ROI事件ファイル No.574『手順は描けたが、使う人の不安に立っていなかった』
手順は描けたが、使う人の不安に立っていなかった
第一章：手順は書けた、だが不安が消えない
「大学のオンプレミスメールサーバーを、Google WorkspaceかMicrosoft 365へ移行したいんです。作業は内製で進めます」
TechNexus社の情報システム担当、添田心氏は、そう言いながら状況を語った。「サポート期限が迫って、迷惑メールも増えている。移行手順は自分で描きました。ただ、設定が妥当か、セキュリティは大丈夫か、専門家の確認がほしくて」
「手順は描けたのに、何が不安なのでしょう」とClaudeが尋ねた。
「……担当する現場が、動けていないんです」と添田氏が答えた。「手順書は作った。でも、実際に手を動かすメンバーが、どこで詰まるか分からない、失敗したら止まる、と不安がっている。技術的な段取りは描けたのに、進まない」
「使う人や、作業する人の不安から、設計しましたか」と私が確認した。
「していません」と添田氏が答えた。「移行の手順ばかり見ていました。誰が、どこで、何に不安を感じるか。使う人の状況に立って組んだことがない」
「手順が描けても、使う人の不安に立っていなければ、移行は進みませんね」と私が応じた。「EMPATHYで分解しましょう」
第二章：EMPATHYが問う、使う人の状況に立って進める
「この案件には、EMPATHYが必要です」
Claudeがホワイトボードに「共感・マッピング・優先順位・評価・テスト・引き渡し・成果」と書いた。
「EMPATHY——共感・マッピング・優先順位・評価・テスト・引き渡し・成果の七段階とは、使う人の状況に立ち、そこから移行を設計するフレームワークです」と私が説明した。「肝は、手順を先に描かないこと。まず、使う人と作業する人が、どこで、何に不安を感じるかに共感する。そこから現状を写し、優先順位をつけ、評価し、試し、渡す。人の不安を起点にするから、移行が現場で進む。手順を人に噛み合わせる道具です」
「まず現状のコストを測りましょう」とGeminiがROI Polygraphを開いた。添田氏から提供されたデータを入力する。
「月間のコストが出ました」とGeminiが読み上げた。「内製移行の手探り・確認工数が月平均百六十五時間、時給四千円で月六十六万円。使う人の不安による移行の停滞が月平均三十八万円。セキュリティ不安による検証の後戻りが月平均三十六万円。現状把握の不足による移行漏れリスクが月平均三十四万円。引き渡し設計の不在による運用定着の遅延が月平均三十万円。合計で月二百四万円。年間換算で約二千四百四十八万円」
添田氏が数字を見つめた。「手順の工数だけ見ていました。使う人の不安で移行が止まるコストまで足すと、これほどとは」
「では、EMPATHYで設計します」と私が続けた。
[共感・マッピング——使う人の状況に立って現状を写す]
「最初に、共感とマッピングです」とClaudeが言った。「作業する現場が、どこで詰まり、何に不安を感じるかに立つ。その上で、現行のオンプレミス環境と、移行先の機能を並べて写す。人の不安を起点に、現状を地図にします」
[優先順位・評価——不安の大きい順に危険を測る]
「次に、優先順位と評価です」とGeminiが続けた。「サポート期限とセキュリティリスクを、不安の大きい順に並べる。現行の脆弱性と、移行後の強化点を評価する。何から手を打てば不安が減るかを、測ります」
[テスト・引き渡し——試してから渡す]
「評価の次に、テストと引き渡しです」と私が続けた。「移行プランを試し、潜在的な問題を先に洗い出す。完了後は、詳細なレポートと運用ガイドラインを渡す。試して、渡す。作業する人が、安心して引き継げる形にします」
[成果——安全な移行という結果を出す]
「最後に、成果です」とClaudeが続けた。「安全かつ迅速に移行を終え、迷惑メールの減少とセキュリティ向上を出す。使う人の不安から設計したから、現場が止まらず、結果につながります」
[投資回収を試算する]
「ROI Proposal Generatorで試算しましょう」とGeminiが提案した。
- 初期費用：共感ヒアリング・現状マッピング・移行設計・セキュリティ評価・テスト/引き渡し支援費用合計五百二十万円
- 月次費用：新サービス利用・運用継続費合算月二十二万円
- 月次削減効果：使う人視点の移行による停滞解消＝月五十万円（七割削減想定）、セキュリティ強化＝月三十四万円、移行漏れの防止＝月二十八万円、運用定着の加速＝月三十万円、合計月百四十二万円
- 月次純削減：百四十二万円－二十二万円＝月百二十万円
- 投資回収期間：五百二十万円÷百二十万円＝約四・三ヶ月
「四ヶ月強の回収です」とGeminiが整理した。「効くのは、手順を先に描かず、使う人の不安から設計する点です。手順だけ整えても、作業する現場が不安で止まれば移行は進まない。人の状況に立つから、現場が動く。投資が空振りしません」
添田氏が数字を確認しながら言った。「手順を描けば進むと思っていました。使う人の不安に立たないと、現場は動かない」
「EMPATHYは、使う人の状況に立って進める道具です」と私が応じた。
第三章：使う人に立って進める導入計画
「進め方を整理します」と私がホワイトボードの前に立った。
「第一ヶ月——現場への共感ヒアリングと、現状のマッピング。第二ヶ月——サポート期限とセキュリティリスクの優先順位付け、脆弱性の評価。第三・四ヶ月——移行プランのテストと問題の事前洗い出し。第五ヶ月——移行の実施と、レポート・運用ガイドラインの引き渡し。第六ヶ月——効果検証と迷惑メール・セキュリティの確認。第七ヶ月以降——運用の定着、他部門・他校への横展開」
「手順書があるのに、共感から始める必要がありますか」と添田氏が確認した。
「そこが要です」とClaudeが応じた。「手順書があっても、作業する人がどこで不安になるか分からなければ、現場は止まる。EMPATHYで人の状況に立てば、詰まる箇所を先に潰し、安心して引き継げる。手順を人に噛み合わせることが、移行を進める近道です」
添田氏がメモを取りながら言った。「手順を描く前に、使う人の不安に立つ。順序が見えました」
第四章：不安に立って、移行が動いた日
十ヶ月後、添田氏から報告が届いた。
移行は、現場に立った設計の後、止まらず進んだ。「手を動かすメンバーが、どこで詰まるか先に分かった。不安が消えて、作業がスムーズに進んだ」と添田氏は記していた。
セキュリティも強化された。脆弱性の評価と移行後の対策が、不安を消した。「サポート期限内に、安全に移行を終えられた。迷惑メールも減った」と報告書にあった。
最も大きな変化は、設計の起点に表れた。手順から描く状態から、使う人の不安に立つ状態に変わった。「移行の段取りばかり組んでいた。使う人の状況に立ったら、詰まる箇所が先に見えて、現場が動くようになった」と添田氏は記していた。
引き渡しも滑らかだった。レポートと運用ガイドラインが、その後の運用を支えた。「渡して終わり、にならなかった。作業する人が、安心して引き継げた」と報告書にあった。
副次効果として、進め方の見方が変わった。手順先行でなく人先行の発想が根づいた。「段取りから、をやめた。誰が、どこで、何に不安を感じるか、から考えるようになった」と添田氏は記していた。
添田氏の報告書の最後にはこう書かれていた。「メール移行の悩みは、手順の妥当性だと思っていた。だが本当の問題は、手順は描けても、使う人の不安に立っていなかったことだ。EMPATHYで人の状況に立った瞬間に、現場が動きはじめた。手順を描く前に、使う人に立つことが先だった」
手順は描けたが使う人の不安に立っていなかった会社が、人の状況に立って移行を動かせる会社に変わった日、メール移行は技術手順の設計から、使う人の状況に立って進める設計に変わっていた、と記されていた。
「システム移行の相談は、たいてい『手順は妥当か』という形で来る。だが手順を描く前に問うべきことがある。使う人の不安に、立っているか。EMPATHYが問うのは、共感から成果までの七段階だ。人の状況に立てば、詰まる箇所を先に潰せる。手順は描けても人に立っていなかった会社が、不安から設計できた日、変わったのは手順の精度ではなく、使う人の状況に立って進める視点そのものだった」
関連ファイル
使用ツール
- ROI Polygraph — 内製手探り工数・使う人の不安による停滞・移行漏れリスクの可視化
- ROI Proposal Generator — 使う人の状況に立った設計を起点にしたメールサーバー移行の投資回収シミュレーション
