設計屋のオシゴト

こーいうお話って不思議な事にドコにもないんで書いとこーかと思った
まぁぶっちゃければ無いよりマシの理想論なんだが
若いのはとりあえず"北向き"がどっちかくらいに覚えておくと良い

製品

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

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

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

製品ライフサイクル

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

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

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

設計

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

設計の区分

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

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

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

製品設計

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

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

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

要件定義

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

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

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

基本設計

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

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

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

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

試験設計

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

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

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

詳細設計

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

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

レビュー

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

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

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

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

よく言うスケジュール管理はリスクの顕在化を監視する話で
コミュニケーション管理はリスクを潰す話だったりするんだが
細かい手法なんぞこの辺体験してからじゃないと覚えても無駄
なお現実にはプロジェクトを成長させる方向のマネジメントってのもあるんだが
普通は先ずコケないことこそが最重要でそっちは余力の話なんだよな

量産設計

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

そもそも現実とのすり合わせなんでやることはたくさんあんのに
実はこっちには具体的にコレという決まったものがあんましないwww
ただはっきりしてんのはココで"頑張る"なんざ設計屋的には失敗だってこと
現場で頑張らんで良いように先に苦労すんのが設計なんだわな

というわけで各自自分の分野で後工程何してんだろを意識して
何時かやってくる成熟期の何かよく分からんコストダウンに備えることになる

品質

「設計しました、終わりました」とかいうのはアホの言うこと
品質って聞くと如何にも直接的な"物"の善し悪しだけの話に思えるけど
実は設計そのものにだって品質ってものがある

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

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

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

蛇足

こんなもん書いておいて何だけど
ある程度技術を学んだ"一人前"はやたらと泥臭い技術を神聖視するんで
そういうのにこんな理想なんぞ語れば多分「現実は～」のオンパレードで否定するｗ
それはそれで一つの成長でとってもヨロシイ事なんだがまだもうちょい
誰かに師事するなら理想を語るときに苦悶の表情を浮かべるようなやつについてくといいよ