ハクソク

世界を動かす技術を、日本語で。

コードとしての企業

109日前原文(blog.42futures.com)

概要

  • ソフトウェア企業の情報管理とISO 27001監査における現状の課題
  • 組織データのプログラマティックな表現「Company as Code」の構想
  • ドメイン固有言語（DSL）による組織モデルの例示
  • グラフ構造による組織関係の可視化と自動化の可能性
  • 実装に必要なシステム構成と今後の展望

ソフトウェア企業における情報管理のアイロニー

  • 先進的なツール で運用やコンプライアンスを自動化している現状
  • しかし、 組織の中核 （方針・手順・構造）は未だに「デジタル紙」管理
  • 日常業務の大半 がデータ化・API化されている一方、組織情報は分散・静的ドキュメント
  • 監査やポリシー更新のたびに 膨大な工数 が発生
  • 組織データの「疎さ」と運用データの「豊かさ」のギャップ

Company as Code：組織をコードで表現する発想

  • Infrastructure as Code や Policy as Code の成果を組織管理にも応用
  • 組織全体を プログラマティックに表現 し、バージョン管理・クエリ・自動検証を可能に
  • ポリシー変更 をコード変更として管理し、影響範囲を自動分析
  • 組織設計 を「ステージング環境」でシミュレーションし、波及効果を可視化
  • 既存の HRIS や GRCツール では実現困難な「全体最適」と「関係性の明示化」

Company Manifest：理想的な組織モデルの要件

  • 人・ポリシー・システム 間の関係を明示的にトレース
    • 依存関係の追跡、ポリシー影響範囲の即時可視化
  • 変更履歴の明確化 （誰が・何を・なぜ変更したか）
    • 監査や組織進化の理解に不可欠
  • 既存ツールとの連携 （Azure、Slack等）
    • 常に最新の組織像を維持し、ポリシーに基づく設定自動化
  • 変更の事前検証環境 と 自動テスト
    • ルールやコントロール単位での検証
  • ノンテクニカルな利用者にも直感的なUI

DSLによる組織構造の定義例

  • エンティティ型・識別子・属性 で構成される宣言的記述
  • 例：エンジニアリングチームの定義
Role "SoftwareEngineer" {
  Responsibilities = [ "クリーンなコード作成", "コードレビュー参加", "技術決定の記録" ]
}
Role "EngineeringManager" {
  Responsibilities = [ "技術リーダーシップ", "評価面談", "チームリソース管理" ]
}
OrganisationalUnit "EngineeringTeam" {
  Department = "Engineering"
  CostCenter = "ENG-001"
}
Person "AliceSmith" {
  FullName = "Alice Smith"
  Role = Role.EngineeringManager
  Unit = OrganisationalUnit.EngineeringTeam
  Email = "alice.smith@company.com"
}
Person "BobJohnson" {
  FullName = "Bob Johnson"
  Role = Role.SoftwareEngineer
  Unit = OrganisationalUnit.EngineeringTeam
  Manager = Person.AliceSmith
  Email = "bob.johnson@company.com"
}
PolicyGroup "SecurityPolicies" {
  Owner = Person.AliceSmith
}
PolicyRule "MFARequired" {
  Group = PolicyGroup.SecurityPolicies
  Enforcement = "Mandatory"
  ComplianceLevel = "Critical"
}
ExternalRequirement "ISO27001_A9_4_1" {
  Standard = "ISO 27001:2013"
  Control = "A.9.4.1"
  ComplianceLevel = "Mandatory"
}
ComplianceMapping "MFACompliance" {
  Requirement = ExternalRequirement.ISO27001_A9_4_1
  ImplementingPolicies = [PolicyRule.MFARequired]
}
  • 宣言的なDSL で組織全体の構造・規則・外部規制との対応関係を一元管理
  • ファイル分割・ディレクトリ管理 でバージョン管理やレビューも容易

組織グラフ構造による関係性の可視化

  • 有向非巡回グラフ（DAG） ではなく、 無向循環グラフ が必要
    • 人が人を管理し、ポリシーが活動を参照し、複雑な相互依存が発生
  • グラフクエリ による影響分析例
    • 「MFAポリシー変更時、どの外部要件が影響を受けるか」等
  • C#によるシンプルなノード・エッジ実装例 （省略）

実装に必要なシステム構成

  • グラフDB ：組織モデルの永続化
  • リレーショナルDB ：エビデンス等の付随データ管理
  • イベントストア ：監査証跡・変更履歴の保存
  • プラグイン型インテグレーション基盤
    • GitHubやAzure等からのデータ収集
    • ポリシー検証・自動証拠収集
    • 組織変更時の自動プロビジョニング・権限変更
  • DSL内のControlエンティティ で外部スクリプト連携・自動チェック
Control "MFAMonitoring" {
  Implements = ComplianceMapping.MFACompliance
  Verify {
    Script = "Security/mfa-checks.js"
    Methods = [ "allUsersHaveMfaEnabled" ]
    Frequency = "Daily"
  }
}

今後の展望と課題

  • 組織の複雑性 をコードでどこまで抽象化・モデル化できるか
  • 既存ツール群の統合 と 新たな抽象化レイヤー の必要性
  • エンジニアとビジネスリーダー 双方が使いやすい設計
  • 継続的なコンプライアンス監査・組織設計の自動化 の実現可能性

この「Company as Code」構想は、組織運営の透明性・効率性・自動化を大きく進化させる可能性を秘めています。今後は、実際のプロトタイプ実装や既存ツールとの連携事例の蓄積が期待されます。

Hackerたちの意見

これに最も近いのはGitLabの形だと思う。あそこは有名なオープンハンドブックを作って、企業向けの仕事をたくさんやってたよね（https://handbook.gitlab.com/）。初期の頃は、すごくオープンで包括的だった。仕事でどう扱うか迷ったときに、何度も見たことがあるよ。

└

それはかなりクールだね。今でもちゃんと展開されて更新されてるのかな？もし「エージェント」ワーカーを展開したいなら、そのソースは文脈の宝の山だね。

└

そのサイトはGitリポジトリとしても利用可能だよ - もちろんGitLabでね： https://gitlab.com/gitlab-com/content-sites/handbook

これって要するにERPを再発明しようとしてるだけじゃない？（つまり、SAPが2070億ドルの企業を築いたもので、フォーチュン500の90％や他の大企業が使ってるやつ）。ERPをコード化することが今のものより価値があるって主張することもできるけど、これが全く新しいアイデアだって言うのはちょっとおかしいよね。

└

俺が働いてたところは、会社で起こることは基本的にLotus Notesの中でアクションとして実装されてた。実装の選択やパフォーマンスは最悪だったけど（決定した時はNotesが唯一の選択肢だったけど、25年後にはそうでもない）、実際のアイデアは素晴らしくて、めちゃくちゃうまくいってたよ。

Hats Protocolでこれを試したんだけど、俺たちのアプローチはすごく合ってると思う！ https://blog.hatsprotocol.xyz/organizational-graphs DAOsの視点からアプローチしたんだけど、最初は役立ったけど最終的には制限があったかな。ブロックチェーンじゃないバージョンが流行ると思う。Tailscaleはそれを実現するのにいいポジションにいるよ。俺たちの得た洞察は、組織内で上下に機能するための適切な委任の原則を構築する必要があるってこと。最近の考えは「Trust Zone」って呼んでるもので、詳しくはここにあるよ： https://blog.hatsprotocol.xyz/making-daos-work 「DAO」の部分は無視しても大丈夫。質問があれば喜んで答えるよ。この探求にはまだすごくインスパイアされてるから。

└

Hats Protocolで似たようなコンセプトを実装した経験をシェアしてくれてありがとう！委任のための「Trust Zone」のアイデアは興味深いね。これらの組織構造をプログラムで構築・維持する際に、具体的な課題に直面したことはある？

これは新しいアイデアじゃないよ。俺はキャリアの初めにこういうことを提案したし、聞いてくれる人がいるときには何度も提案してきた。問題は、組織内の権力ダイナミクスに対する脅威なんだ。コンプライアンスの人たちは、自分たちの成果がこんな風に簡単に検索できてインデックス化されるのは得にならない。だって、彼らの必要性が減るからね。経営者やリーダーもこれからは、さまざまなコンプライアンスフレームワークの知識が求められるから、得にはならない。知識や専門性から権力を得ている人たちが、会社やその運営を支配していることが多くて、彼らはこれを実装するよりも、むしろ完全にブロックする方が得なんだ。俺はこのアイデアが大好きだよ。組織内の透明性が好きで、サイロの壁を越えて問題を特定して解決するのが無限に楽になるから。これは最高の協力だし、俺はそれを支持する。でも、競争が社会全体のデフォルトの運営モードとされている限り、これが大規模に実現するとは思えない。それでも、内部の協力を重視する組織で働きたいと思ってる。そこではうまくやれると思う。

└

問題は、いや、ほんとに唯一の問題は、これが組織内の権力ダイナミクスに与える脅威だってことだよね。それに専門知識も、正直なところ。ドキュメンテーションをコードとして扱うのは、ソフトウェア業界で言うところのテストや型システムのことだ。大多数の開発者は、自分のコードに対して良いテストすら書けないし（そもそも試そうとすらしない人も多い）、ロック証明を書くように頼んだら完全に目が glazed over しちゃうんだよね。コードに命をかけてる人たちですらそうなんだから、ビジネスの人たちなんてもっと遠いよ。

└

今日の「コンプライアンス」はなくなっていくね。

└

とはいえ、内部協力を重視する組織で働きたいな。そこでなら自分が成長できる気がする。キャリアの中でずっとそんな組織を探してたけど、最近は自分で作らない限り無理だろうなって諦めてる。[1] https://blog.webb.page/WM-081

└

それは権力を制約し、意思決定を監査可能にして、権力を持つ人々をガイドラインに従わせるんだ。経営陣は、このパラダイムが嫌いなのは、大手テックプラットフォームが行動やモデレーションのガイドラインを曖昧にしているのと同じ理由だよ。明確に正当化できない理由で、削除したり、罰したり、解雇したり、権力を行使する自由を与えてくれるからね。これはEUや世界中の国々が避けているのと全く同じパラダイムで、報道の自由や表現の自由のようなものにおいて適正手続きを否定して、問題視する発言や人々、グループを抑圧したり「管理」したりする柔軟性を持たせている。明確な法の支配が権力の行使を制約するんだ。権力を振るいたい人は、絶対にそれを好まないよ。

└

競争が社会全体のデフォルトの運営モードとされている限り、スケールで実現するとは思えないね。人や組織間の競争は必要ない、ほぼ同じように機能するけど、異なる二次的なトレードオフを伴う解決策間の競争だけで十分だよ。企業の問題を同じように解決する二つのアプローチを考えてみて。どちらも異なる人に異なる量の作業を生み出すけど、どの解決策を選ぶ？誰が、どの基準で決定するの？少しでもスケールが入ると、これは避けられないよ。

└

何が人々を政策に従わせないようにしているの？「紙のドキュメント」ポリシーも「コードポリシー」も、人間がシステムを利用したり回避したりするのを制約していないから、監視やコンプライアンスは依然として混沌とした人間の機能に見えるね。これはただの「より構造化されたコンプライアンス文書」になるの？それは良さそうだけど、劇的に違うわけじゃない。そして、作成側では、同じような政治的争いが「コードポリシー」に何を入れるかで起こるのをどう防ぐの？それは紙のポリシーで妥協や奇妙な事態を引き起こすのと同じことだよ。

└

ワークグループのパワーダイナミクスに関する本ってある？ちょっと興味深い（なんか病的な意味で）。

ビジョンは好きだけど、インフラと企業の最も重要な違いをスルーしてる気がする。インフラをコードとして扱うのは指示的だけど、企業をコードとして扱うのは説明的なんだ。企業は常に現実に追いつこうとしてるだけで、創造してるわけじゃない。変化は一気に起きるんじゃなくて、徐々に進む。パターンも時間とともに変わって、後から文書化される。企業のコードを指示的にするには、自由よりも抑圧的で制限的な狂った量の規律が必要になるだろうね。

└

その通りだね。規範主義と記述主義をこういうアーキタイプで考えてる： - 「ルールを守る人」は、みんなが従うべきルールを合意すれば組織が良くなると思ってる。境界のところでは、新しいルールを作って新しいことを明確にしようとする。親切に言えば、古いルールを取り除くかもしれないけど、実際にはこれが十分に真実だとは言えないよね。例えば、政府は古いルールを取り除くよりも新しいルールを追加する方が圧倒的に多い。 - 「ルールを破る人」は、ほとんどのルールは提案に過ぎないと思ってる。境界のところでは、他の人が無駄に縛られているルールを見つけて、それを自分がやっているゲームの戦略的な隙間に変換する。良くも悪くも、スタートアップエコシステムにはこういう人がたくさんいる。ルールを守る人は何が許可されているかを知りたがるけど、ルールを破る人は何が_許可されるべきか_を原則から考えようとする。極端な場合、彼らは世界を権威主義に引っ張ったり、無政府状態に引っ張ったりする。これは明らかにスペクトラムで、誰もがこの二つのアーキタイプを持っているけど、比率はそれぞれ違う（例えば、ほとんどの人は税金を払うけど、制限速度を守る人はほとんどいない）。

デジタルでないシステムを「コード」として説明するのは、真実の源ではなく、希望の源だよ。コードは意図された状態を示してるけど、現実と調和させる何かが必要なんだ。これは非構造化文書にあるのと同じこと。だから、監査はまだ必要だし、面白いことに。だから、これができるかもね。CI/CDで何が動いてるのか見てみたいな。誰かが間違ったことをやったり、現実でコンプライアンスを壊したりしたら、どうやってそれをバックポートするの？「アリスはソフトウェアエンジニアで、会社設立時に自分のメールでこのSaaSアカウントを作った。管理者のメールは変更できず、彼女は管理者権限を持ってるけど、別の役割がそれを管理するべきなのに。」

ここでの主な問題は、実際の人間があいまいな領域で動いていることだよね。「コードで」彼らをピタッと当てはめても、最も価値のある実際のワークフローに内在するグレーゾーンは魔法のようには解決しない。例えば、貴重な「高いエージェンシーを持つ労働者」について考えてみて。彼らが魅力的なのは、まだ組織的に定義されていない、あるいはそのタスクに対して「間違った」形で定義されている問題について、よく考えた上で一方的に決定を下す意欲と能力があるからなんだ。あと、Terraformが機能する理由は、それが_運用可能_だから。つまり、実際に動くコードってこと。もしただのドキュメントだったら、誰も気にせずに流れていっちゃうよね。「組織のコード」を運用可能にするには、現実とドキュメントを手動で同期させるための強制力（コンプライアンスチームとか）が必要になる。実際の仕事が行われる肉体的・思考的な空間では、これを自動化するのは難しい。自動化が可能なのはデジタル空間だけだと思う。実際、この記事がそこに触れないのが意外だよ。「組織のコード」は、AIエージェントの定義としては実際の人間よりもずっと現実味を帯びてくる。なぜなら、エージェントはデジタル空間で運用されていて、強制が自動化できるから。

もしこれをすべてのコンプライアンスチェックボックスに拡張したいなら、無限の厄介な問題になると思う。どうやって（コードで）さまざまなチームが作成した新しいアプリケーションを正しいインベントリに追加することを強制するの？ある時点で、人間が特定の制限に対してアプリケーションが範囲内か範囲外かを判断しなきゃいけないよね。もしコンプライアンスフレームワークが特定のデータタイプに対して特定のハッシュアルゴリズムを要求するなら、あなたの会社をコード化したシステムはそれをどうやって強制するの？コンプライアンスに関して見えるのは、フレームワークが「XとYとZをやらなきゃダメ」って言ってるだけで、解決策は「従業員はXとYとZをやらなきゃダメ」って書いたドキュメントをみんなに共有することなんだよね。それが実際に起こっているスクリーンショットを撮る（可能ならね - もしかしたらただそう言うだけかもしれないけど）。要するに、ここには大きな人間の要素があるってこと。もしこの記事が会社やポリシーを宣言するための構造化された言語を提案しているなら、それはWordドキュメントと何が違うの？つまり、あなたの構造化された言語が実際にそれを強制できるプログラムによって解釈される場合を除いて。で、その強制システムを構築するのはかなり地獄のようになると思う。

2018年にコンプライアンスを証拠で自動化することについて少し書いたことがあるよ。[1] それが面白いと思う人もいるかも。 [1] "A Universal Lemma For Compliance" https://blog.eutopian.io/a-universal-lemma-for-compliance/

ドキュメントはコードの形であることがすべての最終目標だと思う。でも、乖離の問題は残るよね。私たちはすでに、日常的に触れているコードベースのドキュメントを現実と一致させるのに苦労している。ビジネスの側では、これらの関係を文書化する実用性を見つけるのがとても難しい。これは社会的な問題だから。一つ確かなのは、ビジネスの場で社会的な文脈を文書化するのは難しいってこと。例えば、みんなが避けるあの面倒なやつ。社会的には知られているけど、こういう複雑な関係は書けないよね。どちらにしても、最終的にはこのシステムに到達できたらいいなと思う。