内製アジャイル開発がJTCに根付く日

外注開発から内製化に転換しアジャイル開発手法も導入したのに、なぜ現場は楽にならず、成果も出にくいのか。JTCに内製アジャイル開発が根付かない理由は、技術的な手法ではなく組織的な「適応課題」にあります。組織の文化的構造からひもとき、現実的な突破口を探ります。

「技術問題」ではなく「適応課題」として考える

近年、多くのJTC（Japan Traditional Company：伝統的日本企業）でも「内製化」や「アジャイル開発」という言葉が語られるようになりました。内製によるアジャイル開発は変化の激しいビジネス環境において、素早く顧客価値を実現したシステムをリリースするための優れた開発手法です。

しかし開発現場を見渡すと、重要なIT開発をわざわざ内製化したはずなのに事業に貢献できていなかったり、アジャイルを導入したにもかかわらずスピードや品質が思ったほど向上しなかったり、最終的には「やはりウォーターフォール開発に戻そう」という議論が繰り返されたりする光景をよく目にします。

この記事では、JTCにおける内製アジャイル開発導入のつまずきを段階的に整理します。そのうえで、それが単なる開発手法の選択ミスではなく、より深い構造的ないわゆる「適応課題」としての問題であることを明らかにし、現実的な突破口を考えてゆきます。

ここでの議論は、JTCの在り方を否定するものではなく、むしろその歴史的前提を踏まえたうえで、現実的に前進する道を探る試みとしてご覧ください。

第1段階の課題：企業戦略とITの距離を詰める

戦略とITが分断されてきた構図

これまで多くのJTCでは、「経営が戦略を考え、IT部門はそれを裏方として支える」という分業構造が前提とされてきました。しかし、デジタルが事業価値そのものになる現在、この構図はもはや成立しません。

企業戦略を実現しようとすれば、何らかの形でITシステムが必ず関与します。戦略の中にITが含まれていないという状態自体が、すでに不自然なのです。それにもかかわらず、経営とITの間には心理的・組織的な距離が残り続け、戦略と実装が別物として扱われてきました。

外注中心モデルが生んだ「契約という壁」

この分断をさらに強めてきたのが、外注中心の開発モデルです。
専門的能力を持つITベンダーによる外注開発は効率的で合理的な選択に見えますが、その一方で、戦略とIT実装の間に「契約」という明確な境界線を引いてしまいます。

結果として、経営の意思決定と現場の実装が断絶し、システムは「要求仕様を満たすもの」にはなっても、事業の変化に寄り添い続ける存在にはなりにくくなります。言い換えれば、システムに魂が宿らない状態が常態化してきたのです。

内製×アジャイルという解決策

こうした課題の解決手法として注目を浴びてきたのが、内製開発とアジャイル開発の組み合わせです。
内製化によって戦略とITの距離を縮め、さらにアジャイル開発によって、リリースを早め価値を中心に据えた改善を継続的に行います。この方向性自体は、きわめて理にかなっています。

内製化が進めば、経営層・事業部門・開発部門が同じ文脈や物語を共有するようになります。経営の意思決定とIT実装が分断されるのではなく、一貫した「ひとつの物語」として事業が進んでいくことになります。この状態こそが、多くの企業が目指している姿でしょう。

第2段階の課題：内製化しても、なぜアジャイルはうまくいかないのか

ウォーターフォール開発は「悪」なのか

内製化が進むと、次に必ず浮上するのが「ウォーターフォールとアジャイル、どちらがよいのか」という議論です。
現実には、「外注よりは、内製ウォーターフォールの方がまだ良い」という評価が出ることも少なくありません。工程や品質が管理しやすく、既存の仕事のやり方とも乖離が少ないからです。

ただし、ウォーターフォールには構造的な弱点が少しあります。リリースまでに時間がかかるため、その間にビジネス環境が変化してしまう場合があります。また、利用者価値の検証が最後に回るため、価値のポイントがずれていた場合の修正コストが非常に大きくなります。いわゆる「ビッグバンリリース問題」が、何度も繰り返されるのです。

それでもアジャイル開発が機能しない理由

一方で、アジャイルを導入しても、期待したほどの成果が出ないケースも多くあります。開発スピードや品質が思うように向上せず、むしろ報告や管理の仕組みが増えてしまうことすらあります。チームは自律的に判断して進んでいるように見えず、どこかもたついた印象を与えます。

こうした状況が続くと、「やはりウォーターフォールの方が現実的なのではないか」という声が強まり、議論は次第に宗教戦争の様相を帯びていきます。

問題の構造①：表層の原因 ― 権限委譲ができていない

スクラムのフレームワークを導入する、CI/CDツールを整える、といった技術的なアプローチは十分に実施されているのにも関わらず、アジャイル開発が機能しない場合があります。

その大きな要因は、必要な権限の委譲が実際にはできていないことにあります。
経営層や管理層は、無意識のうちにマイクロマネジメントを行い、開発チームに十分な判断権限を与えていません。

しかし問題はそれだけではありません。開発チーム自身も、権限を委譲されることを必ずしも歓迎していないのです。報告・連絡・相談を重視する文化が染みついており、自分たちで判断し、その結果に責任を持つことに心理的な抵抗があります。これは意識的というより、無意識レベルで発生しているJTC的な行動様式だと思います。

（なお、権限委譲はアジャイル開発の必要条件ではありますが、それだけで自動的に成果が出る十分条件ではありません。権限を任せた先に、目的・価値・判断基準が共有されていなければ、単なる放任や混乱に変わってしまいます。）

問題の構造②：日本企業の雇用と成長の歴史

この問題の過程的な背景として、日本企業の雇用制度があります。
JTCでは、メンバーシップ型・終身雇用を前提に、人を管理しながら育てるという考え方が長く続いてきました。権限は一気に与えられるものではなく、上位職との密な連携の中で、段階的に委譲されていくものです。

一方、欧米企業ではジョブ型雇用が一般的で、職務定義が明確にされ、最初から一定の権限を与えて仕事を任せる文化があります。アジャイル開発は、この後者の前提と非常に相性が良い手法です。

つまり、日本型雇用の文脈でアジャイル開発を導入すれば、摩擦が起きるのは当然だと言えます。

問題の構造③：「技術課題」ではなく「適応課題」

ここで重要なのは、この問題を「アジャイル手法が悪い」「やり方を工夫すれば解決する」と捉えないことが必要です。

この問題は、技術課題ではなく適応課題に分類されます。

適応課題とは、単に正しい答えや手順を適用すれば解決する問題ではなく、人々の価値観、役割意識、責任の引き受け方そのものが変わることを求める課題を指します。ハーバード大学のロナルド・ハイフェッツ氏が提唱した概念として知られていますが、要点はシンプルです。

• 技術課題：
  専門知識や手法を適用すれば解決できる問題
• 適応課題：
  人や組織が「どう考え、どう振る舞うか」を変えなければ解決しない問題

JTCにおけるアジャイル開発の導入は、まさに後者がポイントになります。
スクラムのフレームワークを導入する、ツールを整える、研修を増やすといった対応は、すべて技術課題へのアプローチにとどまります。しかし、権限を委譲することへの不安、失敗に対する恐れ、責任の所在を曖昧にしてきた慣行といったものは、手順では解消できません。

たとえば、
「現場に任せるべきだと頭では理解しているが、いざとなると口出ししてしまう経営層や管理職」
「判断していいと言われても、失敗したときに守られる保証がなく、結局上に確認してしまう現場」
こうした行動は、合理性ではなく、企業文化に基づく長年の経験から形成された無意識の行動様式に根ざしています。

そのため、アジャイル開発を「正しく説明する」だけでは不十分であり、組織として「どこまで任せるのか」「失敗をどう扱うのか」という前提そのものに向き合う必要があります。
ここを気づいて直視しない限り、内製アジャイル開発は形だけのものになり、うまくいかない理由を永遠に探し続けることにななってしまいます。

解決の方向性：「適応課題」を「技術課題」に分解する

適応課題は、一気に解決できるものではありません。
しかし、それを扱いやすい技術課題に分解することで、現実的に前進することは可能です。

この考え方をうまく体現しているのが、AWSが提唱してきた「ガードレール（Guardrails）」という発想です。

AWSでは、少人数で自律的に動くチーム（いわゆるツーピザチーム）が高速に価値を生み出すことを重視します。一方で、完全に自由にしてしまえば、セキュリティ事故やコスト超過、ブランド毀損といったリスクが現実化します。
そこでAWSは、「細かく管理する」のではなく、「超えてはいけない境界線を明示する」という方法を取ります。これがガードレールです。

具体的には、以下のような考え方です。

• セキュリティや法令遵守など、絶対に守るべき領域は自動的に制御する
• コストやリソース利用には上限やアラートを設ける
• それ以外の部分は、チームに裁量を与えて任せる

重要なのは、ガードレールが「管理を強める仕組み」ではなく、「管理を減らすための仕組み」であり「現場が自律的に判断し実行能力を高める仕組み」だという点です。
境界線の内側であれば、逐一の報告や承認は不要になります。

JTCにおける内製アジャイル開発でも、同じ発想が応用できます。
たとえば、技術的リスクや影響範囲、コスト変動の許容幅、顧客やブランドへの影響などを事前に定義し、その範囲内であれば現場の判断に委ねる、といったルールを設けること、あるいはUI変更は小規模なABテストに限定すること、といったルールがガードレールになります。

さらに、報告を増やすのではなく、ダッシュボードによって状況を常時可視化することも重要になります。状況は見えるが、逐一口出しはしない。これは、信頼と不安のバランスを取るための、きわめて現実的なアプローチです。

ここで重要点は、こうした仕組みの背景にある価値観を言語化し続けることです。
「なぜ任せるのか」「どこまでが許容される失敗なのか」を共有しなければ、ガードレールは単なる新しい管理ルールになってしまいます。

適応課題そのものは最後まで消すことはできないかもしれません。しかし、これらをガードレールによって技術課題に分解することで、組織は少しずつ前に進むことができるはずです。

（勿論、ガードレールは組織文化や価値観の問題を一気に解決する魔法の仕組みではありません。あくまで不安や摩擦を減らし、試行錯誤が可能な状態を「一時的につくるための装置」だと捉える必要があります。）

ガードレール設計の簡易例（JTC向け）

以下は、JTCにおける内製アジャイル開発を想定した、非常にシンプルなガードレール設計例です。
重要なのは「細かく管理すること」ではなく、「超えてはいけない境界線だけを明確にする」ことです。

この表は「何を守るか」と「何を任せるか」を明確に分けるという考え方の例を示しています。
チームはガードレールの内側であれば、逐一の報告や承認は不要になります。

まとめ：JTCに内製アジャイル開発を根付かせるために

JTCに内製アジャイル開発を導入する際の最大の落とし穴は、アジャイルを単なる開発手法の選択問題だと捉えてしまうことです。

実際には、組織の歴史、雇用制度、権限と責任の配分、そして無意識の行動様式が複雑に絡み合った適応課題です。

だからこそ、理想形を無理に押し付けるのではなく、ガードレール付きで小さく任せ、管理を減らして現場がクイックに価値を生産するための仕組みを整える。そうした地に足のついたアプローチが求められます。

内製アジャイル開発は簡単に使える魔法ではありません。しかし組織が協力して地道に条件を整え、結果としてチームがパフォーマンスを発揮できたときはすさまじい成果を達成することができます。JTCにとってもすばらしい進化の道具になり得るはずです。