プログラマ35歳定年説に思う

「プログラマ35歳定年説」という言葉がある（30歳説、40歳説もあるが、数字そのものはあまり問題ではない）。加齢によるスキルダウン、体力ダウンを連想させる言葉だが、むしろ、会社組織的な背景が強いようだ。

システム開発業界では、「彼はまだプログラミングしかできない」といった言葉をよく耳にする。つまり、この業界の中では、プログラミングは一般的に「簡単な仕事」とされているのである。本当はそんなに簡単なわけではないのだが、他の仕事はもっと難しいということだろう（※１）。

開発の仕事を、「簡単だとされている」順に並べれば、テスト、プログラミング、設計、要求分析というように、ウォーターフォールと呼ばれる製造工程を逆流するような順番になるだろうか。もちろん、プロジェクト・マネージメントのように、別の次元ではもっと難しい仕事もある。

それぞれの仕事には、違ったスキルが必要なので、本来、こうやって「順に並べる」のは間違いだろう。しかし、現実には、同じ人がこれらの仕事を順に経験していくことが多いようだ。入社直後はテストやプログラミングから始め、徐々に難しい仕事を任されるというわけだ。つまり、プログラマから、SE、マネージャへと「出世」していくのである（※２）。

また、プログラミングは、与えられた設計書に従って行われる。このため、プログラマという職種には、どうしても「指示される側」という印象がある。日本人は、指示系統と年齢の逆転を嫌うので、自然と、プログラミング＝若い人の仕事という図式が出来てしまう（※３）。

★

もちろん、全てのプログラマが「出世」コースを歩むわけではない。このことは、プログラマという職業にとって、皮肉な状況を作り出す。

有能なプログラマは、物事を論理的に考え、無駄を嫌い効率化を好む。また、コミュニケーション能力等にも秀でている（コーディングだけがプログラマの仕事ではない！）。会社としては、そういった人物を有効活用しない手はない。プログラミングばかりやらせているのはもったいないので、積極的に「出世」させる。35歳にもなれば、少なくとも SE と呼ばれる方が相応しくなっているだろう（※４）。

反対の理由で、無能なプログラマは出世しない。つまり、彼らはずっとプログラマのままなのである。35歳になっても定年にはならない（賢明なら早いうちに自ら職種を変えるのだろうが、あいにくそういう人は少ない）。最初からスキルがないので、加齢によるスキルダウンの心配も無用である（※５）。

つまり、プログラマと呼ばれる期間は、プログラマとしてのスキルが高い人ほど短くなり、低い人ほど長くなるという皮肉な状況になる。

★

そう考えると、プログラマ全体としてのスキルは、どんどん低下していく運命である。このままでいけば、開発効率や品質の低下は必至だ。

実際、プログラミングの「難しい部分」を、プログラマ出身の SE やプロジェクト・リーダーと呼ばれる人々が引き受けなければ、納期に間に合わない、品質を確保できない、というケースは少なくない（当然、彼らの負荷は異常に高くなる）。

業界自体の歴史が浅いため、こうした問題は、重大視されてこなかったのかもしれない。しかし、本来なら、有能なプログラマこそ、純粋にプログラマとして働いてもらうべきだろう。そして、それを実現するためには、人事や組織、キャリアプランのあり方といったことを見直していく必要があるのではないだろうか。

応援のクリックお願いします →

※１
プログラミングは誰でも出来る仕事ではない。ただ、「上位工程」に比べれば、比較的「簡単な仕事」を用意しやすいのは確かである（下記関連記事も参照）。

※２
会社によっては、いきなり SE やマネージャになるような「エリートコース」もあるようだ。なお、現実には、SE、プログラマのように肩書きがはっきりと分かれることは少なく、SE 兼プログラマや、プログラマ兼テスターというように、同じ人間が複数の作業を行うことが多い。小さいプロジェクトでは、１人で全ての工程をやってしまうこともある。

※３
つまり、年上の人向かって命令しにくい、叱りにくい、といったことである。年上の人を敬うという精神が根底にあるのだろう（それ自体は悪いことではないと思うが）。

※４
もちろん、それは彼らをどう呼ぶかということであって、彼らがプログラミングしなくなるというわけではない。高度な技術を要するプログラミングは、彼らでなければできないからだ。

※５
35歳を越えたプログラマが全て無能だと言っているのではない。言うまでもないことだが、念のため。

プログラマの「本懐」 ~アーキテクトという選択

posted with amazlet on 06.09.10

山本啓二
日経BP出版センター (2004/11/25)
売り上げランキング: 17,696

おすすめ度の平均:

プログラマの新たなキャリアアップの道、アーキテクト

ITアーキテクトの確立

アーキテクチャとアーキテクト

Amazon.co.jp で詳細を見る

ソフトウエア開発プロフェッショナル

posted with amazlet on 06.09.10

スティーブ・マコネル松原友夫山浦恒央
日経BP社 (2005/01/20)
売り上げランキング: 16,616

おすすめ度の平均:

ソフトウェア関わる人すべてにお勧め

ソフトウェアエンジニアリングとは？

「ニセ実力主義」の組織のすべての人へ

Amazon.co.jp で詳細を見る

ビジネス書を読んだ気になる

こんなお仕事系ブログを書いていると、ビジネス書の類を好んで読んでいるように思われるかもしれないが、全くそんなことはない。自分がビジネスマンだと思ったこともないし（※１）、ビジネス書を買う資金があるなら技術書を買ってしまう。

しかし、職業プログラマにも役に立つようなビジネス書は沢山あるのだろう。特に、プログラマの定年と言われる年齢（※２）を迎え、管理職的な仕事も多い今となっては、そういった本も読んだほうがいいのだろうと思う。

というわけで、NetVoice の BookCasting というサービスに注目している。このサイトでは、色々なビジネス書が要約されて紹介されている。しかも、ただ文章が載っているだけでなく、その要約を<音読してくれるのだ（ポッドキャスティングも行われている）。

今年の春からサービスが開始され、私も時々聴いていたのだが、気がつけば60冊近くになっている。この調子で増えていけば、ますます便利なサービスになるだろう。

★

昔、ラジオで浜村淳氏の映画紹介を聞いたことがある。氏の解説はストーリを喋りすぎるので、いわゆる「ネタバレ」になってしまうという批判も多い。しかし、ビデオも普及していない時代に、映画館がないような田舎に住んでいた私にとっては、ありがたいものだった。話を聴いただけで実際に映画を観たような気分になったものだ。

NetVoice にも、同じように、本を「読んだ気」にさせるようなところがある。ネタバレといえなくもないのだが、もちろん、本の内容を全て得られるわけではない。ネットで購入する際など、立ち読みも出来ないので、こうした情報はやはりありがたいものである（ちなみに、私の田舎には書店もない）。

なにより、活字を読むのではなく音声で聴くというのは、目を酷使する職業柄、嬉しいサービスである。自動車の運転中にでも聴けるので、時間有効活用にもなるだろう。

書籍に限らず、もっといろんなジャンルについて、このようなサービスが広がって欲しいものである。

応援のクリックお願いします →

※１
本来、ビジネスマンは経営者や事業主を指すらしいが、日本ではサラリーマンとの区別は曖昧だ（はてなダイアリー）。「サラリーマンとビジネスマンはどう違うのか（ビジネスマン育成塾さん）」の分類方法で言えば、サラリーマンであるよりはビジネスマンでありたいとは思うが、「After Five」だけは微妙か・・・。

※２
プログラマ30歳定年説とか、35歳定年説というのがある。というと、脳力低下（あるいは体力低下）をイメージする人もいるかもしれないが、事情はもっと複雑だ。詳細はまたいずれ。

Life Hacks PRESS ~デジタル世代の「カイゼン」術~

posted with amazlet on 06.09.03

田口元安藤幸央平林純角征典和田卓人金子順角谷信太郎
技術評論社 (2006/03/23)

Amazon.co.jp で詳細を見る

Web2.0でビジネスが変わる

posted with amazlet on 06.09.03

神田敏晶
ソフトバンククリエイティブ (2006/06/16)

Amazon.co.jp で詳細を見る

新しいプログラミング言語を学ぶということ

プログラマのスキルを判断する際に、特定のプログラミング言語の経験の有無を重視しすぎるのはよくない。プログラマにとっても、雇う会社にとってもだ（関連記事：Javaなんて知りません）。

プログラマとしては、それを実務で使うかどうかに関わらず、気になる言語があれば、積極的に学んでおきたいものだ。

★

前回の記事にも書いたが、何かしらプログラミング言語の経験があれば、他のプログラミング言語を学ぶことはそれほど難しくはないように思う。

もちろん、プログラミング言語といっても、似ているものとそうでないものがあるので、一概にはいえないのかもしれない。例えば、Ｃ言語（手続き型言語）と LISP（関数型言語）とでは、全く書き方が違う。

しかし、職業プログラマが特定の職場で求められる言語ということであれば、ある程度のパターンが決まってくるのではないだろうか。例えば、私の会社であれば、何かしらのオブジェクト指向言語と SQL を覚えれば、なんとかなりそうだ。

★

とはいえ、「似た言語」を学ぶからこそ、考慮すべき問題もある。

端的な例では、いわゆる switch 文に break が必要かどうかという問題がある。C/C++ や Java などの switch 文では、各 case 処理の終りに break を書かなければ、次にある case 処理が続けて実行される。一方で、VB（Visual Basic）の Select 文（Ｃ言語系の switch 文に相当）では、break に相当するものが存在せず、条件に一致しない Case が実行されることはない。このため、VB に慣れているプログラマが、Ｃ言語で break を書き忘れてしまうことがあるのだ。当然、これはバグに直結する。

他にも、VB プログラマがＣ言語で「if(a == b)」と書くべきところで「if(a = b)」と書いてしまう（※１）とか、C++ プログラマが Java で「text.equals("foo")」と書くべきところで「text == "foo"」と書いてしまう（※２）など、言語の微妙な違いに起因するミスは多い。

個々のプログラミング言語ならではの特徴をきちんと把握しておかないと、思わぬところでバグを生むことになるのである。

★

新しい開発プロジェクトの立ち上げ時など、このような「言語の特徴」を、短期間で多くのメンバーに浸透させなければならないことがある。チームとしては、上記のような「落とし穴」をリストアップし、教育や品質チェックの仕組みを整えておいたほうがいいだろう（そうした仕組み作りがしっかりしていれば、人材募集の際にも、具体的な開発言語の経験有無によって間口を狭めてしまう必要もなくなるはずだ）。

しかし、実際のところは、そのような組織的な取り組みが行われているケースは少ないようだ。結局のところ、プログラマ個人の努力に依存してくることになってしまう。

もっとも、根っからのプログラマは、そんなことを「努力」などとは思わない。むしろ、新しい言語を覚えること自体に喜びを見出すだろう。目の前の仕事に必要であるかどうかに関わらず、役に立ちそうな新しい道具があるのなら使ってみたいと思うのは、プログラマに限ったことではないだろう。

しかし、一方で、仕事で必要だからと嫌々ながら勉強するようなタイプの人もいるようだ。その仕事は彼にとっての天職ではないのだろう。もちろん、誰もが天職につけるわけではないのだから、仕方ないといえばそれまでなのだが・・・。

応援のクリックお願いします →

※１
Ｃ言語で a = b とすれば、比較ではなく代入になるが、if の中に書いたからといって、エラーにはならない。

※２
Java で String に対して「==」を使うと、文字列の内容の比較ではなくインスタンスが同じかどうかの比較（ポインタの比較）になる。

VB6プログラマーのための入門Visual Basic.NET独習講座

posted with amazlet on 06.08.27

川俣晶
技術評論社 (2003/12)
売り上げランキング: 25,261

おすすめ度の平均:

私もこれで移行しました

一度読めばよいかと

移行書でありながら、上級技術者までカバー

Amazon.co.jp で詳細を見る

ふつうのHaskellプログラミング
－ふつうのプログラマのための関数型言語入門

posted with amazlet on 06.08.27

青木峰郎山下伸夫
ソフトバンククリエイティブ (2006/06/01)

Amazon.co.jp で詳細を見る

プログラミングの入門書は何が良いか？

プログラミングの入門書として何が良いかと聞かれることがある。これが意外と困るのだ。自分が入門書の類を読まないので、具体的な書名を挙げることが出来ないのである。

もちろん、プログラマには、いつまでも新しいプログラミング言語を学ぶ機会がある。しかし、ある程度の経験者と、全くの初心者とでは、その学び方が異なるのである。ベテランのプログラマは、「入門書」を読むのではなく、文法書やリファレンス、既存のソースコードなどを読んで、その言語の「特徴」を押さえることで、新しい言語をマスターしようとするだろう。言語が違っても、プログラミングという仕事の基礎の部分は共通しているのである（※１）。

★

また、長年プログラマをやっていると、「初心」を忘れてしまうという問題もある。自分が初めてプログラミングを学んだときに、何が難しかったのか、何につまずいたのか、といったことを忘れてしまうのである（関連記事：「￥」について普通の感覚で考えてみる）。そんなわけで、実際に入門書を開いてみても、今ひとつ、どれが良いのか判断できないのだ。

「どういう本が良いか」と尋ねてくる人には申し訳ないのだが、無責任なことも言えない。結局、「自分で探してくれ」と言うしかないのである。

★

本を選ぶ際に他人の意見（周囲の人や書評系のブログ、オンライン書店のレビューなど）が参考になるのは確かである。しかし、人によってプログラミングの学び方は違うだろうし、苦手とする点も違うだろう。本との出会いは人との出会いと同じように、相性というものがあるのだ。

プログラミングの入門書に限らず、自分なりの「本の選び方」について、一度、考えてみるべきである（※２）。そのためには、やはり、色々な本を手に取り、読んでみることが必要だろう（立ち読みを含めて）。

そして、そういった努力が、最終的には「情報の価値」を判断する力を育てるのではないだろうか。情報過多の現代にあって、それは重要な力のひとつである。

応援のクリックお願いします →

■関連記事
・ポインタという考え方
・Javaは知っていることにしている

※１
例えば、経験のあるプログラマが Ruby を覚えるなら、「一時間で覚える Ruby（MAYAH.JPさん）」。この程度の情報で十分なのである。
もちろん、言語によっては、ここでいう「基礎の部分」が異なる場合もある。例えば、Ｃ言語プログラマがＣ++ を習得するには、「オブジェクト指向」の基礎知識が必要だ。そういった場合は入門書が必要になるかもしれない。しかし、それは「はじめてのＣ++」ではなく「ＣプログラマのためのＣ++入門」あるいは、「オブジェクト指向入門」になるだろう。

※２
私が技術書を選ぶ際に（内容の質という点以外で）確認するのは、出版時期（古いと役に立たないこともある）、情報量（文字が小さくても情報量が多いものが好きだ）、索引の充実度（読み物ではなくリファレンスとして使えるかどうか）といったことだろうか。

やさしいJava 第3版

posted with amazlet on 06.08.20

高橋麻奈
ソフトバンククリエイティブ (2005/09/01)
売り上げランキング: 10,005

おすすめ度の平均:

JAVA言語の文法を一から学んで行こうとする方にオススメ

入門用

Amazon.co.jp で詳細を見る

PerlユーザーのためのRuby入門

posted with amazlet on 06.08.20

吉田和弘
オーム社 (2003/04)
売り上げランキング: 192,142

Amazon.co.jp で詳細を見る

プログラマの神頼み

プログラミングをしていると、「プログラミングの神様」が降りてきて、あっという間に出来てしまった、という人がいる。もちろん、これは「集中力の高まり」を文学的に表現しているだけである。しかし、本当にプログラミングの神様がいれば、と思うこともある。

「怖いこと」という記事に書いたように、システム開発では人間が予想しえないような問題が発生するものだ。どんなに対策をしても、どうしても不安が残ってしまう。結局、最後は神仏に頼りたくなる。

開発時だけなく、システムが稼動してからも避け難いトラブルは多くある。ハードウェア障害、外部ネットワークからの攻撃・・・。しかも、トラブルはなぜか続けて起こる。サーバー管理者等にも、神頼みしたくなった経験のある人は多いはずだ。

いや、神頼みできればまだよい。社会のＩＴ化が進む中、日本人（自分も含め）の信仰心はどんどん希薄になってきているようだ。頭が「デジタル」な技術者にあっては、なおさらその傾向が強いのではないだろうか（※１）。一方で、システム開発業界の過酷さは増すばかりだ。この業界に、ストレスに耐え切れずに精神的なダメージを受けてしまう人が多いのも、「神の不在」と無関係ではないだろう。

★

つまり、日本のコンピュータ業界には神様が必要なのだ。八百万の神々が存在するという日本である。人間界に「ニーズ」があるのだから「担当窓口」の神様を決めてくれているはずだ。そう思って、調べてみると、ascii24.com にこんな記事を見つけた。

　システム安全、バグ退散! 関係者の尊崇を集める神社はその名も“電電宮”!!

電電宮は、京都嵐山の法輪寺の寺内にあり、電気電波の神様である「電電明神」を祀っているという。最初は冗談かと思ったのだが、ちゃんとした神社のようである（法輪寺電電宮、Wikipedia 、Google Map ）。

「出来る限りのことはやった。あとは祈るだけ」という方は、お参りしてみてはいかがだろうか。

★

ここからは宣伝。もし、電電宮まで行く余裕がないなら、「不具合退散」ステッカーがある（※２）。効き目があるかって？　とりあえず、PC 等に貼っておけば、自分が「不具合に立ち向かう姿勢」を表明することはできる。そうすれば、周囲の人にも気持ちが伝わり、開発チーム全体が良い方向に動き出すかもしれない。そう、お札というものは、貼るということ自体が重要なのだ。

また、社内ネットワークのセキュリティを願う方には「火内安全」という姉妹品もある（※２）。「火」は「ファイアウォール」の意味だ。ネットワーク機器にどうぞ。

★

宣伝で終わるのもなんなので、最後にもう一つ。ハードディスクの高速回転によって効力を発揮するという、チベット仏教の呪符をご紹介。

　デジタル呪文でバグ退散！（妖精現実さん）

トップページには「このウェブサイトは、都合により、まもなく終了します。」とあるので、参照はお早めに（※３）。

応援のクリックお願いします →

※１
個人的な感覚であり、根拠はない。もちろん、結城浩さんのように信仰をもった方もおられる。なお、世の中には「アナログ」とは古いこと、「デジタル」とは新しいことみたいな妙な言葉の誤用があるが、ここでは、あえてそれに「乗っかって」いる（適切な言葉が見つからなかったので）。

※２
どちらも拙作だが、私も実物を見ていない。なぜなら高いから。というか、まだ誰も買っていないので実物はこの世に存在しない（2006/08/12時点）。お金に余裕がある人のみどうぞ。もちろん、ただのステッカーなので、神秘的な力はない。

※３
2006/08/12時点。サイトがなくなるという意味なのか、更新しなくなるという意味なのかは不明だが、質の高い記事が多いので残念だ。

■関連記事
・バグの気持ち
・怖いこと
・ラッキーなこと（旗振大明神や神田明神の御守りもご紹介）