サービスの知識が、人々の頭の中だけにあったとき。

背景

この匿名化された事例は、経験豊富なエンジニアがトラブルシューティング知識の多くを頭の中に抱えていたフィールドサービス業務に関するものである。

表面に現れた課題

情報が組織内を移動する過程で、インシデントの文脈が失われることがあった。部品依頼は、その背景にある業務上の緊急性が伝わらないまま倉庫に届くことがあった。

兆候

原典では、顧客から直接の強いエスカレーションがあった時点で初めて、経営陣が問題の深刻さを把握することがあると記されている。また、数か月後に同じ問題に直面したエンジニアが、解決方法を再び学ばなければならないことも記されている。

問いの捉え直し

原典は、この課題を単なるコミュニケーションの問題ではなく、情報が組織内を移動する中で知識と文脈の双方が失われる問題として捉えている。

診断

フィールドサービスは、トラブルシューティング知識を頭の中に抱える経験豊富なエンジニアに大きく依存しており、繰り返される問題では過去の解決時の文脈が確実に保持されていなかった。

設計

ローコード・プラットフォームは、Error → Troubleshooting → Parts → Resolution を結び付けた。エンジニアが後続のトラブルシューティング対応を記録する際には既存の文脈を復元し、新たな対応とステータス変更を元のインシデントに書き戻した。また、問題を種類、エスカレーションのレベル、段階に応じて動的に振り分けた。

二次的な論点

原典では、解決された各問題が再利用可能なトラブルシューティング履歴となり、管理者は現場間を絶えず移動しなくてもフィールド業務を把握できるようになり、部品依頼には文脈のない要求としてではなく業務上の緊急性が付されるようになったと記されている。

実施

著者はプロジェクトを立ち上げ、部門責任者と要件を整理し、プラットフォームを自ら設計・構築し、テストを経て稼働開始した。

検証

原典は、チームが新卒者の採用を始め、新卒採用者1名が約3か月以内に顧客サイトの設備保守を独力で担当したと報告している。

定着・制度化

原典によれば、著者の退職後もプラットフォームは利用され続けた。