長い間、私は自分の成長を「何を作れるか」で測っていました。新しいフレームワークを覚え、新しい種類のアプリをリリースし、履歴書の技術スタック欄に一行増える。それが正しいスコアボードだと感じていましたし、最初のうちはほぼその通りでした。
気づかなかったのは、そのスコアボードが実際の試合と噛み合わなくなった瞬間です。コードが簡単になったわけではありません。ただ、夜も眠れなくなるほど悩む部分ではなくなりました。難しさは別の場所に移っていたのです。何を作るかを決めること、何を作らないかを決めること、そしてその両方の結果を引き受けること。
この記事は、その変化を自分が経験したとおりに書こうとする試みです。誰がシニアかを判定するための枠組みではありません。肩書きの意味は会社によっても市場によっても違います。2025年、私はある会社ではSoftware Engineer、別の会社ではSenior Software Engineerとして同時に働き、数か月後には3社目でFull Stack Developerでした。その肩書きの裏にある仕事は、言葉ほど違ってはいませんでした。だからこれは、誰もが登るべき階段としてではなく、問題の性質がどう変わったかについての一人のエンジニアの見方として読んでください。
ジュニア：実行することを学ぶ
私は2022年、まだ大学に通いながら、Webとモバイルのデリバリーアプリをプロトタイプとして作ることから始めました。一人で作っていたので、アーキテクチャ、データモデル、各部分の連携方法など、すべての判断を自分で下していました。しばらくの間、それを自分が実際以上に先へ進んでいる証拠だと受け取っていました。
その違いを理解するのに何年もかかりました。誰にもレビューされない判断を下すことは、良い判断を下すことと同じではありません。誰も選択が間違っていると言わなかったので、間違っていないと思い込んでいました。他の選択肢が何か、それがどれだけのコストを伴うのか、半年後に何が壊れるのかも知らないまま、アーキテクチャの判断をしていました。自分が何を知らないのかを知らなかったのです。
2024年にチームに加わり、React、Next.js、React Native、FlutterでWebとモバイルのアプリを作るようになると、仕事の形ははっきりし、正直に言えば居心地も良くなりました。タスクは明確に定義された状態で届きました。画面が何をすべきかは誰かがすでに決めていて、私の仕事はそれを実現することでした。一日中自分に問いかけていたのは、この質問です。
「これをどう実装するか？」
これは小さな問いではありません。その段階では正しい問いです。技術スタック、コードベース、誰も書き残していない慣習、そして自分のマシンで動くコードとレビューを通るコードの違いを学んでいる最中だからです。私は頻繁に助言を必要としていましたし、それも具体的な助言が必要でした。
振り返ると、私が主に築いていたのは機能ではありませんでした。実行力です。定義されたものを受け取り、揉めることなく動くソフトウェアに変える力。その後のすべてはこれに依存しています。まだ書くのに苦労しているコードについて、トレードオフを考えることはできません。
ミドル：オーナーシップを学ぶ
ミドルへの移行は、新しい種類のタスクとともに訪れたわけではありませんでした。同じ種類のタスクに付いてくる指示が減った、という形で訪れました。
「この画面を作って」ではなく、「この連携が必要だ」になりました。Mercado Livre、Shopee、Metaとの連携に取り組み、Apple Developerを通じたiOSアプリの公開と保守を担当しました。リリースサイクル、App Storeの審査ガイドライン、プルリクエストがマージされた後に始まる仕事の部分です。この最後の部分は、コードが教えてくれなかったことを教えてくれました。機能は動いたときに完成するのではありません。ユーザーの手に届き、動き続けているときに完成するのです。
外部システムはこの教訓を否応なく突きつけてきます。APIはタイムアウトし、予告なく仕様が変わり、同じイベントを二度送り、データの半分が欠けたまま成功を返してきます。だから自分への問いが変わり始めました。この呼び出しが失敗したらどうなるか。このWebhookが二度届いたら？本物のカードに課金せずにどうテストするか。顧客に言われる前に、本番で壊れたことにどう気づくか。
それらすべての根底にあった問いはこれです。
「これを解決する最善の方法は何か？」
この問いは、問題そのものがすでに正しいことを前提にしています。何を解決するかは誰かが決め、どう解決するかを私が決める。エッジケース、テスト、パフォーマンス、デプロイに責任を持つようになり、チケットに書かれた詳細が少なくても仕事を進められるようになりました。
これは本物の前進で、しばらくはそれが仕事のすべてのように感じられます。信頼され、リリースし、誰も一行ずつ確認しなくなる。次のステップも同じことの延長、つまりより大きな機能、より複雑なシステム、より多くの技術だと信じやすくなります。
私の場合は、そうではありませんでした。
シニア：決めることを学ぶ
仕事が変わったことを示す一番はっきりしたサインは、タスクではなく問題を受け取るようになったことでした。
「Xを作って」ではなく、「この画面が遅い」「このシステムをFirestoreから移行する必要がある」「顧客が支払えず、理由が分からない」。仕様はなく、明確な担当者がいないこともあり、実際に何が起きているのかについての情報も不完全なことが多い。
新しい問題
問題そのものの形が変わりました。一つの機能についての問題は減り、すでに稼働していて、人々が頼っているシステムについての問題が増えました。
私が関わった、フリート管理に特化したERPでは、コアをFirestoreからPostgreSQLへ移行し、6つの別々のプロダクトを1つのマルチテナントのデプロイに統合する必要がありました。すべてを形作った制約は、業務を止められないということでした。新しいスキーマを書くことは難しい部分ではありませんでした。難しかったのは、モジュールごとにどう移行するか、何をどれだけの期間共存させるか、各段階でどのリスクを受け入れるかを決めることでした。そのどれもチケットには収まりません。
新しい責任
責任も変わりました。そしてそれは気づきにくいものでした。誰もチケットで渡してはくれないからです。
- デプロイの後に起きること。 何千人もの人が使うWebとモバイルのプロダクトでは、責任を持つとはクラッシュレポート、ログ、メトリクスを意味しました。顧客に言われる前に、何かが壊れたことに気づくこと。
- 他人のお金とデータ。 同じイベントが二度届くことがあり、不注意なリトライが誰かに二重に課金してしまう決済とWebhook。そして何を収集しないかを決めること。決済フローでは、計測から外したものが、取得したものと同じくらい重要でした。
- トレードオフを伝えること。 コードを読まない人に、何を手放しているのか、なぜなのか、後でどれだけのコストになるのかを説明すること。
- 作る量を減らすこと。 依頼された機能が問題を解決するのかを問い、ときには作らないことを主張すること。
- 判断を引き受けること。 一歩ごとに誰かの承認を得ることなく判断し、それが間違っていたときには自分で引き受けること。
もう一度ゼロからプロダクトを作ったことで、その違いがはっきりしました。2022年、一人でデリバリーアプリを作っていたとき、私はすべての判断を下していましたが、そのどれにも誰もお金を払っていませんでした。連携、決済、注文フローを備えたマルチテナントのマーケットプレイス自動化プラットフォームをゼロから作ったとき、私は再び判断の大部分を下していました。自律性は同じでした。重みはまったく違いました。一つひとつの判断の向こう側に、お金を払っている顧客がいたのです。
そして問いはまた変わりました。
「私たちは実際にどんな問題を解決しようとしているのか？」
この問いは居心地の悪いものです。依頼された機能が、依頼した人の抱える問題を解決しないという答えになることもあります。「まだ分からない。だから、こうやって確かめよう」という答えになることもあります。いずれにしても、今はその答えを出すのは私です。
自信と停滞
この時期には、予想していなかった側面がありました。成長すればするほど自信がつきました。そして同時に、停滞しているとも感じるようになりました。成果は出せました。技術スタックも、システムも、本番環境もよく分かっていました。その自信は判断を下すには役立ちましたが、自分がどこで成長を止めてしまったのかを教えてはくれませんでした。
再び前に進ませてくれたのは、新しい技術ではありませんでした。人でした。スタッフエンジニア、マネージャー、シニア、私の年齢と同じくらいの年数の経験を持つ人たちなど、より経験豊富なエンジニアから助けてもらう機会が増えました。そこから本当に多くを学びましたが、構文に関することはほとんどありませんでした。ここまでに書いたことの多く、つまり何かを書く前に自分に投げかける問いは、彼らの働き方を見て学んだものです。
逆の方向は、もっと意外でした。キャリアを始めたばかりの人を助けることが、私自身の助けにもなったのです。何かを説明することは、自分が本当に理解しているかを確かめる一番の近道であり、誰かの疑問に答えることは、自分の知識を整理することを強いてくれます。それが、私の学び方、学んだことの活かし方、そして知識の伝え方を形づくりました。
それこそが、履歴書には書けないシニアリティの一部だと思います。先を行く人から学びながら、同時に、始めたばかりの人を助けること。
問題が変わる
この変化全体を一文にまとめるなら、こうなります。コードは難しいままだが、ボトルネックではなくなる。
代わりに難しくなるのは、次のようなことです。
- 本当に作るべきものを見極めること。 要件は不完全な状態で届き、欠けている部分こそが重要な部分であることが多い。
- トレードオフを選ぶこと。 どの選択肢にもコストがある。仕事は、それが何かを知り、声に出して言うこと。
- 既存のシステムの中で働くこと。 現実の仕事のほとんどはグリーンフィールドではない。人々が使っている最中に、彼らが頼っているものを変えること。
- 結果を予測すること。 今日選んだスキーマが、今後2年間、何が安く何が苦痛になるかを決める。
- 不確実性の中で働くこと。 100%を待つほうが高くつくから、60%の情報で判断する。
- スピードと品質のバランスを取ること。 スローガンとしてではなく、今週、特定の機能における具体的な選択として。
- 影響を理解すること。 チェックアウトでのフロントエンドのエラーはUIのバグではない。どの技術ダッシュボードにも表れない売上の損失だ。
これらはどれもコードを置き換えるものではありません。コードの上に積み重なるものです。クエリも、コンポーネントも、マイグレーションも、今でも書く必要があります。ただ、一週間で最も難しい一時間が、エディタの中で過ぎることはほとんどなくなりました。
市場は気づく
市場も同じ変化を、少し遅れて追いかけていることに気づくまで、時間がかかりました。
最初のうち、評価のされ方はほとんど履歴書から読み取れます。どの技術を知っているか、どのフレームワークか、どんなプロジェクトを作ったか、経験は何年か、機能を実装できるか。それは理にかなっています。その段階では、それらが実行できるかどうかを示す本当に最良のシグナルだからです。
担う範囲が広がるにつれて、それらのシグナルだけでは足りなくなります。重要になり始めるものは、リストにしにくいものです。
- オーナーシップ：関わったものが、デプロイ後の部分も含めて最後までやり遂げられるか
- 自律性：問題を前に進めるのに、どれだけの指示が必要か
- 意思決定、そして下した判断を説明できるか
- 図としてではなく、結果としてのアーキテクチャ
- アウトプットの量ではなく、プロダクトへの影響
- コミュニケーション、特にトレードオフとリスクについて
- 曖昧さへの耐性
- 技術的な選択を、ビジネスが目指していることにつなげる力
変わるのは評価のされ方だけではありません。巡ってくる機会の種類が変わります。範囲の決まったタスクが、開かれた問題になります。「これを作れますか？」が「ここで何をすべきか見極められますか？」になる。信頼の質が違い、それに伴う責任も違います。
ここは慎重に書きたいと思います。これは給与の約束でも、保証されたキャリアパスでもありません。市場も会社も違いますし、これとはまったく関係のない理由で過小評価されたり過大評価されたりする人はたくさんいます。これは私が気づいたことにすぎません。認識される価値は、技術スタックのリストの長さよりも、任される問題の大きさについていく傾向がある、ということです。
私にとって何が変わったか
2022年の私の技術スタックと今のものを比べれば、増えてはいます。でも、変わったのはそこではありません。使ったことのある技術をすべて並べても、当時の働き方と今の働き方の違いは説明できないでしょう。
変わったのは、どこから始めるかです。以前は実装から始めていました。今は問題から始め、信じる前にまず疑うようにしています。デプロイの後に何が起きるか、壊れたときに誰が気づくか、何を手放しているのかを問います。「誰も反対しなかった」を「正しかった」と見なすのはやめました。
完了の定義も変わりました。かつて完了とはマージされたことでした。次に、デプロイされたことになりました。今は、問題が実際に解決され、なぜ他の方法ではなくこの解決策なのかを説明できることを意味します。
そして、そのほとんどは一人で気づいたものではありません。先にその道を通った人たちから、そしてまだ通っていない人たちに説明しなければならなかったことから得たものです。
まだ学んでいる
どこかに辿り着いたとは思っていません。今も取り組んでいることがあります。十分に良いものが本当に十分なのはいつかを見極めること、トレードオフと手抜きの違いを見分けること、そして以前より早く「私が間違っていた」と言えるようになること。そして今も、ほとんどのことを学んできたのと同じやり方で学んでいます。先を行く人たちから、そして始めたばかりの人たちに説明することを通して。
そして、今信じていることの一部は、数年後には未熟に見えるだろうとほぼ確信しています。最初のアーキテクチャの判断が今そう見えるのと同じように。それでいいのです。それこそが大事なところだと思います。
コードはこれからも仕事の一部であり続けます。今でも書くのは楽しいですし、コードを気にかけなくなったエンジニアを私は信用しません。それでもある時点で、コードを書くことは難しい部分ではなくなります。難しいのはその周りのすべてです。問題を理解すること、何を手放すかを選ぶこと、そして結果を引き受けること。
それが、私がまだ学んでいる部分です。