【システム導入にお悩みの企業必見!】システム導入のためのスキルとは?

システムを作ってもらうスキルとは?

昨今、デジタル化とかDXという言葉をよく耳にします。
よく分からないけど、国家が取り組もうと言っているから、とりあえずシステムに詳しい人間を雇えばいいと考えている経営者は少なくないと思います。

しかし、エンジニアというものは、あくまでも施主のオーダーに合わせてモノを作り上げる人種です。一言で「エンジニア」と言っても、世の中には多種多様な技術が存在しており、決して一人ですべてを賄えるわけではありません。

さらに、本人が会社の課題について詳しいわけでもないし、そもそもなぜそのシステムを作る必要があるのかまで把握しているエンジニアは少ないのが現状です。

これが総じて、丸投げされたエンジニアの悲痛と無駄な投資で結果が出せない経営者というWの悲劇を生んでいるのです。

よくあるシステム導入の失敗パターン

以下は私がこれまで経験してきた中で、よくある業務システム開発の失敗パターンを挙げました。

開発のゴールが不明瞭なまま

関係者それぞれに「何のためのシステムなのか?」とインタビューしてみると分かるのが、それぞれにその認識が異なっていることです。

ゴールは明確に

自部門の利便性のみでも分かっていればまだ良い方ですが、最悪の場合、「会社がプロジェクトに参加せよと言ったから」という認識の方も多いのが現実です。

関係者全員が当事者意識に乏しく、それぞれが「きっと誰かがやってくれる」と思っている状態です。

最初は良くても、その進行プロセスの中で間違いなく迷走していくパターンです。

基本的にエンジニアもしくはシステム受託会社に丸投げ

経営者やしかるべき業務の担当者がシステム開発に関わっていないパターンです。

丸投げは良くない
丸投げは良くない

何も、業務担当者にプログラムを書いて欲しいとは言いませんが、現在何のために何をやっているのかぐらいは関心を持つ必要があります。

エンジニアが必ずしもあなたが欲しいデザインを把握しているわけではありませんし、出来上がってから修正をしてもらおうとすると、大きなコストが掛かりかねません。

たとえ料理を作るのは料理人に任していても、塩や砂糖をあきらかに大量に投入していたら、注意しなければなりません。

業務プロセスまで変更するつもりはない

システムの導入とは、イコール業務プロセスの変更でもあります。
業務は現状のままでツールだけが欲しいという願いは、残念ながら叶いません。

業務プロセスの変更は必須
業務プロセスの変更は必須

もしも業務プロセスを変更しない前提でシステム構築をしようとするならば、構築コストが大きく膨らむことになりかねません。

システムを導入する前提には必ず現状プロセスにおける課題があります。そこにムダやダブリがあるのならば、システム導入によって、それを積極的に排除していく必要があるのです。

最悪のケースでは、出来上がってみたら「さらに業務の手間が増えていた」などという本末転倒な結果を生み出すこともあるのです。誰しも、コストを掛けて手間を増やすことなど望むはずがありません。

本当に必要な機能が搭載されていない

システムを作る前提として、必ず現状の課題を洗い出す必要があります。

難しいシステムは使いこなせない
難しいシステムは使いこなせない

部門によってプロセスは異なるので、「とりあえず多機能なツールを選択しておく」という考え方もあります。

しかしこの考え方は、多額な投資をした結果、誰も使わない機能が豊富に搭載されており、本当に必要な機能が搭載されていないなどという馬鹿馬鹿しい結果を生み出すことにも繋がります。

だからといって現場の声にばかり傾聴しすぎても、投資が膨らむうえに何も生み出さないシステムが出来上がってしまう場合があります。そもそも、どういった機能の実装にどれくらいのコストが掛かるのかは、システムをオーダーする側が把握しておかなければならないことです。

単にパンを焼くためのトースターに、コスト感が分からず何百万もかけてしまう主婦はいませんよね?

ベンダーの選定を誤る

そもそも、自社が希望しているシステムを構築するのが不得意なベンダーを選んでしまうことがあります。
技術を理解している担当者が社内にいないと適切なベンダーを選択することは難しく、プロジェクトが思ってもみない方向に進んでしまうことにもなりかねません。

いつになっても運用開始できない

プロジェクトが中々前に進まない、開発や導入が現在どの段階にあるのかを把握できないなど、全体スケジュールやポイントごとのスケジュールを把握しているプロジェクトマネージャーがいないと、いつになってもシステム運用が始まらないといった壁にぶつかることがあります。

操作が難しすぎて使いこなせない

ユーザビリティを丸投げしない
ユーザビリティを丸投げしない

やっとシステムを導入したが、操作が難しすぎて業務が進まないなどといったトラブルをよく耳にします。

いわゆる「ユーザビリティ」はシステムデザインを行ううえで重要なことですが、業務用システムについては、このユーザービリティをベンダーに丸投げしてはいけません。

これらの課題は、そもそもシステムベンダーの責任だけではなく、システムをオーダーした側の問題が大きいと考えています。

そもそも、「本当に必要な機能が搭載されていない」といったトラブルは、作る側の問題ではなく作ってもらう側の問題です。それは、システムを作る人は必ずしもあなたの会社の良き理解者とは限らないからです。

このように、業務を改善する目的でシステムを構築する場合、システムを作る側とシステムを作ってもらう側との間には必ずコンサルタントが必要です。

システムデザインはコンサルティング
システムデザインはコンサルティング

このコンサルタントのことを、私は「システムデザイン」と呼んでいます。
システムデザイナーに必要なスキルとは、テクニカルな知見に留まらず、自ら答えを持たないまでも、顧客のビジネスを改善するために必要な知見とファシリテーションのスキルを持ち、プロジェクト全体を掌握することが求められます。

つまり、「システムデザイン=テクニカル&ビジネスコンサルティング」なのです。

システムは作って終わりではないのです。
顧客の課題に本当に役立つ機能を実装し、それによって顧客のビジネスプロセスを変化させ、目に見える成果を叩き出す必要があるのです。

システムをオーダーする窓口は誰が適切か?

では、これらのシステムをベンダーにオーダーする窓口は誰が適切なのでしょうか?

端的に考えれば、システムと言えば情シスと考えるかもしれません。又はそのシステムを最も使う可能性が高い部門の責任者という考えもあるかもしれません。

私からのアドバイスですが、まず、真っ先にどんな機能が欲しいかを考えてはいけません。
あきらかに目的が決まっているマイカーや家電を購入する場合なら、「自動運転機能が欲しい」「画質がいいテレビが欲しい」といったことからスタートしても支障はないかもしれません。

しかし、システムの場合、まず最初に「システムを導入して何がしたいのか?」という目的を明確にする必要があります。

よく、プロジェクトをスタートさせた時点では目的が曖昧で、スタートしてから様々な問題が露呈してプロジェクトが静止してしまうといったことがあります。

これはベンダーに負担をかけるのみならず、自社プロジェクトの期限や予算にも大きな影響を及ぼします。予算が増えれば、ROI の達成も遠のくことになります。

プロジェクト関係者は誰か?

プロジェクト関係者を、ざっくり「作ってもらう側」と「作る側」の2つに分けます。

プロジェクト関係者の相関図
プロジェクト関係者の相関図

作ってもらう側には「経営者」、「業務部門」、そして「プロジェクトリーダー」が必要です。

作る側には「情報システム部門」、そして「ベンダー」がいます。

よくある失敗パターンは、この図の右側の「作る側」にしか人が存在しないことです。

それによって、結局はシステムの目的や本当に必要な機能があやふやなまま、プロジェクトが進んでしまうのです。

経営へのインパクトは大きい
経営へのインパクトは大きい

たとえば、こういったケースの場合、しばし経営者は「システムのことは分からないから専門家に任せる」となる場合が多いです。

しかし、実際にはシステムへ投資することによる経営へのインパクトは計り知れないものがあるのです。

オーナーがプロジェクトの詳細まで関わる必要はありませんが、作業効率があがることによる数値へのインパクトとそれによる費用対効果を比較し、経営判断を下していくことは非常に重要なプロセスです。

そのために発足し、その権限を一任するのがプロジェクトチームもしくはプロジェクトリーダーです。

そして次に重要なのが、実際にそのシステムを使ってプロセスの効率化を達成しなければならない当事者「業務部門」です。

業務が他人事にしてはいけない
業務が他人事にしてはいけない

お粗末なシステム導入をしてしまった会社でよくある顛末は、「私たちがどんなシステムを作って欲しいか詳細に聞かれたことがない」や「会社が新しいシステムを導入したけれどやりたいことがちっとも達成できない」などということです。

もちろん、業務部門と連携できない情報システム部門もいけませんが、業務部門が「システム部門は一体何を作っているのでしょうね?」などと他人事にしているのもいけません。

そもそも、導入後の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)

    いよいよシステムを稼働させ、顧客へ納品します。一旦、無事稼働したとしても、運用プロセスで不具合が発生することがあるため、プロジェクトメンバーはカスタマーサービスやカスタマーサクセスチームと共に、継続してリカバリーに勤める必要があります。

今回は詳細説明をしませんが、これら全体の流れをウォッチし、経営にフィードバックする役割がプロジェクトチームもしくはプロジェクトリーダーです。

よくあるシステムデザインの失敗例は、このプロジェクトリーダーが明確でないもしくは、それに相応しい人材が不在であるという部分に問題点があると思います。

当社はエンジニアリングも行いますが、主にこのプロジェクトリーダーの部分を請け負わせていただくことが主要事業です。ぜひ、お困りの企業担当者の方や経営者の方からのお問い合わせをお待ちしております。

ホワイトペーパー】営業DXを成功させるたった5つのヒント

Googleニュースアプリで最新情報をゲット!

Quad CompetenceのブログはGoogleニュースからご覧いただけます。
Googleニュースで当サイトのフォローをしていただければ、最新情報のチェックが可能です。

Quad CompetenceのブログはGoogleニュースからご覧いただけます
Quad CompetenceのブログはGoogleニュースからご覧いただけます
左上に表示されるフォローをクリック

Googleニュース又はGoogleニュースアプリ(Android/iOS)の上部検索窓から「Quad Competence」と検索してフォローいただくと、最新ニュースが配信されます(左上に表示)。Googleアカウントをお持ちの方は、ぜひよろしくお願いします!

▼略歴

  • 学生時代には経営・財務の分野を学び、建設・不動産業界で経理部に在席。
  • 家電メーカーにて直営店舗の運営、マーチャンダイザーを経験。PCのBTOビジネス推進やホームネットワークの普及推進、デジタル家電活用のセミナー講師、直営の免税店を経験。
    同時に、グループ企業のWEBマスターとして、ポータルサイト、eコマースサイトの制作・運営、情報セキュリティマネジメント、ナレッジマネジメントを推進。
  • 家電量販店にて情報部門リーダー、都心店舗の店長を経験。
    その後、店舗開発部で新店舗出店時のレイアウト設計やスタッフの育成、出店準備、VMDの企画・制作などを歴任。
  • システムインテグレーターとして、手術室及び血管造影室の画像・映像配信システムの開発・設計、エンジニアリングを担当。さらに、遠隔手術支援システムの企画・開発を担当し、専門誌へ医師の偏在問題に関する論文を寄稿。
    また、医療向けシステムやフェリーの設備を安全にリモートメンテナンスするソリューションを開発・運用。
    その後、会社のリブランディングプロジェクトへの参画、デジタルマーケティング組織の立ち上げ、メディカル組織のマネジメントを経験。
  • 論文 医師偏在の課題と向き合う遠隔手術支援ソリューション(CiNiiで検索
  • 論文 手術室の生産性向上に貢献する医療映像ソリューション(CiNiiで検索
  • 現在、企業向けにIT技術者育成セミナー(ネットワーク/ウェブデザイン等)を主催しております。