ゼロからはじめる内製化。生成AI時代はどこまで社内で担うべきか？効果的な推進方法を解説。

現在、多くの企業がDX（デジタルトランスフォーメーション）の推進を急ぐ中、「システムの自社開発（内製化）」が大きな関心を集めています。急速に普及した「生成AI」がプログラミングの難易度を劇的に引き下げたことも内製化の動きを加速させています。

しかし、「商用レベルのシステム」を構築するのは、単にAIにコードを書かせるだけで実現できるほど単純ではないことにも留意が必要です。

本記事では、NCDCのマネージングアーキテクト 三浦洋平の講演内容をもとに、主に以下の2つのテーマについて現実的な判断軸とアプローチを解説します。

• システムの開発や改善の実務をどこまで自社で担うべきか
• 継続的にシステムを内製できる体制をいかにして築き上げるべきか

内製化とは

そもそも「内製化（Insourcing）」とはどういう状態を指すのでしょうか。その対義語は、外注・アウトソーシング（Outsourcing）です。

では、「内製化する」とは具体的にどういうことかというと、システム開発の外注・アウトソーシングを「やめる」ことを指します。内製化の検討にあたっては、「なぜ今まで外注してきたのか」という理由に着目する必要があります。

アウトソーシングの狙い

あらためて、「なぜ今まで外注してきたのか」を確認します。

かつてアウトソーシングには、大きく次の二つの狙いがありました。

1. システム開発業務が非競争領域であり、ITの専門知識が必要なものであるため、自社で人材を抱えるのではなく社外の専門家に任せたいという狙い。
2. 外部化による業務の効率化と、人件費の最適化（ITを専門とする企業に外注することで経験の集約が起こり、効率的なシステム開発が実現できることに加え、繁閑の差が大きいシステム開発業務を外注することで人件費を最適化する）。

アウトソーシングのデメリット

このようにして始まったアウトソーシングですが、デメリットもあります。

一点目は、ノウハウが自社に蓄積されないこと。アウトソーシングは、一度作ったものを自社の資産として次のシステムに活かす、というようなことが非常にしにくくなっています。

二点目は、煩雑な業務を依頼するとコストが肥大化するということです。細かい仕様を伝えるためにコミュニケーションコストが発生することに加え、当初の予定から変更が起こった場合、簡単には行えず余計なコストがかかってしまうことなどが挙げられます。

かつては、ITの知見を自社に貯めることや、システムの柔軟性（素早く細かい変更を行えること）の重要性があまり意識されていなかったため、こういったアウトソーシングのデメリットはあまり問題視されてきませんでしたが、DX化の流れでデメリットが顕在化してきたため、内製化へと切り替える契機になりました。

内製化の狙い

先ほど「アウトソーシングの狙い」で述べた背景とは反対に、内製化の文脈ではシステム開発業務は競争領域と捉えられます。また、自社の特徴や強みをシステムに落とし込む必要が出てくるため、ITの専門知識だけでなく、業務知識も重要になってきます。

さらに、競争に勝つためより複雑な機能、より柔軟なシステムが求められるようになるため、システムに対する要求が複雑化し、その結果外注コストが肥大化する傾向が強くなります。これらを回避するために、内製化が注目されるようになったという背景があります。

内製化のメリット

内製化の最大のメリットは、「競争優位性の確保」です。

内製化の一番のメリットとして「コスト削減」を挙げられる方も少なくないとは思いますが、内製に切り替えるための一時的なコスト増大を飲み込んででもシステムの内製化に取り組む企業が増えているため、競争優位性の確保は最も重要な概念と考えてよいでしょう。

具体的には、独自性の高いシステムにするための業務知識が反映しやすいことや、実際の使用や市場調査などを踏まえて、開発途中でも仕様変更するといった変化への対応がしやすいこと、またこれらに対応するスピードを向上させやすいことなどが内製化のメリットと言えます。もちろん、より複雑な機能や柔軟なシステムの開発が求められる場面で、肥大化しがちな外注コストの最適化も、メリットのひとつとして挙げられます。

内製化のデメリット

一方で、内製化のデメリットとしては、体制構築・維持のコストがかかることが挙げられます。

これまで外注していたものを全て内製に切り替え社員で賄おうとした場合には、大勢の社員を雇用することになり、一時的な採用コストが大きく発生する上に、体制の維持コストが膨大になるといった問題が考えられます。このように、これまで外注していたものをすべて内製化するような極端な進め方は、コストの問題に直面しやすいです。

後ほど、こういった問題を回避するため、内製と外注を組み合わせた組織の作り方やハイブリッド戦略についても考えていきます。

なぜ今、内製化なのか

会計システムをはじめとした基幹システムなどは他社と比較して特色を出したい領域ではなく、非競争領域と見なされてきました。一方で、DXの時代に入り、新たなデジタルサービスを立ち上げるために開発されるようなシステムは、多くの場合他社との競争が求められるものになっています。

DXの時代は不確実性が高いとよく言われますが、そのような時代に求められるのは事業に最適化されたシステムであり、変化に強いシステム作りです。システム開発力がビジネスの競争力に直結する時代において、内製化は有効な手段だと考えられます。

また、システムにできることは増加し続けており、特に最近は生成AIの台頭によりITシステムでできることの幅が格段に広くなり、それに伴いシステムに要求されることもより多様化しています。このような状況下で、どのようにして内製化を進め、DX時代のシステム開発に適応していけばよいのでしょうか。

生成AIの登場がもたらした変化

生成AIの登場によって、システム開発の現場における「プログラミングの専門性」は劇的に変化しました。これまでは、高度なプログラミング言語の知識や、何年もの実務経験を持つエンジニアでなければ難しかったコードの記述も、生成AIのコーディング支援によって経験の浅いエンジニアでも可能になりました

これにより、ITの専門知識がない人であっても「ソフトウェアを形にする」ことのハードルは非常に低くなりました。「生成AIを活用すれば、外部のベンダーに頼らずとも、自社だけでシステムを簡単に作れる時代が来た」と考えるのも無理はありません。

しかし、実際に「本番環境で安定して稼働し、ビジネスに直結する商用レベルのソフトウェア」を開発しようとしたとき、求められるスキルはコードを書くこと（プログラミング）だけではないことに留意する必要があります。

商用開発に不可欠なシステム開発の「全体像」

システム開発には、以下のようにプログラミングの前後に存在する極めて重要な工程が数多くあります。

• 要件定義：どのようなシステムを作り、それによって何のビジネス課題を解決すべきかを明確にする。
• アーキテクチャ設計：システムの安全性、将来的な拡張性、耐久性を考慮した全体構造を描く。
• テスト・品質検証：不具合や致命的なバグ、セキュリティ上の脆弱性がないかを厳密にテストする。
• プロジェクトマネジメント：複数人によるチーム開発を破綻なく推進し、納期と予算の範囲内で進行を管理する。

現在、生成AIがいくら優秀なコードを書いてくれるとしても、システムの拡張性や堅牢性を考慮した複雑なアーキテクチャ設計において、AI単体で常に最適解を導き出すのは依然として困難です。AI任せで作成したシステムは脆弱な設計になってしまうリスクを孕んでいます。

また、ユーザーが触れる部分である「UX（ユーザー体験）」や「UI（ユーザーインターフェース）」の設計についても同様です。単にAIに指示を出してコードを生成するだけでは、自社のビジネス文脈やエンドユーザーの行動心理を深く考慮した、使いやすく快適なデザインを実現するのは困難だといえます。

確かに、生成AIによって個々の作業スピードや効率は格段に向上しました。しかし、システム開発の知識や経験がまったくない人が、いきなりビジネスに耐えうるシステムを作るのは現実的ではありません。

生成AIがもたらした「開発の容易さ」が実務で通用するのは、あくまでアイデアを素早く試すための「PoC（概念実証）」や「プロトタイプ作成」のレベルまでであると捉えるのが、現在の現実的な見解です。

これからのシステム開発の常識「AI駆動開発」

これからのシステム内製化を考える上で、もう一つ避けては通れない観点があります。それは、今後のシステム開発のプロセスそのものが「AIの活用を前提としたもの」へと進化していくという点です。

これは「AI駆動開発（AI-Driven Development）」などと呼ばれています。

AI駆動開発においては、単にコードを書く場面だけで生成AIを使うわけではありません。要件定義から基本設計、コーディング、テスト、そしてリリース後の保守運用に至るまで、開発プロセスのあらゆるフェーズにAIを組み込み、プロセス自体を再定義（デザイン）していきます。

このように、これからの開発手法は「AIネイティブ」なものへとシフトしていきます。

ここで重要なのは、AIを効果的に使いこなすためには、「従来のシステム開発の基本知識やベストプラクティス」がしっかりと頭に入っていることが大前提となる点です。

例えば、AIに精度の高いコードや仕様を出力させるためには、開発者が「どのような構造が優れているか」という判断基準を持っている必要があります。簡単になるどころか、むしろ「AIを安全に統制し、最適に使いこなすための高度な開発プロセス設計力」が求められるため、組織に必要な技術スキルの難易度は高まっているとも言えるのです。

単純にプログラマーを採用して自社内のエンジニア数を増やすという旧来の内製化アプローチは終わり、開発工程全体においていかにAIを効果的に組み込み、活用していくかを自社で統制できる力が新たに求められています。

どこから内製化するか

このような背景を踏まえて、具体的にシステム開発のどのフェーズから内製化に着手すべきなのでしょうか。

システム開発における一般的な一連の流れを、以下の5つのステップに整理します。

1. システム化の計画（目的、予算、開発体制、対象とする課題の策定）
2. PoC・プロトタイプ検証（アイデアや操作性の仮説検証、プロトタイプ作成）
3. 要件定義（UI/UX設計、システム全体の仕様・要求の決定）
4. システム開発（インフラ構築、フロントエンド・バックエンドの実装）
5. 保守・機能改善（リリース後のシステム維持、ユーザー行動に基づく追加開発）どこから内製化するか

まずは、どこから内製化していくかを考えていきましょう。

内製化の優先度が高いのは計画、検証、要件定義

上記のシステム開発5つのフェーズのうち、まず内製化すべきなのは、はじめの3つ「システム化計画」「PoC・プロトタイプ検証」「要件定義」です。システム化の計画は社内で実施されている企業が多いと思いますが、要件定義までしっかりと行えている企業は意外と少なく、外部ベンダーに依存しているのではないかと思います。

PoC・プロトタイプ検証の自社完結化

内製化において、最優先で取り組むべきなのが「PoC（概念実証）」や「プロトタイプ検証」の自社完結です。

PoCやプロトタイプは、本格的な開発に着手する前に、「このアイデアで本当に現場の課題が解決できるか」「思ったとおりの操作性や導入効果が得られるか」を確かめるための、いわば「使い捨て」を前提とした試作開発フェーズです。

このフェーズの最大のポイントは、本番運用システムで求められる「強固なセキュリティ対策」や「大人数での同時アクセスに耐えるシステム構造」「将来の拡張性を考慮した複雑な設計」などが不要になる（もしくは重要度が低くなる）ことです。

つまり、実用に耐える安全性の高い設計でなくても、「一定の検証だけできれば良い」という割り切りができます。そのため、生成AIが出力したコードをほぼそのまま活用してアプリケーション化することが比較的容易にできます。

AIの進化によるメリットを最もダイレクトに享受できる領域であるため、このPoC・プロトタイプ作成を自らの手で行うことが、生成AI時代のシステム内製化で優先的に取り組むべき項目となります。

意思決定を主導する「要件定義」人材の育成

次に優先度が高いのが「要件定義」です。NCDCでは、生成AIを活用して要件定義の実務を自動化・効率化するフレームワークを実践しています。

具体的には、以下のような連鎖的なドキュメント生成フローです。

1. 会議の音声録音：関係者で行う要件確認ミーティングの議論を録音し、生成AIで文字起こしする。
2. 構造化された議事録の生成：文字起こしテキストから、議論の要点をAIに分析させ、IDやタグを用いて構造化した議事録を作る。
3. 要求管理表の自動作成：議事録を基に、どのような機能が必要かを整理した「要求管理表」を自動で生成する。
4. 要件定義書（SRS）への展開：要求管理表とシステム設計を紐付け、開発のトレーサビリティ（追跡可能性）を保ちつつ、要件定義書をAIにドラフトさせる。
5. ユーザーストーリーの生成：最終的に、GitHubなどの開発管理ツールでタスクとして使える「ユーザーストーリー」や「サブタスク」にまで連鎖的に分解・自動生成する。

このように、ドキュメントの整理や起票、ドキュメント同士の紐付けといった実務作業においては、AIを導入することで作業負荷を大幅に削減できます。

しかし、要件定義において最も本質的かつ重要なのは、「どんなシステムで、どのような課題を解決するか」という方針の決定や、社内の多様なステークホルダー間の利害調整、そして「何を作って何を作らないか」を決める最終的な意思決定です。

こうした人間関係の調整や高度なビジネス判断は、AIが最も苦手とする領域であり、現時点のAIで代替できる領域ではありません。自社でシステム開発の主導権を握り続けるためにも、外部ベンダー任せにせず、社内に要件定義を主導できる「ビジネスとシステムを繋ぐ人材」を育成・確保することが極めて重要です。

システム開発や機能改善のどこから内製化するか

「システム化計画」から「要件定義」までのフェーズは、内製化を考える際に優先度が高いことが分かりました。その上で、続きの「システム開発」「保守・機能改善」をどう内製化していけばよいのでしょうか

モノづくり全体のうち、どこから内製化に着手するのがよいのかを考えるために、一つの軸を用意します。

上図では、ビジネス面の変更に対し、システムがどれだけ適応を求められるのかを「ビジネスへの変更適応度」として考えます。ビジネス面の変化に伴う適応の要求が大きい領域を内製化の注力領域として、徐々に要求が小さいものへと拡大していくのが効果的です。

また、技術やスキルの変化のスピードも考慮する必要があります。例えば、フロントエンドの技術はバックエンドやデータベースと比べて変化が早いと言われています。常に新しい技術に対応するのはコストがかかるため、変化のスピードが遅い分野を内製化した方が、コスト的には有利になるという側面もあります。

開発領域で分けた場合、一番ビジネスへの変更適応度が大きいのがUIの部分です。UIは特にユーザーに見える部分なので、ビジネス面の変化をユーザーに対して一番大きく伝えられるレイヤーです。

続いて、同じくらい変更適応度が大きいのがフロントエンドです。UIを機能ではなく見た目を指す言葉とした場合、機能を付加したり変更したりするのがフロントエンドになります。

その下のバックエンド、データベース、インフラは、下に行くにつれてビジネスによる変化を受けにくくなります。ビジネスが変わることによってデータモデル（データベース）が変わることも当然ありますが、頻度はあまり高くありません。一方で、業務フローを変えるとバックエンドのAPIが変わるということはよくありますし、業務フローを変えずにユーザーへの見せ方だけを変える場合にもフロントエンドは変わってきます。使い勝手や見た目の良し悪しで差別化を図るために、UIが一番変化の可能性が高いと言えます。

システム開発の技術領域としては、大きく以下の3つに分かれます。

1. フロントエンド：顧客やユーザーが直接目にし、操作する画面。
2. バックエンド：裏側でデータの処理や、データベースとのやり取りを行うロジック。
3. インフラ（クラウド）：システム全体が稼働するための土台となる、サーバーやネットワーク。

この中で、内製化に最もおすすめなのは、圧倒的に「フロントエンド」です。

ビジネスのスピードに直結するフロントエンド

フロントエンドは、ユーザーが直接触れる画面そのものであり、システムの使いやすさ（UX/UI）を大きく左右します。何より、ビジネス環境の急速な変化や、現場のユーザーから寄せられる細かな要望・フィードバックに応じて、最も頻繁に、かつスピーディに変更を加えたい部分がこのフロントエンドです。

フロントエンド開発を外部のベンダーに毎回委託していると、ちょっとしたボタンの変更やレイアウトの調整だけでも「見積もり調整」や「要件定義のやり直し」が必要になり、数週間から数ヶ月のリードタイムと大きなコストがかかってしまいます。自社内にフロントエンドを改修できるスキルを持つメンバーがいるだけで、ユーザーからの要望をより短いリードタイムで改修・反映し、素早くPDCAサイクルを回すことが可能になり、ビジネスにおける大きな競争優位性を生み出せます。

一方で、バックエンドやインフラについては、フロントエンドに比べると、一度システムとしての土台を構築してしまえば、頻繁に変更が加わる領域ではありません。そのため、初期フェーズから無理に自社だけで抱え込む必要性は極めて低く、これらは信頼できる外部パートナーに開発を委託するか、密な連携を取りながら段階的に取り込んでいくアプローチ（スモールスタート）が非常に有効です。

クラウドを活用したインフラ構築の内製化

インフラの構築（クラウド）についても、AWS（Amazon Web Services）などのクラウドサービスの活用により、内製化の障壁は劇的に下がっています。現代のクラウド環境においては、インフラ自体をコードで定義する「IaC（Infrastructure as Code）」という手法が広く一般的になっています。インフラ構築を「ソフトウェア開発化」することによって、以下のようなメリットが生まれます。

• AIコーディング支援の最大活用：IaCはコード化されているため、インフラの設計書や設定に関しても、生成AIによる記述支援やバグ・脆弱性の指摘を大いに活用できます。
• 再現性と安全性の向上：一度コードで定義したインフラは、全く同じ構成をボタン一つで別の環境に再現できるため、人為的な設定ミスやトラブルを大幅に削減できます。
• 圧倒的な情報量と学習環境：AWSは世界中で広く使われており、インターネット上や書籍などに膨大な知見やドキュメント、コードのサンプルが存在します。これにより、自社のエンジニアが自律的に学習し、知識をキャッチアップすることが非常に容易です。

インフラ構築までを自社で内製化できれば、理論上は「100%自律的な開発」が可能になります。

とはいえ、やはりリソースが限られる中で、最もビジネス価値に直結し、変更頻度が高いフロントエンドと比べると、インフラは優先的に内製化に着手すべき領域ではないといえます。

内製化が向いているシステム・プロジェクト

内製化の取り組みは、パイロットプロジェクトから始めることが多いかと思います。現在進行形のプロジェクトの中から難易度の低いものをいくつかピックアップし、それらのプロジェクトを試験的に内製化する進め方です。

では、内製化するプロジェクトはどうやって選べばよいでしょうか。以下に挙げた5つの特徴を備えたシステムやプロジェクトがおすすめです。

• 仕様の不確実性が高い：作ってみないと要件がわからない、頻繁に仕様が変更される
• 新規性が高いビジネスやサービス開発：仕様の不確実性が高いこととほぼ同義。やることが決まりきっていない場合にも柔軟に対応可能。
• リリースのライフサイクルが早い：リリースしたものをすぐに改修して、また新たにリリースするといった改善のサイクルを回したいプロジェクト。
• 業務プロセスの独自性が高い：豊富な業務知識が必要かつその使いやすさが競争力の源泉となっているシステムは、外部ベンダーに知識を伝達するより内製する方が向いている。
• 開発の初期規模が比較的小さい：小さいところから始めていく方が安全。

これらの条件に該当するプロジェクトは、すべてをアウトソーシングで進めようとすると、要件の相談や、度重なる仕様変更の見積もり調整だけで多くの時間とコストを浪費してしまう可能性が高くなります。そのため、自社で柔軟に方向性をコントロールできる内製化のメリットが、最も大きく発揮される領域です。

一方で、障害発生時のリスクが極めて高い大規模な基幹システムや、法令対応などを主目的とした定型的で変化の少ないシステムについては、柔軟性やスピードよりも「確実性・安全性・耐用性」が最も重視されるため、必ずしも内製化のメリットは大きくありません。

したがって、大規模なものや定型的な領域は、実績と確実な品質保証能力を持つ外部パートナーに開発を委託したままにし、自社のリソースは、最も俊敏さが求められる「差別化領域」に直結するシステムに集中させ、段階的に内製化の比率を高めていくアプローチが有効です。

外注と内製を組み合わせる

全てを一度に内製化するのは難しいため、徐々に内製化率を上げていくのが失敗しにくい内製化の進め方ですが、外注と内製の分割の方法は外部ベンダーとの相談が必要です。

フロントエンドまでを自社で内製し、バックエンド以下をベンダーに外注するという切り分け方がおすすめです。フロントエンドとバックエンドが分離していれば責任分界点が明確なため、外部ベンダーも安心して受注することができます。反対に、バックエンドを半分内製し、半分外注したいというような場合は、領域の切り分けが難しくなってしまうため対応できるベンダーを探すことも難しくなります。

また、100％の内製化がゴールになるとは限りません。内製と外注をうまく組み合わせていくのが重要です。

内製化組織のつくりかた

内製化には、IT知識と業務知識を持ち合わせたDX人材が必要です。このDX人材をいかに作っていくかというのが、内製化組織を作り上げていく上でのポイントになります。

DX人材の獲得方法は2通りあります。

• ルートA（既存社員のIT・AI教育ルート）：すでに自社のビジネスや業務プロセスを深く理解している社内の既存社員を配置転換し、ITやAIの教育を施して、要件定義や開発を行えるように育てる。
• ルートB（エンジニア外部採用ルート）：ITやAIの専門的な開発スキルを持ったエンジニアを外部から新しく採用し、入社後に自社特有のビジネスや業務知識を教えていく。

おすすめは、ルートA「業務知識を持った社員にIT知識をつけるパターン」です。なぜかというと、これには現在の市場環境や経営リスクに即した現実的な理由があるからです。

1. エンジニア獲得競争の激化：現在、高度なスキルを持ったITエンジニアの獲得競争は、国内外で激化しています。自社にシステム開発の文化や、エンジニアを適切に評価・キャリアサポートする人事制度がまだない段階で、開発組織をゼロから一人で立ち上げられるような優秀なエンジニアを採用することは、極めて困難です。
2. 多大な採用コストとミスマッチリスク：外部採用には多額の費用がかかり、採用した人材が自社の企業文化や業務内容にマッチしなかった場合の、経営における初期投資リスクが非常に高くなります。
3. 最も重要な「現場目線」の保有：既存の社員は、「現場のスタッフがどんな業務に困っているか」「どこをシステム化すれば本当に便利になるか」という、システム開発において最も重要な課題のありかを最初から理解しています。こうした業務知識は外部のエンジニアをアサインして何ヶ月もレクチャーするよりも、実務において重要なアドバンテージとなります。

既存の社員にIT知識を身につけてもらう際、ITのエキスパートになるよう強い期待をかけるのではなく、システム開発のエッセンス（どのような流れでシステムができていくのか、どんな制約があり、何が簡単で何が難しいのかといった要点・勘所）をしっかりと掴んでもらうことがポイントになります。

また、内製化を推進する人材を既存社員から選抜する際は、以下の2つの人選基準を目安にすると、新時代のAI駆動開発にもスムーズに適応しやすくなります。

• 生成AIに積極的に触れている好奇心の強さ：ただ「会社に言われたからツールを使う」のではなく、自発的にプライベートや日々の業務で「これで何か業務を自動化できないか」とチャレンジしている方は、抜群の適性を持っています。
• 数字やコードの記述に対して拒否反応が薄いこと：過去の経歴の中で、Excelの複雑なマクロ（VBA）を組んだことがある、システム関連の問い合わせ窓口を経験した、などの「ITや論理構築に対するアレルギー」が比較的少ない方をアサインすることが、育成をスムーズに進めるコツです。

はじめから全てを内製する必要はないので、DX人材あるいはDX人材候補の方を軸に、外注リソースや派遣社員などを組み合わせて内製化チームを組成するとよいでしょう。

内製化プロジェクトの進め方

ゼロからはじめる内製化プロジェクトは、社内だけの独学で進めようとしないことが重要です。適切な設計やセキュリティのノウハウがないまま自己流で開発すると、本番環境で通用しない脆弱なシステムを生み出す原因になります。そのため、開発プロセスそのものの技術とノウハウを移転（スキルトランスファー）してくれる伴走型の外部パートナーを頼るようにしてください。

既存の社員を、本番レベルのシステム開発ができる内製化人材へと変革させていくためには、以下の3つのステップに沿った育成プロセスが効果的です。

• Step 1. 基礎研修＋PoC・プロトタイプ作成（自社完結）：基礎的なIT・プログラミングの仕組みと生成AIの使い方を学び、まずは安全で失敗してもよい、動くだけのPoC開発で「形にする楽しさ」を体感する。
• Step 2. 外部パートナーとの「共創プロジェクト」：実務で本番運用するシステム（パイロットプロジェクト）を立ち上げ、レクチャーやスキルトランスファーを徹底して行える外部パートナーと共創チームを結成。ペアプログラミングなどを通して、実務レベルの開発プロセスと設計知識を徹底的に吸収する。
• Step 3. 役割シフトによる自立化：スキルの向上に伴い、自社メンバーが要件定義から基本設計、フロントエンドの実装を主導。パートナーはレビューやアドバイザー役へシフトし、自社だけの体制へ移行する。

当初は外部パートナーが開発プロジェクト全体の主導権を持ち、手本を提示します。そこからペアプログラミングやコードレビュー、ADR（アーキテクチャの選定理由の記録）や仕様駆動開発のやり方の実践的なコーチングを通して、自社メンバーの成長に合わせて徐々に担当する領域と権限を引き渡していきます。

この「緩やかなシフト（役割の段階的移行）」こそが、結果として安全で失敗しないシステム内製化への近道となります。

また、内製化するプロジェクトでは、アジャイル開発を採用することをおすすめします。内製化とアジャイル開発は相性がよく、「変化に強いシステム」や「素早く変化させるシステム」の実現が容易になるためです。

内製化の事例

実際にNCDCが支援させていただき、段階的なスキルトランスファーに成功した事例をご紹介します。

ライフネット生命様の内製化事例（フロントエンドから着手）

ライフネット生命保険様は、ユーザーとの接点であるWebフロントを柔軟に変更・改善したいという要望をお持ちでしたので、フロントエンドの内製化チームを既存のIT部署から派生させて組成しました。そこで、フロントエンドのモダンなフレームワーク（Vue.js）を習得いただきました。

ここでのポイントは、バックエンドやインフラは従来通りベンダーに依頼していることです。優先度の高いお客さまに見える部分＝フロントエンドに注力して内製化したという外注と内製のハイブリッド戦略がこの事例の特徴です。

【事例紹介】システムアーキテクチャの刷新とアジャイルの導入で、ビジネス要求への迅速な対応を実現

戸田建設様の内製化事例（共創開発による人材育成）

戸田建設株式会社様は、システム内製化やDevOpsの実現に必要なDX人材を育成するため、開発プロジェクトを通じた社内メンバーの育成を重視されました。

NCDCとお客さまの混成による「共創チーム」でアジャイル開発を推進し、初期はNCDCが主導しながら徐々に内製メンバーに重要な役割を任せていくことで、実践的なスキルトランスファーを実現しました。単なる開発代行ではなく、チームが自律的に動ける力をつけることに成功しています。

【事例紹介】パートナーとの共創プロジェクトで、内製化とデジタル人材育成を同時に推進

大手金融機関の内製化事例（未経験からの人材育成）

もう一つの事例は、未経験の社内メンバーを中心に内製化プロジェクトを立ち上げ、2年間のロードマップで段階的な技術移転を推進した大手金融機関A社様の事例です。

1年目（基礎スキルの獲得とパイロットプロジェクト）

非本番運用の「パイロットプロジェクト」を立ち上げ、要件定義から開発まで一連の工程を体験。NCDCのエンジニアがチームに並走し、ペアプログラミングなどを通じて実践的なノウハウを定着させました。なお、確実にスキルを習得するため対象は「フロントエンド」と「バックエンド」に絞り、難易度が高く変更頻度の少ないインフラ（AWS）構築はあえて対象外として進めました。

2年目（パイロットプロジェクトの本番化と役割シフト）

実際のユーザー向けに本番リリースを行う開発フェーズへ移行。1年目の成果を活かし、要件定義や画面設計（基本設計）はA社様のメンバーが主体となって推進し、NCDCはアドバイザーやレビュアーへと役割をシフトしました。デザインやAWSインフラなどノウハウが不足する領域はNCDCが支援しつつ、アプリ本体の実装はA社様が中心となって進めることで、自社で主体的に運用・拡張できる体制づくりにも取り組んでいます。

ゼロからはじめる内製化―まとめ

内製化に取り組む際の考え方、進め方についてのまとめです。

内製化のメリットは、競争優位性の創出にあります。もちろんコスト最適化のメリットもありますが、競争優位性を作るために内製化をうまく使っていくことがポイントです。

開発プロセスを大きく変革させた生成AIの活用も大きなポイントです。しかし、誰もが生成AIを開発に活用する時代だからこそシステム内製化を成功させるためには、技術的なスキルだけでなく、進め方の戦略が成否を分けます。

内製化を進めるための重要ポイントを以下に整理します。

• AIは万能ではないと正しく認識する：
  生成AIによってコード生成は劇的に簡単になりました。しかし、商用システムの安定稼働やセキュリティ、人間関係を伴う「要件定義」における意思決定など、AIだけでカバーできない重要な領域にこそ、自社人材のパワーを割くべきです。
• 小さく始める（フロントエンドからのスモールスタート）：
  システム全体の100%を最初から内製化しようとしないことが重要です。まずは「PoC・プロトタイプ作成」から始め、開発の内製化にステップを進める際は、ビジネススピードに最も直結する「フロントエンド」から段階的に取り組みましょう。
• 既存の優秀な社員を「内製化人材」に進化させる：
  高度な外部エンジニアの採用市場は激化しています。現場の課題を誰よりも深く知る既存の社員にIT・AIのトレーニングを施すことで、本当に現場が必要とする優れたシステムを自社で作れるようになります。
• 教え、引き継いでくれるパートナーと組む：
  ただ仕様書どおりに作って納品して終わるだけのシステムインテグレーター（受託ベンダー）を頼るのではなく、ペアプログラミングやペアデザインなどを通して、開発プロセスそのものの技術とノウハウを移転（スキルトランスファー）してくれる、伴走型の信頼できる外部パートナーを見つけることが最大の成功要因です。

生成AIを活用し、段階的に組織の実力を高めていくアプローチこそが、継続的な改善を可能にする現実的なロードマップと言えます。

内製化のご相談はNCDCヘ

NCDCは、豊富な実績と知識で内製化をサポートすることが可能です。「生成AIを活用したシステム内製化（AI駆動開発）」や「自律して継続的に改善できる開発体制の整備」を、企画段階から人材育成、実際の開発支援まで一貫してサポートしています。

「社内にエンジニアが一人もいないが、どこから内製化の手を付けたらよいか」「生成AIをどう開発プロセスに取り込み、安全に統制をかけたらよいか」「内製化に向けて、既存の社員をどのようにトレーニングし、ノウハウをスキルトランスファー（技術移転）していけばよいか」といった課題やお悩みをお持ちの企業様は、ぜひ一度NCDCまでお気軽にご相談ください。

AWS等のクラウドを駆使した最適なアーキテクチャ設計、UX/UIデザイナーによる使いやすい画面構成デザイン、アジャイル手法の導入支援、ペアプログラミングを通じた徹底的な技術スキルの定着まで、豊富な実績を持つ専門コンサルタントやエンジニア、デザイナーが親身に伴走し、外部ベンダーに依存せず自走できる開発チームづくりをサポートします。

また、どこから内製化していくべきか、対象システムの選定に悩まれているような段階からでもご支援が可能です。まずはお気軽にご相談ください。

資料公開

本記事は2024年のセミナー解説記事をベースに、2026年6月のアップデート版セミナー内容を加筆して構成しています。

2024年11月27日にオンラインセミナー『ゼロからはじめる内製化 どこまで社内でできるのか？効果的な推進方法を解説。』で用いた資料と動画も公開しています。

動画で見る