やはりプロダクトの立ち上げから拡張を開発、インフラ面含めて一通りやらないと、いくら同じ会社で職歴を続けてもシニアに必要なスキルを身につけるのは難しいと思います（無理だとは全く言いません）

インフラが弱いならインフラ構成をたくさん考えて実装、開発が弱いならバックエンドなど、システム全体への理解のうち、理解度が浅い箇所を掘るのがいいのかなと感じました。得意不得意の濃淡は誰にでもありそうだからです

エンジニアに限らない話だと思いました。

メタ認知を鍛えることが有効だと思います。まずは本から。

澤円さんの「メタ思考」などはとっつきやすくて入り口に良いと思います。

そこまでやられているなら、技術力もあるのでしょうし、時が解決するのではないでしょうか。

もし根本的に理解できないのであれば、業務ではなく、CSの教科書に戻ることも必要だとは思いますが。

その上で大規模な会社でシニア、スタッフに上がりたいのであれば、技術力よりも組織やチーム外へのインパクトが必要になってきます。逆に技術力だけではキャリアが頭打ちになるので、色々なチームと嫌なやつにならずにコミュニケーションするスキルの方が必要になってきます。

技術力だけで戦うだけがテック企業で生きる道ではないので、あまり悲観的にならないで大丈夫かと思いました。

『ドメイン駆動設計をはじめよう』は読まれましたか？

私はこれを読んではじめてDDDを自分の言葉で語れるようになりました。

第一部では、ビジネスの業務領域のカテゴリー分けのやり方が書いてあり、専門家が使う言葉の整理と文脈の整理方法が書かれています。

同じ言葉と区切られた文脈で整理して、課題を解決できるマップを作るところから始まります。

ここで整理されたいわゆる「ビジネス」が、第二部で実装される「コード」につながっていきます。

DDDは難解で、意味論的な不確実性にのみこまれがちですが、この本で理解した考え方で整理していけば、おそらく「ビジネス」というシステム全体とそのコードの対応が理解できてくるのではないかなと思います。

結局システム全体の設計についても、顧客の課題を解決してお金をもらうという商売をいかにうまくやるかなので、「ビジネス」と「コード」をシームレスにつなぐことができるDDDはソフトウェア開発者としての武器になると思います。

DDDで目的を明確にし、具体的なアーキテクチャは『クリーンアーキテクチャ』などをベースとして実装することで、実際の業務に活きるソフトウェアを構築できるはずです。

私の認識範囲では、このこそこそが「システム全体を俯瞰した理解と構築」だと考えています。

少しでも参考になれば。

開発対象のアーキテクチャ理解も大事ですが、

これどうやって実現してるの？と思ったらすぐに下回りのコードを読んで有識者に確認する。

なんでこの実装してるんだろう？と思ったら自分なりの仮説を立てて有識者に確認する。

これもっとうまく書けないかなぁと思ったら、下回りのコードの改善提案してみるとかもよくやってました。

自分だけで勉強するのでなく、仮説ぶつけてフィードバックをもらうスタイルで。

私は人よりペインを感じるのが早く、常にもっとよくできないか、前やった似たようなことはもっと良いものを早くできないかを考え続けてます。

経験は考えた物量(時間×深さ)に過ぎないと思ってます。

そうかなあ。

あなたがシニアエンジニアっていうロールを与えられたらそれなりの動きをしそうだけど...

自分自身も他人もあなたにレッテルを貼ってあなたの活動を制限してる側面もありそう