生まれた生産性で何してる？──週次PR数3倍の先にあった、企画〜開発プロセスの再設計

「生成AIで生産性が向上した」という事例は、ここ一年で急速に増えました。開発スピードの向上や工数削減の話は多く語られていますが、その先の「生まれた時間や余力を何に使っているのか」という議論はまだ十分とはいえません。

待ち時間が減ったことで、逆に疲労感が増したという声もあります。生産性の向上は、単なる“速さ”の問題ではなく、チームの持続可能性にも関わるテーマです。

本記事では、週次のマージ済みプルリクエスト（PR）数を3.2倍に伸ばした開発チームの取り組みを取り上げ、「生まれた生産性をどう再投資しているのか」を紹介します。

「AIツールを導入したのに、チームの生産性が思ったほど上がらない」「Cursorを使っているけど、正直コーディングだけ速くなっても……」──。こんな悩みを抱えていませんか？

はじめまして、宮田 芳郎（@eng_poets）といいます。医療系スタートアップであるファストドクター株式会社でEMを務めています。

この記事を通してお伝えしたいのは以下の3点です。

• 開発チケットの起票に使うAIアシスタントを作って共有する
• 週次マージ済みPR数などの「無理のない」数値目標を立てる
• スプリントレトロスペクティブで数値目標の達成状況を皆で見てKPT（Keep, Problem, Try）を共有する

まず、なぜAIコーディングの話ではなくて「開発チケットの起票」からなのかを説明したいと思います。

業務時間の中でコーディングに使っている時間は案外少ない

皆さんは1日8時間の中でどの程度コーディングに時間を使っていますか。EMを兼任しつつコードも書く私の場合、1〜2割ぐらいかと思います。エンジニアはコーディング以外にも設計、仕様の確認のためのコミュニケーション、QAの対応、1on1、不具合調査など、様々な業務を行います。コーディングにかける時間は全体の3～4割という方が多いのではないかと思います。

Cursorや Claude Codeなどのツールを使うことで3〜5倍程度はコーディングを速くできるように感じます。しかし私の場合、1割のコーディング時間が5倍速くなったとしても、たった8%の時間しか生み出されません、これでは1.1倍にも満たない計算です。40%をコーディングに使っている人でも1.2倍にしかなりません。

チームのスループットはボトルネックで決まる

開発生産性は「チームのスループット」として捉えるのが一般的です。コーディングのスピードがボトルネックなこともあれば、開発テーマがまだ降りてきていない、開発は終わっているものの検証待ちになっている、という状況もあるでしょう。コーディングがボトルネックだったのであれば開発生産性は高まりますが、他の工程がボトルネックだった場合、スループットの向上は起きません。

お伝えしたいのは、コーディングの枠内だけでAIを使っていても開発生産性の向上にはつながりにくいということです。各工程のスループットをバランスよく高めるための初手として「開発チケットの起票に使うAIアシスタント」の構築がよいのではと考えています。

あるある：いったんタイトルだけチケットを作っておく

チケットの起票を担当するのは、プロダクトマネージャーやテックリードが多いと思います。これらの役割の人は、残念ながら作業時間が全然足りません。会議と会議の間に、忘れないようにタイトルだけの開発チケットを作っていることも多いのではないでしょうか。

あうんの呼吸で回るチームもあるとは思いますが、十分な情報量のない開発チケットは、一般的に次のような副作用を生みます。

• 確認のためのコミュニケーションコスト
• ゴール条件などの認識ズレによる手戻り
• QAメンバーへも説明の時間が必要となる
• 不具合としてリリースされた時の対応コスト

心理的には負い目も感じやすく、リーダーの自己肯定感を下げ続ける悪循環にも陥りやすいと感じています。逆に捉えれば、「短い時間で十分な詳細度の開発チケット」が作れれば、工程横断的に時間を生み出すことが可能になります。

チケット起票AIアシスタントの構築

• チケットのフォーマットを決める
• 情報のソースに接続できるMCPサーバーを設定する
• チケットを起票するSubAgentやコマンドを作る

▼今の開発チームのテンプレート

📋 概要

ユーザーストーリー
[ユーザー役割]として、[達成したいこと]を行いたい。
それによって[得られる価値]。

背景
[このストーリーが必要となった背景や問題点]

📝 詳細

機能要件
[機能や要件の詳細説明]

受け入れ基準

• テスト可能な条件1
• テスト可能な条件2
• テスト可能な条件3

🎨 UI/UX要件（該当する場合）
[画面の変更点やモックアップへのリンク]

🔧 技術的考慮事項（実装時の注意点）

システム依存関係
[既存システムとの依存関係]

影響範囲
（※起票時のAIによる推定です※）
[変更による影響を受けるコンポーネントやサービス]

✅ 事前条件
[このストーリーを開始する前に必要な条件]

👥 関係者

要求・仕様確認先チーム
要求確認が終わったらチェックしてください

• XXXX
• YYYY
• ZZZZ

リリース時連絡先チーム
リリース時に連絡が必要なチーム

• XXXX
• YYYY
• ZZZZ

📅 リリース計画

リリースタイミング
[予定リリース日やスプリント]

リリース後の影響
[リリース後にユーザーや運用に与える影響]

在宅事業の開発チームにいた時にチームメンバーが作ってくれたフォーマットをベースにしています。重要な観点は、以下が端的に記述されていることです。

• なぜ取り組むのか
• Goal条件
• どの辺り修正するのか

情報のソースに接続できるMCPサーバーを設定

当社では、

• コミュニケーションはSlack
• 情報のストックはNotion
• 開発チームのタスク管理はJIRA

を用いています。これらのMCPサーバーは設定してもらうようにしています。

チケットを起票するSubAgentやコマンドを作る

仕組み化されたものがあればいいと考えており、手法はCommandやSubAgentなど、何でもよいと思います。私はフォーマットが決まっているものに関しては、Claude CodeでSubAgentを生成する機能を使って作ることが多いです。

開発チケットの詳細を記述するAgentです
フォーマットはdocs/template/JIRA-Ticket-template.md

• 既存の実現箇所や既存のソースコードを参照して必ず確認してください
• コード例は記述しないでください（影響範囲の記述は良い）
• JIRAに投稿する際にはJIRAでの記法に注意してください
• 不明点は必ずユーザーに確認してください
• 指定がない場合にはJIRAのプロジェクトコードはPJ-XXを利用してください

開発チケットの記述に当たっては、例えば以下のように依頼をします。

@JIRA-Ticket-Detailer-agent

○○機能の開発についてチケットの起票をしてください。

議論したスレッド：XXXX
事業部からの要望資料：XXXX

目標の設定と会議体の運営

何を測るか

測る対象は「チームメンバーと取り組みを評価する人が意義を感じられるもの」であれば何でもよいのですが、当社ではマージ済みPR数にし、重複して計測されないようにラベルを付けて管理しています。

マージ済みPR数は細かくすれば数字を稼げてしまうのですが、PRはできるだけ小さくしようという開発チームの価値観があるので、これに落ち着いています。

インパクトのある数字を目指しつつ、無理のない目標を立てる

チームの過去半年のマージ済みPR数の平均をスタートラインとして、3カ月で200％向上する目標値をセットしました。200％は高いと感じますが、前の開発チームでは320%を達成できていたので現実的に到達可能だろうと考えてセットしました。

3カ月で達成するには、週次で2件ずつマージ済みPR数を増やす必要があるため、週次で2件ずつ数値を増やしています。

※年末年始を除き、全週で目標を達成

レトロスペクティブ（振り返り会）で数値目標の達成状況を皆で確認し、KPTを共有する

2週間後の振り返り会の冒頭で数値目標の達成状況を共有しています。
参加者：プロダクトマネージャー、デザイナー、エンジニア、QA

数値の状況も踏まえて、Keep、Problem、Tryをメンバーごとに出していきます。

運営の中で、皆でボトルネックが変わったかどうかを話すことが重要です。当チームでは、2025年11月後半から明確にQAの不足が見えてきたため、QAに入るタイミング調整の会議体を新設するなどの取り組みを行いました。

開発のスループットが高まった結果として、チケットも不足する傾向が出てきたため、E2Eテストの構築の検証など外部仕様に依存しない開発主導で実施できる（が長期的に価値のある）チケットを追加することもあります。

10倍を目指して：生まれた時間で取り組んでいること

企画/要求定義フェーズからのAI活用

一般論として、開発プロセスを詳細に定義した方が品質は作りやすいです。ただし、（1）ドキュメントやレビューで時間がかかる、（2）解像度が低い状態で定義したゴールが外れやすい──といったデメリットがあります。

その反動としてアジャイルが提唱されました。仮説段階でコーディングを始めて、スプリントを繰り返すことで精度を高めていくアプローチが取られることが多くなりました。

「ユーザー体験向上」など、答えが見えない開発テーマには取り組みやすくなりましたが、人やコミュニケーションを重視する開発手法なので、「誰がやるか」に依存しやすいなと感じています。また、現実的にワークするチームサイズへの制限があり、「大きなものをちゃんと作る」シーンでは成功確率を上げづらいと感じていました。

プロセスとアジリティの良いとこどりのAI活用の形〜

そこでわれわれは、10倍以上の開発生産性向上に向けて、「AI利用を組み込んだ開発プロセスの標準化」を定義することで、プロセスによる品質向上とアジリティの良いとこどりができないかと考えています。

（1）工程ごとのドキュメントのフォーマットを定義、（2）ドキュメントごとにSkillやAgentを構築してAIの支援で効率を向上──。企画からデリバリーへの流れを早くするとともに、得られたフィードバックから次の打ち手を高速に打ち出す体制が作れないかを模索しています。

上記のAIを軸にした開発プロセスの構築以外にも、以下にも取り組んでいます。

• 事業計画書をCodexで「貢献すべき差分」に着目して、エンジニア（＆AI）がわかる内容に書き替えてもらう
• VoC（顧客の声）をDB化し、MCPサーバーでアクセスできるようにして、仮説の数を増やす

形になったら今後紹介したいと思います。

AI疲れの因数分解

最後に私のAI疲れの対処法について、ご紹介します。AIが期待通りの仕事をしてくれない時、今から自分でこれをやり直すかという状況が繰り返されると、心理的にはぐっと来るものがあります。AIが便利に使えていることが多いからこそ、期待と違った時のストレスは高いです。私なりの対処法を説明します。

なぜ期待通りに動いてくれないのか

これまで取り組んできた中で、期待通りに動かない主な原因は次の3つだと感じています。

• 完了条件が不明確
• 指示が不足している
• コンテキストが不足している

完了条件が不明確な問題には、先ほどのJIRAチケットのテンプレートのように、フォーマットの中に完了条件が記述され続けるようにするのがいいと思います。指示不足については、難しそうと思うものには、ひとまずPlanモードを使って質問してもらうのがいいと思います。

コンテキストの不足～使い込むほどに性能が落ちる?

設定が作り込めるClaude Codeで特に顕著だと感じるのですが、最初に使い始めた時の「すごい……！」という印象から、徐々に性能が落ちている印象がありました。存在しない人名を挙げるなど、ハルシネーションが起きやすくなっていました。

ふと思い立って /context コマンドを実行してみると、何も指示していない起動直後の状況で200kのコンテキストを超過していました。特にインパクトが大きかったのはMCPサーバーです。また、作成したCustomAgentも影響がありました。

必要なMCPサーバーに絞った上で、こまめにMCPサーバーのオンオフをすることか、まだβ機能ですが、ENABLE_EXPERIMENTAL_MCP_CLI=trueを指定することで、回避できました。

AIへの期待値を下げる。エージェントではなくアシスタントとして関わる

心理的なつらさが出るのは「期待したのに動かなかったから」です。ここまで記述したのは「動かない」ことへのアプローチですが、自分の気持ちをマネジメントして「期待しない」ことも効果的だと思います。

また個人的には「AIエージェント」と思わずに「AIアシスタント」だと思うようにしています。自分が答えのイメージを持っていることを、指示を咀嚼して実施してくれる主体のイメージです。

たたき台と割り切って自分がイメージを持てていないことをお願いすることもありますが、基本的に自分が明確に指示できること、ゴールイメージを持てていることを中心に依頼するようにしています。

まとめ

AI駆動開発で成果を出すポイントを振り返ります。

1. コーディングではなくチケット起票から始める：ボトルネックは案外コーディング以外にある
2. 無理のない数値目標と振り返りの仕組み：週次2件ずつ増やすぐらいの現実的な目標
3. AI疲れへの対処：期待値を「エージェント」から「アシスタント」に下げる

まだ試行錯誤の途中ですが、一つの事例として参考になれば幸いです。