■右の図は，システム要件定義が曖昧（十分吟味されていない）ために起こる最悪シナリオの図です。 �@当初仕様のつめが十分でないまま依頼する。 �A開発サイドは十分な分析をしないで開発に入る。 �B十分なニーズが分析されていないので，開発した成果物のテストが出来ない。どのテストをパスすればプロダクトとして合格かという正解が分からない。 �C十分なテストを行われていないまま，リリースされたシステムは初日から問題を起こす。（あるいは動かない） �D対策会議を行い，対策を立て，変更仕様を作成する。 �E問題点の山積みがたまるばかりで，山積み消化のためにたくさんのプログラマを投入する。 �F時間が無いため短期リリースする。するとさらに問題は大きくなっていく。 �G毎日が対策会議ばかりになりシステムは没になる。

「たやすい要件変更」，を受け入れる素地がそろったからと行って，要件定義を曖昧にして良いというものではありません。要件定義というと，メインフレーム時代にシステムを担当された方は，画面設計とか，帳票設計，ファイル設計などを想定される方もいるかもしれませんが，要件定義とは， �@システム化の目標を数値化し（問題点や将来のニーズ） �A要件候補を列挙し，その要件がシステム化の目標を実現できるかを立証し �B要件をマンマシンに分離し（つまりマシン部分がシステム化範囲） �Cコスト採算を計算し，要件ごとの優先度をつけ �Dこのシステムを実現するための阻害要因（リスク）を列挙し，列挙されたリスクを回避するための手段を検討し �E要件をライトウエイトなスレッドに分割する。（従来フェイズドアプローチなどともいわれていました） �Fスケジュールとリソースの計画を立てる という部分です。 　最近のオブジェクト指向開発，特にコンポーネント型の開発手法は開発生産性を高め，うまくまわすことができれば短期間で，高品質のシステムを実現できますが，その前の要件定義がしっかりと分析されていればという前提がなおざりにされています。

■マイホームを建てるときに

■ところがシステム開発の場合

T_Epocｈコンサルティングは，経営サイドのニーズを分析・整理検証し， 開発サイドへの言葉に翻訳し，開発者に伝えるという橋渡しのお手伝いをします。