役立つシステムへ向け、隠れた要求を見極めよ！：隠れた要求を見極める！（6）（1/2 ページ）

本連載の最終回となる今回は、システム設計フェイズに入る前に、要求定義フェイズの最後で行うべきタスクを解説する。そして最後に、本連載のこれまでの内容を振り返りながら、要求定義で最も重視すべき事柄について述べる。

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

システムの検討に入る前に

　前回、要求定義においてゴールモデルを利用する意義と、ゴールモデルから「あるべき業務モデル」を抽出し、それを実現するシステム機能の検討へとつなげていく道程を見ていただきました。ゴールを達成するための「あるべき業務モデル」を見いだし、その業務モデルに組み込まれる具体的な機能を検討し、その業務モデルが本当にゴールを達成できるか検証していくというものでした。

　この作業が完了すれば、そこから先はいよいよシステム化に向けての詳細な検討となります。要求定義のフェイズはこれで完了し、システムの設計フェイズに入るわけです。

　しかし、少し待ってください。システム設計に入る前に、やっておかなければいけないタスクがまだ残っています。それは、以下の2つのタスクです。

1. 「あるべき業務モデル」とそれを実現するためのシステム機能が、運用可能なものであるか、本当に期待する効果を挙げることができるか検証する
2. 今回のプロジェクトでは、どこまでの範囲をシステム化するのか確定する

　では、それぞれのタスクについて詳しく見ていきましょう。

実現可能性を検証する

　上記1.は、これまでの作業の結果導き出した「あるべき業務モデル」を、「絵に描いたもち」に終わらせないためのタスクです。

　まず、「あるべき業務モデル」の業務プロセスを基に、業務ごとの具体的なシナリオを幾つか作成します。これらには、正常系以外のシナリオ（例外処理や代替処理）も含むようにします。これは、例えば正常系のシナリオをより効率的に運用できるよう会社組織を改変した結果、例外処理や代替処理のシナリオが想定されていなかったために安定した運用ができなくなってしまった、といったようなケースを避けるためです。

　次に、それらのシナリオが現実の会社組織の中で本当に実行可能なのか、システムの機能としてそのシナリオを正しくサポートできるのかシミュレーションします。その上で、本当にゴールモデルが当初狙っていた目的を達成できるのかを確認するのです。

　ゴールモデルを使って「あるべき業務モデル」を検討する際に、すでに実現可能性は検討しているはずなのですが、実際には実現できないような理想的なモデルをつい描いてしまうこともあるのです。そこで、業務シナリオの流れに沿って詳細に検討してみることで、個別に検討していたときには気付かなかった問題点や制約事項、機能不全などを見つけ出すことができるのです。

　こうして見つかった問題点は、それまでの検討内容をさかのぼって確認しながら原因を探り、解決方法を検討していくことになります。

システム化の範囲を確定する

　次にやるべきことは、「何をシステム化するか」ということを確定するタスクです。

　すでにゴールモデルの検討時にシステム化する範囲はある程度想定されており、「あるべき業務モデル」もそれをベースに策定されています。ここではそれを踏まえた上で、さらに予算の状況、リソースの状況、社内外のビジネス環境の変化などを加味し、さらに詳細にシステム化の領域を確定するのです。

　この段階まで来ると、システムの具体的な機能も見えていますから、予算見積もりの精度もプロジェクト開始当初の概算に比べはるかに高くなります。その結果、ある程度予算を増減する必要性も出てくるかもしれません。また、現実のプロジェクトでは、まったくの外部要因（経営方針の変更、ビジネス環境の変化など）から予算の調整を余儀なくされることもあるでしょう。

　いずれにせよ、この段階での予算は当初の概算から外れていることが多いため、調整が入ることはよくあります。そうなると、何を行って何を行わないのか、優先順位をつけて調整する必要があります。つまり、単にシステムの機能を「確認」する作業ではなく、現実世界の諸条件に照らし合わせて各機能を取捨選択しつつ、システム化の領域を「確定」するためのタスクなのです。

　これらのタスクを経た上で、ようやくシステムの検討に入ることができるのです。