こんにちは、労務プロダクト開発本部でエンジニアリングマネージャーをしている山本です。
SmartHRではSPACEフレームワークを用いて開発者体験を可視化するサーベイを半期ごとに実施しており、これまでに2024年10月と2025年4月の2回行っています。
この記事では
- SPACEフレームワークの概要
- サーベイ設計と設問例
- 集計結果とそこから得た示唆
をご紹介します。
はじめに
組織の規模も大きくなり「どの課題がチーム固有で、どれが横断的か」ということを把握するのが難しくなってきています。また、今年に入ってからはLLMの導入に対するエンジニアからの期待値を知り、施策の当たり外れを検証しやすくするモチベーションもありました。これらを背景に"開発者の生産性"を測るため、SPACEフレームワークに基づいたサーベイを導入しました。
SPACE フレームワークの設問例は Web 上でもあまり公開されていません。本記事が、同じような課題を持つサーベイ設計者の参考になれば幸いです。
SPACE フレームワークとは
SPACEフレームワークは、2021年に『LeanとDevOpsの科学』の著者であるNicole Forsgren氏が、GitHubやMicrosoftのチームなどと共に提唱した、開発者および開発チームの生産性や体験を多角的に評価するための指標群です。
単一のメトリクスでは捉えきれない「開発者体験」を、最低3つ以上の項目をバランスよく観測することを推奨されています。
| 頭文字 | 視点 | 具体例 |
|---|---|---|
| S | Satisfaction & well-being | 仕事 / ツール / 文化への満足度、個人の健康 |
| P | Performance | SLI/SLO、顧客満足度、機能利用率 |
| A | Activity | アウトプット量、サイクルタイム、継続的インテグレーションの実現、インシデント量 |
| C | Communication & Collaboration | 協働のしやすさ、ドキュメントや知識の検索性、オンボーディングの時間と質、レビューの質 |
| E | Efficiency & Flow | フロー状態の維持、会議時間 |
SPACE はこれらを複合的に観測することで、偏りなく開発者体験を可視化できる点が特徴です。
サーベイ設計
SmartHRでは以下の設計でサーベイを実施しています。
- 頻度: 半期 (4月 / 10月)を目安
- 回答者: エンジニア
- スケール: 7段階リッカート尺度 (1 = まったくそう思わない, 7 = とてもそう思う)
- 所要時間: 5〜10 分
設問とスコア一覧 ─ 2025年4月の測定結果
PerformanceとActivityの項目はサーベイ以外で集計することとし、その他3つの項目をサーベイの設問にしています。
また、追加でAIについての設問を含めています。
※設問の内容はあくまで一例としてご認識ください
ここでは全体の平均スコアを出力していますが、部やチームごとのスコアでも集計しているため、各チームごとの傾向も把握することができています。
| SPACE | メトリック名 | 設問（サーベイ設問文） | 2025年4月スコア |
|---|---|---|---|
| Satisfaction & well-being | やりがい・満足度 | 所属チーム内での仕事にオーナーシップを感じている | 5.79 |
| Satisfaction & well-being | やりがい・満足度 | 所属チーム内での自分の役割や仕事にやりがいを感じている | 5.59 |
| Satisfaction & well-being | やりがい・満足度 | 所属チームや組織からの自分への期待値は理解できている | 5.75 |
| Satisfaction & well-being | やりがい・満足度 | 所属チームは自分のキャリアを伸ばすのに適した場所である | 5.27 |
| Satisfaction & well-being | やりがい・満足度 | 所属チームのミッションや方針はわかりやすく、納得している | 5.81 |
| Satisfaction & well-being | やりがい・満足度 | 友人に SmartHR に入って開発することを勧める | 5.56 |
| Satisfaction & well-being | ツールの充足度 | 所属チームの開発環境に満足している | 5.04 |
| Satisfaction & well-being | ツールの充足度 | 所属チームの CI/CD 環境に満足している | 4.36 |
| Satisfaction & well-being | ツールの充足度 | 会社から提供される機材は充実しており、十分な性能を備えている | 6.05 |
| Satisfaction & well-being | ツールの充足度 | 開発に必要なツールは、自ら選択できる、または会社から提供される | 5.92 |
| Performance | コード品質 | —（サーベイ外で集計） | — |
| Performance | 顧客満足度 | —（サーベイ外で集計） | — |
| Performance | 機能利用率 | —（サーベイ外で集計） | — |
| Performance | SLI/SLO | —（サーベイ外で集計） | — |
| Activity | four keys | —（サーベイ外で集計） | — |
| Activity | サイクルタイム | —（サーベイ外で集計） | — |
| Activity | PR 数 | —（サーベイ外で集計） | — |
| Activity | PR サイズ | —（サーベイ外で集計） | — |
| Activity | デスク対応の時間 | —（サーベイ外で集計） | — |
| Communication & collaboration | ドキュメントの網羅性・検索性 | よい仕事をするための情報（ドキュメント・ドメイン知識 etc）はいつでも簡単に得ることができる | 4.45 |
| Communication & collaboration | ドキュメントの網羅性・検索性 | 設計や仕様、コードにおける意思決定の背景は後からでも理解できる | 4.01 |
| Communication & collaboration | レビュー | コードレビューの質や指摘方法は健全だ | 5.27 |
| Communication & collaboration | 心理的安全性 | 会議中や Slack など、自分の発言は否定されずに受け入れられている | 6.15 |
| Communication & collaboration | 心理的安全性 | たとえ耳の痛い話であってもメンバーとのコミュニケーションは円滑に取ることができる | 5.89 |
| Communication & collaboration | フォロワーシップ | 技術的な質問をすると、迅速に回答を受けることができる | 5.83 |
| Communication & collaboration | オンボーディング | 新メンバーのオンボーディングにかかる時間は妥当と感じる | 4.99 |
| Communication & collaboration | 見えない仕事 | 開発以外のタスクは特定のメンバーに偏らず、均等にメンバーで対応できている | 4.32 |
| Communication & collaboration | 他部署とのコミュニケーション | 業務上、やりとりすべき他部署がわかり、問題なくコラボレーションすることができる | 4.69 |
| Efficiency & flow | MTG の数と時間 | 会議の時間は適切で、開発時間を確保できている | 4.75 |
| Efficiency & flow | フロー状態 | 予期しないタスクや要求をほとんど受けず、途切れることなく継続的に開発に集中できる | 4.20 |
| Efficiency & flow | CI/CD の時間 | テスト環境としての CI は十分に整えられており、テスト結果を迅速に確認できる | 4.23 |
| Efficiency & flow | CI/CD の失敗率 | デプロイやインフラ監視の精神的・身体的負担は最小限である | 4.47 |
| Efficiency & flow | CI/CD の失敗率 | 自動テストは安定しており、flaky なテストが少ない or あったとしても隔離されている | 3.91 |
| Efficiency & flow | 新規開発とバグフィックスのバランス | —（サーベイ外で集計） | — |
| (追加) AI について | AI ツール満足度 | 現在利用している AI ツールに満足している | 4.56 |
| (追加) AI について | AI 活用推奨度 | チーム内で AI を業務に活用することが推奨されている | 5.20 |
| (追加) AI について | AI 効果実感 | AI を活用することで業務の生産性が向上していると感じる | 5.32 |
| (追加) AI について | AI 導入度 | AI ツールの導入が開発フローに適切に組み込まれていると感じる | 3.48 |
| (追加) AI について | AI 理解度 | AI ツールの適切な使い方を理解している | 3.61 |
| (追加) AI について | AI サポート充実度 | AI ツールを活用するための社内のサポート（トレーニングやドキュメントなど）が十分にある | 3.68 |
| (追加) AI について | AI ベストプラクティス共有度 | AI を活用した開発のベストプラクティスを共有する機会がある | 3.79 |
どこが強みで、どこが伸びしろか
スコア分布は整理すると以下のようになります。心理的安全性、会社やプロダクトのミッションやバリューへの共感が強いのはまさに SmartHR の強みであり、それが数値上でも表現されています。
CI/CDや会議時間の多さなどはチームによって濃淡ありつつも、全体的に課題としてスコアにも表れました。AI についても、効果性は認識されつつもまだサポートが足りていないという評価が下されました。
| 評価レベル | スコア範囲 | 代表的な項目 |
|---|---|---|
| 強み | 6.0以上 | 心理的安全性、機材充実度 |
| 高評価 | 5.5～5.9 | ミッション共感、リーダーシップ |
| 良好 | 5.0～5.4 | 開発環境、レビュー文化 |
| 改善検討 | 4.5～4.9 | ドキュメント、オンボーディング |
| 要改善 | 4.0～4.4 | CIテスト、会議時間 |
| 優先課題 | 3.9以下 | AI関連、flakyテスト |
サーベイ結果に影響した取り組みを抜粋
いくつかの項目は、2024年10月のサーベイ後に行った施策が、2025年4月のスコアに表れていました。
CI 環境改善
一部のプロダクトでは 2024 年に不安定（flaky）なテストの改善を行い、CIのエラー率を削減しました。
その結果、「テスト環境としてのCIは十分に整えられており、テスト結果を迅速に確認できる」のスコアは依然として平均より低いものの、改善傾向が見られています。
会議体の再設計
2024年10月のサーベイで「会議の時間は適切で、開発時間を確保できている」のスコアが約3.5と顕著に低かったチームでは、必要な会議に絞る・不要な会議を廃止するなどの活動を実施しました。
その結果、2025年4月のサーベイでは約4.4までスコアが向上し、全体の底上げにつながっています。
AI 活用の支援
AIツールの導入や活用に関しては、効果性は高いという実感がある一方で、サポートやナレッジ共有がまだ十分ではないという課題が浮き彫りになりました。
現在は、Cursor や Devin などのツール導入、知見のあるエンジニアによるリード、使い方のナレッジシェアの活性化など、組織としても模索しながら取り組みを進めています。
AIについては現在進行系で導入支援が行われているため、サーベイなどのスコアに表れてくるのは次回以降になりそうです。
AI 導入については、VPoE のsaitoryc による登壇資料が詳しいです。
まとめ： サーベイからの学び
SPACEフレームワークを使ったサーベイを2回実施してみて、いくつかの学びが得られました。
データで裏付けられた施策立案
「感覚」ではなく「数値」で課題や傾向を認識できたことで、CIの改善や会議体の再設計などが具体的に定性面でも効果があったのかを調べることができました。
組織の強みの再確認
心理的安全性の高さやミッション共感といった項目がスコアとしても裏付けられることで、組織の強みを再確認できました。
AI と従来開発の融合への道筋
効果実感（5.32）と実際のサポート（3.68）のギャップが明確になり改めて導入支援の必要性を理解できました。
未知の傾向発見へのチャレンジ
現在の内容は現状把握と施策検証という側面が強いですが、未知の傾向発見にもSPACEを活用できればと思います。
例えば、「マルチプロダクト戦略により、ほかチームとのコラボレーション機会が増えたが、協働する方法に課題が生まれている」や「新しいプロダクトを立ち上げた際のドメイン知識のキャッチアップが満足に行われていない」など、単なる「測定ツール」から「発見と変革のきっかけ」へと発展させていくことが次の課題です。
SPACEフレームワークに基づくサーベイは、組織の横断的な課題を認識するためのフックであり、個人が課題を理解し行動につなげるためのきっかけでもあります。開発組織の健康診断の一環として、より継続的に活用していく土台を作りたいと思っています。
We Are Hiring!
SmartHRでは一緒にプロダクトを作っていく方を募集しています！ 少しでも興味があれば、是非カジュアル面談のお申し込みからよろしくお願いします。
