ハイブリッド開発の前半（初回開発フェーズ）
初回開発フェーズでは、必要最低限の機能を実装しつつ、スケジュールを最短にすることです。その目的や理由について説明します。
初回開発フェーズの目的
初回開発フェーズでの目的は以下の通りです。
- できるだけ早く顧客側がイメージできるようにする
- 人材の適所適材のメリットを最大化する
- 技術リスクをできるだけ早く言語表現化する
- 要件リスクをできるだけ早く言語表現化する
できるだけ早く顧客側がイメージできるようにするという理由は分かりやすいと思います。アジャイルモデルやプロトタイプ開発でも同じような効果が得られると思いますし、このことは先述した内部要因による変更要求による影響を小さくする効果があります。
しかし、目的はそれだけではなく、大きなメリットは他の3つにあります。これらのメリットについてはあまり多くの方が明確に意識したことはないと思いますので、そのことについて説明します。
人材の適所適材のメリットを最大化する
ある機能を実現させる場合の工数、または複雑度などを考慮したポイントを見積もる場合、図10のように考えることが多くあります。
プロジェクトに参加する開発人員のスキルが異なることはごく一般的です。特に開発の初期フェーズではスキルや経験の違いによって工数の差異が大きくなる傾向があります。その原因の1つが「機能と工数での悩み」で説明したように、どの層で開発するかという違いです。
しかし、実際の工数算出では、このような違いを統計的な平滑化を考慮して算出します。もちろん、このような方法が見積として間違っているという訳ではありません。図に示したような3つの機能だけということはなく、実際には非常に多くの機能があるわけですから、全体の工数の数値は平滑化の傾向が生じ、それぞれの差異は無視できるような値に収束します。
しかし、このことは、マクロ視点では正しくても、現実的なミクロ視点では都合が悪いことも生じます。それは、理論上の工数を現実に実行しようとすると、図11のようなことが生じるためです。
この状態はほぼ計画通りとみえるかもしれませんが、機能Cを実装する上での予備は機能Aや他の実装の遅れを取り戻すためバッファです。しかし、計画上にはそのことが反映されていません。そのため、開発者はこのバッファを使って機能Cの実装の充実度をはかってしまうなどの作業を行い、その工数をその機能実装のために消費する方向に動いてしまいます。
しかし、同じ10日を使う開発ならば、図12のように考えた方がよいとは思わないでしょうか。
こちらの考え方では、機能Cを実装する場合の予備が他の機能部分の実装に反映できることが示せています。そのため、現実のリスク管理と計画上のリスク管理の相違が先ほどのすべての機能の中に細かく分散している場合よりも少なくなっているはずです。
また、アジャイルモデルを検討したくなるプロジェクトであるほど、経験者や高い技術を保有する開発者の力が十分に発揮できる必要があります。そのためには、経験豊富な人材やスキルが高い人材が十分に機能するように計画と現実をあわせたスケジュールの方が良いと思っています。
そして、このような考え方にすると、初回開発にかかるスケジュールが全体の2分の1で可能ということも非現実的ではないということも分かるはずです。もちろん、実際にはつくる機能の多さや複雑度によっても異なります。しかし、筆者の経験上では全体の2分の1もしくは3分の1くらいに設定できるとよいと感じています。
リスクの早期発見
この初回開発フェーズではミニマム機能に限定しているとはいえ、あくまで理想的なケースを前提に計画を進めています。従って、現実ではこの計画通りには必ずといっていいほど進みません。
しかし、それでもできるだけ期限を延ばす対応をとってはいけません。そのかわりにスケジュール通りの実装をするために動作上や機能上の制限を設けてもよいようにします。例えば、複雑な設定画面が求められているケースであれば、想定する設定内容を示すJSONファイルをアップロードだけで済ませるくらいに、限定してしまってもよいかもしれません。
このような考え方と実行をすることで、スケジュール通りに行かなかった理由がより明確になってき、以下の視点での判断がしやすくなります。
- 技術的難易度の想定外となるポイントの有無
- 要件や仕様の曖昧性の有無
- 当初の想定と現実の想定との解離の程度具合
なぜなら、誰でも予定通り行かなかった理由を示す場合、その理由としてより正当性がある形で表現したくなります。その意識が常に働くことで、理由として上げられる内容はより具体性があり、同時に解決案も提示されることが多いはずです。
そして、そのような内容は、顧客と開発側がもつ理解の方向性のギャップをより埋めた形で課題事項を話し合うことができる内容にもなっているはずです。
ただし、何らかの具体的解決案がまったくあがらない場合には、それは実現不可能な技術リスクがあるか、もしくはあがってきた要件への理解がまったく足りていない可能性を示していますので、その点で計画を見直す必要があるかも知れません。
また、この手法を実行する際にもっとも注意すべきなのは、スケジュールの遅れが誰かを責める理由にならないようにすることです。一方で、スケジュールの遅れを安易に許容する雰囲気も作らないことも非常に大切です。
