2024年11月27日にオンラインセミナー『ゼロからはじめる内製化 どこまで社内でできるのか？効果的な推進方法を解説。』を開催いたしました。
この記事では当日用いた資料を公開し、そのポイントを解説しています。
目次
内製化とは
内製化の対義語はなんでしょうか？
内製化（Insourcing）の対義語は、外注・アウトソーシング（Outsourcing）です。
では、「内製化する」とは、どういう状態を指すのでしょうか？
内製化する＝システム開発の外注・アウトソーシングを「やめる」ことを指します。
内製化の検討にあたっては、「なぜ今まで外注してきたのか」という理由に着目する必要があります。
アウトソーシングの狙い
かつてアウトソーシングには、大きく次の二つの狙いがありました。
- システム開発業務が非競争領域であり、ITの専門知識が必要なものであるため、自社で人材を抱えるのではなく社外の専門家に任せたいという狙い
- 外部化による業務の効率化と、人件費の最適化（ITを専門とする企業に外注することで経験の集約が起こり、効率的なシステム開発が実現できることに加え、繁閑の差が大きいシステム開発業務を外注することで人件費を最適化する）
アウトソーシングのデメリット
このようにして始まったアウトソーシングですが、デメリットもあります。
一点目は、ノウハウが自社に蓄積されないこと。アウトソーシングは、一度作ったものを次のシステムに活かす、というようなことが非常にしにくくなっています。
二点目は、煩雑な業務を依頼するとコストが肥大化するということです。細かい仕様を伝えるためにコミュニケーションコストが発生することに加え、当初の予定から変更が起こった場合、簡単には行えず余計なコストがかかってしまうことなどが挙げられます。
かつては、ITの知見を自社に貯めることや、システムの柔軟性（素早く細かい変更を行えること）の重要性があまり意識されていなかったため、こういったアウトソーシングのデメリットはあまり問題視されてきませんでしたが、DX化の流れでデメリットが顕在化してきたため、内製化へと切り替える契機になりました。
内製化の狙い
先ほど「アウトソーシングの狙い」で述べた背景とは反対に、内製化の文脈ではシステム開発業務は競争領域と捉えられます。また、自社の特徴や強みをシステムに落とし込む必要が出てくるため、ITの専門知識だけでなく、業務知識も重要になってきます。更に、競争に勝つためにより複雑な機能、より柔軟なシステムが求められるようになるため、システムに対する要求が複雑化し、その結果外注コストが肥大化する傾向が強くなります。これらを回避するために、内製化が注目されるようになったという背景があります。
内製化のメリット
内製化をする上で最大のメリットは、競争優位性の確保です。
内製化の一番のメリットとしてコスト削減を挙げられる方も少なくないとは思いますが、内製に切り替えるための一時的なコスト増大を飲み込んででもシステムの内製化に取り組む企業が増えているため、競争優位性の確保は最も重要な概念と考えてよいでしょう。
具体的には、独自性の高いシステムにするための業務知識が反映しやすいことや、実際の使用や市場調査などを踏まえて、開発途中でも仕様変更を行うといった変化への対応がしやすいこと、またこれらに対応するスピードを向上させやすいことなどが内製化のメリットと言えます。
もちろん、より複雑な機能や柔軟なシステムの開発が求められる場面で、肥大化しがちな外注コストの最適化も、メリットのひとつとして挙げられます。
内製化のデメリット
一方で、内製化のデメリットとしては、体制構築・維持のコストがかかることが挙げられます。
これまで外注していたものを全て内製に切り替え社員で賄おうとした場合には、大勢の社員を雇用することになり、一時的な採用コストが大きく発生する上に、体制の維持コストが膨大になるといった問題が考えられます。このように、これまで外注していたものをすべて内製化するというような愚直な進め方は、コストの問題に直面しやすいです。
後ほど、こういった問題を回避するため、内製と外注を組み合わせた組織の作り方についても考えていきます。
なぜ今、内製化なのか
会計システムをはじめとした基幹システムなどは他社と比較して特色を出したい領域ではなく、非競争領域と見なされてきました。一方で、DXの時代に入り、新たなデジタルサービスを立ち上げるために開発されるようなシステムは、多くの場合他社との競争が求められるものになっています。
DXの時代は不確実性が高いとよく言われますが、そのような時代に求められるのは事業に最適化されたシステムであり、変化に強いシステム作りです。システム開発力がビジネスの競争力に直結する時代において、内製化は有効な手段だと考えられます。
また、システムにできることは増加し続けており、特に最近は生成AIの台頭によりITシステムでできることの幅が格段に広くなり、それに伴いシステムに要求されることもより多様化しています。このような状況下で、どのようにして内製化を進め、DX時代のシステム開発に適応していけばよいのでしょうか。
どこから内製化するか
まずは、どこから内製化していくかを考えていきましょう。
上図は、システム開発における各フェーズをまとめたものです。
- 最初に、システム化の計画をします。どういうシステムを作るか、どのシステムにいくら投資するかなどを計画する、経営に近い領域です。
- システム化するものが決まったら、どのような機能を実現するのか、要件定義を実施します。
- どんなシステムを作るかが決まったら、次は実際にモノづくりを始めていきます。システム開発の領域です。
- 作って終わりになることは非常に少なく、リリース後もどんどん進化させていくことが求められます。システムの保守や機能改善を行うフェーズです。
内製化におけるシステム化計画と要件定義
これら4つのフェーズのうちまず内製化すべきなのは、はじめの2つ「システム化計画」「要件定義」です。システム化の計画は社内で実施されている企業が多いと思いますが、要件定義までしっかりと行えている企業は意外と少なく、外部ベンダーに依存しているのではないかと思います。要件定義においてシステムの理解はもちろん必要ですが、それ以上に業務知識をどのようにシステムに落とし込むかということが重要になってきます。そのため、自社で内製化チームを作って、要件定義を行えるようになるのが理想です。
内製化におけるシステム開発と保守・機能改善
「システム化計画」と「要件定義」は、内製化を考える際に非常に優先度が高いということが分かりました。その上で、続きの「システム開発」「保守・機能改善」をどう内製化していけばよいのでしょうか。
個人的には、「保守・機能改善」といった維持・成長に関する部分だけを内製化するというのが一つの手ではないかと思います。形にするところまでは外部ベンダーに一気に作ってもらい、その後を引き継いで、改善していくのは社内のエンジニアで行うといったイメージです。
システム開発のどこから内製化するか
では、「システム開発」を担うモノづくりのフェーズを内製化する場合、モノづくり全体のうち、どこから内製化に着手するのがよいでしょうか。これを考えるために、一つの軸を用意します。
上図では、ビジネス面の変更に対し、システムがどれだけ適応を求められるのかを「ビジネスへの変更適応度」として縦軸に取っています。図に示したように、ビジネス面の変化に伴う適応の要求が大きい領域を内製化の注力領域として、徐々に要求が小さいものへと拡大していくのが効果的です。
また、上図左の表では「技術・スキルの変化」を横軸に取っています。これは技術やスキルの変化のスピードを表しています。例えば、フロントエンドの技術はバックエンドやデータベースと比べて変化が早いと言われています。常に新しい技術に対応するのはコストがかかるため、変化のスピードが遅い分野を内製化した方が、コスト的には有利になるということを示しています。
次に右の表を見ていきましょう。縦軸は左の表と同じ「ビジネスへの変更適応度」ですが、こちらの表では横軸は取らず、開発領域で分けています。この中で一番ビジネスへの変更適応度が大きいのがUIの部分です。UIは特にコンシューマー向けサービスにおいては変更の要望が多く出るところでもありますし、ユーザーに見える部分なので、ビジネスとして「変わった」ということを一番大きく伝えられるレイヤーとして一番上にしています。
続いて、同じくらい変更適応度が大きいのがフロントエンドです。ここではフロントエンドとUIを切り離して表していますが、この２つは実際には混じり合っている領域です。UIを機能ではなく見た目を指す言葉とした場合、機能を付加したり変更したりするのがフロントエンドになるので、このように表しています。
その下のバックエンド、データベース、インフラは、下に行くにつれてビジネスによる変化を受けにくくなります。ビジネスが変わることによってデータモデル（データベース）が変わることも当然ありますが、頻度としてはあまり高くありません。一方で、業務フローを変えるとバックエンドのAPIが変わるということはよくありますし、業務フローを変えずにユーザーへの見せ方だけを変える場合にもフロントエンドは変わってきます。そして、先にも触れたように使い勝手や見た目の良し悪しで差別化を図るために、UIが一番変化の可能性が高いということでこのような並びになっています。
この中で、どこから内製化を始めるかといえば、やはり上部の「UI」や「フロントエンド」から着手するのが得策かと思います。先ほど、フロントエンドはスキルの変化のスピードが早いという問題点を挙げましたが、それでもビジネスへのインパクトが大きい領域のためやらざるを得ない、ということが言えそうです。
どこから内製化するか―まとめ
これらを踏まえてどこから内製化するか検討すると、工程の最上流の「要件定義」と、ユーザーとのコンタクトポイントである「UI」「フロントエンド」に優先的に取り組んで行くのがよさそうであることが分かりました。人材確保の観点からも、まずは社内で要件定義ができるようになることが優先事項になります。
開発の専門知識が必要な領域では、変更回数が多く、ビジネスへの影響が大きいUI・フロントエンドの優先度が高くなっています。反対に、一度決めてしまえば大規模な変更の少ないインフラやデータモデリングは、内製化の取り組みにおいて優先的に着手すべき領域ではないでしょう。
内製化が向いているシステム・プロジェクト
内製化の取り組みは、いくつかのパイロットプロジェクトから始めることが多いかと思います。現在進行系のプロジェクトの中から難易度の低いものをいくつかをピックアップし、それらのプロジェクトを試験的に内製化するような進め方です。
では、内製化するプロジェクトはどうやって選べばよいでしょうか。以下に挙げた5つの特徴を備えたシステムやプロジェクトがおすすめです。
- 仕様の不確実性が高い：外注するより内製する方が仕様変更などに柔軟に対応可能
- 新規性が高い：仕様の不確実性が高いこととほぼ同義。やることが決まりきっていない場合にも柔軟に対応可能
- リリースのライフサイクルが早い：リリースしたものをすぐに改修して、また新たにリリースするといった改善のサイクルを回したいプロジェクト
- 業務プロセスの独自性が高い：豊富な業務知識が必要なシステムは、外部ベンダーに知識を伝達するより内製する方が向いている
- 開発規模が小さい：小さいところから始めていく方が安全
一方で、基幹システムなど、万が一の障害時のリスクが高いものは基本的に内製化には向きません。ただし、システムの差別化がビジネスの競争力と直結するような基幹システムであれば内製化のターゲットになる場合もあります。このような場合は、「競争優位性の確保」という観点から、内製化の対象を検討してください。
外注と内製を組み合わせる
全てを一度に内製化するのは難しいため、徐々に内製化率を上げていくというのが失敗しにくい内製化の進め方ですが、外注と内製の分割の方法は外部ベンダーとの相談が必要です。
上図のうち、フロントエンドまでを自社で内製し、バックエンド以下をベンダーに外注するという切り分け方がおすすめです。フロントエンドとバックエンドが分離していれば責任分界点が明確なため、外部ベンダーも安心して受注することができます。
反対に、バックエンドを半分内製し、半分外注したいというような場合は、領域の切り分けが難しくなってしまうため対応できるベンダーを探すことも難しくなります。
また、100％の内製化がゴールになるとは限りません。繰り返しになりますが、内製と外注をうまく組み合わせていくのが重要です。
内製化組織のつくりかた
内製化には、IT知識と業務知識を持ち合わせたDX人材が必要です。このDX人材をいかに作っていくかというのが、内製化組織を作り上げていく上でのポイントになります。
DX人材の獲得方法は2通りあります。
IT知識を持っている人を採用し業務知識をつけるパターン（上図左）と、業務知識を持っている社員にIT知識をつけるパターン（上図右）です。はじめからDX人材が採用できればそれに越したことはありませんが、なかなか難しいため、現実的にはどちらかを選ぶことになるかと思います。
おすすめは、業務知識を持った社員にIT知識をつけるパターンです。なぜかというと、もともとシステム開発を自社で行う文化のない組織でエンジニアを採用するのは難易度が高いということが一つ、もう一つは採用には初期投資が必要になるという点でリスクがあるということが原因として挙げられるからです。この際、社員にITのエキスパートになるよう強い期待をかけるのではなく、システム開発のエッセンスをしっかりと掴んでもらうことがポイントになります。
システム開発のエッセンスとは、どのような流れでシステムができていくのか、システムを作る上ではどんな制約があり、何が簡単で、何が難しいのかといった要点です。これらを理解しておくと、外注の方とより強い協力関係が結べるようになります。ただ、システム開発のエッセンスは体験してみないことにはなかなか身につかないため、まずは内製化のパイロットプロジェクトを進めてみるのが重要になるかと思います。
繰り返しになりますが、はじめから全てを内製する必要はないので、DX人材あるいはDX人材候補の方を軸に、外注リソースや派遣社員などを組み合わせて内製化チームを組成するとよいでしょう。
内製化の事例
ここでは、実際の内製化の事例をご紹介します。
ライフネット生命様の内製化事例
まずは、弊社のホームページにも掲載させていただいているライフネット生命様の事例です。
ライフネット生命様は、ユーザーとの接点であるWebフロントを柔軟に変更・改善したいという要望をお持ちでしたので、フロントエンドの内製化チームを既存のIT部署から派生させて組成しました。そこで、フロントエンドのモダンなフレームワーク（Vue.js）を習得いただきました。ここでのポイントは、バックエンドやインフラは従来通りベンダーに依頼していることです。優先度の高いお客様に見える部分＝フロントエンドに注力して内製化したというのがこの事例の特徴になります。
製造業A社様の内製化事例
もう一つの事例は、製造業のA社様の事例です。
こちらの会社様は、社内で使えるツールの内製化を実施したいと考えておられて、領域は限定せずフロントエンド・バックエンドの知識を習得され、システム開発ができるようになりました。当然時間はかかりましたが、フロントエンドだけでなく、バックエンドやデータベース設計などについてもレクチャーを重ねたため、これら全て自社で開発できるようになり、生産性が向上したということです。ただ、より堅牢なシステムを作るセキュリティ面の知識などは、専門の方に比肩するレベルではないため、全社展開する重要なツールなどは従来通り外部と協力する形で開発を進めています。
このように、部署で使うような簡単なウェブツールのようなものは内製化チームで作り、外部の方も利用するようなセキュリティを考慮する必要のあるものは外部ベンダーさんを入れてセキュリティを担保しながら開発するなど、内製化チームのスキルレベルに合わせて考慮するのがよいと思います。
内製化プロジェクトの進め方
最後に、内製化プロジェクトの進め方についてご紹介します。
内製化するプロジェクトでは、アジャイル開発を採用することをおすすめします。
アジャイル開発の詳細については説明を省きますので、こちらの記事をご覧ください。
内製化とアジャイル開発は相性がよく、「変化に強いシステム」や「素早く変化させるシステム」の実現が容易になるためです。
例えばバックエンドを半分だけ自社で開発するというようなことは、請け負う責任の分界点を作りづらいため、ベンダーに請負型の開発を依頼するのは困難です。内製化という新しい取り組みのリスクを取るのであれば、同時に、ウォーターフォール型の請負で行う開発からアジャイル的な準委任型の開発へのシフトにも取り組んでみてはいかがでしょうか。
ゼロからはじめる内製化―まとめ
内製化に取り組む際の考え方、進め方についてのまとめです。
内製化のメリットは、競争優位性の創出にあります。もちろんコスト最適化のメリットもありますが、競争優位性を作るために内製化をうまく使っていくことがポイントです。
内製化に取り組む際は、フロントエンドやUIなど、より変化への対応が必要とされる領域にフォーカスして進めることをおすすめします。
最後に、内製化組織の作り方については、ビジネスを理解している社員に「システム開発の勘所」を押さえてもらい、適切に外部リソースを使いながらチームを組成していってください。
内製化のご相談はNCDCヘ
NCDCは、AWSの「内製化支援推進AWSパートナー」に参加しており、豊富な実績と知識で内製化をサポートすることが可能です。
柔軟なシステム運用を可能にする先進的な開発手法や、クラウド活用術などの知見・技術をお客さまの社内に蓄積していただくことで、外部ベンダーに依存せず自走できる開発チームづくりをサポートします。
また、どこから内製化していくべきか、対象システムの選定に悩まれているような段階からでもご支援が可能です。まずはお気軽にご相談ください。
