Joel on Software 「やさしい機能仕様」

4 min readJan 14, 2018

Joel on Softwareというプログラマー界隈で有名なブログを、このタイミングで読んだ。

スピード感を求めるあまり、焦りでから回りして、
データベースの設計やアプリの設計を雑にやってしまい、
結果開発速度が落ちる、ということを経験し、身にしみて仕様書の重要性を感じるブログだった。

以下まとめ
==============================
仕様書とはそもそも何か……

プログラムをデザインするために必要である。仕様書を書かないことは、最大かつ不必要なリスクであり、その理由は大きく分けて以下の3点である。

Why 1 コードを先に書くことで結果的に工数がかかる

プログラムを書く際には、反復した同じようなコードを書く場合があり、この反復に工数がかかる。またプログラムを書くということは、これを冷静に見たときに悪いコードだとしても、そのコードに執着するようになる。これが１つ目の理由である。

プロダクトを開発する上でコミュニケーションは不可欠。仕様書を書かないことによって、例えば、他のメンバーに仕様を毎度毎度尋ねることにより、その一瞬は短くとも、積み重ねれば、他の人の時間を奪い、邪魔することに繋がる。結果として、開発のスピードをどんどん下げてしまう。

プロダクトには「お金」が関わる場合がほとんどある。期限がなく、完成したらリリースするという方針だとお金が際限なくかかる可能性がある。責任あるビジネスでは、どれほどの時間、お金がかかるかを理解し投資する必要があるからである。

以上の３つの理由から
つまり仕様書を書くという行為は、仕様がなかった場合に見えなくなるような大小の苛だたしい広義のデザイン(コミュニケーションなども含む)を明確にできる手段として捉えるべきである。

この記事では、機能仕様の書き方について、扱い、技術仕様については取り扱わない。

機能仕様
ユーザー視点でどのように動くかを記述する。画面やメニュー、ダイアログも含む。

技術仕様
プログラムの内部実装についてのもの。データ構造やRDBの設計、使用するプログラミング言語などを記述する。

そもそも仕様書における、よく発生する問題は

「誰も仕様書を読まない」

ことである。

この問題を解決するために以下の5つの簡単なコツがある。

文字ばかりだと誰も読まないように、楽しく読めるようユーモアを取り入れて書くこと。

仕様書とは、脳内で実行するコードのようなものであり、読み手を想像し、読み手がどうやったら自分が伝えたいことを理解してくれるかを考えながら、仕様書を書く。

形式張ったフォーマルな書き方を使わず、できるだけシンプルな使い回しになるよう努力する。

コツとしては、短い文に分割すること、イメージなどを用いて、文字だらけの仕様書にしないこと

書き上げたら終わりではなく、なんども読み返すこと。シンプルであればあるほど良い。

プロジェクトは生き物で、同じ形式である仕様書などありえない。その時々に応じた仕様書を書くべし。==============================

「急がば回れ」というが、冷静に現在地を直視し、
最速で成果を行きつくことを考えるべきで、
何も考えずにとりあえず初めて見るというのは、大局を見据えたときには悪手だと思うと同時に、
やはり色々な試行錯誤は重要で、「コードを書く」という手段以外にも思考を広げて、施策をやっていきたいと改めて感じた。