要求仕様書の標準化プロセス

現状の課題と改善策

   問題要因関連図やフィッシュボーンダイアグラムなどを使って分析した問題点（課題）と改善策を記述します。要求分析書では、分析作業に使った関連図などはあくまでも参考扱いとし、それらを整理した結果だけを表形式で記述します。

   課題をクローズアップするうえで大切なのが目的です。課題は次式のように目的とそれを達成できていない現状のギャップになります。つまり、目的がない限り課題もないのです。そのためにも、目的を明確化することが重要です。


   改善策には、運用で解決すべき対策とシステムで解決すべき対策の両方を書きます。大切なのは、なんでもかんでもシステムで解決しようと思わず、運用で対処できるところはシステム化対象外としてもよいということです。

基本要件と優先順位

   要件には「絶対必要」「必要と思われる」「あれば便利」などの重要度があります。システム開発の鉄則は「小さく産んで大きく育てる」ことですので、これらのニーズを整理して優先順位づけします。第一フェーズは、優先順位の高いことに絞ってシステム化することにしましょう。

到達目標

   システムの目的とは別に目標を定義しておきます。目標は作業時間20%削減とか、ミスの半減というようにできる限り数値化して持ちます。以前は「労使上の問題で要員削減とは書きにくい」とよくいわれましたが、最近ではそれが目標の1つであれば明確に記述してもかまわなくなってきています。また経営データの迅速な取得が可能となり、日数にして5日短縮、作業工数にして40時間／月の削減というような目標もよく使います。

   開発側にとっては自分の首を絞めることにもなりかねないのですが、システム的なこともパフォーマンス向上、システムの稼動率アップなどを具体的な数値目標として書きます。

システムの実現手段

   ここでは細かなことではなく、どのようなシステムとするかの全体構想を記述します。既存システムのどれを残して何をリプレースするのか、新システムはどういう基盤技術を使いどのような仕組みを持つのか、それによりどのようにして目標を実現できるかなど、新システムの概要がわかる資料を用意します。

システム化の範囲

   基本要件と優先順位に沿って、今回のシステム化の対象範囲を定めます。概要でとどめておく場合は、何をやり何をやらないかを箇条書きで要件記述します。大切なのは、やることだけでなく、やらないこともきちんと記述することです。

   要求分析作業で出された様々な要望の中から、ニーズが強く実現性の高いものだけがシステム化の対象となります。ユーザは、要求したことはすべてシステム化すると思っていますので、そこで落とされた要望に関しては、運用での対応方法、実現困難なので見送るなどの理由をつけて範囲外としたことを明記します。やる、やらないと明記することにより、レビューによって本当に必要なことが再度絞り込めるのです。

   システム化の範囲をより詳細に記述する場合、新システムにおける新しい業務フローとそのフロー上に登場する機能（画面や帳票）の一覧まで作成します。要求分析フェーズは業務要件を確定する作業ですので、本来ならばここまで行う必要があります。しかし、プロジェクトの事情によりこの作業まで踏み込めないことも多いので、本連載では基本設計の項で作成するものとして説明しました。