DXをやるに当たって注意すべきこと！手段の目的化は典型的な炎上パターンだ
DXという言葉が使われるようになって数年経ちました。DXの波でIT投資が盛んになったように感じます。
一方ですべてのシステム開発プロジェクトが上手くいっているとは考えられません。元々日本ではシステム開発プロジェクトの1/3程度はQCDを守れないと言われているくらいで、プロジェクトに失敗して残業地獄になることを炎上、残業地獄のプロジェクトをデスマーチと呼ぶくらいです。
そしてDXという名のもとにIT投資が盛んになることで、よそもやっているからとか流行だからという理由で取り組む企業が出てきている可能性もあります。
そんなわけで今回は失敗プロジェクトをやらないために気を付けるべきことを書きます。下記のような方に参考にしていただければと思います。
- DXをいきなりやらされるようになってしまった方
- システム導入の経験が少ないのに、システム企画のメンバーにされてしまった方
- 自社のDXプロジェクトに疑問を抱いている方
Contents
手段の目的化はシステム開発ではよくある炎上パターン
システム開発におけるありがちな例
DXという言葉が流行化しているため、東洋経済でも特集が組まれています。特にこの記事はIT業界の方ならよくあるパターンと感じたのではないでしょうか？
上記の記事では、DXが流行であり、よそもやっているため、うちもやるぞ！と社長が号令をかけています。そしてプロジェクトマネージャーには部長が選ばれ、しかしIT畑ではないため何をやっていいか解らずにプロジェクトを進めていきます。
そして想定外があれこれ起きますし、ITベンダーとの会話も全然成り立っていません。ITベンダー側も相手が解るように気を付かないのかという疑問はありますが、普通のITベンダーや普通のITエンジニアは言われたことしかやってくれない可能性もあります。IT企業に限らなそうですが、顧客志向というだけで上から高く評価されることもあります。
実際に私が長年ITベンダー側で仕事をしてきた経験から言うと、発注側がしっかりしろよというのはITベンダー側の人からよく聞く不満です。
上記の東洋経済の記事はシステム開発プロジェクトでありがちなパターンをマンガ化したものです。創作だら極端なんだろ？と思うかもしれませんが、わりと起こりうることだと私には感じられます。
手段の目的化は決まって炎上する
システム開発プロジェクトでは、手段の目的化は決まって炎上します。収拾がつかなくなって残業地獄となり、リスケを繰り返し、コストも当初の予算を大幅にオーバーします。これはもうパターンと言っていいです。
何がしたいんだっけ？どこに向かいたいんだっけ？こういうところをしっかりしましょう。
目的がないままにDXをやりたい、この製品を使いたい、この技術を使いたいでは、あれもこれもやればいいとか、今の業務合わせてくれないと困るからカスタマイズしまくるなどということになります。こうして無理な作り込みが沢山発生し、コストと納期はみるみると膨らんでいきます。
もう一度言いますが、手段の目的化は典型的な炎上パターンです。DXやシステム導入の目的を明確に決めましょう。
私が見てきたありがちな失敗例
私はシステム開発の仕事に携わっています。そんな中で手段が目的化して炎上したプロジェクトをいくつも見てきました。
一応断っておくと、自分のプロジェクトではやったことがないですよ。他人のプロジェクトに参加したときや、他人や他社のプロジェクトを傍から見たら炎上していたという例をいくつも見たということです。
この記事でサービス残業を200時間したという話を書いていますが、そのプロジェクトは製品を使うことが目的化していました。そして無理なカスタマイズをひたすらし続け、カスタマイズ費が製品本体費用の10倍くらいになっていました。
IT業界では製品を新しいものに変更するときに、ユーザーの学習コストを増やしたくないという理由で、現行製品と同じ仕様になるようにカスタマイズするという謎の習慣があります。既製品を使う案件で見かける炎上パターンです。
製品が違えば当然仕様が異なりますので、業務のやり方が変わります。しかし業務のやり方を変えると現場の従業員から反発にあうことや、現場の従業員にとって新たな業務の学習コストが発生することが悩みどころになります。
このパターンでは製品のカスタマイズを沢山行って、新しく採用する製品の仕様をできるだけ現行製品に近づけてしまいます。そしてコストと納期が激増してしまいます。
これも手段が目的化したアンチパターンですので、よく覚えておいてください。
そもそもの目的を考えよう
3大ダメパターン
DXという言葉をよく聞くようになった私が感じている3大ダメパターンがあります。下記のようなものです。
- 偉い人がやれと言ったから
- 流行だから
- よその会社もやっているから
DXやシステム開発に限らないですね。プライベートでも有名人が良いと言ったからとか、最近流行っているから、使っている人が多いからという理由で商品を選ぶことはあると思います。便利グッズやファッションではありがちな話でしょう。しかしプライベートではそこまで大事にはなりません。
DXと名乗るプロジェクトやAI導入（これもDXの一環でしょうね）などにおいても、この三大ダメパターンの話をチラホラと聞きます。先ほど挙げた東洋経済のDXプロジェクトが頓挫したマンガも、最近はDXが流行っていてよその会社もやっているからという理由で、社長がやれと号令をかけています。
つまり私が感じている三大ダメパターンを網羅しています。なんてことでしょう！
DXも目的が大事
先ほど手段の目的化は典型的な炎上パターンだと書きました。三大ダメパターンも手段の目的化です。よって典型的な炎上パターンとなります。
そもそも何がしたいかもなく、偉い人が言ったからとか流行だから、よその会社もやっているからという理由で始めて、何をどう変えるのでしょう？世間がIT投資に躍起になっているから、うちも遅れないようにIT投資を積極的に進めようと言う気持ちは解ります。
しかしIT投資をやることを目的化しては、IT投資によって得たいことがありません。そしてあれもこれも非効率だから改善するなど何でもありビュッフェのようなシステムが出来上がる可能性もあります。
目的がなく場当たり的にあれもこれもとやっていては、コストも納期もドンドン膨らんでいきます。
こちらの本は私が昔会計の勉強をしていた頃に読んだのですが、あれもこれも機能を詰め込んだシステムで失敗する例を書いていました。うんうんその通りと思いながら読みました。
美容院と1，000円カットでは、どちらが儲かるか？ できるビジネスパーソンになるための管理会計入門！ [ 林総 ]
DXだろうとシステム開発だろうと、目的をしっかり決めて取り組みましょう。
自社に合った手段か考えよう
自社に合わないことは上手くいかない
どの会社も強みや文化、プロセスが違います。いずれも長い期間をかけて積み上げてきたものです。
よってよく使われているから、人気があるから、他社も使っているからという理由で製品や技術を決めても、上手くいきません。
製品や技術はあくまでも手段です。それらを使うこと自体が目的になってはいけません。やるべきことは現在抱えている問題を解決することです。そのために最適な手段として製品や技術を選ぶのです。
自社が抱えている問題は何か？そして自社の強みや文化、プロセスなど制約は何か？これらを考えた上で製品や技術を選択しましょう。
フィット&ギャップ分析を行う
IT業界では通常は既製品を導入する際にフィット&ギャップ分析を行います。「通常は」とあえて書いたのは、これができてなくて炎上するプロジェクトが多いからです。
製品を導入する際に、自社の業務プロセスに合っているかどうか、自社が望む機能を備えているかどうかが重要な観点になります。そして合わない部分や足りない部分をカスタマイズで補うことになります。
ところがフィット&ギャップ分析を行わずに製品を決めてしまうと、自社の業務プロセスに合っていない、欲しい機能がないなどの問題が出てきて、あれもこれもカスタマイズするということになります。こうなるとコストと納期はみるみると膨らんでいきます。
だから製品を使うことが目的化してはいけないのです。自社の業務プロセスに合わない、やりかいことができないという問題が続発して、こんなはずじゃなかったとなるプロジェクトは沢山あります。
上記のリンク先記事のように、表で整理すると足りない機能が解りやすいですし、複数の候補製品の検討もしやすいです。
| 機能 | 製品A | 製品B | 製品C |
|---|---|---|---|
| 権限設定 | 〇 | 〇 | 〇 |
| API連携 | 〇 | △ | × |
| レポート機能 | △ | 〇 | △ |
| 顧客対応履歴 | × | △ | 〇 |
また製品の検討時には不明点が出てきますので、製品ベンダーの担当者に問い合わせて、資料をもらったりデモを見せてもらったりするといいです。
終わりに
私がIT業界で長年目にし続けているのが、今回解説した手段の目的化とフィット&ギャップ分析ができていないことです。そしてそういうプロジェクトはお約束のように炎上して残業地獄となっており、納期が何倍にも膨れ上がっています。
DXが叫ばれ、IT人材が不足していると言われ、IT投資は流行として増えていきそうです。すると益々こういうプロジェクトが増えていく恐れがあります。だから今回の記事を書きました。
私自身もできるだけ不幸なプロジェクトを減らせるように尽力していきたいと考えています。
またDXで前例のない取り組みをするケースもあるかもしれません。そんなときのための方法もマネジメントでは提供されています。
今回書いた問題はマネジメントさえ学べば対処可能と私は考えています。ありがちだからと言って、なくすことが絶対に不可能だとは思っていません。
