Findy Team+
システム開発・実装AIサービス・ツール
経営と開発現場をつなぐAI時代の開発資本プラットフォーム「Findy Team+」を提供。開発プロセスのメトリクス可視化、レビューリードタイムやデプロイ頻度の計測、チーム単位で柔軟に設定できるモニタリング機能などを備える。
この事例で使われたサービスFindy Team+サービスのページへ
この取り組みに関心があれば、
Findy Team+の公式情報をご覧ください
※イメージ画像です01 — Overview
Sansanの契約データベース化サービス Contract One を担う開発組織が進めたのは、開発の停滞を数値で捉える仕組みと、生成AIの使い方をチームで揃える仕組みを同時に整えることでした。以前は内製でメトリクスを集計していたものの詳細な数値が取れず、どの施策がどれだけ効いているかは感覚で判断するしかない状態が続いていました。そこで開発生産性を可視化するサービス Findy Team+ を利用し、レビューリードタイムやデプロイ頻度を毎週確認しながら、詰まっている箇所を一つずつ解消していきます。生成AIの側では、コードスタイルや設計方針を定めた rules と、レビュー依頼文の作成やテストコード生成といった繰り返し作業をAIに任せる skills を整備。1人1エピック制などの体制変更も併走し、リリースノートの件数は14倍まで変化しました。
出典：生成AIをチームの戦力にする「skills・rules」設計。Sansan Contract Oneが挑む、LLM活用の標準化と自動化の最前線 | Findy Team+（発行元：Findy Team+）
02 — Problem
バックログには次々とタスクが積み上がるのに、消化が追いつかない。1チームに1プロジェクトという体制だったため、どこか一箇所が詰まれば全体が止まりました。市場開拓を進めるなかで「リリースの生産量を2倍に」という要求もかかっており、焦りはあるのに、何が原因で遅いのかが数値として見えない。内製でメトリクスを集計する試みはあったものの、詳細な数値までは取れませんでした。
編集部の見立てでは、この組織の困りごとの本質は「開発が遅い」ことそのものではなく、遅さの所在を名指しできず、打った手が効いたかどうかも検証できない状態にあったのではないでしょうか。原因が特定できなければ、改善は当たるかどうか分からない賭けになります。生成AIを使い始めた当初に「AIを使うこと」が目的化し、かえって質が落ちる場面が出たのも、同じ構造の裏返しと言えます。
03 — Key points
メトリクス基盤を内製せず、既製の可視化サービスに載せてしまう判断が、この取り組みの起点になっています。内製で作れば時間がかかり、その整備自体が新たなボトルネックになりかねません。開発リソースを計測の仕組みづくりに割かず、プロダクト開発に回すという割り切りが、可視化への着手を早めました。全員が同じ数値を見る状態が先にできたことで、「設計ドキュメントのレビューがここで止まっている」という言い出しにくい話を、個人への批判ではなく数値の指摘として扱えるようになったと考えられます。
生成AIの使い方を rules と skills の二層に切り分けた設計は、品質とスピードのどちらを取るかという二択を回避しています。rules はコードスタイルや設計方針といった、AIに守らせたい約束事。skills は「レビュー依頼文を書く」「テストコードを生成する」といった、繰り返し発生する作業をAIに任せるためのテンプレートです。守らせる側と任せる側を分けたことで、個人の使い方のばらつきを抑えながら、任せる作業の範囲だけを段階的に広げられる構造になっています。
skills と rules を更新し続ける前提で運用している点も、この設計の要です。古い定義を使い続けると、かえって作業の邪魔になる。メトリクス上で遅くなった工程を見つけてから対応する定義を見直す、という順序が決まっているため、AI活用の改善が思いつきではなく数値を起点にした作業になります。AIの効果は体感では判断しにくいため、効果を測る手段を先に持っていたことが、標準化を続けられる条件になったのではないでしょうか。
04 — Results
レビューリードタイムを毎週確認して滞留を潰す地道な運用を重ねた結果、積み上がっていたバックログはほぼ消化できる水準まで減り、今は次に着手するテーマを探すフェーズに入っています。リリースノートの件数は14倍まで変化しました。特定のメンバーでレビューが止まるといった、以前は問題として認識されにくかった詰まりも、数値で示せるようになっています。なお、課題発見からリリースまでを1か月以内に完結させることや工程の完全自動化は、現時点では目標および設計中の段階です。
05 — For your company
応用しやすいのは、作業の流れがツール上に記録として残る仕事です。開発に限らず、依頼から承認までの経過が管理ツールに残る業務であれば、どこで滞っているかを数値で示す第一歩は同じように踏み出せます。またAIに任せる作業を定義するには、その作業を文章として書き出せることが前提になります。依頼文の作成やテスト用のコードのように、手順と完成形をある程度言葉にできる作業から始めるのが現実的でしょう。
一方、このやり方をそのまま持ち込みにくい場面もあります。ルールとテンプレートを書き、数値を毎週見て見直す担い手が必要で、Contract Oneではテックリードがその役割を継続的に担っています。片手間の兼務では、定義が古びたまま放置されて逆効果になりかねません。成果物の良し悪しが数値に表れにくい業務でも、効果検証の部分が働きにくくなります。
手始めとしては、先週チーム内で一番待たされた工程を一つ挙げ、その待ち時間が何日だったかを数えてみるところから。数えられない工程が見つかれば、それ自体が最初の改善対象です。
06 — Company
システム開発・実装AIサービス・ツール
経営と開発現場をつなぐAI時代の開発資本プラットフォーム「Findy Team+」を提供。開発プロセスのメトリクス可視化、レビューリードタイムやデプロイ頻度の計測、チーム単位で柔軟に設定できるモニタリング機能などを備える。
この取り組みに関心があれば、
Findy Team+の公式情報をご覧ください
07 — Category
関連度の高い事例を選定しています。少しお待ちください。