鳥貴族で考えるスクラム

やむ🏔️
·

鳥貴族の晩餐会で吐く寸前まで行ってしまった。ただここから得られる教訓もあったので残す。

食べ放題でスクラムは活きる

食べ放題、甘美な響きである。ただ同時に集まる人間の胃袋という不確実性を抱えている。自分が食べられる量を正確に把握できている人はいるだろうか。おそらくいないだろう。

この他人の胃袋という不確実性を抱えたまま、大人数で食べ放題の店に行った時、残飯を残さず食べきる必要がある。そうこれはプロジェクトマネジメントだ。

食べ放題のWhy

食べ放題の目的は何か、それは全員が楽しく会計を気にせずに飲み食いしまくることである。元を取ることではない。

好きに選べる、好きにどんなものでも頼める。これが価値であり、すべてだ。

このWhyを考えるとマイクロマネジメントは第一に選択肢から外れる。「これを食え」「あれを食え」そんな言われる食べ放題はただの部活であり、Whyは達成できない。

ウォーターフォールアプローチも取りにくい。事前に何を食べるかを全て決めきることは難しいし、何しろ写真や文字では胃袋への見積もりが立たない。それくらい人間の胃袋が持つ不確実性は高い。そうなればアジャイル的なアプローチが一番妥当である。

システムの透明性

鳥貴族の注文システムでは、「今何が届いていて、何が届いていないか」が一目でわかりにくい。この不透明性が招く自体として、「注文済みだがまだ席に届いていない」商品の数が人が増えれば増えるほど不透明になってしまうということである。

仮に商品の注文からわたし達のお腹に入るまでをリードタイムとする。このリードタイムのうち、「注文から席に届くまで」のサイクルタイムが長く、順々に処理されずにバッチで処理される可能性も加味しなければならない。そしてここは作業の共同化はできない。店員と客という関係である以上、作業の受け渡しになってしまうことは必須。ここは変えられない部分である。

これらの情報から見えてきたアプローチを考える

カンバン的フロー

ここで考えたフローは以下になる

  1. 注文バックログ作成

  2. 注文スプリントバックログ作成

  3. スプリント(バックログリファインメント)

  4. スプリントレビュー

  5. スプリントレトロスペクティブ

このサイクルを回していく。

注文バックログ作成

お店に入る前に「自分は何が食べたいか」を明確にすることができる。それは10点かもしれないし、2点かもしれない。そしてこの1点1点がユーザーストーリーになる。たとえば、「やむとして、チェンジャが食べたい。そうすれば香辛料で総合的に食べられる量が増えるからだ」といったふうにだ。

ここでの優先順位付けは難しいものになる。なぜならPOがいない。POは幹事かと聞かれるとそうじゃない。もし厳密に混沌を避けたいのであればPOを決めるほうが失敗は少ない。

注文スプリントバックログ

入店後、一番最初の注文で何を注文するかを決める期間になる。ようは「次の注文」だ。この「次の注文」はメンバーのベロシティも考慮しつつ、メンバー自身が何を食べたいかを対話しながら決めていく必要がある。おそらく初回のスプリントはアルコール類で埋まるだろう。

ここでベロシティ以上のものを積んでしまうと、次のスプリントバックログが苦しくなってしまう。次のスプリントバックログでストーリーの削ぎ落としが行なえない場合は、残飯を産んでしまうリスクを持ってしまう。そして、食べ物という性質上「次のスプリントではこのストーリーをやらない」という選択肢が取れない。スプリントプランニングの時点で取ってしまったストーリーは絶対なのだ。

スプリント

商品が席に届くまでの時間は他のことをする必要がある。それは前スプリントのタスクかもしれないし、次スプリントで行う予定のストーリーを整理するバックログリファインメントだ。

バックログリファインメント(次注文するものを決める)時間はスプリントの10%くらいで良いだろう。それ以外の時間は歓談や届いたものの消化に当てるほうがスムーズになる。

そしてこの消費仕方も重要になってくる。

リソース効率を重視するメンバーの場合、別々の商品を別々の人が淡々と食べ尽くす戦法を取ることになるだろう。

逆に、フロー効率を重視するメンバーの場合1つの商品をみんなで少量ずつ食べ、まずは「食べることを終わらせる」戦法になるだろう。

これは大きな違いであり、後者のほうが圧倒的にリスクが少なくなる。それは、全員が少しずつ胃袋というリソースを消費していくため、限界が分かりやすい。大体全員が8分目になった時点でアラートを挙げ、次スプリントを中断しやすくなる。

逆に前者であれば、誰かが負担を強いられている時、それを他の人はあまり察知できない。リソースとして明確に区切ってしまうと「その人のもの」という認識が芽生えやすくなり、自分は別のストーリーを消化しようとしてしまう。そして誰かのリソースを超えた時、他の人がサポートに入る頃にはサポートに入る側のリソースも食い尽くされてしまっているため、結果的にサポートに入りにくくなるのである。

WIP制限を設けるのも1つの戦法としてはありだと感じる。どうしても注文中のものの透明性が担保できないため、WIP制限を設けずに仕掛品を増やしてしまうことは不要なリスクだと言える。人数×2品のWIP制限でレーンを区切りつつ、食べ進める戦法を取るケースも十分ありうる。

スプリントレビュー

自分たちの目的が達成されたかどうかを確認する。ご飯物が食べたいのに、焼き鳥を食べていたらそれは目的が達成されていないといえる。

そして、ある程度自分たちの腹状態を確認する。この状態で遂行が厳しいメンバーがいる場合は、次のスプリントでは考慮せずに計画を行う。

スプリントレトロスペクティブ

自分たちが頼んだものに対してふりかえりを軽く行う。胃に溜まりやすいものを注文してしまった・咀嚼回数が多いものを注文してしまった・脂質が多いものを注文してしまった・チェンジャが美味しかったなどふりかえることで、次のスプリントに何を頼むかの判断材料になる。ここでプロセスの改善をし、胃袋への適応を行うことで過剰に注文をすることを避ける。

まとめ

食べ放題は意外とスクラムに通ずるものがあった。マイクロマネジメントされてしまうとどうしても食の場はつらくなってしまう。逆に誰かへの負担が重くなった時に、その人自身の余裕がなくなり、雰囲気は悪くなってしまう。

この経験から得られた学びとしては、ここまでガチガチにしないとしてもある程度ルール化し、フレームワークに則ってプラクティスを回していくことで十分全員が楽しく食べ放題を楽しむことができるということだ。

今日はとってもお腹がいっぱいになった。

@yum3
今までの働き方や価値観への問いを持っています。気持ちはスクラムマスター、実態はWeb開発者