はじめに
社内でのやり取りで、こんな経験ありませんか？
- 一生懸命まとめたのに「結局よくわからない」と言われる
- 自分では整理できているつもりなのに、読み手から「で、どうすればいいの？」と返ってくる
- 気づいたら説明が長くなりすぎて、要点がぼやけてしまう
自分ははこれが何回かありました。
障害報告や方針の共有を書くとき、「ちゃんと考えて書いたはずなのに伝わらない…」と落ち込むことがよくありました。
昔から文章を書くことは苦手だったのでなんかちゃんと書くスキルを身につけないとなと思ってたときに 『入門 考える技術・書く技術』 を読んでみました。
最初は「文章術の本かな？」くらいに思っていたのですが、読んでみるとむしろ「考え方の整理術」に近くて、結果的に、社内連絡だけでなく他のドキュメントや連絡文作成にまで効いてきた一冊でした。
「考える」と「書く」はセット
この本で一番刺さったのは、**「考えることと書くことは別物じゃない」**という視点です。
私はずっと「頭で考えを整理してから書く」ものだと思っていました。
でも本書では逆で、「書きながら考える」ことこそ大事だと強調しています。
実際にやってみると、「自分ではわかってるつもり」だったことが文章にすると途端に曖昧になる。
でも、それを直す過程で思考も整理されていく。
なるほど、伝わる文章を書くってつまり「自分の考えを整える作業」なんだなと気づかされました。
実務でどう役立ったか
1. 読み手の「問い」に答える
以前は「自分が伝えたいこと」から書き始めていたのですが、それだと相手に届かないんですよね。
本書を読んでからは、「相手がどんな問いを持っているか」を意識して書くようになりました。
例えば障害報告なら：
- 「いまの状況はどうなっているのか？」
- 「原因は何なのか？」
- 「次に自分は何をすればいいのか？」
こういう問いに答えるように書くだけで、やり取りの齟齬がかなり減りました。
2. 主張 → 理由 → 根拠
「伝わらない」と言われるときって、たいてい論理の筋道が抜け落ちているんですよね。
そこで役に立ったのが、主張 → 理由 → 根拠の順番で書く、というシンプルな型です。
例：
- 主張：「今回の不具合はすでに修正済みです」
- 理由：「終了日が未設定でも正しく処理されるよう改修したからです」
- 根拠：「実際にテストをして再現しないことを確認しました」
この並びを意識するだけで、「結局どういうこと？」と聞き返されることが減った気がします。
3. 図や例を「補助」にする
これは技術記事にも近いのですが、説明のときに図や例を添えるようにしました。
ただ「雰囲気でつける」んじゃなくて、自分の理解を整理するための補助として使う。
障害範囲を図で描いたり、SQLの比較を書き出したりすると、自分の中でも腑に落ちますし、相手にもすぐ伝わるんですよね。多分。
おわりに
『入門 考える技術・書く技術』は、私にとって 「伝わらない文章」を「伝わる文章」に変えるきっかけになった一冊でした。
特に役立ったのは：
- 相手の問いに答える形で書く
- 主張・理由・根拠の三段構造を意識する
- 図や例を理解の補助として使う
まだまだ文章を書くのは得意ではないですが頑張りましょう。
Discussion