フルスクラッチは体力

IoT導入の落とし穴

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

データの墓場化

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

失敗の典型パターン

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

正しい活用ステップ

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

まとめ

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

はじめに

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

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

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

要件定義の丸投げ

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

無理な受注

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

人材紹介会社の利益構造

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

エンジニアの責任範囲

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

発注側の保身

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

危険な繁忙化

なぜか忙しくしているPMやリーダーとなるSEがいれば危険信号である。リーダーが忙しくなると全体的な最適化や効率的な運用ができていない可能性がある。結果として、無駄に費用がかかったり、技術的負債が大きくなったりする。

役割分担の歪み

システムのユーザー側から見ると、SEという見え方しかしないと思われるが、実際はシステムの運用や開発には細かな作業分担が発生する。この作業分担ができていない場合は窓口のSEが余計な作業を行っている可能性がある。役割分担の不均衡がもたらす忙しさではなく、まったく仕事としてやらなくてもよいような事に時間を使っていて忙しい場合がある。

プロセスの確立

たとえば、プログラムが解析できる人をリーダーとしてしまうと、開発者に手取り足取り指示をしてしまうことがある。もし、リーダーがプログラムレビューなどの作業や、開発者にプログラム上の細かな指示をしている場合は注意が必要である。何を基準にプログラムレビューや指示を行うのか、という仕事を見える化し、仕組化することがリーダーの務めである。

俯瞰的視点

木を見て森を見ずという言葉があるように、リーダーとなる人は指針を作ったりメンバーをプロジェクト成功へ導く役割がある。リーダーが開発メンバーと同じように木ばかりを見ているようであれば、森を見る人が非エンジニアであるユーザー側となってしまうことが考えられる。

まとめ

誰が森を見るのか、リーダーやPMが常に忙しそうにしている場合は、何に時間を使っているのか調査する必要がある。実はここがボトルネックになっていてプロジェクトの進行が思うようにいかなかったり、頻繁にリスケが発生していることも多くある。しかし、これは本人にヒアリングするだけでは表面化しないため、ユーザー側の担当者やプログラマーなどの周辺人員から浮き彫りにすることが望ましい。