こんにちはAGI未満です。
みなさんスクラムしてましたか？AIしてましたか？
AI時代でプログラミングは完全に形を変えつつあります。
プログラミングという最も重要な作業が質と量の両面で変革を遂げたいま、開発手法についても色々と考え直すときが来たのではないかと考えている人は多いでしょう。少なくとも多少なりとも業界でキャリアを積んだ人間であればチームでの開発業務にいままでのやり方を当てはめるのが難しくなっているのは感じているとおもいます。
今回はそんな開発手法の中でも名前だけは有名なスクラムがこれからどうあるべきか、あるいはそもそもAI時代のマネジメント手法としてフィットするのか？などを考えていきましょう。
というわけで今回は見積もりについてです。
いままでのストーリーポイント（見積もり）
個人的にスクラムについては愛憎混じりの想いを抱いている私です。
そもそもスクラムを真面目に運用できている組織は一握りでしょう。少なくとも僕がみてきた世界では全滅です。
そして見積もりです。
スクラムといえば見積もり、ポーカー、ストーリーポイント！という印象を抱いている人は多いでしょう。まさにスクラムの華です。
個人的にこの「見積もり」はスクラムの華であり、病巣でもあると感じています。
みなさんご存知の通りこのストーリーポイントの考え方はXPから拝借したものです。
しかし実際に運用すればわかるとおもいますが、このストーリーポイントという技法は道路交通法みたいなものです。ないよりはマシで、実際に道路を走ることはできるんですが制度に無数の穴があります。
穴があるゆえに警察による現場の判断による取り締まりが求められるわけです。現場の裁量が多い場合、警察役の権力が大きくなります。権力は濫用されるものです。
そもそもストーリーポイントの前提にゆがみが置かれることが多いです。
「メンバー全員が全タスクに対して同じくらいの知識を持ち、同じくらいの技術力がある」
そんな現場はみたことがありません。僕が担当することの多いフロントエンドは特にそこまで人数を採らない領域なので僕と同じレベルで設計できる人がチームで横にいたことは一度もありません。
仮に前提を満たしたとして、今度は「完了」の定義をどこに置くかという問題が生じます。
コードレビューの完了？マージ？リリース？手戻りが起きたら？CICDの整備が未熟だったりビジネス側の巻き込みができていない（それってスクラムなんか？というツッコミはさておき）など、組織の環境依存でボトルネックの場所が大いに異なるのが完了条件の設置箇所です。
少なくとも日本の伝統的な企業を想定しがちなスクラムセミナーの類はこの質問に答えられないことが非常に多いです。
……というわけで、とにかくストーリーポイントには問題や課題が山ほどあります。
ここまで色々書いたのを読んでいてスクラム自信諸氏らはモヤつきを感じたとおもうんですが、数年前時点でXP創始者がストーリーポイントにちょっとしたダメ出しをしていたりスクラムガイドラインから見積もりが削除されていたりしてます。ウケる
僕がスクラムごっこをしててマジでアホくせえなとおもうのは、そもそも
「スクラムの一番大事なコンセプトは1イテレーションごとに価値あるものをリリースすること」
なのにほとんどの組織でそれが完全に無視されることですね。
タスクの見積もりは、それを予測可能な範囲までに分割するための手段であって目的じゃあないんだ。
けれどスクラムの主な利用のされかたは
「そうですねえ……この仕様だといままでの実績からいえば、タスクを分割して……と。うーんと、そうですね！12スプリントで終わる想定なのでだいたい8月の中頃にはリリースできるんじゃないかとおもいます！」
ウ、ウォーターフォール……
（とはいえJTC的トップダウン指向から抜けられない人数が少ないだけのスタートアップ組織に最低限の規律を導入するために換骨奪胎したスクラムもどきを当てはめるのは、ちゃんと理解した上でウラ技として導入する分には僕は問題ないとおもっている。むしろ好き。無自覚は悪）
でもアジャイルすら理解できずセレモニー警察の杓子定規の教条主義に陥るくせに肝腎要のコンセプトを全部ドブに捨てるのお母さん嫌いだな。
そういう人たちに限ってすぐJTCとかウォーターフォールとかいって馬鹿にしたがりますけど、とんでもない数のステークスホルダーの利害調整をしながらピラミッドの建設管理をする現場の人たちの能力や努力を、単に参加人数が少ないだけで劣化版を実践してるだけのヒトビトがけなすの本当に失礼なんでやめたほうがいいですよ。
いやまぁね、別にいいんですよ。行動指針がなんもないのは本当の地獄ですから。
ただやっぱこじつけの感はいなめないし、なまじスクラムが多くのイベントを定義するものだとされがちなのもあって犠牲が大きい。もちろん見積もり通りには終わらない。
卑しくもアジャイルの末裔を名乗るならかなり大きい仕様だったとしても
「まずはMVPとしてこれを……2週間スプリントでリリースします。その後はスプリント期間を調整しつつフィードバックを受けて改善していきます。肌感としては8スプリントくらい回せばかなりの完成度になる気がしますねえ？」
くらいに言い換えたいところです。
色々頑張って3ヶ月後にリリースします！
より
色々削りまくって1週間でリリースできるものにします！
のほうが本質的だし、見積もりをミスって倍かかったとしても6ヶ月と2週間じゃあダメージの差も違いますよね？
え？そんなに削れない？
3ヶ月のものを1週間でリリースできるわけがない？？？？？？？？
あのね出来ない出来ないばかりじゃなくてね、どうやったら出来るかを考えるのが貴方たちの仕事でしょう？
というか、どうせ平均的なプロダクトがリリースした機能の8割は使われないんだよ。
じゃあ3ヶ月かかる想定の仕様の8割捨てたら2週間ちょいになるやろ？そっからUI/UXをシンプルにして荒くリリースすれば半分の時間で終わるやろがい！！
ちなみにスクラム失敗勢の多くが罹患しがちな "Nothing is done till it's perfect." 的なビックバンリリース病はコーディング効率が爆上がりしたエージェント時代にこそむしろ致命的ですよ。
ストーリーポイントイズデッド（5年ぶり3度目）
なんの話してたっけ？
ああそうそう僕がスクラムを大好きな話でした。
違いますねAIでスクラムが変わる話でした。
AIくんが冷酷無比のコーディングマシンとして君臨することでストーリーポイントの持つ「メンバー全員が同じ技術力を持つ」という夢物語がひとつ、擬似的に満たされたことになります。
しかしいまや平気で3つ4つ5つと同時並行でタスクを処理するため、ストーリーポイント見積もりという概念は完全に死にました。
でも組織にもよりますけど、見積もり自体は大事だとおもうんですよ。見積もりを通じてチームの意見統一を測ったり、ビジネス側との共通言語を作ったりできるんで。
じゃあやっぱり見積もりは手段じゃないかよ。AI以前からタスク見積もりなんて松竹梅の3種類+αでいいとおもってました。
コンテクストポイントを使え
というわけで正式に逝去されたストーリーポイントのかわりに
コンテクストポイント
という概念を提唱します。
これはつまりタスクの完了に必要なコンテクストの量を見積もるポイントです。
全プロジェクトが持っているであろう
ソースコード + AGENTS.md
を暗黙のコンテクストとしつつ、組織特有でnotionやissue boardが連携されていればそれも基底コンテクストに含めます。
そして、そこでタスク固有で要求されるコンテクスト注入をコストを換算して見積もるわけです。
松- 指示一発（XXという機能を追加して）で自走竹- プランモードなんかを活用して長めのプロンプト or ペラ一枚くらいのテキストファイルを渡せば自走梅- 人間が並走しながら進める
AI活用を高度に発達させた組織なら全てが 松 とされる未来すらありえる管理体制なのがミソです。
最初は 梅 だったタスクだとしても、ある程度の型が発見されたらskill化すれば松や竹に化ける可能性もあるというかそれを目指す仕組み。
梅だけカバー範囲が広大すぎね？とおもった貴方はただしい。
ただし人間が並走してすら完了が想像できないタスクは言語化不足で間違いなく仕様的欠陥を抱えているから想定する必要はない。
単に要件定義からやり直すだけで良い（強弁）。
まとめ
- 筆者はスクラムを愛している
- ストーリーポイントが本当に好き
- ウォーターフォールも好き好き大好き超愛してる
- スクラム イズ デッド……
- AI時代のタスク見積もりは「必要コンテクスト量」と「自走の可否」で行え
以上。続かない
