今日の南関東地方は大荒れの天気となりました。気温も低く強風の中、朝からみぞれが降っています。流石に気分は重く、テンションは低いです。でも気持ちを切り替えて、今週を乗り切りましょう。
さてここ数回に渡り、「ウォーターフォール型開発とアジャイル型をうまくミックスすることで、システム開発の困難さを克服することは可能であるか」について考えています。
アイデアとしてまず思いつくのは、要件を従来の手法でキチッと固めて、開発作業をアジャイルで行うという方法です。なんといっても、アジャイルは開発のスタイルですから。
ところが皆さんもすぐお気づきのように、要件定義の面で捉えるアジャイルスタイルの概念とは全く矛盾してしまいます。なぜならアジャイルは開発作業のスタイルではなく、要件定義を含めたシステム開発全般のスタイルだからです。
アジャイルスタイルの最大のメリットは、要件定義と開発作業が混然一体となって、幾つかのイテレーション（繰り返し）を廻すことで、動くシステムを評価しながら本当にユーザーが必要とする機能だけを現実化するということにあります。
こうすることで、開発全体の期間（つまりコストですね）を短縮し、システムの品質を各段に上げるということを可能にします。
こう考えると、要件定義を従来型の手法で、開発作業をアジャイルでという考え自体が成立しようがないことは明らかです。
では逆の発想はどうでしょうか。つまり、要件定義フェーズをアジャイルスタイルで実施し、そこで固めた要件を、ウォーターフォールスタイルで実装するという方法です。こうすると少なくとも、開発フェーズの期間とコスト見積が可能になります。
要件定義作業が本質的に内包する課題、すなわち「ユーザーは批評でしかシステム機能を評価できない」を前提としたとき、要件定義とモノづくりは切り離せないということになります。
机上の議論と「紙」による要件定義ではその確実性は担保できないわけですから、これも成り立ちそうにありません。
と、ここまで考えを推し進めてきて気づくのは、アジャイル型開発スタイルは開発工程の全般に渡って適用されるべきもので、その一部を切り取って利用することは困難であるという、当たり前のことです。
実はキットPMは要件定義フェーズをアジャイルで実施するという方法が成り立つことに期待を抱いていたのですが、これまで見て来たように論理的に分解していくとちょっと無理があったようです。
しかしながら今回の思考の過程で、アジャイル型開発の適用をレベルで考えるというヒントを得ることができたように思えます。何を言っているか分かりませんね。
次回はこのヒントについて、更に思考を深めていくことにします。