スクラムには一定の型があります。デイリースクラム、スプリントレビュー、プランニング。チーム開発に大切なイベントであることは、今も変わりません。
ただ、AI駆動開発をチームに取り入れてから、この2、3年で開発の速度が変わりました。1スプリントに詰め込めるトライの物量が増えたことも大きいです。以前は1つか2つだったスプリントゴールが、気づけばエンジニアの人数ぶんあります。1つの機能をみんなで分解して並列に進めるのではなく、実験そのものが並列に走っています。
そのぶん、スクラムという型そのものに、合わなくなってきている部分があると感じています。
なぜいまスクラムの型を考えているのか
自分は受託の仕事が長く、ほぼ一人で案件を回す期間が長くありました。だから「チームで型を回す」という感覚を、そこまで強く持っていたわけではありません。
いまは、AI駆動開発が始まってから、以前のようなスクラムの型では回していません。デイリーでそれぞれの持ち場を共有し、チケットはAIも使いながら各自が並列で進めます。週によっては100PR近く動くこともあります。
そのぶん、ある程度まとまったらマージしつつ、週1回チームで同期を取る時間を意識的に作っています。GitHubの変更履歴をAIに要約してもらい、Notionに振り返りページを作って、気になったところをチームで話します。この積み重ねが、業務ドメインの理解や実装判断の目線合わせに効いている実感があります。
型を手放したぶん、何を意図的に残すかを自分で決めることになりました。それが、このテーマを考えている理由です。
フレームに合わせることが目的になっていないか
スクラムという型で進めること自体が目的になっていないか。この問いは、AIが出てくる以前からわかりきっていたことでもあります。フレームに合わせることが目的ではありません。
チームやプロセスが正しく回り、価値をユーザーに届け、組織に還元していく。そのための手段として、「デイリーをやりましょう」「このイベントが大切です」という位置づけに落ちていくはずです。
これはループエンジニアリングでも同じです。フレームワークに合わせることが目的ではなく、何かを成し遂げるためにフレームワークを使う、という順番であるべきです。生産性が上がる、効果的である、費用対効果が見合っている、目標につながる。条件が揃っているなら使えばいいです。揃っていないなら手放していいです。型を守ることと、型に使われることは別物です。
スクラムマスターという役割はどこへ行くのか
スクラムマスターの役割も変わっていくでしょう。エンジニアの役割も変わっていきます。EMやPdMといった垣根もかなり変わってきていて、デザイナーがエンジニアリングをすることも珍しくありません。
コストの面だけで考えても、スクラムマスターという職業がスクラムだけに特化した形で維持され続けるのは難しいと思っています。役割はもっと広がるはずで、スクラムマスターがPdMや営業を兼ねてもいいはずです。スクラムというプロセスを半自動化し、チームが成熟すれば、スクラムマスターとして立ち続ける必要はありません。チームが自立していれば、スクラムマスター自身がスクラムである必要もありません。
「目標を共有すれば人は動く」は本当か
ここで、最近読んだ記事と、あるポストが自分の中でつながりました。
1つは、LeadDev の Staff+ engineers must rebuild team culture です。AIで仕事が並列になると、チームの条件だった共有ゴール、相互依存、安定したメンバーシップが削られ、出荷は増えるのに個々人は孤立していく、という内容でした。文化は日常の共同作業で定着するものなので、AIが「同僚に聞く」を代替すると、その定着の機会そのものが消えます。記事の中身は000137にまとめました。読んで自分に一番残ったのは、「ゴールを人数分にした時点で、実質チームを解散しているのではないか」という感覚です。
もう1つは、@hamatoukon さんのポストです。『スラムダンク』の湘北を題材にした話で、要約するとこうなります。湘北は「全国制覇」という目標を共有して強くなったチームではありません。桜木は晴子さんに認められたかった、三井はやり直したかった、流川は日本一になりたかった。全員バラバラな動機で動いていて、たまたま「勝つ」という一点でしか叶わなかっただけだ、という読み解きでした。その上で、湘北にはチームとして機能する3つの条件が揃っていた、とも指摘されていました。役割がはっきり決まっていること、自由に動く現場の中で崩れない芯を持つリーダーがいること、個人の動機が自然にチームの目標へつながっていることの3つです。
一見、この2つは逆のことを言っているように見えます。LeadDev は「共有ゴールを取り戻せ」と言い、湘北の話は「そもそも動機を共有する必要はない」と言っています。
自分は、この2つは同じことの裏表だと思っています。LeadDev が言う「共有ゴール」は、全員が同じ動機で燃えることではありません。方向がつながっていること、それだけです。湘北の3条件のうち一番効いているのも、動機の統一ではなく「個人の動機がチームの目標に接続されている」という一点でした。
会議が無駄になる理由も、この線で説明がつきます。自分のゴールに関係ない更新を聞かされているだけの会議は、方向の接続を確認する場になっていません。ステータスの読み上げは、個人の集まりがチームのふりをしている時間にすぎません。
越境は、しなければならないものなのか
越境は「しなければならない」ものではありません。それはあくまで人間側の考え方の話です。
ただ、AI駆動で物事を進めていくと、チームは自然と職能横断になっていきます。そのフェーズに入ると、気づいたときにはすでに越境している状態になっているはずです。エンジニアがマーケティング施策を提案したり、QAの視点やデザイナーとの調整のためにワイヤーフレームを作ったりすることも珍しくなくなります。
AIが各分野でカバーできる範囲を広げていけば、自分の軸足を持ちながら、他の職能をサポートしたり、そちらへ軸足を移したりすることもできます。わかりやすい例で言えば、EMやPdM、マネージャーへの越境です。
そちらへ変わっていく可能性は十分にあります。そのときにやりたいかやりたくないかという迷いは出てくるでしょうが、基本的には受け入れていかなければキャリアは維持できません。『鏡の国のアリス』の赤の女王と同じです。同じ場所に居続けるためにも走り続けなければならず、別の場所に行きたければ2倍の速度で走らなければなりません。
これから意図的に残すもの
型を手放したぶん、意図的に残すものを自分で選ぶ必要があります。デイリーやスプリントレビューといった儀式そのものではなく、方向がつながっているかを確認する機会のほうです。
自分のチームで続けている週1回の振り返りは、そのための場になっています。GitHubの履歴をAIに要約させ、Notionでチームの気になった点を話します。そこで見ているのは進捗の答え合わせではなく、なぜその判断をしたのかという方向の接続だと、今なら書けます。
スクラムという型を守ることが目的ではありません。方向がつながっているかを、意図的に確認し続けること。それが、この型が合わなくなってきた今、自分たちがやるべきことだと思っています。
参考