開発内製化の発注は、契約形態と著作権の扱いを決め、そこに技術的負債に充てる工数の枠と段階的な移行を組み合わせて設計します。実際、日本企業の内製化進捗率は米国の46.4%に対し22.3%にとどまり、人材確保・育成の難しさを挙げる声は82.3%に達しています。
Webサービス開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「Webサービス開発の完全ガイドブック」で詳しく解説しています。
開発内製化における発注・外部支援活用の全体像
開発内製化と聞くと、すべてを社内のエンジニアだけで完結させる取り組みを思い浮かべがちです。しかし、成功企業はほぼ例外なく、外部支援を組み合わせるハイブリッド戦略を採用しています。
実際に、星野リゾートやカインズといった内製化の先進企業も、伴走型の支援パートナーやSaaSベンダーを積極的に取り込みながら、段階的に自走する力を高めてきました。
発注の設計は、業務委託契約の条件を決めるだけでなく、ノウハウとソースコードをどう自社へ移すかという知財戦略の面も持っています。
100%内製主義の罠と外部支援活用の必然性
「ベンダー依存から脱却するなら全部自社でやるしかない」という発想は、内製化プロジェクトを頓挫させる典型的なパターンです。日本のIT人材は約72.0%がベンダー企業側に偏在しており、事業会社側に十分なエンジニアを抱える米国型の構造とは前提条件が異なります。また、経験豊富なテックリードやアーキテクトは、いきなり社内で確保するのが難しく、求人を出しても採用に半年から1年かかるケースも珍しくありません。
自動車部品メーカーA社は、社内の人材だけでローコード基盤を立ち上げようとしました。その結果、要件定義が曖昧なままスコープクリープが起き、最終的に「やらないほうがマシだった」という結末を迎えています。一方で星野リゾートは、コロナ禍の最中も外部の技術顧問やクラウドベンダーとの伴走関係を保ちながら、入退出センサーIoTを部材コストのみで短期内製しました。
両者を分けたのは、社内だけで完結させるかではなく、外部の知見を素早く社内に移せる契約を組めたかどうかです。外部支援を活用する目的は、単発の開発成果物を得ることではなく、契約期間中にエンジニアリング文化・ドキュメント文化・運用ノウハウを「資産」として社内に蓄積することにあります。この視点が抜け落ちると、契約終了と同時にブラックボックスだけが残るという最悪のシナリオに陥ります。
コア領域とノンコア領域の切り分け原則
発注設計の出発点は、どの領域を内製化し、どの領域を外部に委ねるかというポートフォリオの判断です。競争優位に直結する顧客接点や業務ロジックの中核は、コア領域とみなして内製化を志向します。一方で、AI/機械学習基盤やセキュリティ診断、決済・認証など高度な専門性を要する非競争領域は、ノンコアとして外部の専門ベンダーやSaaSに委ねたほうが合理的です。
カインズの事例は、このコアとノンコアの切り分けがよく表れた好例です。基幹のERPはMicrosoft Dynamics 365を採用してリードタイムを約1/3に短縮し、フロントの顧客向けコンテンツ管理はmicroCMSで内製化してアクセス30%増を実現しました。
さらに、脆弱性診断はVexを活用しつつ運用ノウハウを内製に取り込み、診断リードタイム最大4週間短縮と累計数千万円規模のコスト削減を達成しています。すべてを自社で抱え込むのではなく、各レイヤーで最適な発注形態を選び抜いている点が、成果の本質です。
契約形態の選び分け（準委任・請負・伴走型支援）
内製化支援を依頼する際の契約形態は、大きく準委任契約・請負契約・伴走型支援契約（実態は準委任の応用形）の三つに分かれます。
- 準委任契約：要件が動く内製化フェーズに合います。
- 請負契約：要件が明確で、仕様変更が少ない案件に向いています。
- 伴走型支援契約：準委任の発展形で、レビューや採用支援、育成を含みます。
それぞれ責任の所在、成果物の定義、ノウハウ移転のしやすさが大きく異なるため、フェーズや目的に応じて選び分けることが欠かせません。誤った選択をすると、社内に何も残らないまま費用だけが膨らむ事態に陥ります。
準委任契約と請負契約の使い分け
請負契約は、完成責任をベンダー側が負う形態で、要件が明確でほぼ仕様変更がない案件に適しています。一方、準委任契約は業務遂行の善管注意義務を負うのみで完成責任は問われず、アジャイル型の継続的な開発や、要件が動きながら進化する内製化フェーズに親和性があります。
内製化のスタート期は、仕様が固まらないまま小さく検証を繰り返すため、準委任契約をベースに進めるのが定石です。請負で内製化を始めると、ベンダーは完成責任を逃れるために要件を厳しく固定し、「いつもの丸投げ」に逆戻りしてしまいます。ただし、決済機能や認証基盤など仕様が安定したノンコア領域では、請負で固定価格・固定納期を取り付けたほうが調達コストを無駄なく抑えられます。
フェーズ別には、PoCや初期プロトタイプは準委任、業務アプリの本番リリース直前で要件が固まった段階は請負、リリース後の運用保守・機能拡張は再び準委任、という三段ロケット型の組み合わせが現実的です。そのうえで、契約書に「中間成果物のレビュー基準」「定例会の頻度」「KPI未達時の見直し条項」を明文化しておくと、準委任が形骸化する事態を防げます。
伴走型支援契約の設計と落とし穴
伴走型支援契約は、技術顧問やPMO型ベンダーが社内エンジニアと並走し、設計・コードのレビューや採用支援、育成までを担う準委任の発展形です。月額固定で技術顧問を1〜2名アサインしてもらい、相談窓口・コードレビュー・採用面接の同席まで担ってもらうのが一般的です。星野リゾートがクラスメソッドと組んで計29%のAWS利用費を削減した事例や、カインズの段階的内製化も、この典型例と言えます。
伴走型契約の落とし穴は、契約書の作りが甘いと「ただ顧問料を支払うだけ」で形骸化することです。具体的には、月次の活動アウトプット（レビュー件数、社内勉強会開催数、ドキュメント整備数）をKPIとして定義し、四半期ごとに見直す条項を必ず盛り込みます。もう一つの注意点は、伴走者の「実働比率」を契約書に明記することです。
週2日相当・月8人日といった工数の下限を定めず月額契約だけ結ぶと、繁忙期に他案件を優先されてレビュー対応が後回しになりがちです。そこで、最低稼働日数と緊急対応SLAを明文化しておくことで、形骸化リスクを抑え込めます。さらに、伴走者が作るスライドや設計書、サンプルコードの著作権も発注者へ無償移転する条項を入れておかないと、契約終了と同時に成果物の二次利用ができなくなる事態が起きます。
著作権無償移転条項と知財設計の実装
内製化を本気で進める企業が見落としがちな最重要の論点が、著作権・知財条項の設計です。発注時にこの論点を曖昧にしたまま進めると、将来の内製拡大や他ベンダーへの引き継ぎ、第三者監査の場面でベンダーロックインが顕在化し、追加コストや交渉難航の原因になります。そのため、標準契約書のテンプレートに任せず、自社で必ずレビューする領域と位置づけるべきです。
ソースコード・設計書の無償移転条項
標準的なシステム開発契約では、ベンダーが作成したソースコードの著作権はベンダーに帰属し、発注者には「利用許諾」のみが与えられる構造になっているケースが多く見られます。この状態のまま内製化を進めると、後で社内エンジニアが同じコードベースを改修・公開・転用しようとした際に、法的にグレーゾーンへ踏み込んでしまいます。
これを避けるには、契約書に「本件成果物に関する著作権（著作権法第27条・第28条の権利を含む）は、対価の支払いと引き換えに発注者へ無償で移転する」旨を明記する必要があります。さらに「ベンダーは、発注者からの要求があれば本件成果物の修正・改変・第三者への再委託を妨げる行為（著作者人格権の不行使を含む）を行わない」旨の条項を加えると、将来の保守ベンダー切替時のリスクをほぼ封じ込められます。
移転対象は、ソースコードだけでなく周辺のドキュメントすべてに及ぶべきです。次のものが該当します。
- 要件定義書・基本設計書・詳細設計書
- ER図・シーケンス図・アーキテクチャ図（Mermaid.js等のソース含む）
- 運用手順書・障害対応マニュアル・テスト仕様書
- CI/CDパイプラインの設定ファイル・IaCコード
- 教育用スライド・社内勉強会の録画／録音
これらを「成果物」として契約書の別紙に列挙し、それぞれの著作権が発注者へ移転することを明文化します。
星野リゾートのように複数の外部パートナーを使い分ける企業ほど、この条項を厳格に運用しています。
OSS・SaaS・既存ライブラリ利用時の取り扱い
無償移転条項を強くしすぎると、ベンダーが業務効率化のために使うOSSや既存の社内ライブラリまで移転対象に含まれてしまい、ベンダー側も契約をためらう事態が起きます。そのため契約書では、「ベンダーが第三者から利用許諾を受けたソフトウェア・OSS・テンプレート」と「本件業務専用に新規開発した部分」を明確に区別し、前者は利用条件を踏襲、後者のみ無償移転とする整理が一般的です。
あわせて、SBOM（Software Bill of Materials）として利用OSSの一覧・ライセンス種別・脆弱性情報を成果物に含めることを必須化すると、内製化後の自社運用で脆弱性管理を引き継ぐ土台になります。カインズが脆弱性診断の内製化で累計数千万円規模のコスト削減を実現した背景にも、こうした「引き継ぎを前提とした成果物定義」が機能していました。
技術的負債20-30%固定枠とペアプロ/OJT条項
内製化プロジェクトが中長期で破綻する典型的なパターンは、機能追加に工数を割いて非機能要件やリファクタリングを後回しにし、気付いた頃にはコードベースに手が付けられない状態になっていることです。日本のIT投資の約8割が既存システムの維持・運営に費やされるという構造的な課題を踏まえると、内製化の初期段階から「負債を作り続けない契約設計」が必要になります。
開発工数の20-30%固定枠（リファクタリング・非機能要件）
総工数の20〜30%を、技術的負債の解消や非機能要件の改善に強制的に割り当てるルールを、契約書と月次計画書に明文化します。対象には、自動テスト整備やセキュリティアップデートも含みます。具体的には、スプリント計画で新規機能と負債解消のストーリーをほぼ7:3で並べ、後者を必ずバックログの最上位に維持する運用です。
この固定枠が機能すると、リリース後3年が経った時点でも改修コストの急騰を抑えられ、内製エンジニアの定着率も上がります。属人化で納期に支障を来した印刷業K社のように、特定の担当者が休むだけで業務が止まる事態を防ぐには、テスト・ドキュメントの整備に工数を強制的に割く仕組みが欠かせません。経営層への報告にも「負債消化率」を主要KPIとして含めると、目先の機能追加の圧力を相対化できます。
運用面では、四半期ごとに「負債バックログレビュー会」を定例化し、社内エンジニアと外部伴走者が共同で優先度を再評価します。ここで「触りすぎて壊れるリスク」と「放置するリスク」を秤にかけ、優先順位を組み替えていくサイクルを回します。Notion・esa・Confluenceなどのナレッジ基盤に意思決定の経緯を残す文化があるかどうかが、3年後の内製化成熟度を左右します。
ペアプログラミング・OJT条項の契約への組み込み
内製化支援契約で最も差別化に効くのが、ペアプログラミングおよびOJTを明示的に契約条項に組み込むことです。ベンダー側のシニアと発注者側のジュニアが、同一画面・同一リポジトリで一緒にコーディングする時間を、月次工数の中で何時間確保するかをあらかじめ取り決めます。たとえば「ベンダー稼働時間のうち最低30%をペアプログラミング・モブプログラミング・コードレビューに充てる」といった条文を入れる形です。
OJT条項では、月次の社内勉強会開催（最低1回）、技術記事の社内Notion投稿（月3本以上）、新人エンジニアのオンボーディング設計など、ナレッジ転写の活動を具体的なKPIとして組み込みます。これにより、ベンダーが「自分で書いたほうが早い」と社内エンジニアを置き去りにする事態を防げます。
あわせて、半年〜1年ごとに「自走度評価」を行い、社内エンジニアが要件定義から障害対応までのどの工程を独力で完結できるかを、スキルマップにまとめます。この評価結果に応じて次期契約のベンダー稼働比率を段階的に減らす前提を契約書に明記しておくと、後述のB-O-T方式へスムーズに移行できます。
B-O-T方式の応用と段階的内製化のマイルストーン設計
B-O-T方式（Build-Operate-Transfer）は、もともとオフショア開発や海外子会社の設立で用いられてきた手法です。ベンダーがいったん組織や仕組みを構築（Build）・運用（Operate）したうえで、最終的に発注者へ譲渡（Transfer）するモデルです。
これを国内の開発内製化に応用すると、外部支援を活用しながらも最終的に自走可能な内製チームを形成できる、強力なフレームワークになります。
Build／Operate／Transferの三段階設計
Buildフェーズでは、ベンダーが主導して開発基盤・アーキテクチャを整え、CI/CDやドキュメント構造も含めて初期プロダクトをリリースまで持っていきます。期間は6〜12カ月が目安です。この段階では、発注者側がジュニア層の1〜2名を専任で配置し、ペアプロを通じてキャッチアップしていきます。
Operateフェーズでは、運用と機能拡張を進めながら社内エンジニアの比率を段階的に高めていきます。具体的には、初期はベンダー7：発注者3で始め、半年ごとに6：4、5：5、4：6と入れ替えていく形で、12〜24カ月かけて自走できる工程を増やします。後半では、社内エンジニアがスクラムマスター・テックリードとして自律的に意思決定できる状態を目指します。
Transferフェーズでは、ベンダーは月数日〜週1日程度のスポット顧問形態に切り替わり、社内チームが本格的に開発・運用を主導します。移管対象は、ソースコードや運用手順書のほか、CI/CDの管理権限、クラウドリソースのオーナーシップ、緊急時のオンコール体制まで含みます。Transferが完了すると、ベンダーは「過去の伴走者」から「必要時のみ呼ぶ専門アドバイザー」へと役割が変わります。
マイルストーンKPIと撤退基準の設計
段階的内製化では、フェーズごとに具体的なマイルストーンKPIを設定します。たとえば、Buildフェーズの完了条件は「主要機能のテストカバレッジ70%以上」「リリース手順の自動化完了」「社内エンジニア1名が単独でデプロイ可能」とします。Operateフェーズへの移行条件は、「障害対応の一次受け対応を社内が50%以上担当」「主要ドキュメントの月次更新が社内主導で回っている」とします。
同時に、撤退基準（損切りライン）も契約書に明記しておくことが重要です。撤退基準の例は、「6カ月時点で要件の30%以上が未着手・凍結状態」「内製エンジニアの自走度評価が一定スコアを下回った状態が3カ月継続」「想定ROI回収シミュレーションが2倍以上ずれた」などです。これらの条件を満たした場合は、プロジェクト体制の抜本見直しまたはSaaSへの切り替えを検討する、という出口戦略を組み込んでおきます。
飲食業S社は、車輪の再発明で無駄なコストをかけました。これを防ぐため、Zapierなど既存のSaaSや連携ツールで3日で済む内容を自社開発していないかを定期的にレビューする「車輪の再発明監査」を、撤退基準の一部として組み込むと効果的です。Make、Zapier、n8n、kintone、楽楽精算などのSaaS群を常に選択肢の最上位に置く判断基準を持つことで、内製化スコープを適切に絞り込めます。
市民開発のガバナンス設計とシャドーIT対策
ノーコード/ローコードを活用した市民開発を発注設計と並行して進める場合、ガバナンスの仕組みづくりが極めて重要になります。日本企業の現場主導DXでは、「システム乱立・管理複雑化・コスト増加」のデメリット感が70.7%にのぼり、米国の47.1%を大きく上回ります。
つまり、市民開発を野放図に解禁すると、後でシャドーIT化したアプリケーションの収拾がつかなくなるという構造的リスクが、すでに顕在化しているといえます。
市民開発のアプリ申請・承認フローの契約への組み込み
外部支援ベンダーに伴走を依頼する際、市民開発の支援も契約スコープに含めるなら、アプリ申請・承認フローのテンプレートをベンダーから受けると効果的です。具体的には、現場が新しいアプリを作る際に提出する「アプリ申請書」に、目的と想定利用者数を書いてもらい、扱うデータの機密区分と業務影響範囲も明らかにしてもらいます。
情シスは承認チェックリストで、個人情報を含むか、業務影響度はどの程度か、保守責任者は誰かを確かめてから承認します。承認後のアプリは、CMDB（構成管理データベース）またはkintone・Notion等の社内アプリカタログに必ず登録し、利用ユーザー数や月次稼働状況を見える状態にします。
半年に一度の「アプリ棚卸し」で、利用されていないアプリは廃止し、業務影響度が高くなったアプリはIT部門による正式管理対象への昇格を判断する、というライフサイクル管理を回します。
セキュリティ・コンプライアンス対応の発注スコープ
市民開発が広がるほど、データ取り扱いに関するセキュリティ・コンプライアンスリスクは高まります。発注設計の段階で、外部支援ベンダーへの依頼範囲に「セキュリティガイドラインの策定」「アプリ別の脆弱性診断テンプレート」「アクセス権管理のレビュー」を含めておくと、市民開発に伴うリスクを継続的に抑えられます。
カインズが脆弱性診断を内製化して累計数千万円規模の削減を実現できたのも、こうしたガバナンス設計を発注段階から組み込んでいた成果です。そのうえで、ベンダー側に「セキュリティ運用フローの伴走支援」を契約スコープとして明記し、社内のセキュリティチームが診断・対策を回せるよう段階的に移管していくアプローチが効果的です。
まとめ
開発内製化の成否は、100%自前で進めるか外部に頼るかの二者択一ではなく、発注設計でノウハウを社内に移せる契約をどう組むかにかかっています。
準委任と請負を使い分け、伴走型支援契約にKPIと最低稼働日数を明記します。さらに、著作権無償移転条項でベンダーロックインを封じ、技術的負債20-30%固定枠で長期の維持コストを抑えます。ペアプロ/OJT条項では、ナレッジ転写を強制します。
これら一連の仕組みを契約段階で設計しておくことで、内製化プロジェクトは中長期にわたって自走力を高めていきます。
さらに、B-O-T方式を応用し、Build/Operate/Transferの三段階で外部支援の比率を計画的に下げていきます。そこに、撤退基準KPI・車輪の再発明監査・市民開発ガバナンスという守りの仕組みを組み合わせると、星野リゾートやカインズに匹敵する内製化成熟度を目指せる土台が整います。
発注書の一文一文が将来の自社のエンジニアリング資産を形作るという視点で、契約レビューに時間をかける価値は十分にあります。
riplaでは、コンサルティングから開発、運用、内製化支援まで一気通貫で伴走できる体制を整えています。自社の内製化ロードマップ設計や契約条項のレビューにお悩みの方は、ぜひお気軽にご相談ください。
▼RFP作成前に読みたい無料ホワイトペーパーはこちらをご覧ください。
・Webサービス開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブックをご覧ください。
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。