こんにちは。ヒコーキ好きのみこやんです。
昭和のおじさんエンジニアの声など誰も聞きたいと思わないかもしれませんが、長くやってきた中で皆さまに知見のお裾分けができるかもしれないということで、「廃れないエンジニアであり続けるには」というテーマのポエムでも語ってみたいと思います。
ご存知の通り、こうしたことには唯一の正解や万人向けの解答といったものは存在しません。
誰かが語った経験則はその人限りの規則であるのと同様に、何かを成し遂げるには千差万別の方法が存在すると言っても良いと思います。
したがって、ここに記載されることは私のポエム以上のものではないかもしれません。
なのになぜ書くのかというと、千差万別といっても、その全てが本人以外には絶対に当てはまらないというわけではないからです。
とはいえ注意すべき点は、私の実践もまた依然として「継続中」であるということです。
つまり、答えが出切っているわけではないということになります。
気が向いたら、ポテチでも摘みながら、ライトに読み流していただければ幸いです。
触れ続ける
どの業種業界でも言えることかと思いますが、やはり現場に触れ続けていないと、廃れて行きやすいものです。
もちろん、マネージャクラスや管理職になってしまったりすると、仮に本人が望んでいたとしても、現場に居続けるわけにはいきません。
それをしてしまうと、かえって現場を壊しかねませんし、何よりマネジメントの仕事に集中できなくなるでしょう。
プレイングマネージャという立場も世の中には増えてきています。
私の理想はここでありましたが、実際には、若いエンジニアなどをサポートしつつマネジメントに関する種々の仕事をこなすなかで、設計と実装という極めて集中力の求められる業務を並行して続けるにはかなり限界があります。
現役の開発者であれマネージャであれ、実装スキルの鍛錬は不可欠でしょう。
自分のコードを客観的に評価したり、コードレビューで他者のコードに適切な評価を下す場面で、どうしてもそうしたスキルは欠かせないものです。
さりとて、プライベートな時間を犠牲にしてまで、業務に必要な知識を獲得することにやぶさかでない、と思える人物はなかなかおりません。
そうはいっても一人の人間が完全にモードを切り分けられることができないのも事実。
業務時間の内外に関わらず、こうした技術に関するアンテナをしっかり常日頃から張っておくことで、情報をとらえることはできます。
もちろんプライベートな時間で情報をキャッチすることもあります。
そのまま好奇心が向かえばプライベートの時間であれ10分時間を割いて知識を拡充できると思います。仕事のときに改めてと思えば、業務内の隙間時間をうまく活用して情報をキャッチできるでしょう。
重要なのは、アンテナを張れているかどうか、ということだと思います。
アンテナを張る力さえあれば、自分の今の職域や立場がどうであれ、触れ続けることはできるのではないかと思います。
ちなみに私は、幅広いIT知識の獲得は三度の飯より大好物なので、プライベートの時間も費やしてしまうタイプですので、ここの知見については皆様のお役には立てないかと思います……。
実装する
これはもう、間違いなく不可欠であると思います。
もちろん商用プロダクトで実装することが最も刺激的で有意義だとは思いますが、現場を離れたエンジニアは立場上そうできない場面は多いことでしょう。
私も実践できたりできなかったりではありますが、方法がいくつかないわけではないと思います。
- コードレビューする
- ペアプロ・モブプロする
- リファクタリングする
- ユニットテストコードを書く
コードレビューする
コードレビューはマネージャやテックリードだけの仕事ではありません。
現役の開発者も他のエンジニアが書いたコードは読むべきです。
コードの共有だけではなく、コードを客観的に見ることで得られる気付きがあります。
もっとも、コードレビューは昨今のプロダクトの開発チームではほぼ導入していると思います。
ただ、指導的立場の人が指導的レビューだけをしているチームもあるかと思いますので、そうではなく、より多くのメンバーがコードに触れる時間を設けることは大切なのではないかと考えます。
ペアプロ・モブプロする
コードレビューでは客観的に他人のコードに触れる機会が獲得できますが、ペアプロやモブプロでは、他のエンジニアの実装の考え方やパターンに触れることができます。
その知見が正しいこともあれば、間違っているのではないかと思えることもあるでしょう。
それを2人以上のエンジニアがお互いに意見を交わしながら1つの実装を作り上げていくということに、多くの意味と意義があると思います。
コードレビューでもペアプロでも、よく言われるのが「意見の齟齬による衝突」だと思います。
そうなるのは、もともと実践の理念が間違っている可能性がありそうです。
レビューやペアプロは指導ではありませんし、どちらかがどちらかを誘導するようなものでも、ましてやどちらかの正統性を主張するツールでもありません。
技術的な客観論を交わすコミュニケーションを繰り返すことで、コードをより洗練させるためのものが、コードレビューでありペアプロ・モブプロだという考え方をするのがよいかと思っています。
そして、これらを通じてコード理解が深まり、ひいてはチーム全体の実装スキルの維持に一役買うことができるのではないでしょうか。
リファクタリングする
長く運用されていればいるほど、レガシーなコードは必ずと言っていいほど埋もれているものです。
特にリファクタリングを恒常的に回しているチームでない限り、レガシーコードの残存リスクは高いといえるでしょう。
そしてリファクタリングをするには、現在のコードを理解する必要があります。
古いコードの何が悪くて、どのようにすれば「良い」とされるコードに変更できるのかの判断は、リファクタリングを通じて獲得できることも多いでしょう。
ユニットテストコードを書く
リファクタリングと同様に、ユニットテストを実装することでも、そうしうた経験を得られると思います。
ユニットテストの実装は、プロダクトにとって大きな価値を持つコードにもなることを考えると、実装に触れ続けながらプロダクトに貢献するための1つの方法としてユニットテストコードの実装は有効なのではないでしょうか。
テスト駆動開発を実践されている場合は、すでにテストコードがあたりまえの存在ではありますが、テストコードのレガシー化を回避するためにユニットテストコードを見直すことも有効な策かもしれません。
好きで居続ける
なにより、この業界、この分野、もっと狭い視野で言えば、設計もプログラミングも何もかもが好きである、ということが根底には必要だと思います。
仕事として割り切ったとしても、興味のないことを続けるのは苦役以外の何者でもないでしょう。
クリエイティブで専門性の高い分野の仕事に就いているということは、まったく何も興味がないことはないと思います。
技術系の経済新聞が紹介するような大局的な話題の獲得も必要ではありますが、たまには大型書店の専門書籍の棚に赴いて1冊手にしてみるのも悪くないと思います。
健康でいること
心身ともに健康でいられる(健康だと思い続けられる)ことが大切かもしれません。
不安の渦中で新しいことにトライしたりすることは難しいでしょう。
さてさて。
ここまで、延々ダラダラと昭和のおじさんの世迷言を書いてきてしまい、失礼しました…。
いずれにしても「やっぱ私は技術が好きだ」と胸を張って言うことができれば、廃れたエンジニアになるのはまだまだ先だと言えるかもしれません。
「なんだ、最後まで精神論かよ」
と言われるかもしれません。しかし人は論理だけでは生きられません。感情の生物である以上、どこかで精神的に突っ張る・引っ込むの話はせざるを得ないでしょう。
無理をしろというのではありません。私は無理はキライです。
しかし、もし無理なく好きを続けられる余裕があるのであれば、ちょっと精神論に傾いて、努力と根性で向き合ってみることも大切なのかな、と思っています。
私もこの記事がウソツキとならないよう、日々鍛錬し続ける所存です。
プログラミングもサーバもフロント(チョトだけ)もインフラ(オンプレ中心)もwebもゲームも組み込みも幅広く何でも雑多にやってきた古株ですが、フルスタックではありません。好きなものはプログラミングと計算機科学。我々と一緒に好きなプログラミングを楽しみませんか?