要件定義書をPMとしてレビューする

要件定義書のレビューに呼ばれたとき、PMは何を見ればよいのでしょうか。

技術的な正しさは、設計担当や有識者が見ます。PMが見るのは、後で問題になりそうな箇所です。見るべき観点は決まっています。

■ ① 目的とつながっているか

それぞれの要件が、立ち上げ期に合意した目的のどれを実現するのかを確認します。

つながらない要件が出てきたら、スコープ外が紛れ込んでいる疑いがあります。「この要件は、どの目的のためですか」と聞いてみます。答えられなければ、なぜ必要かを一緒に確認します。

■ ② 曖昧な言葉が残っていないか

次の言葉が出てきたら、その場で聞き返します。

• 「適切に」「必要に応じて」「原則として」「基本的に」

• 「柔軟に」「速やかに」「使いやすく」「可能な限り」

• 「◯◯等」「◯◯など」

これらは、後で解釈が割れる場所です。設計する人と使う人で違う意味に取られ、テストで発覚します。

聞き方は具体的にします。

• 「この『適切に』は、具体的にどういう状態ですか」

• 「『必要に応じて』は、誰がどう判断しますか」

• 「『速やかに』は何分以内ですか」

その場で決まらないときは、「未確定」と書いて、いつ誰が決めるかを課題管理表に起票します。曖昧なまま通さないことが大事です。

■ ③ 数量と性能が書いてあるか

数字がないと、作れませんし、テストでも判定できません。

• 1日に何件処理するのか。ピーク時は何件か

• 同時に何人が使うのか

• 何秒以内に応答する必要があるのか

• データは何年分保持するのか

とくにピーク時の数字は忘れられがちです。平常時は問題なくても、月末の締め処理で止まることがあります。

■ ④ 例外のときどうするか

正常に進んだときのことは書いてあるが、例外が書かれていないことがよくあります。

• エラーが起きたとき、どう表示し、どう復旧するか

• データがゼロ件のとき

• 締め日をまたいだとき、年度をまたいだとき

• 途中で中断したとき

• 入力を間違えたとき、取り消せるか

ここが抜けていると、テストの終盤で大量に噴出します。要件の段階で埋めておくと、後の手戻りが大きく減ります。

■ ⑤ 誰が使うのか

使う人によって、必要な作り込みが変わります。業務に詳しくない人も使うのか。何人が、どの頻度で使うのか。

これは教育とマニュアルの工数に直結します。使う人が100人いるなら、研修の計画が必要になります。

■ ⑥ 移行と運用が入っているか

忘れられやすい3点です。

• 既存データの扱い　どこまで移行するか、移行しないデータはどうするか

• 締め処理・定期処理　日次・月次でやることが書かれているか

• 障害時の代替手段　システムが止まったとき、業務をどう回すか

これらは要件定義では扱われず、稼働直前に「そういえば」と出てくることが多い項目です。

■ ⑦ 未確定が明示されているか

すべてを決めきれないのは当然です。問題は、決まっていないことが決まっているように書かれていることです。

未確定の箇所は「未確定」と明記し、いつ誰が決めるかをセットで書きます。これがあれば、設計を進める側も判断できます。

■ ⑧ テストできる書き方か

「この要件は、どうやって確かめますか」と聞いてみます。答えられない要件は、まだ決まっていません。

「操作性を向上させる」は確かめられません。「現在3画面の操作を1画面で完了できる」なら確かめられます。

■ ⑨ やらないことが書いてあるか

対象外の業務・機能が明記されているかを確認します。書いていないと、後から「当然入ると思っていた」という話になります。

■ レビューの進め方

• 事前に読んで、指摘したい箇所に印をつけてから参加する

• その場で全ページを読み上げない。論点だけを扱う

• 指摘は「直してください」ではなく「ここはどうなりますか」と聞く形で

• その場で決まらないものは、課題管理表に担当と期限つきで起票する

• 承認したら、日付を入れて記録する

■ まとめ

PMが要件定義書で見るのは、技術の正しさではなく「後で揉めそうな箇所」です。

とくに効くのは、曖昧な言葉をその場で聞き返すことと、「これはどうテストしますか」と聞くことの2つです。この2つだけでも、レビューの質が大きく変わります。