誰でも開発できる「詳細設計」の作成は「正」か「悪」か？

誰でもプログラムが書けるように詳細設計を記述する方法は、つまり「ＤＲＹ(Don't　Repeat Yourself)」の原則に反しているのです。

この事に皆早く気付かなければならばい。

設計書は、何を行うべきかを「自然語」で記述するべきなのです。

でなければ、プログラムを２本つくるのと同じ事になってしまいます。

本当は、プログラムを自然語で記述するため、２．５本から３本記述していることと同じになるはずorz

そのため、開発はタイトになり、「とりあえず動きます」プログラムが横行します。

いつも時間におわれているため、悩むことが出来ず、動かす事が大事で、何故？などと考えている時間もないのです。

本来であれば、リファクタリングすべきプログラムも放置し、次々開発していく羽目になります。

その結果うまれるのが、保守性最悪のソースになるのです。

そうすると、「何故こんなにも保守しずらいプログラムばかりなのだ！」と怒りに言葉が震えんばかりに、ある答えを導き出します。。。

・「そうか！もっと設計書を細かく記述すれば、良いプログラムが出来るのだ！　間違いない！それでいいのだ！！！」

まさに負のスパイラルです。

もう一つの問題として、誰でも保守できるように開発スタイル（テンプレート形式）の開発も問題なのです。

誰でも保守できる開発スタイルは、全体の技術力を停滞させる(向上させない)負の面をもっています。

これは、上級者に足かせとなり、開発生産も極端に悪くなるでしょう。

初心者もテンプレートよろしく、業務に適合しなくてもコピペ形式で開発するため、開発効率が悪くなり、技術力も一切つきません。

大事な事なのでもう一度言います。時間に追われている初心者は、精神的に不安定になり、仕事は苦痛になってしまいます。

苦痛な事にモチベーションが上がる人はいないでしょう（もし、いたらあまりお近づきになりたくありませんが…＾＾;

今やるべきことは、設計書は「何を実現すべきか」を自然語で記述するに留め、実現方法はプログラムで表現する様に変えるべきなのです。

この方法では、初心者は開発出来ないではないか！と言う意見が聞こえてきそうですね。でも大丈夫です。

反ＤＲＹ設計書の作成がなくなるため、上級者の時間に余裕が生まれます。

上級者は初心者の「ソース・レビュー」なり、「指導なり」をしてあげれば良いのです。

この方法は、間違いなく初心者の記述力の向上に役立ちます。

最後に、既存システムの追加要望（またはバグ修正）に、ソースを見ないで見積もりをしている方はいますか？

恐らく少ないはず … ＾＾；　←　この理由が大事！！！