40歳過ぎても仕事がなくならないエンジニアになるには

こんにちは、やまです。

先日、40〜60代のSES, SIerの案件オファーが減り始めたというニュースを見ました。

年齢が上がるにつれて、案件獲得のハードルが高まっていると。

年収や単価など条件が下がったという声もあるみたいですね。

これ、生成AIが開発フローに組み込まれた現代は、フリーランスも概ね似たような傾向になるだろうなと感じています。

見た記事でも、そういった方々自身も年齢を主要因に自己分析しているようだったのですが、

僕はちょっと違うだろうなと考えています。

僕がご一緒するエンジニアの中に40代後半、50代の方もいらっしゃいますし、

周りから「知見が深い人」として、とても頼りにされています。

一方で、40代でも「あぁ、もしかすると読んだ記事に当てはまるかもな」と感じる方もいらっしゃいます。

違いはどこから来るか?

年を取るにつれて案件のハードルが上がる人と、

それどころか頼りにされていて、これぞ年の功と感じられる人。

僕の周りから聞く話と僕の観測範囲内ではありますが、一つはっきりとした傾向があります。

  • 頼りにされ年齢をハンデどころか年の功と言われる人は自分から課題を見つけてガンガン提案する
  • 逆な人は指示・依頼のあったことをやるのみ

前提として、企業様は年齢自体を気にしているのではなく、「自社をより良くしてくれそうか」を見ており、

「高齢だから」アウトではないという点ですね。

そして、違いは上述のように能力以前のスタンスに違いがあるということですね。

能力があるから、そういうスタンスが取れるのでは?と思うかもしれませんが、そんなことはありません。

できるからやる、ではなくやるからできるようになると感じます。

課題を持って解決に向けて試行錯誤する。

分からなければプライベートで学んで知識をつける。

僕がご一緒した周りから一目置かれる40代のエンジニアの方でも

最初から何でも知っていて颯爽と解決できるスーパーマンではなく、

皆「この課題、解決したいよなぁ」と課題意識を持つことから始め、

「こうしたら解決できそうかな」と試したり、

「ちょっとこの辺りの知識薄いから学ぼう」と調べたり。

そういった解決までの過程で力をつけていくことが多いですね。

そして、それまでのプロセスの積み重ねが知見として蓄えられていきます。

一方で指示のあった開発を行うだけの人は、肝心な「課題発見・改善力」が身につきにくくなります。

企業が評価する、実際に現場で役立つのは「自分事として提起し、考え抜いて解決した経験」ですね。

指示のあったタスクは自分起点で考えたものではなく、もう既に他の誰かが見つけた課題であり、

それをこなすことは考える範囲がそのタスクを完遂することに限定されやすくなります。

何より今の現場でも、その先の現場を変える際の面談でも「指示がないと動けない人」という印象がついてしまいます。

雇う企業様からすると、ガンガン改善に向けて動いてくれるエンジニアに期待しますし、

実際そういう人に高い金額を出します。

「そうは言っても、もう高齢だし…」と感じるかもしれませんね。

今からではもう遅いとかつて僕も思ったものでした。

僕はアラサーから未経験でエンジニアを目指し、エンジニアになりましたが、

28歳目前まで仕事もできなくて月収も20万円で、

30歳に近づくにつれて、とても怖かったのをよく覚えています。

そんな僕が今は月単価110万円でエンジニアをやっており、

ありがたいことに「やまさんがいてくれて、本当に助かる」と言っていただくことが増えてきています。

もしあの時、年齢を言い訳にエンジニアになろうと動き出さなかったら

今でも低月収で毎日出社して、気持ちを消耗しながら仕事していたかもしれません。

僕の知り合いにも40代のエンジニアの方でアラフォーからエンジニアデビューし、

経験3年半で月単価80万円のフリーランスの方がいらっしゃいます。

アルバイトから始め、フリーランスになっても時給1400円だったそうですが、

諦めずに成功しているエンジニアから学び、「自分から」提案することから始め、考えることを続けてこられたそうです。

年齢でブレーキを踏むのはとても勿体無い。

人生で今日が一番若い日。

変わりたいと思ったその日から行動し始めて全然OKですね。

どんなに小さなことでも、「ここもっと改善してみませんか?」と提案することから始めてみましょう。

それが習慣になれば、提案がデフォルトになりますよ。

今回お話しした指示待ちを脱却して自分からより良くする動きで評価が変わった話は

次の記事でもお話ししているので、よろしければ是非ご覧くださいませ。

また、僕のメルマガでは、このような提案ができるようになるための考え方、マインドセットを発信しています。

周りから頼りにされ、稼げるエンジニアになるヒントをお伝えしていきますので、よろしければぜひチェックしてみてください。

「ちゃんと仕事しているのに評価されない…」の正体 評価される人は何が違うのか

こんにちは、やまです。

僕はかつて、28歳で月収20万円だったのですが、その頃毎日思っていたことがあります。

いまいち評価されている感じがしない、と。

「ちゃんと真面目に仕事しているのに…」

「タスクもきちんとこなしているのに…」

「ミスもあまりしないのに…」

もしかすると似たような方もいらっしゃるかもしれませんね。

毎日タスク管理ツールを見て、依頼のあったタスクをこなして、PRを出してマージする。

目立ったバグも出しているわけではない。

なのに評価も単価も上がらない…

一方、技術力は自分と同じか、むしろ自分よりも低いと思う人が評価される。

現場で「あの人に相談しよう」と頼られ、リードエンジニアにも抜擢される。

「実力は大して変わらないのになぜ…」と思うかもしれませんね。

ですが、頼られる人、次のような動きをしていませんか?

「ここを改善すると、よりチームの連携上手く取れそうですね」と提案したり、

「Flakyテストを放置していると全体の開発効率を損ねてしまうので、自動で直す仕組みをAIで作ってみました」と解決策まで提示したり。

タスクをやる以前に「現場がより良く回るための改善」をしている。

そして、その積み重ねで信頼が蓄積され、経験年数は3年程度でもリードエンジニアを任されるのです。

このように評価は「頭を使っているか」どうかなのですね。

「ちゃんとミスなくタスクをこなしている」のは素晴らしいことですが、

残念ながら評価は「ちゃんとやってくれてはいるけど…それ以上でも以下でもない」

つまり、「ぜひ長期に渡って参画し続けてほしい!!」のような評価にはなりにくいのですね。

手が空くからタスクをただ振られるだけ。

新しい挑戦しがいのある課題を任せようという時に声がかからない。

結果、いつまでもタスクを振られてこなすだけで評価も単価も上がらない…

そして、このタイプの仕事はAIに真っ先にポジションを奪われやすいですね。

残酷ですが、AIの方が安く、作業も速く、文句も言わないわけですからね…

先述のように評価される人とされにくい人の違いが表れやすい場面を具体的に考えてみましょう。

例えば「ユーザーの通知設定機能を作ってください」と依頼があった時。

評価されにくい人はいきなり設計し始めます。

いきなりhow(手段)から入ってしまうのですね。

そして、いざ設計レビューに入ると指摘が多く入ってしまうのですね…

「通知設定はそもそもなぜ作るのか」

「その設定の仕方で本当にユーザーにとって便利になるのか」

「その通知設定は今後どんな展開の開発が行われる見込みか」

「次にこの展開が見込まれるなら、こう設計してしまうとSQLの発行が多くなってパフォーマンスを損ねないか」

「ループ処理で呼ばれると何度も同じ計算をすることになって非効率ではないか」

このように「言われた要求を実現する」以外の部分の思考が浅くなってしまうのですね。

そして、「すみません、考慮不足でした…」

私も経験があります。これ現場でかなり恥ずかしいのですよね…泣

しかも、これはレビューする側も背景や意図が掴みにくく、かなり時間がかかるので大変なのです…

それでは頼られる人はどうしているのか?

「ユーザー設定でこのような設定をしたい背景をもう少し聞きたいのですが、ユーザーのどのような課題を想定したものでしょうか?」

「このような仕様にできると、ユーザーにとって有益ですしシステムとしてもシンプルになりますが、いかがでしょうか?」

このように「設計する前に」聞ける。

聞いた瞬間、「お!この人ちゃんと考えているな」と思われる。

これを積み重ねるとPdMの方から「ぜひ仕様の意見を聞きたいです」と相談を持ちかけられるようになる。

設計書もコードも一行も書いていないところで信頼は動くのですね。

他にもCIのテストが遅くてとても開発をスムーズにできないとしたら速くする方法を考えて提案する等、

「自分以外の」開発効率を上げることを考えることを習慣づけると、

「この人はただタスクを振られてやるだけの人ではないのだな」と現場での扱いが変わりますね。

EMから是非〇〇さんの意見が聞きたいと相談が来たり、

フリーランスでもCTOから直接正社員オファーがあったり、

何か重要な意思決定, チームの方針の作戦会議に呼ばれたり…

頼りにされ、月単価も100万円を超え、日々充実した気持ちで仕事ができる。

これ、本当です。

月収20万円で毎日自分の存在意義が感じれらず、仕事も仕方なくこなしている…のような悩みと対極ですね。

「ここ、こう改善しましょうか」という言葉が景色を変えます。

タスクをこなすのではなく、提案と改善が自分を変えてくれます。

そして、AI時代に頼りにされる・活躍するのは「課題に気づける」人ですね。

AIは問題を「解く」ことは得意ですが、「提起する」ことはできません。

現場の文脈がわからず、人の指示があってこそワークするものですから。

問題を提起し改善案を提案できる人は手を動かしているのではなく、頭を使って考えている。

労力はむしろ手を動かして作業を大量にこなす人よりも少ないことすらありますが、

評価も信頼も集まり、収入も高いという状況が起きます。

強力な作業者であるAIがいる中で、人がバリューを発揮するのは

「ここ改善したいですね」

「こうすると改善できそうですね」

のような現場をより良くする動きですね。

作業者のままで評価も微妙なまま一生を終えるか、

周りから頼りにされ、気持ち良く働けて、十分な収入も得られるか

その分かれ目は「課題に気づく目」と「改善」なのです。

是非明日から「ここもっと良くできそうだな」と探すことから始めてみましょう。

課題に気づき、提案できるようになるためにどうすれば良いか?

これを日々の発信を通してお伝えするメルマガをやっています。

今回お話ししたような課題に気づくための考え方や現場の選び方をお話しするので、

ご興味のある方はぜひチェックしていただけると嬉しいです。

今やりたい仕事ができていないなら自分から変われば良い

こんにちは、やまです。

  • 目標があるけど、今の仕事で叶えられそうもない…
  • やりたいことがあるけど、現状とのギャップがあって辛い…

こう感じた時でも、自分から変わろうと動けば、望む方向に変わっていくという話をします。

僕は28歳で未経験からエンジニアになりましたが、
それまでは、セキュリティソフトの運用オペレータのような仕事をしていました。

あまりにも仕事ができなさすぎて、30歳近いのにいつまでも新人同然の評価で将来を不安に思ったものでした。

SNSで月80万円, 月100万円を稼ぐフリーランスエンジニアの方々を見て、皆、イキイキと自分のやりたいことを楽しみながら人生を過ごしている姿に憧れました。

そこからエンジニアに興味を持ち始めましたが、最初は何も行動できませんでした。

働いていた企業でも、プログラマの職種はあり、部署変更の希望を出すこともできたはずですが、「こんなに仕事できない奴が機会なんて与えてもらえないだろう」と言えずにいました。

転職活動やポートフォリオ作成など、エンジニアとして働きたいなら、さっさと自分から動けば良いのに、その努力を怠っており、ずるずると時間だけが過ぎていきました。

仕事もできない、やりたいこともできないと悩みが大きく辛く感じ、仕事自体せずに休んだ期間もありました。

行動せずに悩んでいた時期にSNSを見たり、有名な方の本を読んでいると、あることに気づいたのでした。

どんな成功者でも、皆、元々才能があったり、本人にとって望ましい環境でなかったとしても、自分から変わろうとできることは何でもやるということでした。

例えば、幼少期から貧しくて、社会人になってからも最初は月収20万円な状態でも、フリーランスとして独立できるように情報を集めたり、すでに成功している人から学んで数年で年収1000万円を超えた方。

他にも、知識もない、やったことがない仕事でも果敢に挑戦し、その度に「どうすればできるか」を考え尽くして成果を出して年収を上げていった方もいらっしゃいました。

そういった成功者の過去を知ることにより、僕はこう感じました。

「皆が憧れるような実績や生活をする方がこんなに努力しているのに、オレは何もしていないじゃないか」

「今の自分が不十分でも、できない理由探しじゃなくて、どうすればできるか、今持っている力でやれることはないか考えてやってみよう」

それまで逃げ続けていた心地の悪さが吹っ切れる感覚があったことを覚えています。

そこからエンジニアデビューに向けて行動を開始しました。

まずは情報収集として、どんな業界があるかや学習法やポートフォリオとしてどんなものを作ると効果的かを、エンジニアの成功者の方から学びました。

そして、平日は終業後3時間ほど、休日は寝食以外は全て学習とポートフォリオ作成をしていました。

この頃はちょうど新型コロナウィルスが流行り始めた時期で、未経験からの転職活動も苦労したことを覚えています。

トータル100社応募して2社から内定が出ました。

「こんな自分でもやればできるんだ」と嬉しくなりました。

また、内定いただいた企業様からも高評価をいただいたことから、もしかするとフリーランスでもやれるかもと追加で30社応募して1社からオファーをいただき、未経験からフリーランスエンジニアとしてデビューすることになりました。

初めて参画した案件は、振り返ると未経験にはハードルが高めだったと思います。

通常半年はかかる開発を3ヶ月でやってほしいと納期がとても厳しい受託開発でした。

その中でも未経験なりに最低限を考え、終電ギリギリまで実装を続ける日々を続けて何とかリリースしてきました。

その後もチームの回し方に課題を感じれば対策を考えたり、PMがラクになるように溢れそうなボールを拾ったりと

「やるべきと思ったことは誰かがやってくれると黙って見ていないで、自分から何でもやる」

という思いで動いてきました。

当時の僕の動き方はこちら

さらに業務以外の時間は書籍で設計やテストの技法を学んだり、既に成功されているフリーランスエンジニアの方から、活躍し稼げるエンジニアの考え方・ノウハウをお金を払って学んでいました。

やるべきことを精一杯やる。今の自分のできないならどうすればできるかを考える。わからなければ既にできる人から学んで実践する

これを続けていると、経験2年半で月単価105万円でオファーいただけるようになりました。

また、このようなマインドで仕事し、不足する力があればプライベートで身につけることを続けると、

企業様から「やまさんほど真摯に向き合ってくれる業務委託は見たことがない」と言っていただくこともできました。

今も価値提供して企業様に喜んでいただくために邁進しており、

そして、この情報発信を見てくださる方が前向きに行動しようと勇気が出るように記事を書いており、とても楽しいです。

もし、あの時に行動できていなくて辛いまま、エンジニア転職しようにもエージェントに登録するだけで、

自分から調べたり、ポートフォリオを作成・見ていただく努力をせずに、ただ待っていて、

「営業さんが良い求人を持ってきてくれない」と言い訳していたら、今も理想とのギャップに苦しむ毎日を送っていただろうと思います。

言い訳して行動しない時、一瞬は努力しなくても良いからラクですが、心は後ろめたさが残ると思います。

行動するのはほんの少しの勇気。

今でも僕は「自分にやれることは全てやったと言えるか?」と自問自答することを大切にしています。

目標達成のために行動するのは楽しいものですよ。

僕のメルマガでは、エンジニアで価値提供できるようになり、お客様に喜んでいただく楽しさを感じてイキイキと毎日を過ごせるようになるための考え方やノウハウをお話しします。

どんなに過去ダメダメだった僕でも月単価100万円超で、お客様に喜んでいただけるようになれた動き方ややってきたことをお話ししています。

もし興味がありましたら、是非チェックしてみてください。

一目置かれる技術力を持つ人に見られる明確な傾向

こんにちは、やまです。

僕が今参画中の企業で、経験20年近くのエンジニアの方がいらっしゃるのですが、その方の技術的な知恵の深さは目を見張るものがありました。

特にデータベース関連のクエリチューニングやパフォーマンス改善の力は、多くのエンジニアが求めているレベルと思いました。

他にも経験は5年程度だけど、フロントエンドのリードを任され、社内の新規開発のサービスの設計担当を任される方もいらっしゃいます。

僕自身は経験5年ですし、まだまだエンジニアとして道半ばですが、

ありがたいことに「10年くらいエンジニアやっているかと思った」「この若さでこの技術力の高さはすごい」と言っていただけることもあります。

一方で、経験10年、15年あっても指示のあったタスクをこなすのみの人もいます。

経験年数ではない、一目置かれる技術力を持つ人に共通している点は大きく2つあります。

  • 自分のタスクと関係がなくても、組織がピンチの時に積極的に行動する
  • 日頃から学びと個人開発による検証を行い、価値提供する準備をしている

チーム・組織がピンチの時、

自分のタスクと関係がなくても、当然かのように状況を把握し、改善案の提案まで行います。

先日、僕の参画中の現場での話です。

他チームが開発した機能でエラー率が高い不具合が出ました。

特別な指示はありませんでしたが、約半数のエンジニアが自主的に集まって調査・対応しました。

原因はデータベース(MySQL InnoDB)のトランザクション分離レベルの特性によるロックでデッドロックが多発することだったのですが、

他チームが開発したもので、当然最初は状況以前に実装の把握から始まります。

データベース周りのペインは企業でも課題に挙がりやすいため、僕は日頃から書籍や公式ドキュメント、個人開発で検証しており、

「もしかすると、事象の正体はこれかもな」とアタリをつけました。

そして、もう一人の有識者の方と一緒にログを確認し、再現方法がわかり原因を掴み、対応方針を話し合いリリースして解消しました。この経験から、現場内ではその有識者の方と共に「データベース周りの知見がある2人」としてCTO・EM・リードエンジニアから見ていただけるようになりました。

このように自分のタスクと無関係でも、組織がピンチの時は解決に向けて一緒に動くこと

その時に自分の考えを持てるように日頃から学び、検証など準備すること

これらを心がけ、日頃から行動を続けることで、

難しい局面での課題解決を経験し、結果として技術力が磨かれることになると思います。

チームがピンチの時、

どうせ役に立てない、足を引っ張るかも、力になれなかったら怖い等、

そんな気持ちよりも他者のために行動すること

その場で前に進められるように日頃から準備すること

学びと他者のために行動するペイフォワードな心が自分を高めてくれます。

もしピンチの時に見て見ぬふりをしたり、役に立てないと尻込んでいたら

大切な価値提供もできていないですし、知恵もつかなくて経年するだけで、

いつまでも指示のあったタスクをこなすだけのエンジニアになっていたでしょう。

信頼も高まらず、いつも自分の意見を大丈夫かなとビクビクしながら仕事している状況だったかもしれません。

僕も28歳の直前まで自分のことで精一杯で周りを見ている余裕はありませんでした。

でも、自分が関わるサービスをより良くするために「やるべきと思ったことは何でもやってやる!」という気持ちで臨むようになってから、成果が出始めて頼りにしていただけることが増え、結果として経験もできて技術力も上がったと思います。

経験2年半で月単価105万円でオファーをいただけるようになった一要因ですね。

有事の際に解決に向けて一緒に行動する

その時に自分で考えを持てるように日頃から自己研鑽に励む。

現場での信頼は日頃の行動の積み重ねですね。

小さな一歩で良いので、是非現場をより良くする動きを意識してみましょう。

行動の積み重ねが習慣になると、見えてくる風景が変わってきます。

PS. 僕のメルマガでは、活躍するエンジニアになるための考え方を発信しています。

もし興味がありましたら、是非チェックしていただけると嬉しいです。

月100万エンジニアも昔はコードレビューが怖かった話

こんにちは、やまです。

僕は今では月収100万円以上で設計や実装に苦を感じることが少なくなってきましたが、

駆け出しエンジニア時代はコードレビューされるのに常に緊張していました。

まだ設計を考えるのが不慣れだった頃、

レビューでの指摘が「自分の意見を否定された」と思ってしまい、よく落ち込んだのを覚えています。

  • 「また指摘されるのが怖いな…」
  • 「こっそりレビューが優しい人に依頼しようかな…」

そんなように考えていたこともありました。

ですが、今ではレビューを受けるのは「自分ではなく運用するチーム・組織のため」と考えているため、

怖いどころか、むしろより良い案があれば欲しいくらいに前向きに捉えられるようになりました。

皆さんにお伝えしたいのは、もし今レビューで緊張しても、むしろレビューを受け入れられるマインドになれるタイミングが来るということです。

レビューを前向きに捉えられるようになれたのは、大きく以下の3点が要因かと考えます。

  • インプットとアウトプットを繰り返し、設計の知見を増やしたこと
  • 設計に正解はないと知ったこと
  • 視座が上がったこと

それぞれ詳しくお話ししていきます。

まず、「インプットとアウトプットを繰り返し、設計の知見を増やしたこと」についてです。

先述の通り、僕は昔はレビューを受けるのが苦手だったのですが、

その背景の一つが「なぜそう実装したか?」と聞かれても、「それしか思いつかなかった」と答えるしかなかったことでした。

それが悔しくて、歯痒く感じて、書籍を中心に設計を学び、実践を繰り返しました。10冊は読んだと思います。

インプットとアウトプットを繰り返すと、徐々に設計には複数のアプローチがあることを体得していきました。

書籍での学習に慣れてきたら、企業のテックブログでも様々な設計手法を学び、実際の開発で試すことを継続しました。

自分が出したバグや組織で起きた障害からの学び、

言語が変わっても当てはまるグッドパターンの習得といったことを繰り返すと、

「こう設計・実装してしまうと後で困りそう、不具合が出やすそう」と事前に想像できるようになりました。

次に「設計に正解はないと知ったこと」についてです。

先のように自分の中で設計の知見が増えてくると、あらゆる機能を実装するにも複数のアプローチがあることがわかってきました。

多くの場合、複数の案はそれぞれトレードオフの関係にあったり、メリット・デメリットが存在するものです。

そして、それらは既存部の設計・実装にも左右されるものでもあるため、一概にどれが正解とは言い切るのが難しいことが多いです。

そして、状況が変われば今はベストでも、将来的に最適なものが変わることだってあります。

よって、システム開発は「今の自分たちの状況からベストな案を選択する繰り返し」だということに気づいたことで、自分の選択を整理して説明する重要性を知ったのです。

例えば、ある機能の実装でA案とB案があった場合、

それぞれのメリット・デメリットを考慮し、なぜA案を選んだのかを説明できるようにしました。

設計の段階や実装にかかる前に複数案を自分の中で比較・検討し、それをレビューいただくメンバーに見ていただくようになりました。

コードレビューでの指摘も「なぜその選択をしたのか?」という建設的な議論に変わっていきました。

複数案の整理をたたき台として、より良い設計をチームで議論できるようになったと思います。

最後に「視座が上がったこと」についてです。

昔は自分のタスクレベルとしてしか設計や実装を捉えられていませんでしたが、

今は組織全体として最適なシステムを作ろうと考えられるようになったということですね。

駆け出しだったり、まだ活躍する・高収入なエンジニアの思考がわかる前の頃は、

いかに自分のタスクを上手く終わらせるかが考えの中心でした。

しかし、既にフリーランスエンジニアとして評価が高く、月単価も100万円超の方から活躍でき、高収入なエンジニアの考え方を学ぶことで、タスクを組織目線で捉えるようになっていきました。

自分の設計がチームや組織全体に与える影響を理解するようになり、

例えば、ある設計変更が他のモジュールやチームメンバーにどのような影響を与えるかを考慮するようになりました。

コードレビューでの指摘も「全体最適」を意識した建設的なフィードバックとして受け入れられるようになったのです。

組織レベルで設計を考える習慣がつくと、「是非やまさんにお願いしたいです!」とサービスの根幹を担う機能の設計に関わる開発にアサインいただくことも多くなってきました。

今回は、設計に自信が持てずコードレビューに緊張していた時期の乗り越え方についてお話ししてきました。

昔は設計に自信がなく、コードレビューに怯えていた僕でも、

設計の学びと実践の繰り返しや、設計に正解はないと知ったこと、

そして、視座が上がり、設計で成果を出せるようになってきたことで、

今ではコードレビューを前向きに捉えられるようになりました。

もし、今同じようにコードレビューに苦手意識を持つ方がいらっしゃれば、

学びと実践の日頃の積み重ねが大切なので、1日2日でとはいきませんが、必ず恐怖はなくなるタイミングが来るので安心してほしいと思います。

お話ししたように視座を上げる努力も大切です。

自分のタスクだけでなく、チーム・組織全体を意識して設計・実装に取り組むことで、

コードレビューも建設的な議論として受け入れられるようになっていくと思います。

「サービスを伸ばすための運用を見越した設計」を考えられるエンジニアはどの現場でも重宝されるので、

日頃の自己研鑽を大切にしていきましょう!

今回、お話しした設計のインプットを含め、僕が実務経験5年でベテランのエンジニアマネージャーの方から評価をいただけるまでにしてきたことについてお話しする動画もあるので、もしよろしければ合わせてご覧ください!

また、メルマガもやっており、活躍する・評価され、高収入なエンジニアになるための考え方を発信しています!

こちらももし興味があれば、是非チェックしてみてください!

超雑魚社会人でもイキイキと働けるようになれた話

こんにちは、やまです。

僕は昔、エンジニア以前に社会人として超雑魚で自信がなく、
常に将来に不安を抱えながら過ごしていました。

今では周りから頼りにしていただき、
ありがたいことに感謝のお言葉をいただきながら、
100万円を超える月収で生活しています。

そして「もっと企業に喜んでいただくために成長していこう!」と日々、前向きに過ごしています。

変われたのは、適切にキャリアの歩み方、仕事で大切にするべき点を学んだから。

正しく学べば誰だって変わることができるし、成果も出せるようになって自信が持てるようになってきます。

冒頭でも述べましたが、僕は昔は本当にどうしようもなく無能な社会人でした。

まず、新卒で就職できず、無職で大学を卒業しました。

それから2年間、アルバイトをしながら公務員試験を受けるも、結果を出せませんでした。

この時点で25歳で、公務員は諦めてIT業界の自社製品を持つ会社の運用オペレータとして就職しましたが、

PCの扱いもコピペくらいしか知らず、テキストエディタの置換を知らなくて
1秒で終わる置換作業に半日かけていました。(しかもそれでいてミスがありました)

また、要領も悪く、仕事ではいつも上司・先輩から注意を受けていました。

  • 「報告と相談が遅い。自分で考える時間が長い。」
  • 「〇〇さんが忙しくなると事前にわかっていたよね。もっと早く相談するべきだったんじゃないか?」
  • 「何を言っているかわからない。事実と考えを分けて話して」

ビジネス書を読んだり、朝早く会社近くのカフェで勉強するなど努力はしていましたが、
社会人として基本的な仕事の進め方がなかなかできず、
いつまでも新人同然の仕事ぶりと評価で、月収も20万円でした。

そんな状態で27歳になり、周りの同い年の社員は昇進したり、新しい部署で活躍してとても輝いて見えました。

方や自分はいつまでも社会人の基本的なことができず、評価も上がらない状況で、とても精神的に辛かったのをよく覚えています。

そして、ある朝に出社しようにも体が動かなくなり、精神科で診断書を書いていただき休職したこともありました。

休職期間に「おれは何やっているんだろう…」という無力感を感じながら、部屋で寝ながらX(当時はTwitter)を見る日々が続きました。

その中でフリーランスのエンジニアが月70万円, 月100万円稼ぎながら、フルリモートで出社せずに働いている方の存在を知りました。

それでいて、お客様からとても感謝されながら幸せを感じながら過ごしている姿がとても印象的でした。

「いいな。おれもこの人たちのように生きれたら楽しそうだな…」と大きな憧れを抱きました。

「もうアラサーだけど、変わるなら今を逃すとチャンスはもう来ないかもしれない。」

そう思い立ち、プログラミングを一から学ぶことにしました。

まずは基礎として、書籍でWeb開発の全体像を掴むことから始め、
簡単なPHPの環境を構築するところまでできるようになったところで、
エンジニアのインフルエンサーが発信されていたポートフォリオに組み込みたい機能を把握して
ポートフォリオとしてWebサービスを開発。

ポートフォリオをもとに転職活動を開始するも、最初は全く書類すら通らない状況が続きました。
30社出して、ようやく1社面談できるかどうかという戦績でした。

未経験で28歳目前だったこともあり、転職活動は簡単ではないと覚悟しており、やはり苦しい現実に打ちひしがれそうになりましたが、

「ここで負けたら、一生負けたままだ!!!」と自分を奮い立たせて臨みました。

そうして約2ヶ月間、応募を続けているとオファーをいただくことができ、エンジニアデビューすることに。

CakePHPを使った受託開発で、コードを書く仕事に就くことになりました。

それからも継続して学び続けました。

設計やテストに関する書籍は2年間で10冊以上は読み、それを現場での仕事に活かす努力をしていると、
だんだん設計の勘所がわかってきて、「この設計の仕方、コードの書き方をした方が後で楽になりそうだな」という感覚が掴めるようになっていきました。

ただ、2年ほど学び続ける中で、書籍中心の独学だけでは限界もあるなということも感じていました。

技術は書籍と実践で一定磨けるものの、キャリアの歩み方や収入を上げていくための考え方は自分だけで学ぶことは難しいと感じました。

SNSで無料で発信しているものはあるものの、体系的に学べるものは限られているなと感じたところで、
有料でエンジニアのキャリア戦略や面接の攻略法を教えていただける方の発信を見つけました。

その方は他にも技術の習得法や、現場での信頼の構築で大切なこと等も有料で教えていて、
自分も学べばエンジニアとしてステップアップできるかもしれないと思いました。

総額で300万円近くかけて学びましたが、そこで学んだことは今の僕のエンジニアとしての根幹となっていることは間違いありません。

そもそも技術は何のためにあるのか、企業がエンジニアに求めていることは何なのか、
成果を出していけるのはどのようなエンジニアか

このようなエンジニアとしてキャリアを歩む上で、本質的な内容を学び、

現場での言動、日頃の自己研鑽に活かすことで、どんどん成長して周りからも頼りにしていただける機会が増えていきました。

そして、「やまさんにお願いして本当によかった」「いつも頼りにしています!」と身に余るお言葉もいただけるようになり、

「企業、周りの人に喜んでいただくためなら何でもやってやる」というマインドで

日々、行動していると、月単価も100万円を超えるようになりました。

昔は全く自信がなく、「自分なんかが提案しても良く思われないんじゃないか…」と尻込んでいましたが、今では、ガンガン改善提案をできるようになりました。

それは能力に自信があるということではなく、「自分もやればできる!」「たとえ上手くいかなくても、振り返って次に生かせば良い」という姿勢になったからです。

元々ダメダメな社会人だった僕ですが、

書籍だけではなく、できるエンジニアからエンジニアとして生きるイロハを学んだことでどんどん成果も出せるようになっていきました。

そして、自分もやればできるという自信がつき、もっと他者のために行動していきたいとイキイキと仕事ができるようになりました。

どんなに仕事ができなくて苦しい状況でも、正しい方法を学び、行動し続けることで、きっと突破できると思います。

普通に仕事をしているだけでは、教えてはもらえません。

仕事外のプライベートの時間を使って学び、それを現場の仕事に生かすサイクルを大切にすること。

昔、20代のほとんどがポンコツだった僕でも学び続けていたら変われました。

僕はメルマガもやっており、エンジニアとして成果を出す、活躍するための考え方を発信しています。

もし興味があれば是非チェックしてみてください。

「信頼されている感じがしない…」と感じた時に思い出したいこと

こんにちは、やまです。

  • 自分なりにちゃんと頑張っているのに、なぜか評価されない…
  • 簡単な仕事ばかりで、なかなかチャレンジングな仕事を任せてもらえない…

このように信頼されている感覚を得られていない、と悩む方もいらっしゃるのではないでしょうか?

僕もフリーランスになる前は、20代終盤になってもいつまでも新人のような評価で
「いつになったら一人前と見られるようになるのかな…」と思っていたものでした。

今はフリーランスで参画した企業の全てから「是非、長くウチでお願いします!」とありがたいことに言っていただけていますが、
過去の活躍できなかった昔と比べて何が違うのか?

端的に「任せたい」と思える動きができていませんでした。

昔は依頼のあった仕事をただ「そのまま」進めるだけでした。
「依頼のあった通り」に、抜け漏れなく進めること「だけ」を考えていました。

つまり、単なる「作業員」のような動きだったのです。

たしかに最低限はクリアできているように感じられるかもしれませんが、上司や先輩から見ると
「頑張ってはいるけど、チャレンジングな仕事を任せてみたい!とはまだ思わないな…」というイメージですね。

一方で、評価をいただけるようになったのは、+αで提案し始めた時からでした。

  • 「こうすると、よりユーザーの体験として良くなりそうですが、いかがでしょうか?」
  • 「ここはこうすると、より仕様としてシンプルになりそうですね」
  • 「ここの設計を詰めた方が良さそうだったので、考えてみました」

難しいことではなくても、少しでも他メンバーが楽になる動きを意識し始めると、
頼りにされることが増えてきました。

このようにタスクをただ進めるだけではなく、周りの状況も踏まえて自分の意見を言えると、「この人はしっかり考えている人だな」という印象を感じてもらえます。

逆に言われたことをただやるだけでは、「この人は自分の意見がないのかな…」という印象になってしまうのですね。

今の僕の仕事の中心は「自分以外のメンバー・組織がより楽になるための方策」を考えて、提案・実行することです。

フリーランスでの案件面談でも、話す内容はほとんど「組織の困り事を改善するエピソード」で、「是非ウチに来て欲しい!」と継続的に月100万円超でオファーをいただけています。

評価されずに悩んでいた過去の自分には、「仕事を単なる作業とするんじゃなくて、周りを楽にする動きをしなさい」と声を大にして言いたいですね。

今回お話ししたような「先回りして他者が楽になるような立ち振る舞い」は別の記事でもお話ししており、こちらも見ていただけると、より理解が進むかと思うので、是非ご覧ください!

また、エンジニアとして活躍し、評価を高め、フリーランスで単価もアップするための考え方をメルマガでもお話ししていますので、こちらも是非チェックしてみてください👇

肩書きなしでも活躍し継続して仕事のあるエンジニアとは

こんにちは、やまです。

エンジニアでキャリアップしていく上で一般的に想起されるものとして、
資格取得、メガベンチャーの実務経験、上流工程経験などが挙がると思います。

エンジニアで活躍し、評価され収入もUPさせていく上で、このような肩書きは必要なのか?

結論、企業が困っていることに対し、改善・提案できるエンジニアになれば、必ずしも肩書きにこだわる必要はありません。

昔は僕も「エンジニアで評価されるために肩書きが大切なのかな…?」と考えていた時期がありました。

一方で、終業後に一定期間まとまった時間をとって資格を勉強したり、
メガベンチャーをピンポイントで絞って転職して数年経験したりと
時間もかかるし、割と大変だと感じていました。

しかし、企業が課題に感じていることを解決していくことが最も評価・収入に寄与すると知ってから
肩書きに全くこだわらなくなりました。

そもそも活躍したり、収入を上げるのに企業は「肩書き」は見ていません。

企業が見ているのは「自分たちのサービスを伸ばすにあたって、生じる課題をどのように定め、どのように考えてアプローチしていくか」
この1点に集約されます。

企業がどのようにして利益を上げていくかを考えると自然なことですね。

自分たちのサービスで売上を立てて、経費を最小限に抑えることで利益を上げていきます。

資格や経験があれば利益が上がるのか?と考えると、答えは見えてきますね。

肩書きはなくても、課題解決できれば活躍できるし、収入も上がります。

逆に課題解決できなければ、肩書きが沢山あっても、活躍できないし、収入も上がらない、信頼されません。

決して肩書きが悪、という訳ではありません。

SIerやSESでキャリアアップしていきたい場合は有効だと思います。

SIerやSESのビジネスモデルを考えれば、「エンジニアを客先に派遣できるか」が大切なので、
肩書きは有効に働くかと思われます。

また、資格取得はエンジニアとしての知識をつけるのに役立つこともあります。

僕も駆け出し時代は基本情報技術者試験はテキストを購入して勉強していました。
ただ、目的を「資格取得」にせず、エンジニアとしての最低限の基礎知識をつけるために勉強しました。
ここで学んだ知識はその後のエンジニアの基礎力になっているなとは感じます。

AWSにも様々な資格があり、クラウドの基礎知識をつけるのに勉強するなどもありそうですね。

このように目的を持っているなら勉強するのも有効になり得ます。

活躍し、収入を上げていく上では資格取得に躍起にならずに、企業が求めていることを解決していける方が有効だよということです。

「自分がキャリアを歩んでいきたい企業では、何が求められるのか」を明確にして
努力の方向性を定めることが大切ですね。

今回お話ししたような、企業が課題解決できるエンジニアを求めているという内容を書いた関連記事もありますので、よろしければ是非こちらも見てください!

また、課題解決することで活躍し、収入もアップするエンジニアになる考え方をメルマガでも発信しているので、よろしければこちらもチェックしてみてください!

AI時代に仕事がなくならないエンジニアになるには?

こんにちは、やまです。

生成AIが台頭してきて、かつ進化も早い時代の中で、開発プロセスが変わってきていると思います。

Claude Code, Codex, Cursor, Devin, …などなど、生成AIが登場してきて、
実装コード生成やテストコードの生成, ドキュメント生成など、これまで人が行っていたことを生成AIが行う。
そのような現場がかなり多くなっています。

先日、エンジニアマネージャーとの1 on 1で生成AIによる今後の変化として、
「これまでもそうだったけど、一層アウトプットに責任を持てる人が求められるよね」と話していました。

今回は、生成AIに置き換えられないエンジニアの鍵とも言える「アウトプットに責任を持てる人」について、
僕の考えをお話ししていこうと思います。

Claude CodeやCursorを使えば、以下のことは一瞬でできてしまいます。

  • 仕様をもとにコードを大まかに実装する
  • 周辺コードをもとにした機能追記
  • 影響範囲調査

つまり、「受け取った仕様を単に実装に反映すること」自体に価値はなくなりつつあるのです。

仕様を単に動くように実装することは生成AIでもできることをお話ししましたが、
「単に実装することはできるけど、実装として整える力は人が担えばいいんじゃない?」と感じるかもしれません。

しかし、日頃から「自分の意見を持つこと」に慣れておらず、
指示のあった仕事をこなすことが習慣になっていると、ちょっとしたリファクタリングレベルでも困ることになります。

実際に僕が参画した現場であったお話で、
コードレビューで2人のレビュアーが異なる意見を出し、どちらも一長一短あるという状況でした。

レビューに対し、実装者は自分では判断できず、生成AIに判断を委ねており中途半端な状態で進みました。

生成AIに意見を求めることは良いですが、「最終的な判断は人が行うべき」です。
その時の状況を正しく認知するのは人だからです。

最終的な判断ができないのは厳しく言うと「自分の意見」がない証拠。
周りからは「考えていない」と感じられてしまいます。

冒頭でエンジニアマネージャーとの話の中で出た「アウトプットへの最終的な責任」を担うということは
言い換えると、「自分で判断できること」でもあります。

アウトプットへの最終的な責任は人が担うということは、
つまり、生成AIは「人のアウトプットを完全に置き換えるもの」ではないということでもあります。

だからこそ、「自分の判断軸」を持ち、それを言語化できる力が重要となりますね。

  • なぜこの設計・技術選定にしたのか
  • その選択のメリット・デメリットを説明できるか
  • 他にはどのような選択肢があるか
  • 「今の現場の状況」を踏まえ、それらの選択肢の中で、なぜこの選択をしたのか

日頃の業務で現場の状況をもとに最終的な意思決定を行うはずです。

実装は生成AIに任せ、「設計・技術選定・チーム開発体制の意思決定を行えるエンジニア」の少数精鋭で回す方向にシフトしていく企業も増えていくと言わますが、僕もその空気を感じています。

今回お話ししてきたアウトプットに責任を持つことは、「AIに任せられない部分」で価値を出すこととも言えます。

  • 技術そのものではなく、「技術をどう使うか」を考えられる力
  • チーム全体の生産性を上げるために、開発プロセスの改善点を見つけ、提案できる力
  • 周囲のメンバーと信頼を構築し、効果的にコミュニケーションを取り、協力して問題を解決できる力

つまり、「技術が変わっても枯れないスキル」ですね。

AI時代だからこそ、と言うよりも今までも重視されていた力ですが、AI時代に際立ってきたと言っても良いかもしれませんね。

難しいようにも感じられるかもしれませんが、裏を返すと、
技術力は尖っていなくても、考え方・動き方次第で価値を発揮できるチャンスは十分にあるということでもあります。

フリーランスで高単価な案件ほど「現場で日頃どのように考えて課題を設定し、どのように意思決定してきたか」を重視しますので、日頃から自分で考え、判断できるような習慣は大きな力になります。

僕もまだまだ道半ばですが、日頃の意思決定の質・動き方をVPoE経験のあるシニアエンジニアマネージャーの方に褒めていただいたことがあり、それまでにやってきたことを話す動画もあるので、よろしければ是非ご覧ください!

また、今回お話しした生成AI時代でも通用する思考・行動をもとにした、エンジニアとして成果を上げる考え方・ノウハウをメルマガでもお話しします。
こちらもよろしければ、是非チェックしていただけると嬉しいです!

脱指示待ち 評価や収入を決める「働き方」

こんにちは、やまです。

かつての僕は上司や先輩から指示のあった仕事をこなすだけで手一杯でした。

ミスを指摘されるのが怖かったり、注意されるのを恐れて詰まってもなかなか相談できず仕事も遅れがち。

そのような仕事ぶりを28歳の目前まで続け、評価はいつまでも上がらず、月収も20万円でした。

でも、そんな僕でも今では月収110万円でエンジニアをやっており、

「やまさんにいてもらえて本当に助かります」と身に余るお言葉をいただけたり、

コア機能の開発チームにアサインされたり、課題解決のための相談に乗る機会も増えてきました。

今回は、かつての自分のことで手一杯だった僕が、どのようにして頼られる側になっていったのかをお話ししようと思います。

当時の僕は端的に言うと、「単なる作業員」でした。

指示のあったタスクをこなすだけで、仕事の進め方もダメダメでした。

  • 不明なことがあっても、確認せずに進めてしまう
  • 報告も上司や先輩から聞かれるまでしない
  • 相談も遅れて納期に間に合わせられない
  • その割にはアウトプットも微妙

指示のあった仕事をなんとか終わらせる日々で、「いつになったら評価されるようになれるのかな…」と感じていました。

今でははっきりと言えますが、「周りを意識した行動」をしていませんでした。

  • このタスクの背景は何か
  • このタスクのアウトプットを受ける人はどんなことを期待しているか
  • 会社にとってどんな意味があるのか

タスクの位置付けや目的を考えることができておらず、
その仕事によって、周りにどのような影響があるのかを意識した行動が取れていませんでした。

ダメダメだった状態から少しずつ変わり始めたのは、「先回りして、周りが動きやすくなるようにしよう」と意識し始めた頃でした。

  • タスクの背景や目的から全体の優先度をつける
  • チームの進行状況を見て、期日までにどのようなアクションを取るか考えて提案する
  • 必要であれば、自らヘルプに回るように打診する

このように書くと社会人として当たり前の行動のようですが、意外とできていない人が多い印象です。
プログラミングスクールでは技術スキルにフォーカスしがちで、こういった動き方を教えることは少ないと思います。

「仕事」として成果を出すには、こういった周囲との連携や先回りの動き方がとても重要です。

この現場ではCTOと直接一緒に仕事するプロジェクトで、ありがたいことに日頃の動き方をとても評価いただけました。

技術力は駆け出しレベルであることは見抜かれていましたが、
「ビジネスとして先に進めるための動き方」を高く評価していただけていたのでした。

その現場で動き方が成果として見えるようになってきて、
他の案件探しの際の面談でも「どのように考えて動いているか」を少しずつ話せるようになっていきました。

その現場はフリーランスデビューの現場で月単価は30万円でしたが、
その現場での「周りが動きやすくなるような動き方」の話を整理して面談で話すと、
次の案件では、2倍を超える70万円でオファーをいただけました。

当時、ちょうど経験2年のタイミングで、技術力的にはそこまで高くありませんでしたが、
「周りが動きやすくなるようにした実績」を評価いただけたのだと思います。

そして、新しい参画先でも続けて「周りが動きやすくなるように」動くことを徹底しました。

  • チームで相談しやすい雰囲気を作るため、振り返りでポジティブなフィードバックを積極的に伝える
  • 難しい課題に直面したメンバーには、自分の経験をもとにアドバイスを伝える
  • チーム全体として早く開発が進むようなアサインを考える

自分の働きかけで少しでもチームが進みやすくなるようにすることをとても大切にしていました。

フリーランスになってから3年が経過した時点で、月単価は100万円を超えていました。

技術力ももちろん上がっていますが、
それ以上に「周りが動きやすくなるように」動くことを続けた結果、評価される機会が増えたのだと感じます。

案件面談でもチームを円滑にする動き方をベースに話すことがデフォルトになりました。

実際に面談で「チームとして早く成果をあげるため、上がってきた仕様をそのまま受けず、影響範囲もきちんと調査した上で考慮が必要な点を整理し仕様としてPdMに提案する」動き方を伝えると、面接官の方から「めっちゃ良いですね!」とリアクションいただけたこともあります。

単に技術力だけではなく、「ビジネスとして成果を出すための動き方」ができるエンジニアは評価されやすいと実感します。

僕がやってきたのは「能力ではなく、意識次第で行動できること」でした。

  • タスクの背景や目的を考え、全体最適を意識して動く
  • チームメンバーが困っていれば、自分からヘルプに回る
  • チーム状況を見て、自分が必要だと思ったアクションを提案する

上記のような行動は何も高いスキルが求められるものではないはずですね。

しかし、「周りが動きやすくなるように先回りして動く」ことこそが、「任される人」になる要素なのです。

他者のために行動し続けること。

それが結果として、評価や収入アップにつながります。

PS. もっと学びたい方へ

今回のお話以外でも評価され、収入もアップするエンジニアの考え方をメルマガでも発信しています。

月収100万円超でエンジニアをしている僕が日頃どのように考えて行動しているかをお話ししています。

是非チェックしてみていただけると嬉しいです!

また、Youtubeでは「相手のために尽力することが結果として経験になり、収入もアップする」というお話をしています。

技術力を鍛えるのは頑張っているけど、なかなか評価が上がらない、収入も上がるかわからない…

このように悩んでいる方がいらっしゃれば是非見ていただきたい動画です!