LASSIC Media らしくメディア

監修・編集責任者：牛尾 昭昌（株式会社LASSIC 執行役員）

支援を受けて内製化を進めてきたものの、いつ支援を終えてよいのか分からない。支援の担当者が抜けたら、開発が止まってしまいそうだ——。外部の支援を受けて内製化を進める企業では、こうした迷いが起こりがちです。内製化支援とは、外部の企業やエンジニアが社内のチームに加わって開発や運用を一緒に進めながら、社内の人が自分たちで進められるように手伝うことです。その先の目標が、支援がなくても社内主導で開発と運用を続けられる「自走」の状態です。

自走できたかを見極める自走化判断の基準を先に決めておくと、支援をいつ、どの作業から減らすかを社内で合意しやすくなります。ただし基準は万能ではなく、満たしているかどうかは自社の開発現場で確かめるしかありません。本記事では、内製化を進める開発部門のマネージャーに向けて、自走の考え方、社内に残す役割、人材の質と量、知見の残し方、そして判断の進め方を整理します。

内製化支援と自走とは

自走というと、社員だけで設計からリリースまでをこなす姿を思い浮かべるかもしれません。しかし、公的な資料が示す内製化は、もう少し別のところを見ています。IPA（情報処理推進機構）は2022年に公表した報告書で、国内17社・海外6社への調査をもとに、先進企業の取り組みを整理しています。そこで示されたのが「内製化とは自社でプロダクトをコントロールすること。それが出来れば外部エンジニアを活用しても問題ない」という考え方です。^*1

同じ報告書には、製造業の企業が内製化を「プロジェクトのコントロールを全て自社で行うこと」ととらえ、社員と外部のメンバーを区分けせずに1つのチームとして進めている例も載っています。ここでいうコントロールとは、何を作るか、どの順で作るか、でき上がったものを受け入れるかを自社が決めることです。設計やコーディングを担う人が社員かどうかは、その次の問題になります。

日本情報システム・ユーザー協会（JUAS）の「企業IT動向調査報告書2026」も、「完全内製化ができている企業は限られており」、大半の企業が内製と外部委託の組み合わせの最適化を求めているとまとめています。^*2 自走化判断で確かめるのは、社員だけで全部できるかではなく、外部の人を使いながらも自社が開発を主導できるかどうかです。

なぜ自走化判断が難しいのか

内製化支援を、期間を決めた契約で始めると、支援を終える日が先に決まります。一方で、何ができれば自走したといえるのかは、言葉になっていないことが少なくありません。支援者がいる間は、支援者が問題に先に気づいて直してしまうため、社内の人だけでは進められない作業があっても気づきにくくなります。

JUASの同じ報告書は、システム開発の多くの工程を長く外部に頼ってきた企業について、「業務を理解しシステムに落とし込む能力や取組みをマネジメントする能力を十分に育成・留保できておらず」、内製が思うように進まないと指摘しています。^*2 足りないのは、プログラムを書く力よりも、業務の手順をシステムの仕様に置き換え、開発全体を管理する力だということです。

IPAの「DX実践手引書 ITシステム構築編」も、外部委託に頼ってきた開発をすべて自社で育てた人材に置き換える目標は「少なくとも短期的には、現実的ではないだろう」としています。^*3 自社で担い続ける役割と、外部の人に頼んでよい作業を分けて考えることが、判断の出発点になります。

社内に残す役割

DX実践手引書は、内製開発を3つのレイヤー（層）に分けています。1つ目は、自社で作ったものや外部から導入したものを含めて、自社システムがどう構成されているかを把握するレイヤーで、CIO・CTO（情報システムや技術の責任者）の役割です。2つ目は、事業の目標をどのシステムの導入や改修で実現するかという全体構想と意思決定のレイヤーで、プロダクトオーナー（何を作るかを決める責任者）の役割です。3つ目が、設計、コーディング、リリースといった作業のレイヤーです。

3つ目の作業については、必要な人材の量も多く、外部のIT企業の力を借りるのは合理的だとしています。そのうえで手引書は、「CIO/CTO ロール、PO ロールは自社内で確実に実施し、自社システムを自ら掌握することが必要である」と書いています。^*3 PO（プロダクトオーナー）の役割まで支援者に任せたままでは、社員の人数が増えても自走したとはいえません。

ここから、自走化判断の1つ目の基準が決まります。支援者がいなくても、社員が自社システムの構成を説明でき、次にどの改修をどの順で進めるかを社員が決めているかどうかです。改修の優先順位を決める打ち合わせで、支援者の意見が出るまで結論が出ないなら、2つ目のレイヤーはまだ支援者が担っています。設計やコーディングの一部が支援者の手に残っていても、この2つのレイヤーを社員が担えていれば、残りの基準の確認に進めます。

成熟度のレベルで見る自走

IPAの概要報告書は、DX（デジタル技術を使った事業や業務の変革）を進める組織の力を39の指標に分け、それぞれを5段階のレベルで測れるようにしています。^*1 39の指標のうち、自走化判断にそのまま使えるのが「開発・運用の内製化」と「自社開発の内部エンジニアの整備」の2つです。

「開発・運用の内製化」のレベル5は、外部の人を使っていることを前提にしたうえで、「自社主導で開発や運用を行っている」状態を最も高い段階に置いています。レベル4では、エンジニアに加えて、アーキテクト（システム全体の構成を決める人）やUIデザイナー（画面の使い勝手を設計する人）がいることを求めています。

いくつかのシステムを社内で開発・運用できている企業は、表ではレベル3に当たります。ただし、システム全体の構成や画面の設計を支援者に頼っているなら、レベル4の条件は満たしていません。表の文言に自社を当てはめ、いまどのレベルにいて、次のレベルに進むには何が足りないかを書き出すと、支援を減らす順番を決められます。

必要な人材の質と量

2つ目の基準は、人材の質と量です。経済産業省とIPAの「DX推進指標」は、企業が自社のDXの状況を点検するための自己診断の指標で、2026年2月に改訂され、同年8月に回答の手引きとなる「ガイダンス」が出ています。そのうち人材の設問は、DXを推進する人材に求めるスキルと必要となる人材の量が明確になっているか、内部人材の計画的な育成や中途採用、外部アドバイザー・パートナーの活用などの取り組みをしているかを尋ねています。^*4

ガイダンスは、必要な人材やスキルと現状との差を明確にすると、育成で補うべきところと、採用や外部の活用で確保すべきところを特定しやすくなると説明しています。レベル4の定義は、人材の質と量が明確で、継続して見直しており、「スキル・量ともに必要となる人材を確保できている」ことです。^*4

自走化判断に当てはめると、支援者が担っている作業を1つずつ書き出し、その作業に必要なスキルと人数を並べることになります。たとえば、設計の確認、完成したシステムを利用者向けに公開する作業、不具合が起きたときの最初の対応です。それぞれについて、同じ作業をできる社員が何人いるかを数えます。1人しかいない作業は、その人が休んだり異動したりすると止まるため、まだ支援を外せない作業として残します。

スキルを書き出すときの手がかりとして、ガイダンスは経済産業省とIPAの「DX推進スキル標準」を挙げています。これは、DXを推進する人材の役割と、身につけるべきスキルを定めたものです。作業を書き出したあとにこの標準の役割と照らし合わせると、書き漏らした役割に気づきやすくなります。

支援で得た知見の残し方

3つ目の基準は、支援を通じて得た知見が、特定の人ではなく組織に残っているかどうかです。DX推進指標のガイダンスは、外部のアドバイザーやパートナーの活用を尋ねる設問で、外部との協業を通じて得られた知見やノウハウが「特定の部門や担当者に留まらず、組織全体で共有・活用されていることが望ましい」としています。^*4

DX実践手引書も、先進企業の取り組みとして、外部の企業に開発作業の一部を担ってもらいながら足りない技術を補い、少しずつ社内にスキルを移していく方法を紹介しています。^*3 支援を受ける期間は、作業を代わりにしてもらう期間ではなく、社内の人が同じ作業をできるようになる期間だと位置づけておきます。

確かめ方は、支援者が作ったものと教えたことが、社内の共有の場所に残っているかどうかです。設計を決めた理由、手順書、障害対応の記録が、支援者の手元ではなく社内の文書として残っていれば、支援者が抜けても参照できます。そのうえで、その内容を説明できる社員が2人以上いれば、3つ目の基準はおおむね満たしていると見てよいでしょう。関連して、支援を受ける前に自社に残す工程を決めておく考え方は「内製化支援の選定はどこから？自社に残す工程を先に決める」で扱っています。

自走化判断の進め方

DX推進指標のガイダンスは、成熟度レベルの選び方について「レベルに記載の要件を全て満たしているレベルを選択してください」とし、一部の要件しか満たしていない場合はそのレベルを選ばないことを原則にしています。^*4 自走化判断も同じ考え方で進められます。3つの基準をすべて満たしてから支援を終え、一部しか満たしていなければ、満たしている作業から支援を減らします。

進め方としては、まず支援を受けている作業を一覧にし、作業ごとに3つの基準を当てはめます。すべて満たした作業から、支援者が関わらずに社員だけで進める期間を設け、問題なく回るかを確かめます。回らなかった作業は、何が足りなかったのかを書き出し、育成で補うのか、人を採るのかを決めます。

よくある失敗は2つあります。1つは、特定のレベルに達すること自体を目標にしてしまうことです。ガイダンスは、成熟度レベルの把握や特定のレベルへの到達そのものが目的にならないよう注意を促しています。もう1つは、支援を終えた時点で判断を終わりにすることです。担当者の退職や異動で基準を満たさなくなることもあるため、同じ基準で定期的に見直します。

まとめ：自走化判断で確かめておきたい3つの点

内製化支援から自走へ移るうえで、確かめておきたい点は3つに整理できます。第一に、自社システムの現状把握と、何をどの順で作るかの意思決定を社員が担っていること。第二に、支援者が担っていた作業ごとに必要なスキルと人数を書き出し、社内で確保できていること。第三に、支援で得た知見が特定の担当者に留まらず、社内の文書として残り、複数の社員が説明できることです。この3点を踏まえておけば、「支援が終わった途端に、次の改修を誰も決められない」という事態を避けやすくなります。足りない役割を社内の人だけで埋めきれないときは、外部の手を借りるのも一つの選択肢です。

よくある質問

出典

1. *1　参考：IPA「DXの継続的な取り組み事例に関する調査 概要報告書」（https://www.ipa.go.jp/digital/dx/hjuojm000000eem6-att/000097139.pdf）。出典：独立行政法人情報処理推進機構 社会基盤センター「DXの継続的な取り組み事例に関する調査 概要報告書」（2022年4月4日）。1.2節（国内17社・海外6社を対象とした調査）、2.2節と図2-4（39の組織成熟度指標と5段階のレベル定義、#36・#38）、5.2節（開発・運用の内製化のキーメッセージと事例）を参照（2026年9月確認）
2. *2　参考：JUAS「企業IT動向調査報告書2026」（https://juas.or.jp/cms/media/2026/04/JUAS_IT2026.pdf）。出典：一般社団法人日本情報システム・ユーザー協会「企業IT動向調査報告書2026」（2025年度調査）。7.2節の考察とまとめ（システム開発の内製／外部委託）の記述を参照（2026年9月確認）
3. *3　参考：IPA「DX実践手引書 ITシステム構築編」（https://www.ipa.go.jp/digital/dx/dx-tebikisyo.html）。出典：独立行政法人情報処理推進機構「DX実践手引書 ITシステム構築編 完成第1.1版」。1.3節（企業経営の中核課題となる内製開発力の強化）と2.2.3節（自社開発の内部エンジニア・開発・運用の内製化）を参照（2026年9月確認）
4. *4　参考：経済産業省・IPA「DX推進指標」のガイダンス（https://www.ipa.go.jp/digital/dx-suishin/rcu1hd000001a4xh-att/dx-suishin-guidance.pdf）。出典：経済産業省 商務情報政策局 情報技術利用促進課・独立行政法人情報処理推進機構「『DX推進指標』のガイダンス」（2026年8月）。DX推進指標の活用方法、成熟度レベルの考え方、FAQ、3-1の設問11、3-2の設問20・22を参照（2026年9月確認）

Tweet