11月も半ばを過ぎて、今年もあと5週間と3日で終わりとなります。とはいうものの、キットＰＭが関わっているプロジェクトも、年末から年明けにかけて最初の大詰めを迎えるので、実のところ、ゆっくり1年を振り返ってなどど悠長なことを言っている暇はありません。でも焦らずに着実に前進するしかないので、ちょっとここらで深呼吸してチャレンジすることにします。
スーパームーン+1day
ITシステム開発の要件定義フェーズにおける、アジャイルの取り組みについて考えようとしています。結構気楽に設定したテーマですが、正直言って実は苦戦しています。
これまで考えて来たように、既存の組織論理とプロセスのオペレーションに従うと、アジャイルという概念自体を企業が受け入れることは難しいわけです。でも、アジャイルの俊敏さと柔軟性の高い考え方はプロジェクトの現場としては大きな魅力があります。
そこでキットPMが思いついたのは、ITシステム開発の中でも最も難易度が高い「要件定義」フェーズをアジャイル化できないかということです。
もちろんアジャイル開発手法の中には、要件定義と開発とテストのシステム開発の全ての要素が混然一体となって含まれているので、そこから一部の要素を抜き出すというのは果たして可能なのか、現時点ではよくわかりません。ただ、一つの思考実験としてトライしてみるのは、それはそれで何かの意味があるのではないかと思っています。
アジャイル型の開発では、実際に動くシステムを短期間に作り上げ、それをユーザーが評価することで、本当に必要で役に立つシステムを作っていくことを目的としています。つまり極端な言い方をすると、本当のシステム要件はシステムを動かし触ってみることで初めて抽出できるということになります。
ただし誤解が無いように申し添えると、近視眼的な批評にさらされることでシステム自体がアサッテの方向に進化しないように、マネジメントによる歯止めが必要なのは言うまでもありません。
ではアジャイルのいいところを部分的にでも取り入れた開発スタイルは成り立つのか、考えて行きたいと思います。
前回、アジャイルがなかなか全面的に受け入れられない最大の原因は、コスト予算の構成が昔ながらの企業の外部発注手法と相性が良くないことにあると考えました。
つまり、予めシステム開発の目的に合わせて詳細を検討し、工数見積を立て、外部委託を予算化するという手法と、スタート当初に完成までの道筋が明らかにできない（どれほどの時間と工数が必要か分からない）アジャイル型開発のジレンマがあります。
まぁ、ウォーターフォール型開発においてもスタート時点において必要な工数と期間が分かっているわけではなく、「要件定義」という行為を行って初めて（不十分ですが）明確になります。
したがって最近のITシステム開発では、要件定義フェーズとそれ以降のフェーズを切り離して考えることが一般的です。
そう考えると、要件定義フェーズを従来の手法で行い開発するべき機能仕様を確定し、それ以降の開発フェーズをアジャイル型で、試行錯誤と再評価というサイクル（イテレーション）を回しすというのはどうでしょうか。これならば、予算は要件定義フェーズで確定し、実際の作業はトライアンドエラーというアジェイルのメリットを使うことができそうです。
果たしてそう上手くいくのでしょうか。次回もさらに掘り下げて行くことにします。