はじめに
とある大手EC企業のロッカー故障担当になったときの話です。
情シス経験はあったものの、この巨大EC企業のサーバーの中身は全く見えず、社内ドキュメントは穴だらけ。チームの古参メンバーすら全体構造が分からない状態でした。
完全に “新人スタート” でした。
そんな状況でも、フロント側で観察できる 「15分おきの通知」「4時間で止まる」 といった挙動だけを手がかりに、
- ロッカー本体
- チケットシステム
- ベンダーアプリ
がサーバー側でどう連携しているのかを推測し、
年間数百万円レベルのムダ対応を根絶できました。
この記事では、そのとき使った「ブラックボックス推論」の技術を紹介します。
- 中身が見えなくても構造は読み解ける
- 現象から因果を逆算する
- “新人だからできた実験”
1. 業務の全体像と直面した問題
担当していたのは、宅配ロッカーの故障対応です。
ロッカーが壊れると、以下の流れで進むはずでした。
- ロッカー → 自動でチケット起票
- 内容確認
- ベンダーに現地対応を依頼
- 修理が完了したら、ロッカーが「稼働中」に戻る
しかし、現場ではこんな問題が多発していました。
- 修理完了しても 「稼働中」に戻らない
- 原因不明なので、同じ指示を何度も出し続ける
- 最悪、CPU交換（＝めちゃ高い）
- 稼働率が落ちて、現場もコストもボロボロ
「これはどこかで何かが詰まっているな」と感じ始めます。
2. まず「現象のパターン」を観察する
僕が最初にしたのは操作ではなく 観察 でした。
すると、故障チケットに 15分おき に英語通知が届いていることに気づきます。
- 内容は「Locker repair completed」
- でもロッカーは復帰していない
- 通知は 4時間で突然止まる
明らかに 人間の行動では説明できない規則性。
ここに構造が隠れていると直感しました。
3. 推論：「通知」は“メッセージ”じゃなく“シグナル”では？
情シス時代に触れたシステムの挙動を思い出し、こう考えました。
「これ、通知じゃなくて“状態連携のトリガー”じゃない？」
つまり：
- 15分周期 → 再送（リトライ）
- 4時間で停止 → タイムアウト（TTL）
この2つは IoT や分散システムでは超典型です。
つまり、裏では
ロッカー ↔ サーバー ↔ チケット ↔ ベンダーアプリ
の4者が “非同期” で状態をやりとりしているはず。
この仮説が立つと、あとは検証だけ。
4. 検証：「新人特権」を使った最小リスクの実験
本来なら
「チケット閉じていいですか？」
と聞くべきですが、新人が聞いたら止められます。
そこで素直にこう考えました。
「閉じても新人だし、“あ、間違えました！”でいいか」
実際、古参メンバーも普通に間違えて閉じていたので、リスクは最小。
そして、チケットを閉じてみました。
するとロッカーが自動で「稼働中」に戻った。
仮説の正しさを確信しました。
5. 解明されたサーバー構造（推定） → 鍵は「チケットのClose」
観察した現象をすべて説明できる因果構造はこれでした。
まとめると：
- ✔ ロッカーは「直ったよ！」を何度も送っていた
- ✔ しかしサーバーは チケットが閉じられるまで復帰を許可しない
- ✔ チケット未Close → ステータス復帰しない
- ✔ その結果、CPU交換に走っていた（本来は不要）
問題はロッカーでもベンダーでもなく、 “システム構造の誤解” でした。
実際、グローバル企業では仕様が充分に共有されていないことも多いのが現状です。
6. 改善結果：運用だけで問題の9割が消えた
チケットを閉じるタイミングをルール化するだけで、
- ステータス同期が安定
- CPU交換がほぼゼロに
- 対応時間 2時間 → 30分
- 解決率 70% → 100%
さらに、この知見をもとにマニュアルも再構築しました。
（React & Airtableで一元管理する形に刷新しました）
7. この経験で学んだ「因果推論」の5ステップ
今回の学びをまとめると、この5つに集約されます。
- 現象を観察する
例：15分周期、4時間停止など“不自然な規則性”
- パターンを抽出する
IoTの典型挙動（リトライ・TTL）に当てはめる
- サーバー構造を仮説にする
「通知＝シグナル」「Close＝トリガー」
- 最小リスクで検証する
新人特権でチケットCloseを実行
- 仕組みとして定着させる
マニュアル化して全員が再現できるようにする
コードが書けなくても、内部が見えなくても、因果を読めれば構造は理解できる。
改善は可能です。
8. まとめ：現象を見れば、内部は推論できる
ブラックボックスなシステムでも、
- 通知タイミング
- 状態遷移の詰まり
- 非同期の揺れ
- タイムアウト挙動
といった「外側の現象」だけで
サーバー側の構造はある程度推測できます。
新人時代にこの思考を身につけたことは、今の kintone 開発・業務改善の基盤になっています。
「仕組みがわかれば、怖いものはない」
これは業務改善すべてに通じる真理だと感じています。