orangeitems’s diary

40代ITエンジニアが毎日何か書くブログ

デジタルトランスフォーメーション(DX)の幻想を学ぼう

f:id:orangeitems:20180911003615j:plain

 

経済産業省自身がDXをまとめる

デジタルトランスフォーメーション(DX)という掛け声が今年になってよく叫ばれることが多くなりました。いつものバズワードだと捉え静観している人も多いと思いますが、今回経済産業省自らが、「デジタルトランスフォーメーションレポート~IT システム「2025 年の崖」の克服と DX の本格的な展開~」という文書をリリースするに至りいよいよ、いろんな経営者が感化され技術者レベルで無視できない状況に差し掛かったようです。

 

www.meti.go.jp

経済産業省は、我が国企業がデジタルトランスフォーメーション(DX)を実現していく上でのITシステムに関する現状の課題の整理とその対応策の検討を行い、『DXレポート~ITシステム「2025年の崖」の克服とDXの本格的な展開~』として報告書を取りまとめました。

 

とても長いですが、システムエンジニアあるいはIT業界の営業の方は最後まで読むことをお勧めします。というのは、今後ベンダー側はもちろんのこと、経営者がDXについていろんなセミナーを受け、「わが社もDX!」と言い始めることが間違いないためです。

どんな文脈でDX協奏曲が始められたのか、今のうちに読破しておくことでスムーズに立ち回れるようになれると思います。

 

書評

つらつらと、読んだ感想を書いていきます。

まずはこの文章自体、DXに対する定義が文脈によって揺らいでいきます。もともとの根源的な意味は、自社のこれまでの経済活動をゼロベースで見直しデジタル中心のワークフローにすることで、市場でゲームチェンジャーとなることができ競争を勝ち抜くことができることです。しかし、じゃあ具体的にDXって何をするの?と問われると、AI、IoT、マイクロサービス、クラウド、AR/VR、ビッグデータ、アジャイル型開発・・です、とあります。ここで大きくずれています。おそらくIoTだけマイクロサービスだけ、小さく切り取ってPoC(研究)したとしても、なーんにもならないというのが日本流DX失敗です。まずはゲームチェンジするために最新の技術と現在のビジネスモデルをどうトランスフォーメーションするかを考えることが先です。昨今のDXの盛り下がりは各個別技術ばかりがフォーカスされ、結局DXできるかはやってみて考えるというふうな仕事の進め方に大きな問題を抱えているのでしょう。全体的にもやもやするのは、DX自体はドリームであり、個別技術によってドリームを実現できるかどうか答えがわかっていないということです。

次に、個別技術に惑わされずDXを実行したいとして、日本独特の商習慣、具体的にはITがベンダーに丸投げという記載に差し掛かります。アメリカはユーザー企業の中にIT技術者を抱えているから、DXをスムーズに進めやすいんだそうです。情シスと事業部門が一体となって計画できるし、CIOに丸投げにせずCEOも主体的にDXに参加できると。一方で、日本はITベンダーのほうが強いので、ユーザー企業がいいなりになりDXが遅々として進まないそうです。ウォータフォール型で要件定義から進めようとするから、そもそもどうDXを進めるかを、ベンダーに決めてもらわなければいけないのがおかしいとのこと。このあたりからDXというより、ベンダー丸投げ中心のIT統制が、システムのレガシー化(いわゆるブラックボックスとなり、保守運用・システム更新コストが高くなる)してしまうそうです。ここまで来ると、DXやるやらないより、まずITベンダーを解散してユーザー企業にばらまいた方が効果的であるかのように見えます。

レガシー化をどう防ぐかということもたくさん書かれていますが、

諸外国のようにユーザ企業が社内に IT エンジニアを抱えて、開発を主導している場合は、高頻度でかつ小規模に(細かく)プログラムをメンテナンスしつづける形態が一般的になる。短期間でメンテナンスを行い続ければ、結果的にブラックボックス化は起こりにくい。個人が持つノウハウもメンテナンスによって他のエンジニアに伝承しやすくなる。

というのは違うかなあと思います。構成管理を正しく行っていれば、ベンダーであろうがユーザーであろうが、その更新頻度にかかわらず、正しく運用できます。ドキュメントがぐちゃぐちゃだと、短期間でごりごり変更すると、「もうソース見て」の世界になります。マイクロサービスやアジャイルをそんなに神格化する必要もないと思いますし、ウォータフォール型でも十分レガシー化は防げますね。

この文書の肝は29ページ以降の「DX 推進システムガイドラインの構成案」にあると思います。これを真に受けるのではなく、下記のように考えるべきだと思います。

・経営者はこの話を聞いて帰ってくる
・ITベンダーがDXでSIを売るときはこの話が頭にある
・技術者は要素技術を求められているのではなく、この話のDXが実現目標にある

どの立場にいても、共通認識があれば大きく話はずれません。その意味では現実解としてこのガイドラインがあると思います。もっとかみ砕きましょう。

・経営者は、会社とITの関係を大きく見直す覚悟があるか。ないのならば、レガシーシステムを普通にシステム刷新していけばよく、そこに最新技術を組み込めばよい。これはDXではないが、技術的負債を解消することはできる。
・ITベンダーがDXを顧客に問いかけるときは、顧客のビジネス自体に切り込む覚悟が必要。場合によっては顧客に常駐しコンサル的な動きをする必要がある。また単にSIとしてこれを提供すると、「DXにふさわしい新しいビジネスを提供する」というかなり高度なサービス目標であり、達成されず検収できないリスクが大きい。じゃあ準委任か・・となり、いつまでたってもDXにたどり着かないダラダラしたプロジェクトになる可能性が高い。
・技術者は、DXという単語がプロジェクト概要に入っていたら警戒すること。アジャイルやIoT、AIなど流行りの技術が盛り込まれているのがDXとユーザー側が思い込んでいる可能性がある。どんなに最先端の技術であっても、結果を産まないシステムを作らされるのは、それこそ苦痛だ。

と言うことです。どうせ無視できないなら、この文書を先読みしておき、自分が本来の目的にリードしなおせるならば勝ちです。否定から入るのではなく、主体的に本来の目的に是正していくことでイニシアチブが取れ活躍できます。意思決定者はそもそもDXがやりたいのではなく技術的負債を清算したいだけなのかもしれません。経営者も特定のITベンダーと仲良くやっていきたいのかもしれません。また、システムごとにITベンダーをころころ変えるやり方が正しいとも思えません。自社にIT技術者がいることがアジャイルやマイクロサービスの本質であるのであれば、アメリカ流のDXをどう解釈しようと日本にピッタリ当てはまるはずはないと思います。

これ読んでおけば「おお、お前わかってるじゃないか」って経営者から評価されること間違いないです。技術ばかり追いかけるばかりが技術者ではないとも思います。

 

補足

基本的に、意思決定者が何か(えらそうに)しゃべるときって、元ネタが絶対にあります。であれば元ネタを徹底的に理解しておけば、それに対してもっと良い意見を主体的に披露し、本来あるべき姿へ自分からリードできるようになります。今回のように、政府やシンクタンク、日経新聞などから元ネタ的なレポートが出るときがあるので、逃がさず目を通しておくといろいろと有利に進められるのでお勧めします。

案外元ネタが穴だらけなことも多く、分量が多ければ多いほどその傾向が強くなります。また、ベンダー企業の利益誘導もされていることもあります。事前に著者も含めてチェックしておけば、本質を突くことができると思います。

 

3ステップで実現する デジタルトランスフォーメーションの実際