開発者のウェルビーイングは測れるのか――12指標のカタログと、測られる側の受容条件
2026.09.08 / Donut Service
自分の集中時間は毎日測っています。測ること自体に抵抗はありません。ところが「その数字を会社が見る」と言われた瞬間に、急に嫌になる。同じ数字なのに、です。
この非対称を扱った研究が2026年5月に公開されました。Arriel らによる「Understanding developer well-being」（Empirical Software Engineering, 31巻6号, 記事番号153）です。開発者のメンタルヘルスと生産性を同じカタログに並べる12の指標を設計し、現場の開発者47名に評価してもらった研究で、オープンアクセスなので数値も定義も原典で確かめられます。
結論を先に書きます。要旨の最後の一文は「開発者はカタログの価値をおおむね認めた一方、これらの指標が職場の評価メカニズムとして位置づけられたとき、抵抗が生じた」です。測定の成否を分けたのは「何を測るか」ではなく「誰が何のために見るか」でした。
なお BrainSync は測るプロダクトを持つ側です。だからこそ「測定はよいものだ」に寄せずに書きます。
1. 監視の効果は、思ったより小さく、思ったより正当化しにくい
先に土台を確認します。職場の電子的モニタリングにはすでにメタ解析があります。Siegel らは70の独立標本・233の効果量を集約し、電子的モニタリングは職務満足をわずかに下げ（r = −0.10）、ストレスをわずかに上げる（r = .11）と報告しました。
数字としては小さい。「監視は人を壊す」という強い主張は、少なくともこのメタ解析からは出てきません。ただし同じ論文は、モニタリングを導入する最大の理由であるはずの業績について、関連が見つからなかったと書いています（r = −0.01）。反生産的行動とはわずかな正の関連（r = 0.09）。さらに調整分析では、業績目標とフィードバックを伴う場合に負の影響が強まる可能性が示されました。
つまり「測ると伸びる」も「測ると壊れる」も、証拠としては強くない。残るのは、何のために測るのかという設計の問題です。Arriel らの研究が面白いのは、そこを開発者に直接聞いた点にあります。
2. 12指標のカタログとは何か
設計は3フェーズです。まず文献のマッピング。検索で241本を取得し、重複除去後に178本、要旨のレビューを経て65本を精読、そこから土台となる二次研究5本を選定して、生産性やメンタルヘルスに影響する99の要因を洗い出しています。
次に4名の専門家が、この99要因を4カテゴリ——個人のメンタルヘルス（IMH）、チームのメンタルヘルス（TMH）、個人の生産性（IP）、チームの生産性（TP）——に分類しました。生産性が個人とチームに分かれている点は、後で効いてきます。そのうえで上位の要因から12指標を選定しています。
ここは正確に書いておきます。指標を選ぶ投票を行ったのは経験のある実務者3名ですが、原著が明記するとおり、この3名は本論文の共著者であり、心理学の専門家でもありません。役割は構成概念の理論的検証ではなく、実務上の妥当性・明確さ・適用可能性の評価だと自ら断っています。独立した外部評価ではない、と読むのが正しい。
全部は並べきれないので、性格の違う4つだけ挙げます。
- SVI（自己認識）：毎日、自分の生産性を1〜10で自己採点する
- WVI（自己と周囲のずれ）：WVI =（自己評価 − チームからの評価）× 10。原著は ±20% を目安の帯として示しています
- MTA（滞留タスク）：24時間更新のない仕掛かり中タスクの割合
- ABS（欠席）：欠勤日数ではなく、直前のリスケジュールや理由の曖昧な欠席が、約束された予定に占める割合
従来型の指標も3つ（作業容量・コミット数・解決イシュー数）そのまま残されています。なお指標はカテゴリと1対1で対応するわけではなく、複数カテゴリにまたがるものもあります。
3. 受容が反転する瞬間
調査の設計が巧妙です。各指標について2つのことを別々に聞いています。「この測り方は適切か」と「この指標を生産性やメンタルヘルスの評価に使うのは有用か」。
前者への反応は良好でした。原著は全体として12指標のうち10個が65%超の肯定評価を得て、MTA のように80%以上の承認率に達した指標もあったと書いています。測定そのものが拒否されたわけではない。
ところが後者、「評価に使う」と位置づけた途端に、はっきりした不快感が現れます。原著によれば、コミット数では応用面の受容が、測定方法としての承認に比べて60%以上も低下しました。ある参加者は、そこに見える数字は仕事の質を反映していないかもしれず、小さな更新までもが数え込まれていると指摘しています。
同じ指標が、改善のための材料としてなら受け入れられ、評価のための材料としてなら拒まれる。ここが本研究の芯です。そして評価に使われると分かった指標は、防衛的な回答を誘発し、指標としての価値を失っていきます。AIコーディングで負荷の質が変わった話を前に書きましたが、そこでの「何を測れば実態を捉えられるか」という問いも、「誰がそれを見るか」を決めなければ答えが定まりません。
4. QSI——AIが会話を感情分類するという指標
カタログの中で最も強い抵抗を受けたのが QSI（社会的相互作用の質）です。定義は明快で、ネガティブなメッセージ数を全メッセージ数で割った割合。データ源として Slack、Discord、Jira、Trello、GitHub、GitLab、Zoom、Google Meet が挙げられ、判定には AI による感情分類を使います。
参加者の懸念は3つに分かれました。ひとつはプライバシー。「Teams や Slack の私的なメッセージをロボットが読むのは、従業員のプライバシーの侵害に感じる」という声が挙がっています。ふたつめは監視による行動変化。「監視されていると分かるのは従業員にとって良いことではないし、率直なやりとりを妨げうる」「職場では自分の精神状態は見せない」。そして著者らが「おそらく最も意外な発見」と書くのが3つめ、AI の判定能力への疑いです。皮肉やユーモアや感情の機微をテキストから正しく読み取れるのか、という疑問です。
原著自身もこの限界を認めています。皮肉、文脈の曖昧さ、言語差、バイアス。だからこそ QSI は「個人の行動の確定的な評価ではなく、チームレベルの示唆的なシグナル」として解釈すべきだと書かれています。
この但し書きは重要ですが、脆くもあります。集計の粒度は運用側がいつでも変えられるからです。同じことは TVI にも言えて、こちらはメンバー同士が日次で互いの生産性を採点する設計です。カタログを紹介するときに、この転用のしやすさに触れずに「こんな指標がある」とだけ並べるのは、たぶん不誠実です。
5. これはまだ提案であって、実証ではない
限界をまとめておきます。
参加者は47名、うち22名がインタビューにも参加しました。募集は著者らの人脈からのスノーボールサンプリングで、質問紙は英語版とポルトガル語版が用意されています。著者自身が外的妥当性の脅威として、特定の業種や地域が過小に代表されている可能性を明記しています。
最も大きい留保はこれです。このカタログは、まだ実際の組織に導入されていません。評価されたのは知覚された有用性・解釈可能性・導入可能性であって、効果ではない。実地検証は今後の課題で、パイロット→拡張→継続的改善という3段階のロードマップが置かれている段階です。指標間の因果関係を描いた図も仮説であり、原著は一貫して「〜すると期待される」「〜に影響しうる」という言い方で書いています。「効果が実証された測定法」と読み替えてはいけません。
なお、指標の上下より先に気にすべきことがあります。強い疲労感や気分の落ち込みが数週間単位で続いている場合は、職場の工夫だけで抱え込まず、医療機関や相談窓口の利用を検討してください。バーンアウトの定義と3要素については別の記事で整理しています。
6. まとめ——自分で測ることと、測られることは別物
- 開発者47名の評価では、12指標中10個が65%超の肯定を得た。測定そのものが拒まれたわけではない
- 同じ指標を「評価に使う」と位置づけた途端に受容は反転する。コミット数では60%以上の低下
- QSI（会話のAI感情分類）は最も強い抵抗を受けた。原著自身がチームレベルの示唆的シグナルに留めるよう求めている
- このカタログは実組織に未導入。評価されたのは知覚された有用性であって効果ではない
- 電子的モニタリングのメタ解析でも、業績との関連は見つかっていない（r = −0.01）
自分で測るのは平気なのに会社に測られるのは嫌だ——この非対称は、わがままではなく、目的の違いに対する妥当な反応でした。自己モニタリングには別の研究系譜があり、Meyer らは開発者413名の調査と43名の3週間のフィールド調査から、職場での設計指針をまとめています。そこでの目的は一貫して、本人の気づきと振り返りです。脳疲労を可視化する拡張を作った話も、動機はそこにありました。
原著が示す運用指針も同じ方向を向いています。レトロスペクティブで会話の起点として出すこと。可能な限りチーム単位で集計すること。「これは示唆であって決定ではない」と明言すること。「生産性が落ちましたね」ではなく「この指標は作業量や関わり方の変化を示しています。あなたのスプリントの実感とどれくらい合っていますか」と聞くこと。そして数値を定性的な文脈と必ず併せて読むこと。
測る道具を作っている側として、線を引いておきます。自分のために測るのは、自由です。他人を測るのは、設計です。
BrainSync Focus Timer のご紹介
自分のために測るところから始めるなら、道具は軽いほうがいい。私たち Donut Service が開発した BrainSync Focus Timer は、VS Code・Cursor のステータスバーに常駐するタイマーで、25/5（ポモドーロ）と52/17（ロングブロック）を切り替えながら使えます。記録は手元に残るだけで、どこにも送られません。
休憩のタイミングを自動で知らせるポモドーロタイマー。無料でインストールできます。
BrainSync Focus Timer をインストールする →Cursor をお使いの場合は Open VSX 版 をご利用ください。
※ 効果には個人差があります。本記事は医療助言ではありません。
BrainSync — ソフトウェアエンジニアの心と脳を、やさしく整える。
ドーナツサービス · 東京
参考文献
- Arriel, J., Canuto, T., Azevedo, J., Lima, M. V., Mann, P., Garcia, A., & Pereira, J. A. (2026). Understanding developer well-being: measuring mental health and productivity in software teams. Empirical Software Engineering, 31(6), 記事番号153. DOI: 10.1007/s10664-026-10830-6
- Siegel, R., König, C. J., & Lazar, V. (2022). The impact of electronic monitoring on employees’ job satisfaction, stress, performance, and counterproductive work behavior: A meta-analysis. Computers in Human Behavior Reports, 8, 100227.
- Meyer, A. N., Murphy, G. C., Zimmermann, T., & Fritz, T. (2017). Design Recommendations for Self-Monitoring in the Workplace: Studies in Software Development. Proceedings of the ACM on Human-Computer Interaction, 1(CSCW), 1–24.
