ハイブリッド開発手法とは何か？ アジャイルを部分的に取り入れ導入しやすくする開発手法の進め方を紹介

はじめに

　前回、アジャイルモデルを導入したいと思う時期には、同時にそのモデルを導入することが難しい背景があるということについて説明しました。例えば、機能型組織においてはウォーターフォールモデルの方が組織制約と矛盾が少ないなどです。

　しかし、新たな試みをしたい場合、その前提条件が整っていない状態でプロジェクトを始めなければならないことが少なくありません。今回は、そのような前提が整わない中でアジャイルモデルを部分的に取り入れるための考え方について筆者の事例をもとに紹介します。

アジャイルモデルへの悩みと期待

　システム開発の契約制約や組織制約としてはウォーターフォールモデルのほうがなじむと感じているにもかかわらず、現在のシステム開発ではアジャイルモデルが望まれる理由が多くあります。

　それらの理由について開発者目線で見るとうまく表現できないこともあります。

　なぜなら、開発者目線で話をする場合、自分が置かれている状況における詳細な技術的課題や解決方法について注目しがちです。しかし、他のステークホルダーが開発者と同じ目線で問題を捉えていることは多くなく、そのため、前回、プロジェクトの成長過程や組織からみた場合について紹介しました。

　今回は、開発者目線から見える問題をより多くのステークホルダーに理解してもらえるように説明したいと思います。

　なお、本稿では、システム要件の決定や要望を持つ側を利害関係が分かりやすい「顧客」として記していますが、実際には社内での営業チームや運用チームなど、必ずしも「顧客」ではないケースもあります。自分のプロジェクトに合わせて読み替えてください。

ウォーターフォールモデルを採用した際の悩み

　アジャイルモデルを検討している現場において、ウォーターフォールモデルとはプロジェクト管理手法ではなく、組織制約や開発請負としての契約制約と同様と認識した方がわかりやすいでしょう。なぜなら、プロジェクトの全体には、図1のような大きな流れがあり、その中で自分達（開発側）が制御可能なフェーズは限定されているケースが多いためです。

　このように、スケジュール通りに役割がきれいに分割できるのであれば、ウォーターフォールモデルで問題ないと思うかもしれません。しかし、アジャイル開発手法を取り入れたいというプロジェクトでは、このようにきれいにフェーズ分けができない場合が少なくありません。例えば、要件定義が終わった後の各フェーズなどでも要件の変更をしたいという顧客要望を受け付けなくてはならない場合があります（図2）。

　このような状況では、厳密にはフェーズ分けができなくなります。つまり、現実的にはウォーターフォールモデルではないということです。実際、それぞれのフェーズで変更の要望を出されても、開発側としては要望に応えにくい事情もあります。

　例えば、仕様フェーズで画面の文言レベルやボタン位置などの要望が入っても、できあがる際には基にしている画面が100％同じように実現できるとは限りません。つまり、現時点では仮の画面と言えるわけで、その仮の画面への細かい修正要望ではなく、画面が確定してから要望を受けたいという事情があります。

　同じく、テストフェーズで要望を受けても、すでに画面を確定している段階なのでその要望に対応できない場合もあります。

　このような理由は開発側としては正当であったとしても、顧客側から見れば、いつ、どのタイミングで要望を言えばよいのか分からないため、その理由の妥当性は理解し難いのが実状です。そのような事情を考慮すると、「要望を受け付けないというウォーターフォールモデルではなく、アジャイルモデルの方が顧客要望に添ったモデルなのでは」と感じてしまうかもしれません。

　しかし、実は顧客側としても、常に要望を言いたい訳でもなかったりします。例えば、開発側にとっては画面の文言レベルの修正であっても、その目的は文言内容を通じて要求を伝えているケースもあります。このように、情報を伝える手段と目的が一致していないのは、図3のように双方の理解の仕方に違いがあるためです。

　そして、この違いが要望を上げるタイミングにも生じます。共通認識ができていないと言えるのですが、コミュニケーションを密にすれば解決するという程度の簡単なものでもないと、筆者は思っています。

外部要因と内部要因の要求事項

　先ほどは、顧客が要件を変えたいというのは、共通認識ができていないことが原因として大きいと述べましたが、アジャイルモデルを採用したい理由はそれだけではありません。そこで、要件を変更したいというケースを「外部要因」と「内部要因」に分けて考えます。

　外部要因とは、プロジェクトの関係者が関与できない原因から生じる変更理由です。例えば、市場の変化や顧客ニーズの変化、または、事前調査の読み間違いなどから生じる要件の変更理由です。

　アジャイルモデルを採用する理由の1つとして、この外部要因への対応可否を特徴的なものとして挙げるケースが見られます。このこと自体は間違ってはいません。しかし、開発がスタートしてからこのような「外部要因」による変更要求を受け入れる場合、そのプロジェクトをやり直すくらいの戻りが発生することを許容しないとできません。

　つまり、そのような強い権限を保持する人がプロジェクト内にいるということです。そして、そのような権限を持つことができる場合、プロジェクトメンバーのアサインのやり直しもできるということになるので、そのような場合、既にプロジェクトメンバーはアジャイルモデルに適した事業型組織に近いはずです。

　その場合、アジャイルモデルの採用を拒む制約が少なく、アジャイルモデルの方が自然な考え方になっているはずです。

　一方、内部要因とは、プロジェクト外部の影響以外から生じる要因です。ウォーターフォールモデルの理想系は後工程で生じるリスク要因を前工程ですべて洗い出し解決してから進める事です。しかし、そのリスクの認識や理解の度合いがメンバー間でも違うため、前工程で洗い出しできず、現実には気がついた時点でリスクが表面化します。つまり、全員がリスクに気がつかないということでなく、1人が気がついたリスクを全体リスクとして認識させることが非常に難しいということです。これは、先述した共有認識ができていないこととも共通します。

機能と工数での悩み

　スケジュールにそった開発をする上で、もう一つ大きな問題が機能と工数に関する悩みです。

　とくにウォーターフォールモデルの場合、見積上の工数と、実際の工数がどうしてもぶれてしまいます。しかも、実際の方が大きく膨れてしまうケースがほとんどです。この問題は、開発側の現場ではあたりまえという認識を持つ方も多いですが、一方で、顧客側から見れば理解できないことの1つでもあります。

　その大きな理由の一つが、現在のシステム開発での特徴にあります。例えば、1つの機能を作る際に図5のような構造上で開発をしています。

　この構造が、実際の開発者に様々な課題として降りかかります。その一つが、図6のような工数とリスクのバランスの選択です。

　1つの機能を実現するためにシステム基盤やフレームワークに近い層で行えれば、当然、その上で実現することは少なくなるため、結果、少ない工数で機能が実装できます。

　反面、顧客から見た場合の細かい機能や画面における変更要望を受ける自由度は低くなりがちです。そのため、随時要望を受け入れる前提ではリスクが大きな判断になってしまいます。システム基盤やフレームワークに近い層での開発は技術的難易度も高くなるため、それもリスクが高くなる原因の1つです。

　もう1つの問題が、選択するライブラリやフレームワークに関するリスクです。フレームワークに関するノウハウや経験は業界全体である程度共有されているので比較的問題は軽減していますが、特徴的な機能を実装する際に、それに関わるライブラリの情報は決して多くはありません。また、数少ない情報自体が専門性が高く、採用時点では情報が読み解けない場合もあります。

　しかし、ライブラリの選択は、その後の機能開発に大きく影響を与えます（図7）。

　ライブラリは、初期の仕様を元に実現できるかで選択しているのですが、その後の変更要求までは考慮できません。つまり、未来に生じる問題が予測できない以上、最適な選択が難しいということになります。

　以上のような背景から、機能が決まれば、必然的に不変的な工数が決まるわけでもないということです。

　このような背景について分かりやすく例えると、目的地（機能）にたどりつくまでの古い地図（過去の経験）と交通状況の変化（要望変更）に応じた移動手段（ライブラリ等）が分からないなか、目的地に向かっているというイメージです。

　そのため、同じ目的地に何度も行っている人は、様々な経路と状況を予測し調整可能なのですが、初めての目的地だと実際に出発してみると様々な予測できない課題に直面することになります。