プログラマでメシを食うなら
得意分野を持て

　私は1989年に社会人になりましたので、プロのプログラマ歴20年ということになります。その前にアルバイトで3年間プログラミングをしていましたので、合わせて23年間、プログラミングでメシを食ってきたわけですが、それを支えてきたのは得意分野です。

　得意になるから好きになるのか、好きだから得意になるのかは難しいところです。いずれにしても得意分野で活躍できるのは気分も良く、結果も良いものです。

　学生時代から、基本的には誰からも教わることなくプログラミングを得意分野にしてきた過程を紹介することで、こんなレベルの取り組みでも得意分野を育てられるのだということ、得意分野にこだわることにより、より良い仕事を経験できて成長できる例もあると参考にしていただければ幸いです

　学生プログラマから就職、そしてどん底状態へ

　もともとコンピュータは嫌いだったのですが、大学1年生の冬に始めたCADシステムの改造を行うアルバイトでC言語、UNIX、MS-DOSに触れました。周囲のコンピュータ好きの友人は「C言語は難しく、並の人にはできない」というので、「それなら、できれば格好良いだろう」と。そんな優越感が、私をプログラマの道へ引き込んでいきます。

　当時は、PC-9801で快適なC言語コンパイル環境を構築するだけでも試行錯誤が必要で、ハードディスクもない状態でmain関数だけで4000行もあるひどいソースをコンパイルするのは大変でした（もっともすぐに関数分けをしましたが）。バンク切り替え式のRAMディスクが登場したときには、コンパイルの静かさに感動したものです。

　大学卒業までにC言語、UNIX、MS-DOSはほぼ思いどおりに使える状態になり、若者がすぐに活躍できる仕事ということでプログラマの道に進みました。入社早々からCADシステムの開発・販売を任され、技術的には何とかなっても業界知識で苦労したり、販促活動に苦労したり……。

　「何でも対応できる完璧なCADシステムを作るぞ！」と基本設計からやり直して取り組んだものの、あまりにも理想が高すぎて性能や使い勝手で難航し、業績はどん底、毎週の会議では社長や他部署から非難の嵐。作れば良いってものではないことを痛感しました。

　ちなみに、その“理想のCADシステム”はネットワークで各モジュールを連携させ、GUI構築モジュール、簡易言語モジュール、CAD専用モジュールなどを自由に組み合わせて、エンドユーザーがシステムを改良・構築できるようなもので、データ構造もいまのXML並に自由度の高いものでした。

　当時のハードウェアの性能では、巨大データを扱うCADシステムとしてはあまりにも理想が高すぎたといえるでしょう。しかも、ユーザーからは「自分でシステムの改良などしたくない。最初から簡単で使いやすいものを提供しろ」といわれる始末。

　しかし、ここで思いっきり複雑なシステムにチャレンジしたことと、ネットワークでいろいろと試行錯誤したことは大きな力となりました。

　圧倒的なネットワークへのこだわり

　ネットワーク保守支援にも行きました。恥をかきながらネットワークの基礎をたたき込まれました。このときの悔しさがネットワークに詳しくなりたいというきっかけになったとも思っています。

　あるとき、UNIXが分かる技術者を探しているということで、大手の開発に参加する機会を得ました。技術的には、それまで手掛けてきたCADシステムに比べれば簡単なものです。巨大なデータを扱うCADシステムの開発の経験から、「性能」に配慮したプログラミングも身に付いています。ネットワークにも詳しかった点も活きました。

　開発速度も速く、品質も性能も高いという結果を出したことで、「UNIX関連ならここに相談すれば良い」と覚えていただき、定常的な仕事が増加し、業績も大幅黒字となったのです。

　開発メンバーが全員ネットワークが好きだったわけではありません。各自得意な部分を持っていたので、私がネットワークとグラフィック関連を中心に担当したということです。時間があればネットワークのプログラミングや、インターネットサーバの構築などを試行錯誤しながら楽しんでいました。

　Webシステムの開発が活発になってきた頃に、お客さんから「負荷試験をする際に大勢を集めてテストをするのは効率が悪いね」といわれました。「それなら自動で負荷をかけるものを作ってみますよ」と開発したWeb負荷試験ツールは、いまでも製品として販売しています。

　ここからさらにネットワークの性能や信頼性などにこだわりはじめ、さまざまなツールを作りました。特に、技術的に困難そうなものや、性能的にシビアなものほど、商売抜きに燃えて取り組んだので、ますますノウハウがたまっていきます。それを元に著書を書き始めたのもこの頃です。

　受託開発ばかりではつまらないということで、製品開発販売事業を本格的に立ち上げました。もちろん得意分野を活かした製品です。売れなくても技術アピールにはなりますし、自分たちが受け身の姿勢だけにならないようにするためのチャレンジの場でもあります。

　得意分野がないと厳しい時代

　こうやって振り返ると、

• C言語やUNIXを、当時としてはかなり早くに使えるようになったこと
• CADシステムという複雑なシステムの開発をやっていて、ほかの仕事が相対的に簡単に思えたこと
• 多くのプログラマが苦手にしていた、ネットワークプログラミングにこだわったこと

つまり、どの時期でもほかの人とはちょっと違う「得意分野」を持っていたことが、ここまでやってこられた背景だったと思います。

　優秀なメンバーが集まったのも、それぞれが得意分野を持っていたからということに間違いありません。お互いに一緒にやってみたいと思う人たちが集まってくるものです。「なんでもやってます」では優秀な人は集まらないのではないでしょうか。

　私がほかの技術者と違うとお客さんからいわれた点がもう1つあります。

• 技術に詳しいのに、コミュニケーションもきちんとできる人

　これは、CADシステムの開発販売を新人時代に任されて、デモンストレーションもやらされたおかげだと思っています。早くから責任者として会議で責められたことも、冷静な対応の訓練になったといえるかもしれません。

　ITバブルの時代、開発の仕事はあふれていました。得意分野がなくても、すぐに仕事が見つかる時代です。ところが、いまはそんなに甘い時代ではありません。誰でもできるような開発はオフショアで安くできますし、そもそも開発の仕事の量も落ち着いてきました。

　少なくなった仕事を取り合うとなると、納期とコストの競争に巻き込まれます。「うちでないとできない仕事」あるいは「うちがやればすぐできて高品質」というような説得力がないと、おいしい仕事が取れなくなってきているのです。

　「得意分野など、その技術が廃れたら価値がなくなる」という人がいますが、ある分野の価値が突然ゼロになることはありませんし、大抵は技術の積み重ねで新しいものが生まれますから、得意分野は進化した技術でも活かせるものです。

　例えば、シリアル通信はあまり使われなくなりましたが、TCP/IPの仕組みにはシリアル通信で使われていた技術がたくさん含まれていますので、シリアル通信に詳しい人ならすぐにTCP/IPも理解できます。

　また、得意分野で尖っている人ほど、それ以外の情報も集まるものです。得意分野で頼りにされるので、人脈が広がり、多くの情報が集まるようになるからです。

　もちろん、1つの技術以外は知らなくて良いということではありません。幅広い知識の中で、自分はこの分野が好きだというところを見つけ、その分野を伸ばしていけるようにアピールして仕事のチャンスを集め、ますます得意になっていく、というプラスのサイクルを回せるかどうかが、私が考えるプログラマの取り組みのポイントです。

　こういう話を書くと「単なる自己満足だ」「時代が違う」と思う人も多いと思います。しかし、批判するだけでは何も変わりません。「私ならこうする」「いまならこうすべきだ」と考えるきっかけに使ってみてください。

関連リンク：
	プログラマー社長のブログ プログラミングでメシが食えるか！？ http://blogs.itmedia.co.jp/komata/

Coding Edgeフォーラム トップページ

	いまさらアルゴリズムを学ぶ意味 コーディングに役立つ！ アルゴリズムの基本（1）　コンピュータに「3の倍数と3の付く数字」を判断させるにはどうしたらいいか。発想力を鍛えよう
	Zope 3の魅力に迫る Zope 3とは何ぞや？（1）　Pythonで書かれたWebアプリケーションフレームワーク「Zope 3」。ほかのソフトウェアとは一体何が違っているのか？
	貧弱環境プログラミングのススメ 柴田 淳のコーディング天国　高性能なIT機器に囲まれた環境でコンピュータの動作原理に触れることは可能だろうか。貧弱なPC上にビットマップの直線をどうやって引く？
	Haskellプログラミングの楽しみ方 のんびりHaskell（1）　関数型言語に分類されるHaskell。C言語などの手続き型言語とまったく異なるプログラミングの世界に踏み出してみよう
	ちょっと変わったLisp入門 Gaucheでメタプログラミング（1）　Lispの一種であるScheme。いくつかある処理系の中でも気軽にスクリプトを書けるGaucheでLispの世界を体験してみよう
	more

　　Coding Edgeフォーラムフィード　 2.0／1.0／0.91