こちらの記事は カケハシ Part 2 Advent Calendar 2023 の 11日目の記事になります。
こんにちは、AI在庫管理バックエンドエンジニアの安藤です。
今回は、在庫管理システムをテーマにXPを意識した取り組みを行ったのが大変だっ楽しかったので、その振り返りをしようと思います。
トライしたこと
先日、自分たちが普段気づいていないことに気づける機会を開発ディレクターの指示のもと作ってもらいました。 普段の開発のなかではなかなかアグレッシブな試みは難しいため、在庫管理のプロトタイピングを改めて試すなかでいくつかの制約を設けることで普段なんとなくやりすごしてしまっていることに気づき、より変化に適応する開発の方法を知ることが1つの狙いでした（当初はそのあたりの目的を完全には理解できていませんでしたが）。
そのなかで与えられた制約について整理しながら振り返ってみようと思います。その制約とは以下の2つです。
- 1時間スプリント
- ロール交代
以下で、順に見ていこうと思います。
1時間スプリント
これはとても衝撃的でした。今までスプリントは1週間とか2週間くらいでやるものと思っていたのに。 「1時間で1スプリントってできるの？」と最初は思いましたが、やってみると意外とできるものです。
やったこと
指示された内容
ディレクターからは以下の指示がありました。
- 「10分プランニング - 30分実装 - 10分振り返り - 10分休憩」のサイクルを1スプリントとする
- 実装時間の30分は、さらに区切って10分 × 3回で時間を区切り、10分で終わらなければ次のユーザーストーリーに移る
- ユーザーストーリーは小さく、3分でリリース可能なものを目指す
10分という枠の中で何ができるんだと不安いっぱいでしたが、とりあえずルールにしたがって始めてみることにしました。
開発スタート
最初は「在庫が存在する」とか「1個の在庫がある」のような最小限のストーリーから始めて、在庫管理ができるシステムを作ろうとしました。なにせ3分で動く状態を作らないといけないので、それくらいの単位でしかストーリーを切ることができません。なるほど、これはエクストリームだ。
進めながら狙いを理解していったこと
実際に始めてみると、3分のつもりで切ったユーザーストーリーが全然終わらないとか、用語の認識が人によって異なっていて微妙に議論が噛み合わず議論に時間を使うなど、いくつかのずれが見えてきました。
それでもなんとか数スプリントを進めたところで、印象的な出来事がありました。 在庫の数が取れるようになったところで「在庫の品目名が見える」というユーザーストーリーを実装するスプリントがありました。ぼくはそこで、プロダクトオーナーのロールだったのですが、在庫モデルに直接品目を文字列で持たせる判断をしました。 エンジニアであればほとんどの場合品目モデルが在庫モデルとは区別されることは容易に想像できます。そのため、「モデルを分けるべきだ」と反論がありました。 しかし、文字列で品目を持ってもユーザーストーリーの完了条件は満たせるし、3分でリリースするには余計な設計はなるべくあきらめなければなりません。リファクタリングが必要ならリファクタリングのユーザーストーリーを詰めばいいはずと考えその場は進めましたが、これをきっかけに3分という短い時間での実装を積み重ねるべきではなく「モデリングをしてから実装に入るべき」という声が強くなりました。
苦労したり工夫したこと
実際、こういった極端な要求を継続することは難しく、3分でリリースするというルールを守るのは難しくなっていきました。そのため、1時間スプリントの実装時間を10分単位で区切って10分で1ストーリーくらいの粒度でモデリングを進めていくというアプローチに変化しました。これは、上であがったようなモデリングをして見通しを立ててから進むほうが紆余曲折しない分効率よく進めるという判断からでした。 その後は、十分に時間がない中でモデリングを進めるのも難しかったですが、アナリシスパターンなどを参考にしながらショートカットできる部分はショートカットすることで短時間で在庫管理のモデリングを最低限完成させ、実装に入っていくことができました。 ただ、やっぱりモデリングをしている間は動くものとしてのシステムは作れず、アウトプットはモデル図のみになってしまいます。実際の開発では、モデル図を顧客に見せるわけにはいかないので、顧客から見たらこの間の進捗はほぼゼロに見えるんじゃないかという不安がありましたが、モデルの見通しを立てたあとはモデルに沿って開発スピードを上げて追い上げることができると判断して継続していました。このあたりはとても葛藤しました。
葛藤はしていましたがそこから方向転換し直すことも難しく、ある程度実装が終わったところで今回の試みは終了しました。
分かったことや学んだこと
1時間スプリントというタイムボックスは集中的に開発を進めるための方法として有効でした。3分リリースは守れなくなりましたが、それでも、10分で1ストーリー・1時間で1スプリントという枠は効果的に機能したタイミングは多かったと思います。モデリングを議論する中で、議論が発散しかけたときも、時間枠があることでスコープを意識しながら議論を収束させることができました。
最初は10分のプランニングと30分の実装で何ができるんだと思っていましたが、実際に進めてみると、意外とできることはありました。だんだんとそのスプリントでできることを判別し、1時間のスプリントの中でできることを選択できるようになったのだと思います。 タイムボックスを区切ることで、自然と「捨てる」判断ができるようになります。プランニングの際にどんなに長くても30分、実際には10分以内で終わるユーザーストーリーを作ることになるので自然と小さくでき、取り組みやすい状態は継続的に作ることはしだいにできるようになりました。これは、自然と必要のないことを「捨てよう」と意識することなく捨てられていた結果かと思います。 また、小さく区切るためには「小さい価値を価値と認める」ことが必要だと思います。「これくらいやっただけじゃ価値にならない」と思うような小さいことを1つ1つ価値と認めて、積み上げていくことで短いスパンでの開発が実現できるんだと思いました。
途中で悩んでいた「モデル図は顧客にとっての価値にならないのではないか」「とはいえ、闇雲に実装をしても正しい方向に進めているのか不安」という点は今でもまだちゃんと答えは出ていません。 また、3分リリースを厳密に守り続けていればどうなっていたかは今となっては未知になってしまいましたが、「設計を遅延させる」勇気と「リファクタリングをあとから入れられる」確証や自信がないと3分リリースを守り続けることは難しいのかなと、今では思います。このあたりは、単にタイムボックスを決めるだけではなく設計や進め方の別のスキルが必要なのかもと考えています。
ロール交代
さて、次はもう1つのルールとして提示されたロール交代について整理します。
やったこと
指示された内容
スプリントごとに、ロールを指定・交代しました。最初に用意されたロールは以下の5つです。
- 学びの回転を早くするために時間単位を計測し小さく早くたくさんの学びのベースを作るする人（タイムキーパー）
- ユーザーストーリーに責任を持って目的に近づける人（プロダクトオーナー）
- ふりかえりで嫌な事を撤退的に無くし、学びを増やし、知的好奇心を満たしながらチームを効率化させチームの価値を高める人（振り返りマスター）
- 楽しめる様にムードメイキングや会話の偏りを補正して多様性を確保しながら成果を出せるチームにする人（チームビルダー）
- 保守性と変更容易性を確保する人（内部品質マスター）
そして、これらのロールについて、
- 新たにロールを作ってもOK
- 押し付けてもOK
- 奪ってもOK
- 何かのロールに文句をいうなら自分もそのロールを背負う
などのルールが指示されました。
実際に進めたこと
プランニングの最初に自分がどのロールを担うかを宣言しました。 基本的には順番にローテーションで割り当てることから始めましたが、実装時間中に別のロールの振る舞いをしていることもありました。 そして、スプリントの振り返りの時間に、「各ロールが出した価値はなにか？=スプリント内に起こした状態の変更はなにか」を振り返りました。
とはいえ、このロール交代は、比較的早い段階で形骸化してしまいました。1時間スプリントの試みだけでも比較的アグレッシブななかで、普段と違うロールを担って価値を出していくのはなかなかに負荷が高かったです。
進めながら狙いを理解していったこと
実際やってみると、タイムキーパーは単に時間を計るだけでも議論に熱中しすぎてしまって難しかったり、プロダクトオーナーはいざユーザーストーリーの優先順をつけようとしても何から判断していいのかわからなかったりと難しい局面がたくさんありました。 また、振り返りで自分の出した価値について聞かれても、答えるのに困る場面も多く、いかに自分が状態の変化をつくりだせていないかを実感しました。
これも最初は狙いがよくわかっていないまま始めたことではありましたが、このロールごとの難しさを実感するということがまずは大事だったのだとあとでディレクターと話しながら理解しました。 エンジニアとして働いていると、周りのディレクターやPdMなどのロールの方が何を考えて行動しているのかに思いが至らないこともあると思いますが、そうした無知の知に気づけるいい機会だったと思います。
また、1時間ごとに交代できるのはライトにロールを体験できるという面ではよかったように思います。 ふだんの開発の中で、急に別のロールの人から「私と1週間交代しましょう」と言われても「いや、ムリムリ」ってなっちゃうので。
分かったことや学んだこと
いざプロダクトオーナーのロールを持ってみるとどういうユーザーストーリーを作っていくか判断するのが非常に難しかったり、内部品質マスターはプロダクトオーナーのユーザーストーリーに対して内部品質を向上させるストーリーを挟むタイミングが難しかったりと、体験できたところはあると思います。 また、途中から時間の管理はみんながタイマーをうまく使えるようになることでタイムキーパーが不要になったりしました。仕組み化したりノウハウが共有されることでロールがなくなることもありました。
月並みな感想かもしれませんが、このように別のロールで考えていることを少し体験するというのは、たしかにそのロールの難しさを体験するという面もあるものの、逆にユーザーストーリーを進めるために他の誰かがやってくれていることを垣間見ることができたと思います。たとえば、上で書いたようにぼくが「品目はこのモデルでいく」と決めたとき、それは3分というリリース期限を重視して決めたのですが、他のエンジニアからは反発を受けたわけです。普段PdMが何を作るかを決めるときにはPdMなりの合理性があるなかで決めており、他方でエンジニアの観点からはそれに対して合理的な判断でそれに対して意見を出すわけです。PdMが決めるのも、エンジニアが意見するのもどちらもそれぞれ勇気がいることだと思います。
逆に言えば、PdMの合理性では判断できないエンジニアの理屈をエンジニアはちゃんと主張することが価値になると思います。その落とし所を決められた時間の枠の中で判断していくことがプロダクト開発で大事なんだと思います。
まとめ
今回は、プロトタイピングをするなかで試みたXPな取り組みを紹介しました。
- 1時間スプリント
- ロール交代
今回のプロトタイピングは1か月ほどで取り組みとしては終了しましたが、ここで試みたことをふだんの開発でも活かしていこうとしているところです。
XPの考え方のうちに「設計を遅らせる」というものがあり、このあたりは最近のDDDなどの文脈とは少し考え方が異なるため、受け入れづらいところはあったかと思います。どうやって変化を受け入れつつ、闇雲に行ったり来たりするだけではなくビジョンをもって進むのかというあたりが今後の課題なのかなと思っています。
最後に宣伝です！
カケハシは、これから更なる成長のフェーズに突入します。「医療業界をしなやかに」するために挑戦すべき多くの課題があり、成長できる機会がたくさん転がっています。もし気になった方がいれば、採用サイトをチェックしてみてください！また他のカケハシメンバーもアドベントカレンダーで記事を書いておりますので、是非そちらもあわせてご覧ください！
