Well-beingと生産性の関係性 - 指標にとらわれない心地よい環境づくりに参加してきた

developer-productivity-engineering.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

以下、イベントページから引用です。

会の様子

『「開発生産性を、もっと誇れる組織へ」という方針を9ヶ月前に掲げたCTOの振り返り』

最初にiCAREの工藤さんから話がありました。

開発生産性の向上は一過性の取り組みではないため、意志を支えていくために納得感が大切だと工藤さんは考えているということで、具体的にやってきた取り組みに関して説明がありました。

iCAREでは、会社のPurposeに従う形で健康管理クラウドを開発しているということですが、経営と開発組織の共通言語として開発組織のパフォーマンスを定義する必要があり、そこで工藤さんはどういう開発組織にしていきたいかを考え直したそうです。
その結果、開発者がたくさん成果を誇れるような組織にするために開発者体験が良い組織を作りたいという想いが出たそうで、これはiCAREが掲げているカンパニーケア(働く人々の世界を作る)との親和性もあると感じたそうです。
また、こういったロジックがあるからこそ工藤さんはいきいきと働くことができているということでした。

なぜを大切にしたことで、メンバーの納得感も高まり大手を振って改善ができるようになったということで、実際にツール上でも開発生産性が高まったことが実感できたというお話があり、今後はアウトカムベースでの成果測定もやっていきたいということでした。

Q&A(工藤さん)

発表後にはQ&Aがありました。以下、質問と回答を常体かつ記載していきます。

論理的には、「開発生産性」と「開発者体験」とは、相互に因果関係があるわけではない（開発生産性が高いほど開発者体験が高いとは限らない。開発者体験が高いほど開発者体験が高いとは限らない）と思うが、この差分をどう捉えどう扱うべきか？

時間軸の考え方が大切だと思っている。短期的に見るとメンバー負荷が高まり開発者体験が下がるかもしれないが、そこの体験の受け止め方を別の視点で捉えられると良い。

なぜ開発生産性向上に取り組むのかを設計できていたとして、それを他の経営メンバーや現場メンバーに納得してもらえないと進めにくいと思うが、納得してもらうために工夫したポイントはあるか？

経営メンバーは開発組織のパフォーマンスの良し悪しを同じ目線で持ちたいという課題認識があったので、そこを持てていたのがよかった。

メンバーに対しては、短期的にアウトプットを上げるというミスリードを避けたかったので、なぜこういう方針なのか？を丁寧に説明するようにした。

こうした想いはしつこいと思われるくらい伝えていくようにしていた。

経営層との共通言語を作ったとのことだが、Four Keysなどどのようにその重要性を理解してもらったか？

完璧か？というのはまだ課題がある。良くなっている悪くなっているは共通認識ができているが、自分たちの経営戦略とあっているのか？みたいな部分ではまだできていない部分もある。

ストレスチェックは、具体的にどんな内容なのか？（話せる範囲で教えてもらえたら）

厚生労働省が定めた質問を用いている。メンタルの状態や体調を捉えられるような話が57問定まっている。

Four Keys 以外でビジネス側に提示できて、開発側と共有できる指標を導き出す方法論はあるか？

エンジニアの工数も記録を取っているので、使いたいことに時間を使えているのか？とかは取ることを検討している。

方針を掲げたあと、毎日のチーム内の取り組みで意識したことや新しく始めたアクティビティなどはあるか？

定例でツールの画面を見たり、どういう課題感があるのかを各チームが見るようにした。

『Keeper of the Seven Keys ~Four Keysとあと3つ~』

次にカケハシのいくおさんから話がありました。

いくおさんは、PdM 3名、フルスタックエンジニア4名、デザイナー1名、EM1名で仕事をしており、新規事業開発をやっているため、不確実性が高い領域に取り組んでいるということでした。

そのため、高速に仮説検証ループを回そうとしているそうで、同時にツールでFour KeysとWevoxを取っているそうです。
また、これらはただ取るだけではなく取る理由が必要だと考えているため、健康診断的な活用方法をしているということでした。(数字に一喜一憂するのではなく数字が悪くなっている背景などを考える)

高速に仮説検証ループを回すために、EMとしてはチームを良い状態*1にしたいと考えているそうで、ツールで開発生産性をWatchすることで数値を見ながら何が起きているかを分析できるのが良いということでした。
分析する際には、予想をしてその予想と一致しているかが重要だということで、予想通りデプロイ頻度が落ちているのか予想外にデプロイ頻度が落ちているのかは大きく違うということです。
加えて、いくおさんは、EMはビジネスとエンジニアリングのカケハシになると考えているため、リファクタリングをはじめとした直接的に付加価値を生み出さない活動価値をエンジニア以外に理解してもらうために開発生産性の計測は役立っているそうです。

ただし、グッドハートの法則には注意する必要があり、何のための指標か？を大切にするのが大事だということでした。

また、Four Keysを補完するためにSPACEが機能するといくおさんは考えているそうで、実際にFour Keys + Satisfaction and well beingをいくおさんでは取得しているそうです。(Performanceはすでに取っているのと、Communication and collaborationはすでにうまくいっているので取らないことにした)
こうすることで、(医療の会社だからこそ)パフォーマンスが出ているけれど燃え尽きているのは避けたいと思っているそうです。

こうして測った数値ですが意図的に定例などでは見ていないそうで、どうありたいかという姿を大切に行動してその結果出てくる数値を見るようにしているそうです。

Q&A(いくおさん)

発表後にはQ&Aがありました。以下、質問と回答を常体かつ記載していきます。

カケハシさんは複数のプロダクトがあると思うが、プロダクト横断の部署の場合、SPACE指標の選定はチーム、プロダクト毎などどの単位で決めているか？

チームごと。

指標や数値で出しやすいことと出しにくいことがあると思うが、出しにくいことの拾い方はどうしているか？

非常に難しい質問だし良い質問だが、定性的にこうありたいという姿と定量的に数値をセットにするようにしている。

指標を見れないとメンバーが自分ごと化しづらいというイメージがあるが、指標自体は全メンバー見れるようにしているか？それともありたい姿だけを公開しているか？

オープン自体はしている。
ただ、定例など全員で必ず見る場みたいなものはない。

会全体を通した感想

開発生産性をどのように使っているのかという話のなかでどちらの発表も数値自体には大きく着目せずにその背景にあるなぜ？やありたい姿を大切にしているという話や、数値にフォーカスしにくいフォースを意図的に計測している話が、グッドハートの法則に陥らずに数値を活用する上でも重要なんだなというのを改めて実感しました。

*1:成果も出ているしエンゲージメントも上げたい