こんにちは！
関西の上場企業でDX（デジタルトランスフォーメーション）を担当している“ろっきー“といいます。
このページでは、
- DX担当5年目の私が過去にやらかした失敗談
- 同じ失敗をしないための予防策
をリアルな体験に基づいてご紹介します！
- ウチの会社にDXなんてどうせ無理…
- わたしITとか詳しくないから口を出さないでおこう…
DXに対して、こんな風に”苦手意識”を感じている人は多いですが、DXを成功させるカギは実はとてもシンプル！
それは、誰もが陥る「失敗パターン」を避けること
失敗の”予兆”をとらえて回避することさえできれば、当初の目的を120％達成できるDXが実現しますよ。
社内の評価もUP間違いなし！
この記事では、DXを進めるなら絶対に避けたい4つの失敗を、私の実体験を混ぜながら紹介します
一緒に会社DXを成功に導きましょう！
DXの失敗には2種類ある
DXに挑戦したのに上手くいかない…
肝いりでスタートしたプロジェクトが頓挫してしまうと、時間もコストも水の泡になってしまいますね
実は、DXの失敗は大きく2つのパターンに分けられます
- コストが掛かりすぎて失敗
- 新システムがほとんど使われず失敗
DX担当を5年続けた私の感触としては、失敗の9割がこのどちらかのパターンに当てはまります
ということは、この2つさえ避けられればDXは成功するね！
この記事では、そんな2つの失敗例にあてはまる具体的なケースとして、DX担当5年目の私が実際にやらかしてしまった失敗談を紹介します
それぞれについて、予防策（＝こうしていたら防げたな、今ならば分かること）も一緒に紹介しますね！
【5年目のDX担当がやらかしたDX失敗例】
早速見ていきましょう！
＼デキるDX人材の思考が分かる①／
１．念のためが重なってコストが急増
新しいシステムを設計するとき「念のため」とか「無いよりはあった方が…」なんて理由であれこれと機能を追加するのは“失敗のもと”です
やりすぎると思いもよらないコスト増に直結します
複雑なシステムほど、後から変更するときの工数も多いからね
【Point】
システム導入は「小さく始めて大きく育てる」が原則！
最初から100点を目指そうとしなくていいです
＼デキるDX人材の思考が分かる②／
エピソード：システム変更に数百万円かかった話
この「念のため」を重ねすぎて失敗してしまったケースとして、私の会社で経費精算システムを入れ替えた時のエピソードを紹介します
【※経費精算システム】
業務のために使った飲食費や交通費、事務用品を従業員が立て替えて、後日会社宛てに請求するためのシステム
一般的な経費精算システムでは、従業員が入力する項目は次の5つくらいでしょう
- 日時
- 金額
- 支払先
- 目的
- 経費コード
ところが、私の会社で経費精算システム導入したときは違いました
経理部の担当が「念のためこの項目も…」「無いよりはあったほうが…」なんて言ってるうちに入力項目が20以上に拡大！
（追加した項目）
- 購入都市
- 同行者
- 検収量（購入量）
- 過去の購入歴
- 支払方法 など…
当然ながら「入力する内容が多くて面倒くさい！」と従業員からクレームが噴出します
さらにインボイス制度（2023～）に合わせて、システムを大改修することに…
変えなきゃいけない箇所がいっぱいだ…
ところが、システムの変更は業者しかできません
導入時にあれこれ追加してしまったせいで「重く」なったシステムは、柔軟な変更には全く対応できませんでした
結局、数百万円もの費用を払って変更してもらうハメに…
予防策①：MustとMayの区分けをしよう
DXプロジェクトで「念のため」「無いよりはあった方が」という考え方で仕様を増やしていくと、同じような失敗にはまります
上記のケースのようにならないためにはどうすればいいのでしょうか？
【結論】
システム化プロジェクトのなるべく早い段階で、求める条件を「２分割」してください
2分割とは、
①Must（マスト）条件と②May（メイ）条件です
- Must条件：システムとして絶対必要な機能
- May条件：費用やスケジュール次第で実装したい機能
先ほどの経費精算システムでいうと、
① Must条件
支払日や支払先、金額など会計業務の運営上、そして法律（＝会社法や電子帳簿保存法など）上で絶対に必要になる項目
② May条件
上記以外。経理担当者にとって「あればより分かりやすいよね」レベルの情報
【Point】失敗の原因は、
１）Must条件を決めていない、または
２）May条件をMustだと思い込んでいるかのどちらかです
May条件については、価格や開発期間などの制約によっては、実装を諦めるか先延ばしにするかの判断をしましょう
予防策②：ユーザーでメンテできるシステムを選ぶべき
予防策をもう一つ。
ベンダー（＝システム開発業者）しか仕様を変更できないサービスは、まず選ばないようにしてください
多少の項目追加や変更くらいなら、ユーザー側で対応できるようなプラットフォームを持っているシステムの方が絶対に後悔しません
リリースしてから1度も変更を加えなくてもいいシステムなんて存在しないからです
どんなに時間をかけて作りこんだシステムでも、運用をスタートすると必ず仕様変更が発生します
- 思いもよらないミスが見つかった
- 追加で機能を実装したい
- 法律が変わったので対応させなければ、など
【Point】
些細な変更でもベンダーに都度依頼をしなければならないようなシステムでは、正直いって”カモ”にされるだけです
ここも変更？
じゃあ作業費○万円ね！
ITシステムはベンダーに外注する機能と自社で制作する機能をバランスよく配置しましょう
２．スモールスタートのつもりが億越えに
「船頭多くして船山に登る」ということわざをご存じですか？
指示する人間が多いために、見当違いの方向に物事が進んでしまうことの例えです
DXプロジェクトでも、最初は1人のリーダーで船出したはずなのに、周囲の人間が好き勝手に方向を変え始めた結果、最終的に”沈没”してしまうケースは少なくありません
【Point】
繰り返しになりますが、小さく始めて大きく育てるが基本です
小舟でもいいので漕ぎ出すこと！いきなり大型船で出航してもすぐに難破してしまいます
エピソード：人事評価システムで大失敗
そんな船頭多くして船が沈んでしまった例として、タレントマネジメントを導入したときのエピソードを紹介します
タレントマネジメントとは？
→こちらをチェック！
もともとは「営業スタッフの人事評価をスムーズにしたい」という人事部の悩みが出発点でした
Excelを駆使しながら何時間もかけて計算していた人事評価を、IT化して楽にすることが目的です
ところが、プロジェクトが進むなかで“うわさ”を聞き付けた他の部門が次々と参戦。
やりたいことがどんどん増えてしまい、それぞれが勝手な要望を加え始めます
- 入社/退職の手続きを簡素化したい
- 海外で働くスタッフの労務管理をしたい
- 子会社の組織を親会社で管理したい
- でも今の仕事のフローは一切変えたくない など
まるで、人事なら何でもできるシステム求む！と言わんばかり…
もともとタレントマネジメントに見込んでいた予算は300万円。
ところが、ITベンダーが最終的に提示した見積は１億円を超えていました
当然、支払えずにプロジェクトは打ち切り…
人事担当者は今でもExcelを駆使してスタッフ評価を続けています
予防策①：プロジェクトオーナーを決めよう
このように、1つのテーマで船出したはずのプロジェクトがいつの間にか大きくなり、コストやスケジュールの面から頓挫してしまうケースは少なくありません
いったいどうすればよかったのでしょうか？
ここでは２つの「予防策」を紹介します
1つ目：プロジェクトオーナーを決めましょう！
オーナーとは「決定する人」と考えてください
（Aを取るかBを取るか…そんな状況で最終ジャッジを下す人です）
ちなみにオーナーになるべき人は、プロジェクトの影響（良い影響も、悪い影響も）を最も受ける部門のトップです
たくさんの部門や担当者の意見を聞くことは悪いことではありません
しかし、様々な部門から要望されると、担当者はつい期待に応えたくなってしまいます
その結果、先ほどのエピソードのように「何もかなわない」ことも…
本末転倒だね…
上述のケースでは、人事部長がオーナーになるべきでした
失敗を避けるために必要だったのは、他の部門の担当者が追加でグダグダ言い始めた時に「それはプロジェクトのMust条件（※参照）ではない！」とはねつける人だったと思います
予防策②：API連携でいいとこどり！
2つ目：API連携の可能性を探ってみましょう！
APIとは、2つ以上のシステムを繋げて、データをやり取りさせる仕組みです
1つのシステムであれもこれもすべてを解決しようとすると、結果的に高コスト・低品質なシステムに仕上がることがあります
ベンダーにも得意・不得意があるからね
例えば人事系のシステムであれば、
- 給与や勤怠には強いけれど
- 人事異動のシミュレーションは苦手、みたいな感じ。
苦手な領域までムリに実装しようとすると、コストが増えるか品質が落ちるかのどちらか…
そんなときはAPI連携によって、2つ以上のシステムを繋ぐことを考えてください
2つのシステムを“いいとこどり”した方がメリットは大きいね！
（API連携のメリット）
- 導入コストが安くなる
- リリースが早くできる
- ユーザーに豊富な機能が提供できる
【Point】
システムで実現したいことが多岐にわたった時は、API連携を前提にベンダー調査をすると突破口が開けるかもしれませんよ！
３．導入ゴールで使われないシステム
何のためにシステムを導入するの？
この議論が不十分なDXを進めると、待っているのは”大失敗”です
【Point】「目的」と「手段」は違います
目的はあくまで会社の課題を解決すること。DXはそのための手段にすぎません。
- 目的（課題）
若手の離職率が高いので対策を打ちたい - 手段
従業員サーベイの機能があるシステムを導入しよう！
目的と手段の違いも分からないと、「○○システムを導入するぞ！」だけがゴールになります
その結果残るのはユーザーの使い勝手を無視した「誰にも使われないシステム」だけです
そんな一例として、BI（ビジネス・インテリジェンス）を導入したときのエピソードを紹介します
エピソード：BIツールがぜんぜん見られなかった話
ここでは当社でビジネス・インテリジェンス（BIシステム）を導入した時の失敗エピソードを紹介します
Business Intelligenceとは→こちら
ひとことで言うと「見える化」ツールです
細かな文字ばかりで分かりにくいExcel表を、見えやすいグラフに加工して誰でも「見える化」するための仕組みですね
2018年ごろから、BIシステムが一種の”ブーム”になり、私の会社でもそれにつられるように、BIツールを導入するぞ！という大号令がかかりました
ところがこれが失敗のスタート。
「BIシステム導入」が目的になってしまっていたせいで、現場の課題（＝悩み）をヒアリングすることなくプロジェクトがスタートします
気づけば「きっとこんなグラフが必要なはずだ！」と独りよがりのページを作りこんでいました
衝撃だったのは、完成したシステムを現場向けにオープンして1か月後にPV（ページビュー）を見た時です
まさかの0PV！
現場で全く見られていませんでした。
新しいツールばかりを追いかけて独りよがりになった結果、肝心の「現場のどんな悩みを解決したいか？」が置き去りになっていましたね…
予防策：無理やりでも悩みを見つけるべし！
DXの正しい順番は、
- 悩み（課題）を見つけて
- それを解消できるデジタルツールを探す、です
このケースのように「２．デジタルツールの導入」が先に決まってしまった場合はどうすればいいでしょうか？
答えは「無理やりでも悩みを探し出す」ことです
誰の悩みも見当たらないのならば、DXの意味がありません
（無理やりでも悩みを探す→たとえば？）
- BIの導入で助かる人は誰？
- BIが無いためにできない仕事はどれ？
- BIを導入した他の会社では、どんな悩みが解決できた？
【Point】
どんなDXプロジェクトもゴールは現場の悩みを解決すること
順番を逆にしたら、どんな優良なツールでも”宝の持ち腐れ”ですよ
４．システムを仕事に合わせるのは不可能
DXや情報システムの仕事をしていると、よく次のような”2択”に出会います
- 仕事をシステムに合わせるか？
- システムを仕事に合わせるか？
結論から言うと、システム導入の成功率が高いのは「前者」です
優良で顧客満足度が高いシステムほど、どんな会社にも通用するように作られています
つまり、会社ごとのオリジナルルールに合わせるように設計されていません！
システムを“自社だけのオリジナルルール”に無理やり合わせようとするのは危険！
開発プロジェクトが行き詰ってしまうリスクが「大」です
それで失敗した（いまも失敗し続けている）プロジェクトを一つ紹介します
エピソード：1年経っても離陸しない「呪いのプロジェクト」
私の会社には、待てど暮らせどシステム開発に着手できない「呪われたプロジェクト」があります
SCM（サプライ・チェーン・マネジメント）を一元的に管理するシステムの開発です
なぜ「呪われてる」と言われるほどプロジェクトが進まないのか？
その原因こそまさに「システムを仕事に合わせようとしている」ことです
一般的なSCMでは、主に次の4ステップにて商品を作り販売します
- 材料を仕入れる
- 工場で製造する
- 顧客から受注する
- 商品を出荷する（在庫を減らす）
SCMシステムではこれらを1つのシステム上に乗せて、どの製品がどこにあるか？それはいつ次のステップにうつる予定か？を誰でも分かりやすく管理します
私の勤める会社でも、上の１～４の流れは同じですが、業務を円滑に進めるため、細かなところで他社ではあまり例のない“独自ルール”で運用しているケースがあります
紙とExcelなら担当者の努力次第でどうにでもなった独自ルールも、システムに乗せるためにはある程度”しくみ化”をしなければなりません
それを整理できずに（＝誰が整理すべきなのかも曖昧なまま）開発契約を結んだ結果、何も前に進めないプロジェクトになりました
予防策：独自ルールの100％再現はムリ
複雑な業務フローを、システムで100％再現するのはムリと知ってください
選択肢は次の「2択」
- 複数のシステムを”無理やり”つないで再現
（=コストのわりに使い勝手の悪いシステムになる可能性「大」） - 意味のないプロセスはシステム化を機に廃止
⇒ 当然、システム化のメリットを感じられるのは「２」の方です
これも突き詰めれば、Case1の予防策で紹介したMust（マスト）条件とMay（メイ）条件の話につながりますね
つまりDX成功の秘訣は「May条件をMust条件」と勘違いしないことです
【Point】
あってもなくても大勢に影響がない業務フローは、システムで再現できないことを理由に廃止してしまった方が、その後の運用を考えるとはるかに楽ですよ！
DX推進にIT知識は必要ないです！
ここまで読んだ皆さんは、もしかすると次のように感じるかもしれません
DXの失敗例って言うくらいなんだから、もっと
- プログラミングを誤って書いた話とか、
- AI（人工知能）が暴走した話とか、
- システムレビューで袋叩きにされた話だと思ったのに…
もちろん、プログラミングやソフトウェア設計などの高度なIT知識は持っておいて損はありません
しかし、それらはDX人材になるためのMustな条件ではないことを理解してください
わたし自身、IT知識ゼロの工事現場の監督から転職してDX人材になった身です
DXを上手く進めるために必要なのは、ITの知識よりも「人vs人」の関係を作れる能力だと感じています
- 人の話を最後まで聞ける
- 難しいことを簡単に説明できる
- 全体最適で話ができる
DX人材としてITの知識よりも必要なことは、別記事に詳しく書いています
ぜひそちらも読んでみてくださいね
＼デキるDX人材になれる名著③／
まとめ：DXに失敗しないためのたった1つの心がけ
この記事では、DXを失敗させないために必要なことを「4つ」紹介しました
この記事で紹介した私の過去の「失敗」が、これからDXに取り組むあなたの反面教師になってくれれば大変うれしいです
最後に「DXを成功させるたった一つの心がけ」をお伝えします
DXとは「デジタルの力で現場の悩みを解決すること」だと思ってください
ITやデジタルと言われると苦手意識を持ってしまう人も多いと思いますが、DXの本質はある種の「お悩み解決」です
- 顧客をライバル企業に取られた！どうしよう？
- 若手社員の離職が止まらない！どうしよう？
- いまだに紙とハンコの作業がなくならない！
- 相談事があってもどの部署の誰に聞けばいいのか…
【Point】
現場の抱える”リアルな悩み”を解決することがDX
迷ったり、プロジェクトの方向性がブレていると感じたときは「そもそも現場は何に悩んでいたのか？」を自問自答してください
きっと軌道修正ができて、うまく進みますよ！
DXであなたの会社に明るい未来が見えますように。
＼【厳選】デキるDX人材になれる名著3選！／
