# WRITING この場所で、どんなふうに書いていきたいか。記事やページをつくるなかで気づいたことを、忘れないために残しておく。 文章を上手に見せるための規則ではない。迷ったときに、これまでどんな声で書いてきたかを思い出すためのノートである。 ## 書くときに大事にしていること ### 具体的なところから始める 大きなテーマや結論から書き始めるより、実際に見たもの、触れたもの、起きたことから考えていく。声の調子、少し妙な画像、文字を大きくしたときの違和感。そういう小さなことを足場にすると、自分がなぜ気になったのかも見えやすくなる。 抽象的な言葉を使うときも、別の抽象語で説明しない。読む人が同じところから考え始められるように、その感覚が生まれた場面を残す。 ### 自分が感じたこととして書く 自分が見たり、感じたり、考えたりしたこととして書く。「私はそう感じた」と「誰にとってもそうだ」を混ぜない。 まだ分からないことは、無理に答えにしなくてよい。「かもしれない」「気がする」という言葉も、それが考えている途中の正直な調子なら残す。 ### 読む人を急かさない 情報を短く届けることだけを目的にしない。考えが途中で変わったことや、少し立ち止まったところも、必要なら文章のなかに置いておく。 ただし、同じ結論を言い換えて繰り返さない。具体的な出来事のあとに、その意味を何度も説明すると、かえって書き手の声が遠くなることがある。 ### きれいに整えすぎない 賢く見せるための言葉、なくても意味が変わらない修飾、整いすぎた対句や三段の列挙は見直す。口に出したときに、自分ならほんとうにそう言うかを考える。 短い文や、少しの繰り返しは、必ずしも直さない。ためらいや小さなユーモアまで均してしまうと、読みやすくなっても、この場所の文章ではなくなってしまう。 ### 段落には役割を持たせる 同じ場面や考えを続けている文は、ひとつの段落にまとめる。場面が変わる、考えの向きが変わる、問いが立ち上がる。そんなところで段落を変える。 短い一文を独立させることもあるが、すべての文を一段落ずつにはしない。短い文ばかりが続くと、本来残したかった間まで同じ強さになってしまう。 ## 記事ができるまで ### Obsidianで原稿を育てる 最初から完成した文章を書こうとせず、Obsidianで人とAgentが壁打ちをしながら考える。出来事や違和感を持ち寄り、何が気になっているのか、どの順番なら自分の考えに近いかを探す。何を書くか、最後に何を残すかは人が決める。 ### 日本語版を読む 日本語の記事は、Skill `feel-interface-editor`を使って確かめる。まず編集者として、構成、段落、表記、意味の分かりやすさ、これまでの文章とのつながりを見る。次に初めて読む人のつもりで、意味を取り直したところや、急に人の声が薄くなったところを探す。 滑らかにすることだけを優先しない。事実が正しいこと、意味が伝わること、これまでの声が残ることを先に考える。最後は人が所見を読み、直すか、そのまま残すかを決める。 ### 英語版をつくる 英語版は、Skill `create-english-article`を使う。日本語を一語ずつ置き換えるのではなく、同じ記事が英語でもひとつのエッセイとして読めるようにする。 事実、意味、リンク、段落の順序は日本語版から引き継ぐ。主張や例を足さず、タイトル、概要、本文を、穏やかで観察するような英語にする。日本語の曖昧さや小さなユーモアを、英語で強い断定や説明に変えない。 英語版だけを最初から最後まで読んだあと、日本語版と段落数、リンク先を比べる。レビュー済みの原稿を `src/content/english-articles/.md` に置き、英語OGPもそのタイトルからつくる。 ## つくるなかで分かったこと ### 仕組みの説明は、全部を一度に言わない Design Learning Loopを説明した最初の文章では、何を参照し、誰が何をして、何が次へ残るのかを、一度に書こうとしていた。同じ話が導入と手順で繰り返され、かえって仕組みが見えにくくなった。 最初に、なぜ始めたのかが分かると、その後の手順も読みやすい。具体的な操作は手順へ任せ、導入で全部を説明しようとしない。 _Design Learning Loopをつくるなかで。_ ### 短い文章ほど、誰の何の話かを残す Article Notesでは、短く整えようとするうちに「関係」「価値観」「表現」「判断」といった言葉だけが残り、何の話か分かりにくくなった。反対に、記事の細かな出来事まで入れると、今度は要約になってしまった。 本文から気づきを取り出すときは、別の制作にも持ち運べるところまで、一段だけ抽象化する。それでも、その項目だけを読んで、何についての学びで、何がどう変わるのかが分かるようにする。 _Article Notesを調整するなかで。_ ### 説明を、少しだけ言葉の遊びにする 意味が画面から分かるときは、状態を少しだけ言い換えることで、親しみや余韻が生まれることがある。 > 説明：記事に現れる鳥のモチーフ。 > > 言い換え：いまのところ、3羽。 いつも使える型ではない。どのくらい説明し、どのくらい余白を残すかは、その場所で決める。 _Birdwatchingをつくるなかで。_ ### 説明しにくい感覚は、比べながら近づく 「デザインの重心」のような感覚は、最初から定義しようとすると急に固くなる。文字を少し大きくしたとき、小さくしたとき。色や線の強さを変えたとき。何が違って感じられたかを並べると、読む人もその感覚へ近づきやすい。 具体例があると、書き手がどこで引っかかり、どう考えたのかを、読む人も一緒に辿れる。 _記事 #004「デザインの重心」を読むなかで。_ ### 任せた範囲を具体的に書く 006の「Substackへの配信を任せる」という表現は、下書きの作成から最終的な配信判断まで、すべて任せるようにも読めた。そこで、下書き作成を任せ、配信前の確認は自分ですると書き分けた。 AIを使った体験では、何を任せ、どこを自分で確かめたかを残す。画面を操作する機能と、翻訳や画像作成も含むエージェント全体の働きが混ざるときも、読者が取り違えるところだけ説明を補う。 _記事 #006「操作しないインターフェース」の推敲から。_ ### descriptionと本文の距離を見る 006のdescriptionを考えるなかで、本文には不安や面倒さが書かれていても、安心して任せられるときの感覚はまだ行間にあると気づいた。「心地よい」とまとめるより、「ほかのことをしているあいだも気が楽だ」と書くと、何が助けになっているかが伝わった。 descriptionを読んで期待する内容が、本文のどこにあるかを確かめる。足りないときは、実際の体験に沿って本文を補うか、descriptionを本文に合わせて直す。紹介文に合わせるために、経験していない感覚や結論を足さない。 _記事 #006のdescriptionと本文を見直すなかで。_ --- この文書も、記事を書くたびに見直していく。