🧠

どうすれば受託開発のプロジェクトは安定するのか ── Responsibility-Diffusion Development（RDD）

に公開
プロジェクトマネジメント
組織
ソフトウェア開発
idea

※本稿で論じるRDD（Responsibility-Diffusion Development）は、
一般的な設計手法である Responsibility-Driven Design
とは無関係の仮説的概念である。

要旨（Abstract）

本稿では、多層的協働構造を持つ開発プロジェクトにおける責任分散構造を、
仮想的な開発手法「Responsibility-Diffusion Development（RDD）」として定義する。
RDDは、関係者全体が局所的合理性に基づいて行動することにより、
結果として責任が拡散し、心理的安定が維持される構造的現象である。
その生成要因、運用形態、成果物の特徴、および制度的帰結を観察的立場から記述する。

1. 序論（Introduction）

RDD（Responsibility-Diffusion Development）は、
開発プロジェクトにおける責任の拡散過程をモデル化した仮説的構造である。
関係者全体としては責任を分散しているように見えるが、
実際には受注者側の現場層に負荷と責任が局所的に凝縮する。

この構造において、発注主体（顧客側）と受注側上位層は、
相互に責任を曖昧化することで心理的安定を確保する。
受注側下位層（現場）は、実務によってその均衡を維持する。
結果として、全体の安定は保たれるが、
責任は収束せず、労力のみが現場に局所化する。

2. 基本原理（Fundamental Principles）

RDDは、以下の原理に基づき形成される。

  1. 責任の分散（Responsibility Distribution）
    責任は形式的に全体へ分配されるが、意思決定権の欠如により実務層に凝縮する。

  2. 合意の遅延（Deferred Consensus）
    要件は常に「検討中」とされ、確定が回避される。
    再検討を繰り返すことで、決定の責任が恒常的に遅延する。

  3. 包括原理（Full Inclusion Principle）
    すべての要望を要件に包含することで、不採用判断を回避する。
    要件は指数関数的に膨張し、設計整合性は失われる。

  4. 形式による安定化（Formal Stabilization）
    内容よりも体裁が優先され、文書形式の統一が合意形成の代替として機能する。

3. コミュニケーション構造（Communication Structure）

RDDにおける会議体系は、責任分散を支える主要な相互認知構造（Mutual Recognition Structure）であり、
各会議はその中で機能する装置的要素（mechanism）として位置づけられる。
その目的は「決定」ではなく、「未決状態の共有」にある。

複数の会議体が同時並行的に開催され、
各会議では「誰もまだ決めていない」という共通認識が再確認される。
この手続きにより、個人単位での意思決定が防止される。

観察指標: 会議時間の総量が、生産的活動時間を上回るとき、RDDの機能は最大化される。

現場層においても同様の構造が観察される。
進捗会議は、遅延の是正ではなく、遅延の存在を制度的に承認する機能を果たす。
未確定要素は「確認します」と記録され、暫定対応が採用される。
これにより、手戻りが循環的に発生し、活動性が維持される。

さらに、上位層は「本人の意思確認」を名目として、
現場構成員に「間に合わせます」「対応します」という発言を促す。
この言質取得のプロセスが、実質的な責任移譲の儀式として機能し、
上位層の心理的安定を制度的に補強する。

4. 行動モデル分析（Behavioral Patterns）

RDD環境下の主要フェーズにおける行動様式は次の通りである。

フェーズ別行動様式

  • 要件定義フェーズ
    状態は恒常的に「検討中」であり、完了宣言は責任の発生要因とみなされる。
    これにより、要件定義フェーズは形式的に無限延長される。

  • 設計フェーズ
    複雑性を意図的に高めることで全体把握不能性を確保する。
    把握不能性そのものが説明責任の回避装置として機能する。

  • 開発フェーズ
    想定外の発生を防ぐことよりも、発生後に「想定していた」と説明できる状態を整えることが優先される。
    そのため、実際の利用価値よりも「考慮していた」ことを示すための機能追加が行われ、設計は過剰化する。
    問題発生時に「想定内」と言えることが、心理的安定を担保する。

  • UI/UX設計フェーズ
    利用容易性よりも包括性を優先する。
    すべての要望を取り込むことで実際の使い勝手は低下するが、
    誰の意見も排除されないことにより関係者間の均衡が保たれる。

  • 運用フェーズ
    冗長化をもって安定を保証する。
    ただし、その目的は実際の可用性向上ではなく、
    障害発生時に「対策は講じていた」と主張できる状況の確保にある。
    過剰な安全策が制度的な安心として正当化される。

5. 生成要因（Genesis of RDD）

RDDは個人の怠慢によって発生するのではなく、
制度的・構造的な要因により自然発生する。

発注側構造

  • 意思決定権限は名目的に保持されているが、実質的な統合機能は行使されない。
  • 部門最適が全社最適に優先される。
  • 決定可能な変数は「予算」と「納期」に限られる。
  • コンサルタントは助言者として介在するが、意思決定責任を負う構造には組み込まれない。

受注側構造

  • 問題指摘は契約上のリスク要因と見なされるため沈黙が最適解として選択される。
  • 売上の安定が倫理的善として再定義され、対立の回避が合理的行動として制度化される。
  • その結果、問題を指摘しないこと自体が合意の表明と見なされる構造が制度的に定着する。

6. 責任の重力構造（Gravitational Model of Responsibility）

受注側責任者は、発注者と現場の境界面に位置する。
上位からの成果圧力と下位からの支援要請が交錯し、
責任の総和が中間層に集中する。

この環境下では、「判断の保留」が最適戦略として選択される。
明示的決定を避けることで、上位への説明責任と下位への指示責任を同時に回避できるためである。
結果として、責任は下層へと沈降し、実装担当者が唯一の実働的当事者となる。

7. 責任分担モデル（RDDエコシステム）

RDDは、関係者がそれぞれの合理性を最適化する過程で、
外部調整なしに安定を維持する自己平衡的構造として成立する。

各層は固有の評価指標を基準として成果を定義し、
それぞれが形式的成功を記録する。

階層 成果の定義
発注者 命令の記録
担当部門 指示遵守の記録
受注責任者 売上確保の記録
プロジェクト責任者（PM） プロジェクト完了の記録

この構造により全体の安定が維持されるが、
その基盤には、現場層の疲弊が静かに沈殿している。

8. 改善提案の抑制構造（Inhibitory Mechanism）

改善提案は論理的に正しいほど採用されにくい傾向を示す。
提案は計画体系の再定義を伴い、責任の所在を揺るがすためである。
このとき、提案の合理性そのものが既存均衡を乱すノイズとして扱われ、
組織は「誰も責任を負わない状態」を維持する自己防衛的構造を形成する。

9. 非機能要件の制度的運用（Operational Dynamics of Non-Functional Requirements）

非機能要件の明示は責任確定を誘発するため、
多くの場合未定義のまま維持される。
性能試験の判断基準は都度再解釈され、
曖昧であるほど責任が均質化する。

運用段階で問題が顕在化した場合、
最も低リスクな対応としてクラウドリソースの追加投入が選択される。
原因分析を伴わない可視的対処が、制度的沈静化装置として機能する。

10. 成果物分析（Artifact Analysis）

観点 状態
構成 要件集積により構造的複雑性が自己増殖する。全体把握主体は不在。
コード品質 属人的・応急的傾向を強め、リリース時点で長期運用疲弊に類似。
ドキュメント 意図的難読化により誤謬検出コストを上昇させ、参照不能化する。
責任 問題発生時、弱い立場の層が最終責任を吸収する。
納期 初期固定化により変更困難。恒常的遅延が安定状態として受容される。
コスト 全支出が必要経費として自動正当化され、検証は行われない。
利用者満足度 指標が定義されず、存在しない利用者によって安定が保証される。

11. 構造的帰結（Structural Outcomes）

RDDの最終段階では、形式上の成果物が存在し、
表面的には完了状態が観測される。
しかし、その実態は以下のような帰結を伴う。

  • システムは稼働するが、動作原理を理解する者がいない。
  • 保守コストは上昇し、変更は凍結される。
  • クラウド請求額が単調増加する。
  • 担当者離脱により知識継承が断絶し、全容把握主体が消失する。

12. 考察（Discussion）

RDDは、SSOTやRACIといった一貫性モデルを制度的に排除することにより成立する。
目的は成果の追求ではなく、非難回避による持続的安定である。
目的関数が「成功」から「安全化」へと変質し、
意図の欠如自体が最も安定した状態として最適化される。

この構造は、目的の喪失を通じて存続を保証する、
負のフィードバック型安定系として定義できる。

13. 対照モデル：責任収束構造（Responsibility Convergence Model）

RDDは責任と情報の分散により成立する。
その逆位相として、責任を収束させる構造をここでは対照モデルと呼ぶ。
これは新しい手法ではなく、「当たり前を維持する構造」を再定義したものである。

以下に、その主要な構成原理を示す。

  1. 責任の明示化（RACIモデル）
    決定権限と実行責任を分離し、最終判断者を明確化する。
  2. 決定ログの定常化
    すべての会議を「決定／却下／保留」の三相で記録し、循環的議論を断つ。
  3. DoR（Definition of Ready）の制度化
    不確定状態での着手を禁止し、プロセス境界を明文化する。
  4. 変更管理の一元化
    仕様変更の決定経路を一点に集中させる。
  5. 情報一貫性の確立（SSOT）
    判断・仕様・データを単一の真実源から再帰的に更新する。
  6. コストと品質の透明化
    上限値を設定し、自動正当化を防ぐ。

対照モデルとは、分散した責任を一点に再集束させる重力中心の再構築行為である。

14. 結論（Conclusion）

RDDは、

責任を分散し、意思を曖昧にし、安心を最大化する開発構造

として定義される。

この構造は、現場層による責任吸収を基盤として維持され、
その層が縮小・消滅することで、責任自体が自然消滅する。
結果として、組織は完全な心理的安定を獲得し、
外形的には成熟した開発プロセスのように見える。

最終的に、RDDは自己再生的に次のRDDを生成する。
それは、人ではなく構造が意思を代理する状態として持続する。

本稿で描かれる構造は架空のものであり、もし類似の現象が実在する場合、それは純然たる偶然である。

Discussion