「要件定義」って難しい!?その必要性について考えてみました

「要件定義」って難しい!?その必要性について考えてみました

要件定義 … その言葉から連想するのは、そう、 「ムズカシイ!」 IT導入プロジェクトに求められる要求が多様化、複雑化する中、要件定義の難易度も比例して増していますね。 プロジェクトの最初の工程である「要件定義」について、その重要性を考えてみます。

要件定義とは

要件定義 とは、システムやソフトウェアの開発において、実装すべき機能や満たすべき性能などを明確にしていく作業のことです。

ユーザ部門から要求を引き出し、システムに実装するべき機能を整理します。
整理した内容をもとに、業務フローや業務シナリオを作成し、ユーザ部門と認識の齟齬がないことを確認します。

と、簡単なようにも見える要件定義ですが、「システム開発が失敗する原因は要件定義にある」 と言われるほど、実は難しいものだと思います。どのように要件を考え、どこまで検討すべきか、よく考えなければなりません。

プロジェクトのカギを握る「要件定義」

一般的な開発プロジェクトは、
要件定義 → 設計 → 製造 → テスト
という工程により構成されることが多いですね。

その最初の工程である「要件定義」は、プロジェクト成否のカギを握るといっても過言ではないでしょう。

「プロジェクトのスタートと同時に要件定義に着手」というケースがほとんどだと思いますが、その準備に時間をかけることが大切だと考えられます。
昨今の開発期間短縮傾向を受け、プロジェクトの各フェーズの時間的制約は、厳しさを増す一方です。

「設計や製造の期間を確保するためにも、早めに要件定義に着手したい。」
「要件定義に時間をかけても、細部を決定できず、結局は下流工程でカバーせざるを得ない。」
など、要件定義の重要性は理解しつつも、十分な時間を割くことは現実的に難しいことも確かです。

しかし、プロジェクトの冒頭、しかも、今後の開発作業のすべての基準となる要件定義およびその準備にこそ、手間と時間をかけるべきではないでしょうか。

では、要件定義を成功させるために、何が必要か、2つの観点から考察してみましょう。

出典:「オレゴン大学の実験」 クリストファー・アレグザンダー (著) 宮本雅明 (翻訳)

其の壱 - 要件定義は準備が大事

要件定義を成功させるために、事前にしっかりと準備することが大切です。
具体的には、

  1. インプットの内容
  2. アウトプットの内容
  3. 役割分担

を明確化します。
では、一つずつ。

1 インプットの内容

業務改革やITコスト削減などプロジェクトの目的はいろいろですが、多くのプロジェクトでは、すでに何らかのシステムが稼働しており、そこにある何らかの課題をシステム刷新によって解決したいというのが一般的です。解決のためには、既存システムを調査し、現状を正しく理解することが大切です。

要件定義を始めるに当たり、重要なインプットが「現行の業務フロー」と「現行システムの設計書」です。

ただ、残念ながら、これらのドキュメントが当てにできないケースが多いのも事実で、仮にドキュメントとして存在していても、メンテナンスされていないなど、悲しいことによくある話です。

ではどうするか。保守担当者やユーザなど、関係者からヒアリングして、精度を高めるしかありません。一般的にこれらの作業には多くの時間やコストがかかります。限りある資源(時間とコスト)を節約するために、要件定義作業に着手する前に、確認できるように調整することが望ましいです。

2 アウトプットの内容

要件定義の成果物は、「要件定義書」ですが、具体的には、どのようなものでしょう。

明確な定義は難しいですが、要件定義で決めるべきは、後工程となる「設計工程で必要となる項目」です。現状の業務を整理し、それをベースに将来の業務をシナリオ化し、業務の流れを明らかにします。他システムとのデータのやり取りについても明確化し、機能面のみならず、非機能(組織など)や運用に関する事項もまとめます。

3 役割分担

ここでの役割分担とは、おもに「発注側」と「受注側」における関係です。

要件定義における各作業について、担当者が明確に決まっていない場合、現行業務の詳細調査や、To Beモデル(将来像)の策定など、本来、発注側でなければ実施できないタスクを、(現業多忙などを理由に)受注側に任せてしまうケースもあります。

役割外の作業が発生すれば、本来やるべき仕事ができなくなります。そのような事態を回避するためには、作業分担を明確にすることが大切です。
細かな作業に至るまで、誰が実施するのか、支援するレベルなのかなど、決定事項を文書化し、関係者全員で合意します。

ともすると、受注側(開発チーム)が、役割外の仕事を抱え込み、スケジュールに影響を及ぼすことになりかねません。これはお互いにとってのデメリットとなりますので、役割分担に関しては、真剣にかつ遠慮なく決定すべきです。

 其の弐 - 要件定義では解決策も決める

上述「要件定義とは」にも出てきましたが、要求という言葉があります。
「要件」と似ていますが、大きな違いがあります。それは、
要望は「やりたいこと」、要件は「やりたいことをどうすれば実現できるか」。つまり、解決策まで含んでいるのが要件なのです。

ユーザの要求の中には、さまざまな理由で実現できないものがあります。
実現できるものは、「どのようにして」を明確に、実現できないものは「なぜ」も含めて明確化します。

既存のシステムをリプレースする場合、ユーザ部門は今ある機能は踏襲される前提で考えてしまいます。できないことは早めに(要件定義の段階で)明示しなければなりません。

要件定義を終えるタイミングは、要求に対する解決策が提示され、設計に落とし込むレベルまで文書化されていることになります。

この段階での成果物の品質が、そのままプロジェクトの品質に跳ね返ると考え、ユーザ部門とのコミュニケーションを密にして、「要求」を「要件」にまで昇華させ、設計工程に引き継ぎましょう。

要件定義が引き出すものは…

要件定義を終えると、次は「設計」工程です。

ここまでの過程で、発注側と受注側との間で、相当量の情報共有がなされ、コミュニケーションスキル、ドキュメント作成スキル、業務理解の向上が進んだことでしょう。

ユーザ部門との信頼関係も増し、後続の工程に良い影響を与えることが想像できます。要件定義が引き出すのは、ユーザの要求や解決策だけでなく、こうした目に見えない、しかも大切なものなのかもしれませんね。

記事は、予告なく変更または削除される場合があります。
記載された情報は、執筆・公開された時点のものであり、予告なく変更されている場合があります。
また、社名、製品名、サービス名などは、各社の商標または登録商標の場合があります。