• 要件定義の方法が不明確

  •  要件として何をすればよいのかわからない
  •  要件を組み立てる方法がわからない
  •  要求を論理的な要件として組み立てていない


要件定義の方法を知る
  • 要件定義の進め方に問題がある

  •  成果物中心のプロジェクト運営になっている
  •  思考やイメージが共有されない
  •  システムの目指すべき方向が明確になっていない
  •  過去のしがらみを前提にしてしまう


プロジェクトの進め方を変える

こんなことはないですか?


顧客との打ち合わせをリードできない

 顧客の要望を聞くことばかりに打合せの時間が費やされ、脈絡のないやり取りに終始してしまう。

top

ゴールが見えない

 要件定義の結果が最終的にどのような成果につながるのか、つなげていくのか、 よくわからないまま作業している。

top

資料は完成しても要件がまとまらない

 各メンバーが努力して各々の担当する成果物を完成させるが、それらを集めても要件はまとまっていない。

top

議論がすぐに袋小路に入る

 問題を解決すべく分析を繰り返すが、現状を打破できないまま議論がすぐ袋小路に入ってしまう。

top

話がかみ合わない

 バックグラウンドが違う相手と話がかみ合わず、いくら議論を重ねても共通の認識を見出せない。

top

背景にある問題

 

要件定義の方法が不明確

要件として何を定義すればよいのかわからない

 

システムの要件というものの論理的な構造や枠組みをメンバーが理解しておらず、何を定義すれば良いのか見えないまま作業に取り組んでいます。議論に役立つ情報を資料として整理することはできても、それだけで要件が定義できるわけではありません。

 

要件を組み立てる方法がわからない

 

要件の中には相互に関連・依存するものが多く、出された要求を単に列挙するだけでは全体の整合性を保証できません。整合性を維持しながら要件を組み立てる方法を知らなければ、矛盾のない要件を効率的にまとめることは困難です。

 

要求を論理的な要件として組み立てていない

 

システムの要件を定義するには、顧客の漠然とした要求を整理し、論理的に組み立てて、整合性のある形でまとめる必要があります。まずこの認識がないと、いつまでたっても要求を聞くばかりで、課題解決につながるシステムの要件を提示することはできません。
提示した要件はきちんと説明して合意を得る必要がありますが、内容に矛盾がある主張や整合性のない説明では相手を説得できず、議論の主導権を握ることはできません。

要件定義の方法を知る

要件定義の考え方と定義する方法を理解します。そのためには要件定義の構造を知り、その構造に従って定義を行います。

 

活用/要件定義の方法を知る には、このツールの元となったリレーションシップ要件駆動分析(RDRA)という手法の説明と、「要件のツボ」の活用方法が示されていますのでご参照ください。

「要件のツボ」は要件をナビゲートし、要件定義に不慣れな人でもスムーズに要件を定義することを目的にしています。

top

要件定義の進め方に問題がある

成果物中心のプロジェクト運営になっている

要件定義を成果物の集合ととらえ、資料作成を各メンバーに割り当てて作業を進めようとしています。背景には、ガントチャートを利用して作業の並行性を高めるプロジェクト管理手法が普及していることや、個々の成果物は単独で完結できるという考え方があります。しかし、システムの要件は相互に関連する要素からなるものであり、全体として組み立てる作業手順をとらなければ要件定義をまとめることはできません。

 

思考やイメージが共有されない

システムの方向性を決めるためには、各メンバーが自分の考えを表現し、それを全体で共有した上で議論を深め、合意を形成していく必要があります。個々の作業を各人に割り当てて独立して進めていくスタイルでは、それぞれが持つ情報が共有されず、全体を見据えた議論や合意形成ができません。
また、立場や背景が違うと、同じ言葉や表現でも想起される概念やイメージが違うことがよくあります。コミュニケーションの基盤となる言葉や概念を共有せずにいくら議論を繰り返しても、共通の認識を得ることはできません。

 

システムの目指すべき方向が明確になっていない

システムの仕様を策定していく過程では、さまざまな決定を迫られますが、そのよりどころとなるシステムの基本方針や方向性があいまいな状態では一貫性のある判断ができません。たとえば、成果物中心でメンバーが個別に作業を進めるスタイルのプロジェクトや、シーズ中心でスタートしたプロジェクトがこのような状況に陥ることがよくあります。

 

過去のしがらみを前提にしてしまう

過去のしがらみを前提条件としてとらえてしまい、思考がそこから抜け出せなくなっていることがよくあります。場合によっては、しがらみが制約を与えているということ自体、認識されていないこともあります。このような状態では、どうしても現状ベースの議論になってしまい、抜本的な解決策を打ち出すことができません。


プロジェクトの進め方を変える

要件定義は要件を決めていく工程です。要件定義工程全体のタスクを洗い出すことは極めて難しく、それを承知で計画を立てると大抵成果物ベースの計画になります。成果物ベースでの作業では横の連携が取りにくくひたすら個人作業になり、システムの方向性などが見えなくなります。

要件定義では個々のドキュメントを整備することよりもシステムが目指すべき方向性を明らかにすることが重要です。そのためには要件定義メンバーが集まって議論しながらシステムの方向性を共有する必要があります。基本的な方針とシステムの重要な機能が明らかになるまではメンバーが集まって合意のもと進めていく必要があります。

活用/プロジェクトの進め方を変える ではプロジェクトの進め方としてメンバーが集まって作業を行う方式を説明し、その中で「要件のツボ」をどのように活用すべきかを説明しています。

 

top