数値の裏にある課題をサーベイで掘り起こす。ソーシャルデータバンクが挑む組織改善の取り組みとは？
数値の裏にある課題をサーベイで掘り起こす。ソーシャルデータバンクが挑む組織改善の取り組みとは？
目次
目次を読み込み中...
本記事のサマリ
導入前：解決したかった課題
PRの滞留が発生し、1〜2ヶ月放置されるケースがあった。開発スピードに課題感を感じていたが、ボトルネックの特定が難しかった。
Findy Team+を導入した理由
自作の計測ツールでは運用負荷が高く、長期的な維持が困難だった。定量データを活用して、開発生産性の可視化と改善のサイクルを回す仕組みが必要だった。
導入した決め手
導入の手軽さと、Four Keys指標を活用した振り返りのしやすさが導入の決め手になった。
導入後：成果
PR（プルリクエスト）の滞留が減り、レビューリードタイムが短縮。ペアレビューの導入でレビューの負担が分散され、開発フローがスムーズに。
また、サーベイ機能を活用し、定量データに加え定性的な課題も可視化することで、開発生産性だけではなく開発者体験も意識した、次なるステップの改善にも取り組んでいる。
数値の裏にある課題をサーベイで掘り起こす。ソーシャルデータバンクが挑む組織改善の取り組みとは？
開発生産性の向上とエンジニアの働きやすさを追求するソーシャルデータバンク株式会社では、開発チームの課題発見や振り返りの質を高めるために、エンジニア組織支援クラウド「Findy Team+」を活用しています。今回は、開発推進課の島田氏にインタビュー。開発生産性を可視化し、より効率的な開発フローを実現するための取り組みや、Findy Team+導入の背景、活用方法について詳しくお話を伺いました。
――御社のエンジニア組織について教えてください。
島田：当社の開発組織は約25〜30名のエンジニアで構成され、全員が自社プロダクト「Liny」の開発を担当しています。私の所属する開発推進課は、SRE、DevOps、QA、デザインの4つの役割を持ち、開発生産性向上やフロー最適化に取り組むチームです。特定の技術領域に縛られず、誰もが幅広いスキルを持ち、柔軟に動ける体制を目指しています。私自身もDevOpsを中心に、SREやQA、運用改善まで幅広く関わっています。
――開発組織の目標や方針を教えてください！
島田：まず、会社としては「テクノロジーをボーダレスに」というビジョンを掲げています。技術を活用し、あらゆる垣根を超えてより良いプロダクトを生み出すことが目標です。その中で、開発組織としては「全員フルスタックエンジニア」の思想を持ち、特定の技術領域に依存せず、どのチームでも柔軟に開発できる環境を整えています。
――開発生産性の計測に取り組み、ツールを導入しようとしたきっかけは何でしょうか？
島田：t-wadaさんのポッドキャストで「LeanとDevOpsの科学」が紹介され、Four Keysの指標が企業の競争力に直結するという話に興味を持ったのが始まりでした。私は当社にインターンのときから所属しているのですが、インターン時代にミニマムな形で内製のリードタイム計測を試しました。しかしその際、NotionのGitHub連携やサードパーティツールでは運用負荷やデータ管理の手間が大きく、継続が難しいと感じました。そこで、新卒で正社員として入社後、本格的に開発生産性の可視化を進めるためにツール導入を検討しました。
――計測を行っていたなか、どのようなきっかけから「Findy Team+」に興味を持ったのでしょうか？
島田：自作ツールの運用負荷が高く、長期的な維持が難しかったことが大きな理由です。計測自体はスタート地点であり、本当に重要なのは「どう改善につなげるか？」ですが、自作ツールではそこに時間を割きづらい状況でした。
Findy Team+は、導入の敷居が低く、すぐに計測をスタートできる点や、定量データを活用し、3〜6ヶ月の長期スパンで振り返りができる点が魅力でした。定性的な記憶だけでは過去の状態を正確に思い出すのが難しいですが、Findy Team+を活用することで数値に基づいた振り返りが可能になり、改善の方向性を明確にできると感じました。
PRの滞留を解消し、スムーズな開発フローへ
――Findy Team+を導入することで、解決したかった課題や可視化したかった指標は何でしょうか？
島田：一番の課題はPRの滞留でした。
1〜2ヶ月も放置されるPRがあり、開発が進むにつれてコンフリクトが発生し、マージが難しくなる状況が続いていました。さらに、なぜレビューが進まないのか、どこで時間がかかっているのかが不明確で、ボトルネックを特定するのが困難でした。
――その課題を可視化するにあたって、どんな難しさがありましたか？
島田：特にレビューの待ち時間を正確に計測するのが難しかったです。
「レビュー依頼を出したタイミング」「レビュー開始のタイミング」がGitHubのログだけでは追いにくく、私たちはもともとレビューリクエスト機能を使わずラベル管理していたため、どのPRがレビュー待ちなのかの判断も曖昧でした。
Findy Team+を導入したことで、「この運用にすればこのデータが取れる」ということが分かったので、ツールの標準機能に合わせた運用に切り替え、判断基準を統一することにしました。特に、レビュー周りの運用ルールを明確化し、滞留を防ぐ仕組みを構築したことで、スムーズな開発フローを実現できました。
――開発生産性の計測を通じて、どのような目標を設定していましたか？
島田：最初に設定したのは、オープンPRの数とレビューリードタイムの2つです。特にPRの滞留は大きな課題でした。私が開発推進課にジョインしたとき、Linyのメインリポジトリには100件以上のオープンPRがあって、エンジニア数20人ほどの規模に対して多すぎる状態でした。このままでは管理が難しくなると感じ、まずはPRを気合でマージ・クローズして50件以下に減らしました。
――レビューリードタイムを短縮するために、どのような取り組みを行いましたか？
島田：社内でよく話題に上がるのが、「スイッチングコストを減らす」 という考え方です。エンジニアは複数のタスクを並行して進めることが多いですが、タスクを切り替えるたびに集中力が分散し、結果的に作業が遅くなります。
そこで、並行してオープンするPRの数を減らし、レビューの優先度を上げる文化を作りました。特に、レビュー依頼が来たらすぐ対応することを意識することで、レビューリードタイムの短縮につなげています。
また、PRのサイズを小さくすることも重要なポイントでした。大きな変更が一度に入ると、レビューに時間がかかり、結果的にリードタイムが長くなります。そこで、変更範囲を小さく区切り、こまめにマージする運用に切り替えました。
こうした改善を進めるうえで、Findy Team+のデータが非常に役立ちました。
例えば、PRの滞留時間を数値で可視化できるので、「どのタイミングでPRが止まっているのか？」「レビュー依頼後、実際に対応されるまでにどれくらい時間がかかっているのか？」といった課題を具体的に把握できます。実際に、滞留しているPRをリストアップし、一定期間動きがないものは優先的に対応するルールを設けたことで、チーム全体の意識が変わりました。
また、レビューリードタイムの推移をグラフで確認しながら、「特定の週にレビューが遅れがちなのはなぜか？」を分析することで、レビューの負担が一部のメンバーに偏っていることが判明しました。そこで、ペアレビューを積極的に取り入れることで、負担を分散しつつ、質の高いレビューを維持できるようになりました。
このように、Findy Team+の定量データをもとに課題を明確化し、具体的な改善策を講じることで、開発の流れをスムーズにすることができました。
サーベイ機能で組織の課題を可視化。データと現場感覚を融合した改善の取り組み
――Findy Team+の活用において、定量データ以外で活用されている機能はありますか？
島田：チーム内でさらなる改善を進める上での「議論のきっかけ」にできればと思い、チームサーベイ機能を活用しはじめました。
また、定量データだけでは捉えきれない「開発者体験」の領域を、メンバー自身の回答を起点に議論することで、改善活動への当事者意識を高める効果を期待していました。
結果的に、メンバー個々が感じているチームの強みや伸びしろについて、サーベイ結果を元に話し合うことで、課題に対する共通認識を形成したり、止まっていた議論を再開して具体的なアクション案を出すことに繋がりました。
――サーベイは具体的にどのように活用しましたか？
島田： サーベイの回答が集まった後に、振り返りのワークショップを実施しました。開発組織全体で集まったのですが、話し合いはチームごとにしてもらう形で、ツールとしてMiroを使いました。
進め方としては、まず最初に「チームの強みと伸びしろについて考えてみましょう」というテーマで、サーベイの結果を参考にしながら、各自がMiro上の付箋に書き出すところから始めました。サーベイは低い点数の項目に目が向きがちですが、あえて「強み」から出してもらうことで、チームのポジティブな面にも目が向きやすくなったのではないかと思います。
また、工夫した点としては、全体の集計結果を見るだけでなく、メンバー各自に自分の回答結果（メンバーサーベイの結果）をまず見てもらうように促したことです。自分の評価が起点になるので、議論にも参加しやすかったのではないかと思います。
チームによっては、具体的な項目を洗い出すために、「強み」は『過去一度でもスコア5をつけた項目』、「伸びしろ」は『スコア2以下をつけた項目』 という定量的な基準を設けて、チーム内で共有しているところもありました。
このように強みと伸びしろをチームごとに出した上で、「これらの項目の中で、特にどこに注力していきたいか」をチームで話し合い、最後は「じゃあ、具体的にどんなアクションが考えられるか？」をブレスト形式でアイデア出しを行いました。
※実際に活用されたMiroのテンプレート
――サーベイを活用して、どのような気付きがありましたか？
島田：一番大きかったのは、チーム内での『目線合わせ』ができたことかなと思います。サーベイという共通のフレームワークがあることで、「やっぱり自分たちのチームはここが課題だよね」とか、「ここは強みとして認識していいんだな」といった共通認識を持ちやすくなりました。
また、議論を通して、具体的なアクションに繋がるきっかけになった点も大きいですね。以前からなんとなく課題だと感じていたことでも、サーベイの結果をきっかけに「じゃあ、どうしようか」と具体的なアクション案を話し合う場が作れました。中には、過去の合宿で話したきりになっていた課題が、これを機に再度掘り起こされて、ネクストアクションに繋がった、というケースもありました。
メンバーの意識や行動の変化で言うと、ワークショップ以降、「プルリクを小さくしよう」とか、「レビュアーフレンドリーなプルリク作りをしよう」といった声が、以前よりもメンバーの口から自然と聞かれるようになったと感じています。これは、レビュー負荷軽減という具体的な課題とサーベイでの気づきがリンクした結果かもしれません。
もちろん、サーベイの結果からすぐに全てのアクションに繋がったわけではなくて、具体的な改善策に落とし込む難しさも正直感じています。そこはこれからの課題ですね。
ただ、サーベイを活用することで、チームみんなで課題や強みを認識し、改善について話し合う「きっかけ」を作れたことは、組織として大きな一歩だったと感じています。
定量データとサーベイで課題を可視化。Findy Team+が生むチームの成長
――Findy Team+のおすすめポイントを教えてください。
島田：Findy Team+の最大の魅力は、「導入の手軽さ」と「定量的な振り返りができること」です。導入のハードルが低く、すぐに開発生産性の計測を始められるため、手間をかけずにデータを取得できます。また、定量データをもとに振り返ることで、感覚的ではなく「事実に基づいた改善策」を考えやすくなります。
さらに、サーベイ機能を活用することで、チームの強みや課題を可視化し、振り返りの質を高めることができました。開発組織全体の課題認識を揃えながら、メンバーの自律的な改善活動を促進できるのも大きな利点です。
エンジニア組織の開発生産性向上に取り組みたい企業には、ぜひ活用をおすすめしたいですね。
――最後に、今後一緒に働きたいエンジニア像を教えてください。
島田：私たちは、 開発生産性を向上させることに興味がある人、 技術だけでなく、チームの成長にも関心がある人と一緒に働きたいと考えています。
単にコードを書くだけでなく、開発フローやチームの課題解決にも関わりたい人 にとっては、とてもやりがいのある環境だと思います。また、「新しい技術や手法を試してみたい」という好奇心旺盛なエンジニアにも向いていると思いますね。
私たちのチームは、開発生産性の向上に向けて常に試行錯誤を続けているので、新しい挑戦を楽しめる人と一緒に働けると嬉しいです。
※現在ソーシャルデータバンクでは、エンジニアを募集しています。
https://recruit.social-db.co.jp/
本記事のサマリ
導入前：解決したかった課題
PRの滞留が発生し、1〜2ヶ月放置されるケースがあった。開発スピードに課題感を感じていたが、ボトルネックの特定が難しかった。
Findy Team+を導入した理由
自作の計測ツールでは運用負荷が高く、長期的な維持が困難だった。定量データを活用して、開発生産性の可視化と改善のサイクルを回す仕組みが必要だった。
導入した決め手
導入の手軽さと、Four Keys指標を活用した振り返りのしやすさが導入の決め手になった。
導入後：成果
PR（プルリクエスト）の滞留が減り、レビューリードタイムが短縮。ペアレビューの導入でレビューの負担が分散され、開発フローがスムーズに。
また、サーベイ機能を活用し、定量データに加え定性的な課題も可視化することで、開発生産性だけではなく開発者体験も意識した、次なるステップの改善にも取り組んでいる。
数値の裏にある課題をサーベイで掘り起こす。ソーシャルデータバンクが挑む組織改善の取り組みとは？
開発生産性の向上とエンジニアの働きやすさを追求するソーシャルデータバンク株式会社では、開発チームの課題発見や振り返りの質を高めるために、エンジニア組織支援クラウド「Findy Team+」を活用しています。今回は、開発推進課の島田氏にインタビュー。開発生産性を可視化し、より効率的な開発フローを実現するための取り組みや、Findy Team+導入の背景、活用方法について詳しくお話を伺いました。
――御社のエンジニア組織について教えてください。
島田：当社の開発組織は約25〜30名のエンジニアで構成され、全員が自社プロダクト「Liny」の開発を担当しています。私の所属する開発推進課は、SRE、DevOps、QA、デザインの4つの役割を持ち、開発生産性向上やフロー最適化に取り組むチームです。特定の技術領域に縛られず、誰もが幅広いスキルを持ち、柔軟に動ける体制を目指しています。私自身もDevOpsを中心に、SREやQA、運用改善まで幅広く関わっています。
――開発組織の目標や方針を教えてください！
島田：まず、会社としては「テクノロジーをボーダレスに」というビジョンを掲げています。技術を活用し、あらゆる垣根を超えてより良いプロダクトを生み出すことが目標です。その中で、開発組織としては「全員フルスタックエンジニア」の思想を持ち、特定の技術領域に依存せず、どのチームでも柔軟に開発できる環境を整えています。
――開発生産性の計測に取り組み、ツールを導入しようとしたきっかけは何でしょうか？
島田：t-wadaさんのポッドキャストで「LeanとDevOpsの科学」が紹介され、Four Keysの指標が企業の競争力に直結するという話に興味を持ったのが始まりでした。私は当社にインターンのときから所属しているのですが、インターン時代にミニマムな形で内製のリードタイム計測を試しました。しかしその際、NotionのGitHub連携やサードパーティツールでは運用負荷やデータ管理の手間が大きく、継続が難しいと感じました。そこで、新卒で正社員として入社後、本格的に開発生産性の可視化を進めるためにツール導入を検討しました。
――計測を行っていたなか、どのようなきっかけから「Findy Team+」に興味を持ったのでしょうか？
島田：自作ツールの運用負荷が高く、長期的な維持が難しかったことが大きな理由です。計測自体はスタート地点であり、本当に重要なのは「どう改善につなげるか？」ですが、自作ツールではそこに時間を割きづらい状況でした。
Findy Team+は、導入の敷居が低く、すぐに計測をスタートできる点や、定量データを活用し、3〜6ヶ月の長期スパンで振り返りができる点が魅力でした。定性的な記憶だけでは過去の状態を正確に思い出すのが難しいですが、Findy Team+を活用することで数値に基づいた振り返りが可能になり、改善の方向性を明確にできると感じました。
PRの滞留を解消し、スムーズな開発フローへ
――Findy Team+を導入することで、解決したかった課題や可視化したかった指標は何でしょうか？
島田：一番の課題はPRの滞留でした。
1〜2ヶ月も放置されるPRがあり、開発が進むにつれてコンフリクトが発生し、マージが難しくなる状況が続いていました。さらに、なぜレビューが進まないのか、どこで時間がかかっているのかが不明確で、ボトルネックを特定するのが困難でした。
――その課題を可視化するにあたって、どんな難しさがありましたか？
島田：特にレビューの待ち時間を正確に計測するのが難しかったです。
「レビュー依頼を出したタイミング」「レビュー開始のタイミング」がGitHubのログだけでは追いにくく、私たちはもともとレビューリクエスト機能を使わずラベル管理していたため、どのPRがレビュー待ちなのかの判断も曖昧でした。
Findy Team+を導入したことで、「この運用にすればこのデータが取れる」ということが分かったので、ツールの標準機能に合わせた運用に切り替え、判断基準を統一することにしました。特に、レビュー周りの運用ルールを明確化し、滞留を防ぐ仕組みを構築したことで、スムーズな開発フローを実現できました。
――開発生産性の計測を通じて、どのような目標を設定していましたか？
島田：最初に設定したのは、オープンPRの数とレビューリードタイムの2つです。特にPRの滞留は大きな課題でした。私が開発推進課にジョインしたとき、Linyのメインリポジトリには100件以上のオープンPRがあって、エンジニア数20人ほどの規模に対して多すぎる状態でした。このままでは管理が難しくなると感じ、まずはPRを気合でマージ・クローズして50件以下に減らしました。
――レビューリードタイムを短縮するために、どのような取り組みを行いましたか？
島田：社内でよく話題に上がるのが、「スイッチングコストを減らす」 という考え方です。エンジニアは複数のタスクを並行して進めることが多いですが、タスクを切り替えるたびに集中力が分散し、結果的に作業が遅くなります。
そこで、並行してオープンするPRの数を減らし、レビューの優先度を上げる文化を作りました。特に、レビュー依頼が来たらすぐ対応することを意識することで、レビューリードタイムの短縮につなげています。
また、PRのサイズを小さくすることも重要なポイントでした。大きな変更が一度に入ると、レビューに時間がかかり、結果的にリードタイムが長くなります。そこで、変更範囲を小さく区切り、こまめにマージする運用に切り替えました。
こうした改善を進めるうえで、Findy Team+のデータが非常に役立ちました。
例えば、PRの滞留時間を数値で可視化できるので、「どのタイミングでPRが止まっているのか？」「レビュー依頼後、実際に対応されるまでにどれくらい時間がかかっているのか？」といった課題を具体的に把握できます。実際に、滞留しているPRをリストアップし、一定期間動きがないものは優先的に対応するルールを設けたことで、チーム全体の意識が変わりました。
また、レビューリードタイムの推移をグラフで確認しながら、「特定の週にレビューが遅れがちなのはなぜか？」を分析することで、レビューの負担が一部のメンバーに偏っていることが判明しました。そこで、ペアレビューを積極的に取り入れることで、負担を分散しつつ、質の高いレビューを維持できるようになりました。
このように、Findy Team+の定量データをもとに課題を明確化し、具体的な改善策を講じることで、開発の流れをスムーズにすることができました。
サーベイ機能で組織の課題を可視化。データと現場感覚を融合した改善の取り組み
――Findy Team+の活用において、定量データ以外で活用されている機能はありますか？
島田：チーム内でさらなる改善を進める上での「議論のきっかけ」にできればと思い、チームサーベイ機能を活用しはじめました。
また、定量データだけでは捉えきれない「開発者体験」の領域を、メンバー自身の回答を起点に議論することで、改善活動への当事者意識を高める効果を期待していました。
結果的に、メンバー個々が感じているチームの強みや伸びしろについて、サーベイ結果を元に話し合うことで、課題に対する共通認識を形成したり、止まっていた議論を再開して具体的なアクション案を出すことに繋がりました。
――サーベイは具体的にどのように活用しましたか？
島田： サーベイの回答が集まった後に、振り返りのワークショップを実施しました。開発組織全体で集まったのですが、話し合いはチームごとにしてもらう形で、ツールとしてMiroを使いました。
進め方としては、まず最初に「チームの強みと伸びしろについて考えてみましょう」というテーマで、サーベイの結果を参考にしながら、各自がMiro上の付箋に書き出すところから始めました。サーベイは低い点数の項目に目が向きがちですが、あえて「強み」から出してもらうことで、チームのポジティブな面にも目が向きやすくなったのではないかと思います。
また、工夫した点としては、全体の集計結果を見るだけでなく、メンバー各自に自分の回答結果（メンバーサーベイの結果）をまず見てもらうように促したことです。自分の評価が起点になるので、議論にも参加しやすかったのではないかと思います。
チームによっては、具体的な項目を洗い出すために、「強み」は『過去一度でもスコア5をつけた項目』、「伸びしろ」は『スコア2以下をつけた項目』 という定量的な基準を設けて、チーム内で共有しているところもありました。
このように強みと伸びしろをチームごとに出した上で、「これらの項目の中で、特にどこに注力していきたいか」をチームで話し合い、最後は「じゃあ、具体的にどんなアクションが考えられるか？」をブレスト形式でアイデア出しを行いました。
※実際に活用されたMiroのテンプレート
――サーベイを活用して、どのような気付きがありましたか？
島田：一番大きかったのは、チーム内での『目線合わせ』ができたことかなと思います。サーベイという共通のフレームワークがあることで、「やっぱり自分たちのチームはここが課題だよね」とか、「ここは強みとして認識していいんだな」といった共通認識を持ちやすくなりました。
また、議論を通して、具体的なアクションに繋がるきっかけになった点も大きいですね。以前からなんとなく課題だと感じていたことでも、サーベイの結果をきっかけに「じゃあ、どうしようか」と具体的なアクション案を話し合う場が作れました。中には、過去の合宿で話したきりになっていた課題が、これを機に再度掘り起こされて、ネクストアクションに繋がった、というケースもありました。
メンバーの意識や行動の変化で言うと、ワークショップ以降、「プルリクを小さくしよう」とか、「レビュアーフレンドリーなプルリク作りをしよう」といった声が、以前よりもメンバーの口から自然と聞かれるようになったと感じています。これは、レビュー負荷軽減という具体的な課題とサーベイでの気づきがリンクした結果かもしれません。
もちろん、サーベイの結果からすぐに全てのアクションに繋がったわけではなくて、具体的な改善策に落とし込む難しさも正直感じています。そこはこれからの課題ですね。
ただ、サーベイを活用することで、チームみんなで課題や強みを認識し、改善について話し合う「きっかけ」を作れたことは、組織として大きな一歩だったと感じています。
定量データとサーベイで課題を可視化。Findy Team+が生むチームの成長
――Findy Team+のおすすめポイントを教えてください。
島田：Findy Team+の最大の魅力は、「導入の手軽さ」と「定量的な振り返りができること」です。導入のハードルが低く、すぐに開発生産性の計測を始められるため、手間をかけずにデータを取得できます。また、定量データをもとに振り返ることで、感覚的ではなく「事実に基づいた改善策」を考えやすくなります。
さらに、サーベイ機能を活用することで、チームの強みや課題を可視化し、振り返りの質を高めることができました。開発組織全体の課題認識を揃えながら、メンバーの自律的な改善活動を促進できるのも大きな利点です。
エンジニア組織の開発生産性向上に取り組みたい企業には、ぜひ活用をおすすめしたいですね。
――最後に、今後一緒に働きたいエンジニア像を教えてください。
島田：私たちは、 開発生産性を向上させることに興味がある人、 技術だけでなく、チームの成長にも関心がある人と一緒に働きたいと考えています。
単にコードを書くだけでなく、開発フローやチームの課題解決にも関わりたい人 にとっては、とてもやりがいのある環境だと思います。また、「新しい技術や手法を試してみたい」という好奇心旺盛なエンジニアにも向いていると思いますね。
私たちのチームは、開発生産性の向上に向けて常に試行錯誤を続けているので、新しい挑戦を楽しめる人と一緒に働けると嬉しいです。
※現在ソーシャルデータバンクでは、エンジニアを募集しています。
https://recruit.social-db.co.jp/
数値の裏にある課題をサーベイで掘り起こす。ソーシャルデータバンクが挑む組織改善の取り組みとは？
本記事のサマリ
導入前：解決したかった課題
PRの滞留が発生し、1〜2ヶ月放置されるケースがあった。開発スピードに課題感を感じていたが、ボトルネックの特定が難しかった。
Findy Team+を導入した理由
自作の計測ツールでは運用負荷が高く、長期的な維持が困難だった。定量データを活用して、開発生産性の可視化と改善のサイクルを回す仕組みが必要だった。
導入した決め手
導入の手軽さと、Four Keys指標を活用した振り返りのしやすさが導入の決め手になった。
導入後：成果
PR（プルリクエスト）の滞留が減り、レビューリードタイムが短縮。ペアレビューの導入でレビューの負担が分散され、開発フローがスムーズに。
また、サーベイ機能を活用し、定量データに加え定性的な課題も可視化することで、開発生産性だけではなく開発者体験も意識した、次なるステップの改善にも取り組んでいる。
数値の裏にある課題をサーベイで掘り起こす。ソーシャルデータバンクが挑む組織改善の取り組みとは？
開発生産性の向上とエンジニアの働きやすさを追求するソーシャルデータバンク株式会社では、開発チームの課題発見や振り返りの質を高めるために、エンジニア組織支援クラウド「Findy Team+」を活用しています。今回は、開発推進課の島田氏にインタビュー。開発生産性を可視化し、より効率的な開発フローを実現するための取り組みや、Findy Team+導入の背景、活用方法について詳しくお話を伺いました。
――御社のエンジニア組織について教えてください。
島田：当社の開発組織は約25〜30名のエンジニアで構成され、全員が自社プロダクト「Liny」の開発を担当しています。私の所属する開発推進課は、SRE、DevOps、QA、デザインの4つの役割を持ち、開発生産性向上やフロー最適化に取り組むチームです。特定の技術領域に縛られず、誰もが幅広いスキルを持ち、柔軟に動ける体制を目指しています。私自身もDevOpsを中心に、SREやQA、運用改善まで幅広く関わっています。
――開発組織の目標や方針を教えてください！
島田：まず、会社としては「テクノロジーをボーダレスに」というビジョンを掲げています。技術を活用し、あらゆる垣根を超えてより良いプロダクトを生み出すことが目標です。その中で、開発組織としては「全員フルスタックエンジニア」の思想を持ち、特定の技術領域に依存せず、どのチームでも柔軟に開発できる環境を整えています。
――開発生産性の計測に取り組み、ツールを導入しようとしたきっかけは何でしょうか？
島田：t-wadaさんのポッドキャストで「LeanとDevOpsの科学」が紹介され、Four Keysの指標が企業の競争力に直結するという話に興味を持ったのが始まりでした。私は当社にインターンのときから所属しているのですが、インターン時代にミニマムな形で内製のリードタイム計測を試しました。しかしその際、NotionのGitHub連携やサードパーティツールでは運用負荷やデータ管理の手間が大きく、継続が難しいと感じました。そこで、新卒で正社員として入社後、本格的に開発生産性の可視化を進めるためにツール導入を検討しました。
――計測を行っていたなか、どのようなきっかけから「Findy Team+」に興味を持ったのでしょうか？
島田：自作ツールの運用負荷が高く、長期的な維持が難しかったことが大きな理由です。計測自体はスタート地点であり、本当に重要なのは「どう改善につなげるか？」ですが、自作ツールではそこに時間を割きづらい状況でした。
Findy Team+は、導入の敷居が低く、すぐに計測をスタートできる点や、定量データを活用し、3〜6ヶ月の長期スパンで振り返りができる点が魅力でした。定性的な記憶だけでは過去の状態を正確に思い出すのが難しいですが、Findy Team+を活用することで数値に基づいた振り返りが可能になり、改善の方向性を明確にできると感じました。
PRの滞留を解消し、スムーズな開発フローへ
――Findy Team+を導入することで、解決したかった課題や可視化したかった指標は何でしょうか？
島田：一番の課題はPRの滞留でした。
1〜2ヶ月も放置されるPRがあり、開発が進むにつれてコンフリクトが発生し、マージが難しくなる状況が続いていました。さらに、なぜレビューが進まないのか、どこで時間がかかっているのかが不明確で、ボトルネックを特定するのが困難でした。
――その課題を可視化するにあたって、どんな難しさがありましたか？
島田：特にレビューの待ち時間を正確に計測するのが難しかったです。
「レビュー依頼を出したタイミング」「レビュー開始のタイミング」がGitHubのログだけでは追いにくく、私たちはもともとレビューリクエスト機能を使わずラベル管理していたため、どのPRがレビュー待ちなのかの判断も曖昧でした。
Findy Team+を導入したことで、「この運用にすればこのデータが取れる」ということが分かったので、ツールの標準機能に合わせた運用に切り替え、判断基準を統一することにしました。特に、レビュー周りの運用ルールを明確化し、滞留を防ぐ仕組みを構築したことで、スムーズな開発フローを実現できました。
――開発生産性の計測を通じて、どのような目標を設定していましたか？
島田：最初に設定したのは、オープンPRの数とレビューリードタイムの2つです。特にPRの滞留は大きな課題でした。私が開発推進課にジョインしたとき、Linyのメインリポジトリには100件以上のオープンPRがあって、エンジニア数20人ほどの規模に対して多すぎる状態でした。このままでは管理が難しくなると感じ、まずはPRを気合でマージ・クローズして50件以下に減らしました。
――レビューリードタイムを短縮するために、どのような取り組みを行いましたか？
島田：社内でよく話題に上がるのが、「スイッチングコストを減らす」 という考え方です。エンジニアは複数のタスクを並行して進めることが多いですが、タスクを切り替えるたびに集中力が分散し、結果的に作業が遅くなります。
そこで、並行してオープンするPRの数を減らし、レビューの優先度を上げる文化を作りました。特に、レビュー依頼が来たらすぐ対応することを意識することで、レビューリードタイムの短縮につなげています。
また、PRのサイズを小さくすることも重要なポイントでした。大きな変更が一度に入ると、レビューに時間がかかり、結果的にリードタイムが長くなります。そこで、変更範囲を小さく区切り、こまめにマージする運用に切り替えました。
こうした改善を進めるうえで、Findy Team+のデータが非常に役立ちました。
例えば、PRの滞留時間を数値で可視化できるので、「どのタイミングでPRが止まっているのか？」「レビュー依頼後、実際に対応されるまでにどれくらい時間がかかっているのか？」といった課題を具体的に把握できます。実際に、滞留しているPRをリストアップし、一定期間動きがないものは優先的に対応するルールを設けたことで、チーム全体の意識が変わりました。
また、レビューリードタイムの推移をグラフで確認しながら、「特定の週にレビューが遅れがちなのはなぜか？」を分析することで、レビューの負担が一部のメンバーに偏っていることが判明しました。そこで、ペアレビューを積極的に取り入れることで、負担を分散しつつ、質の高いレビューを維持できるようになりました。
このように、Findy Team+の定量データをもとに課題を明確化し、具体的な改善策を講じることで、開発の流れをスムーズにすることができました。
サーベイ機能で組織の課題を可視化。データと現場感覚を融合した改善の取り組み
――Findy Team+の活用において、定量データ以外で活用されている機能はありますか？
島田：チーム内でさらなる改善を進める上での「議論のきっかけ」にできればと思い、チームサーベイ機能を活用しはじめました。
また、定量データだけでは捉えきれない「開発者体験」の領域を、メンバー自身の回答を起点に議論することで、改善活動への当事者意識を高める効果を期待していました。
結果的に、メンバー個々が感じているチームの強みや伸びしろについて、サーベイ結果を元に話し合うことで、課題に対する共通認識を形成したり、止まっていた議論を再開して具体的なアクション案を出すことに繋がりました。
――サーベイは具体的にどのように活用しましたか？
島田： サーベイの回答が集まった後に、振り返りのワークショップを実施しました。開発組織全体で集まったのですが、話し合いはチームごとにしてもらう形で、ツールとしてMiroを使いました。
進め方としては、まず最初に「チームの強みと伸びしろについて考えてみましょう」というテーマで、サーベイの結果を参考にしながら、各自がMiro上の付箋に書き出すところから始めました。サーベイは低い点数の項目に目が向きがちですが、あえて「強み」から出してもらうことで、チームのポジティブな面にも目が向きやすくなったのではないかと思います。
また、工夫した点としては、全体の集計結果を見るだけでなく、メンバー各自に自分の回答結果（メンバーサーベイの結果）をまず見てもらうように促したことです。自分の評価が起点になるので、議論にも参加しやすかったのではないかと思います。
チームによっては、具体的な項目を洗い出すために、「強み」は『過去一度でもスコア5をつけた項目』、「伸びしろ」は『スコア2以下をつけた項目』 という定量的な基準を設けて、チーム内で共有しているところもありました。
このように強みと伸びしろをチームごとに出した上で、「これらの項目の中で、特にどこに注力していきたいか」をチームで話し合い、最後は「じゃあ、具体的にどんなアクションが考えられるか？」をブレスト形式でアイデア出しを行いました。
※実際に活用されたMiroのテンプレート
――サーベイを活用して、どのような気付きがありましたか？
島田：一番大きかったのは、チーム内での『目線合わせ』ができたことかなと思います。サーベイという共通のフレームワークがあることで、「やっぱり自分たちのチームはここが課題だよね」とか、「ここは強みとして認識していいんだな」といった共通認識を持ちやすくなりました。
また、議論を通して、具体的なアクションに繋がるきっかけになった点も大きいですね。以前からなんとなく課題だと感じていたことでも、サーベイの結果をきっかけに「じゃあ、どうしようか」と具体的なアクション案を話し合う場が作れました。中には、過去の合宿で話したきりになっていた課題が、これを機に再度掘り起こされて、ネクストアクションに繋がった、というケースもありました。
メンバーの意識や行動の変化で言うと、ワークショップ以降、「プルリクを小さくしよう」とか、「レビュアーフレンドリーなプルリク作りをしよう」といった声が、以前よりもメンバーの口から自然と聞かれるようになったと感じています。これは、レビュー負荷軽減という具体的な課題とサーベイでの気づきがリンクした結果かもしれません。
もちろん、サーベイの結果からすぐに全てのアクションに繋がったわけではなくて、具体的な改善策に落とし込む難しさも正直感じています。そこはこれからの課題ですね。
ただ、サーベイを活用することで、チームみんなで課題や強みを認識し、改善について話し合う「きっかけ」を作れたことは、組織として大きな一歩だったと感じています。
定量データとサーベイで課題を可視化。Findy Team+が生むチームの成長
――Findy Team+のおすすめポイントを教えてください。
島田：Findy Team+の最大の魅力は、「導入の手軽さ」と「定量的な振り返りができること」です。導入のハードルが低く、すぐに開発生産性の計測を始められるため、手間をかけずにデータを取得できます。また、定量データをもとに振り返ることで、感覚的ではなく「事実に基づいた改善策」を考えやすくなります。
さらに、サーベイ機能を活用することで、チームの強みや課題を可視化し、振り返りの質を高めることができました。開発組織全体の課題認識を揃えながら、メンバーの自律的な改善活動を促進できるのも大きな利点です。
エンジニア組織の開発生産性向上に取り組みたい企業には、ぜひ活用をおすすめしたいですね。
――最後に、今後一緒に働きたいエンジニア像を教えてください。
島田：私たちは、 開発生産性を向上させることに興味がある人、 技術だけでなく、チームの成長にも関心がある人と一緒に働きたいと考えています。
単にコードを書くだけでなく、開発フローやチームの課題解決にも関わりたい人 にとっては、とてもやりがいのある環境だと思います。また、「新しい技術や手法を試してみたい」という好奇心旺盛なエンジニアにも向いていると思いますね。
私たちのチームは、開発生産性の向上に向けて常に試行錯誤を続けているので、新しい挑戦を楽しめる人と一緒に働けると嬉しいです。
※現在ソーシャルデータバンクでは、エンジニアを募集しています。
https://recruit.social-db.co.jp/
