ハイブリッド開発手法
ウォーターフォールモデルも最適ではない一方で、アジャイルモデルも最適ではない場合には、「ハイブリッド」という選択肢が残ります。
しかし、単にハイブリッドにすれば問題解決というわけでもありません。また、ハイブリッドを簡単に採用できるなら、「ハイブリッド」のような名称ではなく別の開発モデル名として確立していてもおかしくないはずです。つまり、ハイブリッドモデルと言うのはやすしですが、実際には開発モデルといえるほどテンプレート化できないのだと思います。
しかし、あくまでアジャイルモデルを取り入れる際の導入の一例と考えれば、有用なポイントも多々あります。ここでは、筆者が行うハイブリッドモデルの導入方法と、その背景や理由を中心に説明します。
顧客側から見えるスケジュール
管理モデルを変えるということは、多くのステークホルダーを巻き込み、全体の合意が得られないと実行できないと思う方も多いと思います。そこで、改めて前提となるプロジェクト全体のスケジュールとフェーズについて考えてみます。
このとき、顧客側視点でスケジュールを見れば、開発側が担当する部分についてはブラックボックスとなっています（図8）。
ウォーターフォールモデルでは、このフェーズは開発側が請け負って最適な方法を自由に採用していいということです。つまり、このフェーズでは本来、比較的開発側が自由に計画しても良いはずです。そして、この大きな工程を生かして、ハイブリッドにして顧客側の意見を取り入れやすくすることは顧客側の要望とも矛盾しません。
ハイブリッド化したスケジュール
この大きな工程を生かして、スケジュールを作り直したのが、図9です。
全体のスケジュールを大きく半分に分け、当初の要件でMUSTとなる機能と、全体像を理解する上で必須となる機能のみを実装する初回開発フェーズと、そこで生じた課題解決をするための開発フェーズに分けます。
また、顧客から随時要望を聞くタイミングは後半の開発フェーズで行います。
開発管理の違いのイメージで言えば、（1）の開発工程がウォーターフォールモデル（正確には機能別組織）の考え方をベースにした開発フェーズであり、（2）で現実との乖離を埋める課題を列挙し、そして（3）の工程でアジャイルモデルの考え方を取り入れるという流れです。
ただし、ここでは各モデルの実践ノウハウではなく、その意図や理由についてより着目するようにしてください。
