SEが設計書を作り、それをもとにプログラマー達は開発を行います。

設計書を作る人はお客さん側にいる場合が多いのですが、場合によっては要件がふわふわしたまま開発に入ることも多々あります（てかほとんど）。

今回は非IT系の方にもわかるように開発現場で何が起こっているか。車の開発に例えて説明してみたいと思います。

運転席が2つある車？

さて、今日から新しい車を作ります。設計書はすでに展開され、どうやら普通の乗用車を作ることになりそうです。

しかし1点気になる点が。なぜか前の席が2つとも運転席のようです。これはちょっとおかしい。

設計者への連絡は全てリーダーを通してリーダーから行う決まりになっているので、早速リーダーに確認してみます。

リーダー「そうなんだよ。おかしいんじゃないかって指摘してみたんだけど、どうやらこれで合っているようなんだよね…。まぁそういっている以上このまま作るしかないね。」

ということでこの設計書のまま作ることになりました。

さらなる疑問

車の開発が進んでいくにつれ、新たな疑問が浮かんできました。運転席が2つあるということは同時に運転しようとするとどうすればいいのでしょう？例えば右の運転席でハンドルを右に、左の運転席でハンドルを左に切ったら車はどちらに曲がるのでしょう？またまたリーダーに確認してみます。

リーダー「そうだな….。ちょっと設計者に確認してみるよ」

リーダー「確認が取れたよ。どうやらスイッチで右と左の運転席を切り替えるようだ。その部分を修正した新しい設計書が展開されたから見てみて」

ということで新たにスイッチをつけることになりました（俗にゆう仕様変更）

そしてテストへ…

ようやく設計書通りに車が完成しました。今回は設計者の方でテストを行います。テストとはきちんと設計書通りに作られているか確認することになります。

そこで衝撃の事が起こりました。なんと運転席はやはり1つでいいとのことでした。

リーダー「というわけで仕様変更ということにしてもらったので再度修正をすることになりました。それに伴って追加で取り付けた運転席切り替えスイッチもなくなり、『助手席』を新たに作ります。」

これは実話です

さて、こんなこと実際にありえないだろと思うかもしれませんが、実際には結構あります。車を開発するとなると実際に加工したりして「もの」を組み立てることになるため後から用意に変更はできないですが、プログラミングになるとコピペなどで案外すぐに変更できてしまいます。

だからと言って変更に対する時間がかからないかというとそんなことはないのですし、その分作業に対するお金もかかってしまいます。しっかり設計をしておくことはとても大切ですね。

実際にこのようなことが自分に降りかかっても負けないメンタルを持ちましょう。