ストーリー

ミッション概要

前提条件

現在の状況

モニタリングツール統一プロジェクトの背景:
  現状: 6チームが5種類のモニタリングツールを個別運用
  課題: 障害発生時にチーム横断の状況把握に平均40分
        アラート疲れ（1日平均200件、うち対応必要は15件）
        ツール維持の重複コスト年間1,200万円
  目標: Datadogに統一し、オブザーバビリティ基盤を構築
  効果: 障害検知時間50%短縮、アラートノイズ80%削減、コスト30%削減

推進体制:
  スポンサー: CTO佐藤
  推進リーダー: あなた
  テクニカルリード: SREチーム 鈴木

Mission 1: 運用チームリーダーの抵抗を分析する

シナリオ

運用チームリーダーの高橋さん（勤続15年、Nagiosのエキスパート）との1on1で、以下の発言がありました。

「Nagiosで10年間やってきた。障害を見逃したことは一度もない。Datadogなんて使ったこともないのに、なぜ変える必要があるのか。クラウドサービスに依存したら、Datadog自体が障害を起こしたときどうするんだ。うちのNagiosのカスタムプラグインは50個以上ある。これを全部移行するのに何ヶ月かかると思っているんだ。若い連中はすぐ新しいツールに飛びつくが、本当に安定運用できるのか。」

要件

1. 抵抗の類型分析: 高橋さんの発言を類型別に分解し、表面の主張と本音を特定する
2. 対話シナリオ: GROWモデルに基づいた1on1の会話を設計する
3. アクションプラン: 高橋さんを「移行リーダー」に変えるための具体的なアクション3つ

Goal:
  「高橋さん、運用チームとして理想的なモニタリング環境は
   どんなものですか？10年後を見据えて」
  → 長期的なビジョンを引き出す

Reality:
  「今のNagiosの運用で、正直に一番困っていることは何ですか？
   例えばマイクロサービスの監視とか」
  高橋: 「...正直、コンテナ環境の監視は厳しくなってきている。
         Nagiosのプラグインでは動的なサービスメッシュに対応できない」
  → 現行ツールの限界を本人から引き出す

Options:
  「もしNagiosの知見を活かしながら、新しいツールの設計を
   高橋さんがリードする形なら、どう感じますか？
   Nagiosのカスタムプラグインの知見は、Datadogのカスタム
   メトリクス設計に直接活かせます」
  → Nagiosの経験が「負債」ではなく「資産」になることを示す

Will:
  「まず、Nagiosのカスタムプラグイン50個の機能棚卸しを
   高橋さんに主導していただけませんか？
   どの機能をDatadogの標準機能で代替でき、
   どの機能をカスタム開発する必要があるか。
   高橋さんにしかできない仕事です」
  → 移行の「専門家」としての役割を提案

Mission 2: 開発チームマネージャーとの交渉

シナリオ

プロダクト開発チームのマネージャー中村さんとの会議で、以下のやり取りがありました。

中村: 「モニタリングツールの統一は賛成だ。ただし、うちのチームはQ3の大型リリースを控えていて、今が一番忙しい。ツール移行に工数を割く余裕はない。Q4以降なら検討できるが、Q3は絶対に無理だ。それに開発メンバー10名のうち、8名がCloudWatchしか使ったことがない。Datadogの学習コストも心配だ。」

さらに、後日のSlackで以下の情報が入りました。

「中村さんのチームのリリースは11月末で、実はQ4初頭（12月-1月）も不具合対応で忙しくなる見込みです。実質的に移行に取り組めるのは2月以降になりそうです」

要件

1. 抵抗の分析: 中村さんの抵抗を類型分析する
2. 交渉シナリオ: 原則立脚型交渉の4原則に基づいた対話を設計する
3. Win-Win提案: 中村さんのチームにとってもメリットのある提案を3つ以上策定する

原則1（人と問題を分離）:
  「中村さんのQ3リリースの成功は当然最優先です。
   ツール移行がリリースの妨げになることは絶対に避けたい。
   その上で、一緒に最善のタイミングと方法を考えませんか」

原則2（利害に焦点）:
  「Q3のリリースで一番心配していることは何ですか？
   例えばリリース後の障害対応が迅速にできるか、
   というような懸念はありますか？」
  中村: 「...実は前回のリリースで障害対応に12時間かかった。
         CloudWatchだけでは原因特定に時間がかかる」

原則3（双方の利益になる選択肢）:
  「であれば、こういう提案はどうでしょう。
   Q3リリースの『モニタリング強化』としてDatadogを
   並行導入する。CloudWatchは維持したまま、
   Datadogを追加の可視化ツールとして使い始める。
   リリース後の障害対応が格段に速くなります。
   中村さんのチームにとっても、リリースの安全網が
   一つ増えることになります」

原則4（客観的基準）:
  「SREチームAでは、Datadog導入後にMTTRが
   8時間から2時間に短縮されました。
   Q3リリースの安全性を高める投資として
   位置づけられませんか？」

Mission 3: 支持者の連合を構築する

シナリオ

モニタリングツール統一プロジェクトの現状は以下の通りです。

1. 賛成者は少数（SREチームとCTOのみ）
2. 中立が大多数（開発チーム3つ、QAチーム）
3. 反対が2名（運用チーム高橋、セキュリティ部長）
4. セキュリティ部長は「外部SaaSへの監視データ送信はセキュリティポリシー違反の可能性がある」と主張
5. 予算は承認済みだが、全社展開には各チームの「自発的な参加」が必要

要件

1. 推進連合の設計: 誰をメンバーに含め、どんな役割を与えるか
2. チェンジエージェントの配置: 各チームに1名、どういう基準で選ぶか
3. セキュリティ部長への対応策: Win-Winの提案を設計する
4. 展開戦略: 6チームをどの順番で巻き込むか、その理由

達成度チェック

推定所要時間: 90分