ストーリー
田
田中VPoE
コッターの段階4「ビジョンを伝える」は、実は8段階の中で最も過小評価されがちなステップだ
あなた
ビジョンは策定したので、あとは全社メールで送ればいいのでは?
あ
田
田中VPoE
それが典型的な失敗パターンだ。調査によると、変革のビジョンが組織全体に正しく伝わっている割合は平均でわずか10%。全社メール1通で伝わるわけがない
あなた
10%ですか…。では、どうすれば残りの90%に届くんですか?
あ
田
田中VPoE
コミュニケーション戦略だ。誰に、何を、いつ、どうやって伝えるか。そして重要なのは「聞く」ことだ。一方的な発信では人は動かない
コミュニケーションの原則
変革コミュニケーションの7原則
| 原則 | 説明 |
|---|
| 1. WHYから始める | 「何をするか」ではなく「なぜ変わる必要があるか」から |
| 2. 繰り返す | 1回では伝わらない。最低7回は異なるチャネルで |
| 3. 一貫性 | メッセージの核心がブレない |
| 4. 双方向 | 聞く機会を設ける。フィードバックを歓迎する |
| 5. 具体的 | 抽象的なスローガンではなく、具体的な変化を伝える |
| 6. 感情に訴える | データだけでなく、ストーリーで共感を生む |
| 7. 行動で示す | リーダー自身がビジョンに沿った行動を取る |
WHYから始めるフレームワーク
サイモン・シネックの「ゴールデンサークル」を変革コミュニケーションに応用します。
┌─────────┐
│ WHY │ なぜ変わるのか?
│ (目的) │ 「週2回リリースできる組織になり、
│ │ 顧客への価値提供を加速するため」
├─────────┤
│ HOW │ どうやって変わるのか?
│ (方法) │ 「CI/CD、テスト自動化、
│ │ プロセスの簡素化を段階的に導入」
├─────────┤
│ WHAT │ 具体的に何が変わるのか?
│ (内容) │ 「PRテンプレート、自動テスト、
│ │ リスクベース承認」
└─────────┘
× 悪い伝え方: 「CI/CDを導入します」(WHATから始めている)
○ 良い伝え方: 「顧客に素早く価値を届けるために、開発プロセスを変革します」
対象別コミュニケーション設計
ステークホルダー別のメッセージ
| 対象 | 関心事 | 伝えるべきこと |
|---|
| 経営層 | ROI、競争力、リスク | 投資対効果、市場での競争優位性、リスク管理 |
| 中間管理職 | チームへの影響、自分の役割 | チームの負荷軽減、新しい役割のメリット |
| テックリード | 技術的な妥当性、品質 | アーキテクチャの改善、技術負債の削減 |
| 一般エンジニア | 自分の仕事がどう変わるか | 日常業務の具体的な変化、スキルアップの機会 |
| QA/セキュリティ | 品質基準、役割の変化 | 品質は維持・向上する、役割の拡大 |
メッセージのテーラリング例
同じ改善を異なる対象に伝える例: テスト自動化
経営層向け:
「テスト自動化により、リリースサイクルを50%短縮し、
年間9,360万円のコスト削減と市場投入速度の改善を実現します」
テックリード向け:
「テスト自動化基盤を構築し、手動テストの80%を自動化します。
テストピラミッドの設計と、CI/CDへの組み込みが技術的なポイントです」
QAチーム向け:
「手動の回帰テストから解放され、探索的テストや品質戦略の策定に
注力できるようになります。QAの役割がより戦略的に進化します」
一般エンジニア向け:
「PRを出すとテストが自動実行され、結果がSlackに通知されます。
QAへの受け渡し待ち3日がなくなり、フィードバックが即座に得られます」
コミュニケーションチャネルの設計
チャネルの特性と使い分け
| チャネル | 到達率 | 双方向性 | 適するメッセージ |
|---|
| 全社集会/オフサイト | 高 | 中 | ビジョンの発表、重要なマイルストーン |
| 部門ミーティング | 高 | 高 | 部門固有の影響と変化の説明 |
| 1on1 | 低 | 極めて高 | 個人の懸念への対応、キーパーソンの巻き込み |
| Slackチャンネル | 中 | 高 | 日常的な進捗共有、Q&A |
| メール/ニュースレター | 中 | 低 | 定期的な進捗報告、公式な決定事項 |
| ドキュメント/Wiki | 低 | 低 | 詳細な技術情報、FAQ、手順書 |
コミュニケーション計画のタイムライン
| タイミング | チャネル | 内容 |
|---|
| 変革開始前 | 全社集会 | ビジョンの発表、危機感の共有 |
| 変革開始前 | 部門ミーティング | 各部門への具体的な影響説明 |
| 毎週 | Slackチャンネル | 進捗の共有、Q&A |
| 隔週 | チーム定例 | チームレベルの変化と対応の議論 |
| 月次 | 全社メール | 成果報告、次月の計画 |
| マイルストーン達成時 | 全社集会 | 成果の祝福、次のステップの共有 |
フィードバックの収集と活用
フィードバックチャネル
| チャネル | 頻度 | 目的 |
|---|
| パルスサーベイ | 隔週 | 変革への感情・態度の定点観測(3-5問) |
| レトロスペクティブ | スプリントごと | チームレベルの課題と改善点の収集 |
| オフィスアワー | 週1回 | 自由に質問・懸念を表明できる場 |
| 匿名フォーム | 常時 | 言いにくい懸念や反対意見の収集 |
フィードバックへの対応
| フィードバックの種類 | 対応 |
|---|
| 質問 | 迅速に回答し、FAQ化して全体に共有 |
| 懸念 | 真摯に受け止め、対策を具体的に説明 |
| 反対意見 | 否定せず傾聴し、対話の場を設ける |
| 改善提案 | 積極的に取り入れ、提案者を表彰 |
「フィードバックに対して最悪なのは『無視する』ことだ。反対意見も含めて、すべてのフィードバックに何らかのレスポンスを返す。それが信頼の基盤になる」 — 田中VPoE
まとめ
| ポイント | 内容 |
|---|
| 7原則 | WHYから始め、繰り返し、双方向で伝える |
| 対象別メッセージ | ステークホルダーの関心事に合わせてテーラリングする |
| チャネル設計 | 到達率と双方向性に応じて複数チャネルを使い分ける |
| フィードバック | 積極的に収集し、すべてにレスポンスを返す |
チェックリスト
次のステップへ
次は「パイロット設計」を学びます。改善施策を小さく始めて検証し、成功パターンを確立する方法を身につけましょう。
推定読了時間: 30分