要件はなぜ「文書」になるのか
一言でいうと
要件定義は、文書を作る仕事ではなく、曖昧な言葉を検証可能な文に変える仕事です。番号を付ける理由は、その番号が設計・開発・テスト・検収をつらぬく糸になるからです。
現場の最初の場面
プロジェクト着手から2週目。PMが議事録の束を渡して言います。 「これを整理して、要件定義書のドラフトを作ってください。金曜日のレビュー会議で使います。」
議事録には、こんな文があります。
「注文画面で照会が少し遅いので改善してほしく、管理者はExcelでも受け取れるとよいですね。あ、それから最近セキュリティ監査が入るので、ログイン履歴も残す必要があります。」
この1つの段落は、要件3つです。そして、3つとも今の状態では開発できません。「少し遅い」は何秒のことでしょうか。「Excelでも」は画面そのままですか、別の項目ですか。「ログイン履歴」は成功だけですか、失敗も含みますか、保管期間は。
要件定義とは、言葉を検証可能な文に変える仕事です。
なぜ番号を付けるのか
SIプロジェクトで要件にREQ-014のようなIDを付ける理由は、官僚主義ではありません。このID1つが、以降のすべての文書をつらぬく糸になるからです。
REQ-014 (요구사항정의서)
→ SCR-032 주문조회 화면 (화면정의서)
→ PGM-118 OrderSearchService (프로그램목록)
→ TC-207 대량조회 성능 테스트 (단위테스트 시나리오)
→ ITC-041 주문-정산 연계 테스트 (통합테스트)
→ 검수확인서 항목 14번
このコードブロックの韓国語は、上から順に、要件定義書、画面定義書の注文照会画面、プログラム一覧、単体テストシナリオの大量照会性能テスト、統合テストの注文・精算連携テスト、検収確認書の項目14を表しています。
この連結が切れると、3つの事故が起きます。
- 開発したのに、誰もテストしていない機能。サービスイン後の最初の障害として発見されます。
- テストはしたのに、要件になかった機能。誰が指示したのか、誰にもわかりません。検収のとき、「これは作業範囲外なのに、なぜやったのですか」と言われます。
- 要件にはあるのに、開発がない機能。検収の直前に発見されます。いちばん痛いです。
この3つすべてを防ぐツールが、要件追跡表(RTM, Requirements Traceability Matrix)です。行は要件、列は成果物。空欄がそのままリスクです。
良い要件文の条件
現場で通用している基準は、おおよそ次のとおりです。
- 検証可能(testable): 「速く」ではなく「同時100ユーザーで3秒以内」。数字がないと、検収のとき顧客と揉めます。必ず負けます。
- 原子的(atomic): 1つの文に1つだけ。「照会してExcelをダウンロードする」は2つに分けます。分けて初めて、進捗率が正確になります。分けなければ、永遠に「90%完了」です。
- 出典がある(source): 誰がいつ言ったのか。あとで「そんなことは言っていない」が出てきます。実際に出てきます。必ず出てきます。
- 優先度がある: 高/中/低。スケジュールが押したら、「低」のものから次回のリリースに回します。優先度なしで始めたプロジェクトは、最後にすべてが「高」になります。
要件は必ず変わる: だから変更管理を行う
新人が最もよくする誤解は、「要件をきちんと定義すれば変わらない」というものです。変わらないというプロジェクトはありません。管理されていない変更があるだけです。
変更管理の最小の形は、変更要求台帳1枚です。
| 項目 | なぜ必要か |
|---|---|
| 変更前 / 変更後 | 何が変わったのか、あとで再構成できます |
| 依頼者 | 責任の所在。顧客企業の業務部門なのか、自社のPLなのかを区別します |
| 影響度 | 関連する画面・プログラム・工数(MD)。これが交渉材料になります |
| 承認の有無 | 承認前の開発着手は、無償開発になります |
承認前に開発してはいけません。これは、SIの世界で最も高くつく形で学ぶ教訓です。「急ぎだから、とりあえずやっておいて、文書はあとで」で始めた仕事は、精算のときに根拠がありません。
作業項目対照表: 検収の最終兵器
公共プロジェクトでは、作業項目対照表を使います。提案依頼書(RFP)の作業項目と、実際の成果物を1:1で対照した表です。検収会議は、事実上この表を1行ずつ読む場です。
RTMをプロジェクトの間ずっときちんと更新していたなら、作業項目対照表は、それを並べ直したものにすぎません。そうしていなかったなら、検収の2週間前に、全メンバーが徹夜で逆追跡をします。どちらを選ぶかは、プロジェクトの最初の月に決まります。
追跡表を実際に回し続ける方法
要件追跡表は、作るのは簡単ですが、維持されません。プロジェクトの中盤になると、文書と現実が乖離し、そのときから誰も見なくなります。維持される表には共通点があります。
1か所だけで管理します。Excelとイシュートラッカーに同じ項目があると、どちらも間違います。どちらか1つを原本と決め、ほかの場所では、それを参照するだけにします。報告用の文書が必要なら、原本から抽出して作ります。
番号は絶対に再利用しません。REQ-042が削除されたからといって、次の要件にその番号を与えると、古い議事録とテスト文書が別のものを指すことになります。削除された項目は、削除の状態で残します。
追跡は双方向であって初めて役に立ちます。要件からテストへ下る方向しかないと、「このテストはなぜあるのか」に答えられません。逆方向があって初めて、なくなった要件に紐づいたテストと、根拠のない機能が見えてきます。
| 方向 | 答える質問 |
|---|---|
| 要件 → 設計 → コード → テスト | この要件は実装され、検証されたか |
| テスト → 要件 | このテストは何を保証するのか |
| コード → 要件 | この機能は誰が、なぜ依頼したのか |
変更は、番号ではなくバージョンで残します。REQ-042の内容が変わったなら、新しい番号を与えず、その項目のバージョンを上げます。いつ、誰が、なぜ変えたのかと一緒に。検収のとき、「これは元々こういう意味ではなかった」という争いが、ここで分かれます。
空欄がそのまま危険信号です。設計はあるのにテストがない行、テストはあるのに要件がない行を、定期的に抽出してみます。表をすべて埋めることが目的ではなく、空いているセルを見えるようにすることが、追跡表の存在理由です。
今回のモジュールですること
インタビューのまとめから要件を抽出して番号を付け、追跡表を作り、協力会社が渡してきた追跡表から抜けている要件を機械的に見つけ出すスクリプトを作成します。人の目で照合はしません。500件の追跡表は、目では見きれません。