駆け出しのプログラマは、仕様書をトレースしたような（つまり手続き型的な）ソースコードを書きがちです。それは仕様書に忠実ですが、読みやすいソースコードになるとは限りません。下手をするとこれだけでSEなるお化けに彼らはなってしまいます。こうして、SEたちは仕様書至上主義者となっていくわけです。
いっぽう、ベテランプログラマは、仕様書を一度そしゃくします。そしてわかり易いソースコードになるように再構成するわけです。すると、仕様書というものが空しく見えてきます。SEなるお化けは、仕様書をトレースするようなコーディングしか経験していませんので、仕様書を詳しく書くことこそがコーディングさせるのに最良のものと考えます。
ベテランかどうかはあまり関係ないかも。おいらが新人として配属された1年目ですらそういうソースコードにそのまま起こすための仕様なんてものは渡されてなかったし、やりたいことをちゃんと理解させて、コードは自由に書けというスタイルだった。つまり、環境のせい。
そもそもそんな仕様書を書く暇があったらコードが書けるわけで、効率がひたすら悪い。
でも日本語によるプログラム設計書と違い、ソースコードの場合、使用する言語やフレームワークによって大幅に構成は変わってくる。それらをすべて自称SEクンに読ませるのは骨が折れるだろう。そのSEクンは現場によって違う、ありとあらゆる言語やフレームワークを理解してもらわないといけないのだから。
とはいえ、言語やフレームワークにはそれなりにあった使い方というものがあり、日本語で指示されたコードがその流儀に従っていない場合どうしたらいいのだろう。つまり、日本語で書かれたトレースさせるような設計書自体役に立たないことを現してしまう。だからいつまでたっても、コボラーのようなコードといわれるのだろう。
言語によって思想が違うというのはこちらにもあったが珍しくはない。だから、すでに言語を１つ知っていれば一ヶ月もあれば追加の言語をマスターするのは簡単だという人は信用できない。それはうわべを覚えただけでマスターとは程遠いだろう、と。たとえばJavaも最低でも1年、まともに使い物になるには2、3年は要するはずだ。
つまり、言語やフレームワークにあわせた最適な日本語によるトレースさせるようなプログラム設計書は事実上不可能になってしまう。数種類の言語を使い分けることができるころには10年以上を要することになってしまうからだ。
言語を選択するってことはとても大事なことで、会社として新人にどういった言語を勉強させるか、2〜3年後の収穫期（バリバリコードを書けるようになる時期）を考慮しながら教えていかなければならない。3,4年たったのでプログラマからSEへクラスチェンジをしてもらうという会社も多く存在するが、稼げる時期をなくしてしまう理由が個人的にはわからない。プログラマってのは設計もコーディングもするクラスなのだからみんなやればいいじゃない。
新人のOJT用としてトレースしたような設計書を渡すのは、ぜんぜんトレーニングにならないのだからやめたほうがよい。最初からこのプロジェクトの背景にあるものとか、DB選択の理由、こういった設計になったわけなどを教えていけばよい。その辺がしっかりわかっていれば、人のコードを見ながら（できればペアプロがいい）自然と必要になるテストコード等がわかってくるはず。そんな状況で鍛えられた新人ならば1年後には仕様の間違い等もしっかり指摘できる頼れる人材になっているはずだ。
そもそも、日本語からコンピュータ言語へ変換するだけの作業ならば、将来に絶望してこの業界をやめていく人が大量にいそう。夢と希望と不安を持って新卒の内容がこれだったら絶望しか生まれてこないでしょ。できる人ならなおさらというあたりがたちが悪い。モチベーションって大事だよね。
