目次

  1. 内製化とは 意味や英語での言い換えも紹介
  2. 内製化に企業が取り組むメリット
  3. 内製化が企業にもたらすデメリット
    1. システムが属人化する
    2. 人件費が増大になる
    3. スケジュールが遅延する
  4. 中小企業はシステム開発の内製化に取り組むべき?
  5. 内製化を進める際のポイント
    1. 内製化の体制は上流工程から始める
    2. システムの内製化は小さく始めて大きく育てる
  6. 内製化の成功事例
    1. 内製化の要件を洗い出す
    2. 内製化によるコストを試算する
  7. 内製化は上流工程から小さく始めることが重要

 内製化とは、主に社外に委託していた業務を社内で行うことです。例えば、システムを自社で開発することによってノウハウの蓄積や機敏性を高めたり、これまで外注していた自社メディアの記事作成や商品の製造工程を自社で行うようにして経費の削減を図ったりする、などが挙げられます。

 英語では内製化を「insourcing(インソーシング)」といいます。

 この記事では、内製化のなかでも、他社で用意されたシステム利用のコストを削減し、自社でシステム開発を行うときにはどうしたらよいのか、に焦点をあててご紹介します。

内製化のポイントと注意点
内製化のポイントと注意点(デザイン:吉田咲雪)

 アウトソーシングは、仕様や見積りを確定させたうえで開発を行い、納品・請求する流れになります。そのため、開発規模が大きくなればなるほど、さまざまな状況の変化に伴う仕様変更が非常に困難です。

 一方、システム開発の内製化を進めると、次のようなメリットが得られます。

  • 開発のチームが自社の状況を細部まで把握できる
  • トラブルなどが起きた場合でも柔軟・迅速な対応ができる
  • システム開発のノウハウが溜まる
  • DX推進に伴いPoC(新しいアイデアが実現可能か検証すること)などに積極的に取り組んでいる場合は、高速にプロジェクトを進行できる
  • アジャイル開発(開発期間を短期間に区切り、新規リリースを繰り返しながらプロジェクトを推進していく手法)を行いやすくなり、試行錯誤しながら進められる
  • ベンダーロックインされにくい

 さらに、内製化により業務効率を高めコストパフォーマンスを上げられます。つまり、これまで手作業でしていたことをシステムで自動化し、社員がより収益性の高い業務に時間をかけることで、間接的に収益に貢献することにもつながります。

 一方で、内製化にはさまざまなデメリットもあります。内製化によくある失敗例を踏まえながら紹介します。

 内製化を進めると同じシステムを長期間作業しつづけるケースが少なくありません。それによって、システムの仕様をドキュメント化する習慣が付きにくく、属人化しやすくなることがデメリットです。また、その結果として、一部のタスクをアウトソーシングしようとしても、システムの仕様がすでに複雑すぎて共有できない事態におちいることがあります。そして、システムのノウハウが溜まらないことにもつながります。

 加えて、特に中小企業は、一人のエンジニアが複数のシステムを横断的に担当することになりがちです。エンジニアが辞めてしまったので、同様のスキルセットの組み合わせを持つ人材を採用しようとしたけれどなかなかうまくいかず、結局、内製化をまた1から進めなければならなくなった、という声はよく聞かれます。

 内製化のメリットとしてコストパフォーマンスの向上が挙げられますが、実際に削減できたケースはかなり少ないでしょう。理論上、アウトソーシングと内製化を比較した場合、中間コストが無くなりコストパフォーマンスが上がることが期待できますが、それに至るには相当な投資と期間が必要です。

 内製化のコストがアウトソーシングより安くなるためには、アウトソーシング先と同等のスキルを持ったエンジニアが社内におり、ノウハウも社内にあることが前提となります。また、内製化で発生した人件費は除外して比較しなければなりません。

 システムはコードを一度作ると再利用しやすいため、ベンダーはコードを再利用し開発コストを下げる術があります。一方で内製化の場合、同じようなシステムを何度も作ることが少なく、コードの流用が限られるため、ほぼすべて1から開発の工数が発生してしまいます。

 また、システムを開発するうえでは、さまざまな専門スキルを持ったエンジニアが必要になるため、多くのスタッフを採用しなければいけません。また、学習・育成する場合は時間コストもかかります。

 加えて、それぞれスキルセットごとに採用人数分のリソースを確保することになるため、大規模なシステム開発を行わない限り、稼働状況に偏りが発生し無駄な工数が発生します。

 したがって、開発するシステムの規模が小さいときは、ベンダーと同等なスキルとノウハウがない場合、人件費などのコストがかさむことをあらかじめ想定することが重要です。

 アウトソーシングの場合は、発注、納品、請求のフローでプロジェクトが進行するため、プロジェクトが遅延しにくいです。内製化の場合は、プロジェクトの進行中に要件や仕様の変更などによって開発が遅れることがよくあります。

 中小企業がシステム開発の内製化を実現するためには、システム開発およびシステム運用・保守など、必要なスキルセットを満たすチームを自社で雇用する必要があります。そして、チームを担えるだけの収益を長期的に維持できなくてはなりません。

 中小企業にとってアウトソーシングは、システムに必要な分だけしか払わずに済むため、内製化に比べてコストパフォーマンスがよいことは事実です。資金に余裕がないときは、システム開発に取り組まずに収益性の高い本業にリソースを集中するのも1つです。

 中小企業におけるシステム開発の内製化には、メリットもあればデメリットもあります。それらをよく精査したうえで、取り組むかどうかを判断することが大切です。

 もし、検討するなかで、やはり自社にとって内製化は重要だと判断した場合は、「上流から始める」「小さく始める」という2点に気をつけながら進めるようにしましょう。以下で詳しく説明します。

 内製化に関しては、できるだけ上流工程から段階的に進めることが重要です。

①工程を分解する

 ここでは、中期経営計画などからマーケティングの戦略を立てて提案依頼を整理し、企画からエグゼキューションまでを広告代理店に委託をしているデジタルマーケティングを例に挙げます。

 下図のように、戦略策定からコンテンツの制作、サーバーまで何層にも工程を分解できます。

上流工程から進めた内製化のイメージ図
上流工程から進めた内製化のイメージ図・筆者作成

②クラウドサービス導入に取り掛かる

 中小企業ではシステム開発が大きなコストになることが多いため、システム開発を不要にできる部分を考えます。そこで下図のように、開発に取り掛からずに利用できるクラウドサービスを導入し、アウトソーシングしていた既存のシステムをクラウドサービス(SaaS)への置き換えることを検討します。

既存システムをクラウドサービスに置き換える内製化のイメージ図
既存システムをクラウドサービスに置き換える内製化のイメージ図・筆者作成

 クラウドサービスの選定において、サービスの機能の他にデータ連携機能も重要です。できる限り汎用的なデータウェアハウス(DWH)にデータ連携できるサービスが望ましいといえます。

 内製化はまず、小さく始めて知見を溜めながら大きく育てていくことが大切です。DXの根幹となるシステムから着手するのではなく、リスクの小さなものから内製化を始めます。サービス運営の根幹に影響を与えるシステムや、24時間365日の運用・保守体制を必要とするクリティカルなシステムの開発・保守・運用の内製化は、最後に取り掛かるほうがよいでしょう。

①段階的に内製化のチームを大きくしていく

 DXを推進するうえで新しい仕組みを導入する場合、まずは会員向けアプリなどのPoC開発や、SaaSサービス同士のデータ連携を内製化するなど、小規模なシステムから内製化にチャレンジします。しばらくは事業収益に直接的に貢献できない期間が続き、投資期間が長くなりますが、ノウハウを蓄積していくことを目標に設定します。

 体制としては社員2名、外部のフリーランスの開発エンジニア2名に、アジャイル開発をコンサルティングしてくれるコーチを外部から1名といった最小体制からのスタートをおすすめします。

段階的に内製化チームを大きくしていくイメージ図
段階的に内製化チームを大きくしていくイメージ図・筆者作成

②システムのインフラ構築に取り掛かる

 DX推進において、とりわけデータの取り扱いが事業の中枢となります。インフラの内製化に取り掛かり、データ基盤の内製化を進めます。ここでは主にインフラ運用保守の完全な内製化よりも、ブラックボックス化やデータロックインを防ぐことが目的です。

 マーケティング施策は、顧客や競合の変化の影響を受けやすく短いプロジェクトでシステムを刷新することも少なくないため、段階的に内製化へ移行しやすい特徴があります。下図のように、汎用的なミドルウェアで構成されるIasS/PaaS(AWS・Google Cloud・Azureなど)のインフラをベースとしたデータ基盤を自社で構築し、運用体制を整えデータを内製化したシステムに蓄積するようにします。これにより将来的なデータの機密性・完全性・可用性を確保します。

インフラとデータ管理の内製化を進めていくイメージ図
インフラとデータ管理の内製化を進めていくイメージ図・筆者作成

 また、24時間365日のインフラ運用保守体制が必要な場合などは、大企業でない限りアウトソーシングやSaaSを採用したほうが、ベンダーロックインのリスクは伴うもののコストパフォーマンスがよいでしょう。

 筆者が経営していた株式会社クロスフェーダーで、システム開発をアウトソーシングから内製化へ移行した成功事例を紹介します。クロスフェーダーでは、デジタル・コンサルティングやWeb制作、アプリ開発の受託開発や自社サービスの開発・運営を行っています。

 内製化のきっかけは、以前、経営難におちいったアウトソーシング先のシステム開発会社から相談を受け、開発部門を引き受けたことです。

 クロスフェーダーでは結果的に内製化を成功させたのですが、そのとき特に注力したのが次の2点でした。

 まず、内製化に必要なスキルセットを洗い出しました。例えば、エンジニアを選定する場合、システム開発・運用・保守の他に、アプリエンジニア、フロントエンドエンジニア、バックエンドエンジニア、サーバーエンジニアなど、さまざまな専門職があります。技能や経験にも大きな違いがあるため、スキルセットの見極めは重要です。

 なお、この件に関しては、既存のシステム会社からエンジニアを引き受けたため、すでに何が得意で何が苦手なのかを十分に理解していたので、人材の適切な割り当てがスムーズにできました。この経験から、エンジニアは、何度か仕事を共にした人から選ぶのがベストだと筆者は考えています。

 続いて行ったのが、内製化によるコストの試算です。

 これまでのクロスフェーダーでは、システム開発はアウトソーシング中心でした。それにより収益と支出の帳尻を合わせることができ、キャッシュフローが非常によい状態でした。

 ただし、内製化すると収益に関係なく人件費が発生するようになるため、それがどの程度発生するのかを、引き受けたエンジニアの数や工数などから事前に計算しました。また、スキルセットが不足した場合、引き続きアウトソーシングが必要となるため、コストを軽減できる見込みを試算しました。

 この要件の洗い出しとコストの試算によって、クロスフェーダーは内製化を成功させました。内製化成功後、受託開発の社内エンジニアの手が空いたときは自社スマホアプリ開発などに取り組むなど、業務を調整できるベネフィットを得ることができています。

 内製化はさまざまなメリットがある一方で、相応の投資が必要です。実際に内製化の費用を回収するのはかなり時間もかかるため、慎重に進める必要があります。

 特に中小企業においては、クラウドサービスなどのシステムを開発せずに済む方法を模索しましょう。そのうえで、クラウドサービス間をAPIで連結させる部分を内製化するなど、軽微なところから内製化を進めることがおすすめです。

 最終的にはDXで他社との差別化を考えると、独自のシステムや環境への適用が必要不可欠になります。十分な資金および収益に見込みを立てて、内製化に挑むことが大切です。