開発者サーベイの設計 - L0 カリキュラム

ストーリー

田

田中VPoE

定量データは「何が起きているか」を教えてくれる。だが「なぜそうなっているか」「何が本当に困っているか」は開発者本人に聞くしかない

あなた

アンケートを取るということですか。ただ、サーベイって回答率が低かったり、建前の回答しか集まらなかったりしませんか？

あ

田

田中VPoE

だからサーベイの設計が重要なんだ。質問の作り方、匿名性の担保、分析の仕方。適切に設計すれば、プラットフォーム改善の最重要インプットになる

あなた

定量データとサーベイ結果を組み合わせて、開発者体験の全体像を把握するんですね

あ

田

田中VPoE

その通りだ。データが「環境構築に3.2日かかっている」と教えてくれて、サーベイが「ドキュメントが古くて毎回先輩に聞いている」と教えてくれる。両方合わせて初めてアクションが決まる

サーベイ設計の原則

効果的なサーベイの5原則

原則	説明	アンチパターン
短さ	回答時間10分以内。質問は20問以下	50問以上の大規模アンケート
匿名性	匿名で回答可能にする	名前や所属チームを必須にする
具体性	具体的な行動や体験を問う	「満足していますか？」のような曖昧な質問
アクション可能性	結果からアクションに繋がる質問設計	「○○を知っていますか？」のような知識確認
定期性	四半期ごとに実施し、トレンドを追跡	年1回の一度きり

質問タイプの使い分け

質問タイプ	用途	例
リッカート尺度（1-5）	満足度、同意度の測定	「デプロイプロセスは簡単だと思う」（1 〜 5 ）
NPS（0-10）	推奨度の測定	「現在の開発環境を同僚に推薦するか」
選択式	優先度、ペインポイントの特定	「最も改善してほしい領域を3つ選択」
自由記述	定性的なフィードバック	「開発で最もフラストレーションを感じる瞬間は？」

サーベイテンプレート

セクション1: 全体的な満足度（3問）

Q1. [NPS] 現在の開発環境を、新しく入社する同僚に推薦しますか？
    0（全く推薦しない）〜 10（強く推薦する）

Q2. [リッカート] 日常的な開発業務において、ビジネスロジックの実装に
    集中できている。
    1（全く当てはまらない）〜 5（非常に当てはまる）

Q3. [リッカート] 開発に必要なツールや環境は十分に整っている。
    1（全く当てはまらない）〜 5（非常に当てはまる）

セクション2: 開発ワークフロー（5問）

Q4. [リッカート] 新しい開発環境のセットアップは簡単で迅速にできる。
Q5. [リッカート] CI/CDパイプラインのフィードバックは十分に速い。
Q6. [リッカート] 本番環境へのデプロイに不安を感じない。
Q7. [リッカート] 障害発生時に、何をすべきかが明確である。
Q8. [リッカート] コードレビューのプロセスは効率的である。

セクション3: インフラ・プラットフォーム（5問）

Q9.  [リッカート] インフラの操作はセルフサービスで完了できる。
Q10. [リッカート] インフラチームへの依頼チケットの待ち時間は許容範囲内だ。
Q11. [リッカート] Kubernetesの設定やYAMLの記述は負担になっていない。
Q12. [リッカート] セキュリティ要件の遵守は開発速度を大きく妨げていない。
Q13. [リッカート] 監視・ログの確認は簡単にできる。

セクション4: ドキュメント・ナレッジ（3問）

Q14. [リッカート] 必要なドキュメントはすぐに見つかる。
Q15. [リッカート] 新しいサービスの作り方は明確に文書化されている。
Q16. [リッカート] チーム横断的な技術的な質問には素早く回答が得られる。

セクション5: ペインポイントと改善要望（4問）

Q17. [選択式] 開発で最も時間がかかっていると感じる領域を3つ選択してください。
     □ 環境構築　□ CI/CDの待ち時間　□ コードレビュー待ち
     □ インフラ設定　□ デプロイ作業　□ 障害対応
     □ ドキュメント検索　□ セキュリティ対応　□ 依存関係の解決
     □ その他（自由記述）

Q18. [選択式] プラットフォームに最も求める機能を3つ選択してください。
     □ ワンクリック環境構築　□ サービステンプレート
     □ セルフサービスDB作成　□ 自動CI/CDセットアップ
     □ 統合ダッシュボード　□ APIドキュメント自動生成
     □ コスト可視化　□ セキュリティ自動チェック
     □ その他（自由記述）

Q19. [自由記述] 開発で最もフラストレーションを感じる瞬間を教えてください。

Q20. [自由記述] プラットフォームチームに一つだけお願いできるとしたら
     何を改善してほしいですか？

サーベイ結果の分析方法

分析フレームワーク

分析手法	目的	方法
セグメント分析	チーム・経験年数による差異の把握	クロス集計
トレンド分析	前回との比較、改善・悪化の把握	時系列比較
相関分析	満足度に影響する要因の特定	スコア間の相関係数
テキスト分析	自由記述からのテーマ抽出	キーワード頻度、感情分析
優先度マトリクス	改善インパクトの大きい領域の特定	重要度 × 満足度のマッピング

優先度マトリクス

重要度が高い × 満足度が低い = 最優先で改善
重要度が高い × 満足度が高い = 維持・強化
重要度が低い × 満足度が低い = 余力があれば改善
重要度が低い × 満足度が高い = 現状維持

    重要度 高
       │
  最優先改善 │ 維持・強化
       │
  ─────┼────── 満足度
       │
  余力で改善 │ 現状維持
       │
    重要度 低

回答率を高めるための工夫

施策	効果
経営層からの呼びかけ	「結果は必ず改善アクションに繋げる」と約束
回答時間の明示	「10分で完了します」と冒頭に記載
前回の改善実績の共有	「前回の結果を受けて○○を改善しました」
チーム別回答率の可視化	適度な競争心を刺激（ただし強制はしない）
結果の全社公開	透明性を示し、フィードバックが活かされることを証明

「サーベイの回答率が80%を超えたら、組織は開発者体験に本気で向き合っている証拠だ。50%以下なら、開発者は『どうせ変わらない』と思っている」 — 田中VPoE

まとめ

ポイント	内容
サーベイ設計の5原則	短さ、匿名性、具体性、アクション可能性、定期性
テンプレート	全体満足度 → ワークフロー → インフラ → ドキュメント → ペインポイント
分析方法	セグメント分析、トレンド分析、優先度マトリクス
回答率	経営層の関与と改善実績の共有が鍵

チェックリスト

効果的なサーベイ設計の5原則を説明できる
質問タイプの使い分けを理解した
サーベイ結果の分析方法を把握した
回答率を高めるための施策を理解した

次のステップへ

次は「Platform Engineeringの基本原則」を学びます。サーベイで特定した課題を解決するための、プラットフォーム設計の原則を身につけましょう。

推定読了時間: 30分