2022年12月22日に開催されたCTOmeetupのテーマは、「開発生産性指標の可視化とその先」です。開発現場において、生産性やパフォーマンスの向上は重要なミッションであり、どのような指標に注目して改善をすればいいのか、模索している企業も多いでしょう。

そこで今回は、エンジニア組織の生産性を評価する「Findy Team+ Award 2022」で表彰された、アンドパッド社の外山さん、星野リゾート社の藤井さん、2名にご登壇いただきました。

開発生産性指標可視化のために「Findy Team+」を導入している両社がそもそも可視化に踏み切った背景や、フォーカスしている指標、具体的な改善アクションの内容などについて、たっぷりお伺いしました。

開発生産性指標を可視化する

生産性指標が可視化される前の状態

藤井氏：
まずは、生産性指標が可視化される前にどんな課題があったのかをお伺いできますか？

外山氏：
アンドパッドでは私が入社した時点で既に「Findy Team+」を活用して生産性指標の可視化を行っていたので、ここでは前職の経験を踏まえてお話しします。

まず、ビジネスサイドも開発サイドも、課題に対する目線合わせの難しさは感じていました。なかなか定量的な話ができず感覚的なレベル感に違いが生まれ、ボトルネックが見えにくくなっていました。

藤井氏：
私たちの場合は、最初のうちは私ががっつり組織に入ってアドバイスや改善ができていたのですが、組織が拡大するにつれて忙しくなり、チームが見えなくなっていたのが課題でした。細かい課題もある中で、「推測するな、計測せよ」という言葉はすごく大事ですね。

生産性指標が可視化される以前に、何かしていたことはありますか？

外山氏：
前職の場合はGitHubでログを見たりはしていましたが、何かツールを使った可視化はしていませんでしたね。

生産性指標の可視化を始める

藤井氏：
生産性指標可視化のために、「Findy Team+」を導入した背景についても教えていただけますか？

外山氏：
当社のVPoEが生産性指標の可視化にかなり力を入れていて、初期段階からFindy社と協働し、欲しい機能などについて営業担当者の方と二人三脚で議論していたと聞いています。

藤井氏：
星野リゾートはサービスのリリース直後にツールを導入しましたが、アンドパッドさんはそれ以前から導入していたそうですね。アンドパッドさんにはそういう、自由に面白いことを実験する文化があるんですか？

外山氏：
そういうケースは多いですね。

藤井氏：
すごいですね。星野リゾートの場合は私が導入を決めました。ちょうど開発組織を内製化して、メンバーが10名を超えた頃でした。

当時から生産性や進捗の可視化はしていましたし、スクラム開発だったのでベロシティも測っていたのですが、進捗もベロシティも誤魔化しが効いてしまうんですよね。例えばタスクを大きく見積もれば、ベロシティは大きく見えてしまいますし。

きちんと可視化をすれば効果があるとわかっていたものの、現状では少し足りないと思っていたときに「Findy Team+」でコードの活動の可視化ができると知り、面白そうだと思って導入しました。以下は私がよく見ている指標の例です。

藤井氏：
棒グラフはプルリクの回数で、折れ線グラフはプルリクのクローズの時間です。例えば左のほうを見ると、全くクローズしていませんし、コミットの総数が少ないからプルリクも出ていないという状態を可視化できています。このほかにも人単位や、人と期間、チームを横串で見た比較なども可能です。

開発生産性指標を活用する

可視化する指標に相関がある中での改善の優先順位づけ

藤井氏：
実際に生産性指標が可視化されるようになって、まずは何に注目されましたか？

外山氏：
前提として、我々の場合はカスタマーエクスペリエンスとの連携を重視していて、デプロイのタイミングをコントロールしています。そのため生産性を測る際にデプロイ頻度を見ると、ほかの要素が混ざってしまう部分が強くて。それでも開発スピードは見ていきたいということで、変更のリードタイムに着目しました。

変更のリードタイムといっても、プルリクを作ってからマージされるまでにはいくつかのプロセスが挟まりますから、それぞれを細分化しています。

藤井氏：
バリューストリームマッピングの開発版を作っている感じですよね。

私たちはむしろデプロイ頻度を見ています。これまでデプロイは自由にできていたのですが、もっと早くリリースできるはずのプロジェクトが頻繁に止まる感覚があったため、改善点をみんなで考えていきました。

可視化した生産性指標をもとに取った具体アクション

藤井氏：
具体的に開発生産性指標をもとにどんなアクションをしたのか、具体的なお話も伺いたいと思います。

外山氏：
チームによって傾向が違うので、以下では1つのチームの例を挙げてみました。

外山氏：
まずプルリク作成からレビューまでの平均時間を、12時間以内にするという目標を持ちました。

プルリクからリリースまでのボトルネックについてチームで相談したところ、プルリクを出してからレビューまでの時間が長めだったからです。プルリクを出してからその結果が出てくるまでの待ち時間やスイッチングのコストをなるべく下げようという意図もありました。

またレビューの心理的ハードルを下げるため、なるべく小さなプルリクにしたり、チーム内でのレビューの優先度も上げていったりしようと話し合いました。

藤井氏：
同じような活動をしているので共感できます。プルリクはどうしても大きくなりますよね。

外山氏：
なるべく続けて作業をしたい心理があるんですかね。

藤井氏：
私たちもプルリク作成からリリースまでに10日かかっていたので、これをまずは3日に短縮しようとしました。

アンドパッドさんよりも状況はよくなくて、プルリクを作っても放置されていたんですよね。なぜかとエンジニアに聞くと、「プルリクが上がったことがわからない」と言われて。プルリクの連絡は、担当者が自分で伝えている状態だったんです。それならSlackで自動的に通知をしようということになりました。

あとは、しっかり時間を決めて必ずレビューをするようにもしましたね。優先度を高くするのはすごく重要です。担当者は自分の開発のほうが優先だから、レビューがボトルネックになると思っていないんです。

外山氏：
確かに弊社でも、時間を決めてレビューをしているチームはありますね。

藤井氏：
レビューを早くすることが結果的に価値を生むし、それでチームが良くなるのだと話しました。
あとはクローズするときにPO（プロダクトオーナー）の承認を得るフローになっていたのですが、POのチェックの予定を1週間に1回しか入れていなくて、ずっと待っているような状況もありました。そこで、終わったらいつでもすぐにPOを呼んでいいと言いました。

またタスクを小さくすることによって、それ単体ではリリースしても無駄な機能もたくさん生まれますが、そういうものでも一緒にレビューをするようにしましたね。可視化をしないと意外にこういう部分がわかりません。ツールで可視化を自動化するのがこんなに良いことなのだと、やってみて実感しました。

そのほかに、チームではなく個人単位でのアクションはありますか？

外山氏：
レビューとコードを書くコミットのバランスは見ていますね。キャリアとして次のステップに進む場合、レビューの頻度やボリュームは重くしていく必要があるだろうという話がありました。

藤井氏：
それは弊社にもありますね。最初はチーム全員でレビューしようとしていたのですが、まだまだスキルが足りずにコードが書けない人がレビュー6割、コード2割だったりして。まずはコードを書いてどんどんプルリクして、フィードバックを受けてスキルアップをしないと、レビューなんてできないよなと。

私が一緒にプロジェクトに入っていてもメンバーの時間の使い方はわからなかったため、可視化して良かったです。

外山氏：
ハイパフォーマーのパフォーマンスは比較的安定していると思いますが、これが新しいことをやってもらったときにどれぐらい落ちるのかも確認していました。無理があったのか、次のステップに行けているのかを判断する指標としての使い方ですね。

藤井氏：
可視化されるとすぐに施策の結果が見えて安心しますよね。当然数値が下がることもありますが、それがどれぐらい下がっているのか、逆に新たな取り組みによってどれぐらい上がったのかを見るのは、すごく重要なポイントです。

アクションをもとに最初に着目した指標との相関で注目している指標例

藤井氏：
そのほかに注目している指標はありますか？

外山氏：
やはりタスクのサイズ感は、なるべく小さくするよう意識していますね。

藤井氏：
開発中に不足部分が出てきたら、タスクを新規に作りますか？

外山氏：
サイズ感にもよりますが、極力新規のタスクとして切り分けて、ゴールは変えないようにしています。

藤井氏：
そのときに重要なのが、デプロイの効率性ですよね。そのプロセスが重いと、タスクを小さくするのは勇気がいると思います。

アンドパッドさんは生産性が高いですし、テスト周りは全部自動化されているんですか？

外山氏：
できていないところはありますけどね。タスクを小さくするのと並行して、テストは増やしました。タスクを小さくしても品質を保てるという、心理的安全性や自信はあるかもしれません。

藤井氏：
自信を持つのは重要ですね。メンバーからも最初はタスクを増やすことへの抵抗がありましたから。

私たちの場合、生産性指標の可視化活動とベロシティがどれぐらい関わるのかも結構見ていました。一定の指標で作ったベロシティなら相関が取りやすくて、面白いですよ。メンバーも「もっとやろう」という雰囲気になってきて、モチベーションが上がりました。

外山氏：
良いサイクルが回っていますね。

藤井氏：
エンジニア採用が激化している中で、エンジニアにとっての気持ち良い環境はすごく重要だと思うんです。星野リゾートは質素倹約をモットーとした普通のオフィス環境なので、その分開発環境の構築や仕事の面白さの創出には工夫して取り組むのが重要なのかなと。

外山氏：
デベロッパーエクスペリエンスですね。

藤井氏：
生産性の可視化について表彰を受けましたが、個人的な感覚として、10年後はどの企業も当たり前にやっていていいことだと思っています。その先を行きたいと常に考えていますね。

指標を元にマネジメントを続けて起こった変化

藤井氏：
ここからは、生産性指標の可視化にまつわる活動を続けてどういう変化が起きたのかについて、具体的に話していきたいと思います。実際にやってみていかがでしたか？

外山氏：
まずレビューのリードタイムは減りました。プルリクのサイズも実際小さくなりましたね。あとはチームで取り組む意識がつきやすくなったのかなと思います。

藤井氏：
これは実際にどのように見ていたんですか？

外山氏：
レトロスペクティブとかで見るようにしていますね。

藤井氏：
それは私たちもやっています。やはりみんなで見て話し合うのはすごく重要ですよね。自分たちとは違う視点で見てくれていたりして、すごく面白いです。

我々もプルリクが大体2～3倍になりましたし、リードタイムが1週間から2～3日にまで短くなりました。これだけ点数が良くなっていくと楽しくてチーム全体として生産性が高まりましたし、モチベーションがかなり上がったと感じます。

外山氏：
数値が見えて成果が出ると楽しくなりますよね。

藤井氏：
「もっと早くできないのか」という抽象的な要望が数字になることで、メンバーにとってもわかりやすくなったのがポイントですね。

より生産性の高い組織を目指して今後取り組んでいきたいこと

藤井氏：
ここまでのお話も踏まえて、今後生産性の高い組織を目指してやっていきたいことは何かありますか？

外山氏：
生産性は開発プロセスに閉じた話のほかにも、ユーザーにどれだけ価値を届けられているのか、あるいは事業として上手くいっているのかといった、さまざまなスコープで考えられると思います。どれも事業の成功をゴールにすべきだとは思いますが、事業規模が大きくなってくると開発の生産性以外の要素も当然含まれます。そうなると、開発に関しては開発プロセスに寄った指標でゴールを見る必要があるんですよね。

一方で新規プロダクトなんかに関してはノイズとなる要素が入りづらいので、もう少し視野を広げて開発チームの生産性を見てもいいのかもしれません。フェーズを踏まえた見方をしていけるといいなと考えています。

スライドにある開発チームの資産や負債を指標化するというのは、開発の活動に関する指標と捉えているFour Keysや生産性指標とは別に、積み重ねていく開発チームの資産的なものを数値として取れればいいなと考えています。どんな経験を得てどんなメンバーが入り、どんな開発能力があった上で負債が存在しているのかを指標化したいなと。

最後に、開発チームのエンゲージメントも見ていきたいと思っています。生産性は無理をすれば上がりますが、それでは長く続きませんから。これらの3つをしっかり見つつ、生産性を高めていきたいです。

藤井氏：
星野リゾートが今後実施したいのは、まずチーム横断での生産性の評価です。チームが増えてきて全体が見えづらくなってきた中でも、どのチームにどれぐらいの生産性や負債があるのか、原因までしっかりと評価をして、どの程度のリソースを投入したらどの程度のアウトプットが出るのか、数字として知りたいと思っています。

もう一つは品質の分析ですね。レガシーなシステムだと品質が良くないプロジェクトも存在しますし、例えばフロントエンドのテストコードがないといった原因と指標を比べて、どの程度生産性が下がり、また変更失敗率が上がるのかを数値化していきたいです。

あとは開発横断組織の立ち上げです。私たちは横断的な部分がまだまだ弱く、例えば私なら生産性の可視化の方法の教示、フロントエンドの人なら身に付けるべきスキルセットに関する教育をする必要があります。あとは70名のエンジニア組織のうち、40名ほどはホテルの現場出身の方が異動してきているので、ITが何かを教える仕組みもきっちり作っていかなければいけません。

Q&A

1on1のときに意識する生産性指標は？

Q.このような生産性指標は1on1の材料として有用だなと思うのですが、お二人が意識していることや見ているポイントはありますか？

外山氏：
1on1のときも生産性指標は使っています。どちらかというと健康診断的に、「ここが下がっているけど、何か困っているの？」と聞くことが多いですね。

藤井氏：
気になる指標も見ますよね。「ちょっとレビューの割合多すぎない？」とか。

外山氏：
コメントからプルリクまでの時間も見ます。何かボトルネックが起きているのだろうかと気にしますし。あとはレビューのコメントもチェックします。

藤井氏：
私はどの時間にコミットしているかも確認します。終業間際にコミットする人には、もっと早い方がいいよと話しますね。終業間際だとレビューが翌日になってサイクルがすごく悪くなるんです。

横断チームで異なる指標を見るメンバーがいた場合の対応は？

Q.横断するチームを構成する場合、これまでのプロジェクトで注目していた指標とは違った指標を見るメンバーもいると思います。この場合メンバーへの取り扱いはどうでしょうか？

藤井氏：
違う指標を見るメンバーがいたら、話し合えばいいのではないでしょうか。ある意味チャンスだと思います。自分たちが見ていたものでは足りていなかったかもしれませんしね。そのプロジェクトの事情にもよると思いますし、過去の歴史を紐解く機会にもなるでしょう。

アンドパッドさんに横断チームはあるのでしょうか？

外山氏：
プロダクトを跨いでいるプラットフォームのようなチームがあるので、そこは各プロダクトで使ってもらう性質がありますね。あとはCREやSREチームは横断で見てもらっています。藤井さんはどんな横断チームを作ろうとしているんですか？

藤井氏：
プラットフォーム的なチームと、あとは教育をするチームかなと思います。SREもそのうち作りたいですね。

まとめ

Four Keysなど相関関係にある生産性指標をどのように改善していくか。エンジニア組織の開発生産性が高いと評価されたアンドパッド様、星野リゾート様の取り組み事例からヒントは得られましたか？

素早く安定的にデリバリーするため、そしてエンジニア組織の健康状態を図るためにも、まずは小さく気になる指標から可視化して生産性の高い組織を目指していきましょう。

LINEでフリーランスの案件情報や最新Tipsを受け取る