システムを構築するときは設計を行い、そしてその通り実装する。最後にテストをして合格したらリリースし、本番運用が始まる。
そう言えば一行で終わるのだけど、そんな簡単な話ではない。
設計段階でとてもイケていない絵を書いてしまうことがある。何が悪いのかは、悪いことが起こってから初めて気がつくものだ。絵は悪さを表現しないし、そして作った本人は悪気があるわけでもなく、そして関係者は専門家が作ったんだから大丈夫だろう。そうやって謎の安心感が覆い次工程に突き進んでいく。
イケてない設計が実装者に引き渡されて、おいおいこれ大丈夫かよ、と思ってもそこは実装者。たいていは技術的には実装できるのである。何とか動くようにするのが実装者の実力でもある。設計を無視したら責任問題になる。もう個人の感想はいいや、とイケてない設計をそのとおりに実装してしまう人もいれば、何か見えない機構を入れておいて事故が起こらないように工夫する人もいる。
設計者はもともと実装を詳しい人が担当するケースが多く、実装者に設計の穴を指摘されるようでは本来は厳しい。しかし実際に実装してみると、設計通りに行かないことや工夫が必要になることはよくある。特にバージョンアップなどが絡むと昔は通用したことが通用しなくなったりする。こう言ったことは実装時に明らかになる場面が多い。
だから、正直言って、設計をがっつりレビューしたらそれでFIXし、実装時に修正を認めないようなウォーターフォールモデルは、結構危険もあると思っている。むしろ実装時にわかったことは設計書に再反映し、実装を進めながら設計をブラッシュアップできるような柔軟さがないと、本当の意味での完成された設計はできないんじゃないかと思う。
これは、ITの世界だからこそ成り立つのであり、建築などでは無理だろう。柱を立ててしまってから設計を変えることはありえないからだ。
この性質を逆手に取り、設計書もなくいきなり構築し始め、その結果を設計書にまとめるようなやり方をする技術者。これがまたかなり多い。もっと過激に、設計書を作らない会社もあり、過去何社もあったことがあるが、これは多分にダメだ。設計書もないのにいきなり構築し始めるんですか！？なんて顧客にいつかなじられる。
というぐらい、設計と実装はかなり曖昧な関係にあり、どちらも省略できないが、一方向に流れているわけでもない。で、最後は設計書と、実装したもの両方が完成された形で仕上がらなければいけない。
あまりにも実装段階で未知のことがわかり、設計書がころころ変わっていくプロジェクトに何度も参加すると、設計書なんて始めから書いても意味なくね？と思うかもしれないが、それは違う。そんなに変わる設計は、そもそも検証が足りない。予定外が起こらないようにしてから設計を始めるに限る。どちらにしても設計はある。設計書がないなら実装者の心の中にあるだけだ。それをまず文書にすることは、無駄ではないし、後々どうせ作らなきゃいけないのならさっさと作ってしまえ、だ。
こんな業界なので、どんなにプロセスを見直したところで、なかなか穴はなくならない。そういうものだと思って対応していくしかない。ハードウェアもソフトウェアもクラウドも、ふわふわしているからね。
