AIで爆速になろうと開発速度は同じでいい。吉羽氏に聞く「アジャイルの“逆説的な”加速の仕方」

AIのおかげでコーディングなどの速度が大きく向上した。では、このブーストをどう活かすべきか――。

AIが急速な進化を遂げるなか、ソフトウェア開発の領域では「AIの力を活かせる組織づくり」「AIネイティブな開発プロセスへの変革」もまた急ぐべき課題となっています。

しかし、アジャイルコーチとして多くの現場を支援する吉羽龍太郎さんは、このように考えているといいます。

「AIの恩恵でたくさん開発できるからといって、たくさん開発しなくていい」
「AIに適応した開発チームやプロセスへの変革は、ちょっとずつ進めればいい」

まるで時代に逆行しているようにも聞こえてしまう、吉羽さんの考え方。しかし、ここにはアジャイルという思想の根幹を理解していなければ、見落としてしまう重要な観点が隠れています。“AI時代のアジャイルの逆説”について、同氏に伺いました。

• keyboard_arrow_down AIで開発は速くなる。でも、増やしたいのはアウトプットか？
• keyboard_arrow_down チーム・プロセスの変革は「自分たちなりにちょっとずつ進めればいい」
• keyboard_arrow_down AIのスピードが、「チーム内の分担・分業」をボトルネックに変えた
• keyboard_arrow_down 開発も企画も全員でこなす「AI時代のフラットな小規模チーム」
• keyboard_arrow_down 変わりつづける「HOW」、変わらないアジャイルの「WHY」

――AIによって開発効率が大きく上がった現在、多くの組織にとって「その恩恵をどう活かすか」が大きなテーマになっています。実際、現場ではどのような動きが主流になっているのでしょうか。

吉羽：一般的には「開発が効率化した分、より多くの機能を実装する」「空いた時間に次の開発を詰め込む」といった、アウトプットの量を増やそうとする傾向が強いように感じます。

しかし、私は「たくさん開発できるからといって、たくさん開発しなくていいのでは」「新機能の提供ペースなどは、いままでと同じでいいのでは」と考えています。

――それは、なぜでしょうか？

吉羽：「プロダクトの機能の数が増えると、ユーザーはうれしいのか」というと、必ずしもそうではないからです。

例えばX（旧Twitter）の多くのユーザーにとっては、ポストができて、タイムラインが見られて、リポストができる機能があれば十分なはずです。他にもさまざまな機能がありますが、めったに使うことはなく、なくても構わないでしょう。

さらに言えば、機能を増やすことでプロダクトが複雑になったり動作が重くなったりして、かえってユーザーの満足度が下がってしまうリスクもあります。「使われない機能をいかに削り、プロダクトをシンプルに保つか」はとても重要な問題なのです。

しかし、多くの組織が、あれもこれもと機能をつくりすぎてしまいます。

特に、プロダクトがうまくいっていないときには「機能をたくさんつくればユーザーに使ってもらえる」「この機能がないから顧客が買ってくれないんだ」という発想に陥りがちです。結果として「機能はどんどん増えていく一方で、プロダクトはいまいち成長しない」というのもよくある流れです。

こういう失敗は効果測定をきちんとしていないチームや、開発チームと企画チームが分離していて、開発チームが「降ってきたものをつくるだけ」という姿勢になっている場合に多いですね。

――プロダクト開発には、実は「開発しすぎる」というアンチパターンがある、と。

吉羽：プロダクトが売れるには、ユーザーの課題を解決しなければいけません。「これがあれば自分の課題が解決できる」と感じてもらい、さらに「お金を払ってでも使う価値がある」と思ってもらわなくてはいけません。

このためには「プロダクトにどんな機能があるか」よりも「どんな課題にアプローチしているか」「それは本当に解決すべき課題なのか」という点のほうが重要です。

であれば、「AIによる開発高速化で生まれた空き時間は、さらなる開発ではなく、ユーザーインタビューや仮説検証などに使ったほうがいいのではないか」というのが私の考えです。

――「AIを使って開発速度を上げる」ことに固執する必要はないということですね。確かに「アジャイルは、何を早くすることを目指す思想なのか」というと、「機能開発」ではなく「価値提供」だとよくいわれます。吉羽さんの指摘も、そのような観点からでしょうか。

吉羽：そうですね。アジャイルという思想は、根幹的に「より早くユーザーに価値を届ける」ことを志向しています。

アジャイルでは、「アウトプット（つくる量）」よりも「アウトカム（それによって得られる成果）」を、そしてアウトカムよりも「インパクト（事業や社会への影響）」が重要だと考えます。

しかし、「アジャイル」という言葉が世に出て四半世紀が経ったいまなお、「アジャイル＝早く開発する手法」という側面ばかりが注目されやすく、ついアウトプットを増やすことに意識が向いてしまう組織が多いのが実情です。

――一部の開発者の間では「AIは急速に進化している。開発組織やプロセスの進化も急がなければならない」という焦燥感のようなものが漂っていると思います。しかし、どのように変革を進めていくべきなのでしょうか。

吉羽：私は「自分の現場に必要な取り組みを、必要に応じてちょっとずつ取り入れていけばいい」と思っています。

アジャイルにおいてはプロダクトだけでなく、開発プロセスもまたチーム自身が生み出し、定期的に検査していくものなんですよね。

より良い方法を探しつづけ、次第に開発プロセスが変わっていく。気付けば、以前とは全く異なるチームやプロセスになっている。そんな状態のほうが、むしろ健全だという考え方をします。

――チームやプロセスの変革は、「ちょっとずつ」でいいのでしょうか？

吉羽：というより、ちょっとずつでなければいけないんです。

これはインフラのパフォーマンスチューニングと同じです。一気に多くの要素を変えてしまうと、何が功を奏し、何が悪影響を与えるのか、原因がわからなくなります。また、失敗が気になったり後に引けなくなったりすることも、一気にやろうとする上で生じがちなデメリットですね。

私はよく「まず実験しよう」という言い方をします。実験としてカジュアルに試してみて、良ければ定着させ、ダメならやめる。そういうサイクルを回すことを推奨しています。例えばスクラムで、1週間のスプリントごとに1つずつ新しいチャレンジを積み重ねれば、1年で50回の実験ができます。それだけで、組織のパフォーマンスは劇的に向上するはずです。

――「ちょっとずつで構わない」のではなく「ちょっとずつでなければならない」のですね。

吉羽：アジャイルの価値観や原則を体現できているチームは、単にスクラムの形式をなぞるのではなく、こうした高いレベルのチューニングを常に繰り返しています。

ただ、もしも「役に立つソフトウェアを短い間隔でデリバリーする」といったアジャイルの基本がまだ実践できていないのであれば、まずは一般的な手法を愚直に取り入れるところから始めるのがよいと思います。

――では、AIが開発のあり方を変えていくなか、従来の開発の進め方にはどんな問題が現れていますか？

吉羽：HOWの部分は、ツールの登場や時代の流れによってどんどん変わっていくものですね。AIによる変化も大小さまざまに起こっていて、なかには従来のチームやプロセスの維持が困難になるほど影響の大きな場合もあります。

1つには、コードを書く速度が上がったことで、「何をつくるかを考える」という前工程への負荷が増したことです。

従来の開発速度は、人間を前提としたペースでした。そのスピード感に合わせてつくりたいものを準備し、「次はこれをつくろう」とチームでプロセスを進めることができていたのです。

しかし、AIによってコーディングなどが加速したことで、「何をつくりたいのか」という、いわば“開発の材料”の供給が追いつかなくなっています。これまで以上に大量の材料を準備しなければならず、いままでのチーム体制を続けようとするとプロダクトマネージャー（PdM）やプロダクトオーナー（PO）の負担が非常に大きくなってしまいます。

また、開発の後工程のレビューも高負荷になっています。

いままでは開発内容が決まったら、個々のタスクを各開発者が分担して実装を進めるのが一般的でした。スクラムかウォーターフォールかによってタスクの決め方は異なりますが、「分業体制をとる」ということ自体は、どちらも変わらなかったわけです。

しかし、AIを活用しながらその分業体制を維持しようとすると、コーディングが高速化した分、プルリクエストの数も膨大になってしまう。結果として、レビューが回らなくなってしまうわけです。

――AIによる「開発の前後工程のパンク」という課題に対し、開発組織ではチームやプロセスをどのように変化させる動きが現れていますか？

吉羽：正解があるわけではありませんが、アジャイルの「短い期間に区切って開発を進める」という基本軸は維持しつつ、厳密なスクラムの型に縛られず、より軽量なスタイルに改めるチームが増えています。

私が支援しているチームで多く見られるのは、このような体制です。

チームメンバーは3〜4人程度の少人数に絞ります。かつ、プロダクトオーナー、開発者、スクラムマスターといった役割分担をあえて設けない体制をとります。全員がすべての役割を担うような、フラットな状態ですね。

開発の進め方としては、AIを活用したモブプログラミングを中心に行います。分業体制でそれぞれが並行してタスクをこなすのではなく、全員で同じコードを見て意見を出し合いながら、1つずつ開発していくやり方です。

――さまざまな分担を取っ払った体制ですね。全員で1つのコードに向き合うモブプロでは「開発タスクの分担」がなくなりますが、どのようなメリットがあるのでしょうか？

吉羽：このやり方は、「レビューの待ち時間がなく、結果的にこちらのほうが早い」という理由で取り入れているチームが多いですね。

プルリクエストを介して非同期にレビューしてもらうやり方だと、誰かがレビューしてくれるまでの待ち時間が発生します。しかし、モブプロであれば全員がその場にいるので、リアルタイムにレビューまでできるというわけです。

――とはいえ、フロントエンド、バックエンドといった「技術領域の違いによる分担」もありません。支障なく開発を進められるものでしょうか？

吉羽：これまでしっかりとスキルアップを積み重ねてきたチームであれば、少人数でも自分たちだけでデリバリーまで完結できる環境が整いつつあります。

これまでは不慣れな技術領域では開発が難しく、それが「フロントエンドエンジニア」「インフラエンジニア」といった分担を設ける理由のひとつになっていました。

しかし現在は、AIのサポートが受けやすくなったことで、ジェネラリストとして一通りの知識を持っていれば開発できるケースが増えています。

――重ねてお聞きしてしまうのですが、このようなチーム体制では「職種による分担」がないので、開発者もプロダクトオーナー、スクラムマスターの役割を担うことになりますよね。隣接領域への越境について、吉羽さんはどう見ていますか？

吉羽：開発者がプロダクトバックログアイテムを書いたり、ユーザーインタビューに行ったり、プロダクトづくりに必要なことであれば「これは本当に開発に分類される仕事なのか？」というところまでやる。そうした変化は、今後、広まっていくのではないかと考えています。

正解が分からないプロダクトづくりは、誰かひとりの力で考えきれるものではなく、みんなの知恵や視点が必要です。開発者も「そもそも何をつくるのか」というところから関わったほうがいいんですよね。

そもそも私は「開発者の仕事は、開発をすることだ」という発想自体が、ある意味で近視眼的だと思っています。

プロダクトの売り上げが立つことで、会社にお金が入り、そこから自分たちの給料が支払われる。であれば、「開発者にもプロダクトを成功させる責任があり、与えられた要件をただこなすだけでは不十分だ」と考えるのは、プロとして当然のことでしょう。

――このまま、さらにチーム内で“職種の壁”がなくなっていくとしたら、マネージャーという役割はどうなると思いますか？

吉羽：プロダクト中心の組織をつくるのであれば、そもそもマネージャーはチーム内ではなく、チームの外側に配置されるべきだと考えています。これはAIの登場前から変わらない意見です。

プロダクトをつくるチームには、多くの権限が委譲されている状態のほうが健全です。いちいちマネージャーの意思決定を仰いでいてはスピードが出ませんし、現場のアイデアも活用しにくくなります。

ただ、「チームの組織構造を変える」といった大きな変更が必要なときは、人事や評価の権限を持つマネージャーの出番です。

現場からエスカレーションが上がってきた際に、周囲の意見を聞きながらチーミングをしていく。こうした働きかけを通じて、チームを健全な状態に保つことが、マネージャーが担うべき本質的な役割で、これからも変わらないのではないかと思います。

――最後に。ここまでチームやプロセスのあり方といった「HOW」の変化を伺ってきました。では、そもそもアジャイルを目指す理由、つまり「WHY」の部分に変化はあるのでしょうか？

吉羽：アジャイルという思想の根幹はまったく揺らいでいないと思います。

現代のプロダクト開発では「すでに正解が分かっているもの」ではなく、「まだ世の中にない新しいもの」をつくるのが主流です。それには「実際に動作する評価可能なものを短い間隔でつくり続け、フィードバックを得ながら改善していく」というアジャイルのアプローチが効果的です。

こうした「正解のなさ」が前提にあり、アジャイルが有効とされる状況は、AIが登場しても変わっていません。というのも、AIはさまざまな仕方で開発を支援してくれますが、「どういうプロダクトをつくれば当たるのか」については教えてくれないのです。

プロダクト開発は「10回打席に立って、やっと1回当たる」というような不確実性の高い世界のままです。でも、AIのおかげで空振りする痛みは小さくなりました。

これからも人間が「何をつくるか」を意思決定して、頑張って打席に立っていきましょう。

取材・執筆：川島 昌樹
編集：川島 昌樹、田村 今人