【DevOps】開発の振り返りをアップデートした話

はじめに

こんにちは、プレックスの池川です。

2023年2月に「DevOpsの指標を開発の振り返りに活用しはじめた話」という記事をこのブログに投稿して、はや10ヶ月。10ヶ月の間に振り返りのやり方も変わってきました。

product.plex.co.jp

そこで今回の記事では、振り返りのやり方が10ヶ月前と比べて何がどう変わったのかを紹介したいと思います!

目次

エンジニア組織について

振り返りについて紹介する前に、プレックスのエンジニア組織について簡単に紹介します。というのも、振り返りの方法を見直すきっかけが「エンジニア組織の拡大」だったからです。

プレックスの開発体制は下記の画像のような事業部制を基本としています。エンジニアの人数は10ヶ月前と比べると、正社員が4名→6名インターン1名→3名に増えました。また、コーポレートマーケという社内システムの開発や管理を行う事業部も立ち上げられ、現在エンジニアは各々3つの事業部に所属しています。

開発体制

以前はエンジニア全員での振り返りを行っていましたが、各事業部ごとにサービスがあり取り扱っているドメインも異なることから、私が所属しているプレックスジョブ開発チームでも振り返りを導入するようにしました。

プレックスジョブ開発チームでの振り返り

振り返りMTGについて

プレックスジョブ開発チームではスクラムを採用しており、1スプリントを1週間としています。振り返りもスプリント単位で行っており、スプリント開始のタイミングでMTGを行い前スプリントの内容を振り返っています。 下記が振り返りの内容です。

  1. KPT
    • 事前に振り返りシートを共有し、各メンバーにKPT用のJamboardに今週のアクションや課題を記入してもらう
    • Jamboardに各自作成してもらった今週のアクションや課題をKeepとProblem、Tryに振り分けて発表する
    • 全員のKeepとProblemが分類でき次第、Tryをタスク化する
  2. 開発のパフォーマンス改善
    • Four Keys の指標をもとに前スプリントのパフォーマンスを振り返り

KPTについて

KPTを用いた振り返りは元々エンジニア全体で行なっていましたが、事業部単位で行うようにしました。

Jambordの作成と共有はGASを使って自動化しており、MTGの前日にSlackのエンジニアチャンネルで共有されるようにしています。

実際のMTGで仕様したJambordです。

Jambord

KPTを行うことでポジティブ、ネガティブなことに関わらずメンバー間で情報共有ができるほか、課題の早期発見と解決にもつながるので振り返りにオススメの方法です!

開発のパフォーマンス改善について

次にFour Keysを用いたパフォーマンスの振り返りについて、どのように変わったか紹介します!

Four Keyesの指標は元々集計していたものの、振り返りの指標としてあまり運用できていなかったため、振り返りのMTGで運用できるようにダッシュボードや運用方法の見直しを行いました。

まず、ダッシュボードを Google Looker StudioからRedashに移行しました。Redashは他のプロジェクトでも使用されていて、データの可視化や取り回しがしやすく、関係者が全員アクセスできるといった点で採用しました。

現在のダッシュボードです。

現在(2023年10月時点)のダッシュボード

集計している指標は10ヶ月前と同じデプロイ頻度リードタイムですが、それぞれの指標についてGoogleのパフォーマンスレベルをもとに下記の目標を定めています。

  • デプロイの頻度:スプリント平均で一日一件以上
  • リードタイム:120時間(5日以内)

集計フローはこちらです。

  1. GitHub API から取得したデータを加工して BigQuery に保存するスクリプトを実行
  2. Redash で Google SQL を実行し、必要なデータを取り込み
  3. 取り込んだデータを Redash でグラフ化してダッシュボードに表示

MTGではダッシュボードを確認し、目標が達成できていない項目については、プルリク単位で振り返りを行い原因の特定と改善策を話し合います。 数字をベースに振り返りを行うことで、KPTとは違ったアプローチで現状把握や課題の発見ができるようになりました。

運用する中で効果のあった改善策の一例を紹介します。従来、パッケージのバージョン管理をDependabotで行なっていましたが、プルリクが大量に作られることから対応が後回しとなり、結果、リードタイムが長くなっていました。そこでマイナーバージョンのプルリクをまとめて作成してくれるRenovateに移行することにしました。導入した結果、リードタイムの平均(コミットされてからデプロイされるまでの時間)は268時間(11日)130時間(5.4日)と半分になり、大幅にリードタイムが改善されました。

リードタイム_平均

次に、エンジニア全体で行なっている振り返りについて紹介します!

エンジニア全体での振り返り

エンジニア全体の振り返りは元々週一回行っていましたが、隔週で金曜日に1時間程度、定例MTGを行うように変更しました。

従来、MTGではKPTを行いアクションや課題間を共有していましが、振り返りの方法を見直す中でKPTは廃止して各々が開発する中で得た学びをシェアする時間を設けました。

メンバーはそれぞれあらかじめNotionに共有したい学びをまとめておきMTGで順番に発表していきます。

振り返りシート(一部抜粋)

開発する中で得た学び開発中に遭遇したバグや、新しい技術を試してみた話、便利なツールの紹介など興味深いトピックが多く、知識の共有だけでなくエンジニア全体の結束を高めることにも繋がっていると感じています。

さいごに

今回の記事では、プレックスのエンジニア全体とプレックスジョブ開発チームでの「振り返り」の取り組みに関して紹介させていただきました。

前回の記事から10ヶ月が経ち、振り返りの継続実施はできるようになりましたが、今後も組織や事業の成長に合わせて随時やり方を見直し柔軟に取り組んでいくことが必要だと考えています。

振り返りの取り組みやFour Keysをはじめとした指標の活用の変化に関しても引き続きアップデートがあれば、本ブログで紹介していきます。

今回紹介したような開発の効率化や振り返りに少しでも興味を持っていただけた方はぜひ一緒に取り組みましょう!

dev.plex.co.jp