開発チームの変化を加速させるためには？　“生産性指標の可視化”でエンジニアのパフォーマンスを向上

生産性の指標を可視化して、開発チームの改善を加速させた事例を発表

司会者：続きまして、株式会社はてな、大仲能史さま。ファインディ株式会社、内田博咲也さまのご講演です。それでは、どうぞよろしくお願いいたします。

内田博咲也氏（以下、内田）：よろしくお願いいたします。本日は、ご参加いただきましてありがとうございます。後ろのブースにもありますが、ファインディでは「Findy Team+」という、開発生産性を可視化し、開発プロセスのボトルネックを発見して、向上を実現するサービスを提供しています。

本日は、Findy Team+をご利用いただいている、はてなの大仲さんから「生産指標を可視化して開発チームの改善を加速させる」というテーマを、Team+にも触れながらお話しいただけるということなので、ぜひお楽しみいただければと思います。よろしくお願いします。

大仲能史氏（以下、大仲）：それでは、はてなの大仲から発表いたします。まず自己紹介ですね。大仲といいます。ふだんインターネット上では「id:onk」という、この3文字のIDで活動しています。株式会社はてなのチーフエンジニアをやっていて、今日は京都から参りました。

今日の話ですが、「生産性の指標を可視化して、開発チームの改善を加速させる」というタイトルで発表します。

もともと2週間ごとのイテレーティブな開発をしていました。イテレーティブに開発しているので、ふりかえりでチームに変化を持ち込むということを日常的にやっていたのですが、生産性指標を取得するようにしたら変化速度が加速したので、この事例をお話ししたいと思っています。

バリューストリームマップで課題を見つけて解消

というわけで、（スライドを示して）このようなアジェンダでお話ししていきます。まずは、開発チームの改善。ふだん僕らがどんなことを改善していたのかという話から入ります。

次に、イテレーティブな開発をしているので、イテレーションで変化をしているのですが、その一部を紹介します。バリューストリームマップの課題を見つけてそれを解消した話、モブプログラミング、WIP（Work In Progress）制限をした話などをいたします。

まず、バリューストリームマップで課題を見つけて解消した話ですね。バリューストリームマップというのは、なにか企画が立ち上がってから、それがリリースされるまでに起きる出来事をそれぞれマップ、図にしてみる。そこでかかっている時間とか、誰に渡すのかみたいな、コミュニケーションの様子を計測してみようといったものです。

バリューストリームマップを作成すると、リリースするまでにどこで時間がかかっているのかが如実にわかるツールです。

実際に描いてみたところ、CIが遅いであったり、デプロイが遅い、コミュニケーションが多くてリリースまでに時間がかかっている場所があるというのが、わかりやすくなりましたので、それぞれ対策をしていきました。

CI改善については、テストを並列化したり、フレーキーなテストがあって、落ちたらリトライしてまた「10分待つ」みたいなものがあったので、不安定なテストを安定化させたりしました。

また、コミット内容に関係ないテストケースをスキップするようにもしました。例えば、フロントエンドのコードだけの変更だった時は、バックエンドのテストをする必要がないよね、ということでフロントエンドだけのテストをするようにしました。これらをやることで、10分ぐらいかかっていたCIの速度が5分未満とすごく速くなって、リリースするまでの時間や試行錯誤するまでの時間が早くなります。

デプロイの改善については、CI/CDフロー、特にCDフローを実施しました。継続的なデプロイをどのように行うのかをすべて変更しました。2チーム、3チームぐらいで変更したので、そこから全社標準という基準にして、全社的にこれに合わせていこうねという動きに取り組んでいます。

この時の着目点は、フローの中に人間を挟まないプロセスにすることでした。「リリースするので確認をお願いします」と確認をお願いして、その確認のオーケーが来てからビルド作業を始める場合、その確認待ちの間は本当に作業ができずに待つ時間になるんですね。

なので、ビルドして、オーケーが出たらもう即座にリリースできるような、なるべく人間が介在しない、人間が介在しなくてもプロセスが進むプロセスフローに修正しました。

モブプログラミング導入

続いて、モブプログラミングです。ここに関しては、まず、チームに新入社員が配属されていて、人間同士の知識に差が出ている。差が出ているせいで経験不足からプロダクトバックログの消化の速度が上がらない。

さらには、十分にサブタスクに分解しているはずですが、このサブタスクのタイトルを見ても、「どこをどう変更したらこれがリリースできるのかな？」みたいなことがわからないという状況が生まれていました。

この時は、4人中2人が新しい人間になっていました。解決策として、チームのみんなで同じ画面を見ながら作業するという、モブプログラミングの手法を採りました。2人ずつのペアプロではなく、4人みんなでモブプロをやりました。2人が新入社員だったので、2人の間に知識の差が出るのを避けるために、4人全員でやっています。

題材としては、まず、既知の不具合の修正をみんなでやって、そこでファイルの場所や変更の仕方に慣れてから、実現の仕方がまだわかっていないプロジェクトのタスクをこなしていく、という流れでやっています。

4人でモブプロにすると、コードを書くのは一度に1人になってしまうので、ベロシティとしてはすごく下がるんですよね。ですが、チームのメンバーが替わったという変化によってベロシティが変化するのは当然なので、ベロシティが下がるのは認めます。

そのため、「この後はベロシティを上げるのが目的ですよ」と掲げて、「その意識を持ってモブプログラミングをやってください」とやりました。

WIP制限で作業の透明性を担保

続いて、WIP制限ですね。これもよくある手法だとは思いますが、もともと1人1施策を持っていて、並行に進めている状況でした。こういう状況だと、ちょっとした相談がすごくしにくい、自分とは違うタスクをほかの人が持っていて、知識展開もしにくい。自分が見つけたことを誰かに伝えても、すごく驚いてくれたりはしにくい。

タスクも1人で持っていると、それ以上きれいにサブタスクに分解できなかったりするので、タスクの状況の透明性も不足していく。WIPがどんどん溜まっていって、リソース効率としては100パーセントなんですが、「リリースしていくフロー効率を考えると、ここには問題があるね」みたいな課題がありました。

ここの解決にあたっては、チームの中で2人組、3人組というユニットを作って、このユニットの単位でタスクをアサインするというふうに変えました。このユニット内の進め方は、ユニットにお任せで、全体としてはあまり管理していなかったです。ですが、「毎日会話してくださいね」というのは、伝えていました。

これによって、ユニットの「Slack」チャンネルが生まれたり、「Google Meet」をずっとつなぎっぱなしで会話したりというのも生まれました。それに慣れてきたら、朝会、昼会、夕会だけという感じになりました。

1人1タスクからユニットにタスクをアサインすることは、いい効果が多かったんです。タスクをしっかり分解するようになる。2人でタスクを分担しなきゃいけなくなるので、2人で作業をする。

すると、そこでタスクを分解し出したり、2人の中で認識をそろえるために会話をしたりするので、その相談内容がログとしてWikiにまとまっていって、作業の透明性がどんどん増していきます。2人で同じタスクにあたっているとコンテキストが共有されるので、コードレビューする時も難易度が下がっているという状況が生まれます。

なので、チームとしてチームの人数の開発ライン数を持っているのではなく、ライン数を下げてWIPを制限するというかたちで進めました。

ほかにも、チームの課題はいろいろあります。よくありがちなものをたくさん挙げています。

キックオフをしたけれど認識がそろっていなくて途中で手戻りが発生する。昼会がなぜか長い。Developer Experience、開発環境の改善系のタスクがぜんぜん消化されない。障害対応があったり、ふりかえりがあったり、ふりかえりが多すぎてタスクの作業時間が取れないなど、いろいろな問題が発生します。これらに関しては、イテレーションごとにふりかえりをして、課題として挙げて、Tryとしてチーム課題に対して変化を入れるというのを日々やってきています。

生産性指標を取得して開発チームのパフォーマンスを可視化

次に、生産性指標を取得する、ですね。『LeanとDevOpsの科学』という本に生産性の指標が載っているのですが、Four Keysというものがあります。

これはDORA、DevOps Research and AssessmentというGoogleのチームが、何万チームか、何万人かに聞いた結果として、「生産性にはこういう指標が関係しているよね」「ここに強い相関があるよね」というのをまとめてくれたものです。

デプロイ頻度、リードタイム、サービス復旧時間、変更失敗率。Four Keysと言われていますが、5つ目として信頼性が2021年から挙げられています。

このFour Keysは強い相関があるらしいので、これを取得しておくといいんじゃないかと考えました。

我々の期待としては、「開発チームのパフォーマンスを可視化したい」ですね。いろいろなチーム改善を日々入れ続けているという話をしましたが、このチーム改善が中長期的に本当に貢献しているのかを確認したかった。「これで良くなったよ」というのを感覚で言い合うのではなく、きちんとデータドリブンで、誰にとっていいのかだけではなく、お互いきちんと数字で見えるようにする。

数字にすることによって個人間でも比較できるし、チームの間でも比較できる。そういう比較できる指標を手に入れるというのが、生産性指標を取得する上での期待でした。

データドリブン。これはAmazonのジェフ・ベゾスの発言ですが、「意見で決めるんだったら、私の意見が常に勝つ。しかし、データは意見に勝つ。だからデータを持ってこい」というように、権威勾配を超えることができるのはやはりデータです。

生産性向上、個人目標設定に「Findy Team+」を活用

Four keysのうち、まず我々はデプロイ頻度を取得するようにしました。これは、ほかの指標と比べて機械的に簡単に取得できたからです。我々はデプロイトリガーを、Branchのマージをトリガーにしてデプロイしたり、タグをつけることによってデプロイしたりしていたので、これらのイベントを取得するだけで、いつデプロイしたのかを簡単にプロットすることができました。

これによって、毎日のデプロイ回数をグラフにしたものが（スライドを示して）こちらです。チームごとに、デプロイ回数は倍、半分ぐらい差があるのが見えるかなと思います。

これらを取ってチームの改善に使い始めたあたりで、Findy Team+を見つけました。自分たちでいくつかFour keysを取り始めたのですが、Findy Team+は、すべての数字が取れるんですね。「GitHub」上でのあらゆる行動がログになって、数字になって出てきます。

このGitHub上の数字をいろいろ手に入れると、生産性以外、例えばチーム運営にもすごく便利です。これは個人間のムラの解消や目標設定に役立てることもできています。

よく、レビュアーが一部の人に偏っているが、この偏りが感覚でしかわからないというのがあると思います。「たぶんあなたの3倍ぐらいレビューしていると思うんだけど」みたいな。プルリクが飛んできたら5分ぐらいでレビューしている人、1日置いてからレビューを返す人、みたいにいろいろいますが、こういうレビュー速度の差がきちんと見える化されます。これによって、「チームの中では最優先でレビューしようね」というのを標語化することができるようになりました。

あと、ジュニアエンジニアに対しては、プルリクエストに対して50個とかコメントがつくことがあると思うのですが、こういうのもきちんと数字で取れるし、半期ごとの平均値なども取れるので、「あなたは来期までにコメント数を減らして一発でマージできるようになる。これを目指しましょうね」みたいなかたちで目標設定しやすくなりました。

（次回へつづく）