はじめに
こんにちは。楽楽販売の開発を担当しているuemuraです。
楽楽販売では11月に、初のAI機能をリリースしました。
楽楽販売をご契約いただいたお客様が導入準備をスムーズに進められるように支援する、チャット形式の機能となっています。
プレスリリースはこちら。
本機能の開発PJは楽楽販売にとって（また私自身にとっても） 初のAI機能開発、初のアジャイル×スクラム開発 となっており、新しいこと尽くめでした。
AI機能を開発する難しさもさることながら、アジャイル×スクラム開発にもなかなか苦戦したため、その学びを残しておこうと思います。
目次
体制紹介
従来の楽楽販売の開発の流れはいわゆるウォーターフォール型です。
プロダクトサイド（組織図の"事業本部サイド"）から要求が下りてきて、エンジニアがそれを実現します。
プロダクトサイドとエンジニアは組織構造的にも離れています。
ただ、市場に対して開発スピードのUPを図るためにも、本開発ではプロダクトサイドのメンバーとエンジニアで以下のようなクロスファンクショナルなスクラムチームを組みました。
- プロダクトオーナー
- プロダクト戦略から1人
- カスタマーサクセス（CS）から1人
- エンジニア4人（私はココ）
- スクラムマスター（所属はエンジニアサイド）
※プロダクトオーナーが2人いる体制はスクラムの原則からズレているのでオススメしません
どのような流れで開発が進んだか
開発期間は2か月半ほどでしたが、ざっくりと3つのフェーズで開発は進みました。
フェーズ1：立ち上がり
ターゲット顧客の設定
楽楽販売はご利用いただいているお客様の業種や企業規模が多岐にわたります。
AI機能を開発するにあたって、全てのお客様に届く機能を作るというよりは、価値を提供したいメインターゲットを決めそのお客様に使っていただくことを第一に想定して開発を進めました。
CS業務の理解
ターゲットとなるお客様群に対して、楽楽販売の契約～導入までの間にCSがどんな支援を行っているのかをエンジニアがキャッチアップしました。
主に導入支援時のCSとお客様のやり取りの録画を確認することで、ターゲット顧客への解像度も上がりましたし、導入支援時のお客様、CSのペインを知ることができました。
とりあえず動くもの作成
ターゲット顧客にどんな体験を提供するかはこの段階では未定でしたが、まずはステークホルダーにこれから作ろうとしているAIチャット機能のイメージを持ってもらうために、最低限の会話と導入支援ができるシンプルなチャットを作ることを最優先しました。
フェーズ2：仮説ドリブンの機能開発
ターゲット顧客にどんな体験を提供すればいいかは探り探りだったので、主にCSの現場目線から必要な機能の仮説を立てプロダクトバックログ化していました。
エンジニアは仮説に対するフィードバックを高速にもらうために、バイブコーディング的にとりあえず動くインクリメントを毎スプリント積み重ねてスプリントレビューで披露しました。
ステークホルダーやCSの方々、実際のお客様からもフィードバックをいただき、実運用で課題になりそうな点を集め改善を繰り返しました。
最初は順調に進んでいるように見えていましたが、だんだんと、
- プロダクトオーナーは集めた課題や新たな仮説のバックログ化
- エンジニアはできたてのバックログを次のスプリントレビューに間に合わせるための短納期な開発作業
に追われることになりました。 このフェーズで高速にサイクルを回したおかげで探り探りだった機能のスコープを定めることができましたが、一方で開発内部ではバイブコーディングを繰り返したことによる負債がどんどんたまっていくことになりました。
フェーズ3：品質改善とリリース準備
これまでの負債を返すように、終盤はリリース品質の確保が中心になってしまいました。
フェーズ1,2と「スプリントレビューに間に合わせるためにとりあえず動くもの」を優先したことで、リリース品質に満たないインクリメントが積み重なってしまっていました。
そういった品質負債を解消し、リリースできる品質まで持っていくことに終始することになりました。
（スクラムを始める段階で、品質改善の予定は確保していましたが、当初の計画よりずっと大きなボリュームとなってしまいました。）
品質改善に追われつつも、何とかリリースを迎えることができました。
良くなかった点
開発を進める中でいかにもスクラム初心者がハマってしまう落とし穴にハマってしまったので、簡単に改善点を振り返ってみます
自転車操業に陥った
要件が探り探りだったため、開発期間中に仮説⇒実装⇒検証を繰り返すことになりました。
その結果、各スクラムイベントとスクラムメンバーは互いに首を絞め合うような負のサイクルに陥ってしまいました。
プロダクトオーナーは、毎スプリント出てくるフィードバックの整理や新たな仮説のバックログ化に追われました。 結果、 将来のための計画や先を見据えたプロダクトバックログの整備ができない状態に陥りました。
スプリントプランニングでは、整理され切っていないプロダクトバックログがスプリントゴールに入りました。
結果、スプリントバックログも具体性に欠けたものになってしまい、スプリントが始まってからプロダクトバックログを具体化する必要がありました。
エンジニアは、「まず動くものを作らないとレビューに出せない」という意識のもと、短期開発に追われました。
結果、品質が犠牲になり インクリメント と リリース可能な品質 の乖離が広がっていきました。
また、エンジニアはプロダクトオーナーへの支援として技術的な面からプロダクトバックログの整理を手伝うべきだったのですが、そこまで意識や手が回っていませんでした。
結果、未整理のプロダクトバックログが積み重なったまま次のスプリントへ…という負のスパイラルに陥ってしまいました。
原因と対策
PJ終了後にスクラムチームで振り返りを行ったのですが、いくつかの原因と対策が挙がりました。
要求があいまいだった
アジャイル開発という名のもと、仮説と検証を繰り返す前提で要求があいまいなままスクラムが始まりました。
プロダクトオーナーは要求の整理をしつつも、エンジニアにバックログを用意しないといけないので将来よりも目先のことに時間を使わざるを得ない状況が続きました。
アジャイルとはいえ、スクラム開始前にターゲット顧客や届ける価値の方針を固めておき、スクラム中は方針実現のための仮説・検証に注力できるようにするべきでした。
1スプリントの期間が短すぎた
1スプリントを1週間で回していましたが、一度負のスパイラルに入ってしまうとリカバリーが難しかったです。
プロダクトオーナーやエンジニアに時間的な余裕を生むためにも次回以降は1スプリントの期間をもう少し長めに置くことを検討しています。
インクリメントの品質を担保できていなかった
PJ終盤はインクリメントの品質向上に追われてしまいました。
これの原因は完了の定義を用意していなかったことに尽きると考えています
完了の定義とは
何をどこまでやれば「プロダクトバックログを完了とする」かを定義したリストです。
具体的には、以下のようなものが挙げられます
- コードレビュー
- 機能テストに合格
- 単体テスト合格
- 統合テストに合格
- リグレッションテストが作成され合格している
- テスト環境にデプロイされている
- POはユーザーストーリーの完了を確認している
完了の定義を置いておくことでリリース可能な品質を保ちながらインクリメントを重ねる効果が見込めます。
今回のPJでは「とりあえず動くものを作ってスプリントレビューに臨んでいること」にエンジニアが疑問を持つこともできていなかったので、
そういった意識レベルの改善のためにも完了の定義は必要でした。
生成AIによるコーディングとの付き合い方
上記2点の改善点の根本的な原因はアジャイル×スクラムに対する知識や準備不足であることは間違いありませんが、
個人的には、そこに生成AIの活用方法の未熟さも重なり、結果として課題が大きくなったと感じています。
生成AIによるバイブコーディングは「とりあえず動くもの」を作るのには強力です。
今回のPJでは仮説⇒実装⇒検証を繰り返すタイミングでバイブコーディングの力を借りることで、
高速にサイクルを回し、探り探りだった機能要件を定めることができました。
一方で、高速に実装できてしまうが故に負債もどんどんたまってしまったとも言えます。
どこかのタイミングでバイブコーディング的なAI活用から
「リリースを見越し、仕様や内部設計をしっかり固めながら実装するAI活用（強いて名前を挙げるなら、仕様駆動開発が近いでしょうか？）」
に切り替えるべきでした。
今回はそういった生成AIの活用方法の未熟さもあり、結果的に開発の負荷を高めてしまったと感じています。
（ただし、仮説⇒実装⇒検証を十分繰り返せていなければ、そもそも未だにリリースできていたかどうかも怪しいので、バイブコーディングしたこと自体が間違いだったとは思っていません）
それでもスクラム開発して良かったポイント
何かと大変な点もありましたが、クロスファンクショナルなチームによるスクラム開発には明確に良かった点もあります
顧客志向が付いた
ビジネスサイドの方と同じチームで働くことで、ビジネス課題や中長期の市場への向き合い方、またお客様や導入プロセスへの解像度が上がりました。
AI機能を開発をする。と最初に聞いたとき、自分のエンジニア的好奇心から「いかにもAIっぽい機能を作りたい」気持ちも生まれたんですが、スクラムチームの人と会話し、顧客の解像度を上げることで、「作りたいものを作る」ではなく顧客の困りごとを解決するための手段を考えるマインドにシフトできました。
スピード感をもってリリースできた
初のアジャイル×スクラムに苦労はしましたが、楽楽販売の従来の開発スタイルではもっとリリースまでに時間がかかっていたと思います。
世に出さないと価値は生まないので、これからもスピード感は大事にしていきたいです。
最後に
この文章を書きながら追加機能のリリースも先日行いました。
追加機能の開発の中でも新たな課題も生まれましたが、一方で上記に挙げていた課題を一定解消することもできました。
この記事が、スクラム開発を始めようとしている人に少しでも役立てば幸いです。
