開発効率の打ち手として、OffersMGR導入
まずはOffersMGR導入の背景や目的を教えてください。開発の効率化のために導入しました。きっかけは、2023年1月にエンジニアマネージャー（以下、EM）に昇格し、EMの仕事を見直す中で「業務の効率化」を課題に挙げたことです。
実はこの効率化の課題は以前から感じていましたが、現状の「効率」の状況を数値化する手段がありませんでした。他社の計測ツールをトライアル導入したり、手動で計算したりしましたが、どうもうまくいかず苦戦していました。
特に手作業での集計は時間がかかりすぎてEMが一番効率の悪い作業をしていることになります。他社のツールも価格や機能の面でニーズに合わず、代替手段を探していました。
そんな時にOffersMGRを知っていただいたと？はい、GitHubやJiraなどからアウトプットデータを簡単に数値化し、それを作業効率の見直しに役立てられることは良さそうだと思い、すぐに導入を決めました。
以前から感じていた開発効率の課題の中に、「リリースまでのリードタイムが長い」という傾向もありましたので、この点も上手く可視化し、改善していきたいと思っています。OffersMGRの導入コストも合理的で、使い勝手が良さそうな点も導入決定の決め手となりました。
OffersMGRの機能の中で、他に「これもよさそう！」と感じたものはありますか？Slackのコミュニケーション量を測れる機能が、意外と良さそうだなと感じました。
EMは人を見るのも仕事の一部です。特定の人物に過度な負担がかかって開発効率が落ちないようにするのが、主な役割だと僕は定義しています。とはいえ、弊社は完全フルリモート組織で、メンバーが日本全国に散らばっています。開発メンバーは約20名いますし、僕一人で全てのプロジェクトを逐次細かく見えるわけではありません。
そのため、EMとして対応する必要のある出来事が発生しても、感知が遅れてしまい、対処が後手になってしまうことがあります。しかし、この機能を使用することで、コミュニケーション量を俯瞰できるため、あるプロジェクトのコメント数が急増してもすぐに察知が可能になります。
確認工数が大幅削減！開発の振り返りも容易に
OffersMGR導入後はどんな使い方をされていますか？感想など聞かせてください。Four Keysを主軸にし、開発効率を俯瞰的に確認しています。具体的には、エンジニアチームの目標設定に入れているPull Request（以下、PR）作成数やサイクルタイムの分析に使っているのですが、数字を取ってみると比較的健全だということがわかりました。
ただ自分がEMになる前に現場で感じていた開発効率の体感値とギャップがあるので細かく確認してみたところ、開発効率が良いところと悪いところの落差があることがわかりました。これはツールで確認するまで気がつくことが出来ていなかったので大きな収穫です。
感覚として感じていたものが数値化されたことで、正しい打ち手が検討できそうですね！はい、まだテコ入れの最中なのですが、問題点は徐々に改善していきたいですね。
ただ、今はコミュニケーション量をメインに見るようにしています。基本的にはSlackの発信数やメンション数を個人やチーム別に見て、コミュニケーション数が多いメンバーに対しては僕が調整に入るようにしています。
エンジニアは開発することが仕事なので、質問の対応など、本来は不要なコミュニケーションに時間が取られてしまうのはもったいないですからね。
OffersMGRはEMである山田さん以外は使っていないのですか？プロダクトマネージャー（以下、PM）や他のエンジニアも活用していますよ。PMはプロダクト関係全体に関わる指標のチェックを、エンジニアは自身の個人目標設計をする際の過去の実績数値のチェックをしています。
実はPMがPR作成数を確認することもあるのですが、今まではGitHubで1個1個見ていました。これだとリポジトリごとに検索者や期間別で集計するので、非常に手間がかかっていました。
これがツールで一発で見れるようになったので「今期はこれぐらいの水準でいこう！」という目標も立てやすくなりました。
確認や管理の工数がだいぶ圧縮された感じですね。細かく計測はしていませんが、PMの気持ち的には10分の1ぐらいになったそうですよ。リポジトリを1個1個を検索するのは、実作業の時間以上に心がしんどかったようなので（笑
全体に数値共有し、数字を意識した組織へ
2023年4月にOffersMGRではFour Keysをリリースしました。先ほど「Four Keys」というコメントがありましたが、こちらの使い勝手はいかがでしょうか？こちらはまだ新しい機能ですし、今後さらに機能追加もあると思いますので、本格的な活用はこれから考えていきたいと思います。まずは現状の仕様で集計した値を全体に共有をして、数字を意識させることからスタートしたいですね。
全体共有はどのように？月次で以下の図のようにデプロイ頻度やリードタイムなどの各項目をグラフ化し、スライドにまとめて展開しています。最近はじめた取り組みですのでまだ特定のプロダクトのみ対象としていますが、今後は全プロダクトで実施していきたいと思います。
そうですね！今までは開発における全体的な数字を意識することはなくて、日々開発チケットを消化し、開発をし、それが終わるまでスプリントを繰り返すみたいなケースが正直ありました。
そこに振り返りをしっかりと行う文化を植えつけていきたいですし、パフォーマンスを数値化することで、それを意識できるような組織にしていきたいですね。
第三者視点で、"打ち手の質"を強化
OffersMGRを導入して、他に良かった点はありますか？OffersMGRのCustomer Success（以下、CS）からいただいている月次の開発組織レポートですね。開発コミット数やリリース数、リードタイム、Slack投稿数などのレポートをいただいているのですが、同じような開発組織規模の他社との比較や改善アドバイスも併せていただけるので、とても重宝しています！
具体的にどのあたりがお役に立っていますか？メンバーの稼働状況を一緒に振り返りながら、業務負荷が先月よりも高いと感じるメンバーに対しては、タスク状況を確認するようコメントをいただいたり、レビュアーの機会が少ないという指摘をいただいたメンバーには徐々に機会を増やしていくようアドバイスをいただいたりしています。実際、それをもとに改善を進めており、効果も出始めています。
なるほど！確かにCSから第三者の観点でコメントがあるのは良さそうですね！レポートでは自分で見ても気がつかない部分であったり、CSの方に数値を出してもらった方がわかりやすい項目もあるので、月次レポートは見落としリスクや確認コストも削減できて助かってます。
ツール利用料を含めたコストに対して、期待以上のものを出していただけてると感じていますし、今後もOffersMGRを積極的に使っていきたいですね！
ありがとうございました。