> >臨機応変というと言葉の響きはいいですが、実際は、最初に決めるべきことを
> >決めないで、走りながら決めていく、というのが実態ではないでしょうか。
>
> 確かに、ご指摘の通りですね。
> それが、実態と言ったほうが正しいと思います。現場サイドではいろんなことが
> あります。
> 営業サイトの仕様で走ったら。途中でレイアウト変更発生なんてのは日常です。
> 仕様が決まるのを待ってたら納期遅れ確実ってのが現状の中で進行してるのが実態です。
> その対応の為に、ユニット化、標準化、コンポーネント化されて来ました。
> それが、設計力の低下と言われればそうかも知れませんが
> そうやって、やる手法も　一つの設計のやり方の大きな技術だと思います。

それは、でも後ろ向きの技術ですね。


> 私が思うのには、どれが正しい設計でどれが間違いというのは存在しないと
> 思います。その会社もしくは、個人でもいいですが。
> おかれた環境によって、下から積み上げる設計もあります。
> 全体から　切り落としていく設計もあります。
>
> その中で、個々の手法のルール造りがあったほうがいいのでは
> ないでしょうか。

うーん、いろんな会社の設計を見た限りではそんなものはないと思います。
まっとうな設計プロセスがあって、そこからどれだけ離れてるか、だけの
違いだと考えます。


> >代表的な例は「設計マニュアル」なるものを作ってメンテナンスをしていない
> >ような場合です。
>
> 私は、「設計マニュアル」必要と思っている一人ですが。メンテナンスされてない
> 例というのは、どのような具体例をご存知でしょうか？

設計マニュアルがメンテされないというのは、作った時点から内容の進歩が
ないと言うことです。ということは、逆に言うと、設計マニュアルどおりに
やれば誰でもできるということになりますね。当然、そんな製品は付加価値が
低くてもうからないものが多いのでしょう。
単に、面倒くさくてメンテしていない場合もあるでしょうが、事が済んでいる
ということも、それはそれで問題ですね。

> >代表的な例は「設計マニュアル」なるものを作ってメンテナンスをしていない
> >ような場合です。
>
> 私は、「設計マニュアル」必要と思っている一人ですが。メンテナンスされてない
> 例というのは、どのような具体例をご存知でしょうか？

メンテどころか、作っておしまい、誰も守っていないなんて事も
あったりして。
マニュアル作ること自体が仕事になっちゃってるんですよね・・・

こんばんは～　(^。^)

>臨機応変というと言葉の響きはいいですが、実際は、最初に決めるべきことを
>決めないで、走りながら決めていく、というのが実態ではないでしょうか。

確かに、ご指摘の通りですね。
それが、実態と言ったほうが正しいと思います。現場サイドではいろんなことが
あります。
営業サイトの仕様で走ったら。途中でレイアウト変更発生なんてのは日常です。
仕様が決まるのを待ってたら納期遅れ確実ってのが現状の中で進行してるのが実態です。
その対応の為に、ユニット化、標準化、コンポーネント化されて来ました。
それが、設計力の低下と言われればそうかも知れませんが
そうやって、やる手法も　一つの設計のやり方の大きな技術だと思います。

私が思うのには、どれが正しい設計でどれが間違いというのは存在しないと
思います。その会社もしくは、個人でもいいですが。
おかれた環境によって、下から積み上げる設計もあります。
全体から　切り落としていく設計もあります。

その中で、個々の手法のルール造りがあったほうがいいのでは
ないでしょうか。


>代表的な例は「設計マニュアル」なるものを作ってメンテナンスをしていない
>ような場合です。

私は、「設計マニュアル」必要と思っている一人ですが。メンテナンスされてない
例というのは、どのような具体例をご存知でしょうか？