Skip to content
Published on

書いて考える — 書くことで思考は明晰になる

🇰🇷KO🇺🇸EN🇯🇵JA
Split View필사 모드
Authors

はじめに — 書くことは思考の結果ではなく、道具です

多くの人は書くことをこう理解しています。頭の中で考えが整理し終わったあと、その完成した考えを紙に書き写す作業だ、と。この順序なら、書くことは単なる書き取りに近いものになります。考えが先で、文章はその影だというわけです。

ところが、何かを真剣に書いたことがある人は知っています。その順序が逆である場合のほうがずっと多い、ということを。書く前は完全に理解していると感じていた主題が、いざ文章にしようとした瞬間に崩れ落ちます。「私はこの問題を理解している」という感覚と、「私はこの問題を一文で説明できる」という能力のあいだには、思った以上に大きな隔たりがあります。

この文章は、その隔たりについての話です。書くことを表現の技術としてではなく思考の道具として扱う方法、そしてそれを日常のルーティンに組み込む具体的な方法を扱います。自己啓発書のような誇張(「書くことが人生を変える」)はできるだけ取り除き、実際に机の前で何をどうすればよいのかに焦点を当てます。

「書き出せないなら、それを十分に理解していないということだ。書くことは、自分の思考がどれほど雑かを明らかにする。」 — ポール・グレアム、エッセイ「Putting Ideas into Words」の趣旨

1. なぜ書くと思考が明晰になるのか

頭の中の考えは、思っているより曖昧です

頭の中では、考えは速く滑らかに流れていきます。けれど、その滑らかさはしばしば錯覚です。私たちは概念を正確につないでいるのではなく、ざっくりまとめたまま「理解した」という感覚だけを抱えて先へ進みます。認知科学ではこれを「説明深度の錯覚(illusion of explanatory depth)」と呼びます。ファスナーやトイレのような毎日使う物でさえ、仕組みを詳しく書き出してみてと言われると、たいていは行き詰まります。

書くことは、この錯覚を破る仕掛けです。文章は線形です。Aの次にB、Bの次にCを置かなければなりません。頭の中で同時に漂っていた概念を、無理やり一列に並べる瞬間、抜けていたつなぎ目が見えてきます。「だからAはBへつながる」と書こうとして、その「だから」が説明できなければ、そこに穴があるのです。

書くことは外部メモリであり、デバッガでもあります

ワーキングメモリは狭いものです。一度に扱える項目はわずかしかありません。複雑な問題を頭の中だけで転がすと、片方をつかんだ瞬間に別の片方を取りこぼします。書くことは、このワーキングメモリを紙の上へ拡張します。いったん書いておけば、その項目はもう頭で抱える必要がなくなり、空いた資源で次の段階を考えられます。

また、書くことはデバッガのように働きます。コードを一行ずつ実行してどこで狂ったかを見るように、考えを一文ずつ書きながら、どこで論理がずれるかを見ます。「書いているうちに自分が間違っていたと気づいた」というよくある経験は、書くことが思考の誤り検出器である証拠です。

明晰な文章と曖昧な文章 — 同じ内容、違う思考

同じ主題を二通りに書いてみます。

曖昧な版:

うちのサービスが遅くなった気がする。トラフィックも増えた気がするし、DBも少し問題がある気がするので、キャッシュみたいなものを少しやってみれば、ましになるんじゃないかと思う。

明晰な版:

先週、応答時間のp95が800msから2.1秒に増えた。同じ期間にリクエスト量は1.4倍に増え、遅くなったリクエストの92%が商品詳細APIに集中している。このAPIはリクエストごとに商品・在庫・レビューの3つのテーブルを結合する。在庫とレビューは30秒キャッシュしても問題ないため、まずこの2つをキャッシュして結合を減らす案を提案する。

二つの文章の違いは文章力ではありません。思考の解像度です。曖昧な版を書いた人は、まだ問題を分かっていません。明晰な版を書くには、数字を確認し、原因を絞り、解決策を特定しなければなりません。つまり、明晰に書こうとする試みそのものが、思考を明晰にするのです。

2. ファインマン・テクニック — 教えるように書く

物理学者リチャード・ファインマンは、ある概念を本当に理解したか確かめる方法として、それを初めて学ぶ人に説明してみることを挙げました。よく「ファインマン・テクニック」と呼ばれるこの方法を書くことに移すと、こうなります。

  1. 説明する概念を一つ選ぶ。
  2. 専門用語を使わず、何も知らない人に教えるように文章で書き下す。
  3. 詰まる地点、つまり「これはそういうものだ」とごまかしてしまう地点に印をつける。
  4. その地点こそ、あなたが分かっていない部分です。資料に戻って埋め直す。
  5. 説明が滑らかになるまで繰り返す。

肝心なのは3番です。専門用語はしばしば「分かっていないこと」を覆う仮面です。「これは非同期で処理されます」と書けばもっともらしいですが、「リクエストを送ったあと答えを待たずに次の作業をして、答えが来たらそのとき処理します」と噛み砕こうとした瞬間、本当に分かっているかどうかが表れます。

ファインマン式の書き方チェックリスト

  • 中学生でも分かる言葉で書きましたか?
  • 「なぜ?」ともう一度問われて答えられますか?
  • たとえを一つ挙げられますか?(たとえが浮かばないなら、まだ理解できていないかもしれません)
  • 説明の途中でそっと飛ばした部分はありますか? その箇所を別に書き留めましたか?
  • 書き終えた文章を読み返して、「で、結局なに?」に答えられますか?

3. 道具別の書き方 — どこに何を書くか

思考のための書くことは、一つの形式ではありません。目的によって、ふさわしい器が違います。

比較表 — 思考のための書き方の形式

形式主な目的長さ読み手書く時点
デイリーメモその日の考えを出す短い自分自身毎日
設計ドキュメント着手前に設計を整理長いチーム仕事を始める前
意思決定の記録なぜそう決めたか保存中くらい未来の私たち決定の直後
振り返り何を学んだか抽出中くらい自分とチーム仕事が終わったあと
公開記事学びを共有し検証長い不特定多数整理がついたあと

表が言いたい肝は、書くことを一種類の重い行為と見ないでほしい、ということです。毎日の短いメモと、四半期ごとの長い振り返りは、どちらも思考のための書くことですが、負担の大きさはまったく違います。

設計ドキュメント — 作る前に書く

コードを書く前に設計ドキュメントを書く習慣は、思考のための書くことの最も実用的な事例です。肝心なのは「実装」ではなく、「なぜ」と「何を」を先に書くことです。

[設計ドキュメントの骨格]

1. 問題 (Problem)
   - いま何が不便で、誰が影響を受けるのか?
   - この文書が解くことと、解かないこと(Non-goals)

2. 背景 (Context)
   - 現在どう動いているか?
   - 関連する制約(時間、資源、既存システム)

3. 提案 (Proposal)
   - どう解くか? 核となる設計
   - データの流れ / インターフェース

4. 代替案 (Alternatives)
   - 検討したが選ばなかった案と、その理由

5. リスク (Risks)
   - 何がうまくいかない可能性があるか? どう備えるか?

6. 未解決の問い (Open questions)

この骨格を埋めていくと、キーボードを一文字も叩く前に設計の穴が見えてきます。「代替案」の項目を埋めている途中で、より良い方法を見つけることもよくあります。設計ドキュメントの価値は文書そのものではなく、それを書いているあいだに強いられる思考にあります。

意思決定の記録(ADR) — 未来の自分のために

決定を下した直後に、短くでも「なぜこう決めたか」を書いておけば、半年後に「いったいなぜこうしたのか?」という問いに答えられます。意思決定の記録は、たいていこれくらい短いものです。

タイトル: セッションの保存先にRedisを選択
ステータス: 採用
背景: 複数サーバー環境でセッション共有が必要。候補はDB、Redis、Cookieベース。
決定: Redisを使用。
理由: DBは照会負荷が大きく、Cookieベースはサイズ制限とセキュリティ上の懸念がある。
結果: 運用するキャッシュサーバーが一つ増える。障害時のセッション消失に備える必要あり。

4. 毎日書く — 負担なく続けるルーティン

小さく、けれど毎日

思考のための書くことで最もよくある失敗は、「大げさに始めて三日で辞める」ことです。解決策は単純です。基準を笑ってしまうほど低くすること。一日三文で十分です。

  • 今日いちばん長く取り組んだ問題は何だったか?
  • その問題について、いま自分が分かっていることと分かっていないことは?
  • 明日の自分に一文だけ残すなら?

この三行は5分あればできます。大事なのは完成度ではなく、「考えを頭の外に出す動作」を毎日繰り返すことです。筋肉と同じで、書くことは頻度が強度に勝ります。

モーニングページ vs 夜の振り返り

比較項目朝に書く夜に書く
目的一日を設計し、頭を空にする一日を整理し、学びを抽出する
雰囲気発散的、自由収束的、評価的
良い点優先順位がはっきりするその日の教訓が残る
注意点ともすると空想に流れる疲れていると飛ばしやすい

正解はありません。自分のリズムに合うほうを選んでまず習慣にし、必要なら、もう一方を加えればよいのです。

続けるのを助ける小さな仕掛け

  • 同じ場所、同じ時間に書く。決める手間をなくす。
  • 空白の画面ではなく、問いが書かれたテンプレートから始める。
  • 表記や文章は気にしない。初稿はもともと雑なものです。
  • 「今日は一行だけ」という最低基準を置く。調子が悪い日のための安全網です。
  • 何日か抜けても自分を責めない。途切れた日ではなく、再開した日を数える。

5. 公開して書く — 学びながら分かち合う

なぜわざわざ公開するのか

書いた文章を引き出しにしまわず公開すると、思考に新たな圧力が加わります。「誰かがこれを読んで反論できる」という可能性は、適当に流していた部分を見直させます。これがよく言う「公開しながら学ぶ(learning in public)」です。

公開して書くことの効用は誇張しやすいものです。だから正直に書きます。ほとんどの文章はほとんど読まれません。コメントで人生が変わることもまれです。それでも公開に価値があるのは、読者の反応のためではなく、公開を前提に書くと思考がより厳密になるからです。読者は一人、未来のあなたかもしれません。

公開して書くことの現実的な長所と短所

側面良い点引き受けること
思考厳密になり、穴を埋めるようになる時間が余計にかかる
反応たまに貴重な訂正やご縁おおむね反応は少ない
記録検索できる外部の脳間違った文章が残る恥ずかしさ
評判続ければ信頼が積もる短期の成果はほぼない

間違えるのが怖いとき

公開を阻む最大の壁は「間違えたらどうしよう」という恐れです。二つを覚えておくと助けになります。第一に、間違った文章を公開すると、親切な誰かが直してくれることがあります。黙っていれば、永遠に間違ったまま残ります。第二に、「いまの私の理解です」と正直に断って書けば、それは嘘ではなく正直な記録になります。文章の最後に「より良い方法をご存じなら教えてください」と添えるだけで、負担は大きく減ります。

6. 編集の力 — 初稿は思考の材料にすぎない

書くことと直すことを分ける

初心者ほど、最初の一文を完璧に書こうとして一行も進めません。書くことと直すことは別の作業です。書くことは発散、直すことは収束です。二つを同時にやると、両方とも台無しになります。

おすすめの順序はこうです。まず判断を切って頭の中をぶちまけます(初稿)。それから批評家の帽子をかぶって削ります(編集)。ヘミングウェイの言葉としてよく引かれるように、すべての初稿はひどくてかまいません。初稿の役目は良い文章であることではなく、直すための材料をつくることです。

編集は二度目の思考です

編集は単なる手直しではありません。文を削り、順序を入れ替えるあいだに、思考の構造が見え直してきます。「この段落は本当に必要か?」という問いは、すなわち「この論点は本当に必要か?」という問いです。良い編集は文章を短くするだけでなく、思考をもう一度こします。

編集の前後の例

編集前:

実はこの部分についていろいろと考えてみたのですが、基本的に今やっているやり方がそこまで悪いというわけではないものの、それでも多少の改善の余地は確かにあると思うので、一度整理してみようと思います。

編集後:

いまのやり方も悪くありませんが、改善の余地があるので整理してみました。

余計なものを取り除くと、メッセージがはっきりします。「実は」「基本的に」「多少の」「そこまで」といった表現は、たいてい自信のなさの痕跡です。

自己編集チェックリスト

  • 最初の一文は核心を述べていますか、それとも言い訳から始まっていますか?
  • 一つの段落は一つの考えだけを盛っていますか?
  • 消しても意味が通る語を消しましたか?(「実は」「本当に」「多少」など)
  • 受動態を能動態に変えられますか?
  • 一文が二行を超えたら、切れますか?
  • 最後の段落を最初に移したほうが良いですか?(結論が埋もれていませんか)

7. 構造化 — 思考に骨組みを立てる

まず骨、それから肉

長い文章ほど、最初から文を書くと道に迷います。まず項目だけを並べて骨組みを立て、その骨組みを見ながら順序を入れ替え、最後に肉をつけます。書くことの難しさの大半は、実は「何をどの順で言うか」という構造の問題です。文がうまく出てこないなら、十中八九、まだ構造が固まっていません。

文章の流れを図で見る

   頭の中の考え(曖昧、非線形)
            |
            v
   [出し切る] 初稿 ── 判断オフ、発散
            |
            v
   [構造化] 骨組みを立てる ── 項目を並べる → 順序を決める
            |
            v
   [編集] 肉をつけ、削る ── 判断オン、収束
            |
            v
   [公開/保管] 検証と記録
            |
            v
   より明晰な考え(鮮明、線形)
            |
            +────────────┐
                         | (次の主題へ循環)
                         v
                  新しい問いを発見

この流れの肝は、一方向ではなく循環であることです。明晰になった考えは、ほとんど常に新しい問いを生み、その問いが次の文章の出発点になります。

一つの段落の構造

良い段落には、たいていこんな骨組みがあります。主張の一文で始め、根拠や例で支え、一文でまとめます。この単純な型を守るだけで、文章ははっきりします。すべての段落を「で、この段落の一行要約は?」と自問しながら点検してみてください。

8. AI時代の書くこと — いっそう重要になった能力

AIが代わりに書いてくれるのに、なぜ自分で書くのか

生成AIは、もっともらしい文章を一瞬でつくり出します。それなら書く力は時代遅れの技術でしょうか。私はむしろ逆だと考えます。理由はこの文章の冒頭にあります。書くことの本当の価値は成果物ではなく、書いているあいだに起きる思考にあります。AIに書かせれば成果物は得られますが、その思考の過程は飛ばすことになります。

たとえるなら電卓と同じです。電卓があっても数の感覚はやはり重要です。答えがとんでもないときに気づくには、自分で見積もる力が必要だからです。AIが書いた文章がもっともらしいのに間違っているとき、それに気づく力は、自分で書いてきた人から生まれます。

AI時代にいっそう重要になった書く力

能力なぜいっそう重要になったか
問いを正確に書く曖昧な依頼は曖昧な結果を招く
結果を批判的に読むもっともらしい誤りをふるい分ける必要がある
構造を設計する大きな絵はやはり人の仕事
自分の考えを持つAIは平均を語る。観点はあなたが加える

AIを思考のパートナーとして使う

AIを書くことから締め出す必要はありません。ただし順序が大事です。まず自分で下書きと骨格をつくったあと、AIを編集者や反論者として使います。「この主張の弱点は?」「私が見落とした反例は?」「この段落をもっと短くするなら?」といった問いは、AIがうまく助けてくれます。逆に、空白の画面をまるごとAIに任せると、成果物は平均的になり、あなたの思考は育ちません。AIは思考を肩代わりする道具としてではなく、思考を映す鏡として使うとき、最も役に立ちます。

9. 事例 — 書くことが仕事を変えた瞬間

事例1. 行き詰まったバグが一枚のメモで解けた

原因が見つからず半日さまよったバグがありました。同僚に助けを求めようと、状況を文章で整理し始めました。「この関数はこういう入力を受け取って、こう処理して、だから……」。その「だから」を書いた瞬間、処理の順序が自分の前提と違うと気づきました。同僚に送る前に問題が解けたのです。これがよく言う「ラバーダック・デバッグ」です。説明しようとする行為そのものが、答えを引き出します。

事例2. 会議の代わりにドキュメント

毎回同じ議論を繰り返していたチームが、決定の前に一枚の提案書を先に書くことにしました。会議はその文書を読んでから始めます。驚いたことに、会議の時間が減りました。書いているあいだに論点が整理されるので、口で堂々巡りする時間が消えたからです。書くことは話すより遅いですが、その遅さが思考を強います。

事例3. 公開した記事が呼んだ訂正

ある概念を整理してブログに上げました。数日後、ある読者がコメントで、微妙だけれど重要な誤解を指摘してくれました。一人でノートにだけ書いていたら、永遠に間違ったまま残っていた部分です。公開の価値は拍手ではなく、こうした訂正にあります。

10. 今日から始める7日間ルーティン

大げさな計画はたいてい失敗します。だから、小さく提案します。

  • 1日目: 今日いちばん長く悩んだことを三文で書く。
  • 2日目: 昨日の文章でいちばん曖昧な一文を選んで書き直す。
  • 3日目: 最近扱っている概念を一つ、ファインマン式に、用語なしで説明する。
  • 4日目: もうすぐ着手する作業の設計ドキュメントの骨格(問題/提案/代替案)を書く。
  • 5日目: 過去の文章を一つ編集する。余計な語だけを消す。
  • 6日目: 短い文章を一つ公開する。「いまの私の理解です」で始める。
  • 7日目: 一週間を振り返り、何が明晰になったかを一段落書く。

7日後に人生は変わりません。ただ一つだけは、はっきりするはずです。書く前と書いた後で、考えが違うという事実。その違いを一度実感すると、書くことを辞めるほうがかえって難しくなります。

11. 行き詰まったとき — 白い画面に勝つ方法

行き詰まりは怠けではありません

文章が書けないとき、私たちはつい自分を意志薄弱だと責めます。しかし、ほとんどの行き詰まりは意志の問題ではなく、情報や構造の問題です。書く中身がまだ十分に集まっていないか、集まっていても順序が定まっていない状態です。行き詰まりを合図として読めば、自責の代わりに次の行動が見えてきます。

行き詰まりの種類と処方

症状本当の原因処方
最初の一文が出ない完璧に始めようとしている何でもいいから書いて後で消す
途中で道に迷う構造がない書くのをやめて骨組みを組み直す
書く中身がない入力が足りない資料に戻って読み直し、メモする
すべてが駄目に感じる書くことと直すことを同時にしている判断を切って最後まで吐き出す
始めること自体が怖い分量への負担タイマーで十分だけと約束する

行き詰まりを解く具体的な動き

  • いちばん易しい部分から書きます。文章は順番どおりに書く必要はありません。結論が明確なら結論から、例が鮮明なら例から書きます。
  • 自分に話しかけるように声で先に説明し、その言葉を書き取ります。口ではすらすら出る説明が、手では詰まることはよくあります。
  • 「私が今書こうとしているのは、一言で言えば___だ」という空欄を埋めます。これが埋まらないなら、まだ書く準備ができていません。
  • 十分のタイマーをかけ、その時間だけは止まらずに手を動かします。めちゃくちゃでも構いません。目標は良い文章ではなく、勢いをつくることです。

「書くことについての最大の嘘は、ひらめきが来てから書けるというものです。本当は逆で、書き始めるからこそひらめきが来るのです。」

12. 協働と書くこと — 共に働く人のための思考

非同期時代の書くこと

リモートワークと分散したチームが増え、話すより書いて働く時間が長くなりました。イシュー、プルリクエストの説明、チャット、ドキュメント。これらは単なる報告ではなく、読む人の頭の中に同じ絵を描く仕事です。よく書かれた一通は会議を一度なくし、まずく書かれた一通は会議を三度呼びます。

プルリクエストの説明 — 何を書くか

コード変更を説明する文章は、協働の書くことの小さな手本です。良い説明は「何を変えた」ではなく「なぜ変え、どう検証したか」を含みます。

[良い変更説明の骨組み]

背景: どんな問題のためにこの変更が必要か?
変更: 何をどう変えたか?(大きな絵を先に)
検証: どう動作を確認したか?
影響: 何が一緒に変わるか? 注意点は?
代替: 別の方法はなかったか? なぜこれを選んだか?

読む人はコードだけでは意図を知るのが難しいものです。「なぜ」が抜けた変更説明は、レビュアーに推理を強います。一段落か二段落の文脈が、レビュー時間を半分に減らします。

レビューとフィードバックも書くことです

他人の文章やコードに残すフィードバックも、思考のための書くことです。「これ、変ですね」は感情で、「この場合、入力が空ならどうなりますか?」は思考です。良いフィードバックは結論ではなく、質問の形をとることが多いものです。質問は相手の思考を閉じず、開くからです。

協働の書くこと チェックリスト

  • 読む人が誰かを一人思い浮かべて書きましたか?
  • 結論や核心の依頼を先頭に置きましたか?
  • 背景を知らない人もついてこられますか?
  • 相手に何をしてほしいかが明確ですか?
  • 非難ではなく、質問と事実で書きましたか?

13. よくある誤解 — 書くことについての嘘

思考のための書くことを阻むのは、しばしば誤った思い込みです。よく耳にする誤解を挙げておきます。

よくある誤解現実
才能のある人だけがうまく書けるうまく書く人は、たいてい多く直す人だ
ひらめきが来てから書ける書くからひらめく、順序が逆だ
一度でうまく書かねばならない初稿は粗いのが当たり前だ
長く書くほど良い文章だ短く削るほうが大きな思考を要する
公開すれば恥をかくだけだたいてい無反応で、たまに貴重な訂正が来る

この表が言いたいことは一つです。書くことの難しさのほとんどは能力の問題ではなく、書くことをどんな仕事とみなすかの問題だということです。結果ではなく過程として、才能ではなく反復として見た瞬間、始めるための敷居は大きく下がります。

道具は脇役にすぎません

最後に、道具について短く付け加えます。どのメモアプリ、どのエディタを使うかは、思うほど重要ではありません。むしろ、完璧な道具を選ぼうとして肝心の書くことを先延ばしにする人のほうが多いものです。テキストファイル一つ、紙一枚で十分です。大切なのは、手になじんだ道具を一つ決めておき、摩擦なくすぐに書き始められるようにすることです。道具を変えることに使うエネルギーは、一文でも多く書くことに使うほうが、ほとんどの場合まさっています。

おわりに — 明晰さは才能ではなく習慣です

明晰に考える人は、生まれつきそうなのではありません。たいていは、明晰になるまで書いて直す人です。頭の中の曖昧さを恥じる必要はありません。誰の頭の中も、最初は曖昧です。違いは、それを文章へ引き出して磨くかどうかにあります。

今日、三文書いてみてください。うまく書こうとせず、ただ頭の中にあったものを外へ出してみてください。そこから思考は、ようやく手で触れられるものになります。

参考資料

Discuss on Twitter • View on GitHub