![見出し画像](https://assets.st-note.com/production/uploads/images/17644891/rectangle_large_type_2_973848e11f9e5cc2f3a48b468c90e4fc.jpeg?width=800)
「仕様」と「設計」、「仕様書」と「設計書」は違う
一般に混同しがちですが、仕様書や設計書と言う言葉には厳密な違いがあります。
もしまったく同じなら、わざわざ言葉として異なるものを利用する必要ありませんですからね。あえて異なる言葉で分けられていると言うことは、明確に異なる部分があると言うことです。
ですが、実際のエンジニアリングを見ているとどうにも「仕様」とは何で、「設計」とはなんなのか、わかっていないエンジニアやリーダー、マネージャーが多いように見受けられます。
たとえば、要件定義、基本設計や外部設計と呼ばれる
"顧客と合意を取って、実現するモノを確定するため"の工程
では仕様書を利用されることがありますが、詳細設計や内部設計と呼ばれる
"モノづくりのため"の工程
では仕様書は利用するものであって作成することはありません。そもそも仕様とは「何を実現してほしい!(するんだ!)」を定義した未来の理想をまとめたものであり、仕様書はその「何を実現するのか」を説明した資料でなくてはなりません。
製品などでいうとスペック表やパンフレットをイメージするといいでしょう。
![](https://assets.st-note.com/img/1654206680212-FrqxXz4GSt.png?width=800)
よって基本的に論点の中心は、依頼してきたお客さまのニーズを汲み取り「実現するものは何か」「実現すると具体的に業務はどう変わるのか」が中心になります。だからお客さまと相談しますし、お客さまと打ち合せて決定することが可能なのです。
建築で言えば概観を定義したり、モック(模型)を作成するところまでの作業と言えばいいでしょうか。
![画像1](https://assets.st-note.com/production/uploads/images/17645122/picture_pc_fe2876e1bf6de849018bd85ba7165989.jpg?width=800)
![画像2](https://assets.st-note.com/production/uploads/images/17645171/picture_pc_8fad9af909e0d3093808d716add60342.jpg?width=800)
むしろ、お客さまを交えない仕様と言うものがあったら、それは既に仕様としての役割を果たしていません。
逆に設計とは
具体的に"何を作るの?"・"どうやって作るの?"を考える工程
です。そして、設計書とは、
"どうやって作るの?"を説明した資料
になります。建築で言えば、大工に依頼するための製図がそれにあたります。
![画像3](https://assets.st-note.com/production/uploads/images/17645197/picture_pc_6d06ab4d51f3bd601ef040011fdc0cf1.jpg?width=800)
外部設計は、その「どうやって作るの?」に対して顧客にも確認を取ってもらえる部分を抜き出し、あらかじめ設計・定義し、決定(合意)しておく工程となりますがそれと同時に、内部設計(詳細設計)やプログラミングするにあたって「この定義に従ってね」「こうやって作ってね」と指示できる内容でなくてはなりません。
どちらも、モノづくりをするときに作成する(ことが多い)資料です。
しかし、一般的には仕様書には"結果(目標、ゴール)"を記述し、設計書には"過程(プロセス、仕組み)"を記述する点で相違があります。
仕様書は、それを見て完成品のイメージはできても具体的な作り方は分かりません。設計書は、それ単体では完成品のイメージをすることが難しくてもそれを見れば書かれたとおりに作ることができます。
また、仕様書のなかでも要求仕様書であれば、技術的なことを知らなくても最低限の知識を持っているだけで作ることが可能です。その気があればお客さまでも作ることが可能です(実現可能かどうかは、その後詰めていくものですしね)。しかし設計書は、技術的なことを知らないと作れません。
このように、仕様と設計、仕様書と設計書には大きな隔たりがあることを知っておきましょう。
特に請負開発の場合は、お客さまと一緒になって作り上げるのが仕様書という位置づけです。作る人たち(開発側)だけで「あーでもない、こーでもない」と言って作り上げるのが設計書です。
そして、プロジェクト活動は
・チーム作業であり、チームメンバーにいつ何が起こるかわからない
・プロジェクト単位でチームが作られ、納品後には解散され、
また同じメンバーが集まれる保証はない
と言ったリスクを考えれば、設計書は工程間あるいはチーム間、そしてプロジェクト間におけるコミュニケーションツールとして確実に残しておかなければならないものということも、多くのエンジニアの方々にとって理解できることでしょう。
もちろん、なんでもかんでも作ればいいと言うものではありませんが、同様になんでもかんでも1人で進められるわけではありませんので、
コミュニケーションが円滑に行われ、
関係者間で認識齟齬が絶対に起きないようにするためには
どうすることが最善なのか?
について、責任ある決断と行動であることが求められています。その条件が成立するための必要最低限でなければ、待っているのは不具合やトラブルの多発しかありません。
いただいたサポートは、全額本noteへの執筆…記載活動、およびそのための情報収集活動に使わせていただきます。