実際のところ、設計ができる（だろう）と思っている人は多いと思う。ただし、現場の業務ではそうは行かないよ、という話。
何かものを作ってごらんなさいと言われたときに、クラウドサービスのコンソールを開き、手を動かしていったら何かできるようになっている時代が現代だ。オンプレ全盛時代はサーバー機器を注文する必要があったので、事前に構成を決めるために設計をしっかりする必要があったが、今では多少間違っていたら解約し再オーダーすればいいので、設計に対する重みは減ったと思う。トライアンドエラーを繰り返しながら構築していくスタイル。最後に出来上がったものを設計書としてまとめるほうが手戻りがなくて良い。
だが、そういう「ゆるい」設計が通用しない案件に巡り合った。かっちりとした設計書を見せないと構築の仕事に進めないようだ。これは困ったというか面白いというか。実物が出来上がる前に設計をしっかりするなんて結構久しぶりなのだが、難度が高い。
なんでこんなに、作る前に設計書作るのが難しんだろうと考えてみる。頭の中で構築をシミュレートしないといけないが、結構な経験がないとリアリティーが出ない。リアリティーのない設計なんて最悪だ。実装し始めた途端に設計が矛盾していることを指摘され、設計書がどんどん変わる。そうなると、手戻りというよりは関係者の事前合意が意味をなさなくなってしまい。プロジェクトがなかなか進まないことになる。その際に設計能力が足りないことをグチグチと言われるのも決定である。
今はクラウドがデファクトスタンダードで、どんどん修正しながらいいものを作っていけばいいじゃない、というアジャイル的な発想が通じない顧客もいるにはいるのである。
この純粋な、作る前に正確な設計思想が必要になる設計業務。まずは日本語の能力が非常に大事になる。何せ、顧客はたいてい専門家ではないのに、内容が難読では了承されない。できるだけわかりやすく、かつ要件を満たし、そして実装段階の際に矛盾があってはいけない。それって「実際にやったことのない人か、ちゃんと事前に検証した実績を持つ人じゃないと無理じゃないか」ということである。
この時点で、設計する対象全てに対して、想定外の部分が少しでもあったら「でまかせ」ということになる。できますできますー。はい実装してね（知らんけど）、という設計を書かざるを得ない状況は、どう考えても次に起こる破綻への第一歩なのだ。
ここ最近、プロジェクトマネージャーが、どちらかというとアジャイルの感覚でスケジュールを短めに引くのに、やり方はガチガチのウォータフォールじゃない？というやり方を目の前にしている。インフラがすぐに調達可能で実装も速いというのと、「実装する前にちゃんと設計書が書ける」というのは全然関係がないことに気がついていない。クラウドから設計書っぽいものが出力できるようなサービスが一部あるけど、それすら実装後なんだから、「くれ！オンデマンド！設計書！よこせ！」みたいなノリは本当にこの世の矛盾が濃縮したものとして捉えている。
でもね、やるしかないじゃない。仕事だもの。にょろっと素晴らしい設計書を書き上げてみよう。書き上げたら書き上げたで、次回も仕事は来るだろう。だって、経験や検証を豊富にやってきたことが証明されるのだもの。この境地に来るまで、金になるかわからない検証や、雑多な経験に揉まれてきたのだから、ついに活かせるチャンスが来たということにもなる。
設計業務が難しいのは、設計そのものが難しいからじゃない。作る前に根拠を示すことは、事前の経験や検証結果を保持している必要があるからだ。本来の設計業務の難しさはここにある。
難しい設計内容なんかわかんないから、とりあえず作ってちょ、みたいな顧客も最近は多いのでそちらを専門にするという方法もあるが、ま、そうじゃない世界というのもあるよ、という話である。そういうお固い方法論、結構仕事があるので、難しいけれど、バリューも結構あるから覚えておくとよいかもしれない。
