『ずっと受けたかったソフトウェアエンジニアリングの新人研修』続き

http://d.hatena.ne.jp/takahashim/20090405/p6 の続きです。

ずっと受けたかったソフトウェアエンジニアリングの新人研修

この本、やっぱりあんまりお勧めできません。なぜか。それは（おそらく旧来の）開発手法に対する反省的/批判的視点が足りないからです。

言うまでもなく、コンピュータの分野はここ数十年、ものすごい勢いで進化してきました。その影響は、社会全体にまで広がっていると言えるでしょう。

では、その恩恵をもっとも受けられるのは誰でしょうか？　その候補の一つに、「ソフトウェア開発者」を挙げるのは不適切でもないでしょう。ソフトウェアは人間の代わりに要件を考えることはできないでしょうし、それをまとめる支援をするのも大変です。一方で、ソフトウェアそのものを作る、あるいはその支援を行うことは、コンピュータの得意分野の一つです。事実、開発プロセスからコードの書き方まで、コンピュータを使う、コンピュータに頼る率は相当増えてるんじゃないかと思います。昔のことはよく知らないんで推測ですけど。

ところが。この本では、そういった変化に、驚くほど欠けているんですよ。おそらく10年以上も前から作って来た文書を、今もそのまま作ろうとしているように見えます。それはないんじゃないか、と。
もちろん、私のよく知らない開発現場はあるはずです。そこではなかなか効率化できないところかもしれません。でも、本書で例に挙げられているのは、最終的にはPerlのCGIでイントラのWebシステムを組む、というものです。そんな題材なのに、いちいちフローチャート（しかも独自記法の）を書いてから、あるいはメソッドの引数の仕様をドキュメントで書いて精査してから「製造」する、というのは、なんぼなんでもないんじゃないでしょうか。

ソフトウェアエンジニアは、それほど人気の高い職業ではないという話もあります（本当かどうかは良く知りませんが。なんかバイアスかかってる気もしますし）。そのような状況で、ソフトウェアエンジニアの新人に伝えたい技術はなんでしょうか。まー、電話の受け方とか話し方とかはさておき、あとコミュニケーション周りの話も除いたとして、やはり現代のソフトウェア開発技術でしょう。別に関数型プログラミングがどうとか、最新のIDEやSCMやITSがどうとかいう話ではありません。それよりももっとベーシックな、たとえば「システム化」「自動化」「電子化」といったレベルの話です。コード書けば済むようなことをいちいち手書きで書いてロジック追っかけてからコーディングする、とかいった（本書でやってるいような）ことを避けるとかいった話です。

本書で対象としているのはおそらくSIerとかだと思います。よく知らないけど。システム化を提案する立場の人が、自分自身の業務がシステム化、自動化されていないようでは、紺屋の白袴にもほどがあるんじゃないでしょうか。実際の現場ではさまざまざまな制約があってそういう風にもいかないのかもしれません。でも、何も知らない新人に対して「研修」の名の下に教えることとしては、もう少しちゃんとした開発方法を教えるべきです。それが開発に携わる先人としての義務でしょう。

彼ら、彼女らこそが、やがて私たちを乗り越えて、これからのソフトウェア開発の、そしてソフトウェアと結びつく、私たちの未来を作っていくのですから。