相場の不在

IoT導入の落とし穴

製造業や物流業を中心に、IoTセンサーやデバイスの導入が加速している。設備の稼働状況、温度・湿度、位置情報など、あらゆるデータがリアルタイムで収集できる時代になった。しかし、IoTを導入したものの「期待した業務改善効果が得られない」という声が多く聞かれる。データは確かに取得できているのに、なぜ業務改善に結びつかないのか。この問題は多くの企業が直面している共通の課題である。

データの墓場化

IoTデバイスから送られてくるデータは、サーバーやクラウドに蓄積されていく。しかし、その膨大なデータを見ても「何をすればいいのか分からない」という状況に陥る企業が少なくない。ダッシュボードには数値やグラフが表示されているものの、それを見て具体的なアクションを起こせる人材がいない。結果として、高額な投資をしたIoTシステムが「データ収集マシン」で終わってしまい、経営層からは「費用対効果が見えない」と指摘される悪循環に陥る。

失敗の典型パターン

活用が進まない企業には明確な共通点がある。第一に「導入目的が曖昧」なケースだ。「とりあえずIoTを入れてみよう」という姿勢では、取得すべきデータの種類も不明確になる。第二に「データ分析のスキル不足」である。統計知識やデータ分析ツールの使い方を理解している人材がいなければ、データから意味のある洞察は得られない。第三に「業務プロセスとの連携不足」だ。データ分析の結果を実際の業務改善アクションに落とし込む仕組みがなければ、分析は絵に描いた餅で終わる。これらの問題は技術以前の、組織体制や戦略の問題なのである。

正しい活用ステップ

IoTを真に業務改善につなげるには、段階的なアプローチが必要だ。まず「解決したい課題」を明確にし、その課題解決に必要なデータだけを取得する設計から始める。次に、データを見える化するだけでなく、「どの数値がどうなったら、誰が何をするか」というアクションルールを事前に設定する。さらに、現場担当者がデータを日常的に確認し、判断できるよう、シンプルなダッシュボードと教育体制を整えることが重要だ。IoT活用は技術導入ではなく、業務プロセス改革として捉え、全社的な取り組みとして推進することで初めて成果が生まれる。

まとめ

IoTで業務改善が進まない企業の共通点は、データ収集が目的化し、活用のための戦略・スキル・体制が不足している点である。導入前の課題設定、データ分析人材の育成、業務プロセスへの組み込みという3つの要素を整えることで、IoTは真の業務改善ツールになる。技術導入だけでなく、組織全体での活用文化の醸成が成功の鍵である。

DX化の現状

多くの企業でExcel業務のDX化が話題になっている。「Excelは古い」「すぐにシステム化すべき」という声も聞かれるが、本当にすべてのExcel業務をDX化すべきなのだろうか。実は、やみくもなDX化は逆効果になることも少なくない。Excel業務のDX化には正しい順序と判断基準が必要である。本記事では、DX化の利点を理解しながら、適切なアプローチについて考えていく。

DX化の利点

Excel業務をDX化することで得られる利点は確かに多数ある。まず、データの一元管理により情報の正確性が向上し、複数人での同時編集や更新作業がスムーズになる。次に、自動化による作業時間の大幅な削減が可能である。手作業で行っていた集計や転記作業から解放されることで、より付加価値の高い業務に時間を使えるようになる。さらに、データ分析の高度化により、経営判断のスピードと精度が向上する。これらの利点は、企業の競争力強化に直結する重要な要素である。

DX化の落とし穴

しかし、DX化を急ぐあまり失敗するケースも多く見られる。業務フローが整理されていない状態でシステムを導入すると、非効率な業務がそのままシステム化されてしまう。また、現場の声を聞かずにツールを選定すると、使いにくいシステムが現場に定着せず、結局Excelに戻ってしまうこともある。さらに、すべてを一度に変えようとすると、従業員の負担が大きくなり、業務が混乱する。投資したコストに見合う効果が得られず、DX化自体が目的化してしまう危険性もある。適切な準備なしのDX化は、かえって生産性を下げる結果を招くのである。

正しい進め方

Excel業務のDX化を成功させるには、段階的なアプローチが不可欠である。まず、現状の業務フローを可視化し、本当に必要な作業とムダな作業を明確に区別する。次に、Excelで十分な業務と、システム化すべき業務を見極めることが重要である。すべてをシステム化する必要はない。その上で、優先順位をつけて小さく始め、効果を確認しながら展開していく。従業員のITリテラシーに応じた教育も並行して行うことで、スムーズな移行が実現する。DX化は手段であり目的ではない。自社の状況に合わせた最適な方法を選ぶことが、真の業務改善につながるのである。

まとめ

Excel業務のDX化は、正しく進めれば大きな効果をもたらすが、順序を誤ると逆効果になる。利点を理解しつつ、自社の状況を冷静に分析し、段階的に進めることが成功の鍵である。やみくもなシステム化ではなく、業務改善を第一に考えた戦略的なアプローチを取るべきである。

はじめに

会社の雰囲気や要件定義の内容をみれば、おおよそそのプロジェクトが成功するか否かがわかる。うまくいかない場合のユーザー側とシステム会社側の原因の一例である。

・要件定義をシステム会社に任せてしまう
・元請けシステム会社が無理な要件でも受注する
・準委任契約の人材紹介会社がリスクなく利鞘を稼げる
・末端エンジニアの作業遂行以外の責任
・ユーザー側、発注側の担当者が保身する

今回はその背景を説明したい。

要件定義の丸投げ

要件定義をシステム会社に任せてしまう。
要件定義はシステム会社がユーザー企業をヒアリングして作るものではなく、ユーザーとシステム会社が議論を重ねることで答えを出していくものにしなくてはならない。ユーザーが目指すべき姿と、システム会社が実現すべき姿のすり合わせが重要である。

無理な受注

元請けシステム会社が無理な要件でも受注する。
無理な要件でも受注できるのは、発注側にもシステムの知識がないため、ゴールが曖昧なまま元請けシステム会社が請け負ってしまうからである。もし、発注側にITリテラシーがなければ、パワハラなども発生する可能性が高い。したがって、元請けシステム会社に精神的な課題を回避するため、要件定義を作る人でさえも二次受けシステム会社から集めてくることがある。

人材紹介会社の利益構造

準委任契約の人材紹介会社がリスクなく利鞘を稼げる。
システムの完成責任は負わず、作業だけ請け負うことになるため、人さえ集めてくれば、そこでリスクなく利鞘が稼げる。発注側のユーザー企業からすれば、契約は元請けシステム会社であるため、3次請け、4次請けを使おうが、完成さえすればいいと考えていることが多い。

エンジニアの責任範囲

末端エンジニアの作業遂行以外の責任。
末端のエンジニアには、クライアントとの調整や導入、一定品質や納期の遵守など、責任感や危機感がないこともある。プロジェクトの全貌が見えないことも原因である。また、言われたことをやるだけで報酬がそこそこあるのが、システムエンジニアの業界だったりするので、作業をした時間分だけ報酬を支払ってほしい、という話にもなる。

発注側の保身

ユーザー側、発注側の担当者が保身する。
システム開発がうまくいかなかったときに、発注側の担当者がシステム会社に責任を押し付けるといったことがある。これは信頼関係によるもので、共同でプロジェクトを成功させようという目標が作れなかった場合に発生する。システム会社を業者扱いして要件定義を丸投げしてしまわないようにしなければならない。