アイネット－待ちの要求定義から能動的要求開発への転身

　情報システムは企業に不可欠な事業インフラとなり、その品質が経営品質に直接影響を与えるようになりました。このため、要求品質を高めることがますます重要となっています。要求品質は狭義の開発工程よりも上流の要求定義工程で作り込まれます。

　もしこの工程を軽視すると、ビジネス戦略に合致していなかったり、あいまいで不明確だったり、合意されない要求が混入するなど、品質の低い要求仕様が作られてしまいます。その下で開発（狭義）がスタートすると、仕様の変更や作業の手戻り、コスト増、スケジュール遅延等が発生し、プロジェクトが失敗する危険が大変高くなります。また、たとえプロジェクトを無事に完遂できたとしても、現場で使われないシステムが出来上がってしまうかもしれません。

　要求に関して、最初から解決すべき問題が明らかにされており、さらには何をどのようにシステム化するかまで決まっていれば楽ですが、ユーザー自身、システム化のイメージが沸かずに混沌とした状態で悩んでいることが多いのです。したがって、要求はすでにユーザーの中に存在していると前提に立ち、ユーザーからヒアリングした要求の実現が業務効率化に結びつくとは限りません。ヒアリングで得られた要求はユーザーの理解の範囲内で生まれた属人的なものや直感的、場当たり的であることが多いのです。もし、最初のヒアリングだけを信じてそのまま作ったら、大抵は作り直しになります。ユーザーは、自分達が本当に必要としている要求をはっきりと認識していない場合が多いのです。

　適確な要求を引き出すために、ユーザーの意思確認や合意など、密なコミュニケーションが欠かせませんが、ユーザーと開発者コミュニケーションの行き違いは多く発生します。ユーザーと開発者はお互いの立場や業務が違うため、仕事上の常識や使用する専門用語が異なるため、相手には通じているという思い込みが生じ、工程が進んでから「それは言ったはず」「それは説明しなくてもわかるでしょう」となることが多々発生することがあるからです。また、言葉は、受け取り方により意味が変わるなど、非常に曖昧な性質を持っています。不明な部分や大切な内容は何度もユーザーと確認を取るなど、コミュニケーションには細心の注意が必要です。

　そのために、業務と情報システムに精通した要求アナリストが、ユーザーと開発者を含む様々なプロジェクトステークホルダーとのコミュニケーションの仲介役となり、システム化に対する様々な要求を引き出し、分析し、要求仕様を作成するとよいでしょう。
しかし、要求アナリストは、ユーザーとステークホルダー間の単なる橋渡し役ではありません。ユーザーが表した要求だけにとらわれず、表面に出てこない、まだ気づいていない暗黙の「真の要求」を引き出し、顕在化させ、真のユーザー要求を創り出すことをしなければなりません。

　要求定義をするときに、ユーザー自身が要求を定義するのを待ってそれをヒアリングするやり方ではなく、ユーザーとの相互作用による能動的な活動を通じて真の要求を創り出す必要があると筆者は考えています。このような要求定義の方法をここでは要求開発といいます。

　要求開発は、表面的に表われている要求だけでなく「暗黙の要求」までも含む「真の要求」を導き出す創造的活動で、直接・間接にそれに関わる関係者間の相互作用と合意形成を通じて創り出されます。要求品質を上げるために、ただヒアリングをして要求収集するといった待ちの要求定義から能動的に要求を創り出す要求開発に転身することが有効です。

　要求開発に要求される機能は、チームの相互作用により創造的に要求を創り出すこと、創り出した要求をチーム全体が合意をすること、刻々変わるビジネスニーズの変化の影響に対応出来るよう要求の変更に柔軟に対応できること、などが挙げられます。

　アジャイルの特徴は、個人とその相互作用を重視（自己組織的チーム、フェースツーフェースのコミュニケーション重視）、顧客との協調（ユーザーと開発者が協調して開発）、変化への対応（ビジネス価値重視、反復漸進的開発）ですが、これらは、まさに要求開発の機能に適合していると考えます。
アジャイル開発というと狭義の開発工程にだけ目が向きがちですが、要求の品質を作り込む要求定義工程にも目を向ける必要があると筆者は考えます。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　以上
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　