設計力がないのに金に目がくらんで「設計」しちゃうのが一番の問題CommentsAdd Star

この中で印象に残ったのは

実際に手を動かして作るのは利益率が低いので外に振るという経営判断

と言う部分ですな。。。親にも指摘されている。

問題の核は「設計」にありと言う部分ですが

プログラム自体が設計であるから、元請けでは設計は出来ないってのが真実じゃないかと。。。

新規で画面のIFとかを作成したとして、細かい操作や、操作手順によってどう言う処理を行うかとかを全てドキュメントに書くのは難しい。

もし書いたら組み込み系におけるテスト仕様書以上にはなるはずだ。

最初からそこまで分厚い仕様書ってあるのけ？

もし業務系で作ったら仕様が少ないものでも何十～何百万と項目があるだろう。。。

また実際作ったものからテスト仕様書に全ての操作手順とその結果を記述したつもりでも抜けが出るのに作る前からそこまで出来るものだろうか？

つまりは、大雑把なところ以外はほぼ開発任せである。

設計と言っても大雑把な機能しか記述出来ない。

設計が悪くてデスマーチになるのではない。

十分な知識と技術力を持った人員の確保と適切な納期の設定、仕様が増えたときの対処、ほぼ請けた段階からデスマーチや赤字になるプロジェクトは決定している。

ソフトウェアは作ってみないと難易度や規模が見えないというのが問題だ。

また仕様は開発が進むにつれ何故か増えてくる。。。

大規模でやると作るものが分からないので大量にドキュメントが必要だ。
設計じゃなくて、作るものが何かが分かる文章を書くことが設計と言われている。

もし、設計がプログラムではないならば、プログラムを書く人は何も判断する必要が無いはずだ。

あとは効率良く動かすための大まかな機能のブロック分けと人員の割り振りだろうな。
これらがプロジェクト管理だ。

設計と言われているものも一人で作って打ち合わせするには必要無い。

設計の通りに動くなら、そのままプログラムを自動生成させて完了のはずだ。

数億のプロジェクトと言うと人員が大量それなりに動いている。。。

プログラムの場合、設計と言われているものは設計じゃない。プログラムが設計だ。

設計がプログラムにあるから、ぶっちゃけ関わる人全てが設計者だ。個人の裁量に任せなければならない部分が必ずある。判断をまったく必要無しに作れる部分は無い。

だから「船頭多くして船山に登る」の言葉そのままの通り、人数が増えれば増えるほど失敗確率があがる。

本当は他のことを書こうと思ったのだが、上の記事を読んだらまったく違う方向に。。。（汗