開発者のための技術記事を書く

実装や調査の経験を、別の開発者が自分の問題に適用できる記事へ変換する。文章の見栄えより、読者が得る判断材料と技術的な再現可能性を優先する。対象は技術ブログであり、API リファレンスや作業ログの清書ではない。

手順

Step 1: 材料と公開条件を確定する

依頼文、既存メモ、コード、Issue、実験ログから、実際に行ったこと・観察したこと・まだ推測に留まることを分けて抽出する。体験のないテーマであれば、公開資料だけによる調査記事として扱うか、一次経験の提供を依頼する。体験を捏造しない。
公開先、想定読者、記事の長さ、守秘範囲、公開権限を確認する。情報が足りない場合は暫定条件を明記して草稿まで進み、承認が必要な内容は伏せる。
題材の指定がない場合は、最近のバグ調査、設計判断、移行、実験、繰り返し受けた質問、公開可能な学びをメモ・Issue・チームの議論から複数挙げる。継続的な題材探しを求められた場合は、日々の疑問と予想外の結果を候補メモに追記し、開発者コミュニティや同僚の疑問を観察する。非公開の発言は転載しない。
各候補で「直接経験があるか」「読者が避けたい痛み・得たい成果があるか」「説明できる具体的証拠があるか」「公開できるか」を判定して一つ選ぶ。同点なら対象読者と判断をより狭く定義できる候補を選ぶ。固有の具体物（失敗の経緯、設計上の選択、コード、測定結果、予想外の挙動）がなければ調査・実験・取材の必要事項を列挙し、一般論で埋めない。

Step 2: 記事の約束を一文にする

読者を「使っている技術・直面している問題・前提知識」で限定する。
「この記事を読むと、誰が、何を判断または実行できるか」を一文で書く。執筆者の経歴や使った技術名だけを価値提案にしない。
既存記事を軽く調べ、読者がすでに得られる説明と、この経験で初めて付け加えられる知見を分ける。公開先の既存記事も見て、読者の前提、説明の深さ、掲載できる図表・コード形式を確認する。差分がない場合は切り口を狭める。
題材に合う構成を選ぶ。バグ調査・移行・実装過程・教訓・トレンド・製品の技術的背景・測定のいずれかなら、必要な場合にだけスキル同梱の references/article-patterns.md を読む。型が合わなければ読者の疑問順に独自構成を作る。