シス開発：システム開発に役立つ様々な視点 |
プログラマーに関する説の１つとして、有名な「35歳定年説」がある。簡単に言うなら、プログラミングの仕事は若いうちしかできず、35歳あたりで能力が低下するので、引退したほうがよいという内容だ。何を根拠に誰が言い出したのか不明だが、かなり広く知れ渡っている。ところが、実力のある人ほど否定しているが、残念ながら、説得力のある反論を見たことがない。そこで、少し論理的に否定してみよう。
最初に注目したいのは、プログラマーのレベルだ。同じ言語でプログラムが作れるからといって、全員が同じレベルではない。できあがったプログラムの質には、天と地ほどの差がある。質の高いプログラムが安定して作れるほど、レベルの高いプログラマー、つまり優秀なプログラマーなのだ。
では、プログラムの質とはいったい何だろうか。処理速度やサイズも大事だが、それだけではない。把握性、柔軟性、信頼性なども考慮して作る必要がある。把握性とは、プログラムのソースコードで、処理内容の読み取りやすさを意味する。柔軟性とは、機能の変更が容易で、変更してもバグが出にくいことまで含まれる。１本のプログラム内の話だけでなく、プログラムの分割方法にも大きく関係する。信頼性とは、バグが少ないことと、メモリー不足などのシビアな環境に強いことである。システムを変更しながら長く利用するなら、柔軟性が高くないと、信頼性も高く保てない。変更が容易でなければ、変更後の信頼性が低下しやすいからだ。
これら全部を合わせた評価が、プログラムの質である。ただし、対象となるプログラムによって、評価基準は少しずつ異なる。処理速度が非常に重要なら、把握性や柔軟性を犠牲にして、速度を追求したプログラミング方法を選ぶ。逆に変更が多い場合は、処理速度を犠牲にして、把握性や柔軟性が高い作り方を採用する。つまり、プログラムの質とは、求められている特徴に適合しているかも含むのである。最近では、CPUの処理能力が向上しているため、把握性や柔軟性を重視する傾向が強い。このような要望に応えて、プログラムを作り分けられれば、本当に優秀なプログラマーである。
以上のような点を考慮しないで作られたプログラムは、トラブルを引き起こしやすいだけでなく、変更や移植などで余分な手間やコストを生じさせる。良いプログラムとの差は、ほんの少しではなく、非常に大きなものだ。相当に我慢しても無視できないほど大きい。
プログラムの質を高めるには、プログラミング以外の技術も必要となる。たとえば、きちんとテストをする技術で、信頼性を高めるために役立つ。また、開発ツールの使い方、OSや動作環境の機能なども理解しなければならない。加えて、プログラミングに関する設計技術も求められる。
ここまでの話で、できあがったプログラムの質を向上させることと、テストなどの技術をマスターすることが必要だと分かった。では、これらを会得するには、どれだけの時間がかかるであろうか。実は、人によって大きく異なる。
まず、本人の能力に関係する部分だ。プログラミングへの適性があれば、プログラムの処理速度やサイズに関しては、資料を集めて勉強することで何とかなる。プログラミングに対する適性が高いほど、短期間でマスターできるはずだ。信頼性の向上に関しても、最近は情報が多く出ているので、探して勉強すればある程度はマスターできる。
それ以外の項目になると、独学では難しい。解説した本や情報がほとんど出ていないからだ。どんな環境で働くか、どんな人と一緒に働くかが一番大きく影響する。とくに、把握性や柔軟性の必要性は、なかなか理解できないようだ。他人が作ったシステムのメンテナンスを経験して、把握性など考慮してないプログラムを何本も見れば、必要性を体で知れる。ところが、そんな経験がないと、理解するのはかなり難しい。そんな経験の後で、把握性や柔軟性を向上させる方法を教えてもらえば、本当に理解しながら覚えられる。テスト技術も同様で、きちんとしたテストを実施している人に教えてもらわないと、なかなかマスターできない。
さらに、設計技術のように、ある程度の経験が必要なものもある。最初は良いと考えて設計しても、後から発生した機能の拡張に対応しづらく、設計が失敗だったと思う経験も大切だ。どんな設計がベストなのか、同じ意識を持つ仲間と何度も討論することが、設計の能力を高めることに役立つ。いろいろな考えに触れ、より多くのアイデアを試すことで設計技術が磨かれる。
このように見ていくと、単なる経験年数だけではダメなことが分かる。独学だけでは難しいので、一番大切なのは、多くの技術をマスターできる環境で働くことだ。もう１つ、幅広い技術をマスターしようとする本人の意識も重要である。その両方を満たし、本人の適性が高いなら、最短だと５年ぐらいの期間で身に付けられると思う。逆に、そんな環境にいなければ、何十年経験しても会得できない。
ソフトウェアの業界は、技術革新が激しい。そのため、新しい技術をマスターしないと、一人前として仕事ができない。定年説の背景として、年齢が高くなることで、新技術をマスターできない点が含まれているかも知れない。しかし、35歳あたりで新技術をマスターできなくなるのだろうか。新しい技術は登場するものの、中身が画期的に新しいことは、ほとんどない。見せかけや仕様が異なるだけで、新しい部分は少ししか含まれていないのが現状だ。既存の技術をきちんと会得していれば、苦労をせずにマスターできる。年齢が高くなると記憶力は低下するが、35歳程度ではまだまだ大丈夫。
最近の新しい技術の中で注目すべきなのは、オブジェクト指向の考え方だ。プログラミングの世界にも深く浸透し、C++やJavaが主流になりつつある（先進的なユーザーは既に移行した）。この種の技術が前と大きく違うのは、力ずくの作り方が通用しない点だ。オブジェクト指向は、設計における考え方が中心となっている。そのため、オブジェクト指向の設計思想を理解なければ、良い設計やプログラミングはできない。つまり、力ずくでは使いこなせず、優秀なプログラマーにしか特徴を生かせない道具なのだ。このようなツールの登場で、プログラマーの能力差はますます広がることになった。
問題なのは、このような新しい考え方の多い技術を、35歳以上でもマスターできるかだ。この点こそ、今回のテーマの中心であろう。自分の周囲を見る限り、優秀なプログラマーは“苦労せずに”マスターしている。ここで、よく考えてほしい。35歳を越えたからといって、頭が悪くなるわけではないのだ。もしそうなら、世界中の研究者は若い人ばかりだろう。35歳以上になっても、新しい成果を産み続けている研究者は多い。頭が悪くならないどころか、上手に考える技を身に付けた人もいて、より高い成果を出すことが可能だ。プログラマーも同じで、たとえ60歳になっても、質の高いプログラムを作り続けられる。
もう１つ、年齢が上がるにつれて徹夜が難しくなるのが理由だという人もいる。たしかに、システム開発では徹夜することもある。しかし、徹夜の回数が多いのは、SEやプログラマーが優秀でないからだ。レベルの低い人を基準に定年説を主張するなら、そのような条件を付けるべきである。
そろそろ結論を述べよう。プログラマーの35歳定年説は明らかに間違いだ。それどころか、優秀なプログラマーは、頭がボケるまで、質の高いプログラムを作り続けられる。もし本人がプログラミングを大好きなら、良いプログラムをどんどんと作ってもらったほうがよい。システムの信頼性や柔軟性が高まり、ユーザーも大きな恩恵が得られる。
逆に、優秀でないプログラマーはどうだろうか。どうすべきかは人によって違う。きちんとした経験がないのが原因なら、今からでも勉強して経験を積めば、優秀なプログラマーへと変身できる。しかし、プログラミングへの適性がないのが原因なら、仕事を変えるのが賢明な選択だ。この仕事は、利用者への迷惑が発生するので、本人だけの問題ではない。どちらなのか判断するためにも、いろいろな技術の会得を試すべきである。
最後に、開発コストの話をしておきたい。プログラマーの生産性は、最低と最高を比較すると、少なくみても10倍は違う。優秀でないプログラマーを何人集めても、苦労が増えるばかりで得にはならない。優秀なプログラマーに数倍の報酬を払って、懸命に働いてもらったほうが、良いシステムを構築できる。実際には、報酬は２〜３倍あたりで落ち着くので、開発コストを考えれば安上がりだ（２〜３倍を推奨しているわけではない）。同様に、優秀なSA（システムアナリスト）やSEを集め、ある程度まで高い報酬を払ったほうがよい。ただし、これを実施するには、優秀な人を見極める能力が必要で、優秀な人にしか優秀な人を見分けられない。それが簡単ではないので、結局は難しいと言うしかない。
（1997年12月31日）
プログラマーの35歳定年説なんて大ウソ |
