「悪い方が良い」原則をご存じだろうか？
プログラミング言語「Common Lisp」の開発に携わったことでも知られるソフトウエア技術者リチャード・ガブリエル（Richard Gabriel）氏が1990年に発表した有名なエッセイ「The Rise of ``Worse is Better''」で主張したソフトウエア開発の考え方だ。
このエッセイでガブリエル氏は、美しく完全に設計・実装されるより、単純で雑に設計・実装されたソフトウエアの方が良いと説く。彼は前者を「正しいやり方」「MIT/スタンフォード式」、後者を「悪い方がよい原則」「ニュージャージー式」と呼び、ニュージャージー式がいかに優れているか様々な事例を挙げて説明する。
これは一見とても奇妙に聞こえる。
ソフトウエア開発では通常「美しい設計」や「美しいコード」が尊まれる。「車輪の再発明はするな」とか、「階層構造に分けて、要素をいつでも交換できるように、柔軟性と拡張性を実現せよ」とか、「再利用性の高いコードはよいコードである」「ソフトウエアは安全でなければならない」などという話をあちこちで聞く。教科書にも書いてあるし、多くのソフトウエアはこうした設計と実装で完成しているケースが多いはずだ。
だが、ガブリエル氏はこうしたMIT/スタンフォード式のやり方に異を唱える。「実装の単純さ」を最優先にし、実装が複雑になる変更をすべきではないと主張する。階層構造に分けなくてもいいし、拡張性がなく再利用がしづらい安全でないコードでよいと言う。単純さのためなら車輪の再発明もOKだ。
実は私もそんなニュージャージー式の信奉者だ。以前参加したあるスマホゲームの開発プロジェクトでその意を改めて強くした。今回はその話をしたい。
残り数カ月で開発に参加、デスマーチにはなってない？はずだった
その時はサービスインまで残り数カ月というタイミングで、そのゲームの開発現場に呼ばれた。まだ幾つかの機能が実装できていない、開発はデスマーチに陥っているわけではなく順調だが、とにかく手が足りないので手伝ってほしいという依頼だった。開発環境を聞くと私が慣れたサーバー環境だった。それならお役に立てそうだと考え、参加を決めた。
依頼を受けるとまずプロジェクトの状況を確認した。ゲームにはプレーアブル（実際に遊べるパートや機能）があり、ちょっと遊んでみると、ゲームの基本動作こそできていたものの、設定の練り込みとか物量の追加、周辺機能の実装はまだまだこれからだという印象を持った。ここが大事なのだが、そのゲームが面白いのか、続けて遊びたいか、顧客がお金を支払いたいと思うかという一番肝心なところがまだよく見えてないようだった。
読者の皆さんにはかなりヒドい状況に聞こえるかもしれないが、開発の末期段階で参加したらプレーアブルが何もなかったという状況も私は経験している。それに比べたらずっとマシに思えた。
依頼者はアイテムの合成やさまざまな面白くて課金にもつながる機能を、ゲームに追加する作業を手伝ってほしいと熱弁した。あれやこれや様々なアイデアがあり、とにかく機能追加を早くしたいんだ、と熱く語っていたのを覚えている。その時に「なるほど、内容が足りていないのか」と了解した。
スマホゲームのサーバーは要するにWebAPIの集合体である。私はこの手を作る時はおおむねPHPかNode.jsかRubyを使う。幸いなことに今回のゲームサーバーは私が慣れた環境を使っていた。手慣れた環境なら私は仕事の早さに少し自信がある。ソースコードを素早く読めるし、プロジェクトの途中から参加したり、コードを引き継いだりしてなんとか開発を乗り切った経験が何回もある。
そんなわけで開発に参加し、ソースコードを管理する「gitレポジトリー」へのアクセス権をもらってソースを読み始めるとすぐに気づいた。このゲームサーバーは「マイクロサービスアーキテクチャー」を採用していた。
