「●●の資料を作って」と言われたら、いきなりパワポ、エクセルを起動していませんか。最近経験の浅いメンバーの作業を見る機会があり、なんか混乱しているなぁと思うことが多かったので、少しまとめてみます。
作業に取り掛かる前にまずは考える
仕事の早い人を見ていると、実際にパワポを開く、コードを書きだすまでの時間が長いです。それまでに何をしているかというと、図を書いたり、何か調べたり、作業の前準備をしている時間が長いです。そのうえで、いざコードを書きだすとガーッと数時間で終わっていました。
資料大枠を考えよう
4W1Hで考えます。（Whichは考えても出ませんでした。。）
- Why: なんのための資料か
- 資料はどう利用されるのか？
- その資料をベースに次のStepは何があるのでしょうか。それを踏まえて、今の資料ではどこまでの詳細度に落とすべきですか。
- What: 何を決めたいのか
- 資料で決めたい、話したい内容はなんですか？
- 確認ポイントはまずは一覧化しましょう。
- How: どうやって作るか ＝ 何をInputにするべきなのか？
- 一般的な情報でしょうか？その場合何か業界のベストプラクティス的な使える情報はありますか？
- 考慮すべきお客さんの社内ルールとか、過去のプロジェクトの情報とかはありますか？
- Who: 誰が読み手なのか
- 誰にこの資料を見せるべきでしょうか？
- お客さんはあなたが作った資料をどうレビューするのか？いきなり詳細データの一覧を見せてもお客さんは面食らうでしょう。
- 前提として、例えばAzureのアーキテクチャの資料なのであれば、お客さんはAzureを知っているのか？もしかしたらAzureの基礎的な部分も説明した方がよいのでは？ZoneやRegionと言ってお客さんに通じるのか？
- When: いつまでに作るべきか？
- それにより、求められる資料の完成レベルが異なります。明日までにであれば、まずは議論のたたき台となるものを早めに提供すべきでしょう。（どんな複雑な資料でも、1日くらいで中間成果物を誰かに見せてもいいと思いますが。まずは図とかは後回しにして、文字だけでもいいでしょう。）
- それにより、求められる資料の完成レベルが異なります。明日までにであれば、まずは議論のたたき台となるものを早めに提供すべきでしょう。（どんな複雑な資料でも、1日くらいで中間成果物を誰かに見せてもいいと思いますが。まずは図とかは後回しにして、文字だけでもいいでしょう。）
これらのことはOneNoteとかに自分用にまとめるのがおすすめです。
または、今作る資料をもとに、今後さらなる作業が予定されている場合、お客さん向けに今後の作業流れをまとめたスライドを1枚頭に載せてもいいでしょう。
フレームワークで考える
適当にブラウジングして得た情報で作成した資料だと網羅感に不安が残ります。
既存のフレームワークやベストプラクティスを積極的に利用しましょう。フレームワークでMECEに考えることでぐっと説得力が増すし、お客さんもレビューしやすくなります。第一自分も考えるのが楽です。
等など
基礎知識を身に着ける
ちゃんと基礎知識を身に着けて資料を作りましょう。いろんな個人Webサイトを読んでみてもツギハギ感がぬぐえません。ただ、いきなり長大な公式ドキュメントを読むのはつらいということもあると思います。
そんな場合、Microsoft技術であれば、以下のページのTraining Catalogからクイックに特定領域について学ぶことができます。以下はTrainingを脅威モデリングについてLearning Pathで絞った例。
個人的にですが、Microsoftのドキュメントは複雑で読む気をなくしますが、Trainingの資料はかなりわかりやすく概念から説明してくれている印象です。いたずらにいろんなページに飛びまくらないのが良い。