浮ついた「ギーク」への説教(※老害注意)

オールドタイプ的な老害トークをぶってみます。「プログラマーなら梅田本よりK&R読め」と(あぁ老害)。

「ヱブ弐点零デ、マツシユアツプ」とか言ってる場合じゃないんですよ。Nintendo DSのカートリッジ自作ハックくらいしろと。OSカーネルやコンパイラを書けと。

本職のプログラマを名乗るなら、「珠玉のプログラミング」を読んで問題を解いて欲しい。Perl/PHP/Ruby/Pythonしか書けないようでは、本物のプログラマと呼びにくい。JavaとLispとC/C++(まあ、いまならC#ですかね)も覚えてほしい。ちなみにWrite Great Codeも良いらしいです。

本書でいうグレートコードとは「高速・コンパクトかつ、リソースを無駄使いせず、可読性に優れ、保守が容易で、一貫したスタイルに従った、系統的に設計され、拡張性に富む、十分にテストされ、確実に動作し、ドキュメントが整備されている」コードです。

つまり、要点としては、コンピュータ・サイエンスとソフトウェア工学は、みっちりおさえてこそ、プログラマということ。単なる「コーダー」は、うちには要らないし、今後日本で必要とされない(オフショアになります)。

プログラマとコーダーの違いを言うと、「コーダー」ってのは、オペレータ(ボスの手足となって動くだけの人)に過ぎない。ソフトウェア開発において、設計とコーディングは不可分であって、自分で考えてコードを書けるかどうかが問題。こういうコードを書けと指示されて書くだけの人は要らんのですよ。偉い人にはそれが分からんのです。

最初に学ぶべきスキルは、コンピュータサイエンス(とくにアルゴリズムとデータ構造)、ソフトウェア工学(設計論、開発方法論、テスト技法など)の2つ。これが基礎。そのうえで、広く、深く、学んでいって欲しいんですよ。なのに、世の中には基礎を学んでいない人が多すぎる。

ついでに言うと、流行技術(の表層だけを)を追いかけるのは不毛。コンピュータの基礎は30年前の知識がいまだに使える。それがあれば最新技術などいつでもキャッチアップできるのです。(コメントより転載) 結局のところ、コンピュータの動作原理やアルゴリズムの基礎は変わってないのでね。

この「The Art of Computer Programming」というシリーズのオリジナルは、1968年に書き始められた。36年前のことである。そして今も書き続けられている。

(中略)

1968年にオリジナルが書かれたとき、本書は全7巻構成であることが、第1巻(Volume 1)の前書きで予告された。そして、分厚い本が3冊、1973年まで5年の間に続けざまに書かれた。その3冊(もちろん改稿が加えられ続けた最新版)は今、ボックスセットになって売られている。映画のDVDみたいだ!!!

スターウォーズ・サーガなんて、目じゃないって。プログラマなら買っておけと。まあ初級者は結城氏の「プログラマの数学」から始めよう。

あぁ、説教じみて、すみません。

そんな私はプログラマとしては中途半端。いまはプログラム書いてませんし(ソフトウェア分野の技術経営コンサルティングや、インタラクティブコンテンツのプランナー職)。上述の話は「むかしはあたりまえにこういう人たちがたくさんいたんだ(それなのに今の若者は・・・)」という話です(自分がどうだというのは横に置かせて頂いて)。

で、まあそういう天才職人が減るのは、産業の成熟化に伴う現象ですから、「ようやくIT産業も成熟化してきたか」という喜ばしい現象と解釈してもいいのですが。ZEROBASEのスタンスとしては、「今だからこそ、職人が活躍できるのだ」です。

そんなわけで、うちではコンピュータ・サイエンスとソフトウェア工学をがっつり身につけた、本物のプログラマを募集中です。あわせてシステムズ・エンジニア(コンサル&プロマネ)も募集しています。(人材募集概要

タイトルに老害と書いてるように、半分は冗談ですので(酒は飲んでません)。とはいえ説教臭いなあ、我ながら。

同じように老害トーク問題提起を展開されているこちらから引用:

知的労働者には「組織を移る力」がある
下の人たちが「こうした方が良いと思う」と真剣に提案するのに耳を傾けてくれない上司はろくな上司ではない。下の人たちのキャリアパスを全く考えてくれない上司も、やはりろくな上司ではない。そんな上司に付いていっても良いことはない。もし、会社がそんな上司をいつまでものさばらせておくとしたら、そこはろくな会社ではない。その時は、真剣に転職を考えるべきだ。

というわけでして、ZEROBASEは、そのような方々の「受け入れ先企業」として(笑)

ソフトウェアの仕様書は料理のレシピに似ている

世界を又にかけてソフトウェア・ビジネスをしている米国の会社は、MicrosoftにしてもGoogleにしても、この法則にのっとって、アーキテクト自らががプログラムを書いている。

しかし、私が一度働いたことのあるNTTの研究所では、ほどんど自らソフトウェアの開発をしたことの無い人達が詳細資料書を書き、それを外注に発注してプログラムを書かせる、というソフトウェアの作り方をしていた。学生時代からプロとしてソフトウェアを作っていた私は、新入社員にも関わらず「こんなやりかたじゃ良いソフトは作れません」と上司たちにくってかかったのだが、誰一人として理解してくれなかった。

追記:
たつをのChangeLogにて引用して頂きました。ありがとうございます。「確かにCプログラマーなら必読です、K&R (プログラミング言語C)。メモリ管理の話が面白いですよね」とのこと。

こういうコードを書くことを推奨しているわけではありません。

そうそう、当時は事情があって、とにかく1文字でも短く書こう、という感じでしたが。。。 最近では、「ある程度冗長でも、読みやすく」というのが常識ですよね。ソフトウェア工学の成果かもしれない。

最近は教科書もJavaになってきているようで、、、C言語って、「広くアプリケーション開発に使われる高級言語」としての役割を終えたんですかね。。。(一部、カーネル、デバドラ、組み込み、高速処理などでは健在ながら)。いっときは、Cにあらずば言語にあらず的な一世風靡具合でしたが。

C言語の行く末は。。。って、やばい、マジ懐古趣味。

追記:3月27日(コメントより抜粋)
改めて主張を整理すると「産業の成熟化に伴うプログラマーの低レベル化は不可避な現象」「むしろ産業の進化という意味では肯定している」。しかし「まだまだ天才職人プログラマが活躍できる場所は多い」と考えております。基礎を理解していない人が増えることは当然だという認識。

主張が混在してしまい、分かりづらい面がありました。「Cが大事」「Cをやれ」というC言語推奨話ではなくて、「基礎が大事」ってことが言いたかった。「コンピュータサイエンス」「ソフトウェア工学」の2つが大事。さらにはコンピュータの動作原理、ハードウェアの理解も大事だといいたくて話がC言語方向に発散してしまいました。

RubyでもシステムコールやI/Oポートを叩けるので、言語がどうこうという話ではないと理解ください。どちらかというと「CPAN知り尽くして生産性を上げるのは大事だけど、どんなモジュールを使うべきか判断することや、CPANにない場合にアルゴリズムとデータ構造に理解がないと困る」といった話として。

あくまで半分冗談の老害トークなので、あまり本気で反論されるとビビります。

トラックバック(0)

トラックバックURL: http://zerobase.jp/mt/mt-tb.cgi/386