Tweet

ユーザーが欲しいのはシステムではない

株式会社NTTデータ
平岡 正寿

2007/10/5

前のページ｜1　2｜第2回

要求定義につきまとう困難

　では、なぜ要求定義なるものが難しいのでしょうか？ 思い付くままに挙げてみようと思います。それには以下のような要因が考えられるのではないでしょうか。

• お客さまにも現場ユーザー、経営層などのいろいろな立場の人がいる
• ユーザー個々の思いが異なり、さまざまな意見が存在する
• 現場ユーザーは業務に関するすべての要求を把握しているわけではない
• 現場ユーザーの要求がいつも正しいとは限らない
• 現場ユーザーが経営方針を理解しているとは限らない
• 経営者が現場の状況を理解しているとは限らない
• 経営者は経営を取り巻く状況に応じて経営方針を変えるため、要求を述べるのはシステムを作る前だけとは限らない
• 開発側と現場ユーザーが合意したとしても、同じことをイメージしているとは限らない
• 経営者、現場ユーザー、開発者などが使う同じ言葉が同じ意味とは限らない
• 現場ユーザーが正しく伝えたと思っている要求内容を、開発側が同じ内容で理解しているとは限らない
• 要求はいつまでも同じとは限らない（時がたてば要求は変わるでしょうし、ビジネス環境が変われば要求は変わるでしょう）
• 開発側の意識している要求のレベルとユーザーの意識している要求のレベルとが同じとは限らない

……
……

　この手の話は枚挙にいとまがありません。こうして挙げてみただけでも、要求定義には実にさまざまな立場の人々のさまざまな思いが複雑に絡み合っており、さらに要求自体が時間や環境とともに変化していくものだとすれば、そうした中から真に必要な要求を抽出するのは至難の業のようにさえ思えてきます。このように、要求を定義することが難しいことを述べるのは、とても簡単です。

　しかし、そのままでは問題は何も解決しません。

要求定義の方法論「MOYA」

　NTTデータは、この要求定義の問題に対して、MOYA（Model-Oriented Methodology for Your Awareness）という方法論を定義しました。 この方法論は、要求工学のプロセスを基盤としつつ、要求定義の品質を向上させるための多くのタスクや成果物から構成されています。

　MOYAのプロセスは、大きく2つのSTEPから成っています（図1参照）。 一般に、要求を定義するプロセスは「要求の抽出」「要求の分析・合意の形成」「要求の仕様化」「要求の確認」となっています。

　最初のSTEP1は「要求の抽出」「要求の分析・合意の形成」に当たり、STEP2は「要求の仕様化」「要求の確認」に当たるということになります。

　STEP1では「さまざまなステークホルダが持っているさまざまな要求を、目に見えて理解できる形に構造化する」こと、つまり、要求を探索し、見える形、理解できる形に構造化することを目的としています。

　STEP2では、STEP1で構造化したさまざまな要求に対して、仕様化に向けた準備を行うことを目的としています。

図1　MOYAのプロセス（クリック >> 拡大）

　本連載では、タイトルのとおり「隠れた要求を見極める」ために、MOYAの手法をどう活用していくかについてご紹介していきたいと思っています。

「隠れた要求」を明らかにする

　隠れた要求を見極めるためには、その局面での課題とその背景に潜む「思い」を深く掘り下げて考えることが必要です。MOYAのプロセスとプロセス支援ツールが、「隠れた要求」を明らかにしていく様子を感じ取ってもらえればと思います。

　読者の皆さんが抱えるプロジェクトが、お客さまに本当の意味で満足してもらえることに貢献したい。これが本連載のゴールです。そのために、お客さまの要求を見極めるためのノウハウを次回以降お伝えしたいと思います。

前のページ｜1　2｜第2回

	Page1 お客様が本当に望んでいるもの 軽視されがちな要求定義フェーズ
	Page2 要求定義につきまとう困難 要求定義の方法論「MOYA」 「隠れた要求」を明らかにする