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