【アジャイルFAQ 第1回】AI時代に問い直す！本当に必要？スクラム基礎の「意味」と「価値」

 この記事を読んでいただきありがとうございます。アジャイルグループに所属する、藤井智弘です。

 「豆蔵最後のアルバイト」という謎の肩書でお客様を煙に巻きながら、日々研修やご支援に従事している中で、同じような質問を何年にも渡って繰り返しいただいてきました。アジャイル開発が世に出て30年近い年月が経ち、実践者の世代交代が進んでいるので、かつて議論し尽くされた（かに見えた）質問が、打者一巡よろしく繰り返し話題にのぼるのも当然とも思います。
 そうしたよくいただく質問を起点に、その背景にある構造的な問題や現場で使える対処法を、FAQの形で明文化しておこう、というのが、これから始める連載の趣旨です。

 対象となる読者像は、以下のように設定しました。

• 研修や専門書での学習によって、「スプリントってなに？」という基本的な用語レベルは知っている
• 新年度になってスプリントを回し始めて数ヶ月、「これでいいんだっけ？」という引っかかりが溜まりはじめた

基礎を学んだ方がもう一歩…「知っているのに、現場でうまくいかないのはなぜか」…掘り下げて考える機会を作ろうということがねらいです。

 実際にいただいた質問を起点にしているので、タイトルを見ると「開発者視点」と思われそうですが、「アジャイルに関わる人であれば知っておいたほうが良い内容」を意識しました。ですので、チームを率いるリーダーや、発注側・経営側としてスクラムのチームと向き合う立場の方もお付き合いください。

 本題に入る前に、お断りを３ついれさせていただきます。

• 「正解」ではなく「選択肢」。
  …課題への対処法は、プロジェクトが置かれた文脈（コンテキスト）に応じて、異なるアプローチを採ることも珍しくありません。本稿でも課題への対処法を提示することがありますが、それらは「正解」というよりも、「皆さんが採りうる選択肢」と理解してください。他の書籍やブログで提案されているアプローチとは異なることもあるでしょうが、「選択肢が増えた」くらいに捉えていただき、ご自身のチームの文脈で何をすればいいかを考えるきっかけとしてください。
• 「AIツールの具体的な使い方」の開設ではありません。
  …昨今開発現場でAI利用に関する関心が高まっていますが、本連載でAIツールの具体的な使い方を解説することはありません。きっと別の人が別の記事で採り上げてくれるでしょう。
• 餅は餅屋、法的なことは専門家にまかせる。
  …請負契約等の法的・契約実務上の論点も守備範囲外とさせていただきます。

 少々前置きが長くなりました。初回のFAQには、いままさに研修や導入支援の場で受けることが増えている、この時代ならではの質問を選びました。

 AIがコードを書き、テストを書き、設計案まで出してくれる時代です。開発のスピードは桁違いに上がりました。正直なところ、いまさらスクラムの基礎を学ぶ意味はあるのでしょうか？　スプリントで区切って人間が見積りや振り返りをするのは、AIのスピードの前では、“儀式”に見えます。

 学ぶ意味はあるし、重要性はむしろ増しているとさえ思います。なぜなら、スクラムが管理しているのは「作るスピード」ではなく「進むべき方向」だからです。
 AIが劇的に速くしたのは「どのように作るか」であって、「何を作るか」「作った結果から何を学ぶか」は人が主体的に行う活動であり、AIが助けにはなっても、AIに丸投げすることはできません。作るスピードが上がるほど、間違ったものも速く作れるようになる——この単純な事実が、検査と適応（作ったものとやり方を頻繁に点検し、次を調整し続けること）という地味な基礎活動の価値を、かつてなく高めています。

 まず、冷静に仕分けをしましょう。生成AIが確かに変えたのは、実装・テストコード作成・定型設計・調査といった「どのように作るか」の領域です。ここが数倍（いやもっとかな？）速くなったという主張に異論はありませんし、私自身実感してもいます。

 では、次の問いはどうでしょうか。

• この機能は誰のどんな業務課題を解決するのか。
• リリースした結果、狙った効果は出たのか。
• 出なかったとして、次に何を変えるのか。
• チームの今のやり方は機能しているか…。

 これらは、人が主体的に意思決定するテーマであり、AIは答えを持っていません。もっともらしい答えの文章は生成してくれますが、その検証責任は人に残ります。そしてお気づきの通り、「何を作るか」「作った結果から何を学ぶか」「チームでどう検査と適応を回すか」は、アジャイルがこの30年間一貫して問うてきたことそのものです。AIは、アジャイルが担ってきたこれらの問いを何ひとつ引き受けてくれていない。むしろ、問いに向き合わないまま作れてしまうスピードだけが上がったのです（少なくともこれまでのところは）。

 その帰結として、現場で目にするようになった光景があります。AIの生成物を、十分な検証もせず、その意図を理解もせずただ丸呑みして積み上げていく開発…「それじゃぁ『AIいいなり開発（AI-Dictated-Development）』じゃないか！」と叫びたくなる姿です。本来の「AI駆動開発（AI-Driven-Development）」とは似て非なるものです。

イラスト左：AI駆動　　　イラスト右：AIいいなり

 AIいいなり開発の特徴は、一つひとつの成果物がもっともらしいことです。コードは動き、テストは通り、ドキュメントは整っている。問題は、その全体が誰の何のために作られたのか、誰も満足に説明できないことです。検証されていない仮定の上に、検証されていない生成物が高速に積み上がっていく。従来なら数ヶ月かかった「間違った方向への行軍」が、数週間で再現できるようになりました。

 しかし、これは新しい病気ではありません。「要件定義書に書いてあったから作りました」「言われた通りに作りました」——意図を問わない開発は昔からありました。AIはそれを高速化し、かつ「作った感」で覆い隠すのがうまくなっただけです。

 診断が同じなら、処方も同じ系統です。

 この連載で扱う基礎を、AIの文脈に置き直してみます。

• 宛先と目的を問う習慣は、「このコードは誰の何のためか」(fig002)をAIの出力に対しても問わせます。生成物がもっともらしいほど、この問いだけが人の仕事として残ります
  
• 小さく完成させて検査するリズムは、生成されたものを鵜呑みにせず、動かして・使わせて・学ぶ機会を強制的に確保します。スプリントは「人間が遅いから区切る」のではなく、「学習のリズムを設ける」ための仕組みなので、生成が速くなっても不要にはなりません。むしろ検証すべき生成物が増えた分、検査のリズムの価値は上がります
• 計測と記録の規律は、「AIで速くなった気がする」を検証可能な事実に変えます。リードタイム（着手から届くまでの時間）は本当に縮んだのか、手戻りは増えていないか。道具の評価もまた、検査と適応の対象です

 逆に、変わってよいものもあります。スプリントの長さ、見積りのやり方、ドキュメントの作り方…これらはスクラムの進行を調整する“運用パラメータ”であり、AIによって最適値が変わり得ます（この「基本」と「運用パラメータ」の区別は、次回以降の各論でも繰り返し登場します）。生成が速いなら、スプリントはもっと短くできるかもしれない。見積りの議論は、作って確かめる方が速い場面が増えるかもしれない。パラメータは大胆に見直してください。この技術の大変革の時代に、「批判精神なき前例踏襲は、“罪”」です。
これらパラメータの変更もチームで議論し合意し、その効果を検査する対象です。周囲を無視して現場で好き勝手やっていい話ではありません。

 そして、ここまで説明した検査と適応のループそのものを外した瞬間、残るのは「高速ないいなり」です。

 「新しい道具が来たから、プロセスの基礎はもう不要では？」という問いは、実はAIが初めてではありません。CASEツール（設計図からコードを自動生成する1980〜90年代のツール群）が自動生成する、RAD（試作を繰り返して短期間で作る1990年代の開発手法）で開発が桁違いに速くなる、ローコードでプログラマーが不要になる…新しい道具が現れるたびに、同じ問いが再演されてきました。打者一巡どころか、これはもう何巡目かの打席です。

 そして毎回、結論も同じでした。道具は「どのように作るか」を変え、ときに劇的に改善する。しかし「何を作るべきか」「作った結果から何を学ぶか」は道具の外に残り続け、そこを疎かにしたプロジェクトは、速い道具で速く失敗した…。

 AIが過去の道具と規模の違う変化であることは認めます。だからこそ、と言うべきでしょう。道具が強力になるほど、ハンドルを握る側の基礎が問われます。本連載がこれから扱うのは、そのハンドルの握り方です。

 次回以降の予定ですが、タイトルと順序を以下に列挙しておきます。
ただ、これらは仮のもので、断りなく変更される可能性があることをご承知おきください。

• 第2回: 保守運用チームにスクラムは合わないのでは？
• 第3回: アップグレード案件の「現行機能保証」にどう向き合う？
• 第4回: 更改案件の見積を、全機能を確定せずにどう出す？
• 第5回: ドキュメントが信用できない現行システム、何を『仕様』にして検証する？
• 第6回: デイリースクラムが進捗報告会になっています
• 第7回: レトロスペクティブが機能しません…同じ改善案の再放送と、ToDoの列挙会
• 第8回: スプリントレビューにステークホルダーが来なくなりました
• 第9回: ストーリーポイントの人日換算を上司に求められます
• 第10回: ベロシティが安定しません。計画に使っていいの？
• 第11回: スプリント内に終わらないタスクが毎回出ます
• 第12回: 割り込み作業はどう計画に入れる？
• 第13回: POが多忙でチームに来ません
• 第14回: スクラムマスターは何をする人？ 暇そうに見えます
• 第15回: 自己組織化と言われても、結局リーダーが全部決めています
• 第16回: 技術的負債の返済をPOが優先してくれません
• 第17回: ドキュメントはどこまで書けばいい？
• 第18回: 最初は改善が進んだのに、最近チームが停滞している気がします
• 第19回（最終回）: 連載の総括

 長い文章にお付き合いいただきありがとうございました。

次回: 「保守運用チームにスクラムは合わないのでは？」