仕様書を先に書き換えてから実装する ― SPEC-First という開発ルール

このプロジェクトには、開発の進め方についてのルールがいくつかあります。 その中でも一番基本になっているのが、SPEC-First と呼んでいるルールです。

内容は単純で、次の2つだけです。

• 機能を追加したり変更したりするときは、先に仕様書を更新してから実装する
• 仕様書に書かれていない挙動は実装しない。追加したくなったら、仕様書の更新から始める

個人開発で仕様書を書く理由

仕様書というと、チームで開発するときに、メンバー間で認識を揃えるための ものだと思われがちです。一人で作っているなら、頭の中にあれば十分ではないか。 そう考えるのは自然なことです。

しかし、個人開発でも仕様書は大きな力を発揮します。 一番の理由は、未来の自分は他人だということです。

数か月前に作った仕組みが、なぜその形になっているのか。 そのときは明確な理由があったはずなのに、時間が経つと思い出せません。 理由が分からないまま手を入れると、以前わざと避けていた問題を 再び引き起こしてしまうことがあります。 仕様書に「何を」だけでなく「なぜ」を書いておけば、 未来の自分がその判断を引き継げます。

先に書くことに意味がある

仕様書は、実装したあとに書くのではなく、実装する前に書きます。 これには2つの効果があります。

一つは、考えが整理されることです。 頭の中では完成しているつもりのアイデアも、文章に書き出そうとすると、 決まっていない部分が次々に見つかります。この値の単位は何か。 データが見つからなかったらどうするか。他の機能とどう関わるか。 コードを書き始めてから気づくより、書く前に気づいたほうが、 手戻りははるかに小さく済みます。

もう一つは、作りすぎを防ぐことです。 実装しながら「ついでにこれも」と機能を足していくと、 いつの間にか誰も把握していない挙動が増えていきます。 仕様書に書いていないことは作らない、と決めておけば、 思いつきで機能が増えることがありません。 本当に必要なら、仕様書を更新すればいいだけです。

仕様書の構成

仕様書は、1つの大きな文書にせず、階層に分けています。

一番上に、プロジェクト全体の方針を書いた文書を置きます。 ジャンル、使っている技術、設計の大原則、フォルダの構成、 そして個別の仕様書への索引です。細かい仕様はここには書きません。

その下に、機能ごとの仕様書を置きます。 戦闘、技のデータ、カメラ、ステージなど、機能単位で分かれています。 何かを変えたいときは、まず索引から該当する仕様書を探し、 そこを書き換えてから実装に入ります。

各仕様書には、その機能でやらないことも書くようにしています。 非ゴールと呼んでいる項目です。「この機能では壁との衝突回避はしない」 のように明記しておくと、あとで「なぜこれがないのか」と迷うことがなくなります。 やらないと決めたこと自体が、大事な設計判断だからです。

大原則は簡単に変えない

仕様書の中でも、プロジェクト全体に関わる大原則は、 「絶対ルール」として特別に扱っています。 データはすべて Mod として管理する、データの読み書きは専用の仕組みを通す、 といった根幹のルールです。

これらは、変更するときに特に慎重な確認を必要とするものとして位置づけています。 根幹のルールは、一度破るとあちこちに例外が生まれ、 設計全体が少しずつ崩れていくからです。

運用してみて

仕様書を先に書くのは、正直に言えば手間がかかります。 すぐにコードを書きたい気持ちを抑えて、まず文章を書く必要があります。

それでも、このルールを採用して良かったと考えています。 仕様書があることで、どこまで作ったのか、何が残っているのかが いつでも分かります。そして何より、しばらく離れていた機能に戻ってきたとき、 仕様書を読めばすぐに作業を再開できる。 その安心感は、書く手間を十分に上回るものです。