昨今、デジタル化とかDXという言葉をよく耳にします。
よく分からないけど、国家が取り組もうと言っているから、とりあえずシステムに詳しい人間を雇えばいいと考えている経営者は少なくないと思います。
しかし、エンジニアというものは、あくまでも施主のオーダーに合わせてモノを作り上げる人種です。一言で「エンジニア」と言っても、世の中には多種多様な技術が存在しており、決して一人ですべてを賄えるわけではありません。
さらに、本人が会社の課題について詳しいわけでもないし、そもそもなぜそのシステムを作る必要があるのかまで把握しているエンジニアは少ないのが現状です。
これが総じて、丸投げされたエンジニアの悲痛と無駄な投資で結果が出せない経営者というWの悲劇を生んでいるのです。
この記事のインデックス
よくあるシステム導入の失敗パターン
以下は私がこれまで経験してきた中で、よくある業務システム開発の失敗パターンを挙げました。
開発のゴールが不明瞭なまま
関係者それぞれに「何のためのシステムなのか？」とインタビューしてみると分かるのが、それぞれにその認識が異なっていることです。
自部門の利便性のみでも分かっていればまだ良い方ですが、最悪の場合、「会社がプロジェクトに参加せよと言ったから」という認識の方も多いのが現実です。
関係者全員が当事者意識に乏しく、それぞれが「きっと誰かがやってくれる」と思っている状態です。
最初は良くても、その進行プロセスの中で間違いなく迷走していくパターンです。
基本的にエンジニアもしくはシステム受託会社に丸投げ
経営者やしかるべき業務の担当者がシステム開発に関わっていないパターンです。
何も、業務担当者にプログラムを書いて欲しいとは言いませんが、現在何のために何をやっているのかぐらいは関心を持つ必要があります。
エンジニアが必ずしもあなたが欲しいデザインを把握しているわけではありませんし、出来上がってから修正をしてもらおうとすると、大きなコストが掛かりかねません。
たとえ料理を作るのは料理人に任していても、塩や砂糖をあきらかに大量に投入していたら、注意しなければなりません。
業務プロセスまで変更するつもりはない
システムの導入とは、イコール業務プロセスの変更でもあります。
業務は現状のままでツールだけが欲しいという願いは、残念ながら叶いません。
もしも業務プロセスを変更しない前提でシステム構築をしようとするならば、構築コストが大きく膨らむことになりかねません。
システムを導入する前提には必ず現状プロセスにおける課題があります。そこにムダやダブリがあるのならば、システム導入によって、それを積極的に排除していく必要があるのです。
最悪のケースでは、出来上がってみたら「さらに業務の手間が増えていた」などという本末転倒な結果を生み出すこともあるのです。誰しも、コストを掛けて手間を増やすことなど望むはずがありません。
本当に必要な機能が搭載されていない
システムを作る前提として、必ず現状の課題を洗い出す必要があります。
部門によってプロセスは異なるので、「とりあえず多機能なツールを選択しておく」という考え方もあります。
しかしこの考え方は、多額な投資をした結果、誰も使わない機能が豊富に搭載されており、本当に必要な機能が搭載されていないなどという馬鹿馬鹿しい結果を生み出すことにも繋がります。
だからといって現場の声にばかり傾聴しすぎても、投資が膨らむうえに何も生み出さないシステムが出来上がってしまう場合があります。そもそも、どういった機能の実装にどれくらいのコストが掛かるのかは、システムをオーダーする側が把握しておかなければならないことです。
単にパンを焼くためのトースターに、コスト感が分からず何百万もかけてしまう主婦はいませんよね？
ベンダーの選定を誤る
そもそも、自社が希望しているシステムを構築するのが不得意なベンダーを選んでしまうことがあります。
技術を理解している担当者が社内にいないと適切なベンダーを選択することは難しく、プロジェクトが思ってもみない方向に進んでしまうことにもなりかねません。
いつになっても運用開始できない
プロジェクトが中々前に進まない、開発や導入が現在どの段階にあるのかを把握できないなど、全体スケジュールやポイントごとのスケジュールを把握しているプロジェクトマネージャーがいないと、いつになってもシステム運用が始まらないといった壁にぶつかることがあります。
操作が難しすぎて使いこなせない
やっとシステムを導入したが、操作が難しすぎて業務が進まないなどといったトラブルをよく耳にします。
いわゆる「ユーザビリティ」はシステムデザインを行ううえで重要なことですが、業務用システムについては、このユーザービリティをベンダーに丸投げしてはいけません。
これらの課題は、そもそもシステムベンダーの責任だけではなく、システムをオーダーした側の問題が大きいと考えています。
そもそも、「本当に必要な機能が搭載されていない」といったトラブルは、作る側の問題ではなく作ってもらう側の問題です。それは、システムを作る人は必ずしもあなたの会社の良き理解者とは限らないからです。
このように、業務を改善する目的でシステムを構築する場合、システムを作る側とシステムを作ってもらう側との間には必ずコンサルタントが必要です。
このコンサルタントのことを、私は「システムデザイン」と呼んでいます。
システムデザイナーに必要なスキルとは、テクニカルな知見に留まらず、自ら答えを持たないまでも、顧客のビジネスを改善するために必要な知見とファシリテーションのスキルを持ち、プロジェクト全体を掌握することが求められます。
つまり、「システムデザイン＝テクニカル＆ビジネスコンサルティング」なのです。
システムは作って終わりではないのです。
顧客の課題に本当に役立つ機能を実装し、それによって顧客のビジネスプロセスを変化させ、目に見える成果を叩き出す必要があるのです。
システムをオーダーする窓口は誰が適切か？
では、これらのシステムをベンダーにオーダーする窓口は誰が適切なのでしょうか？
端的に考えれば、システムと言えば情シスと考えるかもしれません。又はそのシステムを最も使う可能性が高い部門の責任者という考えもあるかもしれません。
私からのアドバイスですが、まず、真っ先にどんな機能が欲しいかを考えてはいけません。
あきらかに目的が決まっているマイカーや家電を購入する場合なら、「自動運転機能が欲しい」「画質がいいテレビが欲しい」といったことからスタートしても支障はないかもしれません。
しかし、システムの場合、まず最初に「システムを導入して何がしたいのか？」という目的を明確にする必要があります。
よく、プロジェクトをスタートさせた時点では目的が曖昧で、スタートしてから様々な問題が露呈してプロジェクトが静止してしまうといったことがあります。
これはベンダーに負担をかけるのみならず、自社プロジェクトの期限や予算にも大きな影響を及ぼします。予算が増えれば、ROI の達成も遠のくことになります。
プロジェクト関係者は誰か？
プロジェクト関係者を、ざっくり「作ってもらう側」と「作る側」の２つに分けます。
作ってもらう側には「経営者」、「業務部門」、そして「プロジェクトリーダー」が必要です。
作る側には「情報システム部門」、そして「ベンダー」がいます。
よくある失敗パターンは、この図の右側の「作る側」にしか人が存在しないことです。
それによって、結局はシステムの目的や本当に必要な機能があやふやなまま、プロジェクトが進んでしまうのです。
たとえば、こういったケースの場合、しばし経営者は「システムのことは分からないから専門家に任せる」となる場合が多いです。
しかし、実際にはシステムへ投資することによる経営へのインパクトは計り知れないものがあるのです。
オーナーがプロジェクトの詳細まで関わる必要はありませんが、作業効率があがることによる数値へのインパクトとそれによる費用対効果を比較し、経営判断を下していくことは非常に重要なプロセスです。
そのために発足し、その権限を一任するのがプロジェクトチームもしくはプロジェクトリーダーです。
そして次に重要なのが、実際にそのシステムを使ってプロセスの効率化を達成しなければならない当事者「業務部門」です。
お粗末なシステム導入をしてしまった会社でよくある顛末は、「私たちがどんなシステムを作って欲しいか詳細に聞かれたことがない」や「会社が新しいシステムを導入したけれどやりたいことがちっとも達成できない」などということです。
もちろん、業務部門と連携できない情報システム部門もいけませんが、業務部門が「システム部門は一体何を作っているのでしょうね？」などと他人事にしているのもいけません。
そもそも、導入後のROIを見るのはシステム部門ではなく、業務部門と考えた方が適切です。ですから、導入予算も情報システム部門ではなく、業務部門が主導権を握った方が適切だと考えます。
そして、これらのシステムを作ってもらう側とシステムを作る側の仲介役となるのがプロジェクトチームもしくはプロジェクトリーダーなのです。
このプロジェクトチームを社内に持つことがベストですが、ここに大きな負荷をかけることが難しければ、我々のようなシステムデザインを請け負うコンサルティングに任せる方法もあります。
システム導入の流れ
システム導入を進めていくうえで、これまで話してきた内容と開発に必要なプロセスをまとめると大きく分けて10段階あります。
STEP1
ゴールの明確化（Concept Framing）2〜3週間という短いスパンで、メンバー全員が向かう方向を定義します。
STEP2
現状分析（Assessment）現行のシステムがどうなっているのか、資料を集めたり過去の担当者にヒアリングするなどして棚卸して分析していきます。
STEP3
仕組み化策定（Business Model）前段で明らかになった課題を解決するため、ビジョンの明確化、施策の絞り込み、プロジェクトの基本計画を立案します。
STEP4
開発要求定義（Scope）どんなシステムが良いかを具体的に検討します。欲しい物を具現化する段階で抜けや漏れが発生しないよう専用のフォーマットを使うのが一般的です。
STEP5
ベンダー選定（PEW）前段で決定したシステムを実現してくれるパッケージとソリューションを提供してくれるベンダーを選定します。
STEP6
プロトタイプ検証（BPP）まずは簡単なフローチャートやプロトタイプを作り、シミュレーションを実施します。
STEP7
システム設計（System Designシステム設計を書き、プログラムやアプリケーションとのインテグレーションを実施していきます。ここでメンテナンス性やトータルコストを踏まえた設計思考が重要となります。
STEP8
開発・テスト（Deployment）システムを開発し、バグフィックスのためのテストを実施します。
STEP9
稼働・導入（Rollout）いよいよシステムを稼働させ、顧客へ納品します。一旦、無事稼働したとしても、運用プロセスで不具合が発生することがあるため、プロジェクトメンバーはカスタマーサービスやカスタマーサクセスチームと共に、継続してリカバリーに勤める必要があります。
今回は詳細説明をしませんが、これら全体の流れをウォッチし、経営にフィードバックする役割がプロジェクトチームもしくはプロジェクトリーダーです。
よくあるシステムデザインの失敗例は、このプロジェクトリーダーが明確でないもしくは、それに相応しい人材が不在であるという部分に問題点があると思います。
当社はエンジニアリングも行いますが、主にこのプロジェクトリーダーの部分を請け負わせていただくことが主要事業です。ぜひ、お困りの企業担当者の方や経営者の方からのお問い合わせをお待ちしております。
Googleニュースアプリで最新情報をゲット！
Quad Competenceの「Business TIPs」はGoogleニュースからご覧いただけます。
Googleニュースで当サイトのフォローをしていただければ、最新情報のチェックが可能です。
Googleニュース又はGoogleニュースアプリ（Android/iOS）の上部検索窓から「Quad Competence」と検索してフォローいただくと、最新ニュースが配信されます（左上に表示）。Googleアカウントをお持ちの方は、ぜひよろしくお願いします！
