---
title: "文章もリファクタリングできる"
author: "Shawn Jiang"
lang: ja
date: 2026-11-02
canonical: https://tplog.dev/ja/essay/writing-can-be-refactored-too/
translations:
  en: https://tplog.dev/en/essay/writing-can-be-refactored-too/
  zh: https://tplog.dev/zh/essay/writing-can-be-refactored-too/
---

# 文章もリファクタリングできる

Tison は[「Agentic Coding の境界」](https://x.com/tison1096/status/2045492574945976478)の中で、重複コードを扱うときの習慣に触れている。最初にロジックを書くときは、流れのまま素直に書く。二度目に似た処理に出会ったら、ひとまずコピー＆ペーストする。三度目になってから、共通コードを切り出すかどうかを考える。

そうするのは、まず見極めたいことがあるからだ。二つのコードは本当に同じ意味を表しているのか、それともたまたま形が似ているだけなのか。この点は、手を動かし始めたばかりの段階ではなかなか分からない。見た目が似ているからといって急いで一つにまとめると、あとで要件が変わったときに、関数へたくさんの引数や条件分岐を足し、二つの経路をまた切り分けることになる。

文章を書くことにも、同じ問題があると思う。早すぎる段階で固めたアウトラインは、早まって切り出した共通コードのようなものだ。

何か思いついたばかりの段階では、自分が何を言いたいのか、まだ自分でも分かっているとは限らない。頭の中ではきれいにまとまっているようでも、いざ書き出してみると、途中の論理が一歩抜けていたり、ある一文がどうしても説明しきれなかったりすることに気づく。その一歩を補うために、別の例を探したり、もともと混ざっていた二つのケースを分けたりすることになる。書き進めるうちに、最初の判断そのものが変わってしまうこともある。

こうした変化を、あらかじめアウトラインに織り込んでおくのは難しい。最初から構成を細かく決めすぎると、あとは見出しの下に無理やり中身を埋めていくだけになるし、書いている途中でより面白い考えが浮かんでも、脱線になるのではないかとためらってしまう。だが、まだ手探りで書いている文章にとっては、その「脱線」に見えるところこそ、いちばん書き進める価値があるのかもしれない。そこで元のアウトラインを無理に守ろうとすれば、既存の抽象に合わせるために関数へ引数を無理やり押し込むのと同じで、直せば直すほど文章はぎこちなくなる。

だから私は、まず流れに沿ってそのまま書くようにしている。一文でも、一つの例でも、あるいはある言い方へのちょっとした異論でもいいから、まずは書き留めておく。

手元に具体的な段落がいくつか揃って初めて、並べて比べる材料ができる。その段階で読み返せば、どの二つの段落が実は同じことを言っていて、どの二つが表面上似ているだけなのかを見分けられる。どの例なら主張を支えられるか、どの数文が自分の言いたいだけのことで、読者には実は必要ないのかも見えてくる。

そこが見えてからリファクタリングに取りかかると、手を入れるのは言い回しだけではなく、文章の順序にまで及ぶ。自分が順を追って考えを整理した順序が、そのまま他人が読みやすい順序だとは限らない。後の判断を理解してもらうには、読者にどの前提を先に伝えるべきか。どの内容が同じ問いに属していて一つにまとめるべきで、どれを切り離すべきか。ときには、もともと最後に置いていた一文を、かえって冒頭へ移したほうがしっくりくることもある。

いまは AI で文章を組み替えるのが簡単になり、いつでも何通りかの並び順を出させて比べられる。だがその前に、まだぎこちなくても、確かに自分が考えている言葉をまず残しておきたい。そうした元の言葉が土台としてあってこそ、修正稿を読んだときに、どの修正が言いたいことをはっきりさせる助けになっていて、どの修正がただ標準的な文章らしく整えただけなのかを見分けられる。

もちろん、結論がすでに固まっている説明文なら、先にアウトラインを作るほうがずっと手間が省ける。私が言っているのは、まだ手探りの段階で、ここに何かありそうだとうっすら感じているだけのときだ。そういうときは、まず少し書いてみればいい。具体的な中身がいくつか出てきてから、改めてこの文章をどう語るかを決めればいい。