判断の仕組みi-Willink
相談相手のいない社長の決め方
一人で経営判断をする社長には「それ本当に大丈夫？」と聞いてくれる人がいません。決めた理由を1件1枚で残す、判断の前に今の状態を確かめる、取り消せるかで慎重さを変える。私たちの3つの仕組みを書きます。
相談相手がいない経営判断の危うさは、間違いを指摘してくれる人がいないことです。私たちはその役を人ではなく仕組みに持たせています。決めた理由を残す、判断の前に今の状態を確かめる、取り消せるかどうかで慎重さを変える、の3つです。
会議で誰かに「それ、本当に大丈夫？」と聞かれる機会がない。一人やごく少人数で会社を回す社長の判断でいちばん危ういのは、この問い返してくれる相手がいないことだと感じています。
私たちの会社には役員会も、隣の席の同僚もいません。実務の多くはAIと分担しています。この記事は、相談相手の代わりに置いている3つの仕組みの記録です。専門家としての経営助言ではありません。
この記事の要点
- 1決めたことは、理由と、選ばなかった案まで含めて1件1枚の記録に残す。2026年11月時点で61件
- 2判断の前に、記録ではなく今の実際の状態を確かめる。AIからの「やりました」も同じ基準で扱う
- 3取り消せる判断はすぐ決め、取り消せない判断だけ時間をかける。お金・法律・外部に出るものが目安
- 4どれも、問い返してくれる人の役を仕組みに持たせている
決めた理由を、1件1枚で残す
決めたこと・理由・検討した他の案・選ばなかった理由を、短い文書に1件ずつ残します。数か月後の自分が、そのときの判断を検証できるようにするためです。
この書き方は ADR（Architecture Decision Record、意思決定の記録）と呼ばれます。もとはソフトウェアの設計の判断を残すために、Michael Nygard が2011年に提案した形です。背景、決定、その結果起きることを、1件1枚の短い文書に書きます。
私たちは設計に限らず、事業の方針や運営のルールもこの形で残しています。2026年3月に始めて、11月時点で61件になりました。たとえば承認の決まりを「重要そうか」ではなく「取り消せるか」で決め直したとき（2026年6月）も、なぜ以前の分け方をやめたか、他にどんな分け方を考えたかまで書いています。
一人で決めていると、「なぜこうしたんだっけ」は数か月で消えます。理由が残っていれば、状況が変わったときに「前提が崩れたから見直す」と判断できます。理由が無いと、前の決定を守るべきか捨てるべきかすら判断できません。
判断の前に、今の状態を確かめる
「たぶんこうだったはず」で決めず、判断の直前に実際のデータや画面を確かめます。記録に書いてあることと、今そうなっていることは別だからです。
チームなら、誰かが「その前提、今も合ってる？」と聞いてくれます。一人だとその機会がないので、私たちは「文書に書かれていること」と「今の実際の状態」を分けて扱う決まりにしています。状態を前提にする判断の前には、少なくとも1つは実際に確かめます。
この決まりは、AIからの報告にも同じように当てはめています。AIが「対応しました」「反映済みです」と書いてきても、その言葉をそのまま記録にしません。実際の画面や応答を確かめてから報告させる仕組みを組んでいます。同じ考え方の仕組みは、公開している道具（ai-coo-starter）にも入れています。
確かめるのに時間がかかりそうでも、たいていは数分で済みます。間違った前提で決めたあとに戻る手間に比べれば、ずっと小さな手間です。
取り消せるかどうかで、慎重さを変える
取り消せて、社内で完結し、お金や法律に関わらない判断はすぐ決めます。お金・法律・外部への発信・戻せない操作だけ、時間を置いて確かめます。
すべての判断に同じだけ慎重になると、何も決まらなくなります。逆にすべてを軽く決めると、取り返しのつかない失敗をします。そこで私たちは、判断を3つの軸で分けています。
| 軸 | 問い | 慎重にする例 |
|---|---|---|
| 取り消せるか | 間違えたら、元に戻せるか | 大量の削除、戻せない設定の変更 |
| 外に届くか | 社外の人の目に触れるか | 公開、配信、取引先への連絡 |
| お金・法律が絡むか | 支払いや契約が発生するか | 価格、契約、5万円を超える支出 |
3つとも当てはまらない判断、たとえば社内の文書の直しや、取り消せる設定の調整は、気づいたらすぐ決めます。どれか1つでも当てはまる判断だけ、いったん時間を置き、確かめてから決めます。この分け方の詳しい経緯は、承認は「元に戻せるか」で決めるに書きました。
3つに共通すること
どれも、問い返してくれる人の役を仕組みに持たせています。相談相手がいないことを嘆くより、いない前提で仕組みを作る方が、一人の社長には現実的です。
記録は「なぜそう決めたのか」を問い返し、確かめる決まりは「その前提は今も正しいのか」を問い返します。取り消せるかで分ける決まりは「本当に今決めてよいのか」を問い返します。どれも、会議で誰かが言ってくれるはずの一言です。
始めるなら、いちばん軽いのは1つ目です。次に大きな判断をしたとき、決めたこと・理由・選ばなかった案の3行だけを書いて残してみてください。3か月後に読み返すと、その価値が分かります。
よくある質問
ADR は、ソフトウェアの開発をしていなくても使えますか？
使えます。もとは設計の判断を残す形ですが、決めたこと・理由・選ばなかった案を1件1枚で残すという中身は、事業の方針や運営のルールにもそのまま使えます。私たちは事業の判断もこの形で残しています。
どの判断から記録すればよいですか？
後で「なぜこうしたんだっけ」となりそうな判断からです。方針を変えたとき、何かをやめると決めたとき、複数の案から1つを選んだときが目安です。
AIを相談相手にすれば足りませんか？
問い返しの相手としては役に立ちます。ただしAIの返答や報告も、そのまま正しいと受け取らず、実際の状態で確かめる必要があります。私たちはAIの報告にも同じ確かめの決まりを当てはめています。
参考・出典
- Documenting Architecture Decisions（Michael Nygard, 2011）（決定と背景を1件1文書で残す書き方の原典）
- Architectural Decision Records（adr.github.io）（ADR のひな形と運用例）
- ai-coo-starter（GitHub）（私たちが公開している、AIの報告を確かめる仕組みを含む道具）