AI活用が進む中で、開発プロセスのボトルネックはこれまでの実装フェーズから、要件定義や設計といった上流工程へ移りつつあります。ourly株式会社では、リードタイム15時間前後の維持や日次デプロイの実現など、実装フェーズの改善をすでにやり切り、価値提供のスピードをさらに高めるために「プロジェクト全体のリードタイム」に着目し始めました。

一方で、要件定義や設計といった上流工程は曖昧になりやすく、どこに時間がかかっているのか把握しづらいという課題もありました。こうした背景から、同社はFindy Team+の「プロジェクトプロセスタイム分析」機能を活用し、プロセス全体の可視化に取り組んでいます。

本記事では、ourly株式会社CTOの相澤さんとエンジニアリングマネージャーの神本さんへのインタビューを通じて、
機能活用に至った背景から、上流工程を可視化するためにどのような実践を進めてきたのか、そして可視化によってどのような気づきが得られたのかを明らかにします。

プロフィール

相澤 宏亮さん
執行役員CTO

2017年に株式会社PLAN-B新卒入社。未経験からスタートして自社開発やSESなどを経験。その後株式会社ビットエーに転職し、ourly事業の立ち上げを行う。分社化してourly株式会社となり、EMの役割を担った後、2024年7月から執行役員CTOを拝命。開発、採用/育成、開発生産性向上など幅広くカバーしながら奮闘中。

神本 直人さん
エンジニアリングマネージャー

新卒でSUBARUに入社し、6年間ハードウェアのエンジニアとして従事。その後、実務未経験からwebエンジニアに転身しourly株式会社にjoin。2025年4月からEMのラベルをいただく。新規機能開発業務の傍ら、開発生産性向上の推進メンバーとして活動中。

リリースが伸びない理由──実装フェーズ以外に残る課題

相澤：Findy Team+を導入した2年半前は、プルリクエスト（以下、PR）のリードタイムやデプロイ頻度に課題があり、まずは実装フェーズの改善に集中していました。
現在、PRのリードタイムは15時間前後で安定し、デプロイ頻度も日次で実現できる状態まで持っていくことができました。

ただ、デプロイが増えてもリリース頻度の伸びは緩やかで、価値提供のスピードが思ったほど上がっていないという状況がありました。

コード変更の反映であるデプロイと、顧客が価値を感じるリリースを分けて見ているのですが、デプロイだけが速くなっても意味がありません。
要件定義や設計といった上流工程が「なんとなく進む」ままになっていて、ちゃんと短くしていかないと、プロジェクト全体のリードタイムは縮められないと感じるようになりました。
プロダクト戦略を見直すタイミングでも、リリース頻度を高めることが重要だという話になり、上流工程を可視化する必要性を強く感じるようになりました。

「PRのリードタイムやデプロイ頻度を突き詰めていった先に何があるんだろう」というのは、メンバーも薄々感じていたと思います。実装フェーズの課題が改善されてきたことで、リリース頻度を高めるために何をすべきかを考える余地がチーム内に生まれてきました。
プロダクトにどう向き合うか、どこに時間を使うべきかといった考えが増えていったように感じています。

神本：僕自身は以前から考えていましたが、最近はチーム全体がアウトカムに意識を向けられるようになってきています。
開発生産性Conferenceや社外イベントでもアウトカムの話題が増えていますし、実装フェーズの改善から、全員が価値提供に向き合えるようになった感覚があります。

相澤：AIが発展してきたことで、PRのリードタイムを短くする、デプロイ頻度を上げるといった取り組みの難易度が下がってきている実感があります。それに伴い、向き合うべき課題も自然と変わってきているように思います。

XやQiitaを見ていても、プロダクト全体の価値提供やアウトカムに関する議論が増えています。実装速度だけを改善しても未来がないという感覚があり、そのうえで自分たちがどこに力を投資するべきかを再考する必要があるのかなと感じています。

Why（なぜ作るか）を見極めるためのデータ基盤づくり

神本：前後のフェーズのボトルネックを改善したいというのが一番大きな理由です。これまで2年ほどかけて、設計から実装、テストまでの、いわゆるプログラミングの専門性が必要な領域はかなり改善が進んできました。最近ではLLMの活用もあって、このプロセスはさらに速く進むようになっています。

そうなると、価値提供のスピードを今の何倍にも高めていこうとしたときに、「設計より前」と「テストより後」の工程を改善しないと限界が来ると感じました。設計〜テストは高速化したものの、「何を作るか」「なぜ作るか」といったWhat・Whyの部分が曖昧なままだと、プロダクトとしての価値提供に直結させることが難しい。

Jiraやスプレッドシートでも、チケットの予実（見積もりと実績工数）までは取っていましたが、フェーズごとの内訳までは踏み込めていませんでした。
設計より上流工程のチケットは一部だけ切られてのみで、設計からリリース運用までを一つのチケットとして扱い、3分類だけを付けていました。

• 攻：新機能開発や改善など新規価値創出につながるタスク類
• 守：不具合修正や保守運用など提供価値の維持につながるタスク類
• 走：勉強会やリファクタなど攻守双方の強化に繋がるタスク類

※ CTOの相澤が野球好きだったため、3分類する際に走攻守という表現を用いました笑

同じ“新規開発”の中でも、それが設計なのかテストなのか、といったフェーズごとの違いは見えていない状態でした。

さらに、1つのチケットが全体でどれくらいの時間を使ったかという実績工数や、着手前の見積もりは取っていましたが、それは巨大なマクロな指標でしかありませんでした。結果的に「どこから手をつければいいのか」が曖昧なままになる課題がありました。

相澤：当時はスプリントの予実を見て振り返りをしていましたが、差分が出ても「休みがあった」「時間が取れなかった」といった理由に寄ってしまい、本質的な改善にはつながりませんでした。差分があったとしても、プロジェクトに大きな問題が起きているわけでもない。改善ポイントが見つからず、着手のしようがなかったという感覚がありました。

神本：なぜ形骸化してしまったかというと、当時はマクロな最終指標ばかりを見に行っていたからだと思います。遅行指標なので、改善しても影響が出るのはだいぶ先になります。
ミクロなサイクルタイムやPRの数などを重視して改善が進んで、ようやく意味のある指標としてマクロの方を見に行けるようになったという感覚があります。

相澤：同時に、当時の自分たちは“改善すべきレイヤー”を間違えていた部分もあったと感じています。PRリードタイムやレビュー体制といった足元の改善がまだ十分でない段階で、プロセス全体の最適化に向き合おうとしても、扱う単位が大きすぎて、どこから改善すべきかが見えてきませんでした。
粒度の粗い課題を追いかけても、具体的な打ち手に落とし込めなかったのは、順番として早すぎたからだと思います。

Findy Team+を導入した当初も、今振り返ると同じ罠に陥っていたと思います。
以前、社外イベントで「生産性の数値を全部改善しようとしたら全部改善されなかった話」というテーマで発表したのですが、そのときはベロシティやデプロイ頻度と同じレイヤーでリードタイムも改善しようとしていました。
先行指標と遅行指標を整理しないまま一度に扱ってしまい、結果としてどれも改善しないという状態でした。そこから、まずはリードタイムに絞って取り組む方針に切り替えました。

実装フェーズの基盤が整って初めて、ようやくプロセス全体に目を向けられる状態になった、という感覚があります。

https://d-plus.connpass.com/

D-Plus｜開発生産性コミュニティ

Jira運用の見直しと、プロセスをチームに浸透させるための工夫

Jira運用の刷新でプロセスを“見える化”

相澤：元々のJira運用は、今とはまったく異なるものでした。
デプロイ頻度が週1回、あるいは2週間に1回だった頃は、スプリント中の変更をレビュー環境に上げ、スプリントレビューでPOと確認し、そこでリリースOK/NGをもらうフローでした。OKが出れば、貯めていたPRをまとめてデプロイするという形です。

ラベルの活用もほとんどなく、Epic単位で管理する程度でした。工数の入力も各自に任せていて、結局スプリントの最終日にまとめて入力されることが多かったと思います。チケットの分類も「攻・守・走」の3種類に分けていただけで、フェーズごとの違いは見えていませんでした。

神本：今回、プロジェクトプロセスタイム分析機能を活用するにあたって、まずはこの運用構造を大きく見直しました。Findy Team+でおすすめされている使い方を基本に、ストーリーを起点にし、そこにサブタスクを切る運用に切り替えています。

そのうえで、サブタスクには必ず4種類のラベルを1つずつつけるようにしています。

• 00：アウトカム（アウトカム分析用）
  • 開発によりどんなアウトカムが提供できるか
• 01：開発種別（投資分析用）
  • 新規機能開発/機能改善
• 02：開発フェーズ（プロセスタイム用）
  • 実装/設計/要件定義/テスト
• 03：開発領域
  • タスクがどの職能領域か

この4項目のうち1つでも抜けていると、プロセス全体の可視化ができなくなるため、必須ルールにしました。

“チケット入力大臣”が支える運用の定着

神本：運用ルールはドキュメント化したうえで、毎日の夕会（10分ほど）で全員で“今日のチケットを全件入力する”時間をつくっています。「各自やってください」では形骸化してしまうので、最初は同期的に全員でやる場を意図的につくりました。この時間の中で議論をしながら、定義の理解を揃えていきました。

相澤：若手のメンバーには“チケット入力大臣”を任せていて、夕会での声かけも担当してもらっています。若手が役割を持つことで当事者意識も生まれ、チーム全体として運用が定着しやすくなっていると感じます。

こうした任せ方は、もともとチームにあった文化でもあります。夕会に僕が入れないこともあるので、声かけだけなら若手でも十分にできますし、OJTの段階でこうした役割を担ってもらうことで、本人たちのやる気にもつながると思っています。成果を出せるようになったメンバーには、神本さんのように徐々に責任範囲を広げてもらっています。

神本：夕会での入力は今でも続けていますが、最近はそれぞれが空いている時間で自主的に入力するようになってきました。
夕会自体も短時間で終わるようになっています。

相澤：運用を浸透させるうえで大事だったのは、「なぜ今これをやるのか」を伝えることだったと思います。今までのプロセスがあるので、最終的に生産性の高いチーム（単純なコード量ではなく、プロダクトの価値を高められるチーム）を目指すために、まずはPRリードタイムなど足元の改善をやり切ってきました。そのストーリーを踏まえて、「次は上流工程に向き合うタイミングだよね」という話をすると、メンバーもすっと理解してくれました。

直近ではAIネイティブな要件定義や設計の話をチームと議論する場面もありましたが、「なぜ今やるのか？」という疑問は特に出ませんでした。実装フェーズを改善し、次に前後の工程を整えることでリリース頻度を高められる、という流れがチームとして自然に理解できていたからだと思います。

“なぜ”を伝え、上流を巻き込む

相澤：一方で、上流工程はまだ十分にチケット化できていません。要件定義やデザインの工程は、代表の坂本がPOとして外部デザイナーとやり取りしながら進めてますが、どれくらい時間を使っているのか、どのようなプロセスで決まっているのかがブラックボックス化していました。ここを可視化しない限り、プロジェクト全体のリードタイムは把握できず、今後のボトルネックになるので、コミュニケーションしていこうと思っています。

上流を巻き込むうえで大事なのは、「なぜ可視化するのか」「これをすると何が改善されるのか」を丁寧に伝えることだと思っています。同時に、どう効率化していきたいのか、チームとしてどんな理想像を持っているのかも共有する必要があります。

最近は、Figmaでプロトタイプを作る動きをチーム内で試しています。DXが進んでいる企業では、POが実際にプロトタイプを動かしながら要件を詰めていくフローを取り入れている例もあり、そうした働き方を参考にしながら、役割やプロセスの見直しにつなげたいと考えています。

全体像の見える化で“やらないこと”を明確に

相澤：可視化を始めてまだ日が浅いので、いわゆる“意味のあるデータ”として明確に読み取れるところは正直まだ多くありません。ただ、可視化しようとしたことでわかったことはたくさんあります。

まず、Jiraを含めたデータを正しく残しておかないと、そもそも可視化のスタート地点に立てないということです。ここに早い段階で気づけたのは大きかったと思います。

もう一つは、可視化しようとすることで、既存のフローのどこがボトルネックになっているのかが初めて浮き彫りになるという点です。例えば、デザイン周りについては、POが外部のデザイナーとやり取りしながら進めているのですが、その時間がどれだけかかっているのか、どんな工程を経ているのかが全く見えていなかったのです。
可視化したいと思った瞬間に、可視化に必要な状態になっていないと何も見えない。
これは、改善を進めるうえで非常に重要な気づきでした。

神本：広く見られるようになることで、“改善してもあまり効果が出ない領域”が見えるようになるのではという期待があります。振り返りをしていると、費用対効果が小さい改善に議論が集中してしまうことがよくあります。でも全体像がわかれば、改善しても全体に数％しか効かない領域に時間を使わなくて済む。つまり、“やらないこと”の意思決定がしやすくなるということです。

再現性を生むプロジェクトの型をつくる

相澤：プロジェクト全体の指標は、PRのリードタイムやサイクルタイムのように毎日追いかけるものではないと考えています。クォーターに1回、あるいは月1回といった粒度で、プロジェクトの進み方を俯瞰して確認するような使い方が適していると思います。サイクルタイムが短かったプロジェクトとそうでなかったプロジェクトの違いを振り返り、実装以外の工程にどのような差分があったのかを明確にすることで、改善すべきポイントがより早く特定できるはずです。

リリース頻度がより上がってくれば、2週間ごとなど、プロジェクトの実態に合わせたサイクルで評価することもできそうです。

また、プロジェクトプロセスタイム分析を活用してプロジェクトの“型”をつくっていきたいと考えています。例えば、要件定義なら「このくらいの期間に収まるのが健全」、設計なら「このサイクルに乗せるにはここまでに終えておきたい」といった基準値です。こうした型が見えてくると、メンバーがプロジェクト全体の進め方を判断しやすくなり、マネジメントの負荷も下がるはずです。最終的には、誰がプロジェクトを担当しても一定の再現性で進められる状態をつくり、個人の経験に依存せず、価値提供までのスピードを上げられる組織を目指したいと思っています。

神本：現時点では計測の下地がようやく整った段階ですが、ここから本格的に活用し始めるフェーズに入ります。半年後には成果をお伝えできると思いますので、乞うご期待ください。

今後一緒に働きたいエンジニア像とは？

単なる実装者や開発業務に閉じず、裁量を持って幅広い領域に関わっていける方と一緒に働きたいと考えています。
そして、プロダクトを技術による問題解決に閉じず、サービス全体で顧客へ価値提供をいかにして行うか?という視点で取り組める方が、ourlyのプロダクトづくりにはフィットすると思っています。

ourly株式会社のテックブログ
https://zenn.dev/p/ourly_tech_blog
開発生産性に関する取り組みなどをテックブログで発信しています！

---

※AI戦略支援SaaS「Findy Team+」のサービス詳細は、以下よりご覧いただけます。
https://jp.findy-team.io/