**コードとしての会社**

先週、ISO 27001 情報セキュリティ監査員と対面している席で、彼らが私たちの文書を熱心に精査する様子を見ていたとき、一つ思い立ったことがあります。

ここまで来れば――ほぼすべての業務が相互接続されたデジタルシステム上で動いているソフトウェア企業――私たちのビジネスの核心（ポリシー、手順、組織構造）は、基本的に一連の文書に過ぎない。そう考えると皮肉がこみ上げてきました。

コンプライアンスチェックを自動化する高度なツールや、バージョン管理されたリポジトリでコードを保管し、インフラをコードとして管理しています。しかし、会社の説明・運用に関しては、デジタルペーパーと建物内に分散した情報の断片に頼っています。

日々のプロセスを振り返るうちに、このギャップはますます明らかになりました。製品や文書、コミュニケーション、意思決定の90 %がデジタルチャネルに存在し、それはデータです。それはクラウド上にあり、個別の業務プロセスを扱う SaaS ソリューションに分散しており―すべて堅牢な API とプログラム的アクセスを備えたシステムです。

その全ての中心には、孤立した文書群が存在します。そこに「私たちの野心」「目標」「ポリシー」「正式構造」が記されています。そしてそれらは非常に重要だと私は考えます。

ISO 27001 を検討する前から私たちのセキュリティ姿勢は堅固でした。既に顧客要件への準拠を実現すべく努力していたからです。コントロール証拠の収集、ポリシー文言の議論・更新、文書レビュー、そして監査そのものといった作業で、別途数百時間を費やしましたが、それらは本来ユーザー向けに素晴らしい製品を開発するために使える時間だったのです。

操作データがこれほど豊富なら、組織データをこんなにも希薄に扱う理由は何でしょうか？インフラは IaC（Infrastructure as Code）で革新し、デプロイは GitOps で管理し、セキュリティは Policy as Code で対処しています。そのメリットは分かります。しかし、組織そのもの―運営の鼓動を表す―には古典的手法しか適用していません。

---

組織全体をプログラム化した表現を想像してください

「会社マニフェスト」――組織構造、ポリシー、業務の単一真実源として機能するものがあれば：

• コンプライアンス監査：さまざまなシステムから証拠を手作業で集める代わりに、監査人は会社マニフェストを直接クエリでき、ポリシーとその実装とのトレーサビリティが明確になります。
• ポリシー変更：更新はバージョン管理され、自動影響分析でどのチームやプロセスに影響が出るかを示せます。
• 組織設計：リーダーは「ステージング環境」で構造変化をモデル化し、変更が会社全体に与える波及効果を事前に把握できます。

---

現状のギャップ

HRIS システムは人員データを管理しますが、ポリシー間の関係性には苦手です。GRC ツールはコンプライアンスを追跡しますが、組織構造との有意義な結びつきはほとんどありません。私たちは、非技術的なリーダーでも使えるシンプルで強力な 「Company as Code」 フレームワーク―全体像をプログラム化した表現―が必要です。

---

「Company as Code」で求めること

• 人員・ポリシー・システム間の関係性をトレーサビリティで追える
• さまざまな視点（例えば、あるポリシーに影響を受ける人々とその所有者）から組織を見ることができる
• 組織変更を明示的に記録し、誰が何をいつ変更したかを追跡
• Azure や Slack など既存ツールとのシームレスなデータ交換で常時最新の図を保ち、ポリシーに基づく設定を自動化
• 実装前に組織変革をモデル化できる「ステージング環境」―個別ルール・コントロールの自動テストも可能
• 非技術的リーダーが直感的に操作できるインターフェース

---

仕組みイメージ

Terraform のような IaC ツールからインスパイアされた、宣言型 DSL（Domain Specific Language）を想定します。自然に読めつつ形式化された構造を表現できます。

基本構文

EntityType "Identifier" {
    References = AnotherEntity.Identifier
    Attribute   = Value
    ListAttribute = [
        "Item One",
        "Item Two"
    ]
}

例：役割の定義

Role "SoftwareEngineer" {
    Responsibilities = [
        "Write clean, maintainable code",
        "Participate in code reviews",
        "Document technical decisions"
    ]
}

Role "EngineeringManager" {
    Responsibilities = [
        "Provide technical leadership",
        "Conduct performance reviews",
        "Manage team resources"
    ]
}

組織単位

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 は高レベル構造から個々のポリシー、規制への影響までを網羅します。各定義は自己文書化され、参照が関係グラフを形成。分析・検証・組織プロセス自動化に利用可能です。

---

基本データモデル

C# での簡易実装例：

public record Node(
    string Id,
    string Type,
    List<Edge> Relations = null);

public record Edge(
    string FromId,
    string ToId,
    string RelationType);

public class CompanyGraph
{
    private readonly Dictionary<string, Node> _nodes = new();
    private readonly List<Edge> _edges = new();

    public void AddNode(string id, string type) =>
        _nodes[id] = new Node(id, type);

    public void AddRelation(string fromId, string toId, string type)
    {
        var edge = new Edge(fromId, toId, type);
        _edges.Add(edge);
        (_nodes[fromId].Relations ??= new()).Add(edge);
        (_nodes[toId].Relations ??= new()).Add(edge);
    }

    public IEnumerable<Node> GetImpactedRequirements(string policyId) =>
        _nodes[policyId].Relations
            .Where(e => e.RelationType == "ImplementsRequirement")
            .Select(e => _nodes[e.FromId == policyId ? e.ToId : e.FromId])
            .Where(req => req.Type == "ExternalRequirement");
}

このグラフ構造により、ポリシー変更時に影響を受ける外部要件を簡単に特定できます。

---

ストレージと統合

スケールアップには：

• グラフデータベース：組織モデル
• 関係データベース：証拠・メタデータ
• イベントストア：監査ログ・変更追跡

スタートアップ規模なら、すべてをローカルファイルにシリアライズしても十分です。

統合はプラグインアーキテクチャで実現：

1. GitHub や Azure などからデータを収集し、証拠をノードへマッピング
2. ポリシーをプログラム的に検証
3. ポリシー違反を検知したら関連システム（従業員プロビジョニング、アクセス権）を自動更新

監視コントロール例

Control "MFAMonitoring" {
    Implements = ComplianceMapping.MFACompliance
    
    Verify {
        Script   = "Security/mfa-checks.js"
        Methods  = [ "allUsersHaveMfaEnabled" ]
        Frequency = "Daily"
    }
}

security/mfa-checks.js

export async function allUsersHaveMfaEnabled() {
    const users = await myAuthClient.listUsers();
    return users.every(user => user.mfaEnabled);
}

---

アクセシビリティを高める

ローコード／ノーコードインターフェースで、コードとビジネスユーザーのギャップを埋めます。

• 経営層：組織エンティティや報告構造をドラッグ＆ドロップし、背後でコード宣言を生成
• コンプライアンス担当者：簡易フォームでポリシーを定義し、即座に影響範囲を可視化。規制変更時には矛盾やギャップをハイライト
• 技術者：コードベースを整理し、データ統合・外部システムへの実装を担当

インターフェース経由で行われるすべての変更は基盤となるコードへ反映され、単一真実源としてバージョン管理・検証が可能です。

---

期待できる価値

技術的に実現可能かどうか以上に、本当に得られるのは組織面での恩恵です：

• 監査時間の短縮
• 意思決定の透明性向上
• 変更影響を事前に把握できる ＝ 実装リスク低減

コンプライアンス文書作成に費やす数百時間を、ユーザー価値創造へ投資できます。

---

この投稿で示したかったこと

組織構造のコード化は未だ存在しないが、実際に構築可能であるという点です。実用性は未知ですが、ビルド可能性には間違いありません。

ご意見をお聞かせください。

Daniel Rothmann は 42futures を運営しており、技術リーダーが高リスクの意思決定を構造化されたソフトウェアパイロットで検証できるよう支援しています。