コードとしての会社 – ダニエル・ロスマン著

先週、私たちの向かいに座っていたとき、 ISO27001 情報セキュリティ監査人が、私たちの文書に精力的に取り組んでいるのを見て、ある考えが浮かびました。

当社はソフトウェア会社であり、ほぼすべての業務が相互接続されたデジタル システムで実行されていますが、当社のビジネスの中核であるポリシー、手順、組織構造は、 基本的な 文書のコレクション。

それはただ皮肉なことだと感じました。当社は高度なツールを使用してコンプライアンスチェックを自動化し、コードをバージョン管理されたリポジトリに保存し、インフラストラクチャをコードとして管理します。しかし、私たちの会社を説明し、管理するときは、デジタルペーパーと、建物内の人々に配布されたちょっとした情報に頼っています。

私たちの日々のプロセスを振り返ると、その断絶がますます明らかになりました。当社の製品、文書、コミュニケーション、意思決定の 90% はデジタル チャネルで行われています。それはデータです。これはクラウド内に存在し、個々の作業プロセスの処理に特化した SaaS ソリューション (すべてのシステムが堅牢な API とプログラムによるアクセスを備えています) 上に広がります。

そのすべての中心には、私たちの野心、目標、方針、正式な構造といった文書の孤島が存在します。そして、それらはかなり重要だと思います。

ISO 27001 を検討する前から、お客様の要件に準拠するためにすでに懸命に取り組んでいたため、当社のセキュリティ体制は強固でした。統制のための証拠の収集、ポリシーの文言についての議論と更新、文書レビュー、そして実際の監査の間に、 さらに何百人時間も費やしました そうでなければ、ユーザーのための優れた製品の作成に費やせたはずです。

運用データがこれほど豊富であることを望むのに、なぜ組織データがそれほどまばらであることを受け入れるのでしょうか?私たちは、Infrastructure as Code (IaC) によるインフラストラクチャの処理方法、GitOps によるデプロイメントの管理方法、および Policy as Code によるセキュリティの処理方法に革命をもたらしました。

メリットがわかります。

しかし、私たちの組織 (業務の心臓部) を代表するときは、昔ながらの方法を適用します。

代わりに、組織構造全体をプログラムで表現できるとしたら、それは静的な画像ではなく、バージョン管理、クエリ、テスト、および自動的な検証が可能な、当社の生き生きとしたデジタル表現である場合を想像してみてください。ポリシーの変更をコードの変更として追跡でき、コンプライアンスを継続的に監視でき、人、プロセス、テクノロジー間の関係を明示的にマッピングして理解できるシステム。

HRIS システムなどの既存のソリューションは個人データを管理しますが、ポリシーとの関係に苦労しています。 GRC ツールはコンプライアンスを追跡しますが、組織構造と意味のある形で結びつくことはほとんどありません。私はもっと大きく考えようと提案しています。それは、全体的でプログラム的な表現を作成することです。 全体 組織: 組織構造、ポリシー、運営に関する唯一の真実の情報源として機能する「会社マニフェスト」。

これが次の場合にどれほど役立つかを考えてみましょう。

• コンプライアンス監査: 監査人は、さまざまなシステムからの証拠を手動でつなぎ合わせる代わりに、ポリシーとその実装の間の明確な追跡可能性を確保しながら、会社のマニフェストを直接照会できます。

• ポリシーの変更: アップデートはバージョン管理でき、自動化された影響分析により、どのチームやプロセスが影響を受けるかを示すことができます。

• 組織設計: リーダーは、構造変化を実装する前に「ステージング環境」で構造変化をモデル化し、変化が会社全体にどのような波及効果を引き起こすかをより深く理解できるようになります。

この考えが頭の中で渦巻いていると、答えよりも疑問の方が多くなります。

誰かこれをもう試したことがありますか?そうでない場合は、なぜそうではないのでしょうか?

組織は本質的にコードとして表現するにはあまりにも複雑かつ動的であるためでしょうか? もしそうなら、それは規制や基準と矛盾するように思えます。規制や基準では、企業活動は非常に統一的かつ手順的に行われ、準拠、非準拠、合法、違法のいずれかを確実に判断できると期待されています。

それは、適切な抽象化レベル、つまりシステム管理に対する Infrastructure as Code に相当するレベルがまだ見つかっていないためでしょうか?

組織の関係を表現するためのグラフ データベース、ビジネス ルールを記述するためのドメイン固有の言語、統合のための API ファースト アーキテクチャなどのツールと概念が存在します。

おそらく不足しているのは、これらのアイデアを、十分に強力で使いやすい方法でまとめるためのフレームワークです。

これがどのように機能するかを考えてみましょう。

このセクションでは、「Company as Code」に何を望むかを妄想してみます。次に、それらのニーズに対応できるいくつかのシステム コンポーネントにそれをマッピングします。

エンジニアおよびビジネス関係者として、私は企業モデルを次のようにしたいと考えています。

システムは、コードの依存関係の追跡と同様に、人、ポリシー、システム間の関係を追跡する必要があります。ユーザーは、ポリシーの影響を受けるユーザーやポリシーの所有者など、組織をさまざまな角度から簡単に確認できる必要があります。

組織の変更を、誰が変更したのか、何が変更されたのか、その理由を含めて、明示的に追跡します。これは、監査と組織の進化の理解にとって非常に重要です。

既存のツール (Azure、Slack など) とのシームレスなデータ交換により、最新の組織像を維持し、ポリシーに基づいてツール構成を適用します。

実装前に組織の変更をモデル化できる「ステージング環境」。個々のルールとコントロールの自動テストをサポートします。

コードを利用していますが、インターフェイスは技術者以外のリーダーにとっても効果的に使用できる直感的なものである必要があります。

このビジョンを実現するには、いくつかのパズルのピースが必要です。各コンポーネントは、比較的簡単に使用できながらも強力な機能を実現するために、特定の要件に対応する必要があります。

Terraform などのコードとしてのインフラストラクチャ ツールからインスピレーションを得て、形式的な構造を表現しながら自然に読み取る宣言型ドメイン固有言語 (DSL) を想像してみましょう。

基本的な構文は明確なパターンに従います。

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

タイプ、一意の識別子、および一連の属性によって各エンティティが定義されます。エンティティはドット表記を使用して相互に参照し、組織グラフを形成する関係の網を作成できます。

この言語で小規模なエンジニアリング チームを定義する方法を見てみましょう。

1. まず、組織内に存在する役割を定義しましょう。

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"
    ]
}

2. 次に、チームの組織単位を作成します。

OrganisationalUnit "EngineeringTeam" {
    Department = "Engineering"
    CostCenter = "ENG-001"
}

3. これらの構造を適切に配置すると、実際の人々とその関係を定義できます。

Person "AliceSmith" {
    FullName = "Alice Smith"
    Role = Role.EngineeringManager
    Unit = OrganisationalUnit.EngineeringTeam
    Email = "[email protected]"
}

Person "BobJohnson" {
    FullName = "Bob Johnson"
    Role = Role.SoftwareEngineer
    Unit = OrganisationalUnit.EngineeringTeam
    Manager = Person.AliceSmith
    Email = "[email protected]"
}

4. ポリシー定義により、コンプライアンスのフレームワークが作成されます。

PolicyGroup "SecurityPolicies" {
    Owner = Person.AliceSmith
}

PolicyRule "MFARequired" {
    Group = PolicyGroup.SecurityPolicies
    Enforcement = "Mandatory"
    ComplianceLevel = "Critical"
}

5. 最後に、これらのポリシーを外部要件にマッピングできます。

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]
}

この宣言的アプローチにより、ハイレベルな構造から個々のポリシーとその規制への影響に至るまで、組織の全体像を構築することができます。各定義は明確で自己文書化されており、エンティティ間の参照によって関係のグラフが作成され、分析、検証、および組織プロセスの自動化に使用できます。

このような表現を使用すると、定義を論理ファイルとディレクトリに整理し、組織の変更をコードの変更と同様に扱うことができ、適用前にバージョン管理、レビュー、検証を行うことができます。

これにより、組織構造の経時的な進化を追跡しながら、プル リクエストによる変更のレビュー、ロールアウト前のポリシー変更のテスト、コンプライアンス ドキュメントの自動生成などの実践が可能になります。

Terraform などのコードとしてのインフラストラクチャ ツールは、有向非巡回グラフ (DAG) と連携してデプロイ順序を決定しますが、組織の構造は本質的により相互接続されています。人は他の人を管理し、ポリシーはポリシーを参照するアクティビティを参照し、チームには複雑な相互依存関係があります。これには、これらの豊富な関係を表す無向循環グラフ モデルが必要です。

public record Node(
    string Id,          // e.g. "Person.AliceSmith"
    string Type,        // e.g. "Person", "PolicyRule"
    List Relations = null
);

public record Edge(
    string FromId, 
    string ToId,
    string RelationType, // e.g. "ManagedBy"
);

public class CompanyGraph
{
    private Dictionary _nodes = new();
    private List _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);
    }

    // Example: Find all requirements impacted by changing a policy
    public IEnumerable 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");
}

上の例は、宣言型 DSL に基づいたクエリ可能なグラフ構造の単純な実装を示しています。この表現により、「MFA ポリシーを変更するとどの外部要件が影響を受けるでしょうか?」など、構造内で複数の参照を必要とする質問に答えることが容易になります。

DSL は組織の構造とルールを定義できますが、モデルが役立つためには実世界のデータに接続されている必要があります。これには、次のようなストレージ戦略が必要です。

• 組織グラフ自体を永続化する

• グラフ エンティティに関連付けられたデータ (証拠など) を保存します

• 考慮された変更の検証を有効にする

これを大規模に実現する方法は、組織モデル用のグラフ データベース、関連データ用のリレーショナル データベース、監査証跡と変更追跡用のイベント ストアなど、複数のデータ ストアを組み合わせることです。小規模から始めたい場合は、代わりに、このすべての情報をローカル ファイルシステムにシリアル化することもできます。

外部データを有効にするには、組織モデルと実稼働システムの橋渡しをするプラグイン アーキテクチャを備えた統合フレームワークが必要です。これにより、次の 3 つの重要な側面が処理されます。(1) GitHub や Azure などの統合システムからのデータ収集。証拠をグラフ内のノードにマッピングします。 (2) 収集された証拠をルールに照らしてプログラム的にチェックするポリシーの検証。 (3) 組織の変更により、従業員のプロビジョニングからアクセス許可の変更まで、接続されたシステム全体の更新が自動的にトリガーされるポリシーの適用。

DSL は、他のシステムと対話するために必要な作業を実行するために、組み込みモジュールまたはユーザー提供のプラグインを使用してこの機能を提供します。カスタム スクリプトを使用して MFA の使用状況を定期的にチェックし、結果をコンプライアンス マッピングにリンクする DSL 内のコントロール エンティティを想像してみましょう。

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)
}

ソリューションは、その有用性を最大限に高めるためにオープンで拡張可能であり、カスタム統合、検証、自動化を可能にする必要があります。 Terraform は、「プロバイダーただし、企業システム内のデータを検査および変更するための統合では、より多くのカスタム スクリプトをサポートする必要がある場合があります。

このアプローチをテストしたい組織の場合は、小規模から始めることができます。

1. 組織構造とレポートラインだけをモデル化します。

2. 主要なポリシーとコンプライアンスのマッピングを追加します。

3. 最も重要なシステムへの接続を開始します。

組織のコードベースの宣言は、技術者に強力な機能を提供しますが、多くのビジネス関係者が「コードで考える」わけではないことも認識する必要があります。

DSL の優雅さは、テキスト エディターやバージョン管理ソフトウェアを使い慣れている人に限定される必要はありません。真にアクセス可能な「Company as Code」ソリューションは、プログラムによる表現と、組織構造、ポリシー、コンプライアンスについて日々の意思決定を行うビジネス ユーザーを接続する必要があります。

これは、次のようなローコード/ノーコード インターフェイスを使用して解決できます。

• ビジネスリーダー システムがバックグラウンドでコード宣言を生成している間に、組織エンティティとレポート構造をドラッグ アンド ドロップします。

• コンプライアンス責任者 シンプルなフォームを使用してポリシーを定義し、それがビジネスのどの部分に影響するかを即座に視覚化します。規制が変更されると、視覚的に強調表示することでギャップや矛盾を迅速に特定できます。

• 技術者 コードベースを整理し、外部システムにポリシーを実装するためのデータ統合とツールを提供します。

このようなアプローチにより、コード モデルの厳密さを維持しながら、誰でもアクセスできるようにすることができます。インターフェイスを介した変更により、基礎となるコードが更新され、バージョン管理と検証が可能な唯一の信頼できる情報源が維持されます。

技術的な実現可能性を超えて、真の期待は、より迅速な監査、より明確な意思決定、および実装前の変更の影響のより深い理解といった組織的なメリットにあります。 コンプライアンス文書に費やした何百時間も、代わりに価値の創造に投資することができます。

この投稿では、組織構造の成文化が次のとおりであることを確立したいと考えました。 ない そしてそれは 構築可能。実用的？わかりません。実行可能ですか？答えはありません。 でも、組み立て可能ですか？ はい。そうだと思います。

それについてどう思うか教えてください。

ダニエル・ロスマンが走る 42先物では、構造化されたソフトウェア パイロットを通じて、技術リーダーが一か八かの技術的決定を検証できるよう支援しています。