週8時間の社内IT担当で、どこまで作れる？システム開発の内製・外注・併用

開発体制の比較・記入シート（Excel）は「02_共通条件_空欄」で業務・期限・使える時間をそろえ、「08_判断表_空欄」で各案の選ぶ条件を比べます。不明な部分だけ、確認する担当者と質問を残してください。

「外注の見積りは高い。AIを使えば社内で作れるのではないか」。開発体制を選ぶとき、まず費用や実装の速さが気になるかもしれません。しかし、画面ができても、仕様を決める人や利用開始後に直す人がいなければ、業務で使い続ける準備は整っていません。

必要な機能を誰が作るかと、社内に残す判断を分けるのが出発点です。会社の人数やAIの利用有無に加え、担当者の技能と使える時間を確かめます。

内製は社内が開発の中心、外注は外部が中心、併用は工程や時期で両者を組み合わせる体制です。SaaS・パッケージ・独自開発という「何を使うか」とは別の軸で、組み合わせて考えられます。

内製・外注・併用を同じ項目で比べる

開発の中心をどこに置くかで、必要な社内時間と引継ぎ先が変わります。次は体制を考えるための比較です。外注でも、業務の優先順位や利用開始の判断は社内に残ります。

比較すること	内製が中心	外注が中心	工程・時期で併用
社内の時間・技能	作る・確かめる・直す時間と技術者を確保	業務説明・質問への回答・受入の時間を確保	社内が担当する工程の時間と技能を確保
仕様の決定	社内の業務担当と開発担当で決める	外部と具体化し、業務の条件は社内が決める	工程間の相談先と決定者をそろえる
実装・品質確認	社内が担当。難しい部分を相談できる先も決める	委託範囲と点検方法を契約前にそろえる	各工程の成果と、次へ渡す条件をそろえる
利用開始後の保守	担当者の通常業務に保守時間を含める	対応範囲・時間帯・費用を契約で決める	不具合の受付先を決め、社内外で切り分ける
担当者が不在のとき	社内の代替担当と引継ぎ資料	外部の副担当・交代条件と社内窓口	相手が不在でも扱える資料・権限・連絡先

週8時間の社内IT担当だけで、どこまで担えるか

20人が使う申請・承認・案件進捗のシステムで比べます（想定例）。初回公開の希望は着手4か月後、比較期間は公開後12か月までの計16か月、小改修は月1回です。4か月は希望時期であり、必要な工数を見積もった納期ではありません。

社内では業務責任者が週4時間、業務副担当が週2時間、IT担当が週8時間を確保できるとします。IT担当には小さなスクリプトの作成経験がありますが、Webシステムの設計・品質確認・復旧を担えるかは分かりません。追加エンジニアの採用は希望段階で、入社時期と技能が決まるまで確保済みの戦力には数えません。

障害時は1営業日だけ暫定台帳で業務を続け、復旧後の照合を業務副担当が行う想定です。翌営業日まで止まると、台帳の照合が通常業務と重なり、申請の承認と案件の引継ぎが遅れるため、この例では1営業日を対応の目安にします。夜間休日の即時復旧、決済、人命に関わる処理は対象外です。停止時の代替作業が成り立たない業務では、許容停止時間と復旧体制を先に見直します。

この条件では、社内が業務を決め、外部が開発・技術運用を担うB案を最初の相談候補にします。内製移行を目指すA案と、社内開発に限定支援を加えるC案も、後で同じ条件から比べます。採用予定や協力者を確保済みと数えないことが、選択を分けます。

週8時間をどう使うか：B案の仮の一週間

次は、社内IT担当の週8時間の使い道を考えるための仮配分です。実測値でも、この時間で開発できる量の見積りでもありません。

社内IT担当の作業	仮の時間
業務の例外を聞き、外部へ渡す	2時間
経験のある小さなスクリプトを直す	2時間
変更結果を業務の例で試す	1時間
外部担当と質問・予定を調整する	1時間
問い合わせや予定外の確認に備える	2時間
合計	8時間

この週は、新しいWeb機能の設計・実装を外部へ頼む配分です。問い合わせが予備の2時間を超えたら、小改修を翌週へ回すか、対象を減らします。障害の復旧まで社内の8時間で抱えず、事前に合意した外部の連絡先へ引き継ぎます。担当者が空き時間に開発を進める想定だけでは、問い合わせが増えた週の作業が決まりません。

週8時間の配分を候補先へ渡すときは、「外部が作る」だけでなく、社内が週1時間の点検で使う入力例と期待結果も合わせます。たとえば申請の訂正、代理承認、担当者不在の3場面を先に選ぶと、受入日に初めて例外を見つけることを減らせます。外部からは、試す版、操作、結果、未確認の条件を受け取ります。

連携を分担する場合には、注文登録が済み、後続だけが未開始の再現教材のように、誰がどの記録を見て再開を決めるかまで分けます。担当工程の表を、そのまま障害時の連絡・判断へ使えるようにするためです。

社内が決めることと、外部へ頼む仕事

申請・承認システムなら、「代理承認を認める条件」は業務側が決め、「誰にどの操作を許すか」は技術側と具体化します。外部に任せる場合も、質問に答え、業務で使えるかを判断する社内の窓口を置きます。助言や資料作成を委託する範囲と、社内が承認する範囲を決めておきます。

IPAの情報システム・モデル取引・契約書（第二版）は、契約不適合、報酬、成果報酬型準委任、協力義務、再構築対応などを別の論点として整理しています。「外注する」という選択と合わせて、依頼する仕事と双方の役割を具体化します。

次の表は、社内が業務判断を担い、外部が開発するB案の役割分担です。冒頭の想定例に基づき、外部の担当配置と対応条件は契約前に合意するものとします。要件は必要な仕事と条件、設計は実現方法、受入は業務で使えるかを試すことを指します。

B案の工程ごとの役割と、不在時の代替

工程	社内・外部・不在時の役割
要件	社内：業務責任者が目的・優先順位を決定。外部：主担当が仕様案・制約を整理。不在時：業務副担当が判断を代行。
設計	社内：IT担当が権限・連携条件を点検。外部：主担当が構成・データを設計。不在時：外部副担当と設計資料を共有。
実装・テスト	社内：IT担当が業務の例外を提供。外部：主担当が実装・技術テスト。不在時：外部副担当が変更内容とテスト結果を引き継ぐ。
受入・利用開始	社内：業務責任者が業務で試し、利用開始を判断。外部：主担当が不具合修正・公開作業。不在時：判断は業務副担当、作業は外部副担当。
運用・障害	社内：業務責任者が手作業への切替、IT担当が連絡。外部：主担当が調査・修正・復旧。不在時：業務副担当と外部副担当。対応時間帯も事前に合意。
引継ぎ	社内：IT担当が資料と操作の再現性を試す。外部：主担当がコード・手順・設定を説明。不在時：外部副担当も同じ資料で対応。

表の外部副担当は、不在時に対応する方法の一例です。業務を止められる時間と、手作業を続けられる期間に合わせて決めます。工程ごとに別人を採用する必要はありません。兼務する場合も、判断権限、使える時間、代替する人を工程別に残します。技術的な正しさの点検と、業務上の利用開始の判断を、それぞれ誰が担うか確かめます。

AIがあれば内製できるのか

AIを使う内製は、出力を評価し、問題が起きたときに止めたり戻したりできる体制かで判断します。GitHubのCopilot Agentsの公式資料は、機能開発・テスト・文書作成などの用途を示す一方、生成コードのレビューとテストを求めています。同製品の用途と注意点を示した資料で、内製化の成功率や費用削減率を示した測定結果ではありません。ツール選びも同じで、同じ課題でAI開発ツールを試す手順で比べると、自社の体制で扱えるかが見えます。

社内で試すなら、実データを使わない試作から始めます。権限に応じて操作できるか、同じ入力を繰り返したときや取消時に正しく動くかを確かめ、問題が起きたときに戻す方法も用意します。技術判断が難しい部分は、外部に見てもらう範囲と対応日を決めます。

委託費に、採用・兼務・保守の費用を加える

必要な機能、初回の利用開始時期、利用期間、変更頻度、対応時間帯をそろえます。そのうえで、委託費に加えて社内の採用・育成・兼務・管理・保守・引継ぎを並べます。次の表は、まだ分からない費用と問い合わせ先を洗い出すためのものです。16か月分の実見積りと社内時間がそろうまでは、三案の総額の順位は付けられません。

費用項目	含める作業・支出と問い合わせ先
採用	紹介料・求人費、面接・選考の社内時間。人事に採用計画と費用条件を聞く。
育成	教材・外部指導、本人と教える人の時間。育成担当、到達条件、指導範囲を決める。
兼務・社内開発	設計・実装・試験の時間と、元の仕事の代替。上長の稼働計画と担当者の業務一覧で見る。
外部開発	要件支援・設計・実装・技術点検の委託費。見積書で作業範囲と対象外を読む。
管理・業務の点検	仕様判断、会議、変更調整、利用前の試験。責任者の予定、決裁・変更の手順で見る。
保守・改修	監視、問い合わせ、更新、障害対応、小改修。保守の提案条件、対応時間と範囲を読む。
環境・AI利用	開発・実行環境、AIや外部サービスの利用料。対象プラン、利用量、請求条件を調べる。
引継ぎ・代替	資料整備、並行対応、復旧練習、担当交代。引継ぎ範囲、代替担当、実施費用を決める。

社内の時間を金額に換算する場合は、対象時間に社内で決めた時間単価を掛けます。表には計算に使った時間と単価も残します。追加の支出と既存社員の工数換算は区別し、同じ時間を給与の配分と機会費用の両方で足さないようにします。外部の見積りに含まれる点検作業を、別の費用欄へ再度計上することにも注意します。

利用開始後の改修や障害対応は、開発費に含まれるかを個別に聞いてください。IPA講演資料が紹介するアジャイル開発版モデル契約の範囲（PDF）は、本番環境へのリリース作業とシステム運用を含みません。これは当該モデルの範囲であり、実際に依頼する範囲は個別の契約で定めます。

採用前の人材や未提示の保守費は「不明」として残します。記入シートも、費用欄が埋まるまで総額を「未確定」と表示します。通常の担当交代に備える費用と、採用遅延で生じる保守延長費などの条件付き費用は、別の計画に分けて重複を避けます。

週8時間の条件で、三つの体制を選ぶ

変更の多さだけでなく、「変更内容を説明できる人」「技術的に直せる人」「直した結果を承認できる人」がそろうかを見ます。社内に残す知識も、業務ルール、設計の理由、復旧手順に分けます。コードの保管に加えて、引き継いだ人が実際に扱えるか確かめることが必要です。

週8時間の社内IT担当という同じ条件で、Aは外注から段階的に内製へ移す方法、Bは外注中心、Cは内製中心として比べます。外注中心でも業務判断は社内が担い、内製中心でも難しい部分は外部へ相談します。

比較項目	A：段階的な内製化	B：外注中心	C：内製中心
開発・運用	初期は外部。移行条件を満たした範囲を社内へ移す。	外部が開発・技術運用、社内が業務判断を担う。	社内が開発・運用。外部は指定した事項を点検。
採用・稼働	採用時期は不明。移行日を確約しない。	既存の社内担当が判断。外部の稼働は問い合わせが必要。	IT担当週8時間で必要な仕事を担えるか、技能と時間が不明。
不在時の代替	移行後の技術代替が不明。外部保守の継続も検討。	業務副担当と外部副担当。配置と対応条件を合意する。	業務副担当のみ。技術代替は未確保。
固有の費用	採用・育成・並行対応・保守延長。	社内管理・継続保守・担当交代。	社内開発時間・専門家の点検・緊急対応の別手配。
現時点の判断	初期外注は候補。内製への移行は保留。	条件付き第一候補。契約・見積りがそろってから決定。	現条件では見送り。技能と代替の確保後に再検討。

A案：外注から段階的に内製へ移す

移行日は、社内担当と代替担当が変更・テスト・公開・復旧を再現できる状態で判断します。コードに加えて、構成、設定、テスト、運用手順、必要な権限、第三者サービスの利用条件を引継ぎ対象にします。契約時に受渡し範囲と移行支援を相談し、条件を満たさなければ外部保守を続ける場合の費用も聞きます。外注先が開発会社か個人かで、担当者が替わるときの引き継ぎや保守の続け方も変わります（開発会社と個人への依頼の違い）。

B案：外注を中心に進める

主担当が不在でも復旧に着手できるようにします。対応者、連絡先、対応時間、資料と権限の共有を事前に合意します。1営業日という手作業で継続できる期間に対し、復旧見込みが合うかも聞いてください。保守契約があるというだけで、翌営業日までに復旧できるとは判断できません。外部に開発を任せる場合の進め方は、中小企業向けオーダーメイドのシステム開発で確かめられます。

C案：内製を中心に進める

社内が作り、外部には設計・セキュリティ・公開手順など、決めた事項の点検を頼みます。緊急復旧も頼む場合は、限定支援とは別に対応範囲と時間帯を決めます。社内で作る開発を、エンジニアに月ごとに相談しながら進める方法もあります（IT・AI月額サポート）。

結論が変わる条件

同じ費用でも、事業の中核技術を社内に蓄積したいなら、A案の共同作業や段階移行を重く評価します。採用を待てない納期なら、外部の着手可能日を聞いてB案を優先します。社内に技術代替ができればC案も再検討でき、B案で主担当が不在のときも、許容できる停止期間内に対応する方法が合意できなければ、第一候補という判断を見直します。副担当を置く方法のほか、資料と権限を引き継いだ別の保守先へ依頼する方法もあります。

役割と合わせて、変更の決め方もそろえます。IPA講演資料の変更手続きと契約書の別紙（PDF）では、アジャイル開発版について、通常の変更と契約の大枠を変える変更を分け、別紙に体制・役割分担・委託料などを書く構成を説明しています。日常の小改修と、追加費用や担当変更を伴う相談を分けて決める際の参考になります。

不明な費用と担当者を、相談前に書き出す

まず共通条件を一枚にまとめ、工程ごとに社内担当、外部担当、不在時の代替を記入します。役職名だけでなく、担当者名、使える時間、判断できる範囲まで書いてください。Excelには、共通条件、工程役割、総費用、判断表の記入済み見本と空欄版があります。

次に、費用の不明欄を問い合わせ先へ戻します。人事には採用予算・選考負担・入社時期の確度を、上長には兼務時間と元の仕事の代替を、外部の候補先には開発範囲・保守時間帯・担当交代時の条件を尋ねます。育成は受講予定に加えて、誰がどの作業をできれば任せるかまで決めます。

最後に「選ぶ条件」「いま選ばない理由」「結論を変える条件」を残し、金額と契約条件をそろえます。不明な欄を埋める担当と期限も決めておきます。

製品や開発方式そのものから選び直す場合は、SaaS・パッケージ・独自開発｜3年・5年の費用比較で「何を使うか」の条件もそろえられます。依頼範囲を相談する段階では、担当・不明点・希望時期をまとめた表を用意し、システム開発の範囲と見積りを相談する際の材料にできます。

相談内容に合うサービスを探す

参考出典

• IPA「情報システム・モデル取引・契約書（第二版）」：見直しのポイント。本文資料2025年4月8日更新、案内ページ2026年9月11日更新
• IPA「システム開発の健全化に向けて」：2025年4月24日講演資料、44〜48ページ。アジャイル開発版の契約範囲・変更手続き・役割分担（PDF）
• GitHub「Application card: GitHub Copilot Agents」：4. Intended uses、7. Limitations。2026年9月15日確認