イントロ
この記事は「エンジニア」もしくは「技術職」にあたる部署に配属され、ガンガンコード書くのかな…
なんて思っていたら三年間ほぼ企画から受けた要件をまとめ続ける仕様書担当だった、メーカー内のPMでもSEでもない平社員が思ったことを殴り書きします。
・上からいろんな仕様変更が舞い降りてくるエンジニアさん
・エンジニアに手戻りをなくさせたいと思っているもののよくわからない企画担当さん
・作業担当者から仕様立案や指示役となりそうな方
いろんな本や知識の焼きまわしになるかもですが、私が立ち返りたくなった時のためが主なので、
上記の方に微々たる参考になれば、と思います。
※私自身エンジニアとしてもPM系としても経験は未熟ですが、せっかく書くなら偉そうに書こうと思います。
ころころ仕様が変わる対策
仕様を考えてくれる営業や企画の人は、突然違うことを言い出すことがあります。
私も仕様を検討していると、前に話したけど、よく考えたら･･･と気づいてしまうことが多々あります。
そんなときに、「この仕様はなんでこうしたんだっけ」というのが分からないと、たぶんたいした理由じゃないから変えよう、みたいに変えてしまうことがあります。
対策1：仕様が決まった理由を仕様書に書く
仕様が決定するには、なにかしら経緯があるものです。
そして、その経緯は大体忘れられ、後の仕様検討の際には思い出されません。
たとえば、
「技術的に難度が高く、工数に収まらないという報告があった」ための妥協仕様
後の会議で改めて理想に近づけた仕様は、結果的に納期を遅らせるか、中途半端な代替機能になってしまう。
「このインジケータの点滅は、他の～～と言う機能と共通性を持たせるため」
点滅速度を一部変え、あとから「共通になっていないじゃないか」ということになり手戻りが発生する。
全ての理由を書いてしまうと、議事録さながらの読みづらい仕様書になってしまいますが、表などを使って
| 要求仕様 | ボタンを押下したら再起動を要求する |
| 理由 | 再起動しないと設定が反映されないため、ユーザーが変えたつもりで気づかないことがありえる |
とか書いておくと、あとから仕様書を読む人も、「ああ、こういう経緯か」と分かります。
USDMというフレームワークが、私にはかなりしっくり着ており、それをアレンジして使っています。
http://swquality.jp/temp/nagasakiqdg15_usdm.pdf
仕様書を書く人が常に一人であれば、どこがどこに影響するかはなんとなくわかるものですが、
誰かに引き継いだり、担当の人がマルチプロジェクトだった場合、大抵の理由はすぐに忘却され、一番初めに決めたルールでさえ有耶無耶になってしまいます。
対策2:デザインは早急に作り上げる
UI（さらにここではGUI画面）が伴う場合、何を差し置いても、ユーザー・営業・企画 の人がパッとみて指摘をくれるグラフィカルな資料を真っ先に作りましょう。
仕様が決まっていないのにGUIなど作れない･･･という場面も多々あるのですが、いっそ自分がデザイナーのつもりで、Figmaとかでサクッと作って見せてあげると、速攻で「イメージとぜんぜん違う･･･！」というレスポンスが貰いやすいです。
（もちろん、ワイヤーでもぜんぜん良いですが、人は、遷移図を頭で考えるより、実際に触った方が気づきます。）
サーバー側をしっかり考えて、エンジニアサイドが納得のいく仕様でも、GUIの前では無力「ここにもう一個パラメータいるわ」と気づかれると
エンジニアサイドは最悪の場合構造体から設計しなおしです。
早めに、エンドユーザーに触れる部分を確定させましょう。
P.S.
執筆をはじめ、2018/7/22の下書きが、2019/8/2まで放置されており （つまりいまは新卒4年半）、対策が5まであったのですが、見返すとなんかイマイチでした
でも一応世に出そうということで、今見ても、「まぁそうだな」と思えるところだけを残して、公開することにしました
この記事に触れる方がすごく多いとは思いませんが、また折を見て更新しようと思います。