ハイブリッド開発の後半（アジャイルモデルフェーズ）
開発の前半が終わったら、続いて開発の後半へとフェーズを進めます。そして、ここではアジャイルモデルをできるだけ採用するようにします。ただし、初回開発フェーズで大きな問題がある場合には、その問題を中心にプロジェクトを進める必要があります。
課題からタスクを作成する
このフェーズでは顧客から再度、要望を聞くフェーズでもあります。そして、このときには開発側も顧客側が明示した内容だけではなく、その背景に隠れた要望や矛盾点などにも気がついているはずです。
また、顧客側も初回開発フェーズでの成果物をみて、開発側が勘違いしている場合でもどのような勘違いが生じているのかがわかりやすくなっています。つまり、双方がコミュニケーションを円滑にするために、相手側により近付いた視点で会話ができるということです。
そして、初回開発フェーズでの課題一覧を元にそれらをどのように解決すればよいかという視点でのみ会話ができるため、会話の粒度がぶれにくくなるはずです。その結果、双方が理解しやすいタスクが作りやすくもあります。
短いサイクルでの開発を実現する
アジャイル開発の難しい点は、短いサイクルでの開発・リリース・評価を実現できるようにすることです。そして、そのためには以下のすべてのことを満たす必要があります。
- 1つのサイクル内で実現可能なようにタスクを分割する
- スケジュール遅延影響が大きくならないようにタスクを分割する
- 実現する単位をメンバーで評価可能なレベルにタスクをまとめる
もし、全員がすべて同じ知識や前提を共有していれば、どのようにタスクを分けても評価可能であるため、この条件を満たすことは難しくありません。しかし、実際には非常に高度なことを求めてられています。プロジェクト初期にこの課題を目にしたら、どこから手をつけて良いのか筆者もわからなくなります。
一般的にアジャイルモデルが機能するために非常に時間がかかると言われる原因は、このことだと思っています。
アジャイルモデルの1つの例であるスクラム手法においても、バックログ（TODOタスク）の粒度やスケジュールの見積方法などの考え方が分からないという質問が多いことからも、多くの疑問や難点は、この3つを満たすための方法がわかりにくいということだと思います。
しかし、初回開発フェーズを経ることで、これらの問題に対して対応しやすくなっているはずです。というのも、多くのタスクがゼロからの開発ではなく、機能の追加、もしくは修正になっているためです。機能の追加、もしくは修正というのは、ゼロからの創造ではないため、多くの人が同じイメージを持ちやすくなっています。
従って、プロジェクト当初であればどのようにアジャイル開発に着手すればよいかイメージもできなったことが、このフェーズではむしろ、ウォーターフォール型ではどうやって進めればよいか分からないと思えるほどの違いがあるはずです。
実は、初回開発フェーズは、このようにアジャイルモデルを導入する際にもっとも難しい点をあまり意識せずに解決するためのフェーズでもあったのです。
その他のメリット
開発メンバーがアジャイルモデルの導入に好意的であり、また、短いサイクルを実現するためのタスク管理もよりコミュニケーションを密にすることで解決できると考えている場合でも、このような考え方で前半と後半に分けるメリットがあります。
それは、プロジェクトの開発ルールの標準化がしやすく、かつ、人員管理がしやすいということです。
前述したようにゼロから機能を開発する能力はスキルや経験に大きく影響します。そのため、初期フェーズで開発ルールを標準化しようとすると、実現するためにルールを破る必要性に迫られるケースがあります。
リスクが高い機能実装ほど、開発経験が多い、もしくはスキルが高い人が担当するのですが、一方で実現性が難しい場合ほど、ルールにこだわることができなくなります。
つまり、そのような模範となる人がルールよりも実現性を重視しているように見えると、ルールが崩壊、もしくは軽視されます。このように、プロジェクトのリスクが見えない時点でルール着手から始めるとうまくいかないケースは多くあります。
また、開発後半の機能の追加や修正の開発フェーズでは、限定した実装や問題が見えている状態での開発になるため、経験やスキルの影響度はより小さくなります。つまり、ベテラン開発者とビギナー開発者の差が小さくなっているということです。
当然、開発ルールも同じ前提に限定しやすくなるため、ルールが守られた状態で運用しやすくなっています。また、それは同時にメンバーの入れ替えや追加がより容易になるということです。
これは、プロジェクトのスケジュールが足りなくなったときに大きな効力を発揮します。スケジュールが足りなくなる多くの場合、教育や引き継ぎなどのタスクがよけいに増えてしまうために、実際には人員を増やしても大きな効果が得られない場合が多々あります。しかし、このようなフェーズ分けを行うことで、部分的な支援も受けやすくなるため、想定外の工数超過リスクにも対応しやすくなります。
最後に
今回紹介した方法ではあたかも問題がなく、メリットばかりと思えるような紹介と感じた方もいると思います。しかし、実際に実行しようとすると様々な課題が生じます。
それは、もともと持つ様々な矛盾ゆえに生じるものであり、その矛盾の種類や程度によって様々な見え方として現れます。そのため、異なる課題に感じてしまうこともあります。
しかし、筆者は矛盾の程度は違えど、多くの場合、その根本となる原因は多くの場合共通していると感じています。そのため、ここで紹介した内容は方法論ではなく、このような方法を選んだ理由と原因により着目してほしいと思っています。そして、この記事を読んでいる読者の多くは、学問としてのアジャイル開発を望んでいるわけではないと思いますので、プロジェクトを成功に導くための取捨選択をしていけばよいでしょう。
