ファインディの「開発生産性カンファレンス ~After Findy Team+ Award 2023~」でパネルディスカッションをしました
はじめに
こんにちは、株式会社モリサワ システム開発部門の小室です。
この度、ファインディ様の「開発生産性Conference ~After Findy Team+ Award 2023~」に登壇しましたので、その内容を報告をいたします。
登壇に至るまでの経緯
DevOpsの推進からFindy Team+導入まで
弊社ではDevOpsの推進から、Four Keysのデプロイ頻度を開発部門のKPIとして設定するにいたりました。
その中で、プルリクの数を増やしていけばデプロイ頻度が増えるのではないかという仮説を立て、プルリク数をチームのKPIとし計測を開始しました。
当初はbotを自作して計測していたのですが、現在はFindy Team+を利用しております。
このときのお話は「夏の開発生産性LT Week」で発表しており、ファインディ様にてまとめて頂きましたので、よろしければご覧ください。
その後、ありがたいことにファインディ様からインタビューもしていただけました。
インタビュー記事はこちらになります。
Findy Team+ Award受賞
Findy Team+を導入したので、「Findy Team+ Award」へ応募しました。
弊社ではデプロイ頻度を増やすために、プルリクがマージされるまでの速度にも注意を払っております。
スピード感を持って開発サイクルを回さないと、結果的にデプロイ頻度を増やすのは難しいだろうと考え、プルリク数を増やすためにもレビューからマージ速度をできるだけ早くするように心がけました。
その結果が実り、過去1年でレビューリードタイムが速いチームに送られる"Quick Review Devision"を受賞することができました。
この受賞を機に、ファインディ様からのご依頼をいただき、本イベントに登壇することになりました。
パネルディスカッション 『開発生産性向上に向けた定量的なチーム目標設定のメリット』
パネルディスカッションは、GO株式会社バックオフィス基盤部副部長の待鳥様と一緒に行いました。
私の発表部分を抜粋してお伝えします。
チーム体制と開発生産性の定義
まず始めにプロダクトチームの体制の紹介と、開発生産性の定義を紹介しました。
弊社ではプロダクトごとにチームを編成しており、プロダクトの中にはさらに職能型のチームが存在します。
この職能型チームの単位でプルリク数をKPIとして設定して計測しております。
チーム毎のプルリク数の調整について
チームにプルリク数は設定されますが、チームごとに調整はしております。
チームの人数に依存する形で「1人1日1プルリク」が目安となっております。
ただし、チームの状況に合わせて調整を行っており、プロパー以外のメンバーには係数をかけて少し少なめにしております。
プルリク数の計測については、純粋にプルリクの数を数えることにしております。
プルリクは課題をベースとし作成を行いますが、プルリク数を増やすハックをするのは自由とかかげております。
プルリク数を増やすには課題を分割する必要があり、結果的にレビューアーの負担も減るというメリットがあります。
この施策を行った結果、非効率で意味のないプルリクが増えることはありませんでした。
今後の開発生産性へのトライ
最後に未来に向けての取り組みについてお話しました。
現在はプロダクト内にチームが存在しますが、プロダクト横断できるチームになりマトリックス型の組織になることを目指しております。
また、SREについても取り組んでおりますが専任のチームが存在せず、バックエンドエンジニアが片手間に行っている状況です。この状況を改善し、専任のSREチームを作りSREの考え方をプロダクトチームに浸透させることを目指しております。
最後に、当初の目標となるFour Keysのデプロイ頻度を増やしリリース数を向上させ、お客様に早くたくさんの価値を届けることを目指しております。
さいごに
今回のイベントでは、弊社システム開発部門の開発生産性への取り組みを紹介させていただきました。
プルリク数を増やすハックをするのは自由という部分が特に受けていただけたようで、イベント後にも多くの方から質問をいただきました。
このお話は、以前Findy Team+の調査中に参加したファインディ様のイベントで話されてた方がおり、私も衝撃を受けて内容を参考にさせていただきました。
この取り組みの結果、毎週スプリントを回し週1回のデプロイ頻度でリリースを行うことができております。
まだまだ改善すべき点はありますが、今後も開発生産性の向上に向けて取り組んでいきたいと思います。
さいごに、ファインディ様にはこのような貴重な機会をいただき、誠にありがとうございました。
登壇時に答えられなかった質問（追記）
時間の関係上答えられなかった質問について回答します。
PRを指標にすることに、反対勢力もあったと思いますがどうすすめてきたのですか？（手段より目的が大事とか、上から強制されるものじゃないとか）
PR数に絞るとなった時に経営層やメンバーからなぜその指標と突っ込まれると思いますが、どう説明責任を果たしましたか？
他の指標ではなくプルリク数を目標にした理由はありますか？
開発者の開発生産性を測るPRを指標にしました。開発部門としてはリリース数をKGIに置いているのですが、その中でPR数を増やしていけばリリース数も増えるという仮説を立てました。弊社ではテレワークを導入したのですが、テレワーク環境では一人ひとりの作業状況の可視化を何らかの形でする必要があります。開発者たるものコードを書くのが主業務であるため、1日1PRを目標とすることにより、わかりやすい形で開発者の生産性を可視化できると考えました。テレワークを続けたいという開発者の思惑と、開発者の生産性を可視化したいというマネージャの思惑も一致するため、まずはPR数を指標にすることになりました。
レビューを偏った一部の人からチーム単位にすることで、レビューの質の問題はでませんでしたか？
レビューワーの偏りなど、レビューに対する課題はありましたか？
内容が簡単なPRではチームの誰かがレビューをすればすぐに進めることができる状況です。Findy Team+は1on1でも活用しているので、そこでのフィードバックなどもあわせて行います。複数人でレビューすべき内容であれば、GitHub上でのコミュニケーションを促すことにより、参加者を増やすようにしています。
レビュー1人承認でマージの場合、情報の非対称が起きませんか？どのようにケアしているか教えて下さい
課題とGitHubを見ることによりキャッチアップできるようにしております。また、GitHubのレビュー内容はSlackへ通知し、すぐに確認しやすい状況を作っております。
レビューをチームで行なっているとおっしゃっていましたが、チームは分野のエンジニアが所属しているのでしょうか？例:1チームがフロント+バック+インフラで構成される
エンジニアのメイン業務（バックエンドやフロントエンドなど）を元にチームを構成しております。一部のリーダークラスのエンジニアは、複数チームに所属することはあります。
目標(メトリクス)はチーム間で比較されるのでしょうか？ハレーションがないか心配しました。
全てのチームの情報は見えるようにし、チーム毎に目標を定めます。過去の実績を元に、目標値をリーダーが全員集まって調整することにより、ハレーションを防いでおります。
どのようなPR数のハックがありましたか？
プロジェクト立ち上げ期などは、VSCodeのプラグイン設定やlintツールなどの導入など、環境整備を細かに調整して、PR数を増やすハックがありました。
定期的にKPiが達成できているかPR数を振り返ると仰っていましたが、課題が見えた時はどういった改善アクションに繋げていますか？
PR数を増やすためにやろうとしていること（課題の分割など）ができているかどうか、メンバーで確認や意識合わせを行っております。また、協力会社との開発では、この辺りが見えにくくなるので見通しが良くなるように気をつけるようにしております。
目標設定はどのレイヤーのマネージャー陣で話し合って決めていますか？
弊社では人員リソースを管理するリソースマネージャ(≒課長)がいるため、リソースマネージャを中心に決定しております。
PR数以外に有効だった指標はありますか？
Findy Team+でも可視化できる「オープンからレビューまでの平均時間」は、意識的に改善することできるため有効でした。自分の仕事を貯めたり、相手の仕事を止めたりしないためにも、レビューは早め（当日中）に行うように推奨しています。
直接デプロイ頻度やリードタイムをKPIにするのではなくPR数に着目したことに戦略性による理由や目的はありましたか？
開発者が直接調整をおこなえるためです。デプロイ数などは、プロダクトの戦略やマーケティングなど、開発者が直接調整できない要素が多いため、PR数を指標にしました。
今後、よりビジネスインパクトにつながる様な指標で目標設定をする想定はありますか？
今のところ予定はしてませんが、リリース数を増やすことを開発者も意識できるようにしたいと思っております。
Discussion