要件定義書のレビューで、必ず確かめる観点

プロジェクトに参画してまだ日が浅いころ、「この要件定義書、一度見ておいてもらえますか」と頼まれることがあります。発注者側の担当者から、あるいは開発を担うベンダーのリーダーから。書いた本人ではない目で読んで、抜けや矛盾を見つけてほしい、という依頼です。

ところが、限られた時間でレビューすると、表記ゆれや誤字、図の番号のずれといった指摘ばかりが並びがちです。それも無駄ではありませんが、要件定義書のレビューで本当に見つけたいのは、そのまま設計に進むと後で手戻りになる穴です。

この記事では、参画者として要件定義書をレビューするときに、必ず確かめたい観点を整理します。書く側ではなく、読んで指摘する側の視点でまとめています。

読む前に、何のためのレビューかを確かめる

最初に確かめたいのは、そのレビューの位置づけです。同じ要件定義書でも、まだ骨組みの段階なのか、承認の直前なのかで、求められる指摘が違います。

骨組みの段階なら、構成や範囲の考え方への意見が役に立ちます。承認の直前なら、細かい言い回しより、承認してしまうと後で困る点に絞った指摘が求められます。依頼してきた人に「今回はどの段階で、どんな指摘がほしいですか」「いつまでに、どの形で返せばよいですか」と一言聞くだけで、レビューの的が絞れます。

あわせて、この文書を最終的に誰が承認するのかも確かめておきます。発注者の業務部門の責任者が承認するなら、その人が読んで判断できる書き方になっているか、という観点が加わります。開発側の視点だけで読むと、業務の責任者にとって読みにくい文書になっていることに気づけません。

レビューに使える時間も、先に見積もっておきます。数百ページの文書を全部同じ深さで読むのは現実的ではありません。業務への影響が大きい部分、関係者が多い部分、過去に議論が揉めた部分を先に読み、残りは目次と構成を確かめる程度にとどめる、という配分を決めておきます。

時間が限られているときは、次の順番で読むと、大きな穴から先に見つけられます。

1. 目的と背景、範囲の章
2. 業務フローと、その分岐
3. 非機能要件と移行の章
4. 個々の機能要件の詳細

細かい機能要件から読み始めると、一つ一つの記述の正しさに気を取られ、文書全体の抜けに気づきにくくなります。全体の骨組みを先に押さえてから細部に入るほうが、指摘の質が上がります。

目的とのつながり ― その要件は何のためにあるか

要件定義書の冒頭には、たいていプロジェクトの目的や背景が書かれています。レビューでまず確かめたいのは、その目的と、後ろに並ぶ個々の要件がつながっているかどうかです。

たとえば、目的に「月次の締め作業を短くする」と書かれているとします。ところが要件を読み進めても、締め作業のどこがどう短くなるのかが書かれていない。代わりに、画面のレイアウトや帳票の項目の話が延々と続く。こうした文書は、承認はされても、稼働後に「目的は達成できたのか」と問われたときに答えられません。

逆の見方もあります。目的とつながらない要件が紛れ込んでいないか、です。ヒアリングで出た要望を漏れなく拾おうとすると、目的とは関係の薄い機能まで要件に入ってきます。一つ一つは小さくても、積み重なると費用と期間を押し上げます。レビューでは「この要件は、どの目的のためにあるのか」を一つずつ確かめ、答えが見つからないものに印をつけていきます。

目的そのものが測れる形になっているかも見ておきます。「業務を効率化する」「情報を一元化する」だけでは、何が達成されたら成功なのかが分かりません。どの業務の、何が、どう変わればよいのか。目的が測れないと、個々の要件とのつながりも確かめようがありません。目的の書き方への指摘は、骨組みの段階のレビューで特に役に立ちます。

指摘するときは、要件を削れと言うのではなく、つながりを書き足してもらう形にすると角が立ちません。「この要件は、目的のどれに対応しますか。対応がない場合、優先度を下げる候補として扱いますか」と問いの形で返すと、書いた側も判断しやすくなります。

範囲外が、はっきり書かれているか

要件定義書には、作るものが書かれています。レビューで意外と抜けているのが、作らないものの記述です。今回の範囲に含めないこと、次の段階に回すこと、別のプロジェクトで扱うことが、明記されているかを確かめます。

範囲外が書かれていないと、何が起きるか。たとえば、受け入れテストの段階で業務部門の担当者が「この帳票はどこにありますか」と聞く。開発側は「範囲に入っていません」と答える。業務側は「入っていないとは聞いていない」と返す。どちらも嘘はついていませんが、文書に書かれていないので、決着がつきません。

レビューでは、ヒアリングの記録や過去の議事録で話題になったのに、要件に載っていない項目を探します。見つかったら、範囲外として明記するのか、要件に加えるのかを、書いた側に判断してもらいます。現行システムにある機能のうち、刷新で持っていかないものも、範囲外の候補です。利用者は今あるものは当然残ると思っているので、なくすなら書いておく必要があります。

範囲外の書き方にも目を向けます。「その他の機能は対象外」のようなまとめ方では、何が外れているのか読む人によって解釈が変わります。外すものを名前で挙げ、外す理由と、いつ誰が扱うのかを一言添えてあるかを確かめます。

非機能要件が、具体的な条件まで落ちているか

非機能要件は、レビューで指摘が出やすい部分です。よくあるのは、項目は並んでいても、中身が一般的な言葉で止まっている状態です。「十分な性能を確保する」「高い可用性を実現する」「適切なセキュリティ対策を講じる」。これでは、設計の担当者は何を作ればよいか決められず、受け入れのときに合否も判定できません。

レビューでは、少なくとも次の項目について、測れる条件や具体的な決めごとまで書かれているかを見ます。

• 性能：どの処理が、どの件数で、どのくらいの時間で終わればよいか
• 可用性：いつ使えればよいか、止まってよい時間帯や長さはあるか
• セキュリティ：誰が何を見られるか、記録をどこまで残すか
• 運用・保守：誰が監視し、障害時に誰が何をするか
• 拡張性：利用者や件数が増える見込みをどう置いているか

数字が書かれていても、その根拠が書かれていないことがあります。たとえば「画面の応答は数秒以内」と書かれていても、それが業務上の必要から来たのか、他の文書から写したのかが分からない。根拠が分からないと、後で費用との兼ね合いで見直すときに判断できません。「この値は、どの業務の場面から決めましたか」と聞いておくと、文書の強さが変わります。

他の文書との整合も見ておきます。非機能要件の値が、基盤の設計方針や運用の契約で決まっている値と食い違っていることがあります。たとえば、要件定義書では夜間も使えることになっているのに、運用の体制は日中だけを前提にしている、という場面です。食い違いは、片方だけを読んでいては見つかりません。

非機能要件は、業務部門が自分から言い出すことが少ない領域です。書かれていないからといって要求がないわけではありません。レビューで空白が見つかったら、誰に確かめれば埋まるのかまで添えて返すと、指摘が動きやすくなります。

例外と異常系 ― うまくいかなかったときが書かれているか

要件定義書の業務フローは、たいてい正常な流れで描かれています。受注が入り、在庫を引き当て、出荷して、請求する。レビューで確かめたいのは、その流れが途中でうまくいかなかったときに、どうするかが書かれているかです。

たとえば、在庫が足りなかったらどうするのか。一部だけ出荷するのか、全部そろうまで待つのか。取引先の情報に誤りがあって請求書が戻ってきたら、誰が直すのか。承認者が長く不在のとき、承認はどう回すのか。こうした場面は、現場では日常的に起きています。要件定義書に書かれていないと、設計者が想像で埋めるか、テストの段階で初めて議論が始まります。

読み方としては、業務フローの分岐や判断のひし形を一つずつ見て、「いいえ」の側の行き先が描かれているかを確かめるのが手早いです。行き先が書かれていない分岐が多い文書は、異常系の検討がまだ浅いと判断できます。

取消、訂正、差し戻しの扱いも、異常系として確かめておきます。一度確定したデータをどこまで戻せるのか、戻したときに連携先のシステムにはどう伝わるのか。業務の担当者に聞けばすぐに答えが出ることも多いのですが、聞かれなければ文書には載りません。

異常系の指摘は、件数が多くなりがちです。すべてを要件定義書に書き込むと、文書がふくらみすぎることもあります。業務への影響が大きいもの、頻度が高いものは要件として書き、それ以外は設計の段階で詰める項目として一覧に残す、という分け方を提案すると、書いた側も受け入れやすくなります。

移行と、決めた人・決めた日付

最後に確かめたい観点が二つあります。移行の要件と、決定の記録です。

移行は、要件定義書の中で後回しにされやすい部分です。新しい仕組みを作る話に比べて地味で、詳細は後の工程で詰める、と書かれて終わっていることがあります。しかし、どのデータを、どの時点のものまで、どの程度きれいにして持っていくのかは、要件の段階で方針を決めておかないと、後で費用と期間が大きく動きます。過去のデータを何年分持っていくのか、切り替えの日に旧システムと新システムをどう並行させるのか。少なくとも方針が書かれているかを確かめます。

移行では、データを直す作業を誰が担うかも確かめます。古いデータの誤りや重複を直す作業は、システムの担当者だけではできず、業務部門の確認が要ります。その作業を誰がいつ行うのかが書かれていないと、移行の直前に業務部門へ大量の確認依頼が届くことになります。

もう一つは、決めた人と日付です。要件定義書の中には、議論の末に決まった事項がたくさん含まれています。その決定を、誰が、いつ、どの会議でしたのかが書かれているか。書かれていないと、後から別の人に「そんな決定は聞いていない」と言われたときに、立ち返る先がありません。

たとえば、要件ごとに出典の欄を設け、元になったヒアリングや会議の日付を書いておく。大きな判断は、決定事項の一覧に決めた人の名前と日付を残す。レビューでこの記録が抜けている箇所を見つけたら、それだけでも十分に価値のある指摘になります。

指摘を、相手が動ける形で返すために

どれだけ良い観点で読んでも、指摘の返し方がまずいと、文書は良くなりません。指摘が数百件並んだ表を渡されても、書いた側はどれから手をつければよいか分からないからです。

一件ごとの指摘には、該当する箇所と、なぜ問題か、どう直せばよいかの案を、短くそろえて書きます。案があると、書いた側は賛否を返すだけで済みます。

次に要件定義書のレビューを頼まれたら、指摘を「承認の前に必ず直したいもの」と「直せればよいもの」の二つに分けて返してみてください。前者には、目的とつながらない要件、範囲外の未記載、測れない非機能要件、異常系の空白、決定記録の抜けといった、この記事で挙げた観点の指摘が入るはずです。分けて返すだけで、書いた側は限られた時間をどこに使えばよいか判断できます。そうしたレビューを重ねることが、参画者としての信頼につながっていきます。