[要求仕様の美学]

2008年12月22日(月)福田 修

　前回（要求仕様書の用途を知り必要事項をもれなく記載する：第2回）、システム取得者側が要求仕様書に記載すべき必須項目とオプション項目を挙げた。今回は、それぞれの項目を詳細に見ていく。

　要求仕様書は必ずしも取得者側がすべて自力で完成させる必要はない。システムの規模や技術的な難易度によっては、システム供給者側に任せたほうがよい項目もある。だが、「なぜその項目を書く必要があるのか」「どのような点に留意して書くのか」を取得者側が理解しておくことは重要である。

要求仕様の必須項目─利用イメージを具体的に描く

まず、要求仕様書に必ず記載すべき10項目について述べる（表1）。これらの項目を記述する際は、抽象的な議論にならないよう心がける。

表1 要求仕様の必須10項目

項目	記述する内容	記述する目的
システム化の目的・狙い	システム化の目的や方向性、期待する効果 例）業務プロセスを効率化し、年間5000万円のコストダウンを図る	経営者や供給者とこれからの方向性を共有し、システム化の当事者全員の力を集約する
現行の問題点	日々の業務における問題点、困っていること 例）在庫管理業務で入力作業の負荷が高い。作業時間は50時間/月	経営者や供給者に、システム化の理由・背景を伝える
解決策の概要	考えられるすべての解決策と、そのなかでシステム化による解決策が最善であるという論的背景	経営者や供給者に、問題解決の方向性やシステム化の必要性を伝える
用途・利用者	利用者のプロフィール（社名・部署名・所在地・利用人数）や、システムの使い方	経営者や供給者に、システムの利用イメージを伝える
要求すべき機能	「解決策の概要」を実現するために必要な機能の詳細な定義 例）クライアントPCの稼働状況を5分おきに確認し、異常を発見したら管理責任者にメールで通知する機能	経営者や供給者に、システムの具体的な機能や実装イメージを伝える
実行環境	システムの種類やOS、サーバー、DBといった動作環境や、クライアントPCのOS、ブラウザ、他システム向けアプリケーションの有無、通信回線の速度といった利用環境	供給者に、システム規模を最適化するための材料を提供する
システム化範囲	開発範囲や他システムとのデータ連携の有無、求めるセキュリティレベル	供給者に、既存システムとの整合性をとりつつ、必要なセキュリティ対策を講じるための指針を与える
操作要件	システムのユーザーインタフェースについて、使用言語やカラー設定、テキストベースかグラフィックベースか、キーボード操作かマウス操作かなど	供給者に、データ入力や画面参照といった機能を設計するための指針を与える
使用条件	利用時間やオンラインアクセスの有無、1日当たりのアクセス件数、同時接続が可能なユーザー数、トランザクション処理、バッチ処理の有無といったシステムの使用条件	供給者に、ハードウエアやソフトウエアを設計するための指針を与える
性能要求	システムにどの程度の応答性や拡張性、可用性を求めるか	供給者に、ハードウエアを選定したり稼働後の運用案、将来の増強案を立案したりする際の指針を与える

1. システム化の目的・狙い

システム化にかかわる当事者全員が力を集約するには、これから進むべき方向について合意しておくことが不可欠だ。このため、要求仕様書にはまずシステム化の目的や狙いを明記する。例えば、「業務プロセスを効率化することでコストダウンを図る」「新商品を投入することで市場を活性化し、収益を増加させる」といったことである。

この項目では、目的に加えてシステム化することで得ようとしている効果について触れる。供給者側が、取得者の期待をまっとうできるかどうか検討するための指標になるからだ。効果については、「年間5000万円のコストダウン」「1カ月平均1000円の収益増加」などと具体的な数値目標を設定する。これにより、システムの規模や範囲が見えてくる。

なお、この「目的・狙い」の内容が細かすぎると、システム化の全体像が分かりにくくなってしまうので注意したい。コストダウンの内訳や収益増の算出根拠といった詳細に言及する場合は、「期待する効果」というオプション項目を別に設けるとよい。

2. 現行の問題点

ここではシステム化したい理由や背景を記述し、なぜこのシステムが必要なのかを鮮明にする。自社が現在どのような問題を抱えているかや、何に困っているのかを「○○業務における△△作業の負荷が高い。作業時間は□□時間／月」といった形で具体的に記述する。

3. 解決策の概要

次に、上で明らかにした問題点をどのように解決するかを記述する。さらに、なぜシステム化による解決策が有効であるかを論証する。この論証を怠ると、要求仕様書を見て投資判断する経営者に「わざわざシステムを開発しなくても業務運用の工夫で問題を解決できるのではないか」という疑問を感じさせる。

解決策の概要は、以下のように記述する。まず、考えられる解決策をすべて列挙し、それら1つひとつがシステム化による解決策かそれとも業務運用による解決策かを整理する。そのうえで、システム化による解決策が最善であると考えられる理由を明らかにする。

この項目は経営者や供給者に全体感をつかんでもらうことが目的なので、ここでは概略にとどめる。詳細な内容は後述する「要求内容」で明らかにすればよい。

4. 用途・利用者

次に、誰がどのようにそのシステムを使うかを明らかにし、システムの具体的なイメージを描く。まず、社名や部署名、所在地、人数といった利用者のプロフィールを記述する。そのうえで、その利用者たちがシステムをどのように使うかを明示する。

5. 要求すべき機能

この項目では、3で提示したものをより具体的な機能に落とし込む。実装イメージを供給者に伝えることが目的であり、要求仕様書のなかで最も重要な項目である。

記述する際は、あまり抽象的にならないよう留意し、要求仕様を作成する段階で分かっていることをすべて書くべきである。例えば、単に「クライアントPCを監視する機能」とだけ書くより「クライアントPCの稼働状況を5分おきに確認し、異常を発見したら管理責任者に電子メールで通知する機能」と記述したほうが、要求仕様書を読む経営者や供給者には分かりやすい。

6. 実行環境

実行環境には、「動作環境」と「利用環境」の2つがある。動作環境は、システム開発時のハードウエアや基本ソフトなどインフラ仕様を決定するために必要な情報である。動作環境については、以下のような内容を記述する。

• システムの種別（基幹系／分散系／Web系）
• アプリケーションが稼働するOS
• アプリケーションが稼働するサーバー
• アプリケーションが利用するDB

もう一方の「利用環境」は、稼働を保証するために必要な情報だ。要求仕様書でこの項目を明確に定義しておかないと、出来上がったシステムがWebブラウザのバージョンにより正しく動作しない、クライアントPCでアプリケーション同士の競合が起きる、といった問題が発生する可能性がある。利用環境については、以下のような内容を明確に定義する。

• システムを利用するパソコンのOSやバージョン
• 利用するブラウザの名称やバージョン
• 他システム向けアプリケーションの有無
• 通信回線の速度

7. システム化範囲について

システム化の範囲を明確にすることは、既存システムとの整合性をとるほか、ハードウェアスペックやセキュリティ対策を明確化するために不可欠である。ここでは、以下のような内容について記述する。

• 開発範囲を記載した図（オプション項目2の業務フロー図で代替可）
• 他システムへの影響範囲
• 求められるセキュリティレベル
• 他の社内システムとの間におけるデータ連携の有無
• 社外システムとの間におけるデータ連携の有無

8. 操作要件について

この項目では、「ユーザーにどのような操作をさせるか」を明らかにする。これにより、供給者にデータ入力や画面参照に関わる機能設計について設計の指針を与えられる。具体的には、以下の内容について記載する。

• 画面上で使用する言語（日本語/英語/その他言語）
• カラーモード（モノクロ/カラー）
• 表示設定（テキストベース/グラフィックベース）
• 操作法（キーボード操作/マウス操作）

9. 使用条件について

要求仕様書にシステムの使用条件を記載することは、ハードウェアやソフトウェア設計の材料となるほかシステム規模を最適化するために役立つ。以下のような内容について記述するとよい。

• システム利用時間
• オンラインアクセスの有無
• 1日当たりのアクセス件数
• 同時接続が可能なユーザー数
• トランザクション処理やバッチ処理の有無

10. 性能要求

ここでは、「システムの性能を、どのような条件でどこまで確保してほしいか」を記述する。供給者側は、これに基づき費用と性能のバランスを取り、ハードウェアスペックや本番後の運用案を明確にできる。この性能要求は、以下のように「応答性」「拡張性」「可用性」に分けて記述する。

応答性：通常時と最大人数接続時のそれぞれにつき、許容できる最大応答時間を記載する。複雑な処理や多数のファイルアクセスが必要な画面での応答時間についても明記する。

拡張性：利用ユーザー数やシステム利用時間が拡大する見込みについて述べる。これは、将来においてシステム負荷が高まる可能性を供給者に認識させるためである。

可用性：システムに障害が発生した場合に生じる業務への影響を提示し、そもそもそのシステムに高い可用性が要求されるのかどうかを記述する。そのうえで、障害発生から復旧までの時間やデータ保存期間、サポート時間に関する取得者側の要求を明らかにする。供給者は、この記述に基づきハードウェア/ソフトウェアの構成や、障害対応体制を決定したりする。