設計関係の記述を拝読。

それぞれ、設計が不要だという人に対する反論のような感じ。

多分、「設計」「設計書」という用語の範囲と深さの違いが背景にあるかも。

ある系(system)で動いているソフトウェア全体の設計を設計といえば、
99%は自分で設計していない。

３つか４つの設計思想の違う、1.操作系(operating system), 2.土台(platform), 3.言語(programming language), 4.通信規約(network protocol), 5.情報基地(data base)の中から選んでいるだけかもしれない。

設計しているわけではない。

第一の境界　選択は設計か

1, 2, 3, 4, 5に、それぞれ制約条件があり、５つの組み合わせを選ぶことが、
構造設計と呼んでもいいかも。

これを設計というか、設計といわないか、設計に対する立場が違うかも。

最終的な系を思い描かずに、選んでいるだけだから設計ではないという方は、自分が選んでいる根拠に、技術的な要素ではなく、経済的な要素が強いのかもしれない。

最終的な系の技術制約から、選択していると、設計と思うかもしれない。
系の全体像を描いて、そこに基本要素を割り当てる。

第二の境界　設定の変更

既存の系の設定を既定値のまま動かすと設計という認識は薄くなる。
既定値から必要に応じて変更すると、設計という意識が濃くなるかも。

選択した要素の、基本的な制約条件をそのままに受け入れて、なんとか動くものを作っていると、設計という認識が薄くなるかもしれない。

選択した要素の、基本的な制約条件の例外的な修正が可能な場合に手を入れていると、設計という認識は濃いかもしれない。

何を設計というか。
系をよくするために、何をするか。

二つの立場の違いが、言葉が通じていなくて、相手の制約条件の妥当性を確認することなく、すれ違っていく。

この２−３年、食っていければいいや的な人のやっていることと、
自分の作った系が３０年、みんなの役に立てばと思っている人の、
設計の範囲（量）も質も全然違う。

人の設計に乗っかるだけ乗っかって、お金をもらう人には、設計なんて不要でしょと思う。
それが契約の範囲内であれば、悪いことではないし、そういう行動の方が短期的にはお金が儲かるかもしれない。

「設計書なんて不要でしょ」について触れるのを忘れていた。

設計書は不要かもしれないし、
ソースコードが設計書かもしれない。

設計よりも、もっと幅広い。

設計になんの役に立たない文書類を設計書と称して、費用計上している仕事もあれば、
設計に必要な資料を、使い捨てで廃棄してしまう仕事もあるかもしれない。

顧客には必要ないかもしれないが、作り直すために必要な資料を、設計書と仮定する。
必要な資料だから、不要ではない。

いらないのは、設計書という名目で、設計に役に立たない書類群。

ソースコードは設計書であり、コーディングは設計作業である
https://qiita.com/mdstoy/items/5510f94c9ed981cfbb85

ver. 0.01 初稿 20190522 午前
ver. 0.02 標題追記 20190522 午後
ver. 0.03 参考資料追記 20190525

いいね　💚、フォローをお願いします。

Please press the like icon 💚　and follow me for your happy life.