「コスト削減」は未達。それでも開発内製化が大きな価値を生んだ理由。
公開日

外部の専門知識を活用でき、コスト削減も期待できるアウトソーシングは、多くの企業にとって魅力的なIT戦略です。しかし一方で、「想定したほどコストが下がらなかった」「ベンダーコントロールが難しく、開発スピードが遅い」「システムの所有権が自社になく、主体的な改善ができない」といった課題に直面するケースも少なくありません。そこで注目されるのが、一度アウトソースした業務を再び組織内に戻す「内製化」への転換です。
本記事では、学術誌『Empirical Software Engineering』に掲載された論文「Bringing it home: successful backsourcing of software development in the public sector」に基づき、ノルウェーの大規模な公的機関がソフトウェア開発の大部分を内製化した詳細な事例研究を紹介します。コスト削減を旗印に始まったこの巨大プロジェクトは、一体どのように進められ、どのような成果と課題を生んだのでしょうか。
事例の概要:ノルウェー労働福祉局(NAV)とは?
今回の事例の舞台は、ノルウェーの労働・福祉行政を担う政府機関「Norwegian Labour and Welfare Administration(NAV)」です。NAVは国の予算の3分の1を管理し、失業、育児、年金など40以上の給付金サービスを提供しています。その業務はITシステムに大きく依存しており、設立当初は約300のITシステムと約600の関連契約を抱えていました。
これらのシステムの開発と保守は、大部分が外部のベンダーにアウトソースされていました。しかし、高額な開発・保守コストが問題視されるようになり、組織内で内製化への機運が高まっていきます。この研究は、NAVの現職および元ITディレクターを含む61人の関係者への詳細なインタビューと、内部文書の分析に基づいており、大規模な内製化のリアルな実態を明らかにしています。
内製化への転換:最大の動機は「コスト削減」
NAVが内製化という大きな決断に至った背景には、複数の動機がありました。その中でも最も大きな推進力となったのが、ITコストの削減でした。
主な動機:高コスト構造からの脱却
最大の動機は、コンサルタントの人件費と、アウトソーシングモデルに起因するプロセスの非効率性による高いITコストでした。論文によると、開発者一人当たり年間100万ノルウェークローネ(約10万米ドル)のコスト削減が見込まれていました。
また、アウトソーシングモデルでは、発注者(NAV)と受注者(ベンダー)の双方にプロジェクトマネージャーやテスト担当者が存在するなど、役割の重複による無駄なコストが発生していました。仕様の交渉や見積もり、報告といった管理業務に多くの時間が費やされ、本来の開発作業そのものにかける時間や費用を圧迫していたのです。
副次的な動機:失われたコントロールとスピードを取り戻す
コスト問題に加えて、組織は複数の副次的な課題も抱えていました。
- 所有権とコントロールの欠如: システムの仕様変更や修正をしようにも、その都度ベンダーとの交渉が必要でした。NAVの担当者は開発プロセスを直接コントロールできず、ベンダーの提案を信頼するしかない状況に不満を抱いていました。
- 開発スピードの低下: 軽微なバグ修正一つをとっても、「これは契約範囲内の修正か、新たな変更要求か」という議論に多くの時間が費やされ、迅速な対応が困難でした。
- 技術的負債の蓄積: ベンダーには、コードの品質を長期的に改善するインセンティブが働きにくく、見えない「技術的負債」が徐々に蓄積していくことへの懸念がありました。
これらの課題を解決し、IT開発の主導権を組織内に取り戻すため、NAVは内製化へと舵を切ったのです。
成功の鍵:内製化を推進した6つの指導原則
NAVの内製化は、トップダウンで詳細な計画を押し付けるのではなく、組織全体で共有された6つの指導原則に基づいて、各部門が自律的に実行するというアプローチを取りました。
原則1:明確な内製化戦略を策定し、組織全体で共有する
まずIT部門が中心となり、「どのシステムを内製化し、どのシステムを外部サービス(SaaS)に移行し、どれをアウトソースし続けるか」を分類するための明確なソーシング戦略を策定しました。この戦略は上層部の承認を得て、組織全体に広く伝達されました。これにより、内製化の目的とゴールが組織内で共有され、変革への抵抗を減らし、関係者の協力を得ることができました。
原則2:現場の裁量を尊重し、自律的な実行を促す
組織全体で画一的なプロセスを強制するのではなく、システム領域を管理する各部門に、内製化を「いつ、どのように進めるか」という大きな裁量権を与えました。これは、計画段階で時間をかけすぎる「分析麻痺」を避け、現場の状況に合わせた柔軟な実行を可能にするためです。このアプローチにより、従業員の当事者意識を高める効果もありました。
原則3:採用と再教育により、有能な内部組織を構築する
内製化の成功には、開発を担う有能な内部組織が不可欠です。NAVは、外部市場からの積極的な人材採用と、既存の内部人材の再教育という両輪で能力開発を進めました。特に「年金システムのJava開発者」のように具体的なポジションを提示する採用活動が功を奏し、多くの優秀な人材を惹きつけました。また、プロジェクトマネージャーがチームリーダーへ、技術アドバイザーが開発者へと役割を変えるなど、多くの職員が新たな役割へと移行しました。
原則4:採用や契約管理など、主要プロセスを組織的に支援する
各部門が変革に集中できるよう、専門知識が必要なプロセスは組織横断の専門チームが支援しました。例えば、人事部門は大規模な採用活動を主導し、契約管理チームは既存のベンダーとの契約内容を内製化に適したものへと再交渉しました。これにより、現場のリーダーの負担が軽減され、変革がスムーズに進みました。
原則5:ベンダーを敵ではなくパートナーとして扱う
NAVは、既存のベンダーとの良好な関係を維持することを重視しました。契約を一方的に早期終了させることはせず、契約期間が満了するタイミングに合わせて段階的に内製化を進めました。知識移転のプロセスではベンダーと密に協力し、内製化後も新たな契約形態で一部のコンサルタントがチームに残り続けるなど、パートナーとしての関係を継続しました。この協力的な姿勢が、円滑な移行の鍵となりました。
原則6:一度にすべてではなく、段階的に所有権を引き継ぐ
大規模システムを一度に引き継ぐ「ビッグバン・アプローチ」のリスクを避け、システムごと、あるいは機能ごとに段階的に所有権を移管するアプローチを取りました。まず知識移転を行い、内部チームが十分なスキルを習得したと判断された時点で、正式に責任がベンダーから内部チームへと引き継がれました。このインクリメンタルな進め方が、サービスを停止させることなく、安全な移行を実現しました。
(参考)内製化の具体的な進捗
これらの原則に基づき、内製化は複数のシステム領域で並行して進められました。下の図表は、各領域の内製化にかかった期間と、それに伴う組織(特に開発者)の成長を示しています。
図表1: 内製化のタイムライン
図表2: 組織構築の推移(2017-2021年)
内製化がもたらした変革とその成果
約3年間にわたる内製化の取り組みは、NAVに多くの変化をもたらしました。当初の目的であったコスト削減は達成されたのでしょうか。そして、それ以外にどのような成果があったのでしょうか。
コスト:想定されたコスト削減は実現せず
意外なことに、最大の動機であった「コスト削減」は、明確な形では実現しませんでした。下の図表が示すように、IT人材に支払われる総費用は内製化の前後でほぼ横ばいでした。
図表3: デジタル化に関するコストと工数の推移
しかし、これは失敗を意味するものではありません。同じコストで、より高価な外部コンサルタントから安価な内部の人材へとシフトした結果、組織はより多くの人員(工数)を開発に投入できるようになりました。つまり、「同じ金額で、より多くのことができるようになった」と言え、生産性は向上したと考えられます。
開発スピード:デプロイ数が劇的に増加
最も劇的な成果が現れたのが開発スピードです。かつては年に4回のメジャーリリースが中心でしたが、内製化後は継続的デプロイメントが導入され、開発者が日に何度も本番環境にリリースできるようになりました。下の図表は、月間のデプロイ数が2019年頃から爆発的に増加していることを示しています。これは、無駄な管理プロセスが削減され、チームが自律的に意思決定できるようになったことの証です。
図表4: アプリケーション領域ごとのデプロイ数の推移
品質:インシデント数が大幅に減少
システムの品質も向上しました。下の図表は、ユーザーから報告されるインシデント(障害など)の数が、2018年以降、明確な減少傾向にあることを示しています。これは、開発チームが自ら開発したシステムの品質に直接責任を持つようになったことや、問題発見時に迅速に修正・デプロイできるようになったことが要因と考えられます。
図表5: 四半期ごとのインシデント発生数の推移
組織文化:所有感とモチベーションの向上
数値には現れない最も大きな成果の一つが、組織文化の変化でした。従業員は「自分たちのシステムを、自分たちで開発・改善している」という強い所有感と責任感を持つようになりました。これにより、従業員のモチベーションは大幅に向上しました。事業部門の担当者がプロダクトオーナーとして開発チームに加わることで、部門間の壁が低くなり、よりユーザーのニーズに寄り添った開発が可能になりました。
避けては通れない3つの課題
この成功の裏で、NAVは多くの困難にも直面しました。内製化を検討する上で、これらの課題は非常に参考になります。
課題1:大規模な「変更管理」の難しさ
内製化は単なる契約の変更ではなく、組織全体の働き方を変える大規模な変革です。この変革はIT部門が強力に主導しましたが、その影響範囲の広さが当初は十分に理解されていませんでした。特に、システムの所有者である事業部門の巻き込みが遅れ、彼らが変革の当事者意識を持つまでに時間がかかりました。
課題2:「コンピテンシーとリソース」の確保
有能な開発者を外部から採用するのは困難を極め、一部の内製化計画が遅延する原因となりました。また、既存の職員を新たな役割(特にプロダクトオーナー)へ移行させる際の再教育やサポートも大きな課題でした。事業部門が多忙を理由に、開発チームに専任のプロダクトオーナーを提供することをためらうケースも見られました。
課題3:IT部門と事業部門の「組織的な緊張」
変革期において、IT部門だけが大規模な採用を許可され、組織が急拡大した一方で、他の事業部門は人員削減や採用凍結に直面していました。この状況は、部門間の不公平感や嫉妬といった組織的な緊張を生み出しました。「なぜITだけが」という感情が、部門間の協力関係に影を落とす場面もありました。
まとめ:NAVの事例が示す内製化成功への道筋
ノルウェー労働福祉局(NAV)の事例は、内製化が単なるコスト削減策ではなく、組織のIT能力を再定義し、開発のスピード、品質、そして組織文化を根本から変革する力を持つ戦略的な取り組みであることを示しています。
当初の目的であった「コスト削減」は明確には達成されませんでしたが、同じコストでより多くの開発工数を確保し、デプロイ頻度の劇的な向上とシステム品質の改善という、それを上回る価値を生み出しました。
この成功の裏には、
- 明確な戦略の共有
- 現場への大幅な権限移譲
- ベンダーとの協力的なパートナーシップ
- ビッグバンを避けた段階的な移行
といった、慎重かつ戦略的なアプローチがありました。同時に、事業部門の巻き込みの遅れや、部門間の緊張といった、大規模な組織変革に特有の課題も浮き彫りになりました。
ソフトウェア開発のアウトソーシングに課題を抱え、内製化を検討している組織にとって、NAVの経験は、その光と影の両面から、成功への道筋を照らす貴重な指針となるでしょう。
開発生産性やチームビルディングにお困りですか? 弊社のサービス は、開発チームが抱える課題を解決し、生産性と幸福度を向上させるための様々なソリューションを提供しています。ぜひお気軽にご相談ください!
参考資料: