台風10号が近づいているようです。皆さん災害に備えて充分な警戒が必要です。今週はしばらく気を抜けない日が続くと思いますが、大きな被害が出ないことを心より願っています。
IT開発における要件定義というフェーズのあり方について考えています。要件定義という行為についてこだわるのは、プロジェクトの最初のタイミングで実施する作業ですが、この作業が後続の作業内容の良し悪しの全てを左右する、とても重要なものだからです。
また一方でこれまで見て来たように、要件定義という行為自体が様々な問題を内在していて、その品質を上げることがとても大変だということがあります。
今考えているのは要件定義の内容を、ユーザーを初めてとするステークホルダーにどうやって正確に伝えるかということです。
その一つの方法として、アジャイルスタイルの開発手法というものがあります。
そもそもアジャイル開発は、昔ながらの開発手法である「要件定義→基本設計→詳細設計→開発→テスト」というプロセスの一つ一つを確定しながら進めて行くという”ウォーターフォール”という手法に対する考え方として提供されました。
ウォーターフォール型はその名のとおり、プロジェクトのスタート地点を上流と呼び、上流から下流に流れる滝をイメージしたものです。従って、その流れを遡る概念は基本的には持っていません。
ということは、設計フェーズを実施する前に要件定義が完璧に行われているという前提であるということになります。
ただし、現実世界では設計どころか、最下流のユーザーテストの段階で要件定義の不具合が見つかるということも、珍しくはありません。こうなると、プロジェクトは取り返しがつかない状況に陥っていることになります。
これに対して、アジャイルでは開発範囲の全ての機能全体について作業するのではなく、重要と判断する部分から形にしていくという考え方で進めて行きます。
開発範囲を小さく区切って、ユーザーが見て触って評価できる”モノ”を作り、それを繰り返すことで徐々に全体機能を充実していくという考え方です。
アジャイル手法にも様々な考え方がり、それらを見て行くととても面白いのですが、今は要件定義の立場から見たアジャイル手法について考えを進めて行きます。
上でも触れたように、アジャイルは少しづつシステムを拡張しながら、最終形態に近づこうという考え方ですから、そもそもスタート時点で確とした仕様があるわけではなく、作り出すものの機能概念、イメージ、範囲などが存在するだけです。
この手法のメリットは、開発者に一定の方向性（ベクトル）を与えますが、決定された細かい仕様がないので、開発者のイマジネーションでもの作りができるということが一つ上げられます。ただし条件として、開発者もしくは開発チームが高いスキルと仕事に対するモチベーションを持っていることが前提となります。簡単ではありません。
少々長くなりました。次回も続きます。