AI時代に「世界を閉じる技術」が価値を持つ（後編）

後悔の目撃者として

私はこれまで、多くの経営者の後悔を目撃してきた。

「なぜあの時、ちゃんと仕組み化しておかなかったのか」

優秀な人材の大量離職。制度の形骸化による組織崩壊。創業の理念を見失った迷走。これらはすべて、予防可能だった悲劇である。

この記事では、私の経験を基にしたストーリーを通じて、組織運営の落とし穴と、それを防ぐ可能性について考えていきたい。架空の事例ではあるが、多くの組織が直面する普遍的な課題を含んでいる。

なぜ予防できなかったのか。答えは明確だ。

短期的な効率を優先し、長期的な仕組みづくりを後回しにしたから。

正直に言おう。組織の将来を守る仕組みづくりは、想像以上に手間がかかる。目の前の業務に追われる中で、将来の問題に備えることは後回しになる。私自身、キカガクを経営する中で何度もその誘惑に負けそうになった。

しかし、短期的な楽は、長期的な苦痛になる。これが組織運営の残酷な法則だ。

それでも、私はこの「手間のかかる作業」に価値があると確信している。なぜなら、ソフトウェア開発の世界で、短期的な手間が長期的な効率を生むことを身をもって体験してきたからだ。そして今、AI 時代だからこそ、この知恵を組織運営に転移学習できる時が来た。

前編では「世界を閉じる」という概念について語った。無限の可能性を有限の計算可能な形に変換する、人間にしかできない創造的行為。後編では、この技術をどう組織運営に実装するかを、私自身の失敗と学びを通じて共有したい。

時間という残酷な審判

創業の想いはなぜ消えるのか

誰しも創業者には明確な想いがある。

売上より社会的インパクト、利益より価値創造。この想いは、創業メンバーと直接対話する中で共有され、強固な文化として根付いていた。

しかし、組織が成長するにつれて、この想いは次のような構造の問題によって徐々に薄れていく。

新しいメンバーが入るたび、創業の想いは少しずつ薄まっていく。それは悪意からではない。単に、文脈を共有していないだけなのだ。

「誰に売るべきか」という判断基準も変質していく。最初は「社会課題を解決したい企業」だったのが、いつの間にか「お金を払ってくれる企業」になってしまう危険性がある。

制度の劣化という普遍的現象

この現象は、創業の理念だけでなく、あらゆる制度で起きる。

私が観察してきたパターンはこうだ。制度導入時は明確な目的があり、全員がその意図を理解している。短期的には素晴らしい効果を生む。しかし時間が経つにつれて、「なぜこの制度があるのか」が忘れられ、形だけが残る。

最も皮肉なのは、短期的な成功体験が、長期的な失敗の種になることだ。

最も恐ろしいのは、問題が顕在化するのは、誰も注目していない時だということだ。新しい制度に目が向いている間は大丈夫。忘れられた頃に崩壊が始まる。

これこそ、前編で述べた「世界を閉じる」ことができなかった結果だ。無限の解釈可能性を持つ理念を、検証可能な形に変換できていなかった。

善意が組織を蝕む：副業制度の悲劇

すべては優秀な社員の提案から始まった

多くの企業に共通する架空のストーリーで失敗が起こる構造を共有したい。「優秀な社員の善意」から始まった組織崩壊の物語だ。

エース級エンジニアから「最新技術のキャッチアップのため、週末にスタートアップで開発経験を積みたい。得た知見は必ず会社に還元する」という提案があった。

本業で圧倒的な成果を出している社員の向上心。応援しない理由はなく、特例として承認した。

公平性という名の罠

問題は、この「成功事例」が広まってからだ。

「なぜ A さんだけ副業が許されるのか」
「公平性に欠けるのではないか」

確かに一理ある。そこで、副業制度を正式に導入することにした。短期的には公平性を確保できる素晴らしい判断に見えた。

しかし、ここで致命的なミスを犯した。

私たちは「A さんのような人」という前提条件を明文化しなかったのだ。短期的な公平性を優先し、長期的な制度設計を怠った。

予期せぬ展開

制度導入から 2 年後、採用面接でこんな光景が日常になった。

「副業 OK ですよね？」

これが応募者の最初の質問。本業への意欲より、副業での稼ぎが目的の人材が集まり始めた。

さらに皮肉だったのは、会社の雰囲気の変化だ。チームワークより個人プレー。会社への帰属意識より、個人のキャリア。まるでフリーランサーの寄せ集めのような組織になってしまった。

そして最も衝撃的だったのは、提案者の A さんが退職したことだ。

「こんな会社になるとは思っていなかった。本当に技術で世界を変えたいという仲間と働きたい」

優秀な社員のための制度が、優秀な社員を失う原因になった。この皮肉に打ちのめされた。

問題の本質：誰のための制度か

この失敗から学ぶべき最も重要なことがある。

優秀な社員の提案は、上位数% の世界の話だということだ。A さんのような人は、全社員の 5% もいない。しかし制度は、100% の社員に適用される。

前編で述べた「世界を閉じる」ことにも通じる。無限の可能性を持つ「全社員」ではなく、適切に対象を絞る。これができていなかった。

この例からの反省として、次のような副業制度の前提条件をまず明文化する必要があった。

副業許可の前提条件

• 本業での評価が一定以上
• 会社への貢献意欲が明確

そして、さらにこれらを「なんとなく」の文章ではなく、検証可能な形で定義する必要があったのだ。

ソフトウェア開発の日常に学ぶ：なぜ彼らは「手間のかかる」作業を続けるのか

提案した瞬間に走る数百のテスト

ここで、ソフトウェア開発の世界で当たり前に行われていることを紹介したい。実はこれこそ、「世界を閉じる」技術の最も洗練された実践例なのだ。

エンジニアがコードを書き、その変更点を提案する。その瞬間、何が起きるか知っているだろうか。

驚くべきは、これが人間の介入なしに、自動で、数分以内に完了することだ。

10 人が同時に開発していても、それぞれの変更が既存システムと矛盾しないか、個別にチェックされる。過去 5 年分の仕様との整合性も、瞬時に確認される。

このチェックは自動で行われるが、そのために過去のエンジニアが未来の自分たちのために苦労して書いた数百のテストコードが存在する。

なぜこんな「手間のかかる」ことをするのか

正直に言おう。テストを書くのは、本当に手間がかかる。

機能を実装するコードが 10 行であっても、それをテストするコードは 100 行になることもある。つまり、10 倍の手間をかけて「チェックの仕組み」を作っている。

短期的には非効率の極みだ。

なぜエンジニアはこんなことをするのか。

私もかつて、テストを書かずに開発したプロジェクトがある。最初は速かった。短期的には圧倒的に効率的だった。しかし半年後、地獄を見た。新機能を追加するたびに、どこかが壊れる。バグ修正に追われ、新規開発どころではなくなった。

今日の 1 時間が、将来の 10 時間、いや 100 時間、1000 時間を節約する。
短期的な手間が、長期的な効率を生む。

この実感があるから、エンジニアは手間を惜しまずテストを書く。

AI 時代だからこそ可能になった転移学習

「でも、それはソフトウェアの世界の話でしょう？」

そう思うかもしれない。確かに、10 年前ならその通りだった。しかし今は違う。

AI の登場により、組織運営の多くの要素が「計算可能」になった。

従来は数値化できなかった要素も、LLM を使えばある程度の定量化が可能だ。コミュニケーションの質、チームの雰囲気、創造性の度合い。これらも間接的に測定し、検証できる時代が来ている。

つまり、ソフトウェア開発で培われた「検証可能にして、自動でチェックする」という知恵が、ついに組織運営にも応用できるようになってきているのだ。

もちろん、この話が一般的になるのはもしかしたら数年後、いや 10 年以上先かもしれない。それでも、未来を見通し、いち早くその特性に合わせて仕込んでおくことは、組織運営においても重要な戦略になる。

明文化の罠：なぜルールがあっても機能しないのか

レベル 1：美しい言葉の無力さ

多くの組織には、立派な理念や行動指針がある。

「私たちは従業員の成長を大切にします」
「顧客第一主義を貫きます」
「イノベーションを推進します」

素晴らしい。しかし、これでは何も検証できない。

「成長」とは何か？「顧客第一」をどう測るのか？「イノベーション」の定義は？

曖昧な美辞麗句は、解釈の余地を残し、都合よく使われる。結果として、本来の意図とは真逆の行動を正当化する道具になることすらある。

レベル 2：定義しても測れない苦悩

一歩進んで、定義を明確にする組織もある。

「従業員の成長とは、スキルの向上と責任範囲の拡大を指す」

前進だ。しかし、まだ不十分。「スキルの向上」をどう測定するのか？「責任範囲の拡大」の基準は？

定義しただけでは、検証可能にならない。

レベル 3：検証可能な世界へ

ここで、前編で触れた「世界を閉じる」技術が必要になる。

例えば、「従業員の成長」を検証可能にするには次のようにさらに具体化する必要がある。

これなら検証可能にかなり近づく。誰が見ても同じ判断ができる。そして重要なのは、改善の議論ができることだ。

「コードレビューの指摘事項は減ったが、それは成長なのか萎縮なのか」
「360 度評価に偏りはないか」
「この重み付けは適切か」

検証可能だからこそ、建設的な議論が生まれる。

3 つの検証：組織を守る CI/CD とモニタリング

CI（継続的インテグレーション）：制度の整合性を守る

ソフトウェア開発における継続的インテグレーション（CI: Continuous Integration）は、新しいコードが既存システムと矛盾しないかをチェックする仕組みだ。これはまさに「世界を閉じる」技術の組織版だ。

これを組織運営に応用すると、新制度導入前の整合性チェックになる。

実際に副業制度を導入する際、もし CI があったらどうなっていたか。

これが提案段階で分かる。実際に問題が起きてからではなく、事前に。会議で延々と議論するのではなく、システムが即座に指摘してくれる。

CD（継続的デリバリー）：制度を安全に展開する

継続的デリバリー（CD: Continuous Delivery）は、検証済みのコードを安全に本番環境へ展開する仕組みだ。段階的なロールアウトや A/B テストを通じて、リスクを最小化しながら展開する。

これを組織運営に応用すると、新制度の段階的導入になる。

実際に副業制度を段階的に導入する場合の流れは次のようになる。

こうすることで、「全社一斉導入」という最も危険な選択を避けられる。もし問題があれば、被害を最小限に留めながら軌道修正できる。

継続的モニタリング：形骸化を防ぐ

制度は導入して終わりではない。ソフトウェアと同じように、継続的な健全性チェックが必要だ。

形骸化は、ゆっくりと進行する。人間の注意力では見逃してしまう。だから自動化が必要なのだ。

このように、CI（事前検証）→ CD（段階的展開）→ モニタリング（継続的監視）という 3 段階の仕組みがあれば、副業制度の悲劇は防げたかもしれない。

最初から全社導入ではなく、A さんのような上位層だけで試験運用し、効果と副作用を測定。問題が見つかれば、その段階で条件を調整。こうすれば、優秀な人材を失うことも、組織文化が崩壊することもなかった。

Policy as Code：まだ見ぬ未来への 1 つの提案

組織ルールをコード化する時代は来るのか

ここで 1 つ、近い将来への問題提起をしたい。

Policy as Code ― 組織の方針やルールを、コンピュータが理解できる形で記述する技術。現在は主にクラウドインフラのセキュリティ管理などで使われているが、これが組織運営にも応用できる時代が来るのではないか。

これは確定した未来ではない。むしろ、私たちが共に考え、試行錯誤していくべき可能性の 1 つだ。そして、これこそが「世界を閉じる」技術の究極的な応用かもしれない。

創業の想いを形にする試み

まず、「誰を顧客とすべきか」という創業の想いを明文化してみよう。

一見、具体的に見える。しかし、これで本当に検証可能だろうか。

営業担当が顧客候補を前にして、「社会課題への取り組みが『明確』かどうか」をどう判断するのか。「技術活用への意欲が『高い』」の基準は何か。SDGs 貢献度の 30%とは、具体的にどう測定するのか。

これではまだ「明文化」の域を出ていない。

ソフトウェア開発であれば、このような曖昧な仕様でテストを書くことはできない。より具体的な定義が必要なのだ。

本当の Policy as Code へ：検証可能な実装

ここで、明文化を検証可能にするために Policy as Code の出番である。Policy as Code を具体的に検証する統一の規格として Open Policy Agent (OPA)¹ が代表的である。曖昧な基準を、機械的に判定可能な形に変換しておけば、ソフトウェア開発で紹介した CI/CD のように、組織運営でも検証可能なルールを自動で適用できる。

具体的な実装も紹介しておきたいが、現状でその全てを把握する必要はない。重要なのは、「検証可能な形で定義する」という考え方だ。そして、それらは AI の支援を受けることで実装がより容易にはなっているが、やはりその検証の定義には人間の思いが入っており、その世界をどうにかして閉じた形に落とし込む努力の一例を見てほしい。

支援すべき顧客の定義（第二段階：Policy as Code）

package customer.eligibility
 
import future.keywords
 
# 顧客適格性の総合判定
default eligible = false
 
eligible if {
    # 必須条件をすべて満たす
    social_impact_clear
    tech_enthusiasm_high
    partnership_mindset
 
    # 除外条件に該当しない
    not excluded
 
    # 総合スコアが基準値以上
    total_score >= 70
}
 
# 社会課題への取り組みが明確か
social_impact_clear if {
    # 以下のいずれかを満たす
    count(input.sdg_targets) >= 3  # 3つ以上のSDGsターゲットに取り組んでいる
    input.social_business_ratio >= 0.5  # 売上の50%以上が社会課題解決に関連
    input.has_impact_report  # インパクトレポートを公開している
}
 
# 技術活用への意欲が高いか
tech_enthusiasm_high if {
    input.rd_investment_ratio >= 0.05  # 売上の5%以上を研究開発に投資
    input.tech_adoption_score >= 8  # 技術導入積極性スコア（10点満点）が8以上
    count(input.poc_projects) >= 2  # 過去1年で2件以上のPoCを実施
}
 
# パートナーシップ思考があるか
partnership_mindset if {
    input.vendor_satisfaction >= 4.0  # ベンダー満足度が4.0以上（5点満点）
    input.co_creation_experience > 0  # 共創プロジェクトの経験がある
    not input.has_contract_disputes  # 契約トラブルの履歴がない
}
 
# 除外条件
excluded if {
    input.business_type in ["weapons", "gambling", "tobacco"]
}
 
excluded if {
    input.environmental_score < 3  # 環境スコアが基準未満
}
 
excluded if {
    input.labor_violations > 0  # 労働法違反の履歴がある
}
 
# スコア計算
total_score = sdg_score + rd_score + engagement_score + innovation_score
 
sdg_score = min(input.sdg_contribution * 30, 30)
rd_score = min(input.rd_investment_ratio * 600, 30)  # 5%で満点
engagement_score = min(input.employee_engagement * 20 / 5, 20)  # 5点満点換算
innovation_score = min(input.innovation_index * 20 / 10, 20)  # 10点満点換算
 
# 判定理由の生成
decision_reason = reason if {
    eligible
    reason := sprintf(
        "適格判定：必須条件クリア、総合スコア %d点（SDG:%d, R&D:%d, ENG:%d, INV:%d）",
        [total_score, sdg_score, rd_score, engagement_score, innovation_score]
    )
}
 
decision_reason = reason if {
    not eligible
    reasons := [r |
        not social_impact_clear; r := "社会課題への取り組みが不明確"
    ] | [r |
        not tech_enthusiasm_high; r := "技術活用への意欲が不足"
    ] | [r |
        not partnership_mindset; r := "パートナーシップ思考が不足"
    ] | [r |
        excluded; r := "除外条件に該当"
    ]
    reason := sprintf("不適格判定：%s", [concat(", ", reasons)])
}

この検証の形を見ると、呆れるほど面倒だと感じるかもしれないし、実際そうである。ただし、すでに伝えた通り、今の目の前の 1 時間向かい合うことが将来の 10 時間、100 時間、1000 時間を節約することに繋がるのである。今だけで評価してしまうとやらない方が得であるが、将来的に「なぜあの時ちゃんとしておかなかったのか」という後悔を防ぐために、今の手間を惜しまないことが重要であると前述のストーリーを読んで理解してもらえたはずだ。

さて、これで何が変わったか。

営業担当は、顧客情報を入力するだけで、即座に判定結果と理由を得られる。「なんとなく良さそう」ではなく、「SDGs ターゲット 5 つ、R&D 投資率 7%、総合スコア 85 点で適格」という明確な根拠付きで。

さらに重要なのは、この判定ロジック自体がコードとして残ること。100 年後の社員も、なぜこの基準だったのか、どういう計算式だったのかを正確に理解できる。そして、時代に合わせて更新もできる。

完璧な答えはまだない、だからこそ一緒に探索を

正直に言うと、Policy as Code を今すぐ組織運営に導入するのは難しい。技術的にも、文化的にも、まだハードルが高い。

しかし、少しずつでも進めることが大事である。

• 今日は明文化だけでもいい
• 来月は一部を数値化してみる
• 来年は OPA で試験的に実装してみる

完璧でなくていい。「世界を閉じる」ことに本気で向き合い、一歩ずつ進む。それが、後悔しない組織運営への道だと信じている。

今から準備を始める組織と、そうでない組織。5 年後、その差は歴然としているだろう。「あの時始めておけばよかった」という後悔を、これ以上見たくない。

だからこそ、完璧な答えがない今、一緒に探索していく仲間が必要なのだ。

制約が生む自由：ガードレールの価値

「なんでもやっていいよ」

一見、素晴らしい自由に見える。しかし実際には、人はこの状況で思考停止してしまう。選択肢が多すぎて、何も選べなくなるのだ。

一方で、ガチガチに管理されれば、人はロボットになってしまう。

だからこそ「制約の中の自由」が重要だ。高速道路にガードレールがあるから、ドライバーは安心してスピードを出せる。それと同じだ。

これも「世界を閉じる」ことの 1 つの形。無限の可能性から、意味のある選択肢の集合を作り出すこと。

Pull Request 文化：批判より提案を

ソフトウェア開発の世界には、素晴らしい文化がある。Pull Request（PR） である。問題があればその問題点に修正を加えて提案するのである。

Policy as Code によって GitHub などでコードとして組織運営の形も改善を提案する親和性が一気に高まる。組織運営もプロダクトと同じく、リリース日に完成するわけではない。日々の改善が積み重なってこそ、より良い組織が作られる。

不満があるなら、改善案を出す。データと根拠を添えて。それが公開で議論され、より良いものになって実装される。

文句を言う労力があれば、提案を実行可能な形で提案する。

これがソフトウェア開発の文化だ。そして、この文化こそが自律的な組織を作る。

この時に、しっかりとテストがあるからこそ、過去の懸念点も明確に洗い出され、改善のための具体的なアクションに繋がるのである。テストがなければ、その提案の妥当性を検証できない。だからこそ、組織運営においても CI/CD の考え方が重要なのだ。

双方向の価値創造

重要なのは、これがトップダウンの押し付けではないことだ。

現場から上がってきた改善案が、組織を変える。経営陣も、現場の声に耳を傾ける。お互いがお互いを信頼し、より良い組織を作っていく。

これこそが、私が目指す和談の形のひとつでもある。

今から始める、小さな一歩

完璧を求めない勇気

ここまで読んで、「ハードルが高い」と感じた方も多いだろう。私自身も提案はしているが、実際にはまだまだ実践できていないことばかりである。

完璧な Policy as Code を今すぐ実装するのは無理だ。CI/CD を完備するのも難しい。

でも、完璧を求める必要はない。ただし、最終的に理想とする姿を描き、現状を把握し、そのギャップを埋める努力をすることでしか変わることもないはずだ。

明日からできる 3 つの実験

1. 1 つの制度を選んで、成功基準を数値化してみる

   • 完璧でなくていい
   • まず測定できる状態にする
   • 3 ヶ月後に振り返り、学びを得る

2. 制度導入時に「なぜ」を記録する習慣

   • 背景、目的、期待効果
   • 将来の自分たちへの手紙として
   • できれば検証可能な形で（でも最初は箇条書きでも）

3. 小さな PR 文化を試してみる

   • 月 1 回の改善提案会
   • 批判ではなく提案を奨励
   • 小さな成功体験を積み、何が機能するか学ぶ

これらは仮説だ。あなたの組織で機能するかは、試してみないとわからない。

その際に一人で戦う必要はない。

社内にエンジニアがいるなら、彼らの知恵を借りよう。いなければ、外部の力を借りてもいい。大切なのは、同じ方向を向いて進む仲間を見つけることだ。

手間をかける価値：長期的思考への転換

予防の経済学

最後に、私がこの「手間がかかる」ことになぜここまでこだわるのかを何度も伝えたい。

それは予防の経済学を理解しているからだ。

今、1 時間かけて仕組みを作るか。
将来、100 時間かけてずっと問題に対応し続けるのか。

今、制度の前提を苦しくもひとつずつ明確にするか。
将来、優秀な人材を失うか。

今、創業の想いを大変ながらも検証可能に形式化するか。
将来、理念なき組織になるか。

短期的な効率と長期的な効果は、多くの場合トレードオフの関係にある。

しかし、組織運営において私たちはあまりにも短期的な効率を重視しすぎてきた。その結果が、冒頭で述べた「後悔する経営者たち」なのだ。

未来の自分たちへの贈り物

だから私は、短期的な手間を惜しまず、仕組みを作る。

それは管理のためではない。
効率化のためでもない。

未来の自分たち、そして未来の仲間たちへの贈り物なのだ。

3 年後、5 年後、10 年後。
「あの時、ちゃんと仕組みを作っておいてよかった」
そう言える組織でありたい。

短期的には非効率でも、長期的には最も効率的。
これが、組織運営における真実だ。

真の「和談」へ：共に未来を探索する仲間として

株式会社和談という社名に込めた想い。それは「和やかなコミュニケーション」だ。

しかし、ただ仲良くすればいいわけではない。問題を予防し、不要な対立を避け、本質的な議論に時間を使える。そんな組織でこそ、真の和談が生まれる。

エンジニアが毎日コツコツとテストを書くように。私たちも、組織の健全性を守る仕組みを作っていく。

たしかに、本当に手間がかかる。

でも、だからこそ価値がある。短期的な手間こそが、長期的な成功の礎となる。

これは完成された答えではない。むしろ、これから一緒に答えを探していく旅の始まりだ。

あなたの組織でも、この記事をきっかけに小さな一歩から始めてみてほしい。

関連記事

この記事について共感いただけたなら、次はこれらの記事で更なる視点を得てほしい。

• AI時代に「世界を閉じる技術」が価値を持つ（前編）：本記事の理論的基盤。無限の可能性を有限の計算可能な形に変換する技術の本質について、哲学的な視点から解説している。
• ボーナス制度の罠：組織に残す見えない負債の構造的問題：「優秀な社員の善意が組織を蝕む」もう 1 つの実例。副業制度と同じく、短期的成功が長期的失敗を生む構造を別の角度から分析。
• 成果物を超えたプロセス評価の真価：プロセスを検証可能にすることの重要性。AI 時代だからこそ、成果物だけでなくプロセスの品質保証が組織の未来を左右する。
• ユニットエコノミクスを応用した人材戦略：「今の 1 時間が将来の 100 時間を節約する」を人材戦略で実現。経済合理性と持続可能性を両立させる実践的フレームワーク。
• テスト駆動開発の進化形：AI協働開発におけるテストトロフィー戦略：なぜエンジニアは「手間のかかる」テストを書き続けるのか。組織の CI/CD とソフトウェア開発の類似性を技術的に深掘り。
• Memory Bankで実現する効率的なAI協働の開発ガイド：文脈を構造化し「検証可能」にする実践例。AI との協働において、知識をドキュメント化し長期的な効率を実現する手法。

これらの記事はすべて、短期的な効率より長期的な価値を重視する思想で貫かれている。あなたの組織の課題に最も近い記事から、小さな一歩を始めてみてほしい。

参考文献