PMプロの知恵コーナー
先号　　　次号

創造的要求定義

竹腰　重徳　[プロフィール]　：4月号
　経営戦略に沿った情報システムを構築するには、情報システムの目的を明確にし、ユーザーの現状の問題や課題および要求を明確にする要求定義が必要である。もし要求定義を軽視すると、経営戦略に合致していなかったり、あいまいで不明確だったり、合意されない要求が混入するなど、品質の低い要求仕様が作られてしまう。その環境で開発がスタートすると、仕様の変更や作業の手戻り、コスト増、スケジュール遅延等が発生し、プロジェクトが失敗する危険が大変高くなる。また、たとえプロジェクトを無事に完遂できたとしても、現場で使われないシステムが出来上がってしまうかもしれません。
　米国の成功プロジェクトと失敗プロジェクトの調査を行っているStandish Groupの2009年の調査によると、プロジェクトの成功(計画通りの期間・予算内で完了し、要求される機能を備えて完了)は32%、と失敗プロジェクト(完了はするが、期間・予算を超過し、要求される機能の達成率が低い、および中止、未完成のもの)は67%となっており、失敗プロジェクトが成功プロジェクトの倍にのぼる。失敗プロジェクトの失敗要因として、ユーザーの関与不足12.8%、あいまいな要求仕様12.3%、要求仕様の変更11.5%、経営幹部のサポート不足7.5%とあげられている。上位3番までは本来ユーザーである発注者が決めなければならない要求の不備によるものであり、全体の45%を占めている。要求定義がプロジェクト成功のためにいかに重要であるかが示されている。
　そこでシステムの開発(狭義)が始まる前に、要求の品質をできる限り高めておく必要がある。そのためには、要求定義をするときに、ユーザー自身が要求を定義するのを待ってそれをヒアリングするやり方ではなく、ユーザーとの相互作用による能動的な活動を通じて真の要求を引き出す必要がある。表面的に表われている要求だけでなく「潜在的の要求」までも含む「真の要求」を導き出す創造的活動で、直接・間接にそれに関わる関係者間の相互作用と合意形成を通じて引き出される。「顧客に欲しいものを聞いたら、彼らはもっと早い馬が欲しいと答えていたであろう」という自動車王ヘンリー・フォードの有名な言葉があるが、ユーザーが自分の要求を理解しているとは限らないのである。最初から解決すべき問題が明らかにされており、さらには何をどのようにシステム化するかまで決まっていれば楽であるが、ユーザー自身、システム化のイメージが沸かずに混沌とした状態で悩んでいることが多い。要求はすでにユーザーの中に存在しているとの前提に立ち、ユーザーからヒアリングした要求を実現したとしても、価値向上に結びつくとは限りません。
　ヒアリングで得られた要求はユーザーの理解の範囲内で生まれた属人的なものや直感的、場当たり的であることが多い。もし、最初のヒアリングだけを信じてそのまま作ったら、大抵は作り直しになる。ユーザーは、自分達が本当に必要としている要求をはっきりと認識していない場合が多い。
　適確な要求を引き出すために、ユーザーの意思確認や合意など、密なコミュニケーションが欠かせません。ユーザーと開発者はお互いの立場や業務が違うため、仕事上の常識や使用する専門用語が異なるため、相手には通じているという思い込みが生じ、工程が進んでから「それは言ったはず」「それは説明しなくてもわかるでしょう」となることが多々発生することがあるからである。また、言葉は、受け取り方により意味が変わるなど、非常に曖昧な性質を持っています。不明な部分や大切な内容は何度もユーザーと確認を取るなど、コミュニケーションには細心の注意が必要である。
　そのため要求定義では、業務とシステムに精通したビジネスアナリストが、ユーザーと開発者を含む様々なプロジェクトステークホルダーとのコミュニケーションの仲介役となり、システム化に対する様々な要求を引き出し、分析し、要求仕様を作成することが勧められる。しかし、ビジネスアナリストは、ユーザーとステークホルダー間の単なる橋渡し役ではありません。ユーザーが表現した要求だけにとらわれず、表面に出てこない、まだ気づいていない潜在的な「真の要求」を引き出し、顕在化させ、真のユーザー要求を創り出す創造的要求定義が求められる。

以上
ページトップに戻る