注力テーマ：リリースファーストの現在地

この記事はKINTOテクノロジーズ Advent Calendar 2025 の17日目の記事です🎅🎄

Engineering OfficeのNaitoです。KINTOテクノロジーズ（以下、KTC）には4つの2025年注力テーマ（インテンシティ、AIファースト、ユーザーファースト、リリースファースト）があります。
以前のブログで2025年注力テーマの1つ、リリースファーストについてお伝えしました。
今回はリリースファーストにまつわるこの1年の取り組みや変化について紹介します。
最初に認識合わせをしておくと、KTCではリリースファーストは、「アイディア創出からリリースまでの期間を短くし、ユーザー・顧客に早く価値を提供する」としています。

2025年1月〜3月

Engineering Officeが立ち上がりました。
メンバーはahomuと私（当時入社3ヶ月）の2人です。
Findy Team+の導入・活用支援という切り口で開発チームとの対話を通し、各チームの状況やメンバーのことを知り始めた状態で、その結果わかったことは以下のようなことでした。

• 自分たちの現状を定量的に把握できているのは一部のチームにとどまっている
• Findy Team+を導入したが、うまく計測・可視化できないチームもある
• Findy Team+の1機能である、プロセスタイム分析（JiraをINPUTとして各工程ごとのリードタイム）の計測・可視化ができるチームはゼロ
• 開発パフォーマンスの計測・可視化に取り組んでいるチームにおいても一部の人で計測データを見て試行錯誤しながら、改善活動に取り組んでいる。チーム全体には広がっていない
• 計測・可視化に関心があっても先行しているチームがどんな状況なのかはわからず、情報収集ができない

現在（2025年末）

Engineering Officeはなんと4名に増えました。それぞれの専門領域を最大限発揮しつつ、コラボレーションしてチームで活動しています。
「一緒にやろう」と複数チームから声をかけていただき（ありがたい！）、私たちはこの1年間で約20チームに関わらせていただきました。
各チームは、

• 注力テーマに紐づいた目標を設定し、取り組んでいる
• リリースファーストの第一歩は自分たちの現状を定量的に定性的に把握することからという意識が全社に広がっており、社内の主なプロダクト、開発チームはFindy Team+を導入して開発パフォーマンスの計測を行っている
• Findy Team+ではFour Keysについては全チームが計測可能な状態になっている
• Findy Team+を見て話し合うことがチーム全体に広がっているところも増え、改善事例が少しずつ共有されている
• Findy Team+の1機能である、プロセスタイム分析（JiraをINPUTとして各工程ごとのリードタイム）は3プロダクトが計測できている
• チームを超えたリリースファーストのタスクフォースが発足し、業務のかたわら、プロダクト横断でリリースファーストを実現するための仕組みづくりを実施中
• ある部門では部門全体で役割分担や開発プロセスを見直し、役割間・チーム間のコラボレーションを強化中

チームのレビュープロセスを見直した結果、レビュー時間が向上した事例

この変化がどうやって起こったのか？正直、各チームの頑張りの賜物なわけですが。Engineering Office（横軸組織）から見た目線でお伝えしていきたいとおもいます。

注力テーマを理解する

各プロダクトにおいては注力テーマの意味はなんとなくわかるけど具体的にどういうこと？というのが当時の状況でした。
そのため、最初の2−3ヶ月は推進メンバー全員で注力テーマについて社内に浸透させるところから始まりました。
まずは社内で言葉の認識合わせを行い、「なぜこれがいまKTCにとって大事なのか」また「リリース期間だけ短くなればよいということではなく、ユーザー・顧客に向き合い、価値を提供することに意味がある」「ユーザーファーストをないがしろにしてリリースを優先しても技術的負債になってしまう」ということを伝える活動を続けました。

プロダクトやチームごとに自分たちにとってのリリースファーストを考える

注力テーマについて各人が理解すると、次はプロダクトごと、チームごとに自分たちは注力テーマを実現するために何をしたらいいのか？自分たちの現状ってどんな感じなのか？ということが話し合われました。
各方面で注力テーマについて考えた結果、私のところにも以下のような声が届いてきました。

• リリースが早くなったかどうかBefore/Afterをわかるようにしたい
• AIを活用して実装スピードあげたい
• リリースまでの流れってどうなっているのか
• 統合テストに時間かかっている
• ユーザーが遠くて価値が届いているのかわからない
• 設計・実装より前のフェーズにボトルネックがあるように思うが計測できていない
• 自チームだけでは前に進めるのは難しい。関係者で集まって話し合いたい

こういった課題感共有や話し合いを経て、プロダクトやチームで注力テーマを実現するための自分たちのチームの目標を定めていきました。

取り組み

以下はリリースファーストに関する取り組みの一部です。複数のチームで同様の取り組みをしているケースもあります。

• なぜ開発パフォーマンスを計測するのかとFindy Team+導入の説明会
• GitHubのブランチ戦略・運用ルール変更
• PRレビュープロセスの改善
• Findy Team+を見合う会
• チームのケイパビリティの可視化
• Jiraを使った工程ごとのリードタイムの計測（そのためにJiraの運用ルール見直し）
• 全社横断でのAI利活用状況の計測・可視化
• Value Streamの可視化
• 部門全体でのValue Streamの改善
• アジャイルトレーニングの実施
• ユーザー視点で要求を整理し、PRDを作成するワークの実施
• プロダクト毎のテスト環境構築
• インシデント対応プロセス改善
• テストデータ作成方法の見直し
• Techラウンドテーブル（チーム間の情報共有）
• トヨタ生産方式勉強会入門編

ここに挙げたのは私が関わった取り組みだけですので、社内には他にもたくさんの取り組みがあります。

ボトルネックを特定し、Value Streamを改善した事例

Techラウンドテーブル @Osaka Tech Lab

まとめ

上記のような取り組みを1年間繰り返し続けてきた結果が冒頭のような変化に繋がっています。
当初のリリースファーストの目標を実現しているチームもまだ途中のチームもいますが、どのチームも自分たちの行動で起きた変化は実感していることとおもいます。

社内の風土としてボトムアップで様々なことが進むことが多いです。そのため、今回の注力テーマの各取り組みにおいてもまずは自分のチームの範囲でやってみようという形で始まることが大半でした。

一方で、KTCのプロダクトは複数のチームで構成されていることが多いです。リリースファーストやユーザーファーストを実現するためには、プロダクト全体を俯瞰する視点が欠かせません。
自チームが整うと、自然とメンバーの視野も広がりより広い範囲に目を向けるようになります。そのため、2025年後半にはチームを超えた「リリースファースト」の取り組みが増えてきました。
チームを超えると部門が異なる人や他の役割の人たちと課題を共有し、目線合わせをしていく必要があるのですが、専門領域や役割の違いにより見えているもの感じているものが異なる場合も多く、ゴール設定や進め方で躓くことも多いです。

このような時にはビジネス・技術・プロセスを統合して見えているマネージャーのアドバイスや方向性づけ、判断というのがとても大事になります。
それによりチームを超えた様々な関係者がまとまり、取り組みが加速するというの目の当たりにしています。

今年の変化が成果となって表れるのが来年です。来年、リリースファースト・ユーザーファーストの活動を加速させ、より多くの成果に結びつけていくためにはマネージャーの関与は不可欠です。
本当の意味でリリースファーストを実現するプロダクトがどれだけ増えるのか今からとても楽しみです。
リリースファースト、ユーザーファーストは一年で終わる話ではありません。プロダクト開発に携わる以上は継続的に取り組んでいくテーマです。

Engineering Officeは来年も引き続き各チームとともにリリースファースト、ユーザーファーストに取り組んでいきます。

お知らせ

Regional Scrum Gathering Tokyo 2026のDay1（1/7）に出ます。具体の取り組みのいくかについて話す予定です。みなさんよかったら見に来てくださいね。

「リリースファースト」の実感を届けるには〜停滞するチームに変化を起こすアプローチ〜