SmartHR Tech Blog

SmartHR 開発者ブログ

Findy Team+ではじめる月イチ生産性ふりかえり ── 心理的安全性を土台に改善サイクルを回す

こんにちは、届出書類チームでエンジニアをしているkidaです。

この記事では、開発生産性の計測ツール導入をきっかけに、私たちのチームがどのようにして改善サイクルを確立していったのかをお届けします。 月イチで実践している「ふりかえり」の具体的な取り組みや、そこから生まれた数々のTryについてご紹介します。

Findy Team+導入で見えたチームの「なんとなく」な課題感

私たちのチームには現在エンジニアが6人在籍しています。

6人でも多いですが、かつては9名在籍していた時期もあり、「多数のエンジニアを抱えるチーム」として、生産性が事業の成果に直結する重要な役割を担っています。そのため、以前からチームのパフォーマンスについては関心が高かったのですが、ツール導入以前は定性的な議論が中心でした。

「しばらく残っているPull Requestがある気がする」
「バーンダウンに向けて頑張ってレビューしよう」

こうした会話はされるものの、具体的なデータがないため、課題の特定や改善アクションに繋がりにくいという、もどかしさを感じていました。

この「なんとなく」の状態から脱却したいと考えていたところ、会社全体の方針として開発生産性を計測し可視化するツール「Findy Team+」が導入されました。 私たちはこれを良い機会と捉え、チーム独自の取り組みとして、このデータを元に月に一度の生産性ふりかえり定例会を始めることにしたのです。

初めて開発メンバー全員でデータを眺めると、いくつかの指標の中で、特にメンバーの視線が集まるものがありました。「この数字、なぜこうなっているんだろう?」――それが、私たちの改善への旅の始まりでした。

心理的に安全な「ふりかえり」を支える2つのグラウンドルール

データを前にすると、時にその数字の上下に感情が揺さぶられたり、「誰のせいでこの数字が悪いんだ」という雰囲気になったりする危険性があります。

そうした事態を避け、誰もが安心して発言できる建設的な場にするために、私たちはふりかえりの最初に、簡単な2つのグラウンドルールを確認しています。

ルール1:良い変化はチームで称賛し、気になる変化は「なぜ?」を考える起点にする

私たちは、数字の上下に「一喜一憂しない」わけではありません。むしろ、数字が改善したときは「改善アクションの効果が出てるね!」「みんな最高!」といった形で、お互いの努力や工夫をガンガン称賛し合います。ポジティブな変化をチームで喜ぶことは、改善活動を続けるモチベーションになります。

一方で、数字が悪化したときも、それを悲観したり誰かを責めたりはしません。その変化を「なぜだろう?」「何か背景があったかな?」と、チームの状態を深く知るための議論の起点として捉えます。このメリハリが、前向きな対話を生む土壌になっていると感じます。

ルール2:他人と比較しない。比較するのは「過去の自分」

チームには様々なバックグラウンドを持つメンバーがいます。使える時間、得意な技術、ドメイン知識の量も人それぞれです。そんな中で個人の数字を他人と比較しても、有益な学びはほとんどないと私たちは考えています。

だからこそ私たちは「過去の自分と比べてどうか」という視点を大切にしています。個人の成長にフォーカスすることで、一人ひとりが安心して自身の課題と向き合えます。

データと対話で乗り越えた、2つのフェーズ

これらのルールを土台に私たちは具体的な課題と向き合ってきました。ここでは私たちの改善活動における象徴的な2つのフェーズをご紹介します。

導入直後:データ分析で見えた「リードタイムの壁」

ふりかえりを始めて、まず私たちの前に立ちはだかったのが「レビューからアプルーブまでの時間」、すなわちリードタイムの長さでした。

Findy Team+のデータを詳しく見ると、どうやら「Pull Requestの変更行数」と「リードタイム」には相関関係がありそうだ、という仮説が浮かび上がってきました。この仮説を元にチームで対話(ヒアリング)すると、

「変更行数が多いPull Requestは、開いた瞬間に『うっ…』となって、つい後回しにする」

という、率直で重要な声が上がりました。データが示していたのは、まさにこの心理的な抵抗感だったのです。

また、対話を進める中で、「そもそもPRが更新されたことに気づくのが遅れる時がある」という、別の課題も明らかになりました。これに対しては、既に一部のメンバーが活用していたGitHubのデスクトップ通知ツール「Gitify」をチーム全体に横展開するアイデアが出ました。

このデータ分析から、私たちは3つの具体的なTryを決めました。

  • 期待値のヒアリングと目標設定
    • まず「どれくらいの時間でレビューされると嬉しいか」をチームで話し合い、「3時間」という具体的な目標を立てました
  • Pull Requestの分割
    • 変更行数が多くならないよう、機能開発を小さな単位に分割してPull Requestを作成することをチーム全体で意識しました
  • Gitifyの導入
    • Pull Requestの更新に素早く気づけるよう、デスクトップ通知ツール「Gitify」の活用を推奨しました

この3つのTryの結果、変更行数は約70%にまで減り、リードタイムはおよそ60%ほどにまで減少しました!

チーム変革期:実は明確な「見えない壁」

数字が好調だったある時、大きな変化が訪れます。チームのエンジニアが9人から6人に減り、加えて社内イベントの多い時期も重なったため、チームは一時的に多忙な状況になりました。

メンバーの間には「時間が取れないし、人が減ったのだから、少しはリードタイムが延びるのも仕方ないだろう」という、半ば諦めにも似た空気が漂っていました。

そして迎えた月イチのふりかえり。データは私たちの体感を裏付けるように、リードタイムの悪化をはっきりと示していました。「やっぱり悪化していたか……」――しかしそこで思考を止めず、その背景をもう少し具体的に探ることにしました。

「本当に『人がいないから』『時間がないから』だけで片付けて良いのだろうか?」

深掘りして対話した結果、レビューに着手できない「実は明確な」理由が、メンバー一人ひとりにあることが分かってきました。

  • 導入直後からの課題だった「変更行数の多いPull Request」が改善しきれていなかった
  • 自分が使っていないツールの更新だった
  • そもそも、変更内容の検証方法が分からなかった

この発見は大きな一歩でした。「仕方ない」で片付けられていたであろう問題の解像度が上がり、具体的なアクションに繋げることができたからです。

この「壁」を乗り越えるため、私たちは対話を通じて2つの新たなTryを生み出しました。

  • 「朝イチレビュー」の横展開
    • あるメンバーが実践していた「業務開始直後にまずレビューをする」というGood Practiceをチームに共有し、皆で意識することにしました
  • 「レビューできない理由」の表明
    • すぐにレビューできない場合、その理由(「〇〇の検証方法が分からないので教えてほしい」「午後には時間が取れそう」など)をPull Requestにコメントすることを推奨しました。これにより、レビュワーの状況が可視化され、依頼者も安心して待てるようになりました

この2つのTryによって、悪化していたリードタイムはおよそ60%にまで改善しました!

「ふりかえり」のふりかえり

こうした活動を続けてきて、私たちは数字の改善以上に大切なことに気づきました。

大事なのは「さっとTry」。軽やかに改善を回す文化

私たちのふりかえりでは、原因の完璧な分析にこだわりすぎません。それよりも「まずこれを試そう」「ダメだったら次を考えよう」と、軽いノリで「さっとTry」を出すことを重視しています。

この軽やかさが、メンバーの心理的な負担を減らし、改善活動を「重いもの」ではなく「日常の一部」にしてくれています。完璧な計画よりも、小さな実験を繰り返すこと。それが、改善のサイクルを止めずに回し続ける秘訣だと感じています。

土台にあった「心理的安全性」が、生産性向上のサイクルを回した

なぜ私たちのチームで「さっとTry」ができるのか。それは、このふりかえり活動を始める前から、チームに心理的安全性が根付いていたことが大きいと考えています。

元々、会議で誰かの意見を否定せず、まず受け止める文化がありました。この「何を言っても大丈夫」という土台があったからこそ、時に厳しい数字を突きつけるデータを前にしても、建設的な対話ができたのです。

この活動は、私たちが元々持っていた文化が、開発生産性の向上という領域でも有効であることを再確認する素晴らしい機会になりました。

「変更行数が多いPull Requestは、つい後回しにする」といった、一見ネガティブに聞こえかねない発言が気兼ねなくできたのも、この心理的安全性の土台があったからに他なりません。

これから始めるあなたへ。「完璧な分析」より「まず対話」を

ここまで読んで、「自分のチームでもできるだろうか」と感じた方もいるかもしれません。

私たちの経験から言えるのは、最初から完璧なデータ分析や立派なルールは必要ないということです。大切なのは、まずチームで一つの数字を眺めて、「これ、どう思う?」と話すこと。

その小さな対話が、チームをより良くするための一番大きな一歩になるはずです。 この記事が、皆さんのチームの改善活動のヒントになれば幸いです。

We Are Hiring!

SmartHR では一緒に SmartHR を作りあげていく仲間を募集中です!

この記事の根底にあるのは、何でも率直に話せる「心理的安全性」です。データの前で犯人探しをせず、前向きな対話から次のアクションを生み出す。そんな健全な開発文化で、あなたの経験を活かしませんか?

少しでも興味を持っていただけたら、カジュアル面談でざっくばらんにお話ししましょう!

hello-world.smarthr.co.jp