背景

デジタルテクノロジー推進室では、いくつもの企業様のDX推進組織をご支援させていただいております。
その多くの企業様において、「DXの推進」と共に「内製化」というキーワードが聞かれます。
IPAの調査では、IT業務の内製化をすすめる企業は50%以上という結果が出ています。
(出典:IPA「デジタル時代のスキル変革等に関する調査」

読者様の会社でも、内製化というキーワードが出ているのではないでしょうか。
内製化は、今まで外注していた作業を社内で実施する取り組みですが、何故今、内製化を志向する企業が増えているのでしょうか?
今回は、「内製化」をキーワードに、その意義や何をすべきかを中心にご紹介したいと思います。

その内製化は何のためにやるのか?

DXの推進をご支援する中で、お客様から「DXを進める上で、内製化にも取り組みたいので手伝ってほしい」とご相談を受けることが増えています。
そのようなご相談を受けた際に、まず私は「なぜ内製化するのですか?」と尋ねるようにしています。
「コスト削減」や「ビジネススピードの向上」等、理由は様々ですが、それは本当に内製化することで達成できるのでしょうか?
多くのお客様は、「内製化」というトレンドキーワードに振り回されて、その意義を見出すことなく推し進めようとされているように見受けられます。

内製化の目的と分類

一口に「内製化」と言ってもその定義は様々です。ここではDXの推進の文脈で語られる「内製化」として、「システム開発の内製化」について考えていきます。
「システム開発の内製化」は、以下の図のように大きく「業務の内製化」と「技術の内製化」の2つに分類することができます。

「なぜ内製化するのですか?」という問いに対する答え、つまり目的によって「内製化」として取り組む内容が変わってきます。以下に、内製化の目的の例と取り組む内製化の分類を示します。

「業務の内製化」で目指す世界観

「業務の内製化」では、自分達が本質的に何をするべきかを考え、それを企画構想検討から要件定義、外部設計(主に自分達が使いやすいユーザーインターフェースを考える)などを自分達で実施できるようになることを目指します。

内製化以前の状態を考えた際に、例えば企画・構想検討のフェーズでは、コンサルタントに様々な調査や事例などをインプットしてもらい、最終的にやりたいことのアウトプットも作成してもらってはいないでしょうか?さらに、要件定義においてもベンダーへ依頼し、要件をまとめてもらってはいないでしょうか?

ある経営幹部の方とのミーティングの際に「うちの社員は、システム開発をベンダーに丸投げになっている。業務もベンダーの方が詳しい。本当にその社員に価値はあるのだろうか?自らその業務のあるべき姿を考え、どうしたらより効率化できるか?どうしたらより価値を高められるか?といったことをもっと考えられるようになってほしい。」と仰っていました。

こういった方々には、「業務の内製化」を推し進めることをお勧めします。その結果として、ビジネスオーナーシップを養うことや、ビジネスアジリティを高めることに繋がると考えています。

「技術の内製化」で目指す世界観

「技術の内製化」では、出された要件を技術的にどうやって実現するかを考え、アーキテクチャ設計から基本設計・詳細設計、製造、試験までのシステムを作り上げることを自分達で実施できるようになることを目指します。
これを自分達でできるようになると、以下のような効果を得ることができます。

  • 自分達で取り組むことで、開発経験における学習効果を自分達のモノにすることができる(今まではベンダーが享受していたものが自分達のモノになる)
  • 省力化を推し進めればそのままコストダウンに直結する(これまでの請負型の開発ではベンダーは省力化することで利益に変えていた)

技術の内製化の難しさ

ここまで2つの「内製化」について解説してきましたが、まずユーザー企業の皆さんが取り組むべきは「業務の内製化」だと私は考えています。その主な理由は以下の2つです。

  1. ①「技術の内製化」を推し進めても、何をすべきかが無ければ宝の持ち腐れになる
  2. ②「技術の内製化」は一朝一夕では成しえない

特に②の要素に関しては、多くの企業様で既に課題となっている状況だと認識しています。その課題について、大きく2つが挙げられると考えます。

  • 人材の確保が難しい
    • 「技術の内製化」の最初の壁は人材の確保です。
    • 技術者の育成はすぐにはできません。育成にもノウハウが必要です。そもそも育成ができる人が居ないのでは話になりません。ベンダーに依頼しようにも、最終的に彼らが必要なくなるようにする施策なので、まともに手伝ってもらえないかもしれません。
    • 中途採用で開発人材を抱えるという手もありますが、高度なスキルを持つエンジニアの給与は年々増加傾向にあります。
    • 人材がいない状態からのスタートでは、そもそも開発ノウハウが無いため、逆に開発スピードの低下やバグの頻出など、開発そのものが破綻する可能性があります。

  • 技術の追従と経験値の獲得
    • 大手のベンダーは様々なお客様のシステム開発を複数並行で行っており、会社単位で見た開発の経験効率は1企業で得られる経験とは段違いです。
    • 専門的な知識を自分達で追い続けるのは非常に困難です。特にセキュリティなどの技術は、大きなインシデントを引き起こし、社会的信用の失墜につながる可能性があり、蔑ろにはできません。
    • 新しいサービスがどんどん出てくる時代なのでアンテナの高さと、目利き力が必要(自分達で身を切って試すお金と時間が必要)になります。

まとめ

今回は、「内製化」というテーマで記事を書かせていただきました。
「なぜ内製化するのか?」という問いに対して、皆さんはどう答え、本記事をどう捉えましたでしょうか?私のオススメは、まずは「業務の内製化」から始めることです。 ユーザー企業様にとっては、業務(=ビジネス)こそが利益の源泉です。ここを内製化することはビジネスの幅を広げることができると考えます。

「技術の内製化」に踏み出す際は、もう一度「内製化」の目的に立ち返り、本当に今すぐ進める必要があるかを考えてみてください。自分達で技術者を抱えたり、最新技術に追従していく気概があるのであれば、大いに進めるべきだと考えます。先進企業のラベリングなど、最終的に得られるメリットが非常に大きいのも事実です。

「技術の内製化」をベンダーと長期的な目線で一緒に進めるのも一つの考え方です。ベンダーのノウハウも生かしつつ、自分達にも知見を蓄えられるので賢いやり方です。その場合は、ベンダー側に御社の内製化を支援するビジネス的なメリットを作り、Win-Winとなる関係性を構築する必要があります。