ドキュメントルール
各部門へのヒアリングの前にドキュメントルールを決めた。議事録は企業や上司によって様々なため、本プロジェクトでは、下記ルールとした。
- 結論を記載する
- 宿題と期限を記載する
- 結論には、経緯（なぜ）も記載する
- 使用ドキュメントを記載する
- 時系列で記載せず、議論のテーマ毎に記載する
- 5W6Hで記載する（誰が読んでも同じ理解ができるようにする）
- ヒアリングに参加していなくても伝わるようにする（社員なら）
また、要件定義書は下記ルールとした。
- 5W6Hで記載する（誰が読んでも同じ理解ができるようにする）
- ヒアリングに参加していなくても伝わるようにする（社員なら）
- 要件は全て記載する。パッケージを利用する部分であっても記載する。（要件定義はフィット&ギャップではない。フィット&ギャップは別資料とする）
- 要望定義は議事録ではないので、実装する機能と実装しない要望（保守フェーズでの候補）は別に記載する。
- 書く人によってレベル、表現方法を変えない。
- 共通部分があっても、ドキュメントを正規化しない。あっちこっちと参照としない。（要件定義はお客様とベンダーと合共通認識を持ち合意することが目的である。記載の合理化は関係ない）
当たり前のようで、実は難しい。残念ながらエンジニアは、開発スキルには長けているが、ドキュメント能力は高くはない。しかも、ベンダーがお客様に提出する前にレビューをするが、レビュワーは内容を知っているので、表現がよくなくても理解できてしまう。しかしながら、お客様からすれば、伝わらない悪いドキュメントとなるのである。
