経営者やCIO、ITマネージャーが理解しておくべきアジャイル開発の本質

経営者とCIO／ITマネージャーが理解しておくべき"アジャイル開発"の本質

　アジャイル開発の実践に関する記述は諸先生・諸先輩方が書かれているが、経営層やCIO／ITマネージャーが理解しておくべきアジャイル開発の本質についてまとめた書籍や論文、インターネット上の記事や投稿などは残念ながら未だ見つけることができていない。

　経営層やCIO／ITマネージャーがアジャイル開発を検討し、結果として取り組む際には、手法や実践、事例だけでなく、アジャイル開発の本質を理解しておく必要があると考えている。昨年2017年5月にチームを立ち上げアジャイル開発の実践を進めてきたが、筆者自身がマネージャーとしてアジャイル開発の立ち上げ過程で学び、経験してきたこと、そして様々な気付きに基づき、そこから得られた洞察を本質としてここにまとめておきたい。

　なお、このまとめは、実践から筆者個人が気づき、学んだことをざっと整理したものであり、書籍や資料を参照せずに殴り書きしたものである。従い、誤認識や不正確なことが少なからず含まれていると思われる。アジャイル開発の諸先生方、諸先輩方および学術的に研究されている方々からの、心優しい忌憚のないご意見、ご指摘をいただければ幸いである。（いくつかのご指摘をいただきました。ありがとうございます。集合知的で良いなと思います。）

従来型のウォーターフォールによるシステム開発が失敗する理由

　ウォーターフォールによるソフトウェア開発が失敗するケースは少なくない。その理由は以下と思われる。

• 初期フェーズにて "仕様"　を確定／決定するものの、開発プロジェクトの途中で仕様の変更、追加が発生することで開発の手戻りが発生したり、当初確定／決定し文書化した仕様に曖昧さが残っているためビジネス要件に適合しないソフトウェアを開発してしまうことが発生する。
• 仕様の変更／追加が発生してしまう理由は、仕様検討の前提であるビジネス要件が曖昧であったり、多くの枝葉の要件にこだわるあまり、ビジネス要件の本質を見失ったり、ビジネス要件の本質が見えにくくなるような記述をし、その結果、読み手によって理解が異なるケースが発生することによると思われる。
• 仕様に基づく初期の開発工数見積もりについて、ファンクションポイント法などよって正確に見積もる方法が取られているものの、何れにしても机上の見積もりに過ぎないため、開発実行フェーズの実績との間に少なくない乖離が発生する。
• ウォーターフォールによる開発では、実際にソフトウェアを利用するエンドユーザーによる確認／検証が開発の最終フェーズまで行われないため、エンドユーザーにとっては使いにくい、そしてエンドユーザーの要求を満たしたものでないことが開発の最終フェーズで発覚することが少なくない。

上記のウォーターフォールによるシステム開発の欠点をカバーしようとしている開発手法のひとつが、アジャイル開発である。

アジャイル開発の特徴

　アジャイル開発の特徴は以下の通りである。

• 開発を短期間のフェーズに分割し、各フェーズの間での見直しを行うことで、仕様の追加／変更に柔軟に対応できる。
• ビジネス要件を、エンドユーザー視点の利用シーンとして整理したユーザーストーリーマップとしてまとめることによって、開発者が全容を理解することができ、またユーザーストーリーマップにおけるエンドユーザーにとって一連の利用シーン毎の優先順位をMVP（Minimum Viable Product）やリリース計画として整理し、開発すべき順番を決めることができるため、開発の区切り毎にエンドユーザーによる確認／検証を行うことができる。
• 上記プロセスを行うことによって、当初のビジネス要件の曖昧さやエンドユーザーにとっての使い易さを随時見直すことが可能となる。いわゆる "つくりながら考える" ことが可能となる。
• 短期間のフェーズに分割した開発単位／期間（アジャイル開発の手法のひとつであるスクラム開発においてはスプリントと呼ぶ）毎に、振り返りと改善活動が行われる。この高速PDCAとも言える活動により、開発生産性の更なる向上を適宜実施することが可能となるとともに、開発途中において過去の実績をもとにその後の未来の開発工数を見積もることによってより、開発工数や開発完了時期をより正確に見積もることが可能となる。

アジャイル開発の生産性

　加えて、アジャイル開発は以下によって従来手法と比較し圧倒的に高い開発生産性を実現している。

• スクラム開発においてPO（Product Owner）と呼ばれるビジネス要件およびエンドユーザー仕様の意思決定者を開発チームに常駐させることによって、要件／仕様検討による開発の待ち状態をミニマイズすることができる。
• 開発者およびPOが、専用の開発ルームに常駐することによって、開発で必要な情報を全てホワイトボードと付箋紙で整理し、また適宜変更し、常に情報共有することが可能となる。また、曖昧な記述についても適宜フェースツーフェースで確認し、記述を変更することができるため、ビジネス要件サイド／エンドユーザー仕様サイドと開発車の間の理解のギャップを常時埋めながら開発することが可能となる。
• POは開発チーム常駐と言っても、開発チームを拠点にアチコチを飛び回る必要もある。エンドユーザーや様々ステークホルダーとフェイスツーフェイスで頻繁に会うこともこともPOの重要な業務である。そこで得られたビジネス展開における最新状況を、ホワイトボードと付箋紙で開発チームに展開する。ビジネスの背景やステークホルダーの判断基準を開発チームと共有し続けることによって、必要に応じて円滑な軌道修正を行うこと可能となる。
• ホワイトボードと付箋紙による情報共有によって、ワープロや表計算ソフトによる "清書" を行う工数を削減することができる。
• 開発ルーム内で "常時ワイガヤ" 状態で開発を進めることができるため、POを含めた開発チーム内の信頼関係が醸成され、円滑かつ誤解のないコミュニケーションが可能となる。
• スクラム開発手法においてプロダクトバックログ／スプリントバックログと呼ばれる To-Do 型で整理された開発単位を優先順位順に、多能工である開発者が順番に開発実行していくことにより、開発車個人個人の待ち時間をなくすことができる。
• 開発者を専任とし、あらゆる間接業務を行わせないことによって開発実務に集中させ、作業の切り替えに伴うオーバーヘッド（頭の切り替え時間）を無くすことができる。
• 短期間の開発フェーズ毎に振り返り、改善活動、高速PDCAを行うことにより、上記と合わせて開発者が高い開発生産性を発揮できない理由（エクスキューズ）を言えない環境とすることができる。
• 開発チーム内の各種ルールや、開発手法および開発環境、開発するための設備やツールを開発者自らで検討し決定させることで、開発者が開発がうまくいかない理由を他責とできない環境においている。
• 開発チームを最大10名の少人数体制とすることおよび開発チームメンバーをフラットな関係とすること、さらに開発者チームメンバーの心理的安全性（どんな発言でも躊躇なく言える状況）を担保することによって、開発チーム内のコミュニケーションの円滑さを誤解のなさを実現している。心理的安全性の確保は、チームビルディングの際だけでなく常にチーム内で留意しておかなくてはならないし、開発チームやステークホルダー各部署のマネジメントの理解も欠かせない。
• POの開発チームへの常駐や開発途中でのMVPや各リリースのエンドユーザー検証／確認によって、エンドユーザーと開発車の距離が縮まる。それによって、開発者がエンドユーザーにとっての最善を考えながら開発することができ、エンドユーザーにとっての最適なシステムを開発することが可能となる。
• エンドユーザーが適宜開発に関与し、特にユーザーの生産性に最も重要なUI（ユーザーインターフェース）、UX（ユーザーエクスペリエンス）を自ら決定し、適宜改良、改善することによって、エンドユーザー自身が納得できる最善のシステムが開発されることとなる。
• エンドユーザーが適宜開発に関与することによって、エンドユーザーが直感的に利用可能なシステムが開発されるとともに、開発者が開発過程でUI/UXを熟知することができるため、開発者サイドでのユーザーマニュアル作成を省略することができる。

　以上が筆者が考える経営者とCIO／ITマネージャーが理解しておくべきアジャイル開発の本質である。

　この本質を理解したならば、アジャイル開発に取り組まない理由は見つからないのではないだろうか。また、アジャイル開発の計画、実戦において、上記の本質を見失っていないことを適宜確認することを強くお勧めする。
　さらに、この本質を鑑みると、アジャイル開発を自社内での内製ではなく、ビジネス知識の少ない、ビジネスの知見を多くは持たないITベンダーなどに外部委託して推進することは、容易ではなく、また無意味である可能性があり、そして本質を損なう可能性が少なくないことをご理解いただけるであろう。

ーーー
(2018.3.11 一部ご指摘をいただき修正と追記をしました。坂口さん、ありがとうございます。)