数値の意味づけや目標設定でメンバーの意識が変化。パーソルキャリアの全社的な開発生産性向上に向けた取り組みとは？
転職支援や求人メディアをはじめとした、幅広い人材サービスを展開するパーソルキャリア株式会社。エンジニア組織における個人の振り返りや組織の課題発見に、エンジニア組織支援クラウド「Findy Team+」を活用いただいています。
今回は、パーソルキャリアにて「Salaries（サラリーズ）」の開発に携わる、エンジニアの吉次さんにインタビュー。「Findy Team+」を活用し、開発生産性の可視化や目標設定にどのように取り組んできたかについて、お話をうかがいました。
目次
人事向けに報酬水準データを提供する「Salaries」を開発
――まず最初に、吉次さんのご経歴と現職でのロールを教えてください。
吉次：学生時代は、高専で情報電子工学を専攻し、音楽情報処理や自然言語処理を研究していました。2014年に新卒で株式会社ぐるなびに入社して、PHPのバックエンドエンジニアをしたり、ベンダーコントロールやプロジェクトマネジメントをしたりしていました。
その後、パーソルキャリアに入社してからは、フロントエンドからインフラまで、技術的には幅広くやってきています。2018年からは、新規サービス開発の部署に移り、現在は「Salaries」という人事向けの、マーケットに基づいた報酬水準データを提供するサービスの開発を行っています。
加えて、チーム横断での生産性向上に関する取り組みや、QAチームの立ち上げ・運営を行ったり、組織運営に関するところでは、評価などのマネジメントの仕事をしたりもしています。
――所属されている「Salaries」の開発チームの規模や体制を教えていただけますか？
吉次：2020年3月に立ち上がったチームで、現在は自分を含めてエンジニア6名です。体制は、各自いろいろな領域を担ってもらえるようにしていますが、メインの担当としては、フロントエンドが2人、バックエンドが2人、スクラムマスターが1人。私自身は、最近はあまりコードを書かず、全体を見るようにしています。
――チームでは、どのようなミッションを掲げられていますか？
吉次：サービス全体やプロダクトの戦略に沿った機能開発をしたり、戦略を考えるにあたって必要なデータのダッシュボードを整備したりといった、事業と関わりが大きい部分が基本的なミッションになっています。
新機能の開発以外の部分では、セキュリティやパフォーマンスの面で、ユーザーの方々により快適に使っていただけるように、改善を積み重ねていくこと。そして、開発速度が落ちないように定期的にリファクタするなど、技術的負債の返却を行っていくこともミッションになっています。
――チームのOKRやKPIとして、定量面や定性面で追っている指標はありますか？
吉次：時点ではOKRやKPIの粒度に落とし込んでいるわけではないのですが、チームとして開発生産性の目標を決めていて、前期に仮で定めたものを運用していました。その後、メンバーの入れ替わりなど、開発状況が変わってきた部分もあるので、今期また改めて適切な目標に見直し、引き続き運用していきます。
定量面は「Findy Team+」を使って、デプロイ頻度や変更障害率などの指標を追っています。定性面はさまざまありますが、OKRで定めているものとしては、少し抽象的ですが間接的にプロダクトの価値向上につながる部分ですね。
機械学習が絡むサブシステムにおける改善サイクルを回すための環境整備（いわゆるMLOps的なもの）であるとか、先ほど挙げた技術的負債の返却であるとか。信頼性の部分では、主要なAPIのパフォーマンス向上ですね。それから、品質の可視化や向上。今テストが手薄になっている部分のカバーや、自動テスト導入の拡大などが挙げられます。
――OKRも半期ごとに設定されているのでしょうか？
吉次：基本的には、半期ごとに見直して更新しています。前期とあまり変わらない場合もありますが、期ごとにプロダクト戦略も若干変わってくる部分があるので、そこに合わせている形ですね。そのほかには、開発において課題感の大きいものを組み込んでいます。
全社的にも動き始めた、開発生産性向上への取り組み
――開発生産性の計測について、どのような背景から取り組みを始められたのでしょうか？
吉次：新規サービスの開発を続けてきたなかで、企画やビジネスサイドとのコミュニケーションにおいては、スケジュールに間に合うかどうかというところが、大きな判断材料になっていました。ですが、それ以外にも、普段どういうクオリティで開発しているのか、開発チームの状況を定量的に示せるものが欲しいと思っていたことが背景にあります。
開発組織の生産性については、前々から取り組んだほうがいいだろうと感じていて、いろいろなところでもぼんやりとしたテーマとして存在していました。組織の外から見るとブラックボックスな部分が多く、それに関する声もさまざまな方面から上がっていたので、「Findy Team+」を利用してみることにしました。
――「Findy Team+」を知ったのは、どういったきっかけでしたか？
吉次：あまりくわしく覚えていないのですが、ツイートかプレスリリースを見て、たまたま知ったという経緯だったと思います。当時は、β版の先行利用が実施されていたので、まずはそれで試してみようと考えていました。
――「Findy Team+」を活用するうえで、現在どういったゴール設定をされていますか？
吉次：高い生産性を維持していくことと、それによって限られた期間で、より多くの機能や改善をお客様に届けることをゴールとしています。そのために、しっかりと定量的に開発生産性を把握し、目標値を決めて継続的に振り返りながら、改善サイクルをまわしています。 あとは、振り返りに関連するところで、レビューの偏りなどのボトルネックや、開発プロセス自体の課題を発見することも、中間ゴールとしてあると考えています。
――開発生産性に対する、全社的な目線での状況はいかがでしょうか？
吉次：全社的にも開発生産性に目を向けていこうと、動き始めている段階です。「Salaries」の開発チームは内製かつ6人なので、「Findy Team+」を活用しやすい環境ですが、社内の開発チームは体制も開発プロセスもさまざまです。
そのため、プロダクトやチームの特性に合わせて、それぞれのチームが「Findy Team+」を上手く活用できるように、社内の事例をどんどん増やしていきたいと考えています。
――吉次さんの「Findy Team+」を使った取り組みが、全社的な動きにつながっていったのでしょうか？
吉次：正確にはわからないですが、先ほどもお話したように、ぼんやりとした課題感はいろいろなところで、おそらくずっとあったと思うんですね。そうしたなかで、「Findy Team+ Award 2023」に選出いただいたりと、社内で活用している事例が出たことで、全社的な動きにつながっていった可能性はあると思います。
開発生産性の目標として設定している、4つの指標
――開発生産性の目標として、具体的に見ている指標を教えてください。
吉次：指標としては主に、DevOps分析のデプロイ頻度、変更障害率、平均修復時間の3つと、サイクルタイム分析のコミットからオープンまでの時間を見ています。そのほかには、レビュー分析でレビューの偏りなど細かなところを適宜見ています。
――これらの指標を目標に設定した背景についても教えていただけますか？
吉次：デプロイ頻度については、「Salaries」は月1回の定期リリースなので、開発ブランチにマージされた頻度を追って、開発スピードを把握しています。これに関しては、デフォルト設定ではメインブランチになっているところを、設定次第で変えられるようになったことが大きいです。
変更障害率や平均修復時間については、どれくらいの品質でリリースできているかをチェックするために見ています。この3つは、チームとして追っている目標ですね。 サイクルタイム分析については、4つの項目に分かれていますが、そのなかでもレビューを出した後の平均時間は定常的に早かったので、そこは今の状態をキープできれば問題ないと考えていました。
コミットからオープンまでの平均時間は、デプロイ頻度と絡めて見ています。チーム全体でのデプロイ頻度の目標に対して、自分がどの程度の時間で作業すれば達成されるのかイメージしづらいため、個人レベルに落とし込んだときの目安になる指標として置いています。
――これらの目標も、半期に1回のサイクルで見直しているのでしょうか？
吉次：今は始めたばかりなので、半期ではなく月ごとに見直しています。メンバーの増減があった場合や、兼務によって使える工数が変わった場合なども、適宜見直すべきだと考えています。
数字への意味づけや目標設定によって、理解を得られた
――パフォーマンスを数値化することに対して、メンバーが抵抗感を持つケースも耳にします。御社では、そういった部分はいかがでしたか？
吉次：私がいるチームでは、あまり個人の数字は追っておらず、あくまでもチームの目標として定めています。チームへの貢献の仕方はさまざまで、プルリクの数やイシューの消化数に表れない部分もあるからです。
チームとしては、目標値を定める前からある程度は数字を追っていたのですが、抵抗感というよりは、「その数字が良いのかどうか、どう解釈すればいいかわからない」といった感じでしたね。意味づけができていないまま、ただ数字を出すだけではダメだということがわかりました。
なので、しっかり言語化したうえで目標設定をして、その数字がどういう意味で、一般的な水準はどれくらいなのかを伝えるようにしました。そうすることで、自分たちのパフォーマンスが良いのかを実感として持てるようになり、理解を得られたのかなと思います。
――チームに指標や目標をより浸透させるために、工夫したことがあれば教えてください。
吉次：もともと「Findy Team+」の導入前から、月1でリリース後の振り返りを行っていて、当時は生産性というよりは、主にコミュニケーションにおける課題を見ていました。
例えば、プルリクのコメント返答率やコミュニケーション相関図を見て、レビューが偏っていないかを確認したりとか。それから、マージクローズ時間やコメント分量の分布を見て、時間がかかっていたりコメントが多かったりするものを取り出して、その要因を見直してみたりとかですね。
その後は、先ほどお話ししたように、数字を出しただけで何となく見ていた状態があったのですが、目標設定をしてからは、どの数字を狙っていくべきなのかが見えるようになってきました。
それらの目標値に対して、どうすれば達成できるかを考えていくなかで、わかりやすい例では、プルリクやイシューを分割したりしていくうちに、徐々にコントロールできるようになっていったと思います。
あとは、数字ではありませんが、月1の振り返り以外にもSlackの通知機能を使って、プルリクが放置されないように、日常業務のなかで見落としが起きづらくする仕組みも整えました。そうしたことを通しても、できるだけチームメンバーの意識が向くようにしています。
――見るべき数字に関して、これまでチームメンバーから意見が出たことはありますか？
吉次：プルリクの変更行数は、常に同じ基準では見られない部分があり、そういった課題が話に上がることはありますね。テストコードがたくさん含まれていたり、ライブラリのアップデートで一括置換を行ったりすると、変更行数が上下してしまうためです。
変更行数は、レビューにあたって効率にも品質にも関わってくる部分なので、上手く基準値を持ちたいと思っていますが、変更行数自体にどれくらい意味があるのかについては、まだはっきりとは見えていないところがあります。
目標設定によって変化を感じた、チームメンバーの意識
――開発生産性を計測し、目標設定を行ったことによって、どのようなベネフィットを感じられましたか？
吉次：やはりチームのコンディションを自分たちで、数字で示せる状況になったことが挙げられます。数字ではっきりわかるようになると、悪くなったら改善して、良くなったら継続すればいいので、次のアクションについての判断がしやすくなったと思います。
――取り組みを通じた、チームメンバーの意識や行動の変化についてはいかがでしょうか？
吉次：何か課題があったときに、「仕方ないよね」で片付けることが減って、ブレイクダウンして原因を探ることができるようになったと思います。目標を設定したことで、課題を発見しやすくなり、アプローチを考えやすくなったところは、成果の1つかなと思いますね。
プルリクのサイズに関しても、どういった単位で実装を分けるか、メンバーのなかで意識が高まってきました。お互いにレビューし合うので、レビュアの立場からみたときに、どうプルリクが分かれていれば助かるかという意識が浸透してきて、細かいことを伝えなくても自走できるようになってきたように感じます。
――先ほど、データの意味づけが難しかったというお話がありましたが、そのほかにも苦戦したことはありましたか？
吉次：「Findy Team+」の導入初期に課題になっていたのは、ノイズが入ってしまうところです。例えば少し特殊なプルリクが含まれるなどの、少数の要因によって、全体の数字が上下してしまう課題が長らくありました。なので、まずノイズを除去して、肌感と合う数字を取れる状態にするのが、「Findy Team+」を使ううえでの最初のハードルだったと思います。
そのあたりは、プロダクトの成長とともに解消されてきた部分もあって、例えばラベルの除外や絞り込み機能などがそうですね。あとは、GitHub側でのラベル運用の仕方や、botを含めるかどうかなど、そういったところを1つずつ解決していったので、活用の下地が整うまでに少し時間がかかりました。 それができると、トントン拍子に進んでいく感覚がありますが、その次に課題になるのは目標設定。他のチームを見ていても、目標をどう設定すればいいかわからない、という壁にぶつかることが多いように思います。
「Salaries」のチームはコントロールしやすいチーム体制でしたが、社内には業務委託やオフショアを含むチームもあります。そういうチームでは、パートナーさんが作る部分と内製で作る部分でレビューのプロセスが違ったりするので、なかなか同じ条件で全部を見ることができません。 そうした場合は、プロセスを見直したり、分析を分けたりする工夫が必要になるので、ハードルになる部分かなと。そこが整って、ようやく改善のサイクルが見えるようになると思っています。
全体を俯瞰した、より多角的な生産性可視化を目指したい
――今後のトライとして、考えていることがあれば教えてください。
吉次：まずはやはり、社内のさまざまなチームでの「Findy Team+」の活用ですね。ある程度のパターンをつくって、それぞれのチーム体制や開発プロセスに合わせた活用ができるようにしていきたいです。
また、「Findy Team+」では基本的に実装に関わる部分のみが可視化されるので、実装を伴わない開発者のタスクも、他のツールを組み合わせるなどして、複合的に見れるようにしていきたいと思っています。 それから、定量的な部分だけでなく、定性面もですね。先日の「Findy Team+ Award 2023」で、SPACEというフレームワークを活用した例が紹介されていて、ぜひ参考にしたいと思いました。そういったものを活かしながら、より多角的な生産性の可視化を目指したいと考えています。
――実装を伴わない開発者のタスクというと、例えばどのような内容ですか？
吉次：今いるチームでよくあるのは、ダッシュボード系のタスクです。アクセスログを集計して、各KPIの達成状況を出しているものなのですが、プロダクトの機能追加ではないため、プルリクを作ったりコードを書いたりする行動は伴いません。
現状だと、ダッシュボード系のタスクが増えたとき、「Findy Team+」上のデプロイ頻度などは下がります。でも、それは数字が下がったからといって、良くないという意味になるわけではありません。 そういった部分を、イシュー管理のところで計測できるようにして、複合的に「Findy Team+」と合わせて見ていきたい。今も見れる状況ではあるのですが、もっと整理して、全体を俯瞰して見れるようにしていきたいです。
――イシュー管理には、どのようなツールを使っていますか？
吉次：チームによって異なりますが、新規サービス系のチームではZenHubが多く使われていて、そこではベロシティを合わせて見ることができます。
――定性面については、どのような内容をカバーしていきたいと考えていますか？
吉次：まだ勉強中なのですが、SPACEで言う「satisfaction and well being」のところで、実装はしていないけれど貢献しているという部分が結構あると思っていて。実装担当ではない他のメンバーのアドバイスがあって上手くいったとか、実装の判断に必要な材料を持ってきてくれたとか、そういうGiverの動きが何かしらの形で可視化できるといいなと思っています。
――それでは最後に、組織のアピールポイントや一緒に働きたいエンジニア像を教えてください。
パーソルキャリアでは「はたらく」に関わる様々なサービスを展開しています。
生産性の文脈では今回1つの事例を紹介しましたが、会社全体としても課題意識を持って取り組もうとしている最中なので、工夫しがいのあるとてもおもしろいフェーズです。
パーソルキャリが掲げる『人々に「はたらく」を自分のものにする力を』というミッションや自らが携わるサービスが目指す世界観に共感し、世の中や組織の課題に目を向け、前向きに解決・改善まで一緒に取り組めるエンジニアの方と一緒に働けると嬉しいな、と思っています。
――吉次さん、ありがとうございました！
※パーソルキャリアでは、『人々に「はたらく」を自分のものにする力を』のミッションのもと、ものづくりを通してユーザに価値を届けることに興味のあるエンジニアを募集しています。 https://jobs.persol-career.co.jp/
※「Findy Team+」のサービス詳細は、以下よりご覧いただけます。 https://findy-team.io/service_introduction
