ROI事件ファイル No.282｜『LogisRent社のIoT迷路』

第一章：システムの悲鳴——障害の連鎖、止まらぬ現場

PromoXのSWOT分析事件が解決した翌週、今度は中部地方から物流資材レンタル企業のシステム危機に関する相談が届いた。第二十三巻「再現性の追求・続編」の第282話は、混乱する開発現場から最大の制約を見つけ出し、全体最適を実現する物語である。

「探偵、我々のIoTシステムが崩壊寸前です。障害対応に追われ、改修も進まず、新機能開発など夢のまた夢。エンジニアは疲弊し、顧客からのクレームは増加する一方です。何から手をつければいいのか、もはや分かりません」

LogisRent社 の技術統括、名古屋出身の田中健一は絶望的な表情でベイカー街221Bを訪れた。彼の手には、300件を超える障害チケットリストと、それとは対照的に進捗ゼロの改修計画書が握られていた。

「我々は愛知県でパレットやコンテナなどの物流資材をレンタルしています。5年前、IoTで在庫管理を革新するシステム『フクLOW』を自社開発しました。しかし今、そのシステムが会社を潰そうとしています」

LogisRent社 の崩壊寸前のシステム： - 設立：2008年（物流資材レンタル） - 年間売上：68億円 - 顧客数：420社（製造業、物流業） - IoTシステム「フクLOW」：2020年稼働開始 - 管理対象：パレット18万枚、コンテナ5万個 - 開発チーム：8名（全員が障害対応に追われる） - 未解決障害：302件 - 改修要望（未着手）：87件 - 平均障害対応時間：1件あたり4.5日

田中の表情には深い疲弊があった。

「問題は、全てが同時に炎上していることです。位置情報が取得できない、データが同期されない、アラートが誤作動する、管理画面が遅い。毎日新しい障害が発生し、エンジニアは対応に追われます。改修計画は立てても、着手する時間がありません」

崩壊する開発現場： - 月曜朝：改修会議で優先順位を決定 - 月曜午後：緊急障害が3件発生、改修作業中断 - 火曜：前日の障害対応継続、新たに5件発生 - 水曜：顧客から「システムが使えない」とクレーム、全員が障害対応 - 木曜：改修作業を再開しようとするが、また障害発生 - 金曜：今週も改修進捗ゼロ、疲弊したエンジニア

エンジニアの稼働内訳（週40時間）： - 障害対応：32時間（80%） - 改修作業：3時間（7.5%） - 新機能開発：0時間 - 会議・報告：5時間（12.5%）

「我々は走りながら火を消していますが、火は増え続けています。このままでは、システムも、チームも、会社も燃え尽きます」

第二章：制約の理論——最も細いパイプを見つける

「田中さん、現在の障害対応は、どのような基準で優先順位を決めているのでしょうか？」

私の問いに、田中は疲れ切った声で答えた。

「基本的には『声の大きい順』です。顧客からクレームが来た障害、上司から指摘された障害、それを優先します。あとは『早く片付きそうなもの』から手をつけます。全部重要に見えるので、判断基準がないのです」

現在の優先順位付け（場当たり的）： - 基準1：顧客の声の大きさ - 基準2：対応の容易さ - 基準3：上司の指示 - 結果：根本的な問題は放置され、表面的な対応の繰り返し

私はシステム全体の流れを見る重要性を説いた。

「全ての障害が同じ重要度ではありません。TOC——制約理論。システム全体のスループットを決めるのは、最も細いパイプ、つまりボトルネックです。そこに集中することで、全体が改善するのです」

⬜️ ChatGPT｜構想の触媒

「鎖の強さは最も弱い輪で決まる。その輪を見つけ、そこに全力を注げ」

🟧 Claude｜物語の錬金術師

「川の流れは、最も狭い場所で決まる。その場所を広げれば、川全体が速くなる」

🟦 Gemini｜理性の羅針盤

「TOCは全体最適の科学。ボトルネックを特定し、集中し、配下を従属させる」

3人のメンバーが分析を開始した。Geminiがホワイトボードに「IoTシステム特化型TOC分析」のフレームワークを展開した。

制約理論（TOC）の5つのステップ： 1. 制約を見つける - システムのボトルネックを特定 2. 制約を徹底活用 - ボトルネックを最大限に活用 3. 他を制約に従属 - 他のリソースを制約に合わせる 4. 制約を強化 - ボトルネックの能力を向上 5. 惰性に注意 - 新たな制約を探す

「田中さん、フクLOWの真のボトルネックを見つけましょう」

第三章：隘路の発見——302件の障害が語る真実

Phase 1：障害の分類と可視化（1週間）

302件の未解決障害を、システムの構成要素別に分類した。

障害の分布： - IoTデバイス（センサー・通信）：87件（29%） - データ収集サーバー：142件（47%） - データベース：18件（6%） - 管理画面（Web）：32件（11%） - 外部連携（API）：23件（7%）

最大の障害発生源：データ収集サーバー（142件）

さらに詳しく分析すると、驚くべき事実が判明した。

データ収集サーバーの障害内訳： - 通信タイムアウト：68件（48%） - データ欠損：42件（30%） - サーバー高負荷：22件（15%） - その他：10件（7%）

Phase 2：ボトルネックの特定

データ収集サーバーの「通信タイムアウト」が最大の制約だった。

通信タイムアウトの影響連鎖： 1. IoTデバイスからのデータが届かない 2. 在庫データが更新されない 3. 顧客が正確な在庫を確認できない 4. 現場が手動で在庫を確認（二度手間） 5. 顧客満足度低下、クレーム増加

根本原因の分析： - データ収集サーバーが単一構成（1台のみ） - 18万枚のパレット + 5万個のコンテナ = 23万デバイスから同時通信 - サーバーの処理能力限界：1秒あたり200リクエスト - 実際の負荷：ピーク時1秒あたり850リクエスト - 結果：処理しきれず、タイムアウト多発

田中は青ざめた。

「我々は302件全てに対応しようとしていました。しかし、68件の通信タイムアウトを解決すれば、他の多くの障害も連鎖的に解消されるのですね」

Phase 3：制約の影響範囲の可視化

通信タイムアウトが他の障害にどう影響しているかを追跡した。

連鎖する障害（68件が引き起こしている）： - データ欠損42件の内、38件はタイムアウトが原因 - 管理画面の遅延32件の内、28件はデータ取得失敗が原因 - IoTデバイス障害87件の内、52件は通信エラーのリトライが原因

試算： 通信タイムアウト68件を解決すれば： - 直接的な解消：68件 - 連鎖的な解消：118件（38+28+52） - 合計：186件（302件の62%）

「システム全体の6割の障害が、たった1つのボトルネックから発生していたのです」

第四章：制約への集中投資——全てをボトルネックに従属させる

Phase 4：制約の徹底活用（Step 2）- 2週間

まず、既存のデータ収集サーバーを最大限に活用する工夫をした。

施策1：通信の時間分散 - 従来：全デバイスが1時間ごとに一斉送信 - 改善：デバイスIDの末尾で送信タイミングを分散 - 効果：ピーク負荷 850req/s → 320req/s

施策2：優先度制御 - 重要顧客のデバイスを優先処理 - 異常値検知は即時、正常値は遅延許容 - 効果：重要データの欠損ゼロ化

2週間後の成果： - 通信タイムアウト：68件 → 22件（68%削減） - 連鎖障害の解消：118件 → 38件 - 残存障害：302件 → 146件（52%削減）

Phase 5：他を制約に従属（Step 3）- 1ヶ月

次に、他のリソースを制約に合わせて再配置した。

施策：エンジニアの役割分担変更

従来（全員が全てを担当）： - 8名全員が障害対応、改修、開発を並行 - 結果：頻繁なタスク切り替えで非効率

新体制（制約に集中）： - 制約チーム（5名）：データ収集サーバーの改善に専念 - 通信タイムアウト対策 - サーバー増強計画 - 負荷分散設計 - 支援チーム（3名）：他の障害対応 - 軽微な障害のみ対応 - 制約に影響しない改修

ルール： 「制約チームは、他の障害対応で中断されない」

Phase 6：制約の強化（Step 4）- 2ヶ月

ボトルネックそのものを強化する根本対策を実施した。

施策：データ収集サーバーの冗長化 - 従来：1台構成 - 改善：3台構成（ロードバランサーで負荷分散） - 処理能力：200req/s → 900req/s（4.5倍） - コスト：月額180万円 → 380万円（200万円増）

投資判断： - 障害対応コスト削減：エンジニア5名×月400時間 = 2,000時間/月 - 時間単価5,000円として、月間1,000万円のコスト削減 - サーバー増強の投資回収：1ヶ月未満

2ヶ月後の成果：

障害の劇的削減： - 通信タイムアウト：22件 → 0件 - 連鎖障害の完全解消 - 残存障害：146件 → 18件（94%削減）

エンジニアの稼働変化： - 障害対応：週32時間 → 週4時間（87.5%削減） - 改修作業：週3時間 → 週28時間（9倍） - 新機能開発：週0時間 → 週8時間

ビジネス指標： - システム稼働率：82% → 99.2% - 顧客満足度：3.2 → 4.6 - クレーム件数：月48件 → 月3件 - データ精度：78% → 99.5%

Phase 7：惰性に注意（Step 5）- 継続

新たなボトルネックが発生していないか、継続的に監視した。

新たな制約の候補： - 管理画面のレスポンス（次に遅い部分） - データベースの容量増加 → 優先順位を付けて計画的に対処

6ヶ月後の総合成果：

システム安定性： - 障害発生件数：月120件 → 月2件（98%削減） - 平均復旧時間：4.5日 → 0.3日 - 予防保守体制の確立

開発生産性： - 改修完了案件：0件 → 62件 - 新機能リリース：0件 → 8件 - 開発サイクル：不定 → 2週間スプリント

顧客価値： - 在庫可視化精度：78% → 99.5% - 顧客の業務効率：「手動確認が不要に」 - 新規契約：月2社 → 月9社

顧客の声：

大手物流企業・物流部長： 「以前は『フクLOWが使えない』と現場から毎日クレームがありました。今では『これなしでは仕事にならない』と言われます。在庫の可視化で、空パレット探しの時間が1日2時間削減されました」

第五章：探偵のTOC診断——全体最適の羅針盤

ホームズが総合分析をまとめた。

「田中さん、TOCの本質は『全体最適』です。302件の障害に等しく対応することは、実は何も解決しないことと同じです。システムのスループットを決めるボトルネック、その制約に集中する。その勇気が、全体を救うのです」

12ヶ月後の最終報告：

LogisRent社は中部地方の物流資材レンタル市場のリーディングカンパニーへと復活した。

最終的な成果： - 年間売上：68億円 → 98億円（+44%） - 顧客数：420社 → 640社 - システム稼働率：99.2% → 99.8% - エンジニアの離職率：年40% → 年5%

田中からの手紙には深い感謝が記されていた：

「TOCによって、我々は『全てと戦う組織』から『重要なことに集中する組織』へと変わりました。最も重要だったのは、『全ての障害を同時に解決しようとしない』勇気でした。ボトルネックを見つけ、そこに集中し、他を従属させる。今では新しい問題が発生した時、必ず『これは制約か？』と問います。制約理論は、混乱を秩序に変える魔法なのだと理解しました」

探偵の視点——制約は敵ではなく、道標である

その夜、制約と全体最適の関係について考察した。

TOCの真価は、諦めにある。全てを同時に解決しようとすることを諦める。そして、最も重要な一点に集中する。この逆説的な選択が、全体を前進させる。

302件の障害は敵ではなかった。その中の68件こそが真の敵であり、それを倒せば186件が連鎖的に消える。制約は敵ではなく、道標なのだ。

「混乱の中で迷う者は、全てを見ようとする。明確に進む者は、一つを見る。そしてその一つが、全てを変える」

次なる事件もまた、制約理論が企業の未来を切り開く瞬間を描くことになるだろう。

「システムの流れは、最も細いパイプで決まる。そのパイプを広げれば、川全体が速くなる」――探偵の手記より

関連ファイル