以前、オンライン会議で共通認識を取るための方法のひとつとして、ポンチ絵 について投稿しました。
図を描くことによるメリットはたくさんあると考えていますが、それだけでは他者には伝わりません。
当然、文章 を書く必要があります。
今回は、他者に伝わりやすい文章を書く方法のひとつとして、文章の構造化 というテーマについて書いてみました。
文章の構造化とは？
"文章の構造化" というキーワードで検索すると色々な手法が出てきます。
私が特に意識しているのは、
特に伝えたい点を考え（トピックの選定）、関連する事柄をまとめて理解しやすいようにトピックを並び替える（アウトラインの設計）こと です。
ここからは、以下の３点のポイントについてまとめてみます。
・フォーマット
・トピックの選定
・アウトラインの設計
１．フォーマット
必須ではないと思いますが、自分なりのフォーマットやルールを決めておいた方が、品質は安定する気がしています。
私は以下のようなフォーマットで書いています。
* トピック
- 文章
- 文章
- 文章（サブ）
- 文章
* トピック
- 文章
- 文章
２．トピックの選定
意識しているのは、似たトピックは1つにまとめる という点です。
そこで大事になるのは、トピックの抽象度 だと考えています。
少し極端ですが、例を上げてみます。テーマは「オンプレからクラウド環境への移行失敗例」とします。
* イニシャルコストの増加
- データ移行にかかる費用の見積もりが甘かった
* ランニングコスト（サーバコスト）の増加
- 適切なアーキテクチャを設計できずオーバスペックとなった
* ランニングコスト（運用人員増強による人件費）の増加
- クラウド環境の経験が乏しく運用人員増加が必要になり人件費が高くなった
* セキュリティ対策への負荷の増加
- オンプレ環境では特に意識しておらず考慮する点が増えた
* 計画メンテナンスへの考慮漏れ
- クラウド事業者によるメンテナンスの考慮が必要になった
* 環境が乱立しサーバ管理ができなくなる
- 簡単にサーバが追加できるようになり、環境が乱立して一元管理が難しくなった
* コストの増加
- イニシャルコスト
- データ移行にかかる費用の見積もりが甘い
- ランニングコスト
- サーバコスト：適切なアーキテクチャを設計できずオーバスペックになったため
- 人件費：クラウド環境の経験が乏しく運用人員増加が必要になったため
* 運用負荷の増加
- セキュリティ対策
- オンプレ環境では特に意識しておらず考慮する点が増えた
- 計画メンテナンスへの対応
- クラウド事業者によるメンテナンスの考慮が必要になった
- サーバの一元管理
- 簡単にサーバが追加できるようになり、環境が乱立して一元管理が難しくなった
いかがでしょうか？
一見すると、そこまで違いがない（もしくは修正前の方が見やすい）ように見えるかもしれません。
しかし、修正前の書き方で書き進めると、トピックがどんどん増えて、結果まとまりの無い形になってしまいます。
これを防ぐために、トピックは内容が分かりつつも具体的にしすぎない程度のもの にした方が良いと考えています。
（ただし、会議や会話のメモを取る場合、話がどんどん展開していくため、この方法は難しいかと思います。
そういった場合、いきなり綺麗にまとめようとせずに、後でまとめる形が良いかと思います）。
３．アウトラインの設計
アウトライトと書くとやや大げさですが、トピックの順番 も意識したいです。
単純に、関連があるトピックは続けて書く ほうが理解しやすいと思います。
例えとして、会議の議事録を取る場合を例にあげます。
この時、発言の順番を重要視するのではなく、後で理解しやすいように関連するトピックで順番を並べ替えます。
もちろん、誰がいつどんな流れで発言したかを残しておく必要がある場合は別ですが、そうでない場合、発言の順番には余りこだわらないようにしています。
まとめ
ここまで書いてきましたが、他者に伝わりやすい文章を書くのは本当に難しいなと日々感じています。
変に文章をまとめることで、大事な要素が抜けたり、自分のバイアスにより内容が違ったものになってはいけないので、そこには細心の注意を払っています。
リモートワークにより以前にも増してドキュメントの重要性が高まっていると思います。
今回の記事が少しでもヒントになれば幸いです。
P.S. DMM.comプラットフォーム事業本部のその他の記事もぜひ見ていってください！