情シスの影響力を高める！情シスのための要件定義書レビューのチェックポイント

 

要件定義書はベンダーの最重要成果物

ベンダーの成果物の中で、最も重要なのが「要件定義書」です。

この要件定義書で、導入するシステムの「品質」も「費用」も「スケジュール」も決まります。

さらにいえば、要件定義書をどう取り扱うかで、今後の情シスの「影響力」も決まってしまいます。

そのため、要件定義書のレビューは非常に大事です。

要件定義書レビューのノウハウを、情シスの立場で解説していきます。
 

まず目次レベルでチェック

要件定義書は、いきなり細かい内容を見るのではなく、大きな項目単位で「漏れ」がないかを確認していきます。

そのために、まずは目次をチェックします。

目次をチェックするには、一般的な基準を知っていないといけません。一般的な目次のテンプレートは以下となります。

 

このテンプレートは絶対ではありません。システムの特性やプロジェクトの経緯などによって、記載が不要なものもあります。

ですが、「網羅性」のチェックには有効です。

テンプレートと比較してみて、差異があるものは、記載がなくて問題ないものか、本当に漏れなのか、を確認していきましょう
 

各項目の解説とチェックポイント

（1.業務要件）

　業務要件は、システムの前提条件となる重要な部分です。システムとの接点である業務の概要を定義し、そもそものシステム化の「スコープ」を示します。
　ここが曖昧だと、システムの根幹が揺らぎます。プロジェクトの途中で「仕様変更」や「責任範囲」を巡って、ベンダーと揉めることになります。

1.1.システム化範囲

　細かい説明に入る前に、全体概要を示す重要な項目です。
　システム全体構成図のうち、リプレイスすべき対象システムを囲い、「ここを新システムで再構築します」が明確になっているか？を確認します。
　また連携するシステムも描かれていることも確認します。ここから「外部インタフェース一覧」につながっていきます。

1.2.新業務フロー

　新システムを用いた業務フロー（業務フローTo-Be）が明確になっているか？を確認します。
　もし、新業務フローがない場合は、「要件が固まった」と何を根拠に言えるのでしょうか？そのまま新システムを作ろうとすると、ユーザーとベンダーの認識齟齬が大きくなり、途中で揉めることとなります（実際、多いです…）。
　新業務フローは、スクラッチ開発の場合は「あるべき姿」が描かれ、パッケージ導入の場合は「パッケージ標準フロー」が定義されます。
　なお、新業務フローは「作成義務」について、よくベンダーと揉める部分です。揉めないためには、あらかじめ「RFP」の段階で、成果物要求に新業務フローを明記しておくべきでしょう。
 

（2.機能要件）

　機能要件は、要件定義で最も重要な部分です。ここでユーザーの要求が明文化され、システムが備えるべき機能が定義されます。ここで定義された機能をもとに、その後の費用やスケジュールが決まっていきます。

2.1.機能一覧

　機能一覧の中身については、ユーザー側で責任をもって確認してもらいます。
　情シスの立場でやるべきことは、RFPの要求に対するベンダー提案書の「要求機能一覧の回答」と今回の「要件機能一覧」を比較することです。ここで差異が発生した部分（当時は実現可能と回答していたのに、今回実現しないことになっている機能）について、妥当性を確認します。技術面や費用面で見送りで合意となっていればよいですが、合意もなく見送りになっている部分は確認が必要です。
　この「要求一覧」と「要件一覧」の比較こそが、情シスの重要なノウハウであり、ユーザーからの信頼を一気に獲得する重要なステップとなります。何を差し置いても、ここだけは情シスが責任をもってやるべきです。

2.2.帳票一覧

　こちらもRFPの当時のベンダー回答と比較します。帳票は要件定義フェーズで最も「削減対象」となる部分のため、ある程度は差異が発生します。その差異について、妥当性を確認していきます。

2.3.外部インタフェース一覧

　こちらもRFPの当時のベンダー回答と比較します。外部インタフェースはあくまで「自動化」にこだわるべきです。下手に「人的運用でカバー」とすると、後でトラブルの温床となるからです。パッケージはカスタマイズしてでも、あるいは外付けでシステムを作ってでも、自動化を前提に調整すべきでしょう。
 

（3.非機能要件）

　非機能要件とは、文字通り「機能以外」の要件を定義します。
　ユーザーにとって、機能は大前提ですが、非機能は「満足度」に大きく影響します。いくら機能が充実したシステムであっても、動作が遅すぎていては使えません。データが移行されてなければ業務に支障をきたします。システム利用時間に過度な制限があるのも困ります。セキュリティが弱いのもリスクです。
　このような、機能以外でユーザーに影響がある全てをここで定義するのです。
　なお、非機能要件についてはユーザーは良し悪しを判断できません。システムの専門家である情シスが責任をもってレビューすることが求められます。

3.1.移行性要件

　まず、移行のターゲット日と移行期間、全体スケジュールが明確になっているかを確認します。
　次に移行方式を確認します。段階的に移行するのか一斉に移行するのか。また、現行システムと新システムを一定期間、並行稼働させるのか。移行時に業務・サービスを一定時間止めるのか。
　また、移行対象が明確になっているかどうかも確認します。移行データはマスタとトランザクションのどれが対象なのか。新システム切替に伴うネットワークの設定変更や関連するシステムの設定変更が必要か。
　これら「移行要件」が定義され、これから作る移行関連の成果物も明確になっている必要があります。
　移行タスクの詳細化は、次の「移行設計」で行えばよいですが、大まかなタスクについては、ユーザーとベンダーの役割分担が定義されている必要があります。なぜなら、それがベンダーの「移行支援」の見積もり前提となるからです。

3.2.テスト要件

　システムの品質を確保する上で、ベンダーとテスト要件を握っておくことは重要です。
　まずはテスト方針を確認します。新システム導入に必要なテストフェーズを定義し、ユーザーとベンダーのどちらが担当するか明確になっている必要があります。
一般的に、スクラッチ開発やカスタマイズ開発における「単体テスト」「結合テスト」はベンダー側、「受入テスト（UAT）」はユーザー側となります。一方で、その中間にある「システム間連携テスト」「負荷テスト」「本番データ稼働テスト」はグレーゾーンです。テスト一覧の中で役割分担が定義されているかを確認します。
　なお、パッケージ本体は既製品のため、単体テストや結合テストという概念は存在しませんが、システム設定やデータ移行後のテストはどこまでやってくれるのか？を確認します。
　また、テスト環境について定義されていることも重要です。テスト環境が何面あるのか？そのうちユーザーが自由に使える環境はあるのか？本番同等環境なのか？容量やパフォーマンスやデータ移行で制約はないのか？またその費用負担や作業負担は？などを確認します。それら環境が立ち上がるスケジュールについても確認が必要です。

3.3.教育要件

　教育要件については、大きく2つあります。「マニュアル作成」と「ユーザー研修」です。
　マニュアル作成については、ベンダーの成果物の有無を確認します。一般的に「業務マニュアル」はユーザー側、「システム操作マニュアル」はベンダー側となりますが、契約に縛られるので、個別に確認が必要です。マニュアルも一般ユーザー向け、管理者ユーザー向け、システム管理者向けと分かれるので、どこまで作ってもらえるのかを確認します。
　ユーザー研修については、ベンダーの担当者がシステム操作について説明会およびレクチャーの場を設けてくれるのか？を確認します。こちらも参加者（ユーザー・システム管理者など）と実施時間、実施タイミング、実施回数、実施方法（リアル/リモート）などを確認します。

3.4.運用・保守性要件

　運用要件については、システムの利用時間帯はどうなのか（24時間365日なのか、定期的にメンテナンス等で利用制限が発生するのか）、システム監視の方法および体制はどうなるのか？を確認します。
　保守要件については、ヘルプデスクの窓口と体制、受け付け時間、質問方法、定期チェックやバージョンアップの有無と方法、などを確認します。

3.5.セキュリティ要件

　インフラ周りのセキュリティとしては、データ暗号化や監査ログ、侵入検知や侵入防止の仕組み、ソフトウェア脆弱性修正のためのセキュリティ更新やパッチ管理などを確認します。
　しかし最近は、クラウド上にシステムを構築することが多くなりました。そうすると「クラウド提供事業者側の基準に準拠します」の一文で終わることも少なくありません。この場合はユーザー側の指摘でどうにかなるものではなく、許容できないのであればベンダー選定時点で弾くしかありません。
　また、システム内部のセキュリティ機能としてはとしては、ログイン認証、権限グループの設定、データアクセスコントロール、操作履歴や各種ログなどの機能がありますが、「機能要件」に盛り込まれていたら、そちらで確認します。

3.6.可用性要件

　システム全体の年間稼働率、データのリカバリーを伴う復旧水準、災害対策の内容などを確認します。
　ただし、こちらもクラウド上でシステムが稼働するのであればセキュリティ要件と同様に「クラウド提供事業者側の基準に準拠します」の一文で終わってしまいます。

3.7.性能・拡張性要件

　例えば、ある検索画面の表示に30秒以上かかるとなれば使い物になりませんし、夜間バッチの処理が終わらずオンライン開始時間が遅れるのも話になりません。そうならないよう、情シスは性能について敏感であるべきです。特に、取り扱うデータ量が多い場合、または企業の拠点数が多い場合、性能が劣化しやすいため注意が必要です。
　具体的には、画面の参照・更新における性能目標、バッチ処理における性能目標を確認します。また、必要に応じて拡張が可能かどうかも確認します。
　こちらもクラウド上でのシステム稼働であれば「クラウド提供事業者側の基準に準拠します」と言われそうですが、ここは簡単に引き下がってはいけません。例えば、画面表示が遅い場合、ベンダー側の検索クエリーの組み方が悪かったり、データの持ち方が適切でなかったりする可能性があります。そのため「性能目標に達しない場合はチューニングする」という一文を入れてもらうのも方法の1つです。
 

要件定義の品質はユーザーではなく情シスにかかっている

いかがでしょうか。

こうして情シスの立場でチェックポイントを書き出してみると、ほぼ全般的に関わることがわかったと思います。

要件定義レビューは、業務要件の出し手であるユーザーが主役なのは間違いありませんが、同じく情シスも影の主役なのです。

「目次チェック」や「非機能要件」は情シスにしかノウハウがありません。情シスがリードすべきでしょう。

「機能要件」についてはも、ユーザーが内容を確認しますが、ベンダー提案当時との比較は情シスでもできます。むしろこのチェックの方が大事です。

なぜなら、ユーザーは眼の前に書かれてある内容は判断できますが、書かれてない内容は判断できないからです。

どういうことか。

ベンダーの提案書には「できる」と書かれてあったことが、要件定義書には書かれていない、というケースは往々にして発生するからです。

「できない」と書かれてあればすぐに気付けますが、ベンダーはわざわざできないことは明記しません。サイレントに闇に葬るのです。

それを防ぐのが比較チェックであり、情シスの役目なのです。

つまり、要件定義書レビューにおいて、品質を底上げできるかは情シスにかかっているのです。
 

情シスのプレゼンス向上

一般的にベンダーは、要件の出し手であるユーザーの方ばかりを見て、プロジェクトを進めようとします。

ところが、情シスがレビューで的確に指摘をすることで、ベンダーは情シスを無視できなくなります。むしろ、情シスに対して真剣に向き合うようになります。

そして、それを見たユーザーは、情シスを信頼するようになります。

プロジェクトはこれから佳境に入ります。プロジェクト管理で統制をとって進めていく必要があります。そのためにも、この時点で情シスが確固たるポジションを確立しておくことは重要です。

要件定義書レビューは、ユーザーに任せるのではなく、ベンダーに丸投げするのでもなく、情シスが主体的に仕切って進めていきましょう！！

 

（↓関連記事↓）
要件定義終了判定の作り方（サンプル画像付き）
要件定義後、大幅に予算オーバーしてきた場合、情シス責任者はどう動くか？
要件定義のキックオフで、プロジェクト計画書をあえてベンダーに作ってもらう意味とは？