AI 時代を乗りこなすために Story Point を導入した話（試験中）

こんにちは、kickflow開発チームの芳賀です。
AI コーディング、いいですよね。AI なくしてはもう作業が回らない時代まで来ちゃいましたね。体感では作業効率は約 2 倍に向上しました。
あと、ちょっと前までは「プロンプトをいかにチューニングして効率よくするか」が焦点だったのに、いつの間にか「AI をどう管理して進めるか」に焦点がステップアップしているのも興味深いですよね。

今回は、そんな AI コーディングの恩恵を受けつつも同時にもたらされた「つらみ」にどう対応していっているかご紹介します。

AI コーディングがもたらした「嬉しい悲鳴」

AI コーディングは素晴らしいです。本当に魅力的です。

これまで半日〜 1 日かかっていた実装が場合によっては 10 分で終わるようになりました。すると「あれもこれもやれるのでは？」という気持ちが湧いてき、やりたさが加速し、気づけば開発タスクの並列量がどんどん増えていきます。

しかし、もちろん問題もあります。
それは コンテキストスイッチコスト です。

その結果、こんなことが起き始めました。

思ったより開発タスクが進んでいない（と感じてしまう）
開発タスクを持ちすぎて、作業の不透明化が進む
上記 2 件が組み合わさり、「 AI コーディング導入前より疲れた」と感じてしまう

AI で速くなったはずなのに、なぜか疲弊している。そんな状態に陥っていました。

kickflow の開発スタイル

原因に触れる前にまずは弊社での開発スタイルについて触れておきます。

開発体制

kickflow では、このようにカンバン形式で機能開発を管理しています。モザイクだらけで恐縮なのですが、左からバックログ〜リリース済み、に並んでいます。

この仕様が固まったバックログからエンジニアは機能をピックアップし、開発を進めています。
また、複数人のチームで対応するわけではなく、いわゆる「一人チーム」で開発をしております。

見積もり

見積もりは各人が自分で行い、「A 月 B 日ごろに終わりそう」「YY 日くらいかかりそう」という目安ベースでチームに共有しています。経験則で見積もりをしている形ですね。

作業フロー

作業の流れとしてはプロダクトバックログに積んである機能開発をシーケンシャルに対応していきつつ、そこに適宜バグ修正、別作業などのサブタスクが並列で入ってきます。

そして現在

そして現在、

AI コーディングの発展によりサブタスクの流入量が増大
果てはメインの機能開発を複数担当する

ということで冒頭の課題感に繋がってきます。

原因

改めてですが、開発タスクを持ちすぎて、作業の不透明化が進んでいた と考察しています。

AI コーディングの到来により、

並列量が増加、コンテキストスイッチコストの増加
-> 作業見積もりに今までの経験則が効かない
-> 自身の作業が把握しにくくなる / 見えにくくなる（不確実性の増加）
-> 見えないからこそ「思ったより進んでいない」と感じる
-> 不確実性をそのまま取り扱うからこそ、心理的に疲れる

つまり、開発速度の問題ではなく、可視化の問題 だった、と考察しています。

対策

とりあえず自分だけですが、試験的に以下を実施しています。

Story Point で「今の自分」を明確化する

Story Point とベロシティを導入することで、自分の現在地を数値で把握できるようにしました。

ベロシティを計測すれば、コンテキストスイッチコストを含めた自分の本当のキャパシティが算出できます。「なんとなく忙しい」ではなく、「数字で忙しい」と言えるようになります。

Claude Code で Story Point を算出

ここで AI 時代ならではのポイントにも触れておきます。

従来は、「チームで共通認識を持つ」、「属人性の排除」、「基準の統一化」のためにプランニングポーカーが必要でした。しかし、AI が画一的に Story Point を算出すれば、AI の見積もりをベースとして先述の問題をすべて解決することができます。結果、プランニングポーカーのコストが不要になります。
今は試験中のため一人で Story Point をつけていますが、もしチーム内に展開することになっても「AI による見積もり」を基軸にしてブレない Story Point の算出ができるようになるはずです。

ベロシティの計測

ベロシティの測定には、普段使っている Asana を活用しています。MCP（Model Context Protocol）経由で Asana のデータを取得しています。
前スプリントで完了したチケットの Story Point 合計を算出して、今作業中の Story Point 合計を算出して というプロンプトで問い合わせればらくらく計算できます。

また、ベロシティを算出には「今まで見えてこなかったコンテキストスイッチコストを含めた値」が出てくることも副作用としてあるかと思います。これが結構良いな、と思っているポイントで「やってるけどなかなか進まない」を数値で可視化してくれているので心理的負担をかなり減らせていると実感しています。

Sprint Planning での共有

Sprint Planning では、以下を共有するようにしました。

ベロシティ（1スプリントで消化できる SP の平均値）
先週の消化 Story Point
現時点の Story Point（今抱えている作業の合計）

作業を一つずつ列挙して説明するよりも、今の状況をはるかに明瞭に伝えられます。
例えばですが、「作業 A がこれくらい進み、作業 B がそれに関連してずれ込んでいるため今の状況は〜」と以前なら説明していたところ「ベロシティは 50、今抱えている Story Point は 75 なので次スプリントまでずれ込みます」と簡潔に説明できます。
以下の表のように数値で表現することで「忙しさ具合」をエンジニアではない方向けにもわかりやすく伝えることができます。

現時点の SP vs ベロシティ	状況
下回っている	他のタスクに着手できる余裕がある
同じくらい	そのスプリントはパツパツ
上回っている	次スプリントまでずれ込む

このように徹底的に可視化を進めることにより、エンジニアの「なんとなくモヤっとしている」部分をクリアリングできると思います。結果、私としてはメンタルリソースを不安に割くことなくより作業に集中して取り組めていることを感じております。

まとめ

原因は AI による並列化ではなく、不透明さ
対策として Story Point とベロシティを導入（お試し）
あくまで試験中なので、よりよい手法があれば試していきたい
今は一人で検証中、チームへの展開も視野に入れていきたい

とにかく可視化、自身の作業の透明性を確保するのが重要かなと感じております。
もしかしたら「そんな時間がないよ」と思っている方もいらっしゃるかもしれません。しかし、自分から言わせていただくと「そここそ AI の使い時」で可視化のための時間を捻出することができると思います。
ほんのちょっと時間を割くだけで心理的負担を解消できる、やってみませんか？