開発組織のブラックボックスをどう開けるか――ファインディ「Findy Team+」が示す課題→改善の伴走モデル

「挑戦するエンジニアのプラットフォームをつくる」をビジョンに掲げるファインディは、求人票の採点サービスに始まり、転職支援から開発組織の支援、メディア、カンファレンスへと事業を広げてきた。その開発組織支援の中核が、開発組織の状態を可視化する「Findy Team+」である。同プロダクトの開発をリードし、エンジニア組織を率いるのが浜田 直人氏だ。

Findy Team+は、GitHubやJiraと連携して開発データを取り込み、見えにくい組織のパフォーマンスとボトルネックを定量化する。「開発組織のアクティビティは、かなりブラックボックス化しやすい」。浜田氏はそう語る。直近では、その前段にある開発プロセスそのものを整えるコンサルティングサービスも始めた。汎用AIでも開発データを扱えるいま、このプロダクト固有の価値はどこにあるのか。浜田氏が描く開発組織支援の現在地を聞いた。

「見えない開発組織」をどう測るか――ファインディが可視化に賭ける理由

ソフトウェア開発の現場は、外から中が見えにくい。他社がどのような進め方をしているのか、その情報は基本的に社内に入ってこない。結果として、自社の開発組織が高い成果を出せているのかどうかすら判断しづらい。「自分の組織がそもそも高いアウトプットを出せているのか、そこが見えていない」。浜田氏はそう指摘する。

Findy Team+は、この不可視性を数字に変えるプロダクトである。GitHubやGitLabといったコード管理ツール、JiraやBacklogといったプロジェクト管理ツールと連携し、日々の開発データを取り込んで解析する。エンジニアのパフォーマンスや開発プロセスのボトルネックは、Web上のダッシュボードに定量的に映し出される。担当者の感覚に委ねられてきた領域を、客観的なデータに置き換えるという発想だ。

数字は、比較があって初めて意味を持つ。自社のデータだけを眺めても、その値が良いのか悪いのかは分からない。多くの導入企業のデータと照らせば、自社が業界の中でどの位置にいるかが見えてくる。浜田氏は、デリバリー能力の高い組織とそうでない組織の差を示すDORAレポートを引き、その格差は年々はっきりしてきていると語る。

使い手は一様ではない。中心はエンジニアリングマネージャーだが、CTOやVPoEのニーズにも応える。彼ら向けには、新規開発と技術改善へのリソース配分を可視化する指標を用意する。メンバー個人が自らの数値を見て改善に動くこともあるが、評価そのものには使用しない。「評価に直接使うと、その数字がハックされる」からだ。いわゆるグッドハートの法則を避け、あくまで改善点を探し、目標を設定するための道具と位置づける。

実際の導入では、具体的な数字が動く。パナソニック コネクトは、アジャイルの形骸化や開発の予測不能性という課題を解決するために導入した。レビュー未実施や誤ったマージ手順などの逸脱を可視化・是正することで、PR（プルリクエスト）滞留を30%削減。一定期間の開発量を示すベロシティも安定に向かったという。しかし、指標を映し出すだけでは組織は動かない。そもそも、数字すら出せない組織もある。

「連携できても、意味のある数字は出てこない」――可視化の前段を整えるコンサルティング

可視化には前提がある。GitHubやJiraといったツールを、開発組織がきちんと使いこなしていることだ。ところが現実には、そうしたツールをそもそも導入していない組織や、コードを置くためだけに使い、レビューの手順が定まっていない組織が一定数ある。「連携できますと言っても、意味のある数字は出てこない」。浜田氏はそう指摘する。

ここを埋めるために、ファインディは最近、コンサルティングサービスを始めた。Findy Team+を導入する手前の段階で、開発プロセスそのものを整え、プロジェクト管理のあり方を見直す。プロダクトを売る前に、プロダクトが機能する土台をつくるという発想だ。

形式は研修である。テレビ朝日系列の開発会社、テレビ朝日メディアプレックスに対しては、開発組織のドキュメント文化をどう根づかせるかをテーマに研修を実施した。その結果、メンバーが自発的にチケットへ記述する量が40%増えた。1回の研修だが、変化は数字に表れている。

狙いは単発のコンサルティングにとどまらない。浜田氏は、その先の流れをこう描く。「開発プロセスが整備されると、結果的にFindy Team+もそれまで以上に活用してもらえる」。土台を整え、プロダクトで可視化し、その先はカスタマーサクセスが並走して改善を続ける。前段の整備は、その一連の流れの入り口という位置づけだ。

プロダクトが扱えるデータの質は、その手前の開発プロセスで決まる。可視化や生成AIの活用を語る前に、足元の整備が要る。ファインディのコンサルティングは、その手前から手を入れる仕事である。

ツールを導入するだけでは終わらない――人が伴走する改善サイクル

汎用AIの進化は、この領域にも及んでいる。前日のプルリクエストの数や所要時間を尋ねれば、GitHubから単純な値はすぐ返ってくる。浜田氏も、そこはほぼ同等になりつつあると認める。ただ、それだけでは取れない指標がある。GitHubはあくまでコード管理のツールであり、デリバリー能力を測るには、4つの指標を組み合わせる「Four Keys」のように、データを計算し加工する工程が要る。「そうした複雑な指標を、AIが今すぐ出せるかというと、まだ難しい」。

とはいえ、指標の精度は本質ではない。より大きな違いは、その先にある。数字を見せられても、組織が自力で改善できるとは限らないからだ。「数字を提示されるだけで、自発的に改善できるかというと、そうではないことが多い」。浜田氏はそう話す。

そこでファインディは、導入企業ごとにカスタマーサクセスの担当をつける。開発指標を一緒に見ながらロードマップを引き、「この値をここまで伸ばす」という目標を決め、次回その達成度を確認する。改善サイクルを外から回す役回りだ。開発生産性の改善は、目の前の開発に比べれば後回しになりやすい。伴走者がいることで、それが前に進む。

この人を介したモデルが、顧客層を押し広げた。Findy Team+はもともと中堅・中小企業やスタートアップ向けだったが、いまは銀行や生損保といった金融業や、製造業にも導入されている。導入の条件は、コード管理やプロジェクト管理の主体を自社内に持っていることだ。開発を外部へ丸ごと委ねていると、データが開発会社側にたまり、導入のハードルが上がる。北國銀行では、レビュープロセスの改善や人材育成に活用が進む。

生成AIによって加速度的に進む内製開発化、その指標の一つともいえるデリバリー能力は、経営層の関心事でもある。開発プロセスの改善に加え、AI投資の効果をどう検証するか――技術領域のトップがそうした問いを持ち込むようになった。プロダクトの重みが増すほど、開発の速さを測る目盛りが必要になる。次に問われるのは、その目盛りで生成AIの効果まで捉えられるかだ。

生産性の先に、生成AIをどう使うか――ファインディが見据える次の問い

開発組織の関心は、生産性そのものよりも、生成AIをどう活用するかへと移りつつある。関心の中心にあるのは、技術そのものより組織の動かし方である。生成AIをすでに導入した企業と話すと、議論は決まって「導入後、現場でいかに定着・活用させているか」に向かう。どういったユースケースがあるのか、業務フローにどう組み込まれているのか。浜田氏は、そうした実務の事例を企業どうしで気軽に交わしてきた。

可視化で開発組織のブラックボックスを開け、人が伴走して改善を回す。その積み重ねの先に、生成AIの活用という次の問いが乗る。導入するかどうかではなく、どう組織に根づかせ、その効果をどう測るか。ファインディが見据えるのは、まさにその問いである。