私は Claude Code を中心とした AI エージェント群で「仮想組織」を運営して、SaaS の個人開発と SES の本業を回している。その仮想組織で、約 3 週間前に「全工数見積もりに × 2/3 係数を掛けて、エージェントには PSP（Personal Software Process）方式で実測値を報告させる」というルールを敷いた。そこから 3 週間で 72 サンプルが集計 CSV に溜まった段階で、当初想定と実測の関係を見直してみたのが本記事だ。
先に結論の骨格だけ言うと、平均 deviation は無加工で -12.7%、判断待ちバイアスが混入し得る超過帯を除くと -36.6% に落ち着いた。「× 2/3 では控えめすぎる」種別と「× 2/3 でもむしろ甘い」種別が同居していて、単純な「AI は速い / 遅い」では語れない分布になっていた。
この記事では、なぜ 1995 年の古典ソフトウェア工学である PSP を AI エージェント運用に持ち込んだのか、何をどう計測したのか、そして N=72 のログから見えた「型が見える作業ほど速い / 判断が絡む作業ほどズレる」という暫定仮説を、社内固有名を伏せて公開する。N=100 で確定値を出すまでの「動いている最中の運用譚」として読んでもらえると嬉しい。
このルールを敷いた発端は、毎週エージェントと一緒に翌週のスプリントを組む会議での違和感だった。10 時間の作業枠があれば、1 作業 2 時間想定なら本来 5 つは詰め込めるはずなのに、エージェント側は 1 作業を 5 時間で見積もってきて、1 日 2 作業しか埋まらない ─ 明らかに詰めが甘い日がずっと続いていた。「これはたぶん、人間が同じ作業をやったときの想定時間をそのまま流用しているから、エージェントの実速度に対して過大評価になっているのでは？」というのが、そのとき私が持ち込んだ仮説だ。
もっと痛いのは、この見積もりのズレが 翌週の進捗予測そのものを歪める ことだった。1 週間で本当なら 10 作業進むはずのバックログが、5 作業しか進まない前提で組まれれば、リリース時期の予測も外れる。仮想組織全体の「今週何がどこまで進むか」の解像度が下がる ─ これは 1 つ 1 つの見積もり誤差より遥かに大きな問題だった。
とはいえ、エージェントがどのくらい速いのかは正確には分からない。だから「一旦 × 2/3 で見積もり直しながら、実測を蓄積して係数を見直そう」と告げた。2/3 という数字自体に強い根拠があったわけではなく、「1/2 では振りすぎ、3/4 では効きが薄い」の間を取った暫定値だ。走りながら決める、というのは PSP 原典で Humphrey が繰り返し語っている姿勢そのものだが、当時の私はそこまで意識していなかった ─ ただ「先にルールを敷いて、動かしながら精度を上げる」しかない、と思っていた。
結論先出し ─ N=72 で見えた 4 つのこと
長くなる記事なので、まず結論を 4 つ並べる。
- 平均 deviation は無加工で -12.7%、バイアス除去後で -36.6%。72 サンプルの内訳は「速い（-30% 以下）が 44.4%」「想定通り ±30% が 36.1%」「超過（+30% 以上）が 19.4%」で、思ったより「想定通り」が最大シェアだった。× 2/3 係数（= -33% 仮置き）は、超過帯を除いた実像（-36.6%）とはほぼ一致していた。
- タスクの「型」で分散が激しい。ルール文書化・監査文書は -84% 〜 -90%、shell / jq スクリプト実装は -87% と大幅短縮。一方で新規プロダクトの初期立ち上げ段階の実装は +78%（想定超過）、起票 / setup も +12% で想定通りより少し膨らむ側に振れていた。「AI は速い」の一言では片付かない。
-
計測フィールドは 10 個入れておいて正解だった。実作業時間・見積もり値・偏差率だけでは足りず、
bug-count / files-changed / lines-added / lines-deletedを並走させることで「速度と品質のトレードオフ」を後から見返せた。PSP が 1995 年に提案した「時間・欠陥・規模」の 3 軸を、そのまま CSV の列として実装しただけだが、これが効いた。 - 速度の改善は必ずしも品質の改善とイコールではない。私の N=72 では 3 週間で bug-count 累計 86 件（うち eng-backend 単独で 66 件、実装系 3 ロール合計だと 81 件で全体の 94%）、これを速度の裏側指標として並走させることの重要度は高い。
ここから本文では、PSP の古典紹介 → 仮想組織に持ち込んだ経緯 → 計測フィールド設計（10 フィールド）→ N=72 ログの分布 → 種別別暫定係数 → 残課題（特に品質のトレードオフ）の順に書いていく。
PSP（Personal Software Process）とは ─ Watts Humphrey と 1995 年
PSP は、Watts S. Humphrey が Carnegie Mellon SEI（Software Engineering Institute）で開発し、1995 年に書籍 "A Discipline for Software Engineering"（Addison-Wesley / ISBN-13: 9780201546101 / 789 ページ）として体系化された、個人開発者向けの計測・改善フレームワークである。
Humphrey は「ソフトウェア品質の父」と呼ばれた人物で、2003 年に米国 National Medal of Technology、2008 年に ACM Fellow を受賞している（Wikipedia）。PSP の中核は、「個人開発者が自分自身の見積もり精度・欠陥傾向・生産性を継続的に測定し、データドリブンに改善する」という考え方だ。組織レベルの CMM / CMMI とは別軸で、個人レベルの規律を立てる位置付けにある。
PSP は PSP0（時間・欠陥記録の導入）→ PSP1（見積もり精度向上）→ PSP2（設計レビュー統合）の 3 レベル構成で、各レベルに改訂ステップ（PSP0.1 / PSP1.1 / PSP2.1）がある。チームに拡張したものが TSP（Team Software Process）で、SEI の公式ページには「TSP と組み合わせると目標達成に効果的」と明記されている。
2000 年代のアジャイル台頭以降、PSP は「測定負荷が高すぎる」「形骸化した」と批判されて主流から外れた。ただしこれは 測定コストへの批判であって、原理そのものへの否定ではない。CACM（Communications of the ACM）には 2021 年に Bertrand Meyer が "Time to Resurrect PSP?" を寄稿して再評価を促している。
そしてここが本記事の核心なのだが、AI エージェントの発展そのものが、PSP 最大の弱点だった「測定負荷が高い」という問題を構造的に解消してしまう。1990 年代の PSP 実践者は、開発中にストップウォッチで作業時間を測り、コードレビューで見つけた欠陥をカウントし、コード行数を数え、これらを表計算ソフトに転記していた。この二重作業が「PSP は理論としては正しいが、実務で回すのが辛い」と評されてきた原因だった。
ところが今、LLM エージェントは着工宣言から PR merge までを 1 チケット単位のタスクとして自然に処理していて、actual-duration / bug-count / git diff --shortstat の値は本人（エージェント）が最終メッセージに YAML で書き出すだけで良い。ストップウォッチも表計算転記もいらない。測定負荷ゼロの PSP が、AI 時代には手が届く距離にある ─ これが私が PSP を仮想組織に持ち込もうと考えた直接の動機だ。
なぜ仮想組織で PSP を必要としたのか
私は仮想組織の運営ルールを CLAUDE.md（Claude Code のプロジェクト規約ファイル）に書き溜めながら、エージェントに工数見積もりを書かせている。当初は「人間が見積もる工数と同じ数字をそのまま使う」運用で 2 ヶ月ほど回した。
問題は 3 つあった。
- 見積もりがほぼ毎回ズレる。人間想定 3h のタスクが 30 分で終わり、人間想定 1h のタスクが 4h かかる、というばらつきが Markdown チケットの履歴を見ると常態化していた。
- 「速かった / 遅かった」の感覚しか残らない。ズレの方向と幅を数値で記録していないので、次回の見積もりに反映できない。
- 週次スプリント会議の進捗予測そのものが崩れる。冒頭に書いた通り、1 作業 2h で本来 5 つ入るはずの週が 2 作業しか入らない見立てで組まれてしまう。1 チケット単位の誤差なら許容できるが、「今週何がどこまで進むか」の全体解像度が落ちるのは仮想組織として致命的だった。マイルストーンから逆算した週次計画そのものの意味が薄くなる。
そこで先述のように「× 2/3 係数 + PSP 報告」をルール化したのが、約 3 週間前の出来事だ。× 2/3 は 暫定の仮置き値でしかなかった。私自身も「いきなり最適値は出ないので、まず 10 件、そして 100 件ログを溜めてから係数を見直す」という前提でルールを敷いた。実際にこのルール文書自体にも「初期値 2/3 は仮置き値であり、固定値ではない」と書き残している。
計測フィールド設計 ─ CSV に 10 列で並べた
最終的に、集計用 CSV には 10 個のフィールドを並べた。1 チケット = 1 行、エージェントの完了報告 YAML から転記する構造にしてある。
| # | フィールド | 単位 | 意味 |
|---|---|---|---|
| 1 | ticket-id |
文字列 | チケットの識別子（本記事では匿名化して掲載） |
| 2 | closed-at |
日付 | 完了報告日 |
| 3 | agent |
文字列 | 担当ロール（eng-backend / eng-frontend / eng-test / eng-reviewer-architecture / eng-reviewer-quality / secretary 等） |
| 4 | estimated-h |
hour（0.1h 刻み） | 起票時の想定工数。× 2/3 係数適用後の値 |
| 5 | actual-h |
hour（0.1h 刻み） | 実作業時間。着工宣言から完了報告まで。reviewer 待ち / 私の承認待ちは含めない |
| 6 | deviation-pct |
% |
(actual − estimated) / estimated × 100。正数 = 想定超過、負数 = 想定短縮 |
| 7 | bug-count |
整数 | レビュー指摘 + 自己発見の不具合数（Critical / Major / Minor 合算 / typo・フォーマット指摘は除外） |
| 8 | files-changed |
整数 | 変更ファイル数（git diff --shortstat の値をそのまま転記） |
| 9 | lines-added |
整数 | 追加行数（同上） |
| 10 | lines-deleted |
整数 | 削除行数（同上） |
Humphrey が 1995 年に提唱した PSP の 3 軸「時間（time）/ 欠陥（defects）/ 規模（size）」を、そのまま CSV の列として実装し直したものだ。当初は 3 フィールドで十分と考えたが、複数の agent ロールで並走させるうちに agent 列と closed-at 列が事後分析に効いてくることが分かり、10 個に落ち着いた。
deviation-pct が ±20% を許容帯、±30% 超で次回の係数見直しトリガーという運用閾値も同時に置いた。これは PSP 原典の「Plan-Measure-Analyze-Improve サイクル」をそのまま踏襲している。
CSV の実物（頭 3 行 / チケット ID は匿名化）はこんな形になっている。
ticket-id,closed-at,agent,estimated-h,actual-h,deviation-pct,bug-count,files-changed,lines-added,lines-deleted
Task A,2026-06-07,eng-pm (secretary),0.4,0.05,-88,0,1,121,0
Task B,2026-06-07,eng-pm (secretary),0.5,0.05,-90,0,1,253,0
Task C,2026-06-07,eng-backend (secretary),0.6,0.08,-87,2,1,172,0
エディタで CSV を開いて 1 行追記するだけで PSP が回る、というのが AI エージェント時代の PSP 実装の実感だ。ストップウォッチも表計算転記も、記録漏れも起こらない。
N=72 観測ログ ─ 分布は思ったより多様だった
3 週間で 72 サンプルが集まった段階で、CSV を集計してみた。deviation-pct の分布はこうなった（有効サンプル 72 件 / 空欄行はレビュー agent の記入漏れ 4 件で除外）。
| 帯域 | 意味 | 件数 | 割合 |
|---|---|---|---|
| 非常に速い（≤ -70%） | 想定の 3 分の 1 未満で終わる | 11 件 | 15.3% |
| 速い（-70% 〜 -30%） | 想定より大幅に速い | 21 件 | 29.2% |
| 想定通り（-30% 〜 +30%） | ± 30% 誤差帯 | 26 件 | 36.1% |
| 超過（+30% 〜 +100%） | 想定を 3 割 〜 倍で超過 | 11 件 | 15.3% |
| 大幅超過（> +100%） | 想定の倍以上かかった | 3 件 | 4.2% |
平均 deviation は無加工で -12.7%。「AI エージェント = 想定より大幅に速い」という直感的な予想と、実際の分布はだいぶ違った。最大シェアは「想定通り帯 ± 30%」の 36.1% で、大幅超過帯も 3 件存在する。× 2/3 係数（= -33% 仮置き）が全体を通して過大評価だったわけではなく、タスクの型で振れ方が全然違う という描写の方が正確だと思う。
バイアス除去 ─ 「判断待ち」が actual に紛れ込んだ可能性
ここで気になったのが、超過帯（+30% 以上の 14 件）にはノイズが混入している疑いが強い、ということだ。PSP ルール上、actual-h は「reviewer 待ち / 私の承認待ち」を含めない実作業時間としているが、実運用では:
- CR ラウンド（レビュー往復）中に「私の承認待ち」で長時間止まる
- チケット判断で私に相談を投げて回答を待つ間、他タスクに切り替えて戻ってくる
といった構造上のノイズが actual-h に紛れ込んでいた可能性が高い。実際、超過帯 14 件の中身を眺めると、reviewer の CR2/CR3 ラウンドや、私に判断を仰いだ後の起票作業が多くを占めていた。
なので > +30% の 14 件（19.4%）を「判断待ちバイアス混入疑い」として除外した集計も並列で出す。
| 集計 | N | 平均 deviation |
|---|---|---|
| 無加工（判断待ちノイズ込み） | 72 | -12.7% |
| > +30% を除外（バイアス除去後） | 58 | -36.6% |
バイアス除去後の -36.6% は、× 2/3 係数（= -33% 仮置き）とほぼ一致する。つまり 実作業だけを取り出せば × 2/3 は割と良い仮置きだった、しかし実運用の見積もりでは CR 待ちや判断待ちを込みで見るなら、係数を掛けても掛けなくてもほぼ変わらないレンジまで戻ってくる、という 2 段のレイヤーが見えたことになる。
初期観測 4 サンプル ─ ここが極端で、N=4 では見誤った
参考までに、ルール制定直後の 6/7 初期観測 4 サンプルを匿名化して並べる。ここが最も -80% 台に振れた種別群で、N=4 時点ではこの 4 件だけを見て「× 2/3 は控えめすぎる」と判断していた。
| サンプル | 種別 | 想定工数 | 実測 | deviation | 一言所感 |
|---|---|---|---|---|---|
| Task A | ルール文書化 | 0.4h | 0.05h | -88% | 候補提示の時点で骨子が固まっていた / 書き出しのみ |
| Task B | 監査文書 | 0.5h | 0.05h | -90% | 監査表の機械的展開 |
| Task C | shell / jq スクリプト（〜200 行） | 0.6h | 0.08h | -87% | jq filter の骨子が型として見えていた |
| Task D | ルール文書化 follow-up | 0.2h | 0.04h | -80% | 既存ルール補足の shell / grep 追記 |
その後 3 週間で「実装系」「レビュー往復」「テスト」「rebase」などが混ざり、分布は先ほどの表のように広がった。初期の Task A〜D だけを見た時点では「AI は 1 桁オーダー速い」と思ってしまったが、それはサンプルバイアスだった と後から分かった。「短期の初期サンプルを一般化しない」というのが、N=72 まで進めて改めて実感した PSP の効用のひとつだ。
bug-count のシグナル
無視できないシグナルが 1 つ出た。72 サンプルの bug-count 合計は 86 件、うち eng-backend 単独で 66 件（77%） が発生していた（実装系 3 ロール合計だと eng-backend 66 + eng-frontend 7 + eng-test 8 = 81 件 / 94%）。文書系（ルール文書化 / 監査文書）は bug 0、レビュー系も bug 0 に近い。
これは速度短縮の数字とは別軸で、「コード生成系では時間より bug-count の方が PSP の価値が高いかもしれない」という新しい視点を生んだ。eng-backend の平均 deviation が -33.7% だとしても、その裏で 66 件の bug 指摘が出ている ─ 時間だけ見て「速くなった」と喜ぶには早すぎる。詳しくは後段の「速度 vs 品質」で書く。
種別別の実測係数 ─ N=72 で見えた仕事の型ごとの落ち着き先
さっきの分布は agent や種別を混ぜたものだ。ここからは種別別に分解する。ticket ID の prefix + agent ロール で分けて集計したのが以下。
作業種別で分けた集計
CSV の ticket-id prefix ベースで作業種別を機械的に分類した。分類ルールは表下に明示するので、CSV を持っている人は同じ集計を再現できる。
| 作業種別 | 分類基準 | サンプル | 平均 deviation | bug 件数 |
|---|---|---|---|---|
| ルール文書化 | ルールドキュメント系 ticket | 2 | -84.0% | 0 |
| 監査文書 | 監査 suffix ticket | 1 | -90.0% | 0 |
| shell / jq スクリプト | shell script suffix ticket | 1 | -87.0% | 2 |
| インフラ / 横断改修 | 横断改修シリーズ ticket | 2 | -32.5% | 3 |
| 長期継続プロジェクトのアプリ実装 | プロジェクト A（3 ヶ月以上稼働中） | 53 | -11.2% | 69 |
| 学習サイトの追加改修 | プロジェクト B（既存資産） | 5 | -39.0% | 4 |
| 新規プロダクトの実装（3 週間内で開始） | プロジェクト C（初期立ち上げ段階） | 3 | +78.3% | 6 |
| 起票 / setup / 一括メタ処理 | 財務部 setup 系 ticket | 4 | +11.8% | 2 |
| スキル実装 | スキル系 ticket | 1 | 0% | 0 |
| 合計 | — | 72 | — | 86 |
分類ルール:
ticket-id列の先頭部分（プロジェクト名 / 種別接尾辞）でバケットを機械決定している。同じ CSV を持っていればawk -F','の 1 パスで同一集計を再現できる構造にしてあり、実際の prefix パターン一覧は記事の管理用メタデータ側に記録している。
agent ロール別
私の仮想組織では、役割ごとに専任のエージェントを用意している。ロール名だけでは伝わりにくいので、担当領域を併記する。
| ロール | 担当領域 | サンプル | 平均 deviation | bug 件数 | 総 lines-added |
|---|---|---|---|---|---|
| eng-backend | サーバサイド実装（API / DB / 外部連携） | 36 | -33.7% | 66 | 18,630 |
| eng-frontend | UI 実装（コンポーネント / 状態管理 / スタイル） | 7 | -29.7% | 7 | 783 |
| eng-test | テスト設計・実装（Unit / Integration / E2E） | 4 | -25.8% | 8 | 2,514 |
| eng-reviewer（architecture + quality） | コードレビュー 2 観点（設計 / 品質・リスク） | 12 | +34.4% | 0 | 2,216 |
| secretary / eng-pm | チケット起票・裁定・進行管理・オーケストレーション | 13 | +15.0% | 5 | 2,057 |
ここから見える暫定仮説を 3 つ。
- 文書系（ルール / 監査 / shell script）は -84% 〜 -90% で振れる。これは初期 N=4 の観測と一致する。「型が見えている作業」は 1 桁オーダー速い、という直感はこの帯域だけなら当たっている。
- 実装系は種別で分散する。同じ「実装」でも、長期継続プロジェクトの中規模実装（-11.2%）、既存資産の小改修（-39.0%）、新規プロダクトの初期立ち上げ段階（+78.3% = 想定超過）で全然違う。新規立ち上げの +78.3% は仕様が固まっていない領域を初期段階で触っていたからで、「型が見えていないコード書きは想定より遅い」という素直な仮説が立てられる。
- レビュー系・secretary 系は超過側に振れる。CR 往復や起票 / setup 系で判断介入が入るものは想定より膨らむ。前節のバイアス除去で外した超過帯 14 件は、実はここが多くを占めていた。
これを踏まえて、ルール文書には次の暫定係数表を置いた。あくまで N=72 段階の仮置きで、この先 N=100 / N=200 と積むごとに更新される前提だ。
| 種別 | 暫定係数（人間想定 × N） | 根拠 |
|---|---|---|
| ルール / 規約文書化 | × 1/10 | -84% 実測 |
| 監査文書 | × 1/10 | -90% 実測 |
| shell / jq スクリプト（〜200 行） | × 1/8 | -87% 実測 |
| アプリ実装系（バックエンド） | × 2/3 | -33.7% 実測 = × 2/3（-33%）とほぼ一致 |
| アプリ実装系（フロントエンド） | × 3/4 | -29.7% 実測 |
| テスト実装 | × 3/4 | -25.8% 実測 |
| 起票 / setup 系 | × 1（想定と同等） | +11.8% 実測（想定通り近い） |
| CR / レビュー対応サイクル | × 4/3（想定より 1.3 倍） | +34.4% 実測（判断待ちバイアス混入疑い含む） |
| 設計書 / UI 設計 | × 2/3（仮置き継続） | N=0 / 未検証 |
未検証カテゴリ（N=0）は × 2/3 の仮置きのまま運用する。「速いなら係数を下げる」だけの単純な話ではなく、種別ごとに落ち着き先がまるで違う（× 1/10 から × 4/3 まで振れる）というのが N=72 段階での暫定仮説だ。
外部研究との比較
私の N=72 データを、公開されている参照データと並べておく。
- GitHub が 2022 年に実施した RCT（n=95 / JavaScript HTTP サーバー実装タスク）では、Copilot 使用群は 71 分、非使用群は 161 分で完了し、約 55% 短縮だった（GitHub Research）。私の実装系（eng-backend / -33.7%）はこれより控えめだが、GitHub の RCT は「単一の実装タスクを 2 グループで比べる」設計で、こちらは「多様なタスクを 1 個人が 3 週間回した実運用データ」なので直接比較はできない。
私の N=72 は AI コーディング業界の全体像を語るには小さすぎるが、「自分の手元で、自分のタスク種別で測る」ことに意味がある、というのが PSP の発想そのものだと思っている。
もうひとつ、この N=72 段階で書き残しておきたい感覚がある。このルール自体が、自分で決めたルールで自分の作業を計測している ということだ。ルール文書を書いたときの作業も、監査文書を作った作業も、shell スクリプトを書いた作業も、9 件の起票をまとめて捌いた作業も、実装系の CR 往復も、すべて同じ CSV に 1 行ずつ追記されていく。エディタで CSV を開いて、ticket-id,closed-at,agent,estimated-h,actual-h,deviation-pct,bug-count,... の列に数字を書き込むたびに、「気持ち」だった時間感覚が「データ」に変わっていく手応えがある。
そして、この記事自体も PSP で計測される予定だ。想定 1.75h に対して、実測は何時間になるのか。deviation はプラスに振れるのか、マイナスに深掘れるのか。書き終えて CSV に 1 行追記した瞬間、それが N=73 サンプル目になる。「自分のルールで自分を測る」の入れ子構造が、書きながら 1 段深くなる ─ N=100 で確定値を出すまでの過渡期にしか書けない副産物として、この感覚は記事に残しておきたかった。
速度 vs 品質 ─ 速い ≠ 品質安全
ここまで deviation の話ばかりしてきたが、これは半分しか語っていない。もう半分は bug-count 側だ。
私の N=72 観測では、3 週間の bug-count 累計は 86 件、うち eng-backend 単独で 66 件（77%） が発生していた（実装系 3 ロール合計だと 81 件 / 94%）。eng-backend の総 lines-added は 18,630 行、単純計算すると 66 / 18,630 ≒ 0.35% の bug 密度になる。ただしこれは「レビュー agent 2 体（architecture / quality）+ Codex の 3 重チェックで拾えた指摘のみ」を数えているためで、拾いきれない潜在バグは別途あるはずだ。「AI コードは人間コードより品質が高い」とは絶対に言えない。
むしろ、PSP の bug-count フィールドを律儀に記録し続けることで、「速度の追求が品質の負債に転化していないか」を継続観測できる、というのが本来の使い方だと思っている。eng-backend の平均 deviation が -33.7% だとしても、その裏で 66 件の bug 指摘が出ている ─ この 2 つの数字を同時に見なければ意味がない。
このトレードオフを認識した上で、bug-count を「速度メトリクスの裏返し」として常時併走させる ─ これが N=72 段階で見えた、もう 1 つの収穫だ。
残課題 ─ N=100 で確定値を出すまでの宿題
N=72 で見えてきたものを整理すると、宿題は 4 つある。
- 未検証カテゴリの係数測定: 設計書 / UI 設計は N=0 のまま。判断介在の多いタスクで振れ幅がどうなるか、これが一番知りたい。
- bug-count を主要 KPI に格上げするか判断: eng-backend で 66 件の bug が集まった段階で、時間より bug-count の方が有用な軸になる可能性が見えてきた。次の 3 週間で「bug 密度 vs 実装ドメインの複雑度」の関係を出したい。
-
「型が見える / 見えない」軸の言語化: 現在の暫定係数は感覚的だが、これを「事前に種別を判定できる」レベルまで言語化したい。チケット起票時に
task-category:をエージェント自身が選べるようにする、というのが次の実装課題。 - 判断待ちバイアスを構造的に除去する仕組み: 今回 > +30% の 14 件を疑ってバイアス除去したが、これは事後的な判定で完全ではない。actual-h の計測をチャンク単位に切って、判断待ちの区間を明示的に record するようなツール側の改善が必要かもしれない。
PSP 規律の本来の価値は、これを N=100、N=300 と続けて、自分の組織における係数の落ち着き先を見つけるところにある。1995 年の Humphrey の発想を、エージェントの YAML 出力に置き換えただけだが、構造としては全く同じだと思う。
まとめ ─ 動いている最中の運用譚として
3 週間で N=72 という個人観測データだが、見えてきたものを一文にまとめると ─ AI エージェントの工数短縮率は無加工で -12.7%、判断待ちを除いた実作業ベースで -36.6%。しかしタスクの型で × 1/10 から × 4/3 まで振れる、ということだ。× 2/3 係数は「実作業だけを見れば良い仮置き」だったが、実運用ではもっと種別ごとに分けて見ないと使い物にならない。
そして、これは 「動いている最中の運用譚」 である。N=100 で確定値を出す予定で、それまでは暫定係数表を観測値ごとに更新し続ける。本記事自体も PSP で計測される予定で、想定工数と実測の deviation-pct は、N=73 サンプルとして次回の係数見直しに使う。「自分のルールで自分を計測する」というメタ構造を、現在進行形でどう運用しているかの記録として読んでもらえれば。
PSP の話は 1995 年で止まったわけではない。LLM が日常的に計測ログを書ける時代になった今、Humphrey が当時想定した「個人の規律で自分の見積もり精度を上げる」という考え方は、エージェント運用にそのまま持ち込める。違うのは、ストップウォッチ片手にコード行数を数える代わりに、YAML 出力と git diff --shortstat で済む、というところだけだ。
よくある質問
Q: AI エージェントに任せると、どれくらい工数が短縮されますか？
A: タスクの種類で大きく異なる。私の N=72 観測では、無加工の平均 deviation が -12.7%、判断待ちバイアスを除去した実作業ベースで -36.6%。種別別ではルール文書化・監査文書が -84 〜 -90%、shell / jq スクリプト実装が -87%、アプリ実装（バックエンド）が -33.7%、逆に新規プロダクトの初期立ち上げ実装は +78%（想定超過）、CR / レビュー対応は +34.4% と幅広く散る。単一の「AI は N% 速い」で語れない。参考として GitHub の 2022 年 RCT（n=95）では Copilot 使用群が JavaScript タスクで約 55% 短縮という別の参照値もある。
Q: PSP（Personal Software Process）とは何ですか？
A: Watts Humphrey が 1995 年に書籍 "A Discipline for Software Engineering" で提唱した個人向けソフトウェア開発フレームワーク。Carnegie Mellon SEI で開発され、計画・記録・測定・振り返りを個人単位で回すことで、見積もり精度とコード品質を継続的に改善する。3 レベル構成（PSP0 / PSP1 / PSP2）で、各レベルに改訂ステップがある。チームに拡張したのが TSP（Team Software Process）。
Q: AI エージェントの工数を計測する最小構成は何ですか？
A: PSP 原典の 3 軸「時間・欠陥・規模」に対応する ①実作業時間 ②バグ数 ③コード量、を毎チケット記録するのが骨。実運用では ticket-id / closed-at / agent / estimated-h / deviation-pct を加えた 10 フィールドを CSV に並べておくと、後から agent 別・種別別に切って分析できる。10 件、そして 100 件蓄積すると、タスク種別ごとの傾向が見えてくる。
Q: GitHub Copilot の 55% 工数短縮データは信頼できますか？
A: GitHub 社が 2022 年に実施した RCT（無作為対照試験 / n=95）の結果で、研究としては妥当な設計。ただし JavaScript の HTTP サーバー実装という単一タスクでの測定であり、全タスク・全言語に適用できるわけではない。研究チーム自身も「より詳細な分析を実施中」と表明している。参考値として活用しつつ、自分の環境で計測するのが現実的。
Q: AI エージェントが速いなら、品質は大丈夫ですか？
A: 速度と品質はイコールではない。私の N=72 では 3 週間で bug-count 累計 86 件、うち eng-backend 単独で 66 件（77%）、実装系 3 ロール合計だと 81 件（94%）が発生していた。速度が上がる裏側で bug 指摘は着実に累積するので、PSP の bug-count フィールドを並走させることで、速度の追求が品質負債に転化していないかを継続観測できる。「速さの計測」と「品質の計測」は同時に行うべき。
参考リンク
PSP 原典・古典文献
- SEI 公式 PSP 概要ページ — Carnegie Mellon SEI による公式解説
- Watts Humphrey "A Discipline for Software Engineering" — 1995 年原典 / ISBN-13: 9780201546101
- Wikipedia: Watts Humphrey — 経歴・受賞歴
- CACM "Time to Resurrect PSP?" — Bertrand Meyer による 2021 年再評価論
AI コーディング生産性研究
- GitHub Research: Quantifying GitHub Copilot's impact on developer productivity and happiness — n=95 RCT / 55% 短縮