どんな人が使い、それを見て何をするのか。これを 1 文で書けるまで作りはじめない。目に見える困りごと（作業を速くしたい）で止めず、その先で何を得て、どう楽になるのかまで書く。

「みんな向け」に作ると、誰にも響かない。幅を持たせるほど一つひとつの機能が平均的になり、わざわざ選ぶ理由がなくなる。尖らせたものは後から広げられるが、平均的に作ったものを後から尖らせることはできない。

作りはじめる前に、完成したときの告知文と、よく聞かれそうな質問への答えを書く。そこに書けた価値だけを作り、書けなかったものは作らない。作る範囲は放っておくといくらでも広がるので、どこまで作るかを先に決めておく。

作りながら決めると、「作れるかどうか」で判断しがちになる。けれど、作れる機能を足すことと、価値を足すことは別の話だ。告知文を書き終えたら競合を見て、選ばれるにはどこまでの品質が要るかを決める。誰も作っていない分野なら、品質は高くなくてよい。

何を優先するか（速さ・簡潔さ・機能の多さ・情報を外に出さないこと）を、「速さと機能がぶつかったら速さを取る」という形で先に書いておく。迷ったときに、そのまま当てはめられる細かさで書く。「品質を大事にする」のような書き方では、ぶつかったときに何も決まらない。

「そのつど良いほうを選ぶ」と、選ぶたびに答えが変わる。要望を全部聞けば、どれも中途半端になり、結局どれも選ばれない。

初めて使う技術や初めての分野では、まず標準的なやり方、実際に動いている例をいくつか、作り手が薦めるやり方を読む。選べる手を増やしてから設計する。調べものを分担させるときも、その分野に詳しい役に加えて、定石を並べるだけの役を必ず 1 つ置く。

「分からない問題」と「知らない手法」は違う。分からない問題は、試行錯誤すれば解ける。知らない手法は、選択肢に入っていなければ何回試しても出てこない。手を動かして埋まるのは前者だけなので、後者は先に調べるしかない。

計画の 1 段目では、目的と制約、それに何が揃えば成功と言えるかを確かめる。作り方の話は、その後にする。

作り方から入ると、目的が「その作り方でできること」まで縮んでしまう。しかも、縮んだことは後から読んでも分からない。制約に合わせて削ったのか、目的がもともとその程度だったのか、書いた本人にも見分けがつかなくなる。

1 案だけを詰めると、その案が良いのか、最初に浮かんだだけなのかが分からない。並べるのは、選ぶためではなく、選んだ理由を残すためだ。比べた記録があれば、後で前提が変わったときに、どの判断を見直せばよいかが分かる。

ただし 2〜3 個で止める。案を増やしても良くなるとは限らず、比べること自体が目的になってしまう。

要件・制約・優先度にあいまいな点があれば、推測で進めずに確かめる。ただし、聞くのは一度に 1 問だけ。選択肢の形にできるなら、選んでもらう。

まとめて聞くと、答える側は全部を頭に入れてから答えることになり、結局いちばん簡単な質問にしか答えが返ってこない。1 問ずつなら、前の答えを踏まえて次の質問を変えられる。まとめて聞くと、手間は答える側に寄る。

計画の最後の段では、削る。いま要らない機能と、いま要らない拡張の余地を落とす。

先回りして作った受け口は、いざ要るときには要件が変わっていて、たいてい合わない。合わないまま残っていると、次に触る人はそれを前提だと思って設計してしまう。使われない受け口は、無いより害が大きい。

新しく作るときや大きく作り替えるときは、何をどの層で検査するかを計画のうちに決める。部品ごとの検査、部品をつないだ検査、最初から最後まで通す検査を、どんな割合にするか。テストを書く前に、動かさなくても機械がコードを読むだけで弾ける誤りはどれか。

後から足したテストは、いま書いたコードが通るように書かれてしまう。それでは実装を書き写しただけで、検査にならない。

始める前に「何が揃えば完了か」を 1〜3 行で書く。2 回試しても満たせなければ、そこで止めて状況を報告する。回数を先に決めておくのが要点で、その場で決めると、たいてい「もう 1 回」になる。

成功条件が無いと、止めどきも分からない。「もう少しで動きそう」と思ったまま、動かない時間がいちばん長く続く。

大きな作業の前に、長くなることを伝え、分けて進める案を出す。途中で余力がなくなりそうなら、無理に続けず、いったん要点をまとめて区切り直す。

限界に近い状態で続けると、質が落ちるうえに、落ちたことに本人が気づけない。気づけないことは報告もできないので、始める前に言っておくしかない。

今ある決めごとと、いま必要なやり方がぶつかったら、どちらか一方を選び、選んだ理由を書く。選ばなかったほうには「整理が要る」と書き残す。

両方を立てるように書くと、矛盾は消えないまま見えなくなる。次に触る人は、2 つが食い違っていることを知らないまま、どちらか片方だけを守ってしまう。

区切りを越えるたびに、済んだことと残っていることを短くまとめる。読む人のためでもあるが、いちばんの狙いは、途中で方向がずれたときに戻れる地点を作ることにある。

最後にまとめて出すと、ずれていたときに全部やり直しになる。

書式や書き方の決まりは、良し悪しより揃っていることのほうが効く。そこに既にあるやり方に合わせる。異論があれば、勝手に変えずに、言葉にして伝える。

自分 1 人で全部を書くなら、どちらでもよい。後から誰か（未来の自分を含む）が読むなら、揃っていないこと自体が、後々まで残る手間になる。

フレームワークや実行環境の最新版は、覚えている知識で決めず、その場で一次情報（作り手自身が出している情報）を調べて決める。世代が 1 つずれると、使える書き方も推奨されるやり方も変わるので、気づかないうちに古い作り方が混ざる。

AI に書かせるときは、とくに気をつけている。AI は、学習した時点の「最新」を今の最新だと思って書く。だから最新版の一覧を別に用意し、AI の知識よりそちらを優先させている。一覧に無いものは、そのつど調べてから使う。

作業の中身より先に、「何を頼まれたか」「何をしたか」「判断してほしいことはあるか」の 3 行を書く。判断が要らなければ「なし」と書く。頼まれていない作業（自動で動いたものなど）なら、何がきっかけで動いたのかを書く。

経過を全部見せても、読む量が増えるだけで、判断に使える情報は増えない。読む人は、次に自分が何をすればよいかを知りたい。

専門用語には、括弧で 1 行の言い換えを付ける。技術の話には、それが仕事や運用にどう影響するかを 1 文添える。略語は、初めて出たところで元の言葉に開く。

別の場所に置いた説明は、まず開かれない。説明は、その場に書かないと読まれない。

道具の名前、設定の名前、社外のサービスの名前は、1 つの報告の中で初めて出たときに 1 回だけ、「何をするものか」「なぜ今出てきたか」を添える。添えるか迷ったら、添える。

「知っているはず」は書き手の主観で、それが外れたときにだけ、相手が困る。長い作業では、前に説明したかどうかを正確には追えない。だから「初めて出たとき」は、1 つの報告の中で数える。

質問には「なぜ今これを聞くのか」を 1 文入れる。選択肢ごとに、選ぶと何が起きるかを平易な言葉で書く。取り消せるかどうかや、費用・時間に差があるなら、それも書く。おすすめがあれば先頭に置き、その理由を 1 行添える。

選択肢を短い名前だけで並べても、意味は書いた本人にしか通じない。背景を書かずに選ばせると、選ぶ側は作業の中身を推測するしかない。

「包括的な」「見ていく」「浮き彫りになっている」のように、中身が無くても書けてしまう言葉を一覧にしてあり、文章を出す前に照らし合わせる。ただし消すだけでは穴があくので、数字・事実・自分の判断に置き換える。

置き換える中身を持っていなければ、その文は書かない。持っていない中身をこしらえれば、それは捏造になる。書かないほうがまだ正しい。

報告や質問を出す直前に、1 回だけ自分に問う。「作業を見ていない人がこれを読んで、意味と次にやることが分かるか」。分からないところがあれば、前提を書き足してから出す。

書いている最中は、自分が作業を全部見ているので、この問いは当てられない。書き手が読む人の立場に立てるのは、出す直前の一度だけ。だから、読み返すのはそのときと決めてある。

手元で作った測定（試算、模擬の実行、自作の採点）は、仮説として扱う。進めるか止めるかは、外で実際に測った値、実際に動かした出力、人が確かめた事実をよりどころにして決める。数字を出すときは、それが実測なのか仮説なのかを書き添える。

同じ間違いを繰り返す原因は、注意不足ではなく、自分の推論を自分の推論で確かめていることにある。これでは輪が閉じたままで、「もっとよく考える」では抜け出せない。外の事実に当てて確かめるしかない。

数字を根拠にする前に、「この測定は〇〇のときだけ信用してよい」と書いておく。その条件を確かめられないなら、その数字で判定はしない。毎回確かめるのは 3 つ。どんな対象を測ったのか。それは本番で効いてくる対象か。別の測り方でも同じ結果が出るか。

数字が出てから考えると、欲しい結論に合う理由のほうが先に見つかる。自分で弱点を書いておきながら、それでも数字を出して結論に寄せたくなったら、そこで立ち止まる。

検査役（作業の結果を点検させる別の AI）の指摘は、2 つに分けて確かめる。食い違いが本当にあるか。あるなら、どちらが間違っているか。前者は機械でも分かるが、後者は元の記録を見ないと決まらない。

どちらが間違っているかを取り違えたまま直すと、正しかったほうを壊してしまう。検査役の数を増やしても、この向きは決まらない。増やすより、元の記録に当てる。いつもの検査 1 回は、毎回通す。それ以上に別の目を足すのは、大事な判断のときだけにする。何にでも検査役を重ねると、結果は変わらないのに手間だけが倍になる。

期待されている結論でも、それに反する事実があれば、はっきり言う。悪い報せは、和らげず、脚注に回さず、後回しにもしない。自分が作ったものも、他人が作ったものと同じ厳しさで疑う。

相手の仮説だから支持する。自分が作ったから信じる。どちらも、同じ種類の身びいきになる。「たぶん大丈夫」「方向性は合っている」で締めたくなったら、そこで立ち止まる。受け取りやすく整えたぶんだけ、判断に要る情報は減る。

調べたこと、試して駄目だったこと、途中で捨てた案は、そのつど記録に書き出す。覚えておくためではなく、頭から手放すために書く。

経過を抱えたまま次を判断すると、捨てたはずの案に引きずられる。これは人でも AI でも同じで、結論だけを持って次へ進むほうが、判断が正確になる。

何を直したかの記録は、1 つの計画につき 1 ファイルにまとめる。書くのは、触ったもの、何をどう変えたか、なぜ必要だったかの 3 つ。終わらなかったことがあれば、「残り」として書き足す。

直したファイルごとに残すと、1 つの狙いで入れた変更が、ばらばらの記録に散ってしまう。後から読む人は、何を変えたかではなく、なぜ変えたかを知りたい。狙いの単位でまとめておかないと、それが読み取れない。誤字の修正のような軽いものは記録しない。何でも残すと、記録があること自体に意味がなくなる。

これからやることは 1 か所に集め、まだ手を付けていないものを必ず上に置く。1 件は数行まで（深刻さ、何が問題か、どこの話か）。終わったら、結果や詳しい中身は一覧に書かず、日付つきの記録へ移して、一覧にはリンクだけを残す。

優先するのは、控えている仕事を埋もれさせないこと、この 1 点。終わったものの説明が増えるほど、まだ手を付けていないものが下へ押し流される。誰も読み返さなくなった一覧は、役に立たない。

コードを直したら毎回、軽い点検を通す。入力の扱い、権限まわり、外部との通信、秘密の値、ファイルやコマンドの実行など、危ないところに触れた変更のときだけ、セキュリティの点検を加える。関係のない変更（文章だけ、設定だけ）では飛ばし、飛ばしたことを書き残す。

深く調べる検査は、節目に人が起動する。毎回やらないのは、手間の問題だけではない。毎回のように警告が出る検査は、そのうち検査ごと無視される。軽い点検を「気づいたらやる」に任せないのも同じ理由で、任せておくと、忙しいときに抜け落ちる。