エンジニアの「生産性」を、どのように測れば良いのだろうか？

2014年に創業し、建設・建築現場で使えるクラウド型のプロジェクト管理サービス「ANDPAD」を提供する株式会社アンドパッド。

2020年には合計約60億円の資金調達を行い、2022年4月時点でおよそ600名の従業員を有するなど、急成長を続けている。

同社のアカウント基盤チームでは、エンジニアのパフォーマンスを解析するSaaS「Findy Teams」を活用し、組織の生産性を可視化。チームの課題を特定した上で複数の施策を実施した結果、「平均プルリクエスト クローズ時間」の指標が、120時間から23時間ほどに激減したという。

この取り組みの中心となったテックリードの柴﨑 優季さんは、改善を行うにあたり「指標だけではなくチームの観察からボトルネックを特定する」「敢えて大きな課題から取り組まない」「自分一人がチームを変えるのではなく、チーム全体で変える」といったことを意識していたという。

また一方で柴﨑さんは、「エンジニアの生産性は、生産サイクルのスピードだけに着目するべきではない。顧客に価値を提供できているか、ビジネスとして成り立っているか、という視点も必要」と話す。

実際に現在は、生産サイクルとチームのエンゲージメントスコアのバランスを見ながら、継続的に顧客価値を提供し続けるためのチームづくりに挑戦している。また、より高い視点から、開発組織全体としての改善にも取り組もうとしているそうだ。

今回は柴﨑さんに、そもそもエンジニアにとっての生産性とは何か？ をお聞きした上で、アカウント基盤チームにおける生産サイクルの改善の具体的な取り組みについてお話を伺った。

開発の生産性 ＝ 生産サイクルがうまく回っているか だけではない

僕は2021年10月に株式会社アンドパッドに入社し、今はアカウント基盤チームのテックリードを務めています。

アンドパッドの開発組織には現在100名以上が所属していますが、その中でアカウント基盤チームは、主に認証部分やユーザー側の基盤を整えて、ほかのチームを助ける役割を担っています。

▼アカウント基盤チーム テックリード 柴﨑 優季さん

僕は、個人的に開発組織の生産性改善にとても興味があって。前職のはてなでも、チーフエンジニアとして、生産性の可視化や、組織面・技術面の双方における生産性改善に取り組んでいました。

ただ、「開発の生産性」というと、色々なものがごっちゃになって話されがちなんですよね。僕としては、以下のように大まかに三つにカテゴライズできると考えています。

まず、生産サイクルがうまく回っているか。要するに、すごいスピードで開発できているか、ということ。

そこからもう少し視座を高めると、その開発自体が本当に顧客に価値を届けているか、ということ。これは、プロダクトマネジメントを含めての生産性ですね。

そしてさらにもう1ステップ先にいくと、そもそもその事業がうまくいっていて、ビジネスとして成り立っているかどうか、ということがあります。

エンジニア視点で生産性を考えると、生産サイクルの部分だけを見がちなのですが、少なくとも生産性をリードする人は、この三つの観点を持たなければまずいと思っています。

実際、最近では「ビルドトラップ」と呼ばれていたりもしますが、生産サイクルはめちゃくちゃ回っていて機能開発は進んでいるけれども、全く顧客価値を生んでいない…ということって「あるある」なんです。

それぞれの観点で、見るべき指標も異なります。事業がうまくいっているか、という一番大きい観点に立つと、「メンバー1人当たりの売上」といったものになりますし、顧客価値を作れているかという観点では、「サービスのKPIやKGIに開発が貢献できているか」といったものになります。

一方で、生産サイクルに関しては色々な指標があるのですが、よく話題になるのが「Four Keys（※）」という指標です。

▼Googleが提唱した開発パフォーマンスの指標「Four Keys」（※こちらを参照し編集部が作成）

このように、生産性と言ってもさまざまな観点がありますので、生産性の向上を推進している人、もしくはチームのリーダーを務めている人は、それを意識しながら改善を進めていく必要があると思っています。

定量的な指標とチームの観察を通じて、最初に着手する課題を特定

とは言え、実際に生産性を改善するときに「じゃあ何から着手するか？」を考えると、開発全体を眺めたときに一番課題があるところから始めることが効果が高そうですよね。

でも、一番課題が大きいところって、実はその解決がめちゃくちゃ難しいことも多いんです。

例えば「開発が本当に顧客の方を向いているか？」という課題を解決しようとすると、まずそのチームがやったことの顧客価値を定量化する必要がありますし、チームが顧客に対して積極的にヒアリングできているか、といった調査もしなければいけません。

まだチームの熟練度が足りていないときにそうした課題を解決しようとしても、レベル1でラスボスに立ち向かう、みたいな話で（笑）、何もできないことも多いです。

そうなると、まずはレベル上げと言いますか、自分たちだけでできることから始める方が進めやすい。そこで、僕がアカウント基盤チームに来てまず取り組んだのが、生産サイクルの改善でした。

具体的には、先ほどご紹介したFour Keysの中の「変更のリードタイム」という、コミットしてからそれがリリースされるまでの時間に関連する指標から見ていこうと考えました。

基本的にFour Keysは4つすべて見ることが重要ではあるのですが、初めから全部やろうとすると何も進まないので、まずはすでに社内に導入されていた「Findy Teams」で可視化されているものから着手した形です。

▼開発チームの生産性に関するさまざまな指標を見ることができる「Findy Teams」

具体的には、Findy Teams上の「プルリクエストのクローズ時間」を見ていました。これはプルリクエストが作成されてからマージされるまでの平均時間ですが、Four Keysの変更のリードタイムの中に含まれる数字になるので、これを見るようにしていました。

さらに、プルリクエストのクローズ時間の中でもより分解した色々な指標が見られるので、それらを見ながら課題がありそうなところに当たりをつけていきました。

ただ、指標だけを見ても、具体的な課題が何なのかを特定することは難しいので、併せてチームを観察することも意識していました。

というのも、例えばTOEICのような指標であれば、「リーディングスキルがこのくらいです」と明確にわかるので、何をすればスコアが良くなるのかすぐにわかりますよね。ですが生産性やエンゲージメントになると、特定の指標が低いからと言ってすぐに課題が特定できるわけではありません。

実際に起こっている課題は、チームを観察してみなければわからない。そしてその結果、最初に見つかったのが「何でもかんでもやりすぎている」という課題でした。

色々な人から色々な話が来る状況の中で、何でも「とりあえずやろう」となりすぎていて、最重要の課題に取り組めていないな、と気がついたんです。

現在進行中のタスクが大量にあると、ひとつのタスクが終わらないまま次のタスクに着手する…という形になってしまい、1個のタスクが完了するまでの時間が長くなってしまいます。実際にFindy Teams上でも、プルリクエストのクローズ時間が長いという結果も出ていました。

まずはこの状況を改善するために、具体的な施策を進めていきました。

プルリクエストのクローズ時間は120→23時間に。副次的な効果も

実際に行った施策は大きく三つです。まず一つ目は、「やるものとやらないものを決める」ためのメンテナンスガイドラインの策定で、これが一番インパクトが大きかったと思います。

ガイドラインの内容は、「やる」「やらない」「やるかどうか判断を入れる」という基準で考えましょう、それは影響範囲とクリティカル度、工数の三軸で判断しましょう、というものです。

加えて事例集として、「影響範囲が限定されており、かつ運用でカバーできるものはやらない」「脆弱性等のインシデントレベルの不具合は即座にやる」といった具体的なケースが記載してあります。

そしてスプリントプランニングの際に、この基準に照らし合わせてどのタスクをやるか、やらないかを決めていきます。

エンジニアがやりがちなのが、一番「気になる」タスクを優先してしまうことです。例えば、1年に1回ほどの頻度で起こる、とある条件を通るとデータが壊れる、というケースがあったとして、「データが壊れる」と言われるとどうしても「やらないと」という気持ちになるんですよ。

ですがガイドラインがあることで、一旦引いてみて「それって年に何回起こるんだっけ？ 優先するべきなんだっけ？」という話ができるようになりました。

それから二つ目が、プルリクエストが作られてからすぐにレビューに取り掛かれるような通知の仕組みを作ること。そして三つ目が、エンジニア同士のペアを決めて「毎日1時間はペアプロしましょう」と推奨することで、一人でずっと悩んで止まっている状態をなくすことでした。

こうした取り組みによって、定量的な意味では、プルリクエストのクローズ時間の平均が120時間から23時間まで激減しました。

また、ガイドラインを作ったことによる副次的な効果として「敢えて放置できるようになった」というマインド面の変化があったことがとても大きいと思っています。加えて、一つひとつのプルリクエストが小さくなったことで、生産サイクルが速く回るようになった体感もあります。

「プルリクエストを投げればすぐマージされる」と感じていれば、1行コードを書いたら解決するような問題であればすぐにプルリクエストを投げるんですよ。逆に、プルリクエストを投げても1日待たされるような状況だと、「じゃあ、気になっている別のものも入れとこう」という気持ちになるんですよね。

そうすると、さらにレビューも遅くなるし、実際にユーザーに価値を提供できるまでの時間も長くなってしまう。レビューを高速化することによって、小さいプルリクエストが増えて、顧客に速く価値を届けられる…という良い循環が回るようになったかなと思ってます。

「チームを改善する人」にはならない。チーム全体の変化を大切に

こうしたチームの改善を実施する上で、大切にしていることが三つあります。一つ目は、「どのくらい変化を受け入れてもらえるチームか」を先に観察することです。

変化を許容しやすいチームにはどんどん提案していけば良いのですが、逆に、受け入れられないチームに急に変化を促すと反発が起きてしまいます。まずは、ちょっとした提案をしてみて、どのくらいならいけそうかな？ とチームの反応を見ながら対処するようにしています。

幸いなことに、アンドパッドの場合は組織が急拡大していることもあり、変化に対して抵抗があるメンバーはほとんどいなくて。「とりあえずやってみよう」という雰囲気があったので、第一段階としては大丈夫そうだなと感じました。

▼株式会社アンドパッドのオフィスの様子

次に、小さい変化を通して自分に対しての信頼度を高める、ということです。先ほど具体的な施策として、ガイドライン、すぐにレビューに取りかかれる仕組み、ペア制度の三つを挙げましたが、実は最初に取り組んだのはすぐにレビューに取りかかるための通知の実装なんです。

これはすぐにできますし、通知されたところですごく困る人もいないので。まずは小さいところから改善して、成果が出ることを見せる。そういった積み重ねを意識しています。

そして最後が、「チームを改善する人」にはならない、ということです。

チーム改善＝マネージャーがやるもの、となってしまうのがよくあるアンチパターンなんですよね。本来は、ある人だけが改善提案をするのではなく、色々な視点でみんなから提案があって、どんどんチームが変わっていくことがあるべき姿だと思っていて。

つまり、自分がひたすら変化を促すだけだとダメで、他の人も含めてチーム全体の意識を変えていく必要があります。そのために、自分の意見だけではなく他の人の提案も同じようにやってみる、自分から変化を起こすときもきちんと提案を作って合意を得る、といったことを意識しています。

「自分がチームを変えている」のではなく、「チームに変化のやり方をインストールしていく」「チームで変えている」という感覚で改善を進めていますね。

持続的に価値を提供し続けるチームであるために、重要なこととは

このように、これまでは生産サイクルに注力して改善をしてきましたが、一方ではそれだけに目を向けすぎると短期的にチームが燃え尽きてしまう、という問題もあります。

Findy Teamsで見られるような指標って、頑張れば短期間でもすごく向上させることができるんです。要するにめっちゃ働けば、一時的にはプルリクエストのクローズ時間もめっちゃ短くなるじゃないですか（笑）。

ですが、やはりチームが持続的に価値を提供し続けられなかったら、いくらスピードがあっても意味がないんですよね。そこで今は、チームとしてのバランスをうまく取るために、Wevoxというツールを使ってメンバーのエンゲージメントスコアも見ながら改善するようにしています。

また、これからは生産サイクルだけではなく、開発が顧客価値を作れているか、ということもきちんと見ていきたいですね。

これは自分のチームだけではなく、開発組織全体で高めていくことを考えていきたいなと思っていて。まだ明確な課題は見つかっていないので、まずはそのボトルネックを特定するところからやってきたいと思っています。（了）