事業会社のためのDX推進の概観
2018年9月、経済産業省が「DXレポート～ITシステム『2025年の崖』の克服とDXの本格的な展開～」を発表、徐々にデジタルトランスフォーメーション（以下DX）という言葉が注目されるようになりました。
社会情勢としては目に見えない驚異が世界的な広がりを見せ、幸か不幸か働き方やビジネスも大きく変わっていきました。そんなことも相まって、今では企業のIR資料や広告でDXという言葉を見ない方が珍しいかもしれません。
一方で、DXという言葉が一人歩きしてしまっているのも事実です。Zoomでミーティングをして、Googleスプレッドシートで資料を共有するだけで「わが社もDXを行っています」と宣言する企業が一定数あると想像できます。
DXレポートではレガシーシステムの問題点が多く取り上げられており、企業にとっても身近な問題であるため、レガシーシステムの刷新や業務効率化のためのシステム導入のみを指してDXと読み違える人もいるかも知れません。
ここではDXの定義の再確認から始めて、DXレポートの内容を含めながら、事業会社のDX推進を取り巻く状況や、今後DXを推進するにあたって必要なことなどを大まかに記載します。なお各所に参考リンクも記載しました。
DXの定義の再確認
DXの定義を改めて確認すると、2019年7月に取りまとめられた「DX 推進指標とそのガイダンス」では次のように定義されています。
企業がビジネス環境の激しい変化に対応し、データとデジタル技術を活用して、顧客や社会のニーズを基に、製品やサービス、ビジネスモデルを変革するとともに、業務そのものや、組織、プロセス、企業文化・風土を変革し、競争上の優位性を確立する
(https://www.meti.go.jp/press/2019/07/20190731003/20190731003-1.pdf)
単にIT化を指して「DX」と呼ばれることもありますが、現在日本で注目を集めているのはこの経済産業省の定義が中心だと思います。この記事でもこのの定義に則って議論します。
DXが必要とされる理由
昨今の情勢でも注目されたように、世界のビジネスはすでにゲームチェンジが起こっています。一見デジタル産業とは関係なさそうなあらゆる事業において、これまでとは全く違った競合と戦うことになる可能性があります。
今や車両を持っていないUberが「タクシー会社」のトップ、ホテルを持っていないAirbnbが「ホテル業」のトップと言うことができます。Amazonを始めとするECの需要も大きく、人々の生活や文化までもが変化してきています。
歴史をたどれば、良いものを作っていれば売れていた時代から、営業力・マーケティングが必要な時代になり、そして現在ではデータ分析・AIによる需要予測など、より高度な戦略を必要とする時代となりました。
そのため、デジタル技術を利用したビジネスモデルの確立や、企業活動によって生まれるデータの活用によって競争優位に立つことが必要不可欠なのです。もはや、どの業界でもDXの推進が他人事ではいられなくなりました。
事業会社と開発会社の関係性の現状
デジタル技術を利用したビジネスモデルはあらゆる業界において主流となり得ますが、DXレポートでも指摘されているようにいくつかの問題点があります。その１つが事業会社とシステム開発会社の関係です。
現在（執筆時点）日本の事業会社のシステム開発は請負契約によって開発会社が請け負うことが主流です。それは事業会社にIT人材がほとんどいないことが主な理由ですが、なぜその様になったのでしょうか。
保険的役割
まず言えるのが、請負契約がある種の保険的な役割を担っているからです。請負契約はシステムの完成によって対価が支払われます。開発会社の都合で開発が完了しなかった場合は損害賠償を請求される可能性があります。
また、開発に関わる人材の確保も開発会社が行うため、事業会社としては進捗の不確実性に対して人材採用に関するリスクを抑えられるのです。これが長く続けられてきたため日本のシステム開発の慣習となりました。
IT部門の子会社化
別の理由として、日本の解雇規制が挙げられます。日本の法律ではITの投資を縮小させる際に簡単に人員を削減させることはできません。そこで資金力のある事業会社はシステム開発の子会社を作ります。
子会社は独立採算のため、自社グループ以外のシステムも開発します。それがいわゆる「ユーザー系SIer」と呼ばれる会社です。これが日本の事業会社にIT人材が少ない要因にもなっています。
事業会社にIT人材がいないことで起こる問題
コスト増大
事業会社にIT人材がいないことで、システム開発の主導権が開発会社側になってしまいます。多くのシステムが汎用的なパッケージソフトウェアではなく、カスタマイズされたシステムなのでメンテナンスが難しく、開発会社の言い値になる可能性があります。そのためコストが跳ね上がります。
レガシー化
開発会社自体も多重下請けなどの問題をはらんでいる場合があり、ノウハウが蓄積されていない可能性があります。そのためシステムがビジネスの進歩に追いつけずにレガシー化し、技術的負債を抱えることになります。
継続的変革できない
事業ドメインについて最も理解しているのは事業会社自身ですが、事業がデジタル化してゆく中で、その中核を担うシステムが他社依存だと行動が遅れてしまいます。また、レガシーなシステムが足かせとなり、なかなかデータ活用もできないという状況に陥ります。
事業会社に必要な推進力
内製化
DXを推進してゆくにあたって大事なことは、システムを内製化することだと考えます。なぜなら、デジタル技術を利用したビジネスモデルの確立は、その企業の核となってくる部分であり、それを他社に丸投げするわけには行かないからです。
どの部門が先導するか
DX推進の取りまとめを行うのは情シス部門であることが多いかもしれません。ところが、情シス部門が事業部門に強い権限を持って口出しするのはなかなか難しいでしょう。一方で事業部門も目の前の成績を重視しがちです。
それぞれの部門がDXを自分事として捉える必要がありますが、強い統率力も必要です。一案として「社長室直下」のような組織が取りまとめるとうまくいくかもしれません。
レガシー化しにくいシステムを作るには
少し技術面にも踏み込んだ話をします。IT技術は日々進化しており、10年前に主流だった技術が今ではもう使われていないということが多々あります。それに対応するにはレガシー化しにくい技術の選択が必要になります。
クラウド技術
インフラの調達からソフトウェアの開発まで、全てを１から作るのはあまりに膨大です。そこで既存のものを組み合わせます。例えば下記のような「クラウドサービス」は超巨大なインフラを持ち、利用者は数クリックでそのインフラを低コストで調達できるため、システムの拡大縮小が容易です。
Amazon Web Service (AWS)
Google Cloud Platform (GCP)
Microsoft Azure (Azure)
ソフトウェアの開発に関しても、クラウドサービスにはデータ分析や、最小限のコードでソフトウェアを動かす仕組みも充実しているため、それらを利用することで事業の進化に合わせてアップグレードがしやすくなります。
アジャイル開発
アジャイル開発手法は、要件定義・基本設計・詳細設計・実装・単体テスト・結合テスト…と各工程を順に行うウォーターフォール開発と違い、はじめから小さな動くシステムを作ります。
常に動くシステムを改善しながら大きくしてゆくので、開発途中での外部要因の変化や、前提が間違いであったことに気付いたときに比較的対応がしやすい手法です。
開発会社の選別と契約
最終的には事業会社自身がデジタル技術を駆使し、旧来の事業をアップグレードし続けられるようになるのが理想です。そのためにはIT人材の採用・育成、枠組みの作成が必要ですが、これらはすぐにできるものではありません。そこで開発パートナーの選別が必要になってきます。選別の基準の１つは「伴走型パートナー」であることです。
伴走型パートナー
DXを推進はシステムは作って終わりではありません。常にビジネスに合わせてアップグレードします。そこで選択するパートナーは、事業会社の担当者と一緒に改善を繰り返すことができる必要があります。それをここでは「伴走型」と呼びます。その間に徐々に人材を育成し、自社にノウハウも蓄積して、最終的にはシステムも内製化してゆくことが重要です。
準委任契約（など）
これまで事業会社と開発会社の関係は、主に請負契約でした。これは仕事の完成を約束し、それに対して報酬を支払う契約です。システムの完成の義務を負うのである種の保険的な意味合いもありました。
しかし、事業会社と一緒に改善を繰り返してゆく伴走型パートナーとの契約ではマッチしない可能性が高いです。考えられる選択肢の１つは準委任契約です。モノの完成ではなく行われた作業に対して対価が発生する契約です。
技術ノウハウ
レガシー化しにくいシステムを作るためにクラウド技術やアジャイル開発に関するノウハウを持っているパートナーを選択すると長期的に見てコストを削減できます。コンサルティングだけでなく開発を担えることも重要です。
予算の確保の問題
請負契約で1つのシステムを開発するというのは成果物がはっきりしているため比較的予算確保がしやすいと思われますが、DX推進では不確実なことも多いため考え方を変える必要があるかもしれません。小さな予算で始めるなどの調整も必要でしょう。投資対効果ではなくコストとして予算確保するという考え方もあります。
選別の難しさ
デジタル技術に関するノウハウが無い事業会社にとってはパートナーの選別も難しい問題です。各社に提案依頼書を出すことも考えられますが、伴走型と提案依頼書ベースの提案はあまり相性がよくなさそうです。
そもそも伴走型パートナーとなり得る会社もまだ多くありません。「DX」という言葉は各社使っていますが、なかなかその違いを見いだせません。開発会社自身がDXに対して危機感を持って取り組んでいることが重要です。
攻めのDX
企業活動によって生まれるデータの収集、そのために今あるシステムを改善して利用しやすくするのを守りのDXとするならば、デジタル技術を利用したビジネスモデルの確立は攻めのDXと呼べます。
今後はそのどちらもが必要になってくるでしょう。しかし、ビジネスモデルの確立がそう簡単にできるのなら苦労はしません。そこで最近は「デザイン思考」が注目されています。
デザイン思考
デザイン思考はデザインを行う過程で用いる手法をビジネスの問題解決に利用する考え方です。「デザイン」といえば日本では表面的な装飾のことというイメージがありますが、ここで言うデザインは顧客ニーズを汲み取って「設計する」という意味が近いです。
誰を雇うべきか
何度も繰り返しますが、DXには内製化が重要な要素です。そのためにIT人材が必要になってきます。なお重要なのは自社内にノウハウが蓄積されることなので、正社員や派遣社員などといった契約形態の議論ではありません。
専門性の領域
実はITエンジニアと言ってもその専門性は細分化しています。機械への組込みシステムのエンジニアもいればWeb系システムのエンジニアもいます。さらにWeb系エンジニアがフロントとバックエンドに別れていたり、機械学習や分析に特化した人もいたりします。テストを中心とする人もいます。IT人材のいない状態から誰を採用すべきか判断するのは難しいでしょう。
技術部門のマネージャー的な人
適切な人材を採用するためにも、まずはそれを判断する人が必要です。最初に望ましいのはCDO(Chief Digital Officer)と呼ばれる経営者視点でDXの推進力となる人でしょうか。
あるいはプロダクトマネージャー、ソリューションアーキテクト、エンジニアリングマネージャーなどシステム開発をリードできる人材から採用するのが良さそうです。このあたりは企業の状況にもよります。
人材はどこにいるのか
DXを行うときの人材採用は、アジャイル開発などに精通した人材が望ましいです。彼らはどこにいるのでしょうか。日本の場合、流動性の高い人材はベンチャー企業やWeb系と言われる自社サービスを開発している会社にいることが多い印象です。
B2Cのビジネスは特に、少ない人数で何万人ものユーザーにサービス提供をする必要があり、クラウドサービスがよく利用されます。参入障壁もそこまで高くないため、競争も激しくサービスのアップグレードが常に行われています。そのため、早い段階からアジャイル開発が取り入れられてきました。
しかし、その中でも優秀な人材は他業種に比べて高給で、外の業界にあまり流出しません。今後Web系企業・開発会社・事業会社で人材の取り合いになる可能性があります。早くから制度設計等に取り組む必要があるでしょう。
DX人材の育成
非IT企業にとって優秀なIT人材を採用するのは難しいかもしれません。これまで採用実績のある企業と競争になるためです。そこで人材の育成も考える必要があります。
１つの方法は伴走型パートナーである開発会社とともに自社の人材も開発に加わることです。そうすることで開発会社からノウハウを得ながら開発を進めることができます。それが伴走型パートナーの１つの役割でもあります。
Appendix: 読むべき資料
この記事が気に入ったらサポートをしてみませんか？