今日は中々ノッてるので、３本目のエントリ突入。
テーマはシステム開発における仕様と設計の違いについて。私が業務系エンジニアから基盤系エンジニアに泣く泣くシフトチェンジした一つの大きな理由も、この仕様と設計の違いに関連しています。
仕様と設計の違い。それは端的に言えば「どうなるか」を定めたものが仕様、「どうするか」を定めたものが設計です。単純にログイン機能を例にとって説明しましょう。下記が仕様です。
ログイン画面にてユーザ名とパスワードを入力して、ログオンボタンを押下した場合、
- ユーザ名とパスワードの組み合わせが正しければトップページ画面へ遷移
- ユーザ名とパスワードの組み合わせが誤っていればエラー画面へ遷移
仕様から読み取れるのはあるべき動作であり、特定の条件下における処理の結果です。そして、これらはSEがお客さんと一緒に考え、合意した上で決めるものです。では、この仕様からプログラムを作ることはできるでしょうか。
もちろん、できる人もいるでしょう。しかし、これだけの情報からプログラムを作れる人は設計ができる人です。仕様をプログラムへ落とし込むためには、データ（およびその格納先）とロジック（条件分岐や順序）、そしてそれらの連携方法を考える必要があります。
上記のログオン画面を設計するには下記のようなことを考える必要があります。
- ユーザ名とアカウント名を保存するためのデータベース・マスタ情報の定義
- 各データの型（数字なのか英文字なのか真偽値なのか）
- ログオン画面レイアウトの設計
- ユーザ名・アカウント名を入力するための入力フォームの配置
- ログオンボタンの配置
- 入力フォームで受け取った情報からデータベースの値を取得するSQL文
- SQL文で取得した情報と入力情報をチェックする処理
- チェック結果に応じて遷移先の画面を切り替えるロジック
- トップページおよびエラー画面のレイアウト
などなど。今は順序性も考えず箇条書きで、かつパッと思いついたものしか書いていませんが、それでも仕様と設計では考えるべき項目の数が全然違うことがお分かりいただけるでしょう。さらに仕様を満たす最適な設計を考えるのはさらにハードルが上がります。それが面白いところでもあるんですけど。
私は業務系のエンジニアはこういうことを考える仕事だと思っていたんですよ。いや、実際こういうことをやっているエンジニアの方もたくさんいらっしゃると思うんです。でもITゼネコンの上の方に位置する会社がやるのは大抵仕様を決めるところまでなんですよね。
要するに設計してないんです。お客さんと調整して、仕様という名のゴールを決めるのがメイン。そのくせ、「あれはおれが設計した」みたいなこと言ってる人もいます。いやいや、あんたは仕様決めただけでしょ〜って。
ただそうならざるを得ない理由もあって。一つはお客さんと調整するのは結構ハードな仕事だということです。仕様を合意するためにはその仕様が最も良いという合理的な理由が必要です。そのために、あらゆる調査をして、あらゆる資料を作って説明をしに行かなければならない。規模にもよりますが、多くても数ヶ月ぐらいの期間内に収める必要があります。
もう一つの理由は、既に既存システムが運用されている場合です。要するに機能追加開発のことですが、0からのシステム開発でない場合、既存の機能の流用で済ませられる場合が多いです。
0からシステムを作るのは結構リスクがあります。一般的には、過去の類似プロジェクトの機能や処理を参考にプログラム規模や工数は見積もられますが、新規システムの場合は作ったことがないので、工数見積の精度がどうしても落ちてしまいます。なので、精度誤差分を踏まえてバッファを積むことになります。
加えて、前例のないことをやると、必ず想定外の問題にぶち当たりますから、問題が起こった場合のことを考えて、バッファを積むことになります。さらに問題の影響度も見切りにくいため、機能追加開発に比べてその割合は多くなるでしょう。
すると、どうなるかというと、お客さんへ提示する価格がめちゃくちゃ高額になってしまうわけです。すると、案件が受注できない。営業から怒られる。じゃあどうやって安くするかというと、最も代表的な手法として、既存システムをうまく流用することを考えるのです。
既存のものを活用した方が効率的に良いものを生み出せるので、これは会社としては全く悪いことではありません。ただ問題なのは、こういったやり方では、SEが本当の設計をする機会はない、ということです。
例えば、家を新築で建てるのも同じですよね。似たような家が既にあれば、その設計図を流用した方が早く作れる。でもそれはつまり、家全体の設計というフェーズをすっ飛ばしているということです。
うちの会社では近年開発力の低下が叫ばれていますが、ほとんどの社員が設計という設計をしていないのだから無理もありません。さっき言ったように、仕様を決めることを設計だと勘違いしている人さえいる次第です。
実際、今振り返ってみても、自分がやってきたことのほとんどはただの決め事でしかなく、既に出来上がった既存システムの枠組みに新しいデータを追加しただけ、という感じが拭い去れません。いと悲しや。
もちろん、SEとして働いていれば、今動いているシステムの設計を勉強することはできます。でも設計図の内容を把握したいからではなく、設計をしたいからSEになっているはずですよね。設計を理解していくことと、実際に設計することに圧倒的な違いがあることはアプリ開発を通じて実感しました。なので、次やるなら是非とも新規開発がいいですね。
正直、今の担当で業務系エンジニアをやっていても何の専門性も身につかないだろうなと思いました。（先輩や同期に聞いても、業務知識は身についたけど、設計スキルは身についていないと感じている人がほとんど。）確かに業務知識はつきましたが、金融みたいに大きな業界ならともかく、ニッチな業界相手だと汎用性が低すぎてエンジニアとしての価値はあんまり発揮できないでしょう。
私は、それが嫌で嫌で仕方なく、基盤系エンジニアになったというわけです。もうしばらくしたら、基盤系エンジニアが何たるかも書き連ねたいと思います。
