20年経ったらこうなりました
20年経ったらこうなりました
エンジニア歴が20年になってしまいました。マネージメント側に行くわけでもなく、お客様または自社の望みを聞いて設計して作ってテストして運用する、ということを繰り返してきました。そんな私がどんなふうになったのかを書こうと思います。
これは20年経験した、いちエンジニアのサンプルとして見ていただけると嬉しいです。私を見習って欲しいという意図はさほどなくて、ずっとエンジニアを続けるとどんな風になるかをイメージできない方々に向けた事例をひとつ提示してイメージするお手伝いができたらいいなと思って書いています。私が続けられたコツのようなものも書いていますが、参考になるかはあまり自信がありません^^;
どうぞ気楽にお読みください。
現在の私の立ち位置
私は現在、ベンチャー企業株式会社ゼタントのシニアエンジニアという肩書でフルタイムのリモートワーク勤務をしています。それと入社前からフリーランスとしても継続して活動しています。自社サービスの展開を目指して試行錯誤を続けていて、少人数なこともあり様々な分野に触れて開発の日々を送っています。
20年エンジニアとしてやってこれてはいますが、特に優れているわけでもない、というのが自己評価です。周囲には、エンジニアとして到底及ばないと感じる人が割と多くいます。ただ、そんな人たちに近づけるようにほんの少しずつだけ努力しています。止まったら終わる、という危機感はずっと持っているように思います。
意識していること
-
英語の文法の勉強を継続する
-
公式ドキュメントを頼りにする
-
入門書は3冊読む
-
頑張らない
-
答えてもらいやすい質問の仕方
英語の文法の勉強を継続する
仕事の開発においてエラーは必ず潰すべきもので、開発はエラーとの格闘と言ってもいいかと思います。エラーの原因は様々で、解決するにはエラーメッセージを元に検索したりドキュメントを調べたりすることとなります。ここで英語の資料にも向かっていけるのといけないのでは、自己解決力に大きな違いが生まれます。
英語の資料の苦手意識をなくすには、英語の文法を理解して体に馴染ませることが必要です。私は英語の文法のトレーニングをするために英作文.netを活用しています。日本語で示された例文を提示された単語を組み合わせて英文を作る問題が1セット30問程度で構成されていて、スキマ時間に学ぶのにちょうど良いので気に入っています。
公式ドキュメントを頼りにする
やりたい処理の実現方法やエラーの対処方法を調べると、検索結果の中でよくstackoverflowやQiitaなどの記事を見てしまいます。見やすい気がする一方で、情報が古かったりドンピシャな回答でないことがあったりして、思いのほか時間がかかってしまったりすることがよくあります。
結局は使っているツールのバージョンに合った公式ドキュメントをよく読むことで、求める答えが比較的短時間でわかることが多い気がしています。
入門書は3冊読む
新しい技術を知るためにやっていることで、私はその技術の入門書を3冊買って読むようにしています。Kindle書籍の人気の入門書を上から3つ買って読んでいます。同じ本を3回読むよりは、異なる本を3冊読んだ方がより理解できると感じています。
同じ事柄でも、違う書き手が違う表現方法で記述したもの読むことで、多方面から認識できてより深く理解できると思います。最初の一冊目は何を言っているかわからないことでも、2冊目3冊目の別な表現を読むことでだんだん理解できてきます。3冊も読むと大概のことはちゃんと理解できるようになります。
頑張らない
しんどい時はすぐに休むことにしています。辛い時にやっても実りは少なく、逆に集中力を欠いてしまって、やるべきことをすっ飛ばしてしまったり後回しにしてしまって、それを取り返すのに余計に時間がかかってしまいます。しんどい状態が続くとメンタルにも響きます。メンタルに響くとエンジニアを長く続けるのは難しいとお思います。
気にしていないこと
-
使っていた技術を忘れてしまうこと
-
効率の悪さ
-
自分のできなさ加減
使っていた技術を忘れてしまうことは気にしない
新たに新しい技術を使って仕事を進めると、新たな技術の知識が増えていきます。その一方で私はすぐに前に使っていた技術を忘れてしまいます。これを気にしないことにしました。優れた技術者は覚えた技術は長く忘れないのかもしれません。忘れてしまうものはどうしようもないんですもの。なので気にしないことにしました。
忘れるとは言っても特徴などは覚えているので、再び使うことになったら3冊の入門書を読み返すことで大概の記憶は蘇ってきます。
効率の悪さは気にしない
コードを書くうえで、効率の悪さは気にしないことにしています。ここはエンジニアとして優れているかそうでないかの力量が現れる部分だと感じています。なのに効率の悪さを気にしない私はすでに優れていないエンジニアに分類されてしまいますね。
ですが、私は効率の良いコードを書くことよりも、まずはきちんと動作するコードを書き上げることに意識をおいています。効率を考えるのは、動作するコードができた後にしています。納期が存在するので、効率化まで手が回らずじまいになることもあるのですが。。
なのでスケジューリングでは、なるべくリファクタリングの時間も含めるように努めています。
自分のできなさ加減は気にしない
人にはそれぞれ向き不向き、好みや耐性の違いがあります。私の弱点部分が別の人だと強かったりします。でも、その別な人にもまた弱点はあるものです。まれにスーパーマンも存在しますが。。弱点はチームの誰かが補えば良いのです。個人でやっていてもMENTAのようなサービスがあります。補う方法はあるのです。
マイナス面に囚われると、長くエンジニアを続けるのは難しくなります。できないことは誰かに頼もう、というマインドを持つことが大切だと思います。
できるようになったこと
-
初見の言語でもひとまず動くものを作れるようになった
-
大概のことは自分で調べて解決できるようになった
初見の言語でもひとまず動くものを作れるようになった
仕事によっては使う言語が決まっているものがあります。最初の頃は知らない言語を理解して使えるようになるまで何ヶ月もかかった上に、あまり動かないようなものしか作れていませんでした。ですが、言語を3つ4つと知っていくうちに、どの言語も核は似たようなものだと理解できました。
特徴や特性はそれぞれ違いますが、その部分の差異のみ理解しようと心がけることで言語の使い方は素早く理解することができるようになりました。現在では3日もあれば言語を理解し、ひとまずは動くものを作れるようになりました。仕事で一度使ってしまえば、次からはこれまで覚えた言語と同じ感覚で使えるようになります。
大概のことは自分で調べて解決できるようになった
調べ方に慣れてしまいさえすれば、やりたいことの実現方法やエラー対処などは大概調べるとどこかに書いてあるもので、ほぼ自分で解決できるようになります。ただそれが効率的なやり方かどうかは、その人の資質や経験などによりだいぶ変わるものと思います。私は効率的に、という意識は割と後回しにしてしまっているため、この点については劣っていると感じています。
それでも、自分でやり遂げられるという感覚が身につくとエンジニアとしての自信が持てるようになります。もちろんどれだけ調べても思った通りの動作にならない場合もあります。例えば言語のバグは滅多にみることはありませんが、外部ライブラリに潜んでいたバグが原因で動かなかったことがあります。どうにもならない時は回避策を考える、という発送の転換も大事です。
未だに身についてないこと
-
素早く作れない
-
仕事がマルチタスクになると効率がガクンと落ちる
素早く作れない
ソフトウェアを素早く作る、ということが未だに苦手です。苦手というよりはできない、かもしれません。素早く作るには、ソフトウェアを効率的に作るために必要なことが自分の中で整理できている必要があります。これは経験だけでは獲得しづらいことかもしれません。個々の能力に依る部分が大きと感じます。これができない場合は、作業を端折る、という方法で実現してしまいがちです。
端折ると、結局はどこかしらボロが出てきてそれに対処するのに時間がかかり、結局は素早く作れない結果となってしまいます。ですので、私は素早く作ることは二の次にして、時間が多少かかろうともきちんと段取りを踏んで作っていこうと心がけています。
仕事がマルチタスクになると効率がガクンと落ちる
複数の仕事が同時に走ると、私の場合、作業を切り替えた時にどこまでやっていたかを思い出すのに時間がかかってしまいます。切り替えが頻繁になるともうほとんど仕事していないのと同じようなスピードになってしまいます^^;
これは未だに対処法が自分で見つけられておらず、できるだけ作業を細かく切り替えないようにだけ気を付けるようにしています。とはいえ、緊急の対応が求められることはよくありまして、そんなときはひと段落ついたら休むようにしています。貯まったストレスのガス抜きです。
業界に残るために身につけると良いこと
-
人に見てもらう
-
勉強会にでてみる
-
背負い込まないこと
人に見てもらう
人に見てもらうことは、自分では気づかなかった点や新たな視点を得られる良い機会です。これを行う行わないでは、成長に大きな差がつくと感じます。会社ならば先輩や上司に見てもらう機会があるでしょうが、独学中やフリーランスの方々は意識して求めないと機会が得られません。
勉強会やMENTAを活用してそのような機会を増やすことを心がけると良いと思います。
勉強会にでてみる
勉強会は、新たな知識が得られる他にも、同業または同じ関心を持つ方たちと知り合える良い機会です。人と知り合い刺激を受けることでモチベーションが高まったり、仕事の紹介を得る機会があったりします。
実際に私も地元山形のエンジニア向け勉強会に参加しています。地元エンジニアはもちろんのこと、デザイナーや非エンジニアの方々が集ってお互いの得意分野を発表して学び合っています。勉強会が縁で転職につながった方もおります。現在は情勢を鑑みてオンライン開催となっていますが、顔をあわせて学びあうことはいい影響しかないです。
背負い込まないこと
わからないということは心に負荷がかかりストレスとなってしまいます。ストレスは長くエンジニアを続けるにあたっては大敵です。適度なストレスは成長の栄養にはなりますが、大きすぎると毒になる困りものです。自分の許容値を知って、それを超えそうな時は周りに助けを求めるべきです。どうしようも無くなったら、そこから離れることも考えてもいいと思います。
MENTAにいるメンターさんは、そういう経験を超えてきた方々だと思いますので、まずは相談してみて欲しいと思います。もちろん私もお応えいたします。
学び始めた皆さんへ
プログラミングなどの技術を学ぶことはハイハイしている段階と例えることができると思います。歩むという意味では、何かを作り始めることこそが最初の一歩だと思います。何も学びきってから一歩を踏み出す必要はありません、学びながらでも踏み出すことはできます。
是非、一歩を踏み出してエンジニアの世界に飛び込んでいただきたいと願っています。つまづいたらここには多くのメンターがいらっしゃいますので、私たちを頼っていただければ喜んで支えます。