視座と肩書と
Date2026/05/07履歴書を書くかのように自分の仕事を説明すると、どこから伝えようか迷ってしまう。
結局なにエンジニアなの？と言われると、うーん、何でも屋さんですよ。と答えるのみ。
そんなこともあり、自分の肩書なるものについて考えてみました。
つい最近読んだ記事。
視座を上げる・視野を広げるということ ぺんぎん(@jitepengin)氏
こちらの記事では、いまの自分の仕事を高い視座で見つめて状況をつかみ、広い視野を持って選択肢が持てていると良い、といった趣旨の話がありました。
ちょっと短絡的ですが、視座が高いほどに肩書が変わっていくんだなぁと感じました。コードだけ見るのか、システム全体を見るのか、チームまで見るのか、と。
自分のケースに置き換えてみると、視座はどんどん上がっている一方でなかなか技術が追い付いていない気がしていて、PM見習いあるいはよちよちテックリード兼フルスタックエンジニアみたいな感じなのかなと思いました。
視野を広げるというのは面白い考え方で、それこそテンプレートがあってあらゆることができていたとしても、通り一遍のことしかできないのなら実は何もできてないのと同じだったりするのかなと。
例えば私がPMだったとしたら、その肩書に見合うのか……。
PMの概念を決めるのが難しかったので、AIに決めてもらいました。
自分の仕事を思い出しながら、働いている姿を想像してみる。
- 納期の管理
自分の工数を把握していて、世の中の一般的な工数もだいたいわかっている状態で算出。
チーム内のスケジュールを勘案して、手が埋まってるときは優先順位を決めてもらってスケジュールを出し直して割り振り。 納期をずらすということは顧客との折衝があり、将来収益とコストのバランス、納期がそこである理由、当期の予算との兼ね合いなどがあるということは知っているが、実際に表に出てそれを調整する立場ではない。自分はPMや経営陣そこらへんを聞く感じの立場。 - 品質の管理
エンジニアとして、システムにまつわるセキュリティリスクや要件の遵守についてはもちろん行いリリースの判断を行う。
インシデントへの対応は優先事項について把握しているものの、自分がそれを旗振りするわけではない。何をしたら良いかを問われたら、プロジェクトの担当者として対応策を答える感じ。
契約関連についてはほとんど詳しくない。資格試験等でどういう形式上のやり取りがあるのかは知っているが、実務の経験はなし。 - 予算の管理
自分を含めたチームの業務が、どれくらいの予算で組まれているのかについては把握している。
ただ、実際にバランスシートを見る機会は少ないので、企業としての会計をあんまり意識したことはない。
技術選定による費用感については把握しているが、それは与えられた業務に対する提案ができるだけであって、その業務をやるべきかどうかについての判断ができるほど視座は高くない。 - 人の管理
１プロジェクトにおける人の管理はある程度行うが、やっぱり会社全体のことはわからない。
あくまでエンジニア向けのプロジェクトをすべて把握しているだけで、他の部署との兼ね合いなんかは全然知らない。 - 顧客期待の管理
経営層と話す機会は少ないが、システムの利用者の意見を吸い上げるあたりはよく行う。
そのシステムを提供する先の業務プロセスまで関与するので、自分から提案する場面もある。そのプロジェクトが発足した理由から、保守運用の観点まで考えることまではあるが、結局のところ企業間の細かい折衝に絡んでいるわけではないので、それを実行するかどうかについて判断はできない。
こうしてみると、「PMや経営陣が何をやってるのかぼんやり知っているけど、全然及ばない」といった感じのような気がしてきた。PMｴｹﾁｪﾝ。
エンジニア全体のプロジェクトは管理しているので、テックリードとかPLが一番近いんでしょう。
でもなんか、PLってもっとエンジニア歴10年くらいの人がやってるイメージ。あんまり高尚な最新の技術に触れたことが無くて、とにかく安く早くみんながやりやすい方法は知ってる……。これでテックをリードして良いものだろうか。
もうAIには頼りきりで、自分はコードレビューするだけになってきてるのに、テックも何もあるんだろうか。配列の関数も毎回検索しないと忘れちゃうのに。悩ましい。
「技術のことなら何でも聞いてね！」と言えるように、急に背中から飛んでくる弾丸に備えるために資格試験の勉強も始めたけれど、専門性も捨てがたい。けど専門性ってどうやって磨くんですかね。最新の開発手法とか、全然試す余裕もないのに。
実はみんな背伸びして肩書を背負ってるんだ、と思えれば気楽なのかもしれません。
誰かが決めてくれるものでもないので、テックリード兼Webエンジニアあたりを勝手に掲げて、あとはケセラセラ。