ROI事件ファイル No.443『深夜三時の無人の窓口』
深夜三時の無人の窓口
第一章：夜間に鳴り続ける電話
「深夜三時に、担当者の個人スマートフォンに電話がかかってきます。週に二、三回は」
TechGlobal社のIT統括部長、渡辺浩一氏は、そう言いながら目の下の隈を軽く指で触れた。東日本エリアに十四拠点を持つ同社は、その中に二十四時間三百六十五日稼働する工場を三つ抱えている。
「工場の生産ラインが止まった原因がITにあると思われる時、現場は誰かに連絡しなければなりません。窓口がないから、過去に対応してくれた担当者の個人番号に電話する。それが三年続いています」
「各拠点にIT担当者はいるのですか」と私は尋ねた。
「名目上はいます。ただ、兼務です。経理が本業で、パソコンに詳しいからIT担当を兼ねている、という方がほとんどです。夜間に起こされても対応できるスキルも権限もない」
「ナレッジはどこに蓄積されていますか」とGeminiが問いかけた。
渡辺氏が苦笑した。「各担当者の頭の中です。あの拠点のあのサーバーは再起動するとこういう挙動をする、あのプリンターはドライバを入れ直す前に一度電源を切る必要がある——こういった情報が、十四拠点に分散して存在していて、どこにも記録されていない」
「外注化を検討している理由は」とClaudeが確認した。
「二つあります。一つは、担当者の疲弊。深夜対応が続いて、昨年二名が退職しました。もう一つは、六ヶ月後に新工場が稼働します。現体制では、とても吸収できない」
事件の全体像が見えた。問題は「外注先をどこにするか」ではなく、「何を外注し、何を社内に残すか」という設計そのものが存在していなかった。
第二章：二つのダイヤモンド
「この案件には、ダブルダイヤモンドが適しています」
Geminiがホワイトボードにひし形を二つ横に並べて描いた。左のダイヤモンドに「問題の発見と定義」、右のダイヤモンドに「解決策の開発と提供」と書き込む。
「ダブルダイヤモンドモデルは」と私が説明を始めた。「デザイン思考を実務に落とし込んだフレームワークです。最大の特徴は、解決策を考え始める前に、問題そのものを正しく定義する段階を設けていること。外注化という解決策が先行しているこの案件では、まず左のダイヤモンドで本当の問題を問い直す必要があります」
[Discover：何が起きているかを広げる]
「左のダイヤモンドの最初のフェーズは、Discover——発見です」とClaudeが続けた。「まず、事実を広く集める。現在、Open Casefilesで類似案件のパターンを確認しましょう」
画面を開くと、過去のITヘルプデスク外注化案件のデータが並んだ。失敗事例の共通点として浮かび上がったのは、「外注前にインシデントの分類ができていなかった」という項目だった。
「渡辺さん、直近六ヶ月のIT問題を思い出せる範囲で教えていただけますか。種類別に」と私が促した。
渡辺氏がメモを取り始めた。ネットワーク障害、端末トラブル、ソフトウェアのライセンス切れ、プリンター故障、サーバーの定期メンテナンス——十分ほどで十八種類が出てきた。
「このうち、深夜に発生するものは」とGeminiが尋ねた。
「ネットワーク障害とサーバー関連です。工場の生産システムがネットワークに依存しているので」
[Define：何が本当の問題かを絞る]
「次のフェーズ、Define——定義です」と私が続けた。「十八種類のインシデントを、二軸で分類します。一つ目の軸は発生頻度。二つ目の軸は対応の専門性——誰でも対応できるか、専門スキルが必要かです」
Geminiがマトリクスを描いた。右上の「高頻度・低専門性」の象限には、プリンター故障やパスワードリセットが集まった。左上の「低頻度・高専門性」には、サーバー障害とネットワークの深刻な断絶が位置した。
「外注すべきは、この右上の象限です」とClaudeが指した。「高頻度で対応が定型化できるインシデントは、ナレッジをマニュアル化して外注先に移転できます。逆に左上の高専門性インシデントは、外注先の選定基準そのものを変える必要がある」
「深夜三時の電話の正体は」と私が整理した。「この左上にある少数の高専門性インシデントです。週に二、三回という頻度は多く聞こえますが、実数で言えば月間十件以下の可能性が高い。問題の大きさと頻度を混同しないことが、外注設計を正確にします」
[Develop・Deliver：解決策を形にする]
「右のダイヤモンドに移ります」とGeminiが続けた。「Develop——解決策の開発フェーズでは、外注先の要件を三段階に分けて定義します」
「第一要件は、二十四時間三百六十五日の一次対応窓口です」とClaudeが説明した。「高頻度・低専門性インシデントを受け付け、マニュアルに基づいて解決する。これは比較的安価な外注先で対応可能です」
「第二要件は」とGeminiが続けた。「夜間の高専門性インシデントへのエスカレーション体制です。一次対応で解決しない場合、三十分以内に専門エンジニアにエスカレーションする契約を結ぶ。この体制があるかどうかが、外注先選定の核心です」
「第三要件は」と私が加えた。「ナレッジの蓄積と移転の仕組みです。外注先のエンジニアが解決したインシデントの対応記録を、必ず社内の知識ベースに戻す契約条項を入れてください。外注先だけにナレッジが蓄積されると、ベンダーロックインが発生します」
「Deliver——提供フェーズでは」とGeminiがまとめた。「まず五拠点でパイロット運用を三ヶ月行い、インシデントの分類精度とエスカレーション対応時間を計測してください。新工場稼働の二ヶ月前には全拠点展開を完了させる逆算スケジュールが必要です」
第三章：問題を正しく定義した先に
渡辺氏はホワイトボードのマトリクスを見つめていた。
「外注化の話をすると、経営層は『コストはどれだけ下がるか』と聞いてきます。しかし、今日の話では、コスト削減よりも先に解決すべきことがあると分かりました」
「ダブルダイヤモンドの本質は」と私が応じた。「解決策を急ぐほど、問題の定義が甘くなる、という逆説への答えです。今回、外注化という解決策は最初から決まっていた。しかし、何を外注するかを定義せずに進めると、高コストで機能しない外注体制ができあがります」
「担当者の深夜対応という問題も」とClaudeが補足した。「解決策は外注化ではなく、インシデントの分類と一次対応の標準化です。外注はその実行手段に過ぎない。この順序を入れ替えると、外注先へのブリーフィングの質が根本から変わります」
渡辺氏が深く頷いた。「来週、このマトリクスを社内のIT担当者全員と共有してインシデントの実態調査から始めます」
第四章：夜明けの窓口
彼が去った後、Claudeが呟いた。「深夜三時の電話は、技術の問題ではなかったのですね。設計の問題だった」
「ああ」と私は答えた。「ナレッジが個人の頭に眠り、窓口が存在せず、夜間に誰も責任を持たない。これは担当者の怠慢ではなく、構造の失敗だ。ダブルダイヤモンドは、その構造を問い直すための道具でもある」
窓の外で、夜の街が静かに動いていた。
五ヶ月後、渡辺氏から報告が届いた。
インシデント分類の調査により、全体の七十三パーセントが「高頻度・低専門性」に分類され、外注移転可能と判定。外注パイロット開始から二ヶ月で、担当者への深夜連絡はゼロになった。
新工場稼働の三週間前に全拠点展開を完了。外注費用は当初想定より十八パーセント低い水準で契約できた。問題を正しく定義したことで、外注先への要件が明確になり、競争見積もりで優位に交渉できたという。
渡辺氏の報告書にはこう記されていた。「問題を定義する前に解決策を選ぶな、というダブルダイヤモンドの教えは、外注先との交渉でも生きました。何を委ねて何を残すかが明確だったから、ベンダーに丸投げしなかった」
深夜三時の電話は、今夜も鳴っていない。
「外注化は解決策であり、問題ではない。しかし多くの企業が、何を外注するかを定義しないまま外注先を探し始める。ダブルダイヤモンドが提供するのは、解決策を急ぐ前に問題を広げ、絞り込む二段階の思考だ。左のダイヤモンドで問題を正しく定義できた時、右のダイヤモンドの解決策は驚くほど明快になる。問題の定義に費やした時間は、実行フェーズの手戻りとして必ず戻ってくる」
関連ファイル
使用ツール
- Open Casefiles — 類似案件の失敗パターンと成功要因を参照
