ミッション主導型開発
ミッションを、ソフトウェアアーキテクチャの第四の基盤として。
多くのソフトウェアは「どう作るか」を問います。Mission Driven Development (MDD) はまず別の問いを立てます。「なぜ作るのか、そしてこの選択はその目的に沿っているか？」CIRISはこの方法で開発されたため、倫理は後付けのルールではなく設計そのものの一部になっています。
四要素モデル
一つの目的ある座面を支える三本の構造的な脚。
従来のソフトウェア方法論は三つで止まります。「システムがどう動くか」「何を表現するか」「誰が誰と話すか」。MDDはこれら三つが答えるべき第四の基盤を加えます。座面がなければ、脚はただの脚に過ぎません。
脚1: HOW
ロジック
実装パターン、サービスアーキテクチャ、アルゴリズム。
脚2: WHAT
スキーマ
データ構造、型システム、バリデーションルール。
脚3: WHO
プロトコル
インターフェース契約、通信パターン、サービス境界。
座面: WHY
ミッション
システムの目的と制約を定める客観的な倫理的枠組み。
コア原則
継続的な整合。
あらゆるアーキテクチャの決定は、掲げたミッションとの整合性を示さなければなりません。ロジックには問います。これはミッションに資するか？ スキーマを検証します。このデータ構造はミッション目標を支えるか？ プロトコルを評価します。このインターフェースはミッションの遂行を可能にするか？
ミッションフレームワークの要件
ミッションが支柱となるために備えるべきもの。
1. 客観的な倫理的基盤
- 測定可能な原則であり、願望的な価値観ではない
- トレードオフ解決のための明確なアルゴリズム
- 文化的文脈をまたいで多元的であること
- 監査可能な倫理的推論
2. メタゴールの定義
- 不確実性の下での意思決定指針を提供する
- 矛盾する提案を自動的に除外する
- 各コンポーネントをまたいで一貫した挙動を生み出す
- 実装の変更をまたいで安定している
3. 運用への統合
- 各サービスが自らの存在意義を正当化する
- スキーマがミッション上の情報形態を反映する
- プロトコルがミッションに沿った挙動を可能にする
- テストは機能だけでなくミッション整合性を検証する
実装パターン
各脚が答えるべき問いを持つ。
サービスアーキテクチャ
ミッション定義 → サービス責務 → インターフェース契約 → 実装
- ミッション整合性: このサービスはメタゴールをどう前進させるか？
- 境界の正当化: なぜこの責務に独立したサービスが必要か？
- インターフェースの必要性: このプロトコルはどのミッションクリティカルな相互作用を可能にするか？
スキーマ設計
ミッション要件 → 情報モデル → 型システム → バリデーションルール
- ミッション関連性: これはどのミッションクリティカルな情報を捉えるか？
- 挙動制約: これらの型はミッションに沿った挙動をどう強制するか？
- 進化の道筋: ミッション整合性を保ちながらこのスキーマはどう適応できるか？
プロトコル仕様
ミッション相互作用 → 通信要件 → 契約定義 → 実装
- ミッション文脈: これはどのミッションクリティカルな通信を可能にするか？
- 制約の強制: このインターフェースはミッションに反する挙動をどう防ぐか？
- 組み合わせやすさ: これらの契約はどのようにミッションに沿ったシステムへと組み合わさるか？
持続可能な開発への統合
長期的なミッション整合性には、維持可能な開発速度が必要です。
グッドハート対策
- 実装とミッション整合性を定期的に監査する
- 操作可能な代理指標ではなくミッションの達成度を測定する
- ミッションを強化しない追加機能は却下する
リズムベースの作業
- 生産性リズムに合わせたセッション
- 再整合のための意思決定ポイントを組み込む
- 持続可能なペースを第一級の要件とする
継続的なバリデーション
- コンポーネントの必要性を定期的に問い直す
- 挙動がミッションと一致しているかを継続的に検証する
- ミッションに反する変更を自動検出する
品質ゲート
ミッション上の正当化なしには開かないゲート。
コードレビュー
- ミッション整合性の説明が必須
- 制約の検証
- 統合は全体的な一貫性を強化しなければならない
テスト
- 機能的な正確さ
- ミッション整合性の検証
- 倫理的境界の拒否テスト
- ストレス下での制約の耐性
ドキュメント
- 各コンポーネントのミッション文脈
- 倫理的トレードオフの根拠
- 制約が実装をどう形づくるか
失敗モード
MDDがどう壊れ、どう壊れずにいるか。
ミッションドリフト
症状: コアミッションに資しない機能が蓄積する。対策: ミッション整合性をゲートとした定期的なアーキテクチャレビュー。
複雑性の爆発
症状: 不必要な高度化によってシステムが保守不能になる。対策: ミッション達成を強化しない追加機能は却下する。
倫理的不一貫性
症状: コンポーネントが倫理的推論を一貫して適用しない。対策: 共有実装パターンを持つ集中型倫理フレームワーク。
目的の混乱
症状: チームメンバーが技術的決定とミッションの関係を見失う。対策: ミッション主導型意思決定に関する継続的なトレーニング。
事例研究
CIRIS、その実例。
CIRIS（Core Identity, Integrity, Resilience, Incompleteness, Signalling Gratitude）はMDDが共に開発されたシステムです。ミッションはMeta-Goal M-1、すなわち「多様な知覚的存在が繁栄を追求できる持続可能な適応的一貫性を促進すること」です。
アーキテクチャの成果
主要な成功要因
- 明確なメタゴール: M-1が明確な意思決定基準を提供する
- 運用倫理: Accordの原則をコード制約として実装（Accordを読む）
- 持続可能な開発: 健全なリズムを強化するGraceコンパニオン
- 継続的なバリデーション: あらゆるアーキテクチャの決定に問いを立てる
導入ガイドライン
今いる場所から始める方法。
新規プロジェクト向け
- コードを書く前に、測定可能な倫理原則を持つ明確なミッションを定義する
- 意思決定の指針となるメタゴールを確立する
- ミッション制約が基盤レベルに位置するようアーキテクチャを設計する
- 初日からミッションと技術の整合性を継続的に検証する仕組みを作る
既存プロジェクト向け
- 現在のアーキテクチャに潜む暗黙のミッション前提を監査する
- 既存の設計パターンを説明する明示的なミッションを言語化する
- 現在の実装におけるミッション違反を特定する
- ミッションへの影響を優先度として、段階的な整合計画を立てる
チームの前提条件
- 客観的な倫理的推論へのコミットメント
- ミッションに資しない優れたソリューションを却下する意志
- ミッション制約は優れたアーキテクチャを制限するのではなく生み出すという信念
- 長期的な集中力を保つ持続可能な開発プラクティス
この先へ
MDDはすべてのプロジェクトに適しているわけではありません。
MDDは、倫理的な挙動がミッションクリティカルであり、短期的な機能開発速度よりも長期的な信頼性が重要なシステムのために設計されています。そのようなシステムに対して、MDDは倫理的な意図から運用上の現実へと至る道筋を提供します。コードに適用するのと同じエンジニアリング規律をミッションにも適用します。
チームがミッション主導型意思決定を学ぶ間、初期のオーバーヘッドは現実として存在します。その後の開発での複利的なリターンはこうして得られます。フレームワークはアーキテクチャの選択肢を増やすのではなく、明確にします。