「理想の設計」が本番環境で崩壊するのはなぜか：開発組織が「機能不全」に陥る理由

システム設計理論や最新手法を導入しても、実際の現場では運用が混乱し、設計と実装の間に溝が生まれる。完璧に見える組織でも、なぜ泥臭い問題が発生するのか。トップアーキテクトが明かす組織改革の処方箋とは。

[TechTargetジャパン]

　システム設計の理論やモダンなプラクティスを導入しても、なぜ実際の開発現場では運用が混迷し、設計書とソースコードのが生じてしまうのか。IT担当者やアーキテクトは、この「現場の現実と理論のギャップ」に悩まされている。

　グローバルな技術カンファレンス「GOTO Copenhagen 2025」にて、トップアーキテクトたちが「組織の機能不全とどう付き合うか」「AI時代における意思決定と変革のアプローチ」をテーマに議論を交わした。現場の停滞を破り、実用的なアーキテクチャを築くための思考法を整理する。

組織の「機能不全」を前提としたアーキテクチャ設計

併せて読みたいお薦め記事

開発現場の改善

• プラットフォームエンジニアリングが「“何でも屋”にされる開発者」を救う
• リーダーの時間を奪う「無駄な作業」　手戻り地獄から抜け出せない理由

　本稿はセッション「Every Software Org is Dysfunctional」で交わされた議論を基に構成する。モデレーターを務めたレベッカ・パーソンズ氏は、アジャイル開発の草分けとして先進的なDX（デジタルトランスフォーメーション）支援やエンジニアリングサービスを展開するグローバルITコンサルティング企業Thoughtworksの名誉CTO（最高技術責任者）だ。

　セッションでは、現場の組織課題に関する問いに対し、登壇者からはエンジニアが直面する本質的な回答が示された。

　Thoughtworksで技術主導の組織変革を担うテックプリンシパルのアンドリュー・ハーメルロー氏は、ドキュメントやWikiに示されたアーキテクチャと、本番環境で稼働するソースコードの間に著しい隔たりが生じる現状を指摘する。「設計思想がソースコードとして実装され、本番運用からのフィードバックを基に改善されるサイクルが回らなければ、理想の設計とシステムの実態は容易に懸け離れてしまう」と同氏は述べる。

　グローバル企業でCTOやIT変革アドバイザーを務めるグレゴール・ホープ氏は、「完璧な状態の組織など存在せず、時代に応じて常に変化し続ける以上、どの組織も何らかの機能不全を抱えるのが自然だ」と説明する。その上で、アーキテクトの役割はきれいなターゲット像を描くことだけではなく、現場の制約や構造を深く理解することにあると主張する。同氏は、日常のシステム開発のような「短期の改善サイクル」と、組織構造を変える「中長期の改革サイクル」という、スピードの異なる2つの時間軸を並行して回す必要性を説く。

　システム設計のアドバイザリーや教育を手掛けるBlack Tulip Technologyを設立したバリー・オライリー氏は、「ソフトウェアを構築する全ての組織は機能不全だ」と明確に述べる。理屈通りに動くシステムの世界に慣れたンジニアにとって、非論理的で不確実な「人間の組織」は機能不全に見えてしまうと指摘する。同氏は「組織の泥臭さを排除しようと抵抗するのではなく、それを避けられない現実として捉え、不確実な組織の中でも機能し続けるアーキテクチャを築くべきだ」と説く。

非決定論的なAI時代における意思決定と境界線

　AI機能やLLM（大規模言語モデル）をプロダクトに組み込む際の評価軸やリスク管理についても議論が及んだ。

　パーソンズ氏は、エンジニアがCOO（最高執行責任者）や法務責任者などのビジネスリーダーに対して、AI技術のリスクや費用対効果を説明する際の姿勢を強調する。単に最新のアーキテクチャを語るのではなく、データ漏えいリスクや法的な賠償可能性といった「ビジネス言語」に翻訳して説明することこそが、適切な意思決定を引き出す鍵になるという。

　「LLMのような本質的に非決定論的な（同じ入力に対して同じ結果が出力されるとは限らない）技術をプロダクトの中心に据える際、従来通りの決定論的な発想を切り替える必要がある」とハーメルロー氏は述べる。一度に大きな意思決定をするのではなく、小さな決定を重ねてフィードバックを得るアプローチが、不可逆な失敗を防ぐ手だてになる。

　オライリー氏は、若手アーキテクトが直面するストレスの大半は役割の曖昧さから生じていると指摘する。同氏は、「ビジネス側の意思決定と技術側の意思決定の境界線を明確に引き、過度な責任を抱え込まないようコントロールすることが重要だ」と主張する。

変化に抵抗する組織をどのように動かすか

　セッションでは、組織の変革や新しい取り組みに対して生じる「抵抗」について、実践的な知見が共有された。

　ホープ氏は、人々が変化に抵抗する主な理由は「過去に新しい試みで不具合が生じたリアルな体験」を持っているからだと分析する。現場が変化に抵抗する背景には、「かつて金曜日にデプロイを実施したせいで、週末返上で復旧作業に追われることになった」などの生々しい“苦い実経験”がメンバーにあるからだと説明する。「言葉で説得しようとするのではなく、実際に動く成果を出して見せる姿勢で証明する姿勢が大切だ」と同氏は強調する。

　ハーメルロー氏は、組織の人間関係や動態をじっくり観察し、最も小さな労力で大きな変化を生み出せる要所（レバレッジポイント）を見つけることの重要性を説く。小さな実験を繰り返し、組織に過度な負担をかけずに成功パターンを証明していくアプローチを推奨している。

　オライリー氏は、炎上したプロジェクトを立て直す際のアプローチとして、開発メンバーを日常業務や社内政治といった「現場の雑音」から一時的に引き離し、別の環境で正しいコラボレーションや設計思考をトレーニングしてから現場に戻す手法が有効だと解説する。

　組織の人間的な不確実性やAI技術をはじめとする新技術の非確定性を受け入れ、完璧な計画よりもフィードバックループと小さな実証を繰り返す姿勢こそが、これからのIT担当者やアーキテクトに求められている。

本稿は、Triforkが2026年3月9日に公開した動画「Every Software Org is Dysfunctional・R. Parsons, G. Hohpe, B. O'Reilly & A. Harmel-Law・GOTO 2025」を基に作成しました。