Joel on Software 「やさしい機能仕様」
Joel on Softwareというプログラマー界隈で有名なブログを、このタイミングで読んだ。
スピード感を求めるあまり、焦りでから回りして、
データベースの設計やアプリの設計を雑にやってしまい、
結果開発速度が落ちる、ということを経験し、身にしみて仕様書の重要性を感じるブログだった。
Joel on Software
https://www.joelonsoftware.com/
Joel on Softwareの「やさしい機能仕様」日本語訳サイトhttp://japanese.joelonsoftware.com/Articles/PainlessFunctionalSpecifi-2.html
以下まとめ
==============================
仕様書とはそもそも何か……
プログラムをデザインするために必要である。仕様書を書かないことは、最大かつ不必要なリスクであり、その理由は大きく分けて以下の3点である。
Why 1 コードを先に書くことで結果的に工数がかかる
プログラムを書く際には、反復した同じようなコードを書く場合があり、この反復に工数がかかる。またプログラムを書くということは、これを冷静に見たときに悪いコードだとしても、そのコードに執着するようになる。これが1つ目の理由である。
Why2 コミュニケーションに不必要に時間がかかる
プロダクトを開発する上でコミュニケーションは不可欠。仕様書を書かないことによって、例えば、他のメンバーに仕様を毎度毎度尋ねることにより、その一瞬は短くとも、積み重ねれば、他の人の時間を奪い、邪魔することに繋がる。結果として、開発のスピードをどんどん下げてしまう。
Why3 仕様書無くして開発スケジュールを立てることができない
プロダクトには「お金」が関わる場合がほとんどある。期限がなく、完成したらリリースするという方針だとお金が際限なくかかる可能性がある。責任あるビジネスでは、どれほどの時間、お金がかかるかを理解し投資する必要があるからである。
以上の3つの理由から
つまり仕様書を書くという行為は、仕様がなかった場合に見えなくなるような大小の苛だたしい広義のデザイン(コミュニケーションなども含む)を明確にできる手段として捉えるべきである。
機能仕様書の書き方
この記事では、機能仕様の書き方について、扱い、技術仕様については取り扱わない。
機能仕様
ユーザー視点でどのように動くかを記述する。画面やメニュー、ダイアログも含む。
技術仕様
プログラムの内部実装についてのもの。データ構造やRDBの設計、使用するプログラミング言語などを記述する。
機能仕様書の要件
- 一人の責任者が記述する
- 具体的なシナリオ
- 対象外の記述(実装しないもの)
- 概要
- 詳細(もっとも重要なパート)
- 未解決な問題
- 注釈
- 仕様書が流動的であること
仕様書を書く上でのコツ
そもそも仕様書における、よく発生する問題は
「誰も仕様書を読まない」
ことである。
この問題を解決するために以下の5つの簡単なコツがある。
- ユーモアを忘れずに取り入れる。
文字ばかりだと誰も読まないように、楽しく読めるようユーモアを取り入れて書くこと。
- 読み手を想像しながら、理解してもらいたいことを伝える。
仕様書とは、脳内で実行するコードのようなものであり、読み手を想像し、読み手がどうやったら自分が伝えたいことを理解してくれるかを考えながら、仕様書を書く。
- 限りなくシンプルに
形式張ったフォーマルな書き方を使わず、できるだけシンプルな使い回しになるよう努力する。
コツとしては、短い文に分割すること、イメージなどを用いて、文字だらけの仕様書にしないこと
- 何度も読み返し、シンプルでない箇所があれば即座に書き直す
書き上げたら終わりではなく、なんども読み返すこと。シンプルであればあるほど良い。
- テンプレートを持たない
プロジェクトは生き物で、同じ形式である仕様書などありえない。その時々に応じた仕様書を書くべし。==============================
「急がば回れ」というが、冷静に現在地を直視し、
最速で成果を行きつくことを考えるべきで、
何も考えずにとりあえず初めて見るというのは、大局を見据えたときには悪手だと思うと同時に、
やはり色々な試行錯誤は重要で、「コードを書く」という手段以外にも思考を広げて、施策をやっていきたいと改めて感じた。