一人社長の経営判断——責任を一身に背負う決定フレーム

📝決定を文書に残す（ADR）

頭の中だけで判断すると、後から「なぜそう決めたか」が消えてしまいます。

私たちは、方針転換や重要な判断をADR（Architecture Decision Record・意思決定記録）という形式の文書に残す運用にしています。書く内容は、決めたこと・その理由・検討した他の選択肢・却下した理由の4点だけの短いものです。例えば「収益目標を当初の水準から実現可能な水準へ引き下げる」といった方針転換をした時も、なぜ従来の水準を維持しなかったか、代わりにどんな指標を軸に据えたかまで書き残しています。後から「あの時なぜこう判断したのか」を自分自身で検証できる状態にしておくと、相談相手がいなくても、過去の自分の判断根拠と対話できるという感覚があります。

🔍「たぶん大丈夫」を「実測して大丈夫」に変える

一人での判断は、確認を怠っても誰にも指摘されないという危うさがあります。

チームがいれば、誰かが「その前提、本当に合ってる?」と聞いてくれることがあります。一人だとその機会がないため、私たちは「文書に書かれた計画」と「実際の状態」を意識的に分けて、判断の前に実際のデータやシステムを確認するというルールを設けています。記憶や過去の記録を根拠に「たぶんこうだったはず」で進めると、状態が変わっていたことに気づけないまま判断してしまうリスクがあるためです。実際に、稼働中のはずと記録上は扱っていたサービスが、定期的な生存確認をかけてみたら実際には止まっていた、ということもありました。記録の更新が実態に追いついていなかったケースで、確認していなければしばらく気づけなかったと思います。

この確認は自分自身の判断だけでなく、AI COOからの報告にも同じ基準を適用しています。「対応しました」「反映済みです」という自己申告をそのまま記録として受け取るのではなく、APIやCLIで実際の状態を突き合わせてから報告させるハーネスを組んでおり、承認境界・棚卸しのルールとあわせて ai-coo-starter という自社OSSに収めています。

⚖️判断の重さに応じて承認の重さを変える

全ての判断を同じ重さで扱うと、身動きが取れなくなります。

取り消しやすい判断と、取り消しにくい判断（金銭的な影響が大きい、外部に公開される等）を分け、後者だけ事前に一段深く確認する、という運用にしています。例えば社内向けの下書きメモの誤字を直すような判断は気づいた瞬間にそのまま直しますが、対外的に発信する文章や、後戻りしにくい契約・支払いが絡む判断は、いったん時間を置いてから見直す、というように扱いを変えています。全ての判断に同じだけの慎重さを求めると意思決定が遅くなりすぎますし、逆に全てを軽く扱うと、取り返しのつかない判断まで見過ごしてしまいます。判断の重さを最初に見極めることが、一人での意思決定を持続可能にする鍵だと感じています。

🧭まとめ: 相談相手がいない分を、仕組みで補う

決定はADRとして理由まで書き残す。判断の前に「たぶん」でなく実測で状態を確認する。そして判断の重さに応じて確認の深さを変える——この3つに共通しているのは、どれも壁打ち相手の代わりを人ではなく仕組みに担わせている点です。

壁打ち相手がいないことを嘆くより、その不在を前提にした仕組みを作る方が、一人社長には現実的だと考えています。

📚参考・出典

• Michael Nygard: Documenting Architecture Decisions（2011）（決定と背景を1件1文書で残すADRという書き方を広めた原典）
• Architectural Decision Records（ADRのテンプレートと運用例をまとめたコミュニティのサイト）