設計屋のオシゴト

こーいうお話って不思議な事にドコにもないんで書いとこーかと思った
まぁクッソ薄っぺらい概論なんだが無いよりマシだろ

製品

まずそもそも設計する対象って何？ってコトで「製品」について

Q:製品って何？
A:要望を満たす機能

人間様は快適に/高速に/安全に移動できるなら
別にその手段は車でも電車でも飛行機でもヘリコプターでも何でもいい
突き詰めると実は製品ってのは要望を満たす機能のコトを言う
今どき製品とサービスの差なんて物理的なモノが付随するかどーかでしかねぇ

製品ライフサイクル

ついでなんだけど世の中には製品ライフサイクルなんつー概念がある
なんのこっちゃない、製品やサービスはいつか死ぬって話

導入期：製品の新規設計
成長期：機能追加や派生
成熟期：コストダウン
衰退期：収束・後継・延命

ゲームだってTPO次第で立ち回りを変えるんだし
設計だってTPO次第で立ち回りを変えなきゃ駄目

設計

ぶっちゃけ一言で言えば「設計＝狙い」だったりする
なおコレ実はISO-9001そのまんまで技術っつーか実はオシゴト全般の真実

設計の区分

ところで設計、設計って言いつつ設計ってのには実は二種類ある

製品設計：製品・サービスを実現するための設計
量産設計：製品・サービスを製造・運用するための設計

こんなサイトだし特に若いヤツは量産設計なんて単語初耳だろーけど
製造・運用できねぇ製品/サービスなんぞゴミだし
設計・保守してなきゃそもそも量産も運用もできねぇ
現実的にはこの他にも実現手法そのものの研究開発なんて区分もあんだろーけど
大多数の技術者にとってアレは「研究者のご所望する実験設備開発」でしかねぇ

製品設計

つーわけでやっとフツーの意味での「設計」の話

要件定義：客が設計屋の仕事にカネ払う条件に合意するコト
基本設計：合意した要件をどう実現するか決めるコト
試験設計：要件の実現をどう確認するか決めるコト
詳細設計：カネもらうための設計作業

なんともまぁ御大層な言葉が並んでやがるけど
技術屋の世界では多種分野の人間が共同作業するんで明確に言語化しないと困るってだけで
この程度のコトは実は大抵の職種で意識せずにフツーにやってるコトだったりする
ぶっちゃけ「ちゃんと聞いて、考えて、やれ」ってだけ

要件定義

要件定義：客が仕事にカネ払う条件

コレ冗談じゃなくて実は法的根拠にさえなり得るくらいに重要
んで、コイツを理解するにはとりあえず要件と要望は別物だと区別しなきゃ駄目
要望は出来るかどうかなんざ分からん欲求なんで
客と技術者は出来るという合意をしなくちゃいけない

よく言われるのは「お客様の身になって考えろ」で
つまりその製品・サービスをエンドユーザー目線で考えろってコトになる
何故かこの「お客様の身になって」と聞いて設計依頼者そのものに媚びるアホが多いけど
顧客は神じゃなくて人間だから彼らなりに迷いながら要件を決めている
彼らが本当に考えなければならないエンドユーザーの事を一緒に考えてやるのが本来は正しい
ユースケース分析とかそーいう話はこの辺が分かんないとそもそも話になんねぇ

基本設計

基本設計：合意した要件をどう実現するか決めるコト

基本設計は受け取った要件を製品・サービス全体としてどう実現するかを決めるヤツ
つまりまずそれを説明するための構造と振る舞いが含まれている必要がある
まぁそれがどの程度かってのが難しいんだが要はコレを関係者に共有させられれば大体勝ち

• 全体に「何」を用意してそのどれでどの要件を実現するか
• それぞれのインタフェイスはどうするのか

結局当然だけど基本設計は要件定義と(頭の中で)並行してないとお話しになんない
要件に合意しようにも何をどう実現するつもりかも分かんないんじゃ合意なんて無理

試験設計

試験設計：要件の実現をどう確認するか決めるコト

フツーは全てを詳細設計の後にしがちなんだけど
基本設計の段階で可能な範囲は基本設計の段階で決めたほうが良い
自分用の簡易レビューみたくなって勝手に要件・基本設計の精度が上がる

ただこうすると要件定義・基本設計・試験設計はほぼ同時並行することになる
ので(同時並行だからこそ)明確に意識して別物として扱わないと混乱する
別人に書かせて突き合わせるのもアリだが...まぁ現実は大体一人

詳細設計

詳細設計：カネもらうための設計作業

実はドコからが基本設計でドコからが詳細設計って区切りはない
敢えていうなら基本設計は複数人数・複数分野の連中が意思疎通するためのもので
詳細設計は数年後の自分か或いは他人にその仕事を引き継がせるためのもの

レビュー

ただただ設計すれば上手く行くなら世の中こんなに楽なものはない
自分の視点できっちり説明できるてそれが合理的だなんてのは当たり前の話で
他人の視点でブラッシュアップするのがレビュー
だから本来レビューに「答え」なんて求めるべきではないけど
大抵のレビューは資料の不備だとか不合理を見つける話になる

というわけで要件定義・基本設計・試験設計・詳細設計は
それぞれのタイミングでレビューをするのが当たり前

プロジェクトマネジメント

ところで実は現実には要件なんざ決まらんことが多い
こういうのは"プロジェクト上の"リスクとして扱われる
んでそのリスクをどーにかすんのがプロジェクトマネジメント

よく言うスケジュール管理はリスクの顕在化を監視する話で
コミュニケーション管理はリスクを潰す話だったりするんだが
細かい手法なんぞこの辺体験してからじゃないと覚えても無駄

量産設計

製品設計ってのは理想の製品を定義するお話だったわけだけど
量産設計ってのは現実に作る製品を定義するお話

そもそも現実とのすり合わせなんでやることはたくさんあんのに
具体的にコレという決まったものがあんましないwww

製品であれば調達/製造/試験/出荷あたりのフローを考えて行く話だし
サービスだと...マジで対象によって何でもありだな...
インフラとか・運用人員なんかも大枠で量産設計の類か？
というわけで各自自分の分野で後工程何してんだろを意識して
何時かやってくる成熟期の何かよく分からんコストダウンに備えるのです...(ぉぃ

品質

設計しました終わりましたとかいうのはアホのすること
品質って聞くと物の善し悪しだけの話に思えるけど
実は設計にも品質がある

割と最初に「設計＝狙い」と言ったのだけれども
その狙いが違わない度合いこそが「設計品質」
設計に従って製品製造・サービス運用するのが「製造品質」
一般的な感覚で言う使う側から見た良し悪しは「使用品質」

ドレが重要かって話じゃなく全部重要なんだけど
設計がコケたら全部コケるのは確定
そういう意味で技術屋の責任はスゲー重い

少なくともテメェの設計ミスで人間が死ぬ可能性はよーく考える必要がある
特に生命と財産は言われるがままに作った下っ端だから分かりませんでしたじゃ済まない