2025年12月6日土曜日

強みねーな・・・っていうとき

👥「naohiroさんの強みって何ですか?」

👦「(やっべ...全部必要だと思ってたし強みとかないな)設計です!」

👥「では、何をされていましたか?」

👦「実装とかDB設計とかAWS触ったりとか運用とか...」

👥「...(なさそうや)不採用」

👦「ああああなんでいつもこうなんや」

今までフルスタック(全部やれ)をやっていたから全然強みとかないな。。どうしよ。と将来大人になったときが心配になってしまったので強みを探していく実際の流れを書いてみたいと思います。

背景:そもそも前職では技術力というより、リーダーシップの発揮がとても大切な会社でした。そうするとエンジニアとしての強みというのは技術的にはあまり主張できないことになってしまいます。

テーマ:T字型人材を目指す

幅広い強みがあることはいいことですが、何か専門的なスペシャリティを持っていた方がよいというのが最近のトレンドなんじゃないかな?と最近面接していて思いました。(される方です)

なので、T字型人材を目指すために振り返りをしたことや分析してみたことを実際にステップごとに書いていきます。

前提

  • 今まで強みとかないし何でもかんでもやっていた人
  • 選ぶ=他を捨てる

自分の好き・得意を掘り下げる

  • 今まで自分がやっていてこれは得意そうだとか好きだなって思ったこと
  • 気づいたらなんか情報収集してるやつ
  • こういうことをやっていた時結構集中して熱中してたなと思うこと
経験が多いこと
  • 何だかんだ経験が多いことは?
相手を見る
  • 市場に幅広く求められている
  • スペシャリティ
    • ニッチな分野
    • 他の人が見てなさ過ぎて競合がいないため枯渇している部分
  • インパクトの大きさ
    • ビジネス的なインパクト
    • 開発チームへのインパクト
      • 会社へのインパクトが大きい
テーマで区切る
  • 自動化
    • IaC
    • テスト自動化
  • 信頼性
  • セキュリティ
  • クラウド
    • クラウドアーキテクチャ設計・構築
    • マルチクラウド対応
    • AWS特化、GCP特化、Azure特化
  • パフォーマンスチューニング
    • 性能調査
    • オブザーバビリティ
  • データ設計
    • データ構造→非構造、半構造、構造化データ
  • コーディング
    • 言語別
  • アジリティ・デリバリー
  • アーキテクチャ
    • ドメイン駆動設計
    • 分散型アーキテクチャ
  • コスト最適化
  • マネジメント
  • 顧客折衝
  • 品質保証
  • ...etc
何が欲しいか
  • 年収
  • 将来性
    • 安定性
    • ワークライフバランス
  • 自由さ・責任の境界
  • 会社のブランド
    • 会社規模
    • 社名
  • 活躍度・楽しさ
  • 0→1
  • 知名度
  • ...etc

自分は?
  • 年収欲しい
  • 将来性欲しい
  • 責任感からか、より根本を直したいと思う性格からか結構事業リスクとか考えてやっていたかもしれない
    • 開発プロセスとか
    • サーバーの障害リスクとか
    • 技術負債とか
    • やべー誰も分からねぇっていう状況をゼロにしたいと思った
      • ドメインをいの一番で理解しておいて人に教える
      • リファクタリングとかコメントとかめっちゃ書いてた
      • ていう割にはテストはあまり書いてなかった
    • ドキュメンテーションみんなやらなすぎじゃね・・?って思った
      • 逆に言うと割と書きたいかもしれない
  • だから逆にいうと新規機能開発ってあんまりやってなかったかも
    • ていうかやりたい人多すぎてた
    • そういえばSIerの時にやってたのってほぼほぼ拡張か構成管理かリプレイスだった
      • 新規機能の耐性ついてないな
      • カオス好きじゃないな。不確実性はめっちゃ減らしたい
  • 設計とか楽しい
    • DB設計とかは楽しいんじゃないかな
      • 一番負債になるのここだったし
    • DDDとかも結構勉強はしてた
      • でもRailsではやらない方がよいっぽい
    • システム移行とかリアーキテクチャには興味がある
      • でかいことやりたいな
    • AWS
      • めっちゃコストかかってね?って思ってからは最適化したいと思った
      • 運用大変じゃね?って思ってからは自動化したいって思った
      • これ構築とか楽しくね?って思った
      • サーバーの冗長化とかDRとかマルチAZとかレプリケーションとかDBの移行とか楽しくね?って思った
  • 実装
    • 楽しくはなかったかもしれない
    • AIでよくね
    • 実装めんどくせって思っちゃう
  • 勉強してて楽しいのは?
    • スケーラビリティ
      • オートスケーリング
        • 垂直スケール、水平スケール
      • キューイングメッセージ
      • ロードバランサー
        • リクエスト負荷分散
      • データベース
        • レプリケーション
        • パーティショニング
        • シャーディング
    • パフォーマンスチューニング
      • 可観測性
      • クエリ分析
結論:お前、それWebエンジニアか?
総括:共通してるのは分析して解決かなぁ。今の問題点ってなんだろう?っていうところから考えて解決するまでの調査と分析をして解決策を考えて実装。


0 件のコメント:

コメントを投稿

モノリス状態遷移からイベント駆動型アーキテクチャへの移行

 キューイングシステムを深堀りたい 背景: SidekiqワーカーがWebサーバーが入っているEC2に同居している状態。Railsモノリスから脱却し、疏結合化を進めることで、スケーラビリティを向上させたい。 現状分析: Railsモノリスの巨大な泥団子システム。 調べるとapp/...