背景
ゼロベースでドキュメントを書くことに慣れていない人が意外と多いため、記載フローの枠組みを定義する。
この型で何ができるようになるか
ゼロの状態から求められるドキュメントを書けるようになる。 結果、書き手(自分)が意図したとおりに読者を動かすことができる。
この型が具体的にどのような人、場面に役立ちそうか
- ゼロからドキュメントを書いたことがない人
- ゼロからドキュメントを書く方法がわからない人
- ドキュメントを書くと散らかってしまう人
- ドキュメントを書くと手戻りが多く、時間が掛かってしまう人
- 説明や説得の機会に迫られている人
型
準備
「コミュニケーション」の理解
仕事上のコミュニケーション原則を理解する
(TODO URL差し替え)【基礎】コミュニケーションの基本
心がけるポイント
- ドキュメントは思考のアウトプットにすぎない。 ドキュメントが整理できない場合は思考が整理されていない。その場合はドキュメント作成に着手する前に手書きなどでアウトプットの上、思考を整理すること。
- ドキュメントは読み手が疑問を持たない状態を作ることが大事。 そのために、ノイズを減らしたり、先行きが見えない状態を作らないよう心がける。 読み手が疑問を感じた状態になると、内容が伝わらなかったり本筋とは違う指摘が来てしまう。 そのため、書き手が出来るだけ読み手の負荷を減らすことが、スムーズな問題解決に繋がる。 ハイコンテクスト
- いいたいことや伝えたいこと、結論などはできるだけ早い段階に記載できるよう、全体構成を考える。
仕立て検討
決めること | チェックポイント |
対象の読者 | ・読者が気にする点が明確に分かっているか ・そもそも読み手となる関係者や部署が漏れてないか ・読み手がどんな指標を追っているか(どんなことを気にしているか) ・読者の業務をイメージし、伝わるテキストの粒度をイメージできたか |
ドキュメントの目的 | ・この資料で何を伝え相手をどう動かしたいか明確か ・共有か、相談か、議論か ・読み手の読後のアクションはなにを期待するか |
補足
仕立てが明確だと、
- 読みやすい
- 内容に抜け漏れがない
- 品質が上がりやすい
- レビュー依頼時の観点がシャープになるため、よい指摘をたくさんもらえます。
などメリット多いです。
作成の手順
No | 概要 | 詳細 | コツ | レビュー判断 |
1 | ざっくりの流れを決める | 下記構成になっていると人は内容を理解しやすい。 • 過去→今→未来 • 結論→背景、理由→補足 • 概要→詳細 | 左記の分かりやすい構成を意識しつつ、思いついた内容を書き出せばよい。 | |
2 | 大分類でテーマを振る | 知りたいことはできるだけ冒頭に記載する | 大きな分類から、小さな分類へ段々と細かくしていく。 | 10点で軽く壁打ち(こんな感じでいいですか?レベル) |
3 | ざっくり粒度でそれぞれのテーマの中身を書いてみる | H1レベルの章立てを作っていく | No2でイメージした内容を書き出せばよい。 | |
4 | 大分類テーマに含まれる小分類テーマがあれば、大分類テーマの下に追記する | あ、これも書かなきゃがでてくるので大分類テーマに追加する | 言葉の粒の大きさを意識すること。 哺乳類⇔爬虫類 クジラ⇔人間 ザトウクジラ⇔シロナガスクジラ | |
5 | 全体の流れをチェックする | MECEを意識する。 | 人に説明するつもりで、実際に行う予定の説明を口に出して話してみる。 | 30点レビュー |
6 | 各テーマの詳細を書き出す | 違和感がない流れになっているかを確認する | 分類する中でイメージしてきた詳細の内容を一気に書き出す。 | |
7 | 説明をシミュレーションする | 書く中で大分類テーマ、小分類テーマの組替えが必要であれば整理する ここでもMECEを意識し、ダブりがあれば他テーマを参照し、ヌケモレあれば追記する | 整合性や網羅性など、細かい部分を意識しながら、予行練習をする。 質問が来そうな部分がどこかを意識する。 | 70点レビュー |
8 | レビューフィードバックの反映 | 相手に説明することを想定して、100%同じになるよう口に出して説明する | 全体の流れも意識しながら修正を行い、適宜前フェーズの対応を行う。 | |
9 | レビューフィードバックの反映報告、再レビュー | 過不足や指摘点を修正する。 修正内容をフィードバック者に伝え、修正後の確認依頼を行う。 | 変更前後の内容、どのような意図で修正したかを伝えるとよい。 | 90点レビュー |
10 | 最終微調整 | ここでも相手に説明することを想定して、100%同じになるよう口に出して説明する。 | よっぽどの観点漏れがなければ、修正しなくて良い。 (ドキュメントは自己満足に入ると一生終わらないので区切りをつけることが必要) |
チェックリスト
5W1Hが適切に含まれているか
- Who (誰): 文章で言及される人物や関係者についての情報です。これは、話の主体や関連する人々に関する情報を含みます。例えば、ニュース記事では、誰が関与しているのか、誰が影響を受けるのかを明確にします。
- What (何): 事件や話題の具体的な内容です。これは、何が起こったのか、何が問題であるのか、または何が議論されているのかについての情報を提供します。
- Where (どこで): 出来事が発生した場所や、話題が関連する場所です。場所の情報は、話の文脈を理解するのに役立ちます。
- When (いつ): 時間的な文脈です。これは、出来事がいつ起こったのか、または特定の行動や決定がいつ行われたのかについての情報を含みます。
- Why (なぜ): 出来事の原因や理由です。これは、なぜ何かが起こったのか、またはなぜ特定の決定が下されたのかについての理解を深めます。
- How (どのように): 出来事がどのように起こったのか、または特定の結果がどのように達成されたのかについての情報です。これは、プロセスや方法論に関する詳細を提供します。
コツは、一つのテキストに対して「誰が?何を?」といった具合に上記観点で質問してみる。回答がテキストに書かれていれば問題ない。
暗黙の了解を前提にしていないか
- 「あれ」とか「それ」の指示語がないか?
- カタカナ、横文字はこれまでのコミュニケーションで共通認識があるか?今回突然登場していないか?
- 相手に解釈の余地を出来るだけ与えないようにする
- 日常的に使っていない言葉だと分かりやすい単語に置き換えるほうが安全
- 比喩表現(例え話)はないか?
- 直感的な理解である事が多く、深掘りされると実は自身で説明できないケースも多い
ファクトを書く箇所に主観が含まれていないか
- 形容詞が含まれていないか?
- 思います、などの語尾がないか?
- 「〜するべき」「〜のはず」などの表現がないか?
- 「悪い」「良い」「イケてない」「ダサい」「分かりづらい」などの主観的な表現がないか?
言葉の粒度が適切か
- 単語が読者のレベルに適切か?
- (例)ボード会メンバー向けの資料に細かい仕様やツールが書かれていないか
- (例)開発向けの資料に概念的な言葉が書かれていないか
- 読者が接している具体的な業務を想像したか?
- 読者に実際に説明したら、質問が来そうか?(シュミレーションでなんとなく分かる)
- プロジェクト全体の話をする資料に仕様の話が書いてあるとなにこれってなる
ドキュメント内の言葉が定義されているか
- 口頭でのコミュニケーションも含めて、これまで使っていなかった言葉を使っていないか
- 同じ・または似たような言葉で意味の異なる単語を使っていないか(前半の「タスク」と後半の「タスク」の意味が異なる場合)
- 文体が揃っているか(突然敬語になったり、体言止めになったりしていないか)
- 同じ接続詞が続いていないか(〜の〜の〜の、など)
- 難しい言い回しを使っていないか(〜ついては→〜は、〜に対する→〜へ、〜関する→〜の、など)
リストなどの箇条書きを多用していないか
- 整理できそうな情報は表にする
- 表を作るときは重要なことから列または行を組む
- 逆に関係ないことは書かない
- 表が多用されていないか?
- 表ばかりだと読みづらくなる
- リストのインデントが深くなっていないか?
分かりづらい表現がないか
- 複数に掛かる言葉がないか?
- インボイスの対応を行った場合、「インボイス対応について」と記載すると複数の対応箇所があった場合に分からない
- 修飾子と掛かる言葉が近くにあるか?
- 〇〇のため、▲▲に本日から変更されています。→本日から〇〇のため、▲▲に変更されています。
- 詳細を念のため共有します!→念のため詳細を共有します!
- 二重否定がないか?
- 読みながら変換が必要なので、伝達力が落ちる。
- 〇〇できない可能性はないです。→〇〇できる可能性があります。
- 表記ゆれがないか?
- 「良い」と「よい」など。表現が異なると、その背景を気にする人がおり情報伝達のにずになる場合はあるので、できるだけ表記を揃える。
- 出来るだけ対比を意識する
- 暫定対応と恒久対応、など
- 片手落ちが気になる人は多い
- 暫定対応と恒久対応、など
装飾について(Excel、パワポ限定)
Excelなど、修飾はなるべく使わない。
色をたくさん使ったりオブジェクトをたくさん使うケースは、思考が整理されていないことが多い。
※見やすさで着色したりするのは全然OK