最近PlateUp!というゲームにハマって会社の同期と何度かプレイしていたんですが、その中でこのゲームの本質は開発組織における開発生産性と近しいのでは？という話が出たのでその話をします。

PlateUp!はSteamで販売されているインディーゲームです。
内容としてはレストラン経営をするアクションゲームで、ホール・キッチンのタスクをこなしながら客を捌いていき、稼いだお金で店を拡張することを目指します。（Overcookedにホールの要素が加わっているといえばわかりやすいでしょうか）

そもそものゲーム自体がめちゃめちゃ面白いのでプレイしたこと無い方は開発生産性に興味なくても一度プレイすることを強くおすすめします。

このPlateUp!、タイトルがアッパーキャメルケースになっていること以外にも様々な要素がエンジニアリングと関係しています。

PlateUp!ではどれだけ仕事をしようと客に料理（価値）を届けられなければ意味がありません。
早く料理を提供しなければ客は怒ってかえってしまいますし、1人でも客が起こると強制閉店させられます。（シビアすぎる...）

逆に暇な時間があったとしても、客に料理を提供できているならそれでいいのです。
特に複数人で仕事をする際にはどうしても待ちが発生しがちですし、タスクがなくなるときもあります。
そういうときに別のタスクをすると他の人の導線の邪魔をすることになったり、タスクによっては失敗率が高くなったりします。（肉を焦がしたり、焼きすぎたり...）

プロダクト開発でもしばしば同様の現象が起こります。
チームでの開発なので当然営業さんとの調整による待ちやデザイナーからのデザイン待ちはあります。
そんな時に無理にリソースの空きを潰す必要はないのです。
大切なのは顧客にできるだけ早く価値を届けること。
そのためには自分の稼働率を上げることよりもむしろ他メンバーの状況把握に時間を使ったほうがいいことも往々にしてあるのです。

4keysは開発組織におけるパフォーマンスを示す代表的な指標です。

4keysは以下の4要素からなっています。

開発組織における4keysはPlateUp!の以下の4要素に対応すると考えることができます。

上述したフロー効率とリソース効率でも述べたように、リソース効率を高めて料理提供頻度や一皿の提供スピードを上げても作業失敗率が上がっては意味がありません。
また、作業に失敗した時にすぐに復旧できるレイアウトを組んでいないと致命的な遅延を招き、最悪店を潰すことに繋がります。

このようにPlateUp!をプレイしているとこのゲームの攻略法がそのまま開発生産性の文脈にアナロジーとして引用できることに気づきます。

プロダクト開発ではしばしば関心事を増やすことを悪と考え、WIP制限などの取り組みが取り入れられることもあります。
これはなぜかといえば、もちろんフロー効率の観点で価値を一つ一つ素早く提供すべきという考え方があるからですが、PlateUp!をプレイしているとこれ以外にも

などの弊害があることに気づけます。

一般的にチームメンバーが少なくてもタスクの種類はそれに比例して減ったりはしません。
ですので、チームメンバーが少ないと一人一人の関心事は基本的に増えます。
こういう状態だと各メンバーの稼働率がチーム全体のフロー効率に直結したりします。（スタートアップが激務になりやすいのはこういう側面もあると思います。）

一方でチームメンバーが増えてくると一人一人は専門のタスクに集中するようになり関心事がどんどんと減っていきます。
ですがその分どうしても視野が狭くなって他メンバーに不満を溜め込んだり、全体の目標認識が疎かになったりします。
チームメンバーが増えて自分の専門タスクに集中できるようになっても常に全体が見える余裕は持っていたいものです。

結局自動化こそフロー効率もリソース効率も向上させる最高の手段です。
自動化さえされれば少ない人数でも多くの価値を顧客に届けることができます。
ただ、自動化には専門知識がいるというのはどこの世界でも変わらないようで...

今回はPlateUp!というゲームをやっていて私が気づいたことをつらつらと書きました。
普段の業務でも開発生産性を意識はしていますが、PlateUp!をやっていると別視点で開発生産性を見直せて個人的には大きな学びがありました。

ところでこれだけ色々語っておきながら、実は私はPlateUp!をソロで15日目までクリアできたことがありません。
いつかクリアしたいな～と思いながらのんびりバイトする今日このごろです。