見出し画像

4ヶ月の開発生産性改善の取り組みを振り返る

shirakawa@PRONI

はじめに

プロダクト開発部に所属しております、白川と申します。

PRONI株式会社では開発生産性の向上を目指し、各チームが自律的に開発生産性の改善に取り組んでいます。

PRONIでは開発生産性の向上に積極的に取り組んでいます。この取り組みは、エンジニアの力を最大限に活用し、プロダクトの価値を高めることを目指しています。

https://note.com/mine_unilabo/n/nf4917fadb7cf


この記事では、私が7月まで所属していたIMカスタマーチームが、開発生産性指標から気づきを得て、システムやプロセスの改善に取り組んだ話をします！
※ IMカスタマーチームとは、PRONIアイミツの発注者に向き合うチームです！ IMとは「アイミツ」の略です。


どのように改善に取り組んだか

PRONIでは、Findy Team+を利用して、チームの生産性可視化をしています。
カスタマ向き合いチームでは、週1で30分のMTGを実施し、Findy Team+を眺めながら、課題を特定・深掘りし、次のアクションを繋げるというサイクルを繰り返してきました。
(レトロスペクティブとは別で毎週やっており、本会議ではアウトプットに閉じた話をしています。)

会議では以下の流れを基本としていました。

  1. 指標を確認し、ボトルネックを特定する

  2. 原因の深掘りをする

  3. 次のアクションを決める

  4. フォーカスする指標を見直す

得られた結果

取り組みの前(2024年2月)
取り組み後(2024年6月)

結果として指標が大きく向上しました！

※ スタッツの設定にはgit-flowにおけるdevelopブランチを指定しております。そのため、Four Keysの定義とは乖離し、数値がよく出てしまっておりますが、取り組み前後で数値が改善できていることをお伝えできればと思います。

試行錯誤の中での出来事

トライアンドエラーの中での出来事を時系列的に紹介できればと思います！

「変更のリードタイムが24時間以上のプルリクエストを作らない」という目標を立てた


最初に注目したのは、その週の全体の変更リードタイムでした。
一週間ごとに全体の数値を追いかけていたのですが、良い数値になった週がありました。

深掘りしたところ、その週は軽微な修正が多かったことが要因でした。この結果を単純に「改善できた」と捉えるのは違うと考え、平均値ではなく、特に目立つデータに着目して振り返りを行っていこうと考えて、この方針になりました。

フィーチャーフラグ導入


3月以降は、変更のリードタイムが24時間以上のプルリクエストにフォーカスして、個々のプルリクエストに対して振り返りました。
深掘りしたところ、変更のリードタイムが長くなっているパターンには3つあることがわかりました。

  1. メンバーが抱えている他プロジェクトに関連しているパターン

  2. 開発者が得意でない領域を担当しているパターン

    • 同時にバックエンドが得意なメンバーが休んでしまった時

    • 学習的な意味合いを込めて、あまりやってこなかった領域にトライしているとき

  3. 親ブランチ

    • 機能が中途半端な状態でマージできず、親ブランチを作成して開発を進めるケース

このうち、3の「親ブランチ」にフォーカスし、開発中機能のコードでもマージ&リリースするべく、フィーチャーフラグを導入しました！
実際にフィーチャーフラグを使い、チームとして手応えを感じられました。実際のメンバーの感想を以下に引用します。

・ 総じてよさげ、ただ課題（考慮しなきゃならんこと）は色々ある
    ・分岐が増える＝コードの複雑度はあがる（動作チェックは入念にしないとイカン）
    ・ テストコードでフィーチャーフラグon／offのテストパターンが単純に増える
・ あらかじめデプロイしておいて、ユーザーに届けたいときにリリースっていうのができてよかった。もしデプロイ＝リリースだったら、他部署との調整で速度がダウンしてたかもしれない。
・ 親ブランチ運用より楽な感覚
    ・ developをマージする手間がない。
    ・ タスク分割が、フィーチャーグラグ運用の方が楽な気がする。
・ 最初は事故るリスクが上がるかと思ったけど、細かくデプロイしているからビックバンリリース（親ブランチ運用）より理論的にリスク減るはず。

コードレビューの容易性の観点でプルリクエストを分割していこうという方針


フィーチャーフラグの導入後、とある「変更のリードタイムが24h以上のプルリクエスト」を深掘りしました。
このプルリクエスト内は、1つの画面に多数のフォームがあるフロントエンドの実装で、項目数の多さゆえに時間がかかりました。

単純に、フォームの項目ごとに分割すれば変更のリードタイムは短縮できたかもしれませんが、果たしてその分割に意義があるのかという疑問が生まれました。
そこで、分割することのメリットを改めて考えました。

・無理やり分割しようと思えばできたけど、旨みはない気がする。PRを早く閉じるだったら、分割の余地があったかもしれないけど、効率は良くなかったかも
・分割すると作業する側は楽だけど、チェックする側は大変かも。
・ 分割しない場合は、フィードバックが遅くなり、設計・実装・認識違いなど様々な不確実性に気づけるタイミングがとても遅くなる

まとめると、分割には以下のメリットがあると話し合いの中で整理しました。

  • レビューが楽になる

  • フィードバックサイクルが短くなる

結果として、分割することについて、チームで腹落ちし、「コードレビューの容易性の観点で分割していこう」という方針が決まりました。

また、合わせて、レビューの容易性を振り返るために、「オープンからアプルブまでの時間」「変更行数」「コメント数」「ファイル数」なども指標として確認していきました。
ただ、1つの指標だけをみてもなかなか課題は見えてきませんでした。手間ではありますが、複数の指標を見る必要があると感じました。

「変更のリードタイムが24時間以上のプルリクエスト」がなくなってきた


タスク分割とフィーチャーフラグを中心としたプラクティスで、「変更のリードタイムが24時間以上のプルリクエスト」は、ほぼほぼなくりました。

個別のプルリクエストをに着目していましたが、結果として全体の指標も改善し、冒頭で記載した通り、

  • 取り組みの前(2024年2月)：30.9h

  • 取り組み後(2024年6月)：9.6h

と改善されました。

感想

開発生産性においてよく言われていることですが、数値を向上させることだけに目を向けるとあまり良い取り組みにはならないなと感じました。

数値は目的ではなく意思決定を支援をしてくれるものと捉えて、行動や仕組みを見直し、結果として指標も向上させるというサイクルを作れれば良い方向へ向かって行きやすいのかなと思います。

実際に、フィーチャーフラグやタスク分割など、新たにケイパビリティを獲得することでチームが成長し、その結果数値も向上した時、改善活動がうまくはまったという実感を得ました。

また、今回は、コーディングプロセスにおける改善が中心でした。次は、CI/CDの改善など開発プロセス全体の改善ができればと考えています。

最後に

PRONIではエンジニアメンバーを募集しています。興味を持っていただけた方は、ぜひお気軽にお問い合わせください！

■PRONIに関する情報配信登録
PRONIに関する最新情報、イベント情報、採用情報などを配信しています。
ご希望の方は以下のフォームよりご登録をお待ちしております！


いいなと思ったら応援しよう！