前回は項目１にて報告資料に書く要素の洗い出しを行った。
今回はそれらを報告資料にまとめていこう。
- 報告に必要な要素を考える
- 起承転結の流れに沿って報告内容の骨子をまとめる
- 今後の進め方（全体像、スケジュール、WBS）を簡潔に資料として挿入する
２．起承転結の流れに沿って報告内容の骨子をまとめる
まずはアウトラインをまとめていく。
起: 共感される課題を記載
承: 起の事例を複数入れる
転: 承の改善／失敗事例を入れる
結: 結を導き予想効果を定量化
なお、結は複数施策も可
具体例があった方がわかりやすいだろう。
例えば、あるWEBシステムを開発している場合、以下の様になる。
起: 今回開発するシステムの概要
作業内容 ：XXXX向けWEBシステムの開発（社内システム）
目的 ：YYYY業務におけるXXXXの効率化
目標 ：作業効率の30％改善
期間 ：2022/10/1～2023/1/31
体制 ：リーダー（私）、開発５名（パートナーXX社）
種類 ：WEB開発（画面数10）
進捗指標 ：WBSタスク消化率
所要工数 ：21人月（リーダ:0.25/月、他メンバ:1.00/月）
承: 事例として現状の予実を示す
目標WBSタスク消化率 40%[20/50]（12/21時点）
実績WBSタスク消化数 30%[15/50]（12/21時点）
要件定義の長期化（各部署要望の調整に時間を要した）に伴い、その後の工程が遅れている。
※これまでの経緯はWBSに詳細を示す
転: 改善すべき事項として以下を認識
- 要件定義の際、部署間調整は社員である私が担務。ここがボトルネックとなった。
- 要件定義後はパートナー主体にて作業を進めているが、実現すべき機能が想定よりも多くなったことから要件定義の遅れが解消できなかった。
- 2月からの本格展開を予定しており、遅れの解消は必須。工数追加は予算上厳しく、対策を検討した。
改善に向けて社内有識者と検討したところ、同じ部署にて以前から運用していた別システムの一部機能を流用できることが判明した。
それを踏まえ以下の施策を進めていく。
施策1：既存の社内システムの基盤部分を可能な限り流用し開発規模を最小化する
施策2：品質確認（レビュー）は、既存の社内システム開発メンバ（現運用メンバ）にヘルプ依頼
施策3：テスト資材は、既存の社内システム開発時に利用したものを流用する
結: 結論を導き予想効果を定量化
以下の通り、施策1～施策3により、遅れタスクの解消は1月中旬までに可能な見込み。
施策1：画面開発工数が30%削減可能
施策2：レビューの平行実施が出来る為、レビューアがネックになるリスクを回避可能
施策3：テスト資材 設計期間を30%削減可能
依頼事項：
既存の社内システムチームのヘルプについては、事前に担当ベースで承諾を得ているが、管理職を通じて正式に承諾を得て頂けると助かります。
原則は起承転結で、もしページ数が多くなる場合には『起・承 の中にも起承転結をいれ』たり、『添付や参考資料へ移動』したりして流れを遮らないようにする。
また、起承転結でまとめたが「結論から書く」のが報告書の書き方の鉄則なので、資料上は結＋起承転結とする。冒頭の結は一枚にまとめよう。
３．今後の進め方（全体像、スケジュール、WBS）を簡潔に資料として挿入する
項目２で報告の内容は出来上がった。
あとは補足資料を追加する。全体像、スケジュール、WBSなど図示するものを入れ、より伝わりやすい資料をつくろう。文章だけでなく図解すると、瞬間的に見ただけで理解でき、効果的だ。
いかがだっただろうか。
資料作成はやったことがないと尻込みしがちだが、誰だってはじめから出来るわけではない。立場があがるにつれ、書かなければならないことも増える。
資料を作る機会があればぜひ積極的にトライしていってほしい。