これまで関わってきたプロジェクトの中で、テトリスのモバイル版をチームの一員として一番誇らしく思っています。同じ地域のプレイヤーが決まった時間にログインし、同じピースを使って競い合う、といったマルチプレイヤーゲームモードもあり、テトリス99と似たようなゲームモードもありました。モノマネではありませんでした。テトリス99がリリースされる以前にも、N3TWORKがテトリスのリアルタイムマルチプレイヤー機能のプロトタイプ開発に成功しました。

要件の難易度が高かっただけではなく、南と北アメリカを渡った国際的なチームで、数ヶ月でゲームを大幅に再開発し、全世界のリリースもできました。

どうやって成し遂げられたんでしょうか。何でもかんでもうまくいってたわけではありませんが、チームとしての効率や生産性の要因はいくつかありました。

低い技術的負債

テトリスを開発することになるまで、N3TWORKがパズドラと似たような、Legendaryというモバイルゲームをリリースしました。ソフトウェアとしても、ビジネスとしても、非常にうまく回っていたゲームです。経験豊富なエンジニアリングリーダーたちが考えてくれたソフトウェアアーキテクチャが、機能の開発過程を統一化させながら、可能性を狭めるほど制限的でありませんでした。テトリスはそんなアーキテクチャーを受け継ぎました。

統一化はなぜ良いことかというと、アーキテクチャがすでに解決してくれた問題に、開発者の時間を費やすことがなくなるからです。例えば：

機能をどうやって設定するのか。
サーバーが状態をどこに保存するのか。
サーバーとクライアントの状態一貫性をどうやって守るのか。
クライアントがどうやって新しい状態を取得するのか。
クライアントがどうやって新しいアセットをダウンロードするのか。
状態をどうやって端末の画面で表示するのか。

誰でも答えらる問題かもしれませんが、綺麗に解決できる人は少ないと身をもって言えます。N3TWORKは、運が良いことにそんな人がいました。おかげで、開発たちはそれぞれの問題を自分で下手に解決することに膨大な時間を使わないで済みました。

素晴らしいチーム

テトリスの開発者たちは主にチリにいました。僕はサンフランシスコに住んでいた数人のエンジニアの一人でした。チリの文化なのか、チームがすごくうまく回っていたのです。信頼性と尊重性と協力性は全て会社のカルチャーが抱いていた価値観でしたが、会社がそんなものを押し付けなくても、テトリスではすでに存在していたものだと感じていました。

一人一人のメンバーは実力が高く信頼できたので、リモート環境では難しい管理や同期的ななコミュニケーションの必要性は最小限にできました。

コードレビューがほとんどなかった

コードを全くレビューしないことは、アンチパターンに思われるかもしれませんが、僕たちの場合はコードレビューをなくすことでチーム全体のスピードが大幅に上がりました：

いうまでもありませんが、貢献するには誰かのレビューを待つ必要はありませんでした。少人数で技術的な負債が少ないチームでは、レビューをなくすことで取り戻せた時間が、かえってバグによって費やされることはあまりありません。
責任感が増えます。他人が貢献を見てくれないので、自分自身が責任を持って貢献するしかありません。
変更の妨げがなくなります。バグを書いたら、すぐ直せます。改善したいものがあれば、勝手にどうぞ。

もちろん、メリットもればデメリットもあります：

自分が書かなかったコードへの意識が薄くなります。
他人から学ぶ機会が減ります。
バスファクターが高くなります。

とはいえ、コードレビューをなくすことでプロダクトの開発速度が高くなり、スタートアップとしてはもってこいでした。会社によっては目的が変わり、コードレビューの必要性も変わります。

自信を持って貢献できる開発者たち

以上の内容のテームとしてあるのは、開発者一人一人に自信を持って自由に行動させるための要因が揃っていたことです。

バグへの忍耐性が高く、開発を統一化させたアーキテクチャーがあり、管理の必要性を最小限にできました。管理がなければ、貢献への妨げもなくなり、開発者の生産性も上がります。生産性が高ければ、チームへの影響が感じやすくなり、やっていることに意味を感じるようにもなります。僕から見て、テトリスはそんな素晴らしいチームでした。

会社がもうなくなりましたが、そんなチームを可能にしたN3TWORKには感謝しています。