オピニオン

「内製のすゝめ」〜情報システムを「内製化」するとは、何をすることか？〜

　ここ数年、DX推進へのプレッシャーもあって、「内製化」開発を進める風潮が高まっているのは、読者の皆様は当然ご存知だと思います。言われるまでもなく当たり前のこととして、内製化に取り組んでいらっしゃるCIOやシステム責任者の方々も多くいらっしゃることも間違いないでしょう。

　ただ「DX」もそうなのですが、「内製化」もややもすると定義が不明確です。企業や人によって解釈の余地が多く、言葉だけが先走りしがちなところあります。皮相的にいえば、あえて内製化を謳うこと自体ができていないことの証明であり、ベンダーやコンサルティング会社のマーケティングに乗せられているきらいもあると言えるかも知れません。

　その根拠の1つが、情報処理推進機構（IPA）が毎年発行している「IT人材白書」（2021年からDX白書に統合）にあるIT人材に関する調査です。一貫して量の面でも質の面でもIT人材が不足していることを明らかにしています。肝心の人材が不足する中、言葉を唱えるだけで外部化していた何かを内製化できるはずもありませんから、何かがおかしいと考えるのが普通でしょう。そこで、ここでは「一般の事業会社における内製化とは？」について、論じてみます。

かつて当たり前だった内製化の実態とは？

　少しノスタルジックな話ですが、筆者を含めた50歳以上の年代では実のところ、アプリケーションの内製化（開発）は当たり前でした。1970年代から1990年代初頭までのメインフレーム全盛時代においては、今でいうERPやCRMのようなパッケージは存在せず、PL/I、COBOL、FORTRANといったプログラミング言語を使って必要なアプリケーションを都度、スクラッチで開発し、保守していました。

　もう少し詳しく説明すると、IBMを筆頭にBUNCH（Burroughs、UNIVAC、NCR、Control Data、Honeywell：社名は当時）と呼ばれる外資系メーカーが、共通性のないOSを搭載した独自のハードウェアを提供。日本メーカーでは日立製作所と富士通がIBM互換の、NECなどが独自のハードウェアを提供していました。OSはもちろん、プログラミング言語やDBMS、トランザクションモニターなどのソフトウェアには目に見える明確な価格はなく、ハードウェアの付属物だった時代です。

　当時、ハードウェアを購入した企業のIT部門は付属するソフトウェアを使って総勘定元帳や出納管理を行う会計システムはもちろん、在庫管理システム、受注管理システム、勤怠管理システム、給与計算システム、製造管理システムなどを、自社でゼロから開発していました。ハードウェアの価格は非常に高価な半面、性能はプアでしたから、CPUやメモリーなどのリソースをいかに節約しながら目的とするアプリケーションを作るのかは、腕の見せ所であり、醍醐味でもありました。

　お金を掛け、様々な苦労をしてスクラッチ開発してもペイした理由は単純です。人海戦術で記録を管理し、決算や税務申告などを必要な時間軸で処理を行うことに対して、業務の効率化という点で十分な費用対効果があったからです。企業にとって内部管理費（膨大な人件費）を低減させ、利益率を向上させる差別化要因にもなり得ました。

　例を挙げると、筆者がCIOを務めた生命保険業界では保険商品が最低でも10年、第一分野では終身が大半を占めます。それを提供可能にしているのが、保険約款に定められた契約条件を記録・管理している契約管理台帳システムです。保険金の支払い条件から数理計算まで内部規定を含めて、すべての業務に知見が内包されたアプリケーションがあります。保険会社にとって商品はビジネス上の戦略的差別化要素であり、したがってそれを反映したアプリケーションは内製化してこそ、競争力の源泉になります。「内製化」と言う時、こういったシステムを念頭に置くケースが多いでしょう。

　この頃の内製は、ダム端末を使ったプロセス指向なモノリシックな開発が主流でした。人の仕事や業務の流れやを直観的にプロセスとして記述していけば、アプリケーションを開発できましたし、アプリケーションをまたがったデータの共通性や再利用については、ほとんど意識されませんでした。このように単純な手順をプロセスとして処理に落とし込むだけだからこそ、内製化できた面もあります。

ITの進化が「内製化」から「外製化」へのシフトを促した！

　1990年代に入ると、オープン化のムーブメントがITを席巻します。メインフレームから汎用マイクロプロセササーバへ、メーカー製OSからWindows／UNIX／Linuxへといった潮流です。DBMSなどのミドルウェアは当然のこと、業界を問わず同じ仕様で標準化されても問題のない会計や在庫管理などのアプリケーションも、専業のソフトウェア企業が誕生し、パッケージ化していきます。ERPにしろCRMにしろ、オーダーメイドではなく、レディメイドで問題なければ貴重な開発・保守リソースを共有する意味で効率が良くなります。

　一方、技術革新によってIT基盤の中心がサーバーやPCになり、導入費用が劇的に下がり、性能が向上すると、オーダーメイドでアプリケーションを開発するためのソフトウェアエンジニアリングの手法も変わります。様々な変化がありましたが、大きいのがプロセス指向からオブジェクト指向へと変わったことです。オブジェクト指向ではデータとプロセスを一体（オブジェクト）として扱うこと、またそのオブジェクトを抽象化（クラス）して定義し、再利用性の概念をエンジニアリング思想として取り込んでいます。

　まさしくパラダイムシフトでした。オペレーティングシステム（ユーザーインタフェース）やデータベースやといった汎用性の高いソフトウェアもそうですが、コーディングの領域でもSimulaやSmalltalk から始まった流れはJavaやC#、C++などのオブジェクト指向言語へと広がりました。オブジェクト指向だけではありませんが、ITに関わるこうした様々なパラダイムシフトは、「内製化」に影響を及ぼします。一言で言えば専門性が高くなり、一般企業が内製化する（できる）対象は、どんどん狭くなっていったのです。

　同時期の1990年代から2000年代にかけて、ミドルウェアからアプリケーションまであらゆる領域のソフトウェアを提供するソフトウェア企業、そういったソフトウェアを使ったり、スクラッチでシステム構築を受託する情報サービス企業が、数多く誕生しました。これにより内製化する必要のない対象が、どんどん拡大していったと見ることもできます。

Citizen Developmentは「内製化」ではあるものの・・・

　もちろん構築という意味での内製化が、ゼロになったわけではありません。市販ソフトウェアには、企業のニーズに合わせて追加開発ができる機能を備えたものが少なくありません（SAP ERPのABAPなど）。さらにリレーショナルDBやルールエンジン、ワークフローエンジン、UIデザイナーなどのツールを組み合わせ、簡易なスクリプトを記述すればアプリケーションを作ることもできます。

　少し横道に逸れますが、増大するシステム化のニーズに対してIT部門だけではなく、事業部門が自らアプリケーションを作るシーンもありました。EUC（エンドユーザー・コンピューティング）です。代表例はLotus NotesやAccess、FileMakerなどでしょう。今日ではKintoneもそうです。EUCも自社内で開発するという意味では内製ですが、一部、問題を抱えてきたのも事実でしょう。

　「あれば便利」といった理由から本質的な必要性の評価がないままに作成し、当初は業務自体の生産性、管理性を向上させたものの、時間が経つと「何故そうしているのか？」や「内部でどのように処理をしているのか？」のドキュメントが散逸し、属人化して保守が叶わないことがその1つです。セキュリティはじめITガバナンス上の問題もあるでしょう。

　時間軸は「今」になるのですが、ローコード・ノーコード開発の文脈でよく言及される「Citizen Development」（市民開発と訳されることが多いが、個人的にはしっくりこず、センスのある言葉が欲しいところです）も、気になるところです。EUCと同じ轍を踏まないか危惧します。すでに定着した感のあるRPAも同じかも知れません。「内製化」の成果であると単純に評価せず、適用する業務やプロセスの正当性の評価について本質的な議論が先にあるといいと思います。

現在進む”技術爆発”に、IT部門はどう対処する？

　次にインターネットがもたらした技術進展です。メインフレームの時代には、ネットワークはコンピュータの遠隔地操作用オンライン接続の意味合いしかありませんでした。インターネット以降は、プロトコルが標準化され接続もパブリックに「繋がる」事が出来るようになります。併せてその回線帯域幅と回線速度が、指数的な費用低減を伴って普及していることは、誰もが体感・実感している通りです。

　この「繋がる」ことの意味が大きく拡張されてきました。以前のITが効率化を主軸に検討されてきたのに対し、今日ではユーザー価値の提供へシフトしています。これもパラダイムシフトですし、デジタルの本質的な思想の根源になっています。検索エンジン、E-コマース、SNS、スーパーアプリ、IoT/エッジ、データサイエンス、メタバース、VR/AR/MR/XR、暗号資産、そしてAIと、広範囲にわたるビジネス機会を生み出しています。

　それだけではありません。ネットワークからソフトウェアエンジニアリングを技術階層として捉えると、アーキテクチャからアプリケーションの作り方まで、すべての考え方が変わりつつあります。サービス化（その昔のSOAではなく）とAPI、カプセル化、コンポーネント化、ブロックチェーンまたオブザーバビリティーエンジニアリングも駆使しないと、対応するアプリケーションは作れません。もちろんパブリックに「繋がって」いることに対するリスク対策も必須です。

　マイクロサービスアーキテクチャ、サーバレスアプリケーション、データファブリック、サイバーセキュリティーメッシュといった技術あるいは思想もあります。これらの技術開発は専門エンジニアを抱えるベンダー企業にしかできませんし、ネット企業はこれらの技術や思想をいち早く取り込み、提供価値を高めようとするでしょう。

　では一般企業のIT部門は、どうするといいのでしょう。筆者は様々な技術や思想を正しく理解し、必要に応じて取り込み、応用するのがミッションであると考えます。つまりアプリケーションの進化によるビジネス価値の向上です。我々IT部門がこれをしなくて誰がするのでしょう？コンサルティング会社などに頼っていては、正しく、タイムリーな判断は困難ですから、IT部門が技術や思想を理解して「内製化」するしかありません。

　技術進展については今後、Web 3、量子コンピューティング、光コンピューティング、6G無線通信、ジェネレーティブ（生成）AI、ロボットを含むオートノミックシステムを含めて、思いもよらぬものが今後も出てくるでしょう。内製を狭義に捉え、何らかの開発言語でコーディングが出来ることとしたり、ローコード／コーノード開発ができることとしたり、あるいは要求仕様に責任を持てばそれでよしとする論調もあります。間違っているとは言えませんが、目的はあくまでビジネスの成長と拡大、加えて持続可能な社会貢献です。手段や方法に終始せず、「内製化」の本質を見極めなくてはなりません。

CIO／IT部門は技術を学び、習得しよう

　「学問のすゝめ」は、言わずと知れた「天は人の上に人を造らず人の下に人を造らずと言えり」から始まる福沢諭吉による明治時代の名著です。当時の日本の人口は3480万人。聞くところによれば340万部が売れたので、国民の10%読んだことになります。平等思想、独立自尊、民主主義思想を明治維新の動乱期に広く流布し、封建社会から近代社会への脱皮をしたとも言われます。

　当時と違って現代は、価値観もベースとなる経済環境も違います。「内製のすゝめ」といってもすべき範囲や内容は上述の通り、常に変化します。ただ、はっきり言えるのは、やはり学び続けなければならないということです。「内製のすゝめ」は「学問のすゝめ」でもあるわけです。リスキリングは新しい変化を柔軟に取得し、確実に消化して身にしていくことです。これだけは他者（社）に頼れません。自身が学び続けなければならないとの覚悟が必要でしょう。

せっかくその最前線となるITを行っているのであれば、それを是非楽しんでいただきたい。仕事も勉強も楽しくなければ続きませんから。

オリックス不動産株式会社
不動産セグメント シニアフェロー
菅沼 重幸