要求機能一覧がなぜもっとも重要なドキュメントなのか？

ユーザーが絶対に作らないといけないドキュメント

「ドキュメントはベンダーが全部作ってくれますよね？」

A社は、あるシステム導入を企画しています。現場作業が中心でアナログな文化ということもあり、A社の方々はドキュメント作成がとても苦手だと言っていました。

システムに関するドキュメントは、確かにベンダーが作ってくれます。そのため、ユーザーに高度なドキュメント作成能力はいりません。

でも、絶対にユーザー側で責任をもって作らないといけないドキュメントがあります。

それが「要求機能一覧」です。

ざっくりいうと、ユーザーがシステムに対して搭載してほしい「機能」のリストです。これは、ユーザーがベンダーに提案依頼書（RFP）を提示する際の、中心となるドキュメントです。

他のドキュメントは多少雑でも構いませんが、これだけはユーザーが時間をかけてでも、こだわり抜いて、全力で作らないといけません。

なぜ、この要求機能一覧がそれほどまでに重要なのでしょうか？

要求機能一覧は各フェーズでどう使われるのか

要求機能一覧の利用シーンと使い方を整理してみると、よくわかります。

①（企画段階）ユーザーの要求整理の基準となる

各部署で何を必要としているかが『要求機能一覧』で明確になります。ユーザーにとって、自部署の要求はすぐにイメージできますが、他部署の要求はこの一覧を通じてはじめて分かります。全社的な要求を一覧上で把握でき、整合性を確保でき、共通認識を持つことがでいます。

②（ベンダー選定）ベンダーを選ぶ最大の基準となる

パッケージの場合は、「ユーザーの要求機能」と「パッケージの標準機能」の適合率が全てです。言い換えると『要求機能一覧』の「Fit率」でほぼ決まります。
スクラッチ開発の場合は『要求機能一覧』をもとに見積もりが行われます。金額はベンダーによって大きな開きがあるため、おのずと選定するベンダーも決まってきます。

③（要件定義）開発スコープと開発費用を決める際の基準となる

『要求機能一覧』を全て実装するわけにはいきません。パッケージではカスタマイズが発生し、費用が膨れ上がります。スクラッチ開発では、もっと顕著に機能の数だけ見積もり金額が上乗せされます。
そのため、要件定義では優先順位の低い機能は見送りとし、開発スコープを狭めていくことになります。『要求機能一覧』で見送りとした機能をグレーアウトし、スコープを明確化した最新版が、要件定義の最大の成果物となります。

④（受入テスト）ユーザーテストの基準となる

受入テストでは、一部の機能に偏ったテストやモンキーテスト（思いつきテスト）では不十分です。また、ベンダーのドキュメントはシステムの切り口で書かれているため、そもそも何を要求したのか記憶も薄れ、埋もれていきます。
そのため『要求機能一覧』で、テストの網羅性を担保します。自分たちで作ったこの一覧でユーザー要求を思い出し、それを軸にテストを進めていきます（要件定義でスコープアウトした機能は対象外です）。

⑤（保守）二次開発リストの基準となる

本番リリースは必要最低限の「スモールスタート」である場合が多く、リリース後に追加改修が必ず発生します。ユーザー利便性を上げるためには、保守が重要となります。
その際の改修候補が『要求機能一覧』のグレーアウトされた機能です。「当初見送ったけど、やっぱり必要だよね」という検討のたたき台となります。要件定義の時に、機能単位で見積もりをもらっているため、追加の費用感もわかります。

つまり、プロジェクトの各工程で『要求機能一覧』は基準となり、プロジェクト後の保守でも基準となります。社内の合意形成においても、ベンダーとの調整においても、「共通のモノサシ」となります。

逆をいえば、この一覧を作るときに手を抜いてしまえば、その後、長期にわたり苦労することになります。追加開発が発生し、追加費用は予算オーバーとなり、スケジュールも大幅に遅れていきます。

システム導入を成功させたいなら、パッケージ／スクラッチ開発を問わず、この一覧の作成に注力しましょう。ここさえしっかり押さえれば、後は何とでもなります。

まさに『要求機能一覧』は、システム導入における「バイブル」といえます。

このバイブルが作られるのは、最初の企画段階です。つまり、プロジェクトは最初が肝心なのです。

バイブルを管理する部署

この『要求機能一覧』は各部署にまたがります。各部署に要求を出してもらい、その後、時間をかけて要求を整理し、統合していく必要があります。

この時、どの部署が管理・編集していくべきでしょうか？

もちろん、情シスです。

なぜなら、どこか1つのユーザー部門が作ると偏りが生じるからです。間接部門である情シスだからこそ、各ユーザー部門の要求を吸い上げ、客観的な視点で一覧に落とし込んでいくことができます。

そうすることで、『要求機能一覧』の書き方の粒度が統一され、中立的な記述は信頼性もあがります。

バイブルを情シスが管理することで、プロジェクトを通じて、ユーザーと主体的に会話ができ、またベンダーとの調整もリードしていくことができます。

貴社の情シスは『要求機能一覧』をきちんと作っていますか？そして、それをバイブルとして、使い倒せていますでしょうか？