Deep Insider の Tutor コーナー
>>  Deep Insider は本サイトからスピンオフした姉妹サイトです。よろしく! 
Build Insiderオピニオン:花井志生(3)

Build Insiderオピニオン:花井志生(3)

歳を取ってもエンジニアを続けられるのか

2016年8月25日

エンジニアが年を取るとはどんなことだろう。年を取ることのデメリットとメリット、加齢に対する心構えを筆者自身の経験を基に語ってくれた。

花井 志生
  • このエントリーをはてなブックマークに追加

 今回は割と語り尽くされた感のある話題であるが、歳を取ってもエンジニアが続けられるのかという話をしてみたい。最初に結論から言ってしまえば、歳を取ってもエンジニアは「もちろん続けられる」なのだが、そうはいっても老化というのは否応なしに全ての人の身に降りかかってくる(将来は遺伝子研究が進んで老化というものがなくなるのかもしれないが)。

 30半ば過ぎの方は、最近物忘れが段々と増えてきたり、あるいはもともと視力の良い方であれば近くが見えづらくなってきたりと、このままエンジニアという職を続けてよいのだろうかと不安を抱えているかもしれない。今回は、老化への対処について具体的に取り上げたい。また、老化には負の側面だけでなく、プラスとなる面もあるのでその点についても触れてみたい。

勘違いしてはいけない。それは老化のせいなのか?

 人間誰しもある程度歳を取ると「もう自分は歳だな、ダメだな」と気弱になってしまうものだ。特に自分よりも優秀な若いエンジニアを見たときにはそう感じるものだ。しかしちょっと待ってほしい。それは本当に老化のせいなのだろうか。

 老化のせいなのかどうかを見極めるのであれば、「若いころの自分」と「今の自分」を比べるべきだ。若いころの自分と競って勝てるだろうかと考えてみるのがよい。あるいは「若かりしころの自分なら、その若い優秀なエンジニアに勝てるのか」と考えてみればよい。大抵は若いころの自分でも勝てないと感じるはずだ。

 潔く認めよう。それは歳のせいじゃない。能力的に負けなのだ。

 もっとも、悲観することはない。そういうときは大抵、ある一面(スキル)のみを比較して焦っているだけなのだ。人間誰しも自分が苦手なところを難なくこなす人に畏れを感じてしまうものなのだ。

 さて筆者自身が自分の若いころの仕事ぶりを思い浮かべると、だいたい図1の左のような感じだったかと思う。確かに集中力はあるし、手を動かすのも速いのだけど、ミスが多く、また最終的なゴールが見えなくなりがちで、どうでもよいところにこだわったり、感情が邪魔して冷静な判断を失って気が付くとあさってな方向性のものが出来上がっていたりしたものだ。

若いころと年を取ってからの仕事の進め方の違い

 歳を取ると図1の右のような感じとなり、確かにミクロに見ればスピードは落ちるのだけど、目標へ到着するための、より効率のよい道をたどることが可能となったように思う。つまり若いころの自分が相手なら、まだまだ対等以上に渡り合えると感じる。読者の方々も自分が若いころを思い起こしてみてほしい。自信が出てきたのではないだろうか。

加齢により失われるものと、その対処

記憶力

 とにかく面白いように物事を忘れる。特にひどいのは自分が興味を持てないもの(筆者の場合は特に人の名前をすぐに忘れてしまう)。何か技術的に面白いトピックを見つけて「後で調べよう」と思っていても、そのまま忘れてしまう。

 ただ、幸いなのは単純記憶というのは機械に肩代わりさせることが容易だという点である。

 今はさまざまなツールが発達している。単にURLを自分宛にメールで送っておくのでもよいし(Gmailは、未読メールが既読メールを押しのけて上にせり上がってくるので便利。他のメーラーを使っている場合は届いたメールに☆を付けるなどしておく。さもないとそのまますぐに埋もれて忘れてしまう)、Pocketのようなサービスを使うのでもよい。

 注意点として普段使っているツールを使うことだ。意気込んで新しいツールを使おうとしないこと。まず間違いなくそのツールを使い始めたこと自体を忘れてしまうからだ。筆者の場合は長期保存しておきたい内容は、Dropboxの決まったディレクトリにEmacsのorg-modeでメモを残し、短期でよいもの(待ち合わせ日時、場所など)は自分宛にメールするかカレンダーに登録するようにしている。

 外部サービスを使うときは、操作性はもちろん、検索性が良いものを選ぶべきだ。また突然のサービス停止や値上げになることも想定しておいた方がよい。代替のサービスがあること、内容をエクスポートできるものを選んでおくのがよいだろう。

 記憶力が低下したことで、コードを読むときに「この変数/関数って何だっけ?」という事態が頻発する。もっとも現在はIDEが発達しているので、カーソルを合わせれば説明がポップアップするし、すぐに宣言元にジャンプし、その後で元の場所に戻ってくることも容易だから、昔ほど大きな問題にはならないだろう。

 ライブラリを構築しているときには、全体の名前の統一を取れないということが起きる。これは不自然な(もとい新しい)ネーミングルールを持ち込んでいると起きやすいので、あまり新規の概念を持ち込まない方が無難だ。自分が昔から使っている概念を使ってシンプルな名前を付ける。それが結果として多くの人にとって分かりやすいネーミングとなる。

 記憶力低下にはマイナス面ばかりがあるわけではない。それは分かりにくいコードにすぐに気付けるようになるという面があるからだ。少々長い関数や分かりにくい名前が含まれているコードでも、若くて記憶力が良かったころなら難なく読めるだろう。しかし記憶力が低下するとそうしたコードは非常に読みにくいものになる。書いてから半年くらいたって忘れかけたころに自分のコードを見ると、「なんて読みにくいんだ」と感じることがあるのではないだろうか。記憶力が低下してくると、数日経過したところでそれに気付けるようになる。

視力

 筆者がコンピューターにディスプレイを初めてつないだころ、それはテレビの2chを使うものだった(初代ファミコンもこの形式だったので覚えている方もいるだろう)。画面はノイズや、ゴーストが多く、長時間見るには耐えないものだった。

 その後、専用ディスプレイとなったが、それでもブラウン管のディスプレイは、にじみやちらつきが多く、やはり目にはつらいものだった(当時は20インチの「巨大」ディスプレイを20万円以上出して購入し大事に使ったものだ)。

 今はどうだ。27インチもの巨大ディスプレイが数万円で買えるではないか。

 テレビの解像度が上がったので、60インチクラスのテレビをディスプレイの代わりに使うことも可能だ。筆者は30インチのディスプレイを2枚接続しているが、このくらいの面積のディスプレイを用意して文字を大きくして使えば、視力の低下によるハンデは微々たるものだ。

 ただし半田付けがかなりつらくなった点は認めなければならないだろう。眼鏡のようにかけるルーペを使えば幾分改善できるが、ルーペはピントの合う範囲を狭めるので、やはり作業効率は落ちてしまう。若い方は今のうちに思う存分、半田付けを楽しんでほしい。

聴力

 筆者は幸い今のところ顕著な聴力の衰えはないが、それでも特に低い声は聴き取りにくくなったと感じる。プログラミングに関してはメールやチャットなどの文字ベースのものが多いので聴力の衰え自体は大きな問題になることはない。

 唯一支障があるとすれば電話会議だろう。電話にはヘッドセットを付けること。このときイヤホンはカナル型のように外部音を遮断できるものを使うとよい。大事な会議なら録音しておいて後から聞き直すことも可能だろうが、筆者はそこまでしたことはない。あとサーバールームでの作業がある人は、常に耳栓を携帯しておくこと。

 余談になるが、聴力が低下してくると、人間というのは聴覚によって聞き取れなかった部分を類推で補っているのだということが実感できる。おやじがギャグを言うのは聴力低下のせいというのを聞いたことがあるが、なるほどそうなのだろう。会話の中で類推が占める部分が多くなってくると、変な言葉が頭の中に湧いてきて口走ってしまうわけだ。

体力、集中力、スピード

 歳を取ると作業に没入して集中できる時間は短くなるし、睡眠時間を削って物事を仕上げるというやり方も通用しなくなる。つまりミクロで見たときのスピードは落ちる。とはいえ、この手の集中力に頼った作業は長続きするものではない。下手な集中は全体として非効率なケースもある。

 例えば、先日、若いプログラマーが眠い目をこすりながら必死にコードをデバッグしているのを見かけたのだが、彼はデバッグするためにコードを直してはアプリケーションサーバーにデプロイして何をしていたかというと「printfデバッグ」をしていたのだ。

 ある程度大きなアプリケーションのデプロイ作業というのは数分を要するので、このやり方では非常に非効率だし、せめてデバッガーをアタッチしてやるべきだ。そのときはデバッグしている部分を関数に抜き出してJUnitでテストしたらどうかと提案したのだが、彼は「あともう少しで終わりそうなので」とかたくなにやり方を変えず、その後、数時間の間、沼にはまっていた。そのときの彼はいわば「集中している状態」だったのだろうが、それが悪い方向に作用して全体を見て、より効率の良いやり方を考えることができなくなってしまっていた。

 プログラミングは肉体労働ではないので、筋力の低下も大きな障害にはならないだろう。むしろ問題になるのは運動不足により、身体の弱い部分に影響が出る点だ。筆者の場合は若いころから、運動不足が続くと消化器の調子に影響が出ていた。これを回避するには軽い運動を継続的に続ける必要がある。加齢により、体内の弱い部分が増えてくる。今は視力にも影響が出るようになった。また健康維持に必要な運動量が幾らか増えてきたようだ。若いころは週1で水泳に行く程度だったが、今は1日1万歩、歩くようにしている。

 自分自身の日々の集中力に波があるのが不思議で、その原因を分析してみたことがある。結果として「時間内に正確に何らかの動作を行う訓練」というものに効果があるらしいことが分かってきた。それは例えば楽器を弾くというのでもよいし、アクションゲームをやってもよいと思う(筆者くらいの世代だと、例えばテトリスやコラムスのようなもの)。

 あと集中力を保つコツとして、単純作業をある程度混ぜるのにも効果があることが分かった。例えばJavaはboiler plateコード(決まりきったコード、例えば、getter/setterなど)を書かないといけないことが欠点としてやり玉に上がるが、逆にロジックに集中するようなコーディングばかりだと集中力が続かずに気が散ってしまうのだ。

 さすがにgetter/setterの実装などはIDEで生成すべきだが、例えばVisitorパターンを使っていて、新たなメソッドをVisitorに追加したので、コンパイルエラーを手がかりにして既存のコードに新たなVisitorメソッドの実装を追加していくような作業。こういう比較的単純な作業がある程度含まれていた方が、長時間集中を続けられるようだ。

加齢により向上するもの

視野

 よく「歳を取ると視野が拡がる」などといわれることがある。こういわれるとなんだか格好いいが、実際のところは「熱中力」の低下が原因と思われる。

 歳を取ると「熱中力」とでもいうような力が衰える。新しいプログラミング言語や技術に触れたとき、若い時にはそういうテクノロジを「盲目的に愛して」しまうことが多かった。

 自分のお気に入りの言語がdisられれば猛然と抗議する。恐らくエンジニアというのは、30歳くらいまでこういう中2病が続くのだ。そういう熱中した状態がプラスに働けば、高いモチベーションを保ったまま開発を続けることが可能だ。

 しかしそれにはマイナス面も当然あり、すぐに下火になる「失敗技術」に入れ込んでしまって時間を無駄にしたり、全体のアーキテクチャから見て、あまりバランスの取れていないシステムを構築してしまったりという失敗を招きやすい。歳を取ると、新しいテクノロジは単に手段としてしか見ることができなくなり、余程のことがなければ熱中できなくなってしまう。

 そもそもIT技術というのはコンセプト的には同じことの繰り返しであることが多く、ある程度昔を知っていると、真に新しいことに遭遇できることはあまり多くはない。

経験と勘と度胸

 「勘」というと、あまり論理的思考に頼らない直感的な判断を連想するが、歳を取ってえてくる「勘」は経験に裏打ちされたものだ。作業をしていて「あぁ、この流れはいつか見たダメなパターン」というのに気付くようになる。

 若いころはとかく思い込みで突っ走ってしまうことが多い。デバッグしていて「コンパイラ or ライブラリのバグではないか」などと、あさっての方向の原因を仮定して時間を無駄にしたり、ER図を完膚なきまでに正規化しようとしてしまったりという具合だ。

 歳を取ると、若いころの苦い経験があるのと、先ほど述べた「熱中力」が落ちているために冷静に自分を見ることができて、早期にこういう間違いに気付けるようになる。チームで仕事するときの年寄の役割の一つは、熱中し過ぎている若い人にアドバイスをしてクールダウンさせてあげることなのだろう。とはいえ自ら失敗しないと身に付かないから、アドバイスするときには優先順位、影響の大きさを考慮しつつ、あまり全体に影響のない部分は好きにやらせて失敗経験をさせてあげる必要があるだろう。

 「度胸」というと無鉄砲なことができるような勇気を連想するが、これも少し違う。相手が考えていることや、これからどうなるかが経験である程度読めるようになるし、また人間、経験のないものは怖いので、経験があるほど、怖いもの知らずになるというだけのことだ。

最後に

 筆者は1965年生まれで、今年で51歳となった。歳を取ると、どういったことに困るようになるのか。今回の話が、漠然と将来に不安を抱えている若い人や、老化を感じ始めてきた40代のエンジニアの方に、少しでも参考となれば幸いである。もっとも「エンジニア」とひと言に言ってもさまざまなあり様があるし、筆者自身の経験をベースにしているので、今回の話は、他の人には当てはまらない点もあるかもしれない。その点についてはご容赦いただきたい。

花井 志生(はない しせい)

花井 志生(はない しせい)

 

入社当時はC/C++を用いた組み込み機器(POS)用のアプリケーション開発に携わる。

10年ほどでサーバーサイドに移り、主にJavaを使用したWebアプリケーション開発に軸足を移す。

2015年夏からクラウドを用いたソリューションのテクニカル・コンサル、PoCを生業としている。

主な著書にJava、Ruby、C言語を用いたものがある。

 

Build Insiderオピニオン:花井志生(3)
1. Dockerでビルドを改善する

開発現場で役立つ記事や書籍を多数著している花井志生氏がオピニオンコラム初登場。今回は、コンテナー型の仮想実行環境「Docker」を使ってCIを行うことのメリットを考察。

Build Insiderオピニオン:花井志生(3)
2. 自宅サーバーか、クラウドか ― 開発/テスト機の採用基準と最適なミックス

個人の開発/テスト機でもクラウド(調達)の方が安いといえるのだろうか? 自宅サーバー(所有)の方が割安なケースを考え、両者のメリットを生かす手法と実践手順の例を示す。

Build Insiderオピニオン:花井志生(3)
3. 【現在、表示中】≫ 歳を取ってもエンジニアを続けられるのか

エンジニアが年を取るとはどんなことだろう。年を取ることのデメリットとメリット、加齢に対する心構えを筆者自身の経験を基に語ってくれた。

Build Insiderオピニオン:花井志生(3)
4. Mac の 良いところ、悪いところ

スタバでMacでドヤ顔ブームも一息ついた今、エンジニア目線であらためてMacの良いところ、悪いところを考えてみよう。

サイトからのお知らせ

Twitterでつぶやこう!