239
120

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

アイレット株式会社Advent Calendar 2024

Day 12

10年のエンジニア人生を振り返り、その中で本当に大切だと思ったもの

Last updated at Posted at 2024-12-12

はじめに

こんにちは。ようやく涼しくなってきたと思ったら、あっという間に年末ですね。

年末を意識し出して、ふと思ったのが「そういえば、俺ってもうエンジニアになってから10年が経つんだなぁ」ということです。

私はIT未経験の大卒からエンジニアとしてのキャリアを歩み始めました。そして、気づけばあっという間に10年が経とうとしています。10年というちょうど良い区切りで、エンジニア人生を振り返り、自分の経験の中で本当に大切だと感じたことを言語化していこうと思います。

ほとんど自分のための記事ですが、これがどなたかのキャリアに少しでも良い影響を与えることができれば嬉しいです。

お前誰?

と思うので、自己紹介がてら私のキャリアを紹介します。

大学と就職

大学は理系でしたがIT系以外のことを専攻していました。就職活動でITについての可能性を感じて(というより採用人数が多くていいなというくらいの浅い考えだった気がする)、IT系の企業を志望するようになりました。

1社目 : SIerにてオンプレインフラエンジニア (5年ちょっと)

就活でご縁をいただいた会社に入社しました。その会社は業界では規模の大きいSIerの会社で、インフラエンジニアとして現場に配属されました。オンプレのサーバ周りを担当して、5年ちょっと働かせていただきました。

オンプレ周りをやられた経験がある方は共感しやすいかと思いますが、当時はAWSなどのパブリッククラウドの台頭が著しく、このままオンプレをやり続けても良いのかという漠然とした不安がありました。またエンジニアなのにコードを書けないというところにも負い目を感じていました。

2社目 : ベンチャー企業にてソフトウェアエンジニア (即死)

オンプレをやり続けていても良いのか、アプリ開発にも挑戦してみたいと悶々としていました。そこでホリエモン信者だった私は「変化を恐れるな!」と言うホリエモンの言葉に背中を押されて、これまでと全く違ったことをやろうと決意しました。そしてソフトウェアエンジニアのポジションでベンチャー企業に転職をしました。結局、数ヶ月間という短期間で辞めることになります。

オンプレのインフラしか経験のないエンジニアが、ベンチャーというスピーディーさが求められる環境でソフトウェアエンジニアとして働いていくことについていけませんでした。自分の不甲斐なさに絶望しながら、次に何をやるか考えて、今までのキャリアと親和性のあるクラウド特化のインフラエンジニアになることを決意しました。

3社目 : アイレットにてクラウドインフラエンジニアなど (現職、4年目)

そして今の職場であるアイレットに入社いたしました。最初の2年ほどはさまざまのSI案件にてAWS周りの設計/実装/運用を担当しました。そのあと自社プロダクト開発案件にジョインして、アプリケーション開発およびインフラ、監視運用保守などの幅広い領域を経験することができました。案件外ではブログ投稿や登壇などの活動を行い、AWSのTop EngineersおよびAmbassadorsといった称号をいただくこともできました。

こんな感じのキャリアです。決して褒められるような華々しいキャリアではなく、ユニークというわけでもないです。それでも自分なりに色々考えて、チャレンジしてきたキャリアではあるのかなと思っています。

そのキャリアの中で特に大切だと思ったものを10個紹介していきます。

1. 目的意識を持つ

エンジニアに限らず仕事をするということは、何かを成し遂げ続けるということなのかと思います。

成し遂げることの粒度もそれぞれで、

  • 粒度大きめ : 「フルスタックエンジニアになる」、「プロダクトをリリースする」など
  • 粒度小さめ : 「タスクを終わらす」、「資料を作成する」など

何かを成し遂げるということにおいて、最も大切なものが「目的意識」だと思います。

私は、目的意識=なぜそれをやるのかを自分の言葉で説明できることだと捉えています。

ちょいと言っていることが抽象的すぎてイメージしにくいかと思います。なので、2つの異なる成し遂げを例にして、目的意識を持つことの大切さについて語っていこうと思います。

例1 : 資料を作成する

「資料を作成する」という粒度小さめの成し遂げのことを考えてみましょう。
「XXXについての資料をYYYYという観点でまとめて」という指示を上司から受けて、資料を作ることになりました。

この時、目的意識を持たずにいると、XXXXについてWebや文献などで満遍なく調べて、調べた内容を資料に落とし込んでいくという形になると思います。作る人の技量にもよりますが、目的意識なくして生まれた資料は「書いてあることの内容は理解できる。それで、この資料で何がしたいの?」ということになりがちです。

資料を作る前、「なぜこの資料を作るように上司に言われたのか」について上司に聞くなり/自分で仮説を立てるなりして目的意識を明確にもつことができると、聞き手にどのようなアクションを促したいかが伝わる資料作りができるはずです。目的意識が明確になると、目的から必要なものを逆算することができます。また、目的が明確なため、必要なものだけを調査して考察できるので、無駄なプロセスがなくなります。

例2 : フルスタックエンジニアになる

私は一時期フルスタックエンジニアを目指していました。
それはインフラしかできずアプリ開発ができないということに負い目を感じており、全部できるようになれば面白そうという漠然とした思いから来ていました。

こういった大きいことを成し遂げる場合、目的意識がないとブレブレになります

程度はさておき、フルスタックエンジニアになるのはかなり大変です。(ウェブ界隈であれば)フロントエンド/バックエンド/インフラの各領域で数年の実務経験が必要です。そしてフルスタックエンジニアになれば、それぞれの領域についてのキャッチアップを絶えずしていく必要があります。めちゃくちゃ大変です。

大変なことを成し遂げるにあたり、明確な目的がないと辛い時や壁に当たった時、踏ん張れません。

私はフルスタックエンジニアになる目的意識が曖昧であったため、ベンチャーでのソフトウェアエンジニアとして働くことに耐えられず、早々に退職することになりました。

目的意識が明確でなければ、大きなことを成し遂げることは難しいことを実感しました。

2. 本質を掴む

ITの世界では絶えず新しいテクノロジーが生まれます。そしてそんなITの世界でエンジニアをしていると、色んなことに手を出してみたくなります。

まだChatGPTなどの生成AIが台頭していない頃の話です。私は機械学習に興味を持ち、G検定やE資格をとったり、Kaggle(機械学習モデルの性能を競うコンテストみたいなもの)をやってみたりしていました。その他にも流行りのテクノロジーに表面上だけ触れて、チュートリアル的なものをやって、できた気になっていました。

ぶっちゃけ、そういった表面上の薄っぺらいことをやっても、ほとんど自分の身になりません(引き出しを増やすという意味では意味があるとは思います)。表面上で理解していることを実務で取り扱っていると、すぐにボロが出ます。ググってわかる範囲であれば手が動きますが、何かエラーや問題に遭遇して、ググっても解決策が見つからない時に手が動かなくなるのです。

要するに応用ができていない訳です。そして応用ができないのは基礎の徹底ができない、すなわち本質を掴んでいないからです。基礎を徹底的に押さえることで本質が掴めるようになります。本質を掴むとそのテクノロジーがどのような仕組みで実現されているかなどを理解でき、応用的なことができるようになります。

本質を掴むのには多くの時間がかかります。

公式ドキュメントなどの文献を読み込む、さらにその分野の時系列や歴史の理解し、実務レベルで手を動かす。これを繰り返して、ようやく本質を掴むことができると思います。他人のブログを少し読んで、チュートリアルをしたぐらいでは本質を掴むことはできません。

エンジニアに求められる能力の中に「新しいテクノロジーを素早くキャッチアップする能力」があります。これに本質を掴むことが必要不可欠です。

Webアプリ開発を例にして説明します。昨今のWebアプリ開発に欠かせないものがフレームワークです。RailsやLaravelなど、多くのフレームワークがあります。現場や担当者の指向によって利用するフレームワークは異なるので、開発者は複数のフレームワークを取り扱う必要があります。そこで新しいフレームワークについてキャッチアップする時のことを考えます。

Webアプリのフレームワークの本質の1つの要素としてWebの仕組みを理解することがあると思います。Webの仕組みを理解せずに、フレームワークの文法や使い方だけを理解しているだけでは新しいフレームワークのキャッチアップをするときにほぼ0からはじめることになります。

Webの仕組みをきちんと理解していると、フレームワークがWebアプリケーションの中でどのように動いているかをイメージできるようになります。それをイメージできるようになると、今まで触ったことのない新しいフレームワークを素早くキャッチアップできるようになります。

生成AIと共に生きる時代において、本質を掴むことが難しくなってきている気がします(難しいというより、本質を掴まずともできることの範囲が生成AIによって広がってしまったため、本質を掴むことの意義が希薄になっているような感覚です)。そんな時代だからこそ、本質を掴むことを徹底していきたいと強く思います。

3. 継続する

上で本質を掴むことが大切と言いましたが、本質を掴むためには継続することが大切です。(大切なことがネストしてる....)

「継続は力なり」という有名な言葉があるので、継続することが大切ということをほとんどの人が認識しているはずです。そんなことわかりきっていることですが、私は実際に継続することの大切さを身をもって感じたので、ここで掲げていきます。

すぐに得られるものは、すぐに陳腐化します。また誰でも得ることができるので、市場価値もありません。
普遍的であり市場価値の高いスキル/経験というものは、継続し続けることでようやく得ることができるものであるはずです。

先ほどの本質を掴むの話で

まだChatGPTなどの生成AIが台頭していない頃の話です。私は機械学習に興味を持ち、G検定やE資格をとったり、Kaggle(機械学習モデルの性能を競うコンテストみたいなもの)をやってみたりしていました。その他にも流行りのテクノロジーに表面上だけ触れて、チュートリアル的なものをやって、できた気になっていました。

と私の体験談を語りましたが、これは私が継続することから逃げていたという意味も含んでいます。

継続して1つのことに取り組んでいくのは、時間が必要だし、忍耐力もいるし、地味です。ついつい新しいことに手を出して、継続することから逃げたくなります。自分自身もそうなった経験がありますし、そうなった人をたくさん見てきました。

何かの拍子に自分の人生が急激に良い方向へ変わるのは宝くじに当たるようなものだと思っています。まずあり得ません。人生が良い方向に変わるのは、何かをコツコツ継続していき、ふと気がついたら良くなっていた!というのが実体だと思います。すぐに結果を求めてはいけないのです。

そして継続することの面白いところは、効果を一度実感できると、継続していくことが苦にならなくなっていくことです。

筋トレを例にするとわかりやすいです。続けていくのは辛いしダルいけど、自分の体がちょっとずつ変わってきていることを自覚し始めると、継続することの価値を見出すことができるようになります。そうすると継続し続けることができるのかなと思います。ただし、鏡の前で自分の体を見てニヤニヤしているのは気持ち悪いので、それはやめましょう(自戒を込めて)。

4. やらないことを決める

私は「やりたいことが見つからない」とずっと悩んでいました。そして今も悩んでいます。エンジニアが自分にとってやりたい仕事なのか、それすらよくわかっていません。エンジニア以外で何かやりたいことがあるのでは?と常々考えてしまいます。

またエンジニアという括りの中でも、インフラではなく他にやりたい分野/役割があるのでは?とも悩んでいます。やりたいことを見つけるというのは、資本主義における共通の課題なんじゃないかと疑っています。

これは主観ですが、やりたいことが明確になっている人ってあんまりいないんじゃないかなーと思います。それくらいやりたいことを明確にする、見つけるって難しいことだと感じています。

やりたいことが明確ではない、でもやりたいことを見つけなきゃいけない、そして色々なことを手当たり次第やっていくと全てが中途半端になります。

私はこれまでの経験を経て、やりたいことを探すことも大切だが、それと同じくらいやらないことを決めるのも大切だということに気がつきました。

やってみて、これは違うなと思ったことには「やらないラベル」を貼ります。そうすれば迷いが減り、同時にストレスも減ります。ちなみに私は「フルスタックエンジニアを目指す」は絶対にやらないと決めています。

フルスタックエンジニアを目指さないと決めた背景として、実際にインフラに加えてフロントエンドとバックエンドに手を出してみて、「全ての領域を深掘りして、さらにキャッチアップを継続していくなんて、時間がいくらあっても足りない」と感じたからです。そう思ってからはインフラを自分の専門分野として、バックエンドは最低限わかるようになっておこう、フロントエンドは捨てようと線引きするようになりました。

このように線引きすると、以前までは気になっていたフロントエンドの新しいフレームワークやアップデート情報などを気にすることはなくなりました。そして自分のやるべきことである、インフラとバックエンドへ注力できるようになりました。

やりたいことが見つからない人は、やらないこと決めていきましょう。ただやらず嫌いは良くないと思うので、一回試してみて、違うなと思ったらやらないと決めていくのが良いかと思います。

5. 記録を残す

記録を残すことによるメリットは計り知れません。

  • 備忘
  • 成長を実感できる
  • 建設的なPDCA

まず初めに言っておきたいのが過去の自分は他人であるということです。人はすぐに自分の考えたこと/言ったことを忘れてしまいます。将来の自分に向けて、考えたこと/言ったことの記録を残しておきましょう。それが自分にとっての大きな助けになるはずです。この記事を書いたのもそんな狙いがあります。

また、記録を見返すと自分の成長を実感できるというのも記録を残すメリットです。以前はこういう考え方をしていたのに、今はこういう考え方をすることができている!という感じで、自分のことを時系列で相対的に評価することができます。

(唐突ですが)私はジムへ行った日にInBodyという高性能な体重計のようなものを利用して、体重などをアプリで記録管理しています。これを見ると、自分の体重が減っていること、筋肉量が増えていることを実感することができます。これにより自己肯定感が上がり、仕事などのやる気も出てきます。

また記録をつけることで反省や改善が建設的になります。自分の業務の反省と改善を行うときに、記録をつけていないと「なんか時間が足りなかったので失敗した。」みたいなフワッとした反省しかできません。記録をつけていると「XXXを行った際に、YYYYが理由で時間が足りなかった。そのため失敗した。」のように踏み込んだ反省ができるようになります。

逆に記録を残すことのデメリットってなんでしょうか?めんどくさい/時間がかかるということくらいだと思います。記録を残すことのメリットを実際に体感してもらわないと、メリット>>>デメリットであることを実感できないので、まずはメリットがわかるようになるまで記録を続けていきましょう。メリットがわかれば、無意識に記録することができるようになります。

6. フィードバックをもらう

ある成果物を作った後に、どんなに時間をかけて見直して/考え直しても、自分には気付けないものが必ずあります。
主観的/客観的と言う言葉があるように、自分だといくらやっても主観の枠からはみ出ることはできません。

主観的な視点と客観的な視点からブラッシュアップしていくことが、高い質の成果物を生み出すために必要です。なので、自分が生み出した成果物(コード、プレゼンの資料、設計書etc...)は他人からフィードバックをもらって客観的な視点で評価してもらいましょう。上司から「見せて」と言われる前に、自分から「見てください」と言えるようになりましょう。

なるべく多くの人にフィードバックをもらった方が良いですが、時間との兼ね合いもあります。最低1人からはフィードバックをもらうように心がけましょう。大事な成果物の場合は多くの人からフィードバックをもらえるように働きかけましょう。

フィードバックをもらうことに抵抗を感じる場合、その理由の一つに「自分の至らないところを指摘されるのが怖い」というものがあるかと思います。私は豆腐メンタルなので、自分のダメなところをほじくられるのが怖いです。でもフィードバックを受けずに、主観でしか評価していない成果物をそのままにしておくことのほうがもっと怖いことに気がつきました。

勇気を持ってフィードバックをもらいにいきましょう。

7. 他人に期待しない

ちょっと棘があるような言葉ですが、これは要するに以下のように捉えていただければ良いのかなと。

  • 他人からの見返りを求めない
  • 他人を変えられると思わない

見返りを求めないということについて、他人に見返りを求めるようになると、損得勘定で動くようになります。また、思ったような見返りが返ってこないと、次第に他人を思いやるなどができなくなってしまいます。意識高い系の本とかYoutubeにて、成功者の人が「Giverになりなさい」と言っているのを聞いたことありませんか?見返りを求めていると、Giver(他人に何かを与えられる人間)にはなれません。

10人のために何かやってあげて、1人からでも返ってきたらラッキーと思うくらいの心構えでいましょう。もしくは「他人に何かやってあげてる俺、かっちょいい」という自己満の気持ちで他人にGiveしていきましょう。

チャンスなどが舞い込んでくるのは普段見返りを求めずにGiveしている人だと思います。後から思い返すと、見返りを求めず他人に何かしてあげたから、あの時の機会をもらえたなと思うことが多くあります。

また、他人に期待しない=他人は変えられないという意味もあります。他人に期待して色々してあげた結果、自分の思ったように動いてくれず、勝手に失望してしまいます。そうすると感情などにもネガティブな影響が出てしまい、人間関係などを悪くしてしまいかねません。

他人を変えようとすること自体は良いことだと思います。ただ結局他人が変われるかどうかはその人次第です。なので「変わってほしいけど、まあ変わらなくてもしょうがないか」くらいの感覚でいると良いのかなと思います。

8. 常に謙虚でいる

キャリアを積んでくると、自分よりも年次や経験が下の人たちが増えていきます。そのような環境において、決して傲慢になってはいけないです。周りから面白いくらい人がいなくなります。他人を見下したり、自慢したり、技術マウントをとるような人には誰も近づきません。

人間って一人でできることって限られているんですよね。何か大きなことを成し遂げたり、成果を出したりするには必ず他人の協力が必要不可欠になります。他人の協力を得やすいように、普段から謙虚でいることを心がけましょう。

自慢するのではなく、他人を褒める癖をつけましょう。私は常に自分が一番下っぱくらいの感覚でいたいと思っています(それはそれで極端な気もしますが)。

9. 悪口を言わない

まあ、ありきたりなことですね。でも私含めて多くの人ができていないと思います。

悪口を言うと、その人がその悪口を聞いたわけでもないのに、自分自身がどことなくその人に対して後ろめたい気持ちを持ってしまいます。自ら後ろめたい気持ちを持って、その人とギクシャクしてしまうのです。悪口を言わないと自ら他人とギクシャクすることはなく、苦手な人/嫌いな人とも変に関係を壊すことがないはずです。

言霊という概念がありますが、悪口は言霊の典型例だと思います。悪口を言い続けることで、その人のことに対するネガティブな気持ちが勝手に増長されていく気がします。そして自分自らその人との関係を悪くしてしまいます。

また、苦手な人/嫌いな人が思いもよらない良いチャンスを持ってきてくれることが多々あります。

正直、悪口にはストレス解消という効果はありそうです。しかし、それ以外には悪い効果しかありません。悪口を言わないようにしましょう。

10. 認知してもらう

これが最後です。

他人から良い意味で認知してもらうのは、仕事を楽しく快適にこなしていくために大切だと実感しています。

もともと私自身、あまり人前に立ったり、目立ったりすることが好きではありませんでした。ただブログや登壇などを行なっていく中で社内外に知り合いが増えて認知されていくと、仕事に良い効果が出ていることに気がつきました。

良い効果の1つとして、社内外から色々なチャンス/機会が自分のもとに舞い込んでくるということがあります。私がAWS Top Engineers/Ambassadorsと言う称号をもらったのも、認知された結果舞い込んできた機会だと思っています。

良い効果としてもう一つあるのが、認知されると仕事が楽しくなるということです。良い意味で認知される=信頼されるということだと思います。信頼されると自分の裁量でできる範囲が大きくなります。また他の人への協力などを求める際もスムーズになります。仕事がどんどんやりやすくなり、その結果楽しく感じるという流れです。

良い意味で認知されるのには、派手な活動はいらないと思っています。ブログや登壇などのアウトプット活動をコツコツ継続していると、次第に認知してくれる人が増えます。そしていつか多くの人に認知されているはずです。

認知してもらえるように継続してアウトプット活動していきましょう。

最後に

読んでいただきありがとうございます。軽い気持ちで書き始めましたが、気がつけば1万字近いハイカロリーな記事になっていました。後半になるにつれて疲れて、どんどん内容が薄くなってしまった感はあります。あと、たまたまですがエンジニア10周年ということで大切なことも10個ありました。

今後もキャリアを積んでいくと、新しく大切なものが見えてくる気がしています。
ひとまずこの記事の内容は10年目時点のものとして、15年/20年でも同じような形でどこかで吐き出すことができればと思います。

とりあえずそれまでエンジニアとして生活できているように、食らいついていかないと。

239
120
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
239
120

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?