何のために、何を作っているのか
毎月のレポートは、この1枚に対してどれだけ進んだかを測るためにある
作っているのは便利なシステムではなく、事業のブレインを育てるプラットフォームである。面談・面接・商談で毎日生まれている現場の事実を、吸い上げ → 貯め → AIが磨き → 判断し → 武器として届ける。使った結果がまた生データに戻る、複利の循環を作る。
動かしたい数字（売上の公式）
売上 ＝ CA数 × 1CA集客 × 企業紹介数 × 内定率 × 承諾率
パイプラインは目的ではなく、この式を動かすための水路である。数字なき機能は作らない —— 各月のレポートで「重要度」を判定するときの基準もこの式である。
8つの持ち場（STATION）と、いまの通水状況
水源 → 取水 → 貯水 → 浄水 → 配水。どこで水が止まっているかを見る
docs/roadmap/03_current-status.md（master 基準・2026-07-23）に8月以降の変更を重ねたもの。ST.4 から先が、いま手つかずの区間である。直近のマイルストーン
「できている状態」から逆算して置いたもの
| 期限 | できている状態 | 状態 | 効く数字 |
|---|---|---|---|
| 8月末 | A. KPI を実データで見る管理画面 PGチームが売上公式のKPIを実データで見られる | 未達 | 全数字の計測基盤 |
| 8月末 | B. バックエンド移行（Pigeon → Supabase） 主要機能がSupabaseで動き、本番切替を判断できる | 未達 | —（後続すべての前提） |
| 8月末 | C. CAに渡せるコンテンツの大量作成 研修・マニュアル・選考対策がシステム内にある | 未達 | 内定率 ↑ / CA生産性 ↑ |
| 8月末 | D. 面談データが漏れなく貯まる状態 文字起こしの格納率が数字で見える | 一部 | 承諾率 ↑ / 歩留まり ↑ |
| 9月末 | E. システム/CAからの学生個人情報登録 CAが管理画面から新規登録を完結できる | 未着手 | 企業紹介数 ↑ |
| 9月末 | F. 企業DBの作成（生データ → 加工データ） 企業プロファイルをDB上で生成・保存できる | 一部 | 企業紹介数 ↑ / 内定率 ↑ |
8月末マイルストーンは30項目中0達成
実装が難しくて止まったのではない。A は決めるべき定義が決まっていない。B は移行の意思決定が要る。C は中身が社外にある。D は測るという発想が誰のタスクにもなっていない。止めているのはコードを書く力ではなく、その手前にあるものである。
作った機能は、運用に乗っているか
月ごとに作った機能を1単位ずつ追い、乗っていないものを名指しで見つける
毎月のレポートで束ねた「機能単位」に、ユーザーが答えた運用状況（乗っている／一部だけ／乗っていない）を重ねた一覧。回答は月末のチェックシートで集め、翌月にもう一度聞く。乗っていないものは「時期でない／伝わっていない／業務に合わない」のどれかを聞いて理由を残す。このタブは最新の回答を映す。月次レポートの04章は、その月を締めた時点の値を固定して載せる。
全27機能の状態（1マス = 1機能）
領域ごとの盤面
持ち場（STATION）の通水図と同じ見方。バーが塗られていれば運用に乗っている
判定はユーザーの回答をそのまま載せている（推測で埋めない）。データ元は docs/reports/2026-08/adoption.tsv。翌月に同じ機能をもう一度聞き、乗ったかどうかを追う。
全体サマリー
この4日間で何が起きたか
8月末に着地した請求・課金まわりの詰めが中心の4日間だった。承諾日・辞退日の自動記入（#946）、金額が空でも請求行を作る（#960）、課金対象を面談ごとに保存（#945 #953）など、8月に作った仕組みを実運用に合わせて詰めている。
一方でQ2（未来への投資）は16本中1本。8月の21%から大きく落ちている。4日間の数字なので断定はできないが、「作ったものの後始末」で帯域が埋まる月の入り方になっている点は注意しておきたい。
スピードチェック
PRの数と、その中身の内訳
月別 マージPR数（2026年）
development 宛・マージ済みのみ。1〜3月はリポジトリの履歴が無い（最初のコミットは4月3日）。9月は 9/4 時点の途中経過。
領域別 PR数（9/1〜9/4）
クオリティチェック
どういう種類の仕事をしたか / それは運用に乗ったか
重要度 × 緊急度（n=16）
縦軸＝売上公式を将来動かすか。横軸＝今月やらないと業務が止まるか。「低」は価値が低いという意味ではなく、今の業務を回す仕事という意味。
守りの仕事
212.5%テストが実SMTPへメールを送る事故の停止（#970）／過ぎた面談の一括ステータス移行（#968）
未来への投資
16.3%Pigeonの【All】系通知6件をアプリ内Slack送信へ移行（#974）。データ資産に効いた分は0本。
今月を回す仕事
1381.3%請求4／通知3／管理画面3／集客パートナー2／Pigeon設定1。8月に作った仕組みの詰めが大半。
磨き込み
00%なし。
作ったものは、運用に乗ったか
9月分の機能単位のチェックは、月末に作成します。8月分については下の「2026年8月」タブを参照してください。
来月あたりやったほうがいいこと
9月の残りと10月に向けて
Q2（投資）に固定枠を置く
4日間でQ2が1本という入り方は、放っておくと月末までこのままになる。「今週はこの1本を投資枠に使う」を週の頭に決めるだけで変わる。目安はPRの2〜3割。
EFFECT8月末マイルストーンが0達成だった構造の是正
請求・課金まわりの「詰め」に終わりを設定する
8月から通算すると請求・売上は35本（8月31 + 9月4）。仕様が動き続けている状態なので、いったん「ここまでで完成」と線を引くと、後始末に食われる帯域が止まる。
EFFECTQ3を減らし、Q2の枠を空ける
8月に作った27機能のうち、乗っていない16本の引き渡しを決める
8月分の運用チェックが埋まり、乗っているのは6本（今の手順のまま使えるものと社内ツール）、乗っていないのは16本と分かった。請求・売上の7機能は0本。乗せるか止めるかを機能ごとに決め、理由を3択（時期でない／伝わっていない／業務に合わない）で残す。
EFFECT「作る」から「使われるようにする」へ打ち手が変わる。10月に作るものの優先順位が数字で決まる
組織的な課題
誰が、どこを書いているか
PRの作成者内訳（1マス = 1 PR、n=16）
この月に新しく見えた組織的な論点はまだない。8月に出した4つの課題（1人＋2領域の構造／合流点が1つ／現場要望が優先順位の層を通らない／渡せる単位への投資）がそのまま継続している。詳細は「2026年8月」タブの05を参照。
全体サマリー
8月に何が起きたか
出力は前月の3.0倍になり、請求・売上、集客パートナー管理、ゲスト予約、開発基盤の4つに集中した。現場が今日から使える機能は確かに増えている。
一方で、その69%は「今月やらないと業務が止まる」種類の仕事だった。中長期の数字に効く投資は21%で、そのうち大半が開発基盤そのもの。8月末に「できている状態」として置いた30項目のうち、達成できたものは0である。
スピードチェック
PRの数と、その中身の内訳
月別 マージPR数（2026年）
development 宛・マージ済みのみ。1〜3月はリポジトリの履歴が無い（最初のコミットは4月3日）。9月は 9/4 時点の途中経過。
領域別 PR数（n=175）
できるようになったこと
請求・売上
31本- 請求書のデータ元をGoogleスプレッドシートから Pigeon へ移設。承諾者リストを起点に発行・PDF出力・複数月の統合発行まで画面で完結 #767 #805 #810 #814
- 発行済請求書をプレビュー付きでメール送付（PDF添付・担当RAへCC・宛先の複数登録） #872 #920
- 対応状況を未送付／送付済み／入金確認済み／出金済みで管理 #831 #916
- 内定承諾・辞退で請求管理レコードを自動作成 #768
- 集客パートナー請求書を月×パートナー単位で発行 #871 #878
- 売上管理：月次サマリ・目標入力・達成率・グラフ #841 #856 #869 #873
これまで：社外スプレッドシートと手作業。発行漏れ・送付状況は担当者の記憶に依存していた。
予約・面談
25本- LINEログイン不要のゲスト予約。電話アポ運用でその場で枠を押さえられ、後日LINE連携で名寄せされる #653 #659 #898 #906 #908
- 対法人（企業）予約ページと法人面談履歴・文字起こし閲覧 #782 #796
- ロスター全員が同席する「全員が参加式」 #815 #819
- 会員詳細の「面談予定／履歴」タブとステータス名の統一 #808
- 予約ページごとの事前アンケートで担当CAを出し分け #576 #588 #826
これまで：LINE連携が前提で、電話アポ経由の学生は予約に乗らなかった。
集客パートナー・管理画面
26本- 旧ページを廃止し集客パートナー管理ダッシュボードへ一本化 #850 #853
- 課金対象を面談ステータスから自動導出（キャンセル・無断欠席は対象外、未実施は「未判定」） #893 #904
- パートナー本人に自分の送客分だけを閲覧専用で開放 #936 #940
- 会員フェーズを実態から自動更新 #809
- Pigeonの左メニューのCS業務を運営モードの4画面へ移行 #561 #630 #744
これまで：送客実績と課金可否の判断が、手元集計と口頭確認に載っていた。
安全性・権限
17本- コードベース全体レビューを起点に未認証で個人情報を出力できるエンドポイントを塞いだ #723 #736 #761
- SMS認証の総当たり対策・なりすまし可能な共有URLの是正・GETでの退会実行の修正 #700 #702 #724
- 他代理店のデータを読み書きできたテナント分離の欠落を修正 #752 #769 #770
- 本番データを読み取り専用・個人情報マスクで調査する仕組み #925 #931 #932
これまで：発見されていなかった。潰し始めた段階で、未対応の指摘が11件残っている。
AI機能・データ取得
8本- AI企業作成（Web検索ONなら資料が薄くても生成可） #783 #790
- AI求人作成の出力改善（網羅性・保存前プレビュー） #645 #715
- 求人単位の DeepResearch を自動化し資料まで生成 #619
- Zoomの録画完了Webhookで文字起こしを取得・保存 #777 #844
この8本が事業の中長期の数字（データ資産）に効いた分。全体の 4.6% にとどまる。
開発基盤・自動化
43本- issueを自動実装してdraft PRまで通すパイプライン #579 #690 #696 #714
- 3段レーンと品質ゲートの変更スコープ判定で1本あたりの固定費を削減 #564 #575 #580
- Slackからのプレビュー起動、マージ通知に「何を解決したか」を載せる #749 #797 #843 #860
- 非エンジニア向けのモックプレビュー #732
8月にマージしたPRの 4本に1本が、機能ではなく「作る仕組み」への投資だった。
クオリティチェック
どういう種類の仕事をしたか / それは運用に乗ったか
重要度 × 緊急度（n=175）
セルの濃さは件数に比例。「事業インパクト：低」は価値が低いという意味ではなく、今の業務を回す仕事という意味。
守りの仕事
4123.4%個人情報の露出・テナント分離（17）／本番障害・テスト赤・デプロイ停止（10）／請求の誤り（3）／Zoom・Googleの審査対応
未来への投資
3721.1%開発基盤（25）／AI（5）／面談データ（1）／その他（6）。37本中25本が開発の仕組みで、データ資産に効いたのは実質4本。
今月を回す仕事
7945.1%請求27／予約20／集客パートナー10／管理画面9／通知7ほか。現場要望がそのまま開発に入る区画。
磨き込み
1810.3%見た目・文言・軽微なUX。まとめて出せば帯域を食わない領域。
いちばん重要な発見
「未来への投資」に見えるQ2の37本を開くと、25本（68%）は開発基盤そのものだった。事業のデータ資産（面談ログ→学生カルテ→判断エンジン）に直接効いたのは、DeepResearchの自動化（#619）、Zoom文字起こしの取得（#777）、AI企業作成（#783 #790）の実質4本にとどまる。
つまり8月は「作る速度を上げる」ことと「今月を回す」ことに帯域を使い切り、「作るべきものを前に進める」には手が届かなかった月だった。
作ったものは、運用に乗ったか
8月の175本を27の機能単位に束ね、機能ごとに「運用に乗っているか」をチェックシートで確認した（回答日 2026-09-04）。結果は乗っている 6本・一部だけ 5本・乗っていない 16本。作った機能の59%が、まだ現場で使われていない。
| 領域 | 機能数 | 運用に乗っている | 一部だけ | 乗っていない | もう使わない | 未回答 |
|---|---|---|---|---|---|---|
| 請求・売上 | 7 | — | 1 | 6 | — | — |
| 集客パートナー | 3 | — | 1 | 2 | — | — |
| 予約・面談 | 7 | 3 | 1 | 3 | — | — |
| 管理画面・権限 | 2 | — | 1 | 1 | — | — |
| AI・データ | 4 | — | 1 | 3 | — | — |
| LP・社内ツール | 4 | 3 | — | 1 | — | — |
| 領域 | 機能（できるようになったこと・根拠PR） | 運用状況 | メモ |
|---|---|---|---|
| 請求・売上 | 請求書の発行（承諾者リスト起点） 内定承諾者の一覧から請求書を作り、右プレビューを見ながらPDFまで出せる。複数月をまとめて1枚で発行することもできる。 #805 #810 #814 #816 #851 | 乗っていない | — |
| 発行済請求書の一覧と消し込み 発行した請求書を一覧で管理し、対応状況（未送付／送付済み／入金確認済み／出金済み）を更新できる。PDF再出力・編集・削除も可能。 #785 #831 #916 | 乗っていない | — | |
| 請求書のメール送付 発行済請求書を、本文プレビューを見ながらPDF添付でメール送付できる。担当RAへ自動CC、宛先の複数登録に対応。送信すると対応状況が「送付済み」に進む。 #872 #876 #920 | 乗っていない | — | |
| 集客パートナー請求書（支払通知書） 当社が代行作成する支払通知書を、月×パートナー単位で発行できる。対象学生の一覧と金額を画面で入力する。 #871 #878 | 乗っていない | — | |
| 内定承諾からの請求レコード自動作成 エントリーのステータスが内定承諾／承諾後辞退に変わった時点で、請求管理のレコードが自動で作られる。 #768 | 乗っていない | — | |
| 売上管理（月次サマリ・目標・グラフ） 月次の売上実績と目標を入力し、達成率・実績×目標グラフ・累計推移を「合計／自社CA／PG」で切り替えて見られる。 #841 #856 #869 #873 | 乗っていない | — | |
| 単価・卸価格の画面修正 承諾者一覧から単価・卸価格を直接修正できる（発行済み書類の材料はロック、金額変更にはメモ必須）。 #864 | 一部だけ | — | |
| 集客パートナー | 集客パートナー管理ダッシュボード 集客経路ごと・CAごとの新規面談実績を1画面で見られる。卒業年での絞り込み、運営専用メモつき。旧ページは廃止済み。 #850 #853 #832 #863 | 乗っていない | — |
| 課金対象の自動判定 面談ステータスから課金対象かどうかを自動で決める。キャンセル・無断欠席は対象外、未実施は「未判定」と表示される。 #893 #903 #904 | 一部だけ | — | |
| 集客パートナー本人への開放 パートナー本人が、自分の送客分だけを閲覧専用で見られる（課金ダッシュボードと初回面談一覧、課金対象外理由まで）。 #936 #940 | 乗っていない | — | |
| 予約・面談 | ゲスト予約（LINEログイン不要） 電話アポ運用のパートナーが、LINE連携なしでその場で面談枠を押さえられる。後日LINEログインすると同一人物として名寄せされる。メールからのキャンセル・再予約にも対応。 #653 #659 #898 #906 #908 | 一部だけ | — |
| 対法人（企業）予約ページ 企業向けの予約ページを発行でき、会員登録なしで面談履歴を企業に紐づけられる。法人面談の文字起こしも閲覧できる。 #782 #796 #813 #826 | 乗っていない | — | |
| 全員が参加式（全CA同席） 予約ページの割り当て方式として、ロスター全員が同席する枠を選べる。学生向け・法人向けの両方で使える。 #815 #819 | 乗っていない | — | |
| 予約時アンケート 予約ページのカレンダーごとに事前アンケートを設定し、回答によって担当CAを出し分けたり、対象外の方をお断りしたりできる。 #576 #588 #622 | 乗っていない | — | |
| 会員詳細の面談タブ 会員詳細に「面談予定／履歴」タブができ、CAが予約中／実施済み／キャンセルのステータスを画面から変更できる。表示名も統一済み。 #618 #808 #837 | 乗っている | — | |
| 会員フェーズの自動更新 会員のフェーズが面談・エントリーの実態から自動で更新され、手動操作はリリース／リリース解除だけになった。 #809 #839 | 乗っている | — | |
| 面談前日リマインド 初回面談の前日18:00に、LINE（未連携の方にはメール）でリマインドを送るバッチ。※cron登録がインフラ作業として残っている可能性あり。 #568 #755 #759 | 乗っている | — | |
| 管理画面・権限 | 運営モード（CS業務の移行） Pigeonの左メニューでやっていたCS業務を、運営モードの会員・エントリー・企業・求人の4画面へ移行。絞り込みと表示ビューの保存、操作履歴・変更履歴の閲覧つき。 #561 #630 #744 #824 #867 | 一部だけ | — |
| アシスタント権限 代理店内を横断して閲覧だけできる読み取り専用の権限を追加（機微項目は非表示）。 #760 #769 #770 | 乗っていない | — | |
| AI・データ | AI企業作成 運営が企業レコードをAIで下書きできる。Web検索をONにすれば、手元の資料テキストが薄くても生成できる。 #783 #790 | 乗っていない | — |
| AI求人作成の改善 AI求人作成の出力を改善（セクション可変・網羅性の向上・選考フローの番号付け・保存前に実サイト同等のプレビュー）。 #645 #715 #716 | 乗っていない | — | |
| 求人DeepResearchの自動化 求人単位の調査を自動で回し、CA向け・学生向けの資料まで生成する。 #619 | 乗っていない | — | |
| Zoom面談の文字起こし自動取得 Zoomの録画完了WebhookでNoteへ文字起こしを保存する。取得が「取得中」のまま固まる不具合も解消済み。 #777 #844 | 一部だけ | — | |
| LP・社内ツール | LPクリック計測 LPの問い合わせ文面のクリックを計測する仕組み。受口をVercelからPHPへ移し、スキャナの誤検知も対策済み。 #784 #804 #894 #922 | 乗っていない | — |
| CA画面のUIプレビュー 非エンジニアがdevサーバーに触れずにCA画面のUIを比較できるモックプレビュー。 #732 | 乗っている | — | |
| 本番データの読み取り専用調査 本番データを読み取り専用・個人情報マスクで調査できる仕組み（/prod-probe）。 #925 #931 #932 #935 | 乗っている | — | |
| issue自動実装パイプライン ラベルを付けたissueをAIが自動で実装し、draft PRまで通す仕組み。停止・再開の自動回収とSlack通知つき。 #579 #690 #692 #696 #714 | 乗っている | — |
乗ったのは「今の手順のまま使えるもの」。乗っていないのは「人が手順を変えて使うもの」
運用に乗った6本は、会員フェーズの自動更新・面談前日リマインド・会員詳細の面談タブ（予約・面談）と、CA画面のUIプレビュー・本番データの読み取り専用調査・issue自動実装パイプライン（社内ツール）。前者はCAが毎日開く会員詳細に足したものと、入れれば勝手に動く自動処理。後者は作った本人たちが使う道具で、どちらも使い始めるために誰かの手順を変える必要がなかった。
一方、事業機能で最大の領域だった請求・売上（7機能・31本）は乗っているものが0本、一部だけが1本。集客パートナー管理・法人向け予約・AI生成（企業・求人・DeepResearch）も乗っていない。共通するのは、現場の誰かが今のやり方を置き換えて使い始める必要がある機能だという点である。
メモは全件空欄のため、乗っていない理由はこの資料では判断しない。「まだ使い始める時期でない」のか「使い方が伝わっていない」のか「作ったものが業務に合っていない」のかで打ち手が変わるので、9月の確認ではこの3択で理由を聞く。
開発の流れ — 最短で運用に乗せたいときの型
全員に同じやり方を求めるものではない。速さが欲しいときに選べる選択肢として置く
開発は「依頼者がイメージを持つ → エンジニアが形にする → 依頼者がレビューする」の3段で進む。ここで変えられるのは1つだけで、依頼の段階でどこまで作り切ってから渡すかである。作り込みが浅ければ、その分の決めごとを開発が引き受ける。深ければ、開発は実装に集中できる。
どちらが正しいという話ではなく、速さと自由度のトレードオフである。じっくり相談しながら固めたい依頼もあるし、それで困っていないなら変える必要はない。以下は「早く運用に乗せたい」ときに選べる型として読んでほしい。
依頼をどこまで作り切ってから渡すか
箱の横幅は、その工程が引き受けている「決めごと」の量。どちらの型も成立する。
B を選ぶなら、依頼のときに埋める4項目
「作ってほしいもの」ではなく「どう運用に乗るか」を先に書く。4つ全部そろっていなくてもよい。埋まっている数だけ往復が減る、という性質のものである。
誰が使うのか
役割で書く（CA / 運営 / 代理店管理者 / 集客パートナー / 学生）。ここが決まると、権限と画面の置き場所が自動的に決まる。
いつ使うのか
業務のどのタイミングで開く画面か。毎日か、月末だけか、特定の申し込みが来たときか。
使い始めるのに何が要るか
設定・初期データ・周知・教育。Pigeon 側の項目追加が要るなら、それも依頼のうちに入れておくとリリース当日に止まらない。
使われていると、どう分かるか
件数・画面の利用・現場の声。ここがあると、完成後に「乗ったかどうか」を確かめる先ができる。
8月のデータで、この型が効きそうなところ
| 起きたこと | 数字 | 読み取れること |
|---|---|---|
| 請求まわりの仕様が1か月で7手動いた 承諾者リストの新設 → 複数月の統合発行 → ページ再構成 → 発行操作のプルダウン化 → 対応状況の追加 → 課金単位を会員から面談へ組み替え → 会員側の課金状態を廃止 |
31本 +9月4本 |
作り直しは学習として正しく、この領域は探りながら進むのが自然だった面もある。ただし1手ごとに判断待ちが発生しているので、次に似た規模のものを出すときは B が効く候補になる |
| 作った27機能のうち16本が運用に乗っていない | 16 / 27 | 乗ったのは今の手順のまま使えるものと社内ツールに偏る。04（使われていると、どう分かるか）を依頼時に1行決めておけば、引き渡しの段取りが最初から入る |
| 「今月を回す仕事」が最大区画 | 78本 / 45% | 要望がそのまま開発に入る導線しかない。依頼を作り切る場を「使いたい人が使えるオプション」として用意するのが、いちばん軽い一歩 |
やりたいのは、選べる状態を作ること
AI で実装は速くなったが、律速しているのは人間が処理する判断と往復の量である。 渡せる単位を作るというのは、技術的な境界を引くことであると同時に、依頼のイメージを作り切ることでもある。
ただしこれは全員に同じ手順を課す話ではない。B の型を用意しておいて、 「これは急ぎたい」「完成したらすぐ使いたい」と思った人が、そのときだけ選べる——それで十分に効果がある。 A のままで回っている依頼を、わざわざ B に寄せる必要はない。
来月あたりやったほうがいいこと
9月に向けて出した打ち手
計測を先に置く（マイルストーンA）
売上公式の各項を「どのテーブルのどの値から算出するか」まで落とし、集計APIを実装して、雛形のままのダッシュボードを実データに配線する。数字が無い限り、優先順位の議論は毎回ゼロから人の主観でやり直しになる。
EFFECT全数字の計測基盤 / 合意コストの恒久的な低下
材料をシステムの中に入れる（ST.3 → ST.4）
企業・求人「研究ノート」の基盤を足がかりに、企業の生データ置き場を作り、社外にある企業MD 116社・代理店MD 53社・ノウハウ辞典14冊を取り込む。学生MDの材料はすでに揃っている。
EFFECT企業紹介数 ↑ / 内定率 ↑。同時にAIへ丸ごと渡せる仕事を作る
Supabase移行を「速度のための投資」として位置づけ直す
いま移行は「DBの載せ替え」に見えているが、実態は外部SaaSの管理画面作業をコードに閉じ込める施策である。スキーマ変更がコードとマイグレーションで閉じれば、リリースまでAIで完結でき、CIでテストも走るようになる。
EFFECT人間の手作業の回数を恒久的に削る
合流点を広げる
PRのレビューとマージが1人に集中している限り、上流をいくら並列化しても頭打ちになる。領域別に2人目のレビュー担当を置く、PR本文の「非エンジニア向け」節を使って事業側が仕様面だけレビューできる範囲を切り出す、の2本立て。
EFFECTスループットの上限そのものを上げる
組織的な課題
誰が、どこを、どれだけ書いたか
PRの作成者内訳（1マス = 1 PR、n=175）
| 担当 | PR数 | 主な領域 | 読み取れること |
|---|---|---|---|
| Shosuke24 | 161 | 請求・予約・集客パートナー・安全性・開発基盤・AI — 全領域 | 設計・実装の指示・レビュー・マージがこの1人に集中。AIの並列度を上げても最後は必ずここを通る |
| denhdknis | 13 | 運営モード（管理画面CRUD）／通知移行 | 領域が固定され独立して回せている。唯一「丸ごと渡せている」区画 |
| moraine8 | 1 | 本番YAML・デプロイ | インフラ側のスポット対応のみ |
「1人＋2領域」構造で、増員が効く形になっていない
denhdknis の13本は運営モードに固まっており、独立して回っている。領域を切り出して渡せば手離れすることは実証済み。それでも他が渡せないのは、能力ではなく渡せる単位に切れていないから。請求・予約・課金は「誰にいくら請求するか」という事業判断と直結していて、その判断がコードにもissueにも書かれていない。
打ち手運営モードを手本に、次は「予約・面談」を1領域として切り出して渡す
合流点（レビューとマージ）が1つしかない
175本は例外なく人間のレビューとマージを通っている。営業日あたり約8本。AI側の並列度は上げられたが、受け止める側は1人のままなので、ここがスループットの上限になっている。
打ち手領域別に2人目のレビュー担当を置く／事業側が仕様面だけ見る範囲を切り出す
現場の要望が、優先順位の層を通らずに直接開発へ入っている
Q3が78本と最大になったのは、要望→issue→実装が最短距離でつながっているから。速さとしては良いが、「今やらなくてよい」と判断する層がないためQ2が構造的に後回しになる。
打ち手週の頭に「今週AIに渡す仕様」を確定させる場を持ち、運用要望は溜めて週1でまとめて出す
「作る仕組み」への投資は効いた。次は「渡せる単位」への投資
開発基盤に43本（24.7%）を投じてPR数は3.0倍になった。判断としては正しかった。ただし増えたのは実装の供給量であって、判断・レビュー・外部サービス設定といった人間側の処理量ではない。
打ち手Supabase移行・事業判断の先出し・レビュー担当の増員の3つ