ストーリー

ステークホルダーマッピング

まず、誰が意思決定に関わるかを把握します。

interface Stakeholder {
  name: string;
  role: string;
  influence: "high" | "medium" | "low";
  interest: "high" | "medium" | "low";
  communicationStyle: "data-driven" | "vision-driven" | "detail-oriented";
  keyQuestion: string; // この人が最も気にする質問
}

const stakeholderMap: Stakeholder[] = [
  {
    name: "CTO",
    role: "技術部門責任者",
    influence: "high",
    interest: "high",
    communicationStyle: "vision-driven",
    keyQuestion: "長期的な技術戦略との整合性は？",
  },
  {
    name: "プロダクトマネージャー",
    role: "製品企画",
    influence: "high",
    interest: "medium",
    communicationStyle: "data-driven",
    keyQuestion: "ユーザー価値とリリーススケジュールへの影響は？",
  },
  {
    name: "CFO",
    role: "財務責任者",
    influence: "high",
    interest: "low",
    communicationStyle: "data-driven",
    keyQuestion: "コストとROIは？",
  },
  {
    name: "開発チーム",
    role: "実装担当",
    influence: "medium",
    interest: "high",
    communicationStyle: "detail-oriented",
    keyQuestion: "具体的にどう変わる？学習コストは？",
  },
];

技術を翻訳する技術

同じ技術的提案を、相手に合わせて表現を変えます。

例: マイクロサービスへの移行提案

## エンジニア向け
「モノリシックアプリをドメイン境界でマイクロサービスに分割します。
Strangler Figパターンで段階的に移行し、API Gatewayで
ルーティングを制御します。サービス間通信はgRPCを採用し、
Event Sourcingで整合性を担保します」

## プロダクトマネージャー向け
「各機能を独立してリリースできるようになります。
"ユーザー管理"の改修が"決済機能"に影響するリスクがなくなるため、
機能リリースの速度が約2倍に向上する見込みです。
移行中も既存機能は影響なく動作します」

## 経営層向け
「現在、新機能のリリースに平均4週間かかっています。
この改善により2週間に短縮でき、市場への対応速度が2倍になります。
初期投資は3ヶ月の追加工数ですが、12ヶ月後には
運用コスト30%削減と障害対応時間50%短縮が見込めます」

技術的提案の構成法

interface TechnicalProposal {
  // 1. 課題（相手が感じている痛みから始める）
  problem: {
    businessImpact: string;  // ビジネスへの影響
    currentMetrics: Record<string, number>;  // 現状の数値
    riskIfIgnored: string;  // 放置した場合のリスク
  };

  // 2. 提案（シンプルに）
  solution: {
    summary: string;  // 一言で
    approach: string;  // どうやるか
    timeline: string;  // いつまでに
  };

  // 3. 効果（数値で）
  benefits: {
    quantitative: Record<string, string>;  // 定量的効果
    qualitative: string[];  // 定性的効果
  };

  // 4. コストとリスク（隠さない）
  costs: {
    investment: string;  // 必要な投資
    risks: Array<{ risk: string; mitigation: string }>;
    tradeoffs: string[];
  };

  // 5. 次のアクション
  nextSteps: string[];
}

// 提案書の例
const proposal: TechnicalProposal = {
  problem: {
    businessImpact: "新機能リリースに平均4週間。競合は2週間で出している",
    currentMetrics: {
      deployFrequency: 2,  // 月2回
      leadTime: 28,  // 28日
      incidentRate: 3,  // 月3件
    },
    riskIfIgnored: "市場シェアの低下。エンジニア採用での不利",
  },
  solution: {
    summary: "CI/CDパイプラインの刷新とテスト自動化",
    approach: "3段階で移行。既存機能への影響なし",
    timeline: "3ヶ月で完了。1ヶ月目から効果を実感",
  },
  benefits: {
    quantitative: {
      deployFrequency: "月2回 → 週2回",
      leadTime: "28日 → 7日",
      incidentRate: "月3件 → 月1件以下",
    },
    qualitative: [
      "エンジニアの生産性向上",
      "障害対応の負担軽減",
      "採用時のアピールポイント",
    ],
  },
  costs: {
    investment: "エンジニア2名 × 3ヶ月",
    risks: [
      {
        risk: "移行中の一時的な生産性低下",
        mitigation: "段階的移行で影響を最小化",
      },
    ],
    tradeoffs: ["短期的な機能開発速度の低下を許容する必要がある"],
  },
  nextSteps: [
    "来週: PoCの実施計画を共有",
    "2週間後: PoC結果を報告",
    "1ヶ月後: 本格移行開始",
  ],
};

コミュニケーションの場面別テクニック

「No」の伝え方

テクニカルリードは、時に無理な要求を断る必要があります。

## Bad: 直接的な否定
「それは技術的に無理です」

## Good: 代替案を添えた建設的な回答
「ご要望の機能を2週間で実装する場合、3つの選択肢があります。

1. **スコープを限定する**: コア機能のみ2週間で実装し、残りは次スプリントに
2. **技術的負債を許容する**: 2週間で全機能を実装するが、1ヶ月後にリファクタが必要
3. **期限を延長する**: 品質を保って4週間で全機能を実装

私の推奨は選択肢1です。理由は......」

まとめ

チェックリスト

• ステークホルダーマッピングの方法を理解した
• 技術を非エンジニアに伝える技術を学んだ
• 提案書の構成法を把握した
• 建設的にNoを伝える方法を理解した

次のステップへ

次は「技術ロードマップの策定」を学びます。中長期的な技術戦略を計画し、チームを正しい方向に導く方法を掘り下げましょう。

推定読了時間: 25分