エンジニアとして歳をとっていく

新しい技術や方法論に関心を示さない

変化が速い IT 業界において技術そのものへの好奇心が弱いのは不利になる。これは流行を追いかけるということともまた違う。何が本質的に重要なことで、何が従来とは違う考え方なのか、どこに新規性があるのか、表面だけではなくもう少し掘り下げて考えないといけない。必然的にその過程で歴史を学ぶことにもなる。

こういった視野をもつことで技術が発展していく方向性を予測したり、比較的長く応用できる概念を手に入れたりできる。現代において台頭する技術の大半は従来あった技術の積み重ねによる改善や、環境も含め時代背景によって注目を浴びることがある。決して何の前触れもなく唐突に現れることはない。

もしかしたら技術に好奇心のない人にとっては毎年のように新しい技術が台頭しているようにみえるのかもしれない。もしそんな風にみえ始めたら世の中の状況に対してかなり遅れていると危機感を持った方が良いのかもしれない。

学習のために自分の手を動かさない

はてなブックマークやQiitaなどをみていると技術情報はたくさんある。人気のある記事を読んで何となくその技術を分かった気になったりもするが、やはりそれは分かった気になるだけでしかない。職場の、実際の業務に応用できるかどうかはまた別の視点や要件があり、実際に手を動かして、自分でその技術をある程度は理解する必要がある。学習した結果、その技術は自分たちの業務の用途にはあわないといったこともある。

自主的な学習の話になるとよく業務外か業務内かという議題が話題になることもある。そのどちらでも構わないと私は思う。

自主的に学習した技術が使いものにならないと分かったとする。その価値をどう考えるか。それは徒労ではなく、自分たちの業務を深く理解することに繋がり、その学習した技術の特性を理解することにも繋がる。それを溜めていくことでアーキテクチャの理解や技術選定の洞察力も高まっていく。

前節の好奇心も含め、歳をとるごとにモノゴトそのものに面倒くさくなっていく。相対的に他にやることが増えているのもあるだろう。歳をとるごとに怠惰になりやすい自分を律することが必要になってくる。

怠惰に立ち向かうきっかけが何になるか、人によって違うとは思うけれど、何かしらの刺激が必要になると私は思う。よほど刺激的な職場環境でないと社内だけで刺激を得ることは難しいかもしれない。幸いなことに IT 業界は勉強会やオープンソースコミュニティといったものが活発な業界なので社外で多くの刺激を得られる。

話し合いが本質的ではない内容になる

老獪という言葉がある。歳をとると論理の粗探しや自分の責任を回避するのが経験的に上手くなる。

だまってコードを書けよハゲ

と言えれば一言で終わるのだけど、職場の人間関係を考慮するとこんな厳しい表現はなかなか使えない。

極端な例を紹介すると、現状の問題の改善案を提案したときに改善案の粗探しをして潰してしまう人が稀にいる。もちろん適切な欠点を指摘してさらに優れた改善案を提示するのであれば構わない。このとき新しいことをやりたくない人は、現状の問題を放置したとしても、新しい取り組みをやらない方向へ議論をもっていく。その新しい取り組みの課題のみをことさら指摘する。対案に関しては自分の職務ではないとか言って責任回避して逃げてしまう。

こういう人と議論をするのは時間の無駄である。往々にして議論を悪魔の証明へもっていくのにも長けている。新しい取り組みをするとき、それが実際に有効かどうか、本当のところ、やってみないと分からない。さらに新しい取り組みへの経験やスキルが足りない場合はさらにそうだ。

もし話し合いをする度に建設的な議論にならなかったり、話しても結論が出そうにないといったときはそんな人と話し合うのはやめて、偉い人にリスクを理解した上でやる・やらないを決めてもらうと良いだろう。

自分より詳しい人に聞きに行かない

技術だけの話ではないけれど、自分から情報を取りに行こうという姿勢をみせない。(ビジネスにおける) コミュニケーションの原則で言えば、依頼した業務の責任は全てマネージャーが負う。つまり年配の人が聞きに来なくて失敗をしたとしてもその責任はマネージャーが負う。そのこと自体は構わない。

もし私がマネージャーをしていて、経験の浅い若い人がチームにいるときは定期的に「困っていることはないか？」「分からないことはないか？」と私から聞きに行く。経験が浅い場合、往々にして何が分からないのか分からなくて止まっているということがある。そういう状況を察して助言することはある。

但し、私は年配の方にこういう気遣いはしない。というのは、経験のある方には失礼になるかもしれないし、分からないときは分からないと言うことぐらい分かっていて当然だと思うからだ。

日本だと年功序列の影響が根強いせいか、若い人に教えを請うという行為そのものに抵抗がある人もいるかもしれない。もし自分が全ての技術分野において長けているという自負がないのであれば (そんな人はどこにもいない) 、年齢に関係なくより詳しい人に聞きに行くべきだ。

また年功序列をうまく利用する方法もある。若いときは自分で調べずに先輩へ聞きに行くと「聞く前に自分で調べろ」と怒られることもあるかもしれない。自分の方が年上だと若い人の方が気を遣って丁寧に教えてくれることもある。もちろん私も教えてもらうために適切な態度で接する必要はある。

やっていることや状況を文章で表現できない

世の中の開発業務でどのぐらいチケット駆動開発が導入されているのか分からないけれど、開発や業務をマネジメントするのに課題管理システムは有効だ。

年配の方にとっては課題管理システムのない時代に開発していた人もいるだろうから馴染みがないかもしれない。しかし、いまは課題管理システムを普通に使えるのが必須のスキルだと私は考えている。

課題管理システムが優れているのはチケットというタスク単位にいまやっていることの状況を共有する手段として妥当なシステムだからだ。前節で聞きに行くべきだとも書いたけれど、なんでもかんでも細かいことを聞きに行くのも実際には難しい。そういうときにチケットに質問を書いておけば、マネージャーがみて答えてくれるだろう。

チケットには質問だけでなく、そのタスクをやっていて調べたこと、考えたこと、起こったことなど何でも書けば良いと私は考えている。実際、私自身そうやってチケットに書き込んでいるし、周りにもそのようなスタイルを推奨している。

そう推奨してもそれができない人もいる。ただ書けば良いだけだと私は思うのだけど、なぜか書いてくれない。別に10分ごとに書けというわけではなく1日数個のコメントといった頻度で構わない。マネジメントの観点から状況を報告してくれないと手伝うことも、負荷や業務のスケジュールを調整することもできない。

もし自分の日々の業務の状況を文章として表現できないとしたらすぐに先輩や上司に相談した方が良い。単純にそれを表現する文章力がないとしたら、業務以前の問題でまず文章を書くスキルを身につけるべきだ。

さらに文章を書くスキルがあるにも関わらず表現できないとしたらやはり業務以前の問題がある。そのタスクの背景の理解が足らないのかもしれないし、そのタスクを遂行するのに必要なスキルが欠けているのかもしれない。まずはその問題を解決しないと業務もうまくいかないのではないかと個人的には思う。

まとめ

スキルもやる気もない年配の方の特徴としてあげてみたけれど、実際には年配の方に限らず若い人にも当てはまることがあるだろう。但し、若い人は単純に経験がなくて分からなかったり、適切な指導を受けていなくてできていないということがある。周りの先輩たちもそんな若い人をみかけたら指導してくれるだろう。そして若い人は何かのきっかけで大きく変わることがある。

なぜ年配の方に指導しないかというと、これは私の憶測だけど、年配の方も自分でこんなことには気付いていると思う。何か事情があるとしても、自分で気付いていて自分で対策を講じようとしない人に他人がしてあげられることはないという意味で私は諦めている。

気付きがない人と、気付きがあっても何もしない人の差は大きい。気付いたら何をするかは自分次第だ。