「要件定義」の4つの構造と依存関係に着目した実践手法

リレーションシップ駆動要件分析による実践的な要件定義手法（1）

要件定義は詳細な仕様を作成するための入力

システムを取り巻く環境を明確にする

　要件定義というと「開発するシステムの要件を定義したもの」というイメージがありますが、私は「システムを取り巻く環境とシステムの両方を定義したもの」と捉えています。

　要件定義の後には詳細な仕様を決める工程が続きます。従って要件定義は詳細な仕様を決めるための入力情報になると考えます。

　詳細な仕様を決めるためには、仕様を決めるための指針や方針が明確に決まっていることが重要です。方針や指針がぶれると、せっかく決めた仕様も無駄になります。ひいてはそれが手戻りになり、プロジェクトを混乱させます。

　要件定義で重要なことは粒度の細かい情報を定義することではなく、システム化の目的や価値などの方針を明確に示すことです。それがプロジェクトの生産性に大きく関わってきます。

図1　要件定義書は方向性を示す

繰り返し型の開発に使えるの？

　要件定義を行ってその後に詳細な仕様定義工程が続く...こう聞くと「なんだ昔ながらの重厚長大なウォーターフォールのやり方か～」と思われる読者も少なくないと思います。

 

　現在のように変化の激しい状況では、Agile開発などの繰り返し開発（仕様を決めソフトウェアとして動くもので結果を確認する）で進める方が、プロジェクトの終盤で動くものを確認するウォーターフォールよりもリスクが低いと考えています。

 

　しかし、要件定義の段階から繰り返し型の開発を行うのは手戻りが多すぎると考えています。繰り返し型の開発を行うにしても要件定義で方向性を確認した後に行うべきだと考えるからです。

 

　一方で要件定義と並行してアーキテクチャの検討とその検証のための開発は行うべきだと考えています。それにより要件の実現可能性を高めることができ、次の工程での手戻りを減らすことができます。

 

　私は要件定義も洗練化を繰り返しながら進めることを推奨していますが、検証はモデルやツールなどを使った定義情報を検証すべきで、プログラムによる検証はスピードが遅くなると考えています。

粒度が揃っていることが重要

　既存のシステムを再構築する場合などは、要件定義の粒度がばらつきます。既存システムにある機能は細かく定義できますが、新規機能として追加する部分は、要件を定義することが難しく粒度が粗くなりがちです。

　一方、要件定義書を受け取る側は、内容の粒度は一定だと考えて理解します。要件定義書の内容のばらつきに気づくには時間がかかり、それが見積もりなどのさまざまな判断の間違いを誘うことになります。

　詳細な仕様を決めるためには数多くの判断を迫られますが、粒度がばらばらなドキュメントでは整合性が合っていないことが多く、判断基準になり得ません。

　結果的に定義情報を再度分析し均一化することになりますが、一般に大変な工数がかかります。バラツキがひどい場合は手戻りや納期遅れの原因になります。

　大切なことは粒度の細かい情報を書くことよりも、粒度を細かくできない部分に注力し、全体として粒度を揃えることです。そうすることで余分な手間をかけずに次の工程をスタートすることができます。

　結局、要件定義工程のゴールとは、どのような情報をどの粒度で記述するかを決めることになります。決められた時間の中でどの粒度の情報として落とし込んでいくかを軌道修正しながら決めていきます。

図2　成果物の粒度の違い