失敗しない要件定義その４ は 議事録のテンプレート、書式です。ワードとPDFファイル版をアップしておきます。
シンプルですが、構成と大事なポイントは私がフューチャーアーキテクトにいた頃から20年以上変わっていないのでご安心を。
こちらです。議事録（MSワード、PDF）研修も以前ご紹介しました
あまりにシンプルなのでガッカリされたでしょうか？でも、シンプルなほうが書きやすいです。この書式を見ながら、要件検討会の運営も含め大事なことを列挙していきます（検討会は毎週開かれる前提とします）。
要件検討会で一番大事なことは重要な論点を効率良く、徹底的に議論、検討することです。システム設計プロジェクトの最初の段階、要件定義では検討結果、検討状況の確認ツールとして議事録があります。従って議事録の内容、品質、デリバリータイムが重要です。その分、体裁など他のことは端折ります。検討資料と議事録がしっかりしていれば要件定義書はできたも同然です。
失敗しない要件定義のポイント
- 要件定義フェーズのプロジェクト設計（仮説、重要論点出し、推進体制作り、検討会スケジュールの事前調整など）
- 検討会での意思疎通、コミュニケーション
- 検討資料と議事録作り（ドキュメンテーション）
- 検討会の論点は２週前からアナウンスしておく。業務部門内での検討に２週かかるのが相場。その上で必要な資料準備や予習をしてきてもらう。１週前の検討会では進み具合を確認する。
- 検討会の１週前には議論の材料となる資料を用意し、問題がないか予習してきてもらう（検討会資料、業務フロー、データ定義、画面構成・遷移図など）。
- 検討会はスケジュール表で今日の位置付け、論点や、前回の振り返り、宿題状況の確認から入る。1週ぶりなので参加者の準備ができないと、いい議論に入れない。
- 検討会では議論となる論点が絞られているので、各部門の立場で、大胆に見直す案、現状との親和性を維持する案、その間の妥協案、その案をとった場合の盲点などをじっくり議論できる。ただし積み残し、宿題が出るので２週など期限を設けてもちかえってもらう。重要な論点を要件定義前半にカバーしておく。それでも時間がきつくなることがあるので、毎回検討会スケジュールを見ながら善後策を考えていく（検討会スケジュールには問題がなかったことを納得してもらいながら）。
- 検討会では議論の中で別の論点に言及することがあるが、議事録は論点別に再構成し、箇条書き形式とする。言葉を補い要件定義書のインプットになるレベルに仕立てる。確認が必要な言葉にはアンダーラインを引くか、目立つ記号★★を付けるなどして、参加者に議事確認をしてもらう。誰が言ったかよりも、ドキュメントが優先される。曖昧さ、考慮漏れを排除していく(MECEという言葉があったりします)。
- 概ね時間順になるが、それにとらわれず構成の分かりやすさを重視する（論点の階層、議論の粒度など）。
- 発言者の記載は必要に応じて。質問－回答は一文にまとめて構わない。細かい発言、同じ内容はカットする。本線に関わらないが記録に残したいものは、「その他」として最後にまとめておく。
- 決定事項、未決宿題の確認を検討会の最後に行っておく。時間切れの場合、メールでの議事確認を必ず伝えておく。
- 議事は必ずレビュワーがチェックする。書き始める前に重要ポイントをおさらい、確認しておくと早く正確に作ることが出来る。
- 議事送付は当日か翌日までに行う。
永島志津夫
全社のシステムを少ない人数で見ていれば時に見落としもあるかもしれません。
オフィスエヌ ショートレビュー5万円から。
連絡先 office.nagasima#gmail.com (#を@に変えてメールをお願い致します
