ROI事件ファイル No.457『二割の鍵』
二割の鍵
第一章：修理のたびに止まる時計
「修理の問い合わせが来るたびに、古参の社員を探すことになります」
Innovatech社の製造部長、遠藤康雄氏は、そう言いながら製品の一覧表をテーブルに広げた。顧客ごとに異なる仕様でカスタマイズされた制御装置が、数十行にわたって並んでいる。製品番号、顧客名、納品年——しかし、仕様の詳細欄には空白や「田中さんに確認」という記述が目立つ。
「当社はカスタマイズ開発がメインです。標準品がなく、顧客ごとに設計が異なる。修理依頼が来た時、その製品の仕様を把握しているのが特定の古参社員だけ、ということが多い。その人が不在だと、修理の初動だけで一日以上ロスします」
「古参の社員は何名ですか」と私は尋ねた。
「実質三名です」と遠藤氏が答えた。「その三名が辞めたら、修理対応が成り立たなくなる。その危機感が、今回の相談の背景にあります」
「情報はどこで管理されていますか」とGeminiが確認した。
「Excelです。ただ、各部署がバラバラに持っていて、全体を統合したものがない。図面はNASに保管していますが、更新履歴が正確に反映されておらず、どれが最新か分からないものもある」
Claudeが一言、言った。「情報が死んでいる」
「そういうことです」と遠藤氏が苦笑した。「どうすれば、この状況を変えられるか」
第二章：八割の問題は二割の原因から来る
「この案件には、パレートの法則が必要です」
Claudeがホワイトボードに大きく「80/20」と書いた。
「パレートの法則とは、全体の八割の結果は、二割の原因から生まれるという経験則です」と私が説明した。「属人化の解消を『全製品の全情報をデジタル化する』という問いで立てると、膨大なコストと時間がかかり、完成前に組織が疲弊します。パレートの法則で問うのは——どの二割の製品と情報が、八割のトラブルを生んでいるか、です」
「まず、修理対応の履歴を整理しましょう」とGeminiが提案した。「過去三年間の修理問い合わせ件数を、製品別に集計してください」
一週間後、遠藤氏が持ってきたデータをROI Polygraphに入力した。ツールが分析結果を返す。
「数字が出ました」とGeminiが画面を見ながら言った。「過去三年間の修理問い合わせ、延べ二百三十八件。そのうちの八十一パーセントが、製品カテゴリー全体の十九パーセント——具体的には十七製品——から発生しています。パレートの法則が、ほぼ正確に成立しています」
「その十七製品の仕様情報が」と私が確認した。「どれだけ整備されていますか」
遠藤氏が資料を確認した。「この十七製品のうち、仕様が完全に文書化されているのは——三製品です。残り十四製品は、古参社員の記憶に依存しています」
「つまり」とClaudeが整理した。「全製品の情報を一斉に整備しようとせず、この十七製品から始めるだけで、修理対応トラブルの八割を解決できます。対象が全体の十九パーセントなので、情報整備のコストも大幅に絞れます」
[二割の原因を特定する——なぜ十七製品が集中するか]
「次の問いは、なぜこの十七製品に修理が集中するかです」とGeminiが続けた。「パレートの法則は集中を示しますが、原因は示しません」
ROI Polygraphでさらに深掘りすると、十七製品に共通するパターンが浮かんだ。
「設計担当が一名だった製品、かつ納品後の仕様変更が三回以上あった製品」とGeminiが読み上げた。「この条件を満たすものが十四製品。変更のたびに仕様書の更新が追いつかなかった結果、最新の仕様が担当者の頭の中だけに残っている」
「仕様変更の記録プロセスに問題がある」と遠藤氏が声を上げた。「変更自体はするが、文書に反映させる文化がなかった」
「これが、属人化の本当の原因です」と私が言った。「古参社員の知識が属人化しているように見えるが、根本は変更管理プロセスの欠如です。AIで知識を吸い出すより先に、変更のたびに仕様書を更新するルールを設ける方が、長期的には根本解決になります」
[二段階の対応計画]
「第一段階——十七製品の仕様情報を三ヶ月で整備します」とClaudeが具体化した。「古参社員三名に週一回、二時間のインタビューを行い、製品ごとの仕様をドキュメント化する。情報を引き出す場としてOpen Casefilesを活用してください。過去案件の情報を体系的に蓄積し、後から検索できる構造にします」
「第二段階——変更管理プロセスの確立です」とGeminiが続けた。「仕様変更が発生した際、翌営業日以内に文書を更新するルールを設ける。これを守るために、変更申請書と仕様書の更新をセットのワークフローにする。最初は手間に感じますが、三ヶ月後には修理問い合わせへの初動時間が大幅に短縮されます」
遠藤氏が頷きながら言った。「全部やろうとすると、どこから手をつければいいか分からなくなっていました。十七製品から始めればいい、という言葉が、目の前の霧を晴らしてくれました」
第三章：記憶を地図にする
「AIを活用した知識ベース構築については」と私が続けた。「第一段階と第二段階が安定してから、第三段階として検討してください。ドキュメントが整備されていない状態でAIを導入しても、AIが学ぶ正しい情報がない。ゴミが入ればゴミが出る——情報の質が、AIの回答の質を決めます」
「つまり」と遠藤氏が言った。「まず情報を作る。次に情報を更新し続けるルールを作る。その上でAIを乗せる——三段階の順序ですね」
「パレートの法則が教えるのは」とClaudeが締めた。「全部を一度に解こうとしないことです。二割の原因を特定して、そこに集中する。その集中が、八割の問題を解きます。残りの二割の問題は、第一段階の成功を見てから判断すればいい」
窓の外では、夕暮れの工場から作業を終えたスタッフが出てくる姿が見えた。古参社員の一人が、若い担当者に何かを説明しながら歩いている。
第四章：記憶が文字になる日
六ヶ月後、遠藤氏から報告が届いた。
十七製品の仕様文書化は四ヶ月で完了。修理問い合わせ対応の初動時間は、平均一・三日から二時間以内に短縮された。
五ヶ月目に変更管理ワークフローを導入。六ヶ月目の修理問い合わせ件数は、三年間の月平均と比較して三十一パーセント減少した。原因は、変更管理が機能し始めたことで、設計段階での曖昧さが解消されていたことだった。
遠藤氏は報告書にこう記していた。「古参社員の問題だと思っていましたが、プロセスの問題でした。記録を残さない文化が、記憶への依存を作っていた。十七製品から始めた理由を、古参社員三名に話したところ、初めて本気で協力してくれました。全部やれと言われたら、どこから手をつければいいか分からなかったと言っていました」
二割の鍵が、八割の扉を開けた日だった。
「属人化の問題を、人の問題だと見ると解けない。人が情報を手放さないのではなく、情報を残す仕組みがないのだ。パレートの法則が問うのは、どの二割の原因が八割の問題を生んでいるか、だ。全部を一度に変えようとすると、全部が中途半端になる。二割を特定して集中すると、八割が動く。そして、変化が可視化された時、人は自分から協力を申し出る」
関連ファイル
使用ツール
- ROI Polygraph — 修理履歴の分析と問題集中製品の特定
- Open Casefiles — 過去案件・仕様情報の体系的な蓄積と検索
