diaryクラウド専任の40代インフラエンジニアが書くブログ。新規事業マネージャー。20世紀末の就職氷河期スタート時にIT業界に文系未経験で入りこみそのまま生き残った人。1日2記事投稿しています(0:00、12:00)。DX経済産業省自身がDXをまとめるデジタルトランスフォーメーション(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ベンダーがDXでSIを売るときはこの話が頭にある・技術者は要素技術を求められているのではなく、この話のDXが実現目標にあるどの立場にいても、共通認識があれば大きく話はずれません。その意味では現実解としてこのガイドラインがあると思います。・経営者は、会社とITの関係を大きく見直す覚悟があるか。ないのならば、レガシーシステムを普通にシステム刷新していけばよく、そこに最新技術を組み込めばよい。これはDXではないが、技術的負債を解消することはできる。・ITベンダーがDXを顧客に問いかけるときは、顧客のビジネス自体に切り込む覚悟が必要。場合によっては顧客に常駐しコンサル的な動きをする必要がある。SIとしてこれを提供すると、「DXにふさわしい新しいビジネスを提供する」というかなり高度なサービス目標であり、達成されず検収できないリスクが大きい。準委任か・・となり、いつまでたってもDXにたどり着かないダラダラしたプロジェクトになる可能性が高い。・技術者は、DXという単語がプロジェクト概要に入っていたら警戒すること。アジャイルやIoT、AIなど流行りの技術が盛り込まれているのがDXとユーザー側が思い込んでいる可能性がある。どんなに最先端の技術であっても、結果を産まないシステムを作らされるのは、それこそ苦痛だ。無視できないなら、この文書を先読みしておき、自分が本来の目的にリードしなおせるならば勝ちです。否定から入るのではなく、主体的に本来の目的に是正していくことでイニシアチブが取れ活躍できます。意思決定者はそもそもDXがやりたいのではなく技術的負債を清算したいだけなのかもしれません。経営者も特定のITベンダーと仲良くやっていきたいのかもしれません。システムごとにITベンダーをころころ変えるやり方が正しいとも思えません。自社にIT技術者がいることがアジャイルやマイクロサービスの本質であるのであれば、アメリカ流のDXをどう解釈しようと日本にピッタリ当てはまるはずはないと思います。これ読んでおけば「おお、お前わかってるじゃないか」って経営者から評価されること間違いないです。技術ばかり追いかけるばかりが技術者ではないとも思います。基本的に、意思決定者が何か(えらそうに)しゃべるときって、元ネタが絶対にあります。あれば元ネタを徹底的に理解しておけば、それに対してもっと良い意見を主体的に披露し、本来あるべき姿へ自分からリードできるようになります。今回のように、政府やシンクタンク、日経新聞などから元ネタ的なレポートが出るときがあるので、逃がさず目を通しておくといろいろと有利に進められるのでお勧めします。元ネタが穴だらけなことも多く、分量が多ければ多いほどその傾向が強くなります。ベンダー企業の利益誘導もされていることもあります。事前に著者も含めてチェックしておけば、本質を突くことができると思います。最近、知らない間にノーコードという言...2020-10-21DXを阻む「21の習慣病」へのコメント(パート3)下記記事の続きです。00:00クラウド専任の40代インフラエンジニア。新規事業マネージャー。20世紀末の就職氷河期スタート時にIT業界に文系未経験で入りこみそのまま生き残った人。1日2記事投稿しています(0:00、12:00)。引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。