こんにちは、システムチームのKです。
私は業務のほとんどが自社サービス開発で、
まだサポートいただくこともありますが、基本は仕様も一から考えます。
ですが、まだまだ、「仕様が浅い」「仕様が漏れる」という失敗をしてしまうことがあるので、
「良い仕様とは何か」調べたこと、考えたことを共有しようと思います。
命名について
自動車業界は専門用語が多く、
データベース名、カラム名、変数名などの英語名を決めることが難しいです。
「車検」でも
inspection
car inspection
vehicle inspection
automobile inspection
など、業界共通の単語というものがなく、
チーム内でもちゃんと決めておかないと実装者によって表記ゆれが起きます。
「Name」や「Color」など、それ単体では
「何の」名前や色なのかわからないものについては、接頭語として「Car」をつけて
「車の」ということがわかるようにしたり、
逆に「Mileage（走行距離）」など、
当然に車のこととしてわかるようなものについては、Carをつけず、
必要最低限の文字数に抑えることも大事だと思います。
MECE
代表ブログや社内でも使われている単語なので聞いたことがあると思いますが、
MECEは「Mutually Exclusive, Collectively Exhaustive（モレなく、ダブりなく）」の略です。
このMECEの考え方が強く活かされる部分が、
「エラー処理の分岐」です。
私の場合、この分岐が少なく、5～10個くらいになることが多いです。
分岐の数は、機能の内容や規模によって変わるものなので重要ではありませんが、
重要なのは「モレがなく」定義されているかという点です。
エラー処理にモレがあると、
・Fatal Errorを吐いて、お客様のページが真っ白になる、エラーが表示される
・扱うことができないデータなのに、扱えるものとして処理した結果、別の場所でバグを引き起こす
など
システムを壊す要因となります。
機能の規模が大きいほど、モレが発生すること可能性が高いですが、
どうして漏れるかを考えたときに、
エラーが起こる条件がしっかりと整理されていないことが原因として挙げられます。
世の中のプログラマがどうやって網羅しているかを調べてみると、
項目やエラーコードを使って表形式で整理し、
漏れなく網羅する工夫をしており、勉強になりました。
「書いてある通りに作るだけ」まで落とし込む
MECEの内容につながることですが、
やはり「書いてある通りに作れば、ちゃんとしたシステムが出来上がる」ものになっていることが、
良い仕様の条件だと思いました。
良い仕様は、実装者本人がこの仕様さえあれば、
開発からリリースまでできるように作られている。
というのは当然として、
途中ミスしたり、詰まりそうな箇所への対応方法や、
一般的ではない用語について、解説や参考URLを記載するなどの
問題が起こったときの改善まで想定されています、
実際、仕様を見るのは、実装者だけでなく、それを承認する上司や、
チームで開発をするなら他のメンバーも見ます。
実装する人が皆同じ知識量ではないですし、
問題点は出てくるものです。
システムは未来の赤の他人の行動を制御するものと定義していますが、
それはシステムを使う人だけではなく、システムにかかわる人すべてが対象で、
仕様作成の段階から、始まっているものなのだと
改めて思いました。
私は、「仕様が浅い」ということに対して、
ブレインマップ（社内のマインドマップツール）の枝を深くまで掘り下げることで改善しようとしていました。
それ自体は必要なことですが、十分ではなく、
次は、それらを整理して、MECEな仕様にする。
また、その仕様を会社の基準に合わせ、ドキュメントとして残せるレベルまで仕上げる。
チームとして開発力を上げ、アウトプットを増やすためには、
ここまでできるよう、成長する必要があるとおもいました。
