「内製化」と「脱自前主義」に向きあうための3つのシナリオ

情報システムには、いま２つの大きな潮流が押し寄せている。それが、「内製化」と「脱自前主義」だ。

「内製化」と「脱自前主義」の潮流が加速する

「内製化」とは、事業の競争力強化や差別化を目的に、事業部門が主導して、情報システムを自社社員で開発、運用することだ。

ITを前提とした新しいビジネス・モデルを作ることであり、予め何をすればうまくいくかが分からない。だから、高速に試行錯誤を繰り返し、最適解を見つけてゆかなければならない。あるいは、めまぐるしく変わる顧客のニーズの変化や競合サービスの動きにも俊敏に対処できなくてはならない。

このような情報システムは、予め仕様を決めることができない。だから、このようなシステムを作って欲しいと外注することができない。加えて、事業の売上と利益に直結するので、開発や運用の当事者もまた、圧倒的なスピードを求められる。

丁寧に仕様を洗い出して、見積もりをとって、体制を整えてなど、とても無理な話である。ならば、自前で開発と運用のチームを常設し、その範囲の中で、高速かつ俊敏に対処する。自ずと、アジャイル開発、DevOps、クラウドを前提に、AIやIoTなどの最新技術を駆使して、アプリケーションに全てのリソースを注ぎ、情報システムを実現してゆくことになる。

「脱自前主義」とは、出来合いのサービスやパッケージを、できるだけ手直しせずに、そのまま使おうということだ。

これまでも、パッケージをカスタマイズして、あるいは、アドオンを作って、情報システムを構築してきた。しかし、その目的は、自社の業務を大幅に変えることなく、情報システムの開発生産性を高めることにある。出来合いの機能を使うことで、全てを一から作る手間を省こうというわけだ。つまり、目的は、自社専用の自前システムを作ることであり、その手段としてパッケージを使用することだった。

しかし、パッケージの本来の思想は、パッケージの前提となった業務プロセスのベストプラクティスを、そのまま使うことで、業務プロセスの改革を加速することにある。ERPパッケージなどは、まさにそのために作られた製品であり、様々な業務に応じたテンプレートを用意しているのはそのためである。

しかし、我が国の多くの企業は、このパッケージの思想を無視し、自前のシステムを作るにあたっての開発生産性を高める手段として、パッケージを導入した。その結果として、膨大なカスタマイズやアドオンの開発費が、パッケージのライセンス料金を遥かにしのぐ規模になったり、パッケージのバージョンアップに対処するために、膨大なテストや修正を余儀なくされたりといった事態を招いている。

もはや、このような状況を看過できない状況となっている。それは、IT利用の適用範囲の拡大にある。事業のグローバル展開に対応し、迅速に現地の業務システムを立ち上げ、これに対応しなくてはならない。あるいは、前節で述べた「ITを前提としたビジネス・モデル」のための新しい情報システムとの連係を必要とするからだ。

要求仕様が定まらないままに作り始められるシステムや仕様の変更は日常茶飯事であり、これにも対応できなくてはならい。これを全て自前のシステムで対処することは容易なことではない。

ある企業が、M&Aによる事業領域の拡大に取り組み始めた。その基幹業務は、自社の従来業務にきめ細かく対応するために作られたものであり、その範囲に於いては、申し分のないシステムではあった。しかし、経営戦略の方針転換に追従するためにパッチワーク開発を余儀なくされたが、追従できなくなってしまったというケースもある。

もはや、ひとつの情報システムに十分な時間や潤沢なお金を掛ける余裕はない。ITの適用範囲の拡大と予測できない事業環境の変化に対処するために、「脱自前主義」は、避けられないだろう。

この２つの潮流は、コロナ禍をきっかけとして、加速するだろう。従来からも、この潮流への認識はあったが、現場の納得が得られない企業も多かった。しかし、コロナ禍がITの役割についての認識を大きく変えてしまった。この潮流を分かっていなかった、あるいは分かろうとしなかった人たちが、言い訳できない状況になってしまったのだ。

これは、変革を促してきた人たちにとっては、千載一遇のチャンスであろう。これを味方に付けて、変革組が勢いを増し、２つの潮流を加速することになるのは、想像に難くない。

２つの潮流に呑み込まれないために3つの前提を転換せよ

SI事業者にとって、「内製化」と「脱自前主義」は、これまでの事業を転換することを迫られる。

「内製化」は、SI事業の対極にある。表現を変えれば、競合である。まずは、この前提に立たなくてはいけない。お客様が自分たちでシステムの開発や運用をやってしまうのだから、外注はない。受託・請負での開発や派遣での運用という需要が喪失する。

「脱自前主義」は、SI事業の業務そのものを喪失させる。つまり、独自システムの開発、カスタマイズやアドオンの開発などがなくなってしまう。また、クラウド・サービスを使うとなると、運用業務は自動化あるはクラウド事業者が担うことになり、SI事業者の関わる部分は、大幅に減ってしまう。

いずれにしても、この大きな２つの潮流は、従来型SI事業の「工数＝売上と利益」という収益モデルを、成り立たなくしてしまう。そのため、SI事業者は、次の３つの前提を転換することが迫られるだろう。

• 「作る技術力」から「作らない技術力」への転換
• 「他律型」から「自律型」への転換
• 「受託型」から「共創型」への転換

「作る技術力」から「作らない技術力」への転換

SI事業者に求められてきたのは、作る技術、あるいは、工数を増やす技術であろう。開発生産性は、SI事業とは利益相反の関係にあるので、できるだけ、事業の現場の要求に合わせて、微に入り細に入りきめ細かく作ることで、お客様の期待に応えてきた。パッケージのカスタマイズやアドオンは、そんなお客様の要求に応えることであり、それが、「工数を増やす」というSI事業者の利益にも一致し、工数需要は、収益の源泉となってきた。

しかし、先にも述べたとおり、時代の潮流は、「作らない技術」を求めている。そのまま使えるクラウド・サービスやパッケージを目利きし、個別の業務システムにも柔軟に対処するためのAPIやアプリケーション・サービスバスを整備する。コンテナを前提にマイクロ・サービス化によってシステムの部品化をすすめ、サーバーレスやプラットフォーム・サービスと組み合わせることで、開発や変更の生産性を劇的に高めることで、変化に俊敏に対応できるようにする。運用も徹底して自動化し、継続的インテグレーション（CI）と継続的デプロイメント（CD）ができる開発実行環境を整備する技術者（SRE/Site Reliability Engineer）への需要が高まっている。

アジャイル開発やDevOpsとは、上記の「作らない技術」を前提に、できるだけシステムを作らずに、現場のニーズに応え、頻繁な改善と安定稼働を両立しようという取り組みである。だからと言って、UXが劣化することが許されるはずはない。そのためには、「現行業務を前提」にするのではなく、「業務のあるべき姿を前提」に、業務プロセスの再定義のために、あらゆる手段を使って現場を観察し、対話して、そのフィードバックに基づいて、高速に改善を繰り返すといった、およそこれまでの常識では考えられない、顧客との関係を築く必要がある。システムと業務、あるいは、エンジニアとお客様との関係における価値観を大きく変えなくてはならない。

このような価値観を体現するためには、「工数＝事業資産」から「技術力＝事業資産」への発想の転換が、根本にあることは言うまでもない。

「他律型」から「自律型」への転換

「はじめに仕様書ありき」で、納期と予算を固定して、それをプロジェクト・マネージャーの管理の下に、機能を分担しながら作り上げる「他律型チーム」が、これまでの受託請負型のやり方だった。しかし、クラウド・サービスの頻繁なサービスの拡張、現場のニーズへの俊敏な対応、沸き起こる新しい技術への試行錯誤的対応を、従来のやり方で対処することは難しい。

高い技術力、あるいは、業務や技術への高度な専門性を持つ個人が、チームとなり、それぞれが自分の役割を自ら考え工夫して実行する「自律型チーム」への転換が求められている。

このようなチームに求められるのは、自分の仕事や関わる技術が大好きであるということだ。大好きだからもっと知りたいと思うだろう、大好きだからスキルやノウハウを極めたいと思うだろう。その前提なくして、「自律型チーム」に参加することは難しい。

この前提の上で、業務上のビジョン、例えば、お客様にどのような価値を提供するのか、売上や利益はどの程度を目指すのかを全員で共有しなくてはならない。また、お互いの得意や不得意、精神状態、興味や関心などの個人的なことにも関心を払い、オープンに共有し、深い信頼に結ばれたチームであることが求められる。

プロジェクト・マネージャーから指示されることに従うのではなく、どうすればビジョンを達成できるかをひとり一人が常に考え、工夫し、「仕様書どおりに作ること」よりも「成果を実現すること」を優先しなければならない。

高い技術力、集中とスピード、HRT（Humility／謙虚、Respect／尊敬、Trust／信頼）といった、価値観を全員が持ち、経営者も含めて、これを自分たちの文化や風土へと落とし込むことが必要だ。

「受託型」から「共創型」への転換

お客様の事業の当事者である内製チームに、その一員としてSI事業者の技術者が参加し、システムを作り上げて行く取り組みが、「共創」である。「共創」が注目されるのは、社会の不確実性の高まり、多様性の拡大、変化の加速がある。この状況に対処するには、多様性を高め、変化に俊敏対応するための圧倒的ビジネス・スピードを求められる。しかし、単一の企業文化の中だけで、これらを担保することは容易なことではない。だから、自分たちとは異なる価値観や技術を持つ人たちと、「共創」することで、この状況に対処しようというわけだ。

「共創」には、ビジョンの共有、知識の共有、リスクの共有の3つの共有が必要だ。

ビジョンの共有

共創に関わる全員（お客様も自分たちも）が、業績の改善／向上のために目指すべきゴールとビジョンを深く理解し、これを共有すること

知識の共有

スキルやノウハウ、課題や悩み、意見や思いなどを、同じゴール／ビジョンを目指す仲間として、オープンに共有すること

リスクの共有

成果だけではなく、失敗やリスクも共有し、それぞれにとっての成果／リスクを完全に共有すること

従来型SI事業メンタリティでは、この３つの共有が難しい。例えば、「ビジョンの共有」を意識することより、「仕様の共有」が優先され、環境やニーズの変化に柔軟に対応すること、すなわち仕様の変更は、できるだけ避けたいと考える。

本来、仕様を変更するとは、環境やニーズの変化に対応することで、売上や利益、あるいは顧客の利便性を改善することに貢献するわけだから、当然にお客様のビジネスにとっては、価値を高める。しかし、システム開発の納期やコストにとっては、不都合であることから、できるだけ受け入れたくない。これは、「新たなビジネス価値を共に創る」との「共創」の理念とは反している。

また、「知識の共有」とは、あらゆる知識を共有することだ。例えば、新しい技術やサービス、ノウハウやスキル、進捗や課題など、全てだ。SI事業者はこれまで、知識の共有を限定していた。それは、ノウハウやスキルを相手に渡してしまうと、自分たちの存在意義を失ってしまうからだ。あるいは、自分たちの弱点や不都合を、顧客に知らせたくないからだ。当然、そんなご都合主義の関係では、顧客とSI事業者との信頼関係は育まれることはない。つまり、チームの一員にはなれない。すべてを共有できてこそ、信頼関係は築かれる。それができなければ、「共創」の前提は崩れる。

「リスクの共有」も避けたいところだ。従来型のSI事業は工数が収益の源泉なので、コストは保証されるという前提がある。しかし、未知な業務や技術にチャレンジすることは、大きなリスクを伴う。手堅い従来のやり方と技術であれば、そんな心配はない。しかし、「新しいことを創る／クリエーション」となると、リスクはつきものだ。お互いが技術や知恵を出し合うだけではなく、その成果もリスクも分かち合うことが当然だ。これができなければ、「共創」する意味はない。

3つのシナリオでSI事業を進化させる

これら3つの転換を前提に従来型SI事業を進化させてゆくためには、3つのシナリオが考えられるだろう。

ひとつは、既存事業の高収益化である。既存事業は、3〜5年程度の期間で見れば、売上は徐々に減少に転ずる。そこで、売上が減少に転じても利益を確保しつづけるための施策が必要だ。具体的には、以下の通り。

• 標準化・効率化のためのプロセス・リ・デザイン
• モダナイゼーション・クラウド化・自動化
• データ・ドリブン・マネージメント　など

上記に加えて、事業の構想やシステムの企画などの段階から、セキュリティや業務品質、ムダの排除を考慮した業務プロセス設計にも積極的に関与して、取り組む必要があるだろう。

次は、戦略事業の開発である。既存事業で収益があげられるうちに、こちらを育ててゆかなくてはならない。具体的には、以下の通り。

• 試行錯誤・非連続な探索
• 投資・M&A
• 既存事業からの分離（組織・評価・場所など）あるいは別会社の設立など

特に注意すべきは、「技術を使うこと」ではなく、「技術を活かすこと」だ。事業の原点は、課題やニーズにある。技術は手段に過ぎない。ところが、AIやIoTといった技術を使うことが目的とされてしまい、本来の目的であるはずの課題の解決やニーズの達成が、後付けにされてしまうような取り組みも見かける。「課題やニーズ」->「戦略」->「手段（プロセスと技術）」という順番を変えてはいけない。

最後は、デジタル・サービスの提供である。ITでお客様を支援するのではなく、自分たちがITを使って、お客様に直接デジタル・サービスを提供することだ。具体的には、以下の通り。

• 得意とする業務や技術の棚卸し
• 社会的需要や課題についての検討と考察
• 既存IT事業との業績や事業目的についての分離など

広義には、顧客のシステム開発や運用を支援するプラットフォームも含まれるが、さらに一歩進めて、エンドユーザーに直接ビジネス価値を提供するデジタル・サービスを運営することだ。

例えば、例えば、日本ユニシスは、2009年から、電気自動車（EV）の充電スタンド事業を展開している。さらにブロックチェーンを使って「間違いなく非化石に由来するエネルギー」であることを証明する「非化石証書」を発行し、二酸化炭素排出ゼロに取り組む企業に貢献している。また、日鉄ソリューションズの文書管理サービス「NsxpressⅡ」は、文書管理のSaaS提供に加え、契約書や図面などの紙の原本をスキャンし登録する作業や登録した原本の倉庫保管業務を一括して提供している。このようなエンドユーザーの便宜に直接応えるシステムとBPO（Business Process Outsourcing：自社の業務プロセスの一部を継続的に外部の専門的な企業に委託すること）を一括して提供している。

詳しくは、こちらの記事をご覧頂きたい。

>> 「IT人材」から「デジタル人材」へ　あなたはこの変化に向きあっているか

これまでやって来たことの延長線上で、事業を考えるのではなく、これから起きる未来から逆引きして考える。それは何も、既存を捨てるとか否定すると言うことではない。まずは、「既存」を神棚に上げて、「しばらくお預け致しますので、お守り下さい」と手を合わせ、深々と頭を下げて、一旦これを忘れる。そして、これから起こることに思いを馳せて、未来における自分たちの「存在意義／パーパス」を徹底して考える。そして、自分たちの「あるべき姿」を描くことだ。

「あるべき姿」を描き終えた後、再び神棚に預けておいた「既存」を、手を合わせて下ろしてくる。そして、「あるべき姿」との間にあるギャップを理解し、これを埋めるための物語を描く。これが、「事業戦略」だ。そうやって、自分たちを進化させる道筋を描くと良いだろう。

「まだ何とかなる」かどうかは、私にも分からない。しかし、早くやった方が良いことだけは、言うまでもない。

【募集開始】第37期 ITソリューション塾　5月19日・開講

5月から始まる第37期では、DXの実践にフォーカスし、さらに内容をブラッシュアップします。実践の当事者たちを講師に招き、そのノウハウを教えて頂こうと思います。

そんな特別講師は、次の皆さんです。
===
戸田孝一郎氏／お客様のDXの実践の支援やSI事業者のDX実践のプロフェッショナルを育成する戦略スタッフサービスの代表
吉田雄哉氏／日本マイクロソフトで、お客様のDXの実践を支援するテクノロジーセンター長
河野省二氏／日本マイクロソフトで、セキュリティの次世代化をリードするCSO（チーフ・セキュリティ・オフィサー）
===

DXの実践に取り組む事業会社の皆さん、ITベンダーやSI事業者で、お客様のDXの実践に貢献しようとしている皆さんに、教養を越えた実践を学ぶ機会にして頂ければと準備しています。

デジタルを使う時代から、デジタルを前提とする時代へと大きく変わりつつあるいま、デジタルの常識をアップデートする機会として、是非ともご参加下さい。

詳しくはこちらをご覧下さい。

• 日程 ：初回2021年5月19日(水)～最終回7月28日(水)　毎週18:30～20:30
• 回数 ：全10回＋特別補講
• 定員 ：120名
• 会場 ：オンライン（ライブと録画）
• 料金 ：¥90,000- （税込み¥99,000）

＊オンラインによるライブ配信、および録画で受講頂けます。

詳細 ITソリューション塾 第37期 スケジュールは、こちらよりご確認いただけます。

詳しくは、上記バナーをクリックしてください。

今年は、例年開催していました「最新ITトレンド・１日研修」に加え、「ソリューション営業の基本と実践・１日研修」を追加しました。

また、新入社員以外の方についても、参加費用を大幅に引き下げ（41,800円->20,000円・共に税込み）、参加しやすくしました。

どうぞ、ご検討ください。

ITビジネス・プレゼンテーション・ライブラリー