ユーザ企業としてのDX(Digital Transform)は、こと先進的ITの華々しいイメージが強いですが、DXの本質は、業務や風土の改革にも踏み込んだシステム刷新だと考えます。このあたりの必要性や世間一般的なよくある誤解についてまとめました。何かの参考になれば幸いです。 ※ 特定の企業や団体について固有の話を述べたものではありません。

1. DX完全に理解した
DXわけがわからないよ
…なユーザ企業に伝えたいこと
2020年3月21日
宜保 洋平 (Yohei Gibo)
ITストラテジスト、中小企業診断士(試験合格)
https://www.facebook.com/profile.php?id=100002830583283
https://www.linkedin.com/in/yohei-gibo-7453a91a5/

2. 【Transform】
トランスフォーム
一変させる、変形[変容]させる
(性質・機能・用途などを)すっかり変える

3. このスライドでやりたい話
【DXレポート＠経産省】
• ユーザ企業の取り組み方について、
体系的にまとめられている公的資料
• 一番大事なところがストレートではない。
• 本質は…
企業としてDigital Transformするためには、
業務や風土の改革にも踏み込んだシステム刷新が必要

4. 経産省レポートが言っていること
挑戦
ITの
あれ
圧倒的
成長
割とよくある誤解

5. 挑戦
ITの
あれ
圧倒的
成長
それ、違うんだよなぁ～
経産省レポートが言っていること

6. 経産省レポートが言っていること
今後DXを本格的に展開していく上では、DXによりビジネスをどう変えるかといった経営戦略
の方向性を定めていくという課題もあるが、そもそも、既存システムが老朽化・複雑化・ブ
ラックボックス化する中では、データを十分に活用しきれず、新しいデジタル技術を導入した
としても、データの利活用・連携が限定的であるため、その効果も限定的となってしまう。
（本文 １．検討の背景と議論のスコープ）
ブラックボックス化した
既存システムを刷新
DXで圧倒的成長！
そのためには

7. なんか誤解されそうなところ
弊社は大丈夫です！！
・情報インフラをオープン化
・ドキュメントを整備
・技術者の確保
・・・

8. なんか誤解されそうなところ
弊社は大丈夫です！！
・情報インフラをオープン化
・ドキュメントを整備
・技術者の確保
・・・
問題の根本は
このレイヤ(既存システム)
ではない

9. なんか誤解されそうなところ
ここ！！
こいつ何

10. なんか誤解されそうなところ
業務要件

11. 一応レポートでも言及している 目立たないけど
既存システムの問題を解消しようとすると、ビジネス・プロセスそのもの
の刷新が必要...
（本文 １．検討の背景と議論のスコープ）
すなわち、既存システムの問題を解決するためには、業務自体の見直しも
求められることになるが、それに対する現場サイドの抵抗が大きく、いかに実行
するかが大きな課題となっている。（本文 2.3.1 経営層の危機意識とコミットに
おける課題）
特に、業務プロセスや周辺システムとの関係を明確にして、将来あるべき
システムのビジョンを描くことが非常に重要である。（本文 2.3.4 ユーザ企
業におけるIT人材の不足）
業務の簡略化や標準化を行い、システムのカスタマイズコストとそれを実施す
ることによる経営のメリットのバランスを評価しているか（本文 3.1 「DX推進ガ
イドライン」の策定

12. 業務要件を再点検すればいいんでしょ？
業務要件の再点検ね。
既存システムの利用状況アンケートで
さっと効率的に済ませますか～
「廃止してよい機能はありますか」
「改修要望の実施状況はどうですか」

13. 業務要件を再点検すればいいんでしょ？
業務要件の再点検ね。
既存システムの利用状況アンケートで
さっと効率的に済ませますか～
「廃止してよい機能はありますか」
「改修要望の実施状況はどうですか」
そんなレベルの
ものではない！
！！！

14. 業務要件を再点検すればいいんでしょ？
要件とシステムの間
だけの問題ではなく

15. 業務要件を再点検すればいいんでしょ？
業務要件そのものが
おかしい
ただ、たいてい反論が来る

16. 業務要件を再点検すればいいんでしょ？
業務要件そのものが
おかしい
でも業務はちゃんと回ってるよ
おかしい所だけ直せばいいじゃない
既存システムベースで何が悪いの

17. 業務要件を再点検すればいいんでしょ？
業務要件そのものが
おかしい
でも業務はちゃんと回ってるよ
おかしい所だけ直せばいいじゃない
既存システムベースで何が悪いのその先入観は
危険！！

18. なぜ業務要件はおかしくなるのか
・背景：業務要件の複雑化 グローバル化、コンプラ、働き方改革…
・対応：業務のマイナーチェンジを繰り返してきた
・結果：業務がツギハキ化、フラグメンテーション化
・放置すると「わかる人がいなくなった」で常態化・深刻化

19. 怖
※フィクションです（何かの予防線）
～開かずの業務（ブラックボックス）～
本当にあった怖い話

20. 怖第一の恐怖
ある情シスが、業務部門から改善の相談を受けた。
「毎月、Excelで膨大な量のデータを出力する決まりがあり、
大変なので省力化したいが、実はもう誰も中身を知らない。
何とかしてもらえないか。」
情シスはRPAで自動化し、50％の省力化を達成した。
成果に満足した情シスは、上司にアピールするため、この
データの内容と用途を尋ねた。すると、
「それが…。他の部門がデータを利用できるように共有
フォルダに置いているだけで、誰が何に使うのかなんて、
私にはさっぱり…。」

21. 怖第二の恐怖
ある情シスが、システムのリプレースを担当することと
なった。古い機能が多く作業は難航したが、特定の機能を
廃止できれば、問題点の多くが解消すると判明した。
幸い、その機能は何年も利用されていないことがわかった。
また、重要な機能でないことは明らかだったので、情シス
は業務部門に、廃止の方向で調整を進めた。
数日後、業務部門から返事の電話がきた。
「あの…例の機能ですけどね。なぜ使われなくなったのか
調べてみたのですが、古すぎて課内の誰に聞いても、知ら
ないというのですよ。」
情シスは、それもそうだろう、と思いながら、廃止の結論
が述べられるのを待った。しかし、
「廃止できる根拠が無い以上、継続でお願いします。」

22. 怖第三の恐怖
ある情シスが、総務から相談を受けた。「役員や高役職者
の出張が増えて、決裁書類が滞留する傾向になっている。
なんとかならないものか。」
そこで、情シスは出張中でも決裁ができるよう、電子承認
基盤の導入と、タブレット配布の拡大を検討することにし、
その方向性に総務は満足した。
ふと、情シスは気になったことを聞いてみた。例えばタブ
レット数十台の追加購入の場合、社内の決裁行為は、何回
発生するのか、と。
「そうですねぇ。その程度の規模なら入庫や精算まで含め
だいたい60回ぐらいで済むかと…。」

23. おわかりいただけただろうか…
でも業務はちゃんと回ってるよ
おかしい所だけ直せばいいじゃない
既存システムベースで何が悪いの
・業務要件の異常性は、
中の人には気づかれにくい
・業務要件を変えるのは面倒
PDCA = Please Don’t Change Anything

24. つまり？
ブラックボックス化を
疑い、向き合う

25. ブラックボックス化を
疑い、向き合う
一番ダメなパターン
・わが勢がこのような
無能のわけがなかろう！
・そのようなことは
日々の改善で済む話ぞ！
都合の悪いことを疑わない、向き合わない
→ 大本営的組織へ

26. 正しい向き合い方
ブラックボックス化を
疑い、向き合う
・ブラックボックスは、いま見つけないとまずい…
・ゼロからの業務再定義は大変だけど、
ブラックボックスはとことん潰して、
意味のある業務だけにシフトするぞ

27. 正しい向き合い方
１．業務要件の再定義
２．システムの再構築

28. 正しい向き合い方
システムの再構築
１．業務要件の再定義
メリット１
・必要十分な機能に絞り込める
・適切な余力を生み出せる
・業務で生み出すデータの意味を明確化できる
→ 新たな価値創造の基礎となりうる

29. 正しい向き合い方
業務要件の再定義
２．システムの再構築
メリット２
・昔に比べて効率的に構築できる
・昔に比べて運用保守を省力化できる
・昔ではできなかった要件を実現できる
通常、この段階ではじめてIT施策が登場する
※特殊要件は除く
・クラウド
・アジャイル、マイクロサービス、DevOps
・AI、ビッグデータ
・ドローン、ロボティクス

30. 正しい向き合い方
１．業務要件の再定義
２．システムの再構築
Jump!

31. ２．システムの再構築
１．業務要件の再定義
ユーザ企業にとってのCSF

32. １．業務要件の再定義
ユーザ企業にとってのCSF
• セクショナリズムに陥らない
→ 全社プロジェクトとして推進する
• 決してベンダー任せにしない
→ 社内の要件定義人材をプロジェクトの中核に
• 社内の共通的な制度や文化も見直す
→ 権限移譲、人事評価/配置にも踏み込む

33. １．業務要件の再定義
「人・組織」の留意点
• セクショナリズムに陥らない
→ 全社プロジェクトとして推進する
• 決してベンダー任せにしない
→ 社内の要件定義人材をプロジェクトの中核に
• 社内の共通的な制度や文化も見直す
→ 権限移譲、人事評価/配置にも踏み込む

34. 留意点①「人」の観点
（１） ユーザ企業において求められる人材
• CDO (Chief Digital Officer)：システム刷新をビジネス変革につなげて経
営改革を牽引できるトップ人材
• デジタルアーキテクト(仮称)：業務内容にも精通しつつ IT で何ができる
かを理解し、経営改革を IT システムに落とし込んで実現できる人材
• 各事業部門においてビジネス変革で求める要件を明確にできる人材
• ビジネス変革で求められる要件をもとに設計、開発できる人材
• AI の活用等ができる人材、データサイエンティスト
（本文 3.5 DX人材の育成・確保）
→ 要件定義人材の確保が最重要

35. 留意点①「人」の観点
・初期の IT システム構築は、ユーザの作業を写し取って論理化し、「要件
定義」としてきた。
・現在のユーザは、システムがある状態で仕事をするのが当然となっている
ので、システムの 全貌と機能の意義が分からない状態であり、従来のよう
な「要件定義」をする能力を喪失している。
（本文 3.5 DX人材の育成・確保）
→ 要するに、
・昔の要件定義はヘタクソ
・今はもっとヘタクソ

36. 留意点②「組織」の観点
• 「破壊的イノベータ」の組織文化は、大いに参考になる
• 全てを真似るのは不可能だし無意味
• 「なぜ彼らは勝ち続けることができるのか」を知ることが重要
• 比較すると自社の欠点や異常性が見えてくる
• 必要なところは直せばいい
（ただし文化を変えるのは相当大変）

37. DXの初手にやるべきこと①
• トップがコミットメントを明確に示すこと
・ITシステムを刷新
・業務や風土/共通ルールも刷新
※ 権限移譲や人事制度・風土改革にも具体的に言及すると効果的
3.3 節で述べたとおり、IT システム刷新は、システム構築や投資回収に長時間と多額の支出を
伴い、失敗のリスクもあるため、経営者は中長期的な観点から実行の可否を検討することが求
められる。
また、IT システムは、経営戦略や業務に合わせて全体最適化を実現することが必要であるため、
経営層は、事業部門や情報システム部門と連携して、全社的な業務プロセスの改善等にも取り
組む必要がある。そのため、経営トップによる中長期的なコミットが不可欠である。
（本文 3.5 DX人材の育成・確保）

38. DXの初手にやるべきこと②
• トップのコミットメントに強く賛同し熱量を持った
要件定義人材を、社内の各部署から集める。
・それなりの大所帯が長期間必要
・立候補者を公募し、面接や小論文などで熱量と力量を確認する
・各部門からエースを出し惜しみされないように、フォローは太っ腹に

39. 【Transform】
トランスフォーム
一変させる、変形[変容]させる
(性質・機能・用途などを)すっかり変える
DXの道は険し…。
だがここまでやれば、
Transform に相応しい。
良いDXライフを！