【連載】ドキュメントルール

スポンサーリンク

ドキュメントルール

各部門へのヒアリングの前にドキュメントルールを決めた。議事録は企業や上司によって様々なため、本プロジェクトでは、下記ルールとした。

  • 結論を記載する
  • 宿題と期限を記載する
  • 結論には、経緯(なぜ)も記載する
  • 使用ドキュメントを記載する
  • 時系列で記載せず、議論のテーマ毎に記載する
  • 5W6Hで記載する(誰が読んでも同じ理解ができるようにする)
  • ヒアリングに参加していなくても伝わるようにする(社員なら)

また、要件定義書は下記ルールとした。

  • 5W6Hで記載する(誰が読んでも同じ理解ができるようにする)
  • ヒアリングに参加していなくても伝わるようにする(社員なら)
  • 要件は全て記載する。パッケージを利用する部分であっても記載する。(要件定義はフィット&ギャップではない。フィット&ギャップは別資料とする)
  • 要望定義は議事録ではないので、実装する機能と実装しない要望(保守フェーズでの候補)は別に記載する。
  • 書く人によってレベル、表現方法を変えない。
  • 共通部分があっても、ドキュメントを正規化しない。あっちこっちと参照としない。(要件定義はお客様とベンダーと合共通認識を持ち合意することが目的である。記載の合理化は関係ない)

当たり前のようで、実は難しい。残念ながらエンジニアは、開発スキルには長けているが、ドキュメント能力は高くはない。しかも、ベンダーがお客様に提出する前にレビューをするが、レビュワーは内容を知っているので、表現がよくなくても理解できてしまう。しかしながら、お客様からすれば、伝わらない悪いドキュメントとなるのである。

タイトルとURLをコピーしました