なぜシステムを自分たちで作り運用することが事業にとって重要か？

こんにちは、エンジニアのgamiです。このnoteでは、ビジネスとエンジニアリングにまつわるより広い視点を示して、皆さんと議論したいと思っています。

今回は最近たまたま考える機会があった、システムの「内製化」について書きます。なんとなく「内製化」と聞くと情報システム部門や経営層にしか関係がない難しいトピックに聞こえます。でも、誰もが何かのシステムに触れながら仕事をしている現代において、「自分たちのシステムについて自分たちで考えよう」という内製化の活動は、職種に限らず関係のあることに思えます。

企業のIT戦略としての「内製化」

最近のデジタルトランスフォーメーション（DX）ブームの中で、「ITを使って企業や事業をどう変革するか？」みたいな記事が世の中に大量生産されています。（この記事もその中の1つかもしれませんが。。。）その中でよく語られる言説に、「システム開発を外注に丸投げするのをやめて、内製しよう！」というものがあります。

僕は前職では自治体からシステムを外注されるような部署で働いていました。その部署には自治体の業務ロジックを職員よりも深く理解した優秀なシステムエンジニアがたくさんいて、「この法改正に対応するためのシステム改修については、弊社側で対応方針を考えました。修正作業も弊社側でやっておきますね」みたいなコミュニケーションが日々行われています。発注者側はそのシステムの中でどのような処理が行われているのかを把握しなくても、システムの使い方を知っているだけで業務を回すことができます。それは発注者からすればとても楽な状況で、一見すると本来の業務に集中できて良さそうです。そんなに楽なのに、なぜ「システム開発を外注に丸投げするのをやめて、内製しよう！」などと言う必要があるのでしょうか。

「内製化」の事例

このnoteを書くきっかけになったとあるブログ記事があります。

事業をエンジニアリングするチームを作ります。エンジニア募集！ : 小野和俊のブログ

クレディセゾンというクレジットカードで有名な会社のCTOである小野和俊さんが2020年9月に書かれた記事です。このnoteに関連する部分を要約すると、次のようなことが書かれています。

・事業会社が、その事業の根幹を担うはずのシステムを外注している
・その結果、マネジメント業務が大量に発生し、「価値あるシステムを作る」という本来の目的が軽視されてしまう
・クレディセゾンのCTOとして、「各事業部で一番解決したいシステム的な課題」を自社の開発チームを新しく作ることで解決しようとしている

小野和俊さんは、小学4年生からプログラミングを始め、サン・マイクロシステムズ本社で開発者として働いていた時期もあるバリバリのエンジニアです。その後BtoBの開発会社を日本で起業した起業家でもあります。そんな小野さんが、日本の金融業界のど真ん中にいるクレディセゾンで、CTOとしてデジタルトランスフォーメーションに取り組んでいる。そしていま立ち向かおうとしているのが、内製化を強めて「事業とエンジニアリングの距離を極限まで縮める」というテーマなわけです。

なんとなく、「内製化」というものは事業にとって大事そうである、という気持ちになってきました。

なぜシステムは外注され、再び内製されようとしているか？

では、そもそもなぜITシステムは「外注」されることが一般的で、なぜいま「内製」することが求められているのでしょうか？

まず、ITシステムを外注する場合、その外注先はシステムインテグレーター（SIer）と呼ばれる類のIT企業になることが多いです。SIerの厳密な定義は無さそうですが、ざっくり言うと「大規模なシステム受託開発案件を、プロジェクト的に集められた比較的大人数のチームで請け負う事業」をやっている会社のことです。そこにはシステムエンジニアやプログラマーがたくさんいて、発注者と合意した大量のシステム仕様書に沿って、日々プログラムが量産されています。そのプログラムは最後に大きなシステムとして束ねられて、発注者側に納品されます。納品して終わりのこともありますが、多くの場合はそのシステムの保守・運用も継続して外注されます。その保守・運用業務の中で、日々のサーバー管理やシステムの細かい仕様変更が行われます。

なぜ事業会社はITシステムの開発をSIerに外注するのか。それについては、過去の僕のブログ記事で次のように説明されています。

まだITシステムが一般的では無かった時代、SIerのような存在がシステムを開発することには十分に合理性がありました。オフィスの内装を外部の業者に発注するように、企業が業務システムを外注するのは当たり前のことでした。最初にITシステム化が進んだのは、企業内部の業務を自動化・効率化するような領域でした。 すでにある簡単な業務をITシステムに置き換えるだけであれば、プロジェクト初期に発注者と受注者で要件を全て固めてしまうことができたと想像します。あとはシステムを要件通りに作って納品するだけなので、受注者の中で独立して開発プロジェクトを回しても、開発するものに対する認識のズレは比較的生じにくかった。このような状況の中で、開発プロセスをガチガチに固めて誰でも一定のパフォーマンスが出せるように標準化されていきました。

オフィスの内装とITシステムとの対比はわかりやすいですね（自画自賛）。オフィスの内装は、一度作ってしまえばそんなに変わるものではありません。その場合、自社で内装を変えられる人員を正社員で抱えておくよりは、オフィスを作るときにまとめて外注してしまった方が合理的です。それと同じように、かつてのITシステムは「一度作った後はそんなに変化しないもの」でした。当然、外注した方がコスト的に有利だったわけです。つまり、最初から「内製化」が正義ではなく、どこかでゲームのルールが変わったということになります。

では、「外注から内製へ」という動きを生んだゲームチェンジとはなんだったのでしょうか？それは、システムに対する要求が高度化、複雑化したことです。特に、環境変化のスピードが上がったことで、システムに「変化し続けること」が求められるようになりました。ここに至って、ITシステムは「オフィスの内装」的ではいられなくなってしまいます。

こうした変化が起きた経緯について、ありがたいことに過去の僕は先のブログ記事で次のようにまとめてくれています。

・単純な業務がシステム化され尽くされ、より複雑な業務ロジックを扱う案件が増えた
・さらに企業内の業務だけではなく、生活者や顧客のクライアントが使うサービスまでソフトウェア化され始めた
・インターネットの普及などを背景に、ニーズが多様化し変化するスピードが上がった

情報の記録やコストカットのためのシステムだけではなく、事業の根幹を担うような領域までもがシステム化されるようになってきました。

たとえば、今まで実店舗や電話でしか宅配注文を受け付けていなかった小売企業が、新たにECサイトを立ち上げるようになりました。ECサイトの売上比率が5割になったら、そのECサイト上での購買体験が売上に直接与える影響は、とても無視できないもののはずです。

エンドユーザーに直接触れる領域だけではなく、業務オペレーションの徹底的なチューニングによって差別化するケースも増えています。極端な例で言えば、Amazonの配送システムが今ほど狂気的に効率化されていなければ、「多様な商品がすぐに届く」というサービス体験を実現できないはずです。

こうして、多くのITシステムはもっと多くを求められるようになり、より変化に柔軟であることを強いられるようになりました。

あなたの課題は、あなたにしか解けない

ITシステムへの要求が高度化したとしても、「じゃあ内製化した方がいいですね」とすぐに納得できる人は少ないでしょう。「SIerとか呼ばれるIT企業自身が、より難しいシステムも作れるようにもっと高度化すればええんちゃうんか」という意見があるのはもっともなことです。

これについては、いま語られているシステム開発の「難しさの種類」について考える必要があります。

すぐに思いつく難しさは、「技術的な難しさ」です。もし現代のシステム開発が単純に技術的に難しいのであれば、SIerが自社のエンジニアを教育して技術力を上げれば解決できるかもしれません。

しかし残念ながら、ほとんどのシステム開発上の課題は、たとえばAIとか機械学習とかビッグデータとかにまつわるキラキラした技術があれば解けるような単純なものではありません。

多くの課題が抱えている難しさとは、「意思決定にまつわる難しさ」です。システムをどう変化させるとどのような結果になるのか。市場の不確実性が驚くほど増している中で、それでも仮説を立ててシステムに連続的に変化を生み出し、そこから得られた情報から仮説の正しさを丁寧に検証し、学習サイクルを回していく。その結果得られた学びを、組織やITシステムに対して蓄積しながら事業を前に進めていく。そうしたタフな意思決定の連続の中にシステムの開発や運用を位置付けなければ、事業にとって価値あるシステムを維持し続けるということができなくなっています。

こうした不確実な状況における意思決定を連続的に実施する上で、「システムを外注している」ということはとても大きなディスアドバンテージになります。その要因となるコストについて、前述した小野さんの記事では次のように紹介されています。

マネジメント業務を膨れ上がらせる要因はいくつもある。例えばSIer側の作業だけ考えてみても、次のような作業がある。

見積もり、コスト調整、要員調整、
大量のプロジェクト計画書、
内部進捗（SI）と報告用進捗(事業会社)の二重管理、
人月による無意味な見積もり、、、
開発専門部隊が存在する会社だと内部売買の報告資料の作成まで必要になるケースもある。
それにそもそも事業会社とSIとの話がかみ合わず、歯車を嚙合わせるための会議に膨大な時間がかかったりする。

SI観点だけでもこれらの業務が大量に発生するのだ。

当然、相対する事業会社側の作業も含めたらこれらのマネジメント業務のボリュームはさらに膨大なものとなる。

結果として、エンジニアリング以外の業務が大量に発生するだけでなく、事業の当事者と現場で実際に開発するエンジニアとの間にいくつものレイヤーができてしまう。多重下請け構造も考慮するとこのレイヤーはさらに重厚なものとなる。

また、『エンジニアリング組織論への招待』という僕のバイブル的な本の中ではこの問題に関して、アメリカの経済学者ロナルド・コースが提唱した「取引コスト理論」を紹介してさらに広く論じています。その中では、外注管理における取引コストを次の3つに大別しています。

・探索のコスト: 外注先選定にかかるコスト
・交渉のコスト: 外注先とどのような契約条件で、契約を行うのかを決めるために必要なコスト
・監督のコスト: 作成されたプロダクトの品質を監督し、クオリティの維持がなされていることを検収したり、外注先をマネジメントするコスト

さらに、こうしたわかりやすいコストを払って外注を始めたとしても、発注者側と受注者側で完全に同じ目線に立ってシステム開発をし続けることはビジネスモデルの構造上かなり難しいといえます。一般的な契約において、システムを受注するSIerからすれば、事業上価値あるシステムを作って発注者側の事業会社の利益が何倍かに上がったとしても、そこから直接的な利益が得られることはないからです。

ちなみに、ここで語られている問題は僕が「なぜ全ての職種にITリテラシーが必要なのか？」というnoteで書いた課題意識とほとんど同じです。今回は個人というより組織レベルの視点で書いていますが、結局は「あなたの目の前の課題をきれいに解ける人は、あなたしかいない」ということに尽きるのです。

「内製化」についての3つの誤解

ここで、「内製化」という語感やそれについて語られるときの論調から生まれる3つの誤解について、簡単に補足しておきます。「内製化」の最も大きな価値は、「ある事業に直接関わる人が関連するシステムについての意思決定を自由にできること」でした。この目的を外れた「内製化」を形だけ目指しても、あまり得るものは多くありません。

1つ目は、「とにかく自社内で開発すればいい」という誤解です。もちろん、別の会社に外注するよりは自社の別の部署で開発をした方が、一般的には取引コストは下がります。しかし、会社によってはそれぞれの部署が個別最適を追求した結果、同じ会社にあってもそれぞれの部署が全く別の会社のように振舞うようなケースがあります。そのような状況においては、「自社内で開発しているから内製化できている」と自慢げに語ったところで、実態は外注するのと意思決定のスピードは大して変わらないということも往々にしてあります。

2つ目は、「自分たちで開発したものしか使ってはいけない」という誤解です。「内製化」を突き詰めると、「自分たちが使うシステムは全て自分たちで作るべき」という極端な思想に走ってしまうことがあります。もちろんその方向に突っ走った結果うまくいったAmazon/AWSなどのレアケースはあります。しかし一般的には、自社の開発リソースに限りがある中で、広く普及しているソフトウェアをうまく取り入れて活用するという戦略が重要になります。特に業務領域ではSaaSの発達が著しく、大抵の業務は自社で無理やり開発するより筋のいいSaaSを契約して使った方がうまくいきます。（SaaSと自社開発の棲み分けについては、また別の機会に書くと思います。）

3つ目の誤解は、「全ての外注は悪である」という誤解です。かつてITシステムの外注が正義であったように、現代においても「外注した方がいいシステム」というものはありえます。たとえば何年も変化が無い定型業務を担うシステムを、高いコストを払って無理に内製化するのは、割りに合わないかもしれません。

組織がシステムを内製化するステップ

ここまでで、今回のnoteで語りたかったことはだいたい書きました。とはいえ、「じゃあどうすればいいんですか」という読者の声が聞こえてきそうです。せっかくなので、できる限りその声に応えたいと思います。（僕にはシステム内製化の真っ只中で戦った経験はないので、ここから先は話半分に聞いておいてください。）

まず、こちらの地味な図をご覧ください。この図では、2×2のマトリクスでシステムを分類しています。左右がシステムの規模を、上下が内製度合いを示しています。内製化を進めたい文脈では、なるべく上の領域にあるシステムを増やしたくなります。できれば規模の大きいシステムを内製化して右上の領域にシステムを持っていけると、リターンも大きそうです。

ここには、1〜3の矢印が書かれています。これが組織レベルでのITシステム内製化の戦略です。

1つ目の動きは、「小さなシステムから内製化する」ということです。社内のシステムを眺めると、全てが大きいシステムばかりではなく、中には業務上の独立性が高い小さなシステムがあります。よくありそうな例でいえば、勤怠管理ツールとか、レポートツールとか、そういったものです。もしそういった置き換えできそうなシステムが外注システムの中に含まれていれば、それを自分たちで運用できるもので代替してみる、というのが第一歩になりそうです。前述したように、いきなりエンジニアを採用して自社開発をする必要はありません。それを代替するSaaSを見つけたり、ちょっとしたNoCode/LowCodeツールを使うことで同じような業務フローを実現できないかから考えましょう。ここで注意すべきことは、小さく始めることと、うまくいったら大きく他の部署にも広げることです。いきなり大風呂敷を広げても何も進まないですし、逆にずっと自分のチームだけで使い続けていても社内システムが乱立するだけです。

2つ目の動きは、「大きなシステムを小さな独立性の高いシステムに分割する」ことです。重厚長大で一枚岩のシステムは、一般的に「モノリシックなシステム」と呼ばれます。モノリシックなシステムは、構造がシンプルな反面、個別のパーツの取り替えが難しく変化に弱くなりがちです。もし自社内にモノリシックなシステムがある場合は、そのどこを置き換え可能なパーツに分割できるかを考えます。一度に全てのシステムを内製化することは一般に難しいですが、独立性の高いパーツに分割できれば、それを1つずつ順に内製化できます。ここに至ると、発注者側にシステムのアーキテクチャに関する一定の知識が求められます。また、外注先に対して「この部分だけ外部のサービスを使うように切り替えたいんですけど」といった要求をぶつけ、プレッシャーをかけながらタフな交渉をする必要があるかもしれません。

3つ目の動きは、「本丸である大きなシステムを、自社の開発組織で開発・運用する」という最終フェーズです。これを綺麗に実現するには、優秀なCTOの登用、Techブランディング、エンジニアの採用、自社開発チームの立ち上げが必要になるでしょう。図の中では、比較的大きなシステムを内製システムでリプレースする縦の動きと、すでに内部で運用している小さなシステムを大きなシステムとして束ねていく横の動きの組み合わせで表現されています。

あなた一人から始める「内製化」活動

こうした「内製化」の推進は、強力なリーダーシップや組織改革を伴うトップダウンな動きによって実現されるものに見えます。しかし、「内製化」が進んだ組織では、事業に関わる誰もが関連するシステムの選定・開発・運用に関与することが求められます。その組織で働く個々人がシステムに対する向き合い方を変えなければ、本当の「内製化」は実現できないわけです。まさに、「あなたの目の前の課題をきれいに解ける人は、あなたしかいない」のです。

逆にいえば、あなた一人からでも働き方を変えることで、未来の「内製化」につながる活動を始めることはできるはずです。あなたがITリテラシーや社内システムへの理解を高めることでさえ、内製化のための一歩になります。その一歩は最初は小さなものでも、いずれ大きな"うねり"となって組織変革を加速させるかもしれません。

職種や立場による違いはあれど、個人として「内製化」の活動を始めるためのステップは、おおよそ次のようなものになると思います。

1. 自分の日々の業務や使っているシステムについて、もっとよくできるものがないか考える
2. まずは世の中にあるSaaSやソフトウェアを使ってそのシステムを代替できないか試してみる
3. それで限界がきたら、NoCodeツールやGoogle Apps Scriptなどを使って足りない部分を自分で開発してみる
4. 自分の取り組みを社内外に発信して、共犯者を集める
5. コミュニティを形成し、経営層を動かせるくらいの大きな動きに育てていく

特に、2〜3については、一人でやり切るのは大変かもしれません。そんなときは「非エンジニアのためのエンジニアリング」という素晴らしいサイトでヒントを探したり、ぜひ僕までTwitterのDMで気軽に相談したりしてください（宣伝）。僕はそんなあなたを応援することで、社会をより良くできると信じています。

もっと詳しく知りたい方へ

最後に、今回のテーマについてより詳しく知りたい人向けの情報を載せておきます。

「事業をエンジニアリングするチームを作ります。エンジニア募集！ : 小野和俊のブログ」

このnoteを書くきっかけとなったクレディセゾンCTO小野さんのブログ記事です。まだ全文読んでない方は、ぜひ読んでみてください。また、小野さんが書いた『その仕事、全部やめてみよう』も面白そうです。読みたい。

『ソフトウェア・ファースト』

なぜあらゆる企業活動においてソフトウェアが重要であるか、ソフトウェア・ファーストな組織に変えるためにはどうすればいいか、について書かれた本です。危機感を増すための薬として読んでおくといいかもしれません。

『エンジニアリング組織論への招待』

記事中でも紹介した、僕の活動のバイブルです。分厚くて難しいですが、組織や不確実性に関する問題について多くの文献を引きながらロジカルに説明してくれています。内製と外注をめぐる問題については、本書の「5-4. 取引コストと技術組織」で論じられています。

以上！また来週。