nwiizo
株式会社スリーシェイクのソフトウェアエンジニア。ブログ「じゃあ、おうちで学べる」を運営。趣味は読書、格闘技、グラビア。共訳書に『アーキテクチャモダナイゼーション 組織とビジネスの未来を設計する』（Nick Tune & Jean-Georges Perrin著）。nwiizoはインターネット上のハンドルネームであり親がくれた名前ではない。
開発組織において「技術的負債の解消」は永遠の課題です。しかし、技術的なアプローチだけで対処しようとすると、思わぬ落とし穴にはまることが少なくありません。
本記事では、3月に開催された「EM Conf 2026」におけるnwiizo氏のセッション「技術的負債の泥沼から組織を救う3つの転換点」の内容を一部再構成してお届けします。
「レガシーシステムが技術的負債を生み出し続ける悪循環を止めるには？」「負債解消に向けた投資の必要性を経営層にどう伝える？」といった現場の悩みに対処する際、重要になるのが技術・組織・学習文化の3軸からの実践的なアプローチです。
セッションでは、『アーキテクチャモダナイゼーション 組織とビジネスの未来を設計する』（翔泳社）を中心に、複数の関連書籍から得られる知見を活かしながら、負債解消を進める戦略が語られました。
なぜモダナイゼーションは先送りされるのか。技術的負債を再生産する構造的な問題
いわゆる「技術的負債」が技術だけの問題ではないということは、皆さんもお分かりだと思います。十分に管理されているアーキテクチャであっても、ビジネス戦略の変更や場当たり的な応急処置の積み重ねといった要因により、時間とともに劣化し、負債が溜まっていくのです。
そもそもなぜ技術的負債を解消することが難しいのでしょうか。
それは、アーキテクチャの「モダナイゼーション」にかかる短期的なコスト増を前に、多くのリーダーが躊躇するからです。本来ならプロダクトの機能改善に費やされるはずの時間や資金を、土台の刷新に回さなければならず、この投資を躊躇する間にレガシーシステムがさらなる負債を積み上げてしまうということです。将来的なモダナイゼーションのコストが増大し、それがまた次なる投資への躊躇を生むという悪循環に陥ります。
結果として「先送りすればするほど、先送りが合理的に見えてしまう」という強力な構造が出来上がり、競争上の致命的な不利益をもたらします。
この泥沼から脱却するためには、単なる技術の刷新を超えたアプローチが必要になるのです。
「玉ねぎモデル」で見る負債の性質
まず、負債が増え続ける構造をもう少し深堀っていきます。
レガシーシステムが開発速度を下げ、レビューが長引くと優秀な人から組織を去っていきます。人材の流出はさらなる開発速度の低下を招き、負のサイクルを生みます。しかしこの負のサイクルは技術だけでは断ち切れない。
書籍『Taming Your Dragon: Addressing Your Technical Debt』（Apress）によると、技術的負債は5つの層に分けられます。この層構造を「玉ねぎモデル」と呼びます。
表面から順に、コード品質やアーキテクチャの不整合といった「Technical（テクニカル）層」、人間が即時的・確実な利益を優先したことによる「Trade-off（トレードオフ）層」、組織構造の影響を受ける「Systems（システム）層」、利害関係者の対立が絡む「Economics/ Games Theory（経済学/ゲーム理論）層」があります。
そして最も深いところに「Wicked Problem（厄介な問題）層」があります。ステークホルダーごとに意見が分かれ、解決策が「正しい／間違い」ではなく、「好き／嫌い」「良い／悪い」で判断されるような問題です。
技術で解決できそうに見えて組織やプロセスに要因がある、という罠
技術負債を返済しようというとき、 本質的にどの層の課題に向き合っているのかを見極める必要があります。介入する階層を間違えると負債を再生産します。
最もよくある罠は「テクニカル層」への介入で解決できるように見えて、組織やプロセスの問題が技術の層に表出しているだけだった、というケースです。
2010年代後半に多く見かけた例は、「マイクロサービス化すれば負のサイクルを断ち切れる」という思い込みでした。マイクロサービス化の目的は本来、組織に「より高度な自律性」をもたらすことです。モノリスが最適な組織において、ドメイン境界、チーム構造、デプロイ戦略という観点を抜きにしてマイクロサービス化を進めると、かえって組織内の摩擦が増え、負債が再生産されることになります。
言い換えると、「組織を変えずにアーキテクチャだけ変える」というのは幻想で、組織設計はアーキテクチャ設計に等しいものであるべきということです。
ここで有効になるのがコンウェイの法則を逆手に取るアプローチです。
ご存知の通り、コンウェイの法則は「組織はそのコミュニケーションを反映したシステムを設計せざるを得ない」という考えです。これを無視したアーキテクチャを採用しようとすると、組織構造との摩擦が生まれ、技術を変えても負債が再生産されます。
これを逆手に取った「逆コンウェイ戦略」は、先に理想のアーキテクチャを描き、それに合わせて組織構造を変換する戦略です。
この「理想のアーキテクチャ」をどのように描き、移行するのか。これが今回のメイントピックです。
「技術構造・組織構造・学習文化」の3つの軸でアーキテクチャ改善の壁を捉え直す
はじめに、アーキテクチャをモダナイゼーションするときにぶつかりがちな3つの「壁」を整理します。
第1は技術だけでは解けないこと、第2に組織が構造的に変わらないこと、第3に人間が変化に対して抵抗することです。3つの壁が入れ子構造になっているため、1つを解いたとしても、残り2つが足を引っ張ってきます。これがモダナイゼーションの本質的な難しさといえます。
全ての壁を越えるには、技術構造・組織構造・学習文化の3つの軸を同時に動かす必要があります。ここからは、組織に3つの転換点をつくることで、モダナイゼーションを成功させる方法を紹介します。
転換点1 イネーブリングチームをつくり、自律的な学習を促す
事業がある程度成功して組織が環境に適応すると、業務の分業化やルーティン化が進みます。
その弊害として、従業員の思考の幅や質が制約され、「構造的無能化」が起こります。チーム間の壁ができてサイロ化が進む「断片化」、誰かの意思決定待ちになる「不全化」、「銀の弾丸」に頼って場当たり的な対応になる「表層化」という3つの症状が連鎖していきます。
そのため、組織が自ら学び、変わる力を引き出すための「触媒」が必要になります。
この触媒を担うのが「AMET（アーキテクチャモダナイゼーション・イネーブリングチーム）」です。活動はファシリテーションが中心で、Event Storming（イベントストーミング ※1）やWardley Mapping（ウォードリー・マッピング ※2）などの手法を組織に根付かせ、チームの自律と自走を促します。
※1 Event Storming…アプリのダウンロードやプロファイル構成、認証といった「ドメインイベント」を時系列に並べ、ビジネスフローの全体像を可視化するワークショップ形式の手法。
※2 Wardley Mapping…Simon Wardley氏が開発した戦略フレームワーク。ユーザーニーズを起点に、ビジネスを構成する各コンポーネントがどの程度進化しているかを可視化する。
チームの責務は以下の6つです。
1. キックスタート…最初のEvent Stormingを企画し、対話の場を設計する
2. モメンタム維持…Quick Wins（クイック・ウィン ※）と定期ショーケースで進捗を可視化
※ Quick Wins…短期間で確実に成果が出せる「小さな成功体験」。
3. 設計促進…チームが自ら設計できるよう、Event Storming、Wardley Mappingなどをファシリテート
4. 持続的変化…AMETなしで回る状態を目指し、学習サイクルを組織に埋め込む
5. ビジョン共有…「なぜやるのか」を全員が説明できることを目標に、技術者とビジネス側の共通言語をつくる
6. 学習共有…成功も失敗もドキュメント化し、横展開の仕組みをつくる
AMETの動き方は、まずステークホルダーにヒアリングして現状を把握する「準備」、次にEvent Stormingなど初回ワークショップを開催する「キックスタート」、そして、チームが自走するまでペアリングとファシリテーションを続ける「伴走」という流れです。そして、組織が手法を内製化したら解散します。
モダナイゼーションで最も難しいのは着手すること、2番目に難しいのは勢いを持続することです。従来の手法に逆らって進む以上、どうしても慣性が働いて元に戻ってしまいます。AMETは、社内のチームにこれらの手法を自分のものにしてもらい、彼らがイネーブリングチーム不在でもEvent Stormingを自発的に開催できる状態を目指します。
転換点2 投資すべきドメインを切り分け、経営層の意思決定に入り込む
学ぶ力をつけるだけでは組織は動かせません。そこで、経営層を含む上層部をどう動かすかという話になります。
留意すべきは、経営層は、ビジネスリスクが伝わらないと基本的に動いてくれないということです。「技術的負債があるので投資が必要です」と言っても予算は取れません。
そこで、「コードが複雑で保守が困難」「デプロイに3日かかる」「テストがない」といった技術的な問題を、「新機能のリリースが競合より数ヶ月遅い」「障害で数億円の損失がある」などとビジネスリスクに言い換えることが大切です。単に言い回しを変えるのではなく、放置すれば事業にどんな制約が生じるのかを示し、経営層が自らの判断軸で技術投資を評価できる構造をつくることが大切です。
このような“翻訳”に役立つのが「コア・ドメイン・チャート（Core Domain Chart）」です。これは、自社のドメインを「差別化度」と「複雑性」の2軸で整理し、どこに集中的に投資すべきかを可視化する道具です。チャートの縦軸が「自社の競争優位性にどれだけ貢献するか」という差別化の度合い、横軸が技術・ビジネスにおける複雑性を示します。
各象限における技術投資の方針は以下の通りです。
1. 「Core Domain」（高差別化・高複雑性）…集中的に投資すべき場所で、組織で最強のチームを布陣する
2. 「Supporting」（低差別化・高複雑性）…差別化の余地が無ければ技術的な「コア」にはなり得ないため、外注化やSaaSによる簡素化を検討する
3. 「Generic」（低差別化・低複雑性）…「車輪の再発明」を避けるためにSaaSやOSSで済ませる
Core Domainの選定において重要なのは、「技術的な差別化」が「顧客価値」と一体化しているかどうか、言い換えると、そのドメインへの投資により顧客の課題にどれほど深く応えられるようになるかどうか、です。
この「顧客価値」の本質理解に役立つのが、クレイトン・クリステンセン氏が提唱した「ジョブ理論」です。「顧客はプロダクトそのものを買っているのではなく、自分たちが抱える課題（ジョブ）を解決するためにプロダクトを“雇って”いるのだ」という考え方です。
この視点に立つと、開発の効率化で浮いたリソースを「まだ片付けられていないジョブの特定や定義」に充てることが真に重要なのだと分かります。
というのも、効率化には理論的な上限があるからです。AIによるコード生成、テスト自動化などによって効率化を推し進めたとしても、それ自体が目的化してしまえば、プロダクトの価値は単に「安くつくれること」に収束してしまいます。すると、顧客にとっての価値も表面的なものになり、プロダクトはやがてより安価な代替品に置き換えられてしまうでしょう。
AIが解決策の構築や作業の効率化を肩代わりしてくれる時代だからこそ、私たちはその先にある、未解決の顧客課題の発見に注力しなければなりません。そして、課題発見の価値や難しさについて、経営層に対して的確に伝えるコミュニケーション能力こそが、これからのエンジニアリングマネージャー（以下、EM）に求められる不可欠なスキルと言えるでしょう。
ドメインを適切に分けるための5つの基準
集中的に投資すべきCore Domainを特定したら、次に行うべきは「ドメインの境界をどこで引くか」の具体的な設計です。
ビジネス視点で重要な3つの境界（言語、ビジネスプロセス、データ）とEMが直接コントロールできる2つの境界（チーム、変更頻度）があります。
1. 言語の境界…「顧客」という単語が営業チームではリード、サポートチームでは契約者、課金チームでは請求先を意味するなど、同じ単語がチームによって異なる意味を持つ場所で分ける
2. ビジネスプロセスの境界…異なるライフサイクルを持つ業務で分ける
3. データの境界…異なるデータモデルが必要な場所で分ける
4. チームの境界…Team Topologiesの考え方に基づき、1チームが認知負荷内で管理できる範囲で分ける
5. 変更頻度の境界…デプロイ頻度をもとに、開発リズムの差に基づいて分ける
これら5つの指標を用いて適切に境界を引くことは、戦略的なCore Domainを担うチームが他の領域に引きずられることなく、独立してデプロイ・進化できる環境を整えるために不可欠なステップとなります。
転換点3 最重要課題から小さく始め、着実に拡大する
どこに集中投資すべきかを提示できたら、最後は実行です。 ここでは「戦略を間違えない」「バリューストリーム単位で動く」「具体的な始め方と進め方を定義する」「人と組織を動かす」という4つのポイントがあります。
1. 解くべき課題を見極め、戦略を立てる
書籍『戦略の要諦』の著者リチャード・P・ルメルト氏によると、実行に向けて良い戦略を立てるには、現状を正直に診断し、克服可能な最重要課題を見極めることが求められます。
多くの組織が陥りがちな罠は、「ミッションや願望」を「戦略」と混同することです。例えば「マイクロサービス化する」「AIで効率化する」「技術的負債を返済する」は手段であり、それ自体は戦略ではありません 。
まずはシステムが3年後に解くべき課題は何か、その障害となっている構造は何か、を問うことから始め、「どのシステムのどの部分が、どの事業判断を阻害しているか」を掘り下げましょう。
それができたら、戦略の実行単位を考えます。
2. 「バリューストリーム」単位で実行する
理想の単位は、成果がビジネス指標で測定でき、失敗しても影響が限定され、1つのチームが自律的に動ける範囲です。
ここでは、顧客への価値提供の流れを1つの単位として切り出す「バリューストリーム」という考え方が有効です。バリューストリームとは、未解決のユーザー需要の特定から始まり、ソリューション提供を経てニーズ解決の検証までを含む一連の活動を指します。
独立したバリューストリームには、ビジネスドメインの境界と一致している「ドメイン整合性」、他チームの承認なしに動ける「チーム権限」、ビジネス指標による「成果ベースの測定」、そして他のソフトウェアに影響しない「独立デプロイ可能」という、4つの特性があります。
ここで3つの転換点がつながります。
Event Stormingで可視化したビジネスフローが、バリューストリーム候補になります。Core Domain Chartで投資の優先度を決めたのち、そのバリューストリームを小さく選んで始めます。
3. 小さく始め、着実に成功させてから拡大する
戦略が見えたら、「Nail it, then Scale it（着実に成功させてから拡大する）」です。
まずは成功確率の高い、1つのバリューストリームから始めるのが大切です。いわゆる「パイロットプロジェクト」（新しい技術を組織全体に展開する前に、小さく試す実証プロジェクト）をつくり、最初の3〜6ヶ月で目に見えるアウトプットを出し、組織の信頼を築かなければ、2回目のチャンスは巡ってきません 。
最適なバリューストリームは次の4条件で選びます。
条件1：ビジネスインパクト
経営層が関心を持つ領域です。これを満たしていれば、プロジェクトが成功したとき、経営層にその意義を認められます。
条件2：チームの意欲
モダナイゼーションは新しい手法の学習を伴います。その負荷を引き受ける内発的動機が不可欠です。 「やらされる」チームでは成功しないため、手を挙げたチームを選ぶ必要があります。
条件3：技術的に切り出しやすい
依存関係が少なく、独立デプロイ可能な領域であることです。これを満たさず他チームとの調整コストが高い領域を最初に選ぶと、技術以外の問題で止まってしまいます。
条件4：学習価値
将来のモダナイゼーションを支援する知見が得られるか。単に成功を収めるだけでなく、次に活かせる学びを得ることもパイロットプロジェクトの重要な目的です。
選ぶバリューストリームは、必ずしも4つ全てを満たす必要はありませんが、チームの意欲だけは絶対的に必要な条件です。
バリューストリームを1つに決めたら、「Discovery（ディスカバリー）」「Design（デザイン）」「Execute（実行）」「振り返り」の4つのフェーズに分けて進めましょう。なかでも実行フェーズでは、旧システムを徐々に新システムで置き換える「締め殺し植物パターン（Strangler Fig）」と呼ばれる手法が有効です。細かくリリースを重ね、各ステップで学びを得ながら段階的に進めることが、リスクを最小化する鍵となります。
成果を出し続けるための「小さく長寿命」なチーム設計
このプロセスを支えるチームの設計もしなければいけません。目指すべきは互いに深い信頼関係を維持し、開発から運用まで一貫して意思決定の責任を持てる「小さく長寿命なチーム」です。
ここで注意すべきは、「長寿命」をメンバーの固定と混同しないことです。認知負荷の変化を正しく設計し、柔軟にチームを再編していくことこそが、持続的な進化には不可欠なのです。
具体的な手法として、チームトポロジーに基づき、ドメイン境界に合わせて「Stream-aligned」「Platform」「Enabling」「Complicated-subsystem」という4つの型でチームを設計します。ビジネス価値の提供に直接対応する「Stream-aligned Team」の認知負荷を、残り3つの型が軽減することが、組織全体の生産性向上の鍵となります。
また、チーム間の関わり方も重要な設計対象です。コラボレーションやXaaS、ファシリテーションといったインタラクションモードを適切に使い分けます。
4. 摩擦を解消し、人と組織を動かす
どんなに魅力的な提案であっても、変化には常に「摩擦（抵抗）」が伴います。組織を動かすには、無理に力で押し通すのではなく、「安心できる状況をつくる」という姿勢が重要です。
変化を阻む摩擦には4つの種類があり、それぞれに対応する「処方箋」が存在します。
1. 惰性（現状維持バイアス）
「ダメならやめればいい」という安全網を張ることで、惰性による現状維持を打破します。これは、チーム・サービス・スプリントを単位とした「小さな実験」で始めることで解消できます。
2. 労力（変化のコスト）
AMETが伴走し、新しい手法を一緒に学ぶことで学習コストを下げます。
3. 感情（否定的感情）
「レガシーを尊重する」ことが第一歩です。過去の仕事を否定せず、「これまで会社を支えてきたシステムを、次の10年のために進化させる」という言葉を選び、感情的な障壁を下げます。
4. 心理的反発（自律性への脅威）
「選択肢を与える」ことで解消します。「やれ」と押し付けるのではなく、複数の案から現場チームが「どう実現するか」を選べる構造にします。
変化への「抵抗」は、反対意見だけではありません。何も考えていない、感情がないという人も結構います。上記の4つの摩擦を理解したうえで、経営層との対話に臨み、安心してもらえる状況をつくりましょう。
まとめ：構造的な失敗を避けるために
アーキテクチャモダナイゼーションにおける失敗の多くは、技術の問題ではなく構造の問題に起因します。
特に、境界設計と組織設計を分離した瞬間、「コンウェイの法則」が働き、境界は元の組織構造へ引き戻されてしまいます。境界の正しさを測る唯一の基準は、各チームが他チームに依存せず自律的にデプロイできるかにあります。
組織に働く力学に抗いすぎず、組織と境界を同時に設計することが肝要です。「学ぶ→語る→始める」の順序を守り、アーキテクチャモダナイゼーションの失敗を構造的に捉えることで、不確実な環境下でも正しい意思決定を積み重ねていくことができるのです。
