LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

開発体制の見直しとは何か

開発体制の見直しとは、既存のシステム・アプリ開発における人員配置・役割分担・発注構造・使用ツールを点検し、品質を維持しながらコストを最適化する取り組みを指します。単なる人員削減や外注化ではなく、「誰が・何を・どこに・どうやって依頼するか」という体制全体を再設計する点が特徴です。

多くの企業では、開発プロジェクトが積み重なるにつれて体制が複雑化し、当初想定していなかったコストが発生するようになります。プロジェクト終了後も要員が残り続けるケース、複数のベンダーが並走して調整コストがかさむケース、内製と外注の役割が曖昧なまま二重作業が生じるケースは、体制見直しの典型的な動機となっています。

費用肥大化を招く4つの要因

開発体制のコストが膨らむ背景には、単純な「人件費の高さ」ではなく、体制そのものが生み出す非効率があります。よく見られる要因を4つに整理します。

多重下請けによるマージン積み重ね

元請（プライムベンダー）→ 一次下請け → 二次下請け → 三次下請けというように、開発作業が多層的に外注されると、各層でマージンが積み重なります。発注者が実際に支払う費用のうち、開発作業そのものに充てられる割合が下がっていきます。

日本のソフトウェア産業では、多重下請け構造が長年にわたって定着してきた経緯があります。大手ITベンダーが受注した案件を複数の協力会社に再委託し、さらにその先へと展開する形態は、プロジェクト規模が大きいほど層が深くなる傾向があります。発注企業が体制の実態を把握しないまま費用だけが増えているケースは、見直し対象として優先度が高くなります。

要員過多と稼働率の低下

プロジェクト立ち上げ時に確保した人員がピーク時の規模のまま維持されると、フェーズが移行しても費用が下がらない状態が続きます。設計フェーズには複数名の上流エンジニアが必要でも、保守運用フェーズに入れば少数精鋭で対応できる場合があります。

フェーズ移行に合わせた体制縮小を契約上実施しにくい場合、要員の「待機コスト」が発生します。特に一括請負ではなく準委任・SES（システムエンジニアリングサービス）型で複数名を常駐させている場合、稼働実態と費用のズレが生じやすくなります。

スキルミスマッチによる生産性低下

担当者のスキルセットと実際の作業要件が合っていないと、同じ作業に余分な工数が発生します。高単価のシニアエンジニアが定型テスト作業を担当している、クラウドネイティブ開発にオンプレミス専門者が配置されているといったケースが、スキルミスマッチの典型例です。

スキルミスマッチは「品質は問題ないが工数が多い」という形で現れるため、問題として顕在化しにくい面があります。月次コストをメンバー単位で確認し、作業内容と照らし合わせると見えてくる場合があります。

内製と外注の役割境界の曖昧さ

どこまでを社内で行いどこから外注するかの境界が不明確だと、同じ作業を内製チームとベンダーが並行して行う二重作業が起きます。要件定義・設計レビュー・テストの各工程で「一応確認してほしい」という依頼が積み重なると、外注費用と社内工数が両方増えていきます。

特に長期継続案件で担当者が変わった際に、役割の引き継ぎが不十分なまま「以前からやっていたから」という理由で維持されている作業分担は、見直しの余地がある場合が多くあります。

見直しの4つの観点：役割・内外製・地域・自動化

体制の見直しは、以下の4つの観点を組み合わせて進めると効果が出やすくなります。

役割の再定義：誰が何をするかを明文化する

見直しの起点は、現体制における各メンバー・ベンダーの役割を文書化することです。「何となくやっている」状態の作業を洗い出すと、担当が重複している箇所や、逆にカバーされていない箇所が見えてきます。

役割を再定義するときは、「コア業務（競争優位に直結する）」「ノンコア業務（外注・自動化を検討できる）」「境界業務（状況に応じて判断が必要）」の3区分で整理すると判断しやすくなります。この分類は後述する内外製の最適配分に直接つながります。

内製と外注の最適配分：コアとノンコアの分離

役割の再定義で「ノンコア」に分類された業務は、外注化・共有化の候補になります。一方でコア業務は、外注への依存度が高いと技術的なノウハウの流出や、ベンダー変更時の引き継ぎコスト増大につながります。

内外製の最適配分を検討するうえで、既存の外注先との契約形態も確認が必要です。一括請負は成果物に責任を持つ形態ですが、仕様変更が多い開発では変更対応費用が膨らみやすい面があります。準委任は柔軟に対応できますが、稼働管理を発注側が行う必要があり、管理工数が増えます。どちらの形態が現在の開発スタイルに合っているかを照らし合わせることが、見直しの一歩目になります。

ニアショア・ラボ型開発の活用：地理的コスト格差の利用

ニアショア開発とは、東京などの大都市圏以外の国内拠点（地方都市・離島・地方自治体特区など）を活用した開発委託を指します。大都市圏の人件費単価と比較して低コストで優秀な人材にアクセスできる場合があります。時差がなく、言語・法制度上のリスクもないことから、オフショア（海外委託）と比べてコミュニケーションコストを抑えやすい点が特徴です。

ラボ型開発は、特定のベンダーと専属チームを長期契約で確保する形態です。都度の見積もり・発注作業が不要になり、チームがプロダクトやシステムへの理解を深めながら継続的に開発できます。要員の入れ替えが少ない分、スキルミスマッチや引き継ぎコストが軽減される傾向があります。

ツール・自動化の活用：繰り返し作業のコストを圧縮する

テスト自動化・CI/CD（継続的インテグレーション・継続的デリバリー）パイプラインの整備・インフラのコード化（IaC：Infrastructure as Code）など、手動で繰り返していた作業を自動化することで、長期的に人件費を下げられる場合があります。

初期の自動化ツール導入・整備には工数がかかります。ただし、リリース頻度が高い・環境構築が頻繁に発生する・テストケースが多いといった開発では、中長期的に人件費削減効果が出やすくなります。自動化の優先度は「繰り返し頻度 × 手動工数」が大きい作業から検討するのが実務上のセオリーです。

費用削減の進め方：5ステップ

体制見直しを実際に進めるには、一度にすべてを変えようとするよりも、段階を踏んで進める方が体制崩壊のリスクを抑えられます。以下の5ステップが実務上の基本的な流れとなります。

ステップ1：現状の体制・費用構造を可視化する

まずは現在の体制を「誰に・何を・いくらで・どのくらいの期間」依頼しているかを一覧化します。ベンダー別・工程別・要員別にコストを整理すると、どの部分の費用が大きいかが見えてきます。

このとき、契約書・発注書・稼働報告書を横断して確認する必要があります。複数のベンダーが関わっている場合は、全体コストを把握している担当者が社内にいないケースもあります。把握できていない部分は、ベンダーに問い合わせて実態を確認することが出発点になります。

ステップ2：無駄コストの発生源を特定する

可視化した費用構造をもとに、先述した4つの要因（多重下請け・要員過多・スキルミスマッチ・役割境界の曖昧さ）のどれが自社の体制に当てはまるかを確認します。

稼働実績と請求費用を照合すると、期待稼働率に対して実際の成果物が少ない工程が見えてくる場合があります。ベンダーの担当者から「誰が何をやっているか」を聞き出す1on1形式のヒアリングも、表面化しにくい問題を把握するうえで有効です。

ステップ3：役割と内外製区分を再定義する

特定した問題をもとに、「変えるべき部分」と「維持すべき部分」を切り分けます。プロジェクトのコア工程に関わるメンバーを不用意に削減すると品質リスクが高まるため、まず「ノンコア・定型業務」から見直しの対象にすることで、品質リスクを抑えながら進められます。

再定義後の役割は、ベンダーとの契約内容に反映させます。SES契約の場合、担当業務の範囲を明文化して合意しておくことが、後のトラブル防止につながります。また、内製化を進める場合は、必要なスキルセットを事前に整理し、採用・育成計画とセットで検討する必要があります。

ステップ4：新体制でパイロット実施する

いきなり全体を切り替えるのではなく、1つのプロジェクト・1つの工程に絞って新体制を試す期間を設けることを推奨します。パイロット期間中は、品質・コスト・スケジュールを旧体制と比較できる形で計測します。

パイロット対象は「改善余地が大きく、かつ失敗した場合のビジネス影響が限定的な案件」が適しています。基幹システムの本番移行案件などはパイロットに向きません。新規機能開発や保守運用の一部工程から始めると、リスクを抑えながら効果を確認できます。

ステップ5：効果測定と全体展開

パイロット期間終了後、コスト・品質・速度の三軸で効果を測定します。期待した効果が出ている場合は対象範囲を広げ、課題があった場合は改善してから展開します。

見直し後の体制は、半年〜1年後に再点検する仕組みを作っておくと、環境変化に対応しやすくなります。開発量の増減・新技術の導入・事業戦略の変化に合わせて体制を柔軟に調整できる状態を保つことが、継続的な費用最適化の前提となります。

見落としやすい3つの注意点

体制見直しを進める際には、コスト削減ばかりに目が向いてリスクを見落とすことがあります。実務上、特に注意が必要な3点を挙げます。

注意点1：削減しすぎると保守品質が低下するリスク

要員を削減しすぎると、障害対応・セキュリティパッチ適用・バージョンアップといった保守作業の担当者が手薄になります。平常時は問題なく見えても、大きなインシデントが発生したときに対応が追いつかなくなるリスクがあります。

特にシステム全体の仕様を把握しているベテランエンジニアがいなくなると、ブラックボックス化が進み、後の改修コストが増大します。コスト削減の効果が短期的でも、中長期の維持コストが上がるケースは費用削減として機能していません。

注意点2：ベンダー変更時の引き継ぎコストを試算する

多重下請けの解消や外注先の見直しに際して、既存ベンダーから新しい委託先への引き継ぎには相応のコストと期間が必要です。ドキュメントが整備されていない場合や、ソースコードのバージョン管理が適切でない場合は、引き継ぎ期間が長くなります。

引き継ぎコストを事前に試算せずに切り替えを実施すると、「見直し前より一時的にコストが増える」状況が発生します。切り替えのタイミングは、業務の閑散期または大きなリリース直後の安定期を選ぶのが実務上の定石です。

注意点3：内製化は採用・育成コストとのセットで検討する

外注から内製化にシフトする場合、エンジニアの採用・育成に時間がかかります。採用市場でIT人材の競争が続いている現状では、必要なスキルセットを持つ人材をすぐに確保できない場合があります。

内製化は「外注費用が下がる」と同時に「採用費・教育費・雇用維持コスト」が発生します。採用までの空白期間に業務が滞るリスクもあります。コスト比較は外注費用と人件費の単純比較ではなく、採用コスト・育成期間・定着率も含めた中長期での試算が必要です。

内製化・外注・ニアショアの費用比較の考え方

開発体制の選択肢は、大きく「内製化」「都市圏外注」「ニアショア外注」の3形態に整理できます。それぞれの費用特性を比較することで、自社の状況に応じた配分の判断材料になります。

費用レンジについては、市場参考値であり一次資料ではないため、ここでは断定的な数値は掲載しません。実際の単価は地域・スキル・契約形態・プロジェクト規模によって大きく異なります。相見積もりと実績ベースでの比較検討が、精度の高いコスト試算につながります。

3形態を組み合わせるハイブリッド体制も有効です。コアの設計・アーキテクチャ判断は内製チームが担い、実装・テストはニアショアのラボ型チームに任せ、スポット的な高度スキルが必要な場面だけ都市圏外注に依頼するという形が、費用と品質のバランスを取りやすい構成の一例です。

元請（プライムベンダー）に一元管理させることで管理コストを下げる

複数のベンダーを自社で個別に管理する体制では、各ベンダーとの調整・品質確認・進捗管理にかける社内工数が積み重なります。元請（プライムベンダー）として複数ベンダーを束ねる立場の事業者に一元管理を委ねる形を選択すると、社内の管理工数を削減しながらも品質を担保しやすくなります。

一元管理を委ねる場合は、元請事業者の管理能力・協力会社ネットワーク・過去の類似案件実績を評価指標にすることが重要です。また、元請事業者が多重下請けを深くしないかどうかを、契約段階で確認しておくことも費用の透明性を保つうえで欠かせません。

まとめ：体制見直しで押さえる3つの判断軸

開発体制の見直しによる費用削減を進めるうえで、判断の軸となるポイントを3つに整理します。

第一に、「コスト肥大化の発生源を特定すること」です。多重下請け・要員過多・スキルミスマッチ・役割境界の曖昧さのいずれが主因かによって、見直しのアプローチが異なります。体制を可視化しないまま手を付けると、別のコストが増える「モグラたたき」になりがちです。

第二に、「内外製の最適配分をコア業務基準で決めること」です。コア業務を外注化するとノウハウが流出し、後の体制変更コストが上がります。ノンコア業務を内製し続けると余剰人員コストが積み重なります。「何が競争優位に直結するか」を判断基準に持つことが、適切な配分の前提となります。

第三に、「短期コストだけでなく中長期コストを試算すること」です。ベンダー変更・内製化移行・自動化投資はいずれも初期コストを伴います。パイロット実施と効果測定を組み込んだ段階的な進め方が、見直しの失敗リスクを下げます。

よくある質問

開発体制の見直しはどの工程から始めるのが現実的ですか？

ビジネス影響が限定的なノンコア・定型業務の工程から始めるのが現実的です。具体的には、テスト工程・環境構築・定例報告の作成といった繰り返し作業から手を付けると、品質リスクを抑えながら効果を確認できます。基幹システムの設計・要件定義といったコア工程は、体制が安定してから対象にすることを推奨します。

多重下請けを解消したい場合、どのような手順を踏めばよいですか？

まず現在の外注先の構造（一次・二次・三次の層と各社の役割）を可視化することが出発点です。次に、各層のコストと実際の作業量を照合し、どの層でマージンが積み重なっているかを確認します。解消の方法は「元請（プライムベンダー）を直接の管理窓口に絞る」または「発注者が一次委託先を直接管理できる形に変える」の2通りが実務上多く見られます。切り替えの際は、既存ベンダーとの契約期間・引き継ぎ計画を事前に整理することが重要です。

ニアショア開発を活用すると費用はどの程度変わりますか？

費用の変化幅は地域・スキル・契約形態・プロジェクト規模によって異なるため、断定的な数値はお伝えできません。ただし、ニアショア（地方拠点）は都市圏と比べて人件費単価が抑えやすい傾向があり、ラボ型で長期安定稼働させることで1人あたりの管理コストを分散できます。実際の費用比較には、候補先ベンダーから条件を揃えた見積もりを複数取得することが確度の高い判断材料になります。

内製化とニアショア外注はどちらが費用削減に向いていますか？

一概にどちらが優れているとは言えません。内製化は採用・育成コストが先行し、スケールアップにも追加採用が必要ですが、ノウハウの蓄積や機密情報の管理がしやすくなります。ニアショア外注は変動コストで柔軟に対応できる一方、ベンダー管理の工数や引き継ぎコストが発生します。コア業務は内製・ノンコア業務はニアショア外注というハイブリッド配分が、費用と品質のバランスを取りやすい構成です。中長期コスト（採用費・育成費・定着率も含む）で比較することを推奨します。

体制見直し後の品質低下を防ぐにはどうすればよいですか？

体制見直し後の品質低下を防ぐには、コア工程の担当者を削減しないことと、引き継ぎドキュメントを整備してからベンダー変更を行うことが基本です。また、パイロット期間を設けて品質指標（不具合件数・対応時間・リリース遅延率など）を旧体制と比較してから全体展開することで、品質リスクを可視化できます。新体制開始後も半年〜1年を目安に定期的な体制レビューを行う仕組みを設けることを推奨します。

著者：テレリモ総研編集部　鈴木 亮佑

---

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：独立行政法人情報処理推進機構（IPA）「DX白書2023」（2023年3月公表）— ITシステム開発における体制・人材・技術の動向を分析。IPA DX白書2023（概要ページ）