  |
はてなキーワード: シニアとは
“「ご存知なかったのかもしれないけれど、女も本を読むんですよ」”
“「研究にお戻りください」って、あたかも研究環境の改善が研究とは関係ないことみたいですね”
“若手研究者が学界内外のハラスメント防止に尽力していたら、中堅研究者から「そのエネルギーを研究に向けろ」なんて言われてしまうのか。誰が残したツケを払ってると思ってるんだよ。そういう態度で次に押し付けてきたんでしょうが。それに、もっと若い世代はどっちを見たら安心すると思ってるんだ。”
“年配の研究者が、会ったこともない若手にあのような言い方をすることこそがハラスメント。イジメです。それに「研究に没頭できる」「試験監督しかしなくていい」助教職って、文系ではもう稀じゃないかと思うんですよね。件の方は、随分古い助教イメージをもっておられると、ため息しかでません。”
“ハラスメントの問題にエネルギーを割いてないで研究に集中したら、みたいなの心の底から腹が立つ。誰もが研究に集中できる環境をつくるために、アカデミアからハラスメントをなくさなければならないのだろうが。シニア世代が残したツケを初期キャリア世代が払っているのに、何でそんなに偉そうなんだ。”
転職歴としては1社目は新卒で入った地元の零細受託Web制作会社→4年前くらいに転職し現在自社サービス企業に勤務中。
ちなみにまだ内定は0件。
コロナを機にフルリモート案件が増えたのと、リーダー経験とか積むにつれて市場価値と今の職場が合わなくなってきたのがあるのと、
今の年収だと婚活で戦うのはかなりきついということを実感したので動き出すことに。現年収は400万ちょっとくらい。
専門卒で経験はPHP/JS中心だから経験してきた技術スタックや学歴的にはあんまり上位狙えるようなアレじゃないんけど今回は心が折れるまでは初年度年収600万を目指すことに。
現職でのリーダー経験と、Saasを立ち上げから設計・開発全部8割型自分で進めて競合と戦えるサービスに成長させた経験とか、ゼロイチで既存案件をDDDに移行したりテスト駆動体制を導入したりとか、まあまあ個人開発もやってますよとかその辺をアピールポイントとして戦うことに。
肌感覚としては「500万までは余裕だけど600万はきつい」だわ。
まず某転職サイトに応募すると早速600万のスカウトが来たユニコーン系ベンチャー。フルリモート。
「貴方のSaas開発経験に魅力を感じ～」とか書いてたから誰でも送ってる風じゃないと思い応募。
結果はなんと書類選考落ち。いや学歴とか職務経歴とかほぼ転職サイトにそのまま書いとったやん。
恐らくだけど選考時にGithubアカウントとかTwitterアカウントを求められたときに仕事用のものはセキュリティ上渡せないとか渋ったのと、
渋々渡した個人用Githubアカウントはオープンソース活動とかはしたことなかったからこれがしょぼいって思われたのかな？って思った
ちなみにこの会社からは書類選考落ち後に各転職サイトから5回くらいスカウトが来てる。
大手っていうわけではないけど割と有名なSaas企業。こっちもスカウト。転職サイトの上の方でよく見る気がする。
結構近しい分野のSaasを立ち上げから関わったことがあるのでこちらを武器に面接へ。1次面接落ち。
面接は割とうまく行ったと思うけどなぁ、って思ったけどやっぱりフルリモートでこの給与帯の休日は倍率半端なさそうだからちょっと良いくらいだと全然落ちるんだなと実感。
立ち上げから3年も経っていないベンチャー、ただし既に利益率は割と凄い感じで業界的にも硬そうだから応募。
カジュアル面談のときにCTOに是非応募してほしいって直接言われた。
1次の技術面接のレベルがたけぇ。○○の設計思想の内容だとかDIコンテナとかReactの状態管理用ライブラリの運用とかの質問をクイズ形式っぽく質問される。
割とうまく答えられたと思ったけど1次面接落ち。
有名地元に拠点がある東証一部上場の自社サービス企業。600万の求人と450万の求人で分かれてて600万の方で応募したら書類選考で「600万は厳しいけど450万なら良いですよ～」って言われてる状態。
やっぱ相場観的にはそうだよなぁって思った。
今週1次選考だけど受かっても年収交渉時に450万しかもらえないなら辞退しちゃうかも。
有名医療系ベンチャーと車業界系のSaas。カジュアル面談の要請出すも音沙汰なし。
別の転職サイトで確認すると応募条件大卒以上って書いてたから多分それが原因。ちゃんと書いとけや。実質書類落ち。
少人数の建築系ベンチャー。HPの情報量も少なく恐らく資金調達のフェーズでは？って感じの企業。
なんとなく社長から与沢翼の匂いがする。まだマネタイズまで行けてないのに何百億とか何兆とかやたらでかい数字を言いたがる感じ。
技術スタックに対して年収が高すぎるのが逆に怪しい感じがする。
一応最終選考まで残ってるが、通ったとして行くべきかは悩みどころ……
スカウト来て応募。かなり好感触だが求人票と実態の下限年収に相違あって思ってた年収より100万くらい下がりそう。
去年末くらいから始めた転職活動。今週も面接面接面談面談面接。
自分の市場価値みたいなところは良くも悪くも痛感する。500万までのスカウトはよく来るけど600万になるとやっぱなかなかこない。これが相場観なんだろうなって感じ。
「テックリード」とか「シニア」とかのスカウトは全く来ないからまだそういうレベルではないんだなぁって。
「誰もが知る有名企業で年収600万」は多分俺のスペックだと無理ゲーで、あとはいかに穴場のベンチャー狙えるかっていうところにかかってる感じ。
それはそれで安定捨てて市場価値より高い会社に勤める感じになるわけだし将来トータルで考えるとそれはそれで大丈夫なの？って感じもある。
でも専門卒じゃ20代現年収600万くらい武器ないと婚活じゃ戦えないしなぁとも……はよ彼女作ってこの悩みから開放されたい……
エントリーする度にそこで働く未来の自分を思い浮かべるのに祈られた瞬間に全部がなかったことになるの辛い
あとカジュアル面談受けまくってるけど、これが割と面白かったりする。
「こんな有名企業だけどQAは俺がリーダーやってる案件のがカバレッジ率とかしっかりしてるんだー、バグったら人が死ぬタイプのシステムじゃないし逆に今の運用が過剰品質すぎなのかなぁ」「LeSSって開発手法あるんだー」「前職も現職もSelenium導入って微妙な感じになってるけどこのMablってテストツールだと割と良い感じかも」「今の職場みたいに運用フェーズのエンジニア部署でKPI設定を半期ごとに設定するのは粒度がでかすぎるよなぁ、この会社みたいに1ヶ月周期とかで設定した方がよさそう」「ワーカーサーバーの悩むポイントはどこも同じだなぁ、でもやっぱGoだとPHPよりも並列処理強いんだなぁ」
他の会社の運用とか技術スタックの話を深堀りして質問しまくれる機会とかなかなかないから、落ちたは落ちたなりに吸収できるものはある気がする。
あと社交辞令かもしれんけど「いやその経験と技術力で今の年収はどう考えてもおかしいっすよ」とか結構言ってくれるの嬉しい。
元アジャイルコーチとして、アメリカのガチの、ガチのシステム開発現場に、言うたらエスノグラフィ（行動観察調査）をしてるようなもんです。三流プログラマながら。
そういうリファレンスみたいなことをお伝えしたら、皆さん（Regional Scrum Gathering Tokyo 2022の参加者）が喜んでくれるかなとか思って、内容を構成しています。
ただ、僕が知っているのはマイクロソフトだけですし、自分の職場だけなので、主語が大きすぎるとか、そう言うのはやめてください。心が傷つくから（笑）
そういうのを踏まえて聞いてください（笑）。全部一次情報で、人から聞いたものではないです。ちょっとだけマネージャ関連のところはマネージャに聞いたところもありますが、基本的には自分が経験したことのみで構成します。
ウォーターフォールは使われていない
まず滝。ウォーターフォールがどれぐらい使われてるのかって話ですけど、これは簡単です。ゼロパーセント、本当に見たことないです。
だからといって本当に素晴らしいスクラムをみんなやってるかっていうと、そうでもない。どれぐらいプロセスに対してマチュア（成熟）かはチーム次第なんだけど、少なくともイテレーティブじゃないのはないし、アップフロントデザイン（開発前の仕様策定）を大量に時間をかけてやってるというのもない。
デザインドキュメントっていうのを書く人もいれば書かない人もいて、書く人が多いですけど、書いても5ページぐらい。
何年か前にサム・グッケンハイマーというDevOpsで有名な人が日本に来たときに日本のお客さんに「ウォーターフォールとアジャイルのメリットデメリットを教えてください」って聞かれて、彼が「ウォーターフォールは全くメリットがないのでやめておきなさい」って言い放って。
私は間違っていた。ごめん。ウォーターフォールは何のメリットも無い - メソッド屋のブログ
分かります。誰も使ってないんだから。やっぱりもうやめといた方がいいですよね、正直話無理があります。
次は、僕のチームがどんな感じで運用されてるかっていうお話をします。
マイクロソフトには統一プロセスとかなくて、基本的にチームをどう回すかはチーム次第なんですよ。でもだいたいみんな似たような感じでやってると思います。
基本的にはスモールチームです。どんな大きなプロジェクトであっても、スモールチームの集まりって感じです。
自分のチームについては、これがよいやり方かは分からないですが、個人商店みたいなもので。「IC」というのはIndividual Contributorですね、開発者。
マネージャからアサインされるバックログが基本的にはふわっとしているので、ICがそれを明確にします。
ICが仕様を自分で明確化して、自分でデザインして、インプリメントする。だからそれぞれがレスポンシビリティを持っていて、それぞれが実装をする。
ただ、同じマイクロサービスをメンテする役割の人みたいなのがいて、それは「Buddy」（バディ）みたいになっていて、僕の場合は例えば「スケールコントローラー」っていうのを開発していますが、スケールコントローラーのチームでバディになってると、質問というかお互いに話が聞きやすい。すぐに答えてくれやすいですね。
他のチームとかになると、ちょっとバリアがあって。やっぱりみんなそれぞれの仕事をやっているので、プライオリティがそれぞれあるんですよ。だから違うチームの人になると意地悪じゃなくて彼らのレスポンスは1日に1回とかになったりするわけですよね。仕方がないことです。
多分このチームの単位はマネージャが管理できる最大以下の人数で構成されてるんじゃないかなと思います。だから本当に自分のチームはそれぞれが個人商店みたいな感じですね。自分でレスポンシビリティを持って自分でやる。それは新人であっても一緒です。
司会）ここでちょっと会場から質問が入りました。このチームというのはどういう単位なんでしょうか。プロダクトの単位なのか、どういう単位なのか。
（右下の点線で囲われたところ）このチームはスケールコントローラをやっていて、（右上の3つのICを指して）このあたりはプラットフォームと言って中の基盤みたいなことをやってたりします。
でも基盤もかなり巨大なので、内部でいくつか分かれているんですけど、同じマネージャが見て、みんなを助けている、という感じですね。
司会）隣のチームと、このチームを分けているのは、マネージャが違うだけ？
ええと、大きな機能で分かれているというのがあります。例えば隣のチームはランタイムっていうチームなんで、Azure Functionsのランタイムを担当してるんですよ。
さて、エンジニアの評価っていうのはどんな感じになってるかっていうと、この図にはマイクロソフトは入っていないのですが、僕の友達に「ゆうさん」っていう人がいて、彼がブログでGAFAの給与体系みたいなをまとめてくれて、マイクロソフトも似たような感じです。
参考：GAFA米国本社のエンジニアの年収をジョブレベル別に比較してみた【Google・Amazon・Facebook・Apple】
こういう情報って外部に公開されてるので別に隠すことはないし、マイクロソフトの給料の額とかも調べられるんですよ。
どういうふうになってるかっていうと、エンジニアとしてランクがあるんですよね、「SDE1」「SDE2」とか。マイクロソフトの場合は「シニアソフトウェアエンジニア」があって「プリンシパルエンジニア」がある、みたいな。
このランクの人はこういうことができる、っていうのが明確に定義されていて、それによって給料が決まるんですね。
だから自分が給料を上げたかったらどうするかっていうと、プロモート（ランク上げ）してもらえるように頑張るって感じです。他の人との戦いじゃないんです。
いまより一つ上のランクの仕事をしばらくしていれば、マネージャが「こいつは今はシニアだけどプリンシパルの仕事してるからプロモートしよう」とノミネートしてくれる。
そうやってノミネートされたら次のレベルに行けるし、行けなかったら転職をする。転職するとそこでネゴシエーションしやすいので、その時に例えばシニアとかプリンシパルになれればその給料がもらえる。
ただ、そういうふうに上に行くとレスポンシビリティも大きくなるので、自分でチョイスする感じですね。自分でチョイスするし、自分との戦いなので。だから他の人と比べて不公平とか全然思わない。
給料を上げたかったら次のレベルになればいい。そういうアクションをとればいいので、あくまで自分との戦いって感じになります。
マネージャの存在っていうのは僕的にはすごい（日本と）違ってるように感じています。
日本にいるときはマネージャって進捗管理や課題管理をしたりとかして、プログラマとか開発者を指揮するとかそんなイメージだったんですかね、僕のイメージとしては。
アメリカの場合は、彼らが重視してくれるのは僕のキャリアなんですよ。僕がハッピーかどうかとか、僕がキャリアで成功するかっていうのをすごい重視してくれるんです。
これまで何人かマネージャが変わりましたけど、みんなそうでした。マイクロソフトには明確にそう定義されているんです。だからマネージャはみんなそういう動きをしてくれます。
マネージャのすごく大事な仕事に「アンブロック」というのがあります。IC、つまり開発者の人がどこかで詰まっている状態になると、マネージャが助けてくれる。ブロックされているものをアンブロックしてくれるんです。
例えば、僕が技術的に詰まるとして、誰かに聞かなあかんけど、誰か聞かなあかん人がなかなか答えてくれへんとか、そういうこともあるかもしれないです。
そういうブロックをされる状況が一番生産性を阻害すると思うんですね。
そういうときにマネージャがアンブロックを手伝ってくれる。ある人に繋いでくれたり、マネージャ経由で他の人が僕に協力してくれたりとか。
マネージャが、このプルリクエストを見たら分かりやすいよと教えてくれるとか。
あと結構面白いのは、少なくとも今の僕の職場では、納期が基本的にない感じです。
あるときもあるんですよ。どんなときかっていうと、マイクロソフト最大のイベントの「Build」というのが5月ぐらいにあって、そのキーノートで発表される予定のプロダクトみたいなもの。それが決まったら納期があるのかもしれないですけど。
マネージャも僕に対して「早くしてください」って言ったことは1回もないですね。どっちかというと、僕が「何か遅くてごめんな」とか言ってたら、「いやそんな気にすんなよ」って、「よくあることだよ」とか言われたりする。
これは多分いろんな意味合いがあるんですよね。多分クラウドのプラットフォームって、難しいことがいろいろあって、例えば自分が1週間でできるって思ったのに2カ月かかったりとか、ほんまにあるんですよ。
例えば、JVMにあるJarをアタッチするだけに見えた仕事に、僕は半年かかりました。
僕の能力のなさもあるかもしれないですけど、そういういろんな予想外のことが起こる。
やっぱり世界中の人が使うプラットフォームなので、よく分かってない実装とかしたらむちゃくちゃになるんです。ちゃんと理解して、より良いアーキテクチャを作らないとひどい目にあう。
だから多分マネージャは絶対に急かさないんだと思います。ちゃんと理解して出来るようになれば、次からは開発が速くなる。だからマネージャとしてはそこで急かさないことによって未来への投資をしてる感じなんじゃないかなと、僕は思ってます。
バックログはあり予定もあるが、達成されないこともしょっちゅう
司会）すいません、マネージャの話しに行く前に。質問が集まっていて。納期がないという話に関して皆さんが大混乱に陥っていてですね（笑）。納期がないとすると逆に何があるのか。バックログみたいなのがあるのか、ロードマップがあるのか。どういうものを始点に駆動されていて、牛尾さんの仕事が始まるのか。
バックログですね。大きなトピックだけはある。今期はこれをやろう、というのはあるんですよ。
だいたい今期はこれとこれをやっていこうというのがあって、それを荒い粒度ですけどブレイクダウンしたストーリーにして、それをICにアサインするんです。
でも、それが今期に達成されないということはしょっちゅう起こります。
思ったよりもすごく難しかったとか、あるシステムで改変が入るのでそれまで作れないとか、そういうのがしょっちゅうある。でもそれでそのICが責められることはないです。
変化は見通せないので仕方ないですよね。オーガナイズはされているけど、できなかったときはできないと認める、ということです。
司会）お客様からバックログの元になるような要求がきて、それがリリースされるまでのタイムスパンはどのくらいなんでしょうか？
僕らの場合はプロダクトオーナーみたいなチームとしてプロダクトマネージャがあって、バックログの発生元はプロダクトマネージャが決めるのですが、そのインプットソースとしては、彼らの戦略（ストラテジ－）とカスタマフィードバックですね。
あとはハッカソンでエンジニアがなにかプロポーズするときもあります。
そういうもののなかからプロダクトマネージャが、今期これをやればインパクトがあるんじゃないかと考えるものがピックアップされます。
で、それが達成されてリリースされるまでの期間は本当にピンキリです。
僕の場合は、早いときは1週間で終わりましたけど、さっきの話みたいに1週間で終わると思ったやつが半年かかったこともあります。
僕の上にはプリンシパルマネージャがいるんですね、それが日本で言ったら課長みたいなもので、その上に部長みたいなのがいて、で、テクニカルフェロー、これは事業部長みたいな感じです。
彼らの技術力はどんな感じか。
僕の1つ上の上司は、Azure FunctionsのJavaランタイムをイチから書いた人です。
その上の人は、Azure Automationの開発をしている人で別チームなので細かいところまでは知らないのですが、技術力がハンパない、ということだけは分かります。
何でかと言うと、どんなテッキーな話題を振っても、ものすごく早く深く理解するんです。彼が経験したことのないことであっても、Kubernetesでも、彼がやったことのないPythonとかでも、完璧に理解してアーキテクチャの深い話をするんです。
で、テクニカルフェロー。これはAzureの主要なサービスをイチから書いていたりします。
つまり何が言いたいかというと、僕の上司で僕よりもプログラミングができない人なんて一人もいないんです。
そしてこういう人が僕の仕事のサポートをしてくれる、応援をしてくれるわけです。
だからこんな上司に何かを説得する必要なんてないんです。彼らがテッキーなミーティングに参加して、しかも僕らにすごい鋭いアドバイスをくれるんですよ。
皆さんがもしマネージャをやるときには、こういう人たちと世界で戦わないといけない、ということをちょっと意識していただきたいんです。
3人のソフトウェアエンジニアでチーム開発をしているんだけど、3人には技術レベルに差がある。極端に表現するなら、一人がシニアで、他がジュニアレベルだ。こんな構成だともちろん一人しかいないシニアがコードレビューで時間がかかってしまうし、レビュー時の真意が必ず伝わることもないので、シニアから苛立ちを文面から感じることもある。ジュニア側もきついよなーと思って見ている。シニアが孤軍奮闘しているこの状況に継続性もないし、新しい人が入っても同じように、シニアから自信を奪われてすぐに辞めるんだろうなと思う。優秀なエンジニア、ハードル上げすぎ問題あると思います。事業のフェーズによるが、メンバーをスケールしたい時にシニアがいると足を引っ張るよ、という話です。つまり、インターンを安く使ってぴよぴよコードを書かせるのは合理的だ。
特にマネジメントの一部も持っていってくれるSIerさんのレビューがきつい。いや、ありがたい一面もあるんだけど…
特に、アサインされたての発注側/受注側エンジニアからの指摘が非常にしにくい。急に来て「何こいつ」と思われないかどっちも不安になる。
双方、同じ会社の人からのレビューであれば、成長を促す目的で実装者の視座を高めるようなコメントをして考えさせる余地を残したほうがいいと思うが、他社の人からそんなコメントを貰っても「何様だよ」と思われそうで思っていることを長々と全部書くことになる。
その結果、発注側のエンジニアの意見ばかり通ってしまう（こういう言い方したくないが、SIer努めでもここで発注側に噛みつけるくらいの人であればどんどんキャリアアップしていくという肌感がある）。
成長みたいな余地が、会社同士で閉じているのがもったいなさすぎる。だからといって、受注側が開発したコードを受注側のマネジャー・リード・シニアの人だけがレビューするわけにも行かない。
発注側のレビュアーの技術力もジュニアレベルだと、指摘内容に抜け漏れがあった場合、受注側が言われたとおり実装しちゃって後で問題になる、みたいなケースも往々にしてある。すべてリード・シニアクラスのレビューができればいいんだろうが、それができないから外注するわけなので現実的には厳しい。
準委任契約だからといってうまくいくんじゃなくて、やっぱり受注側のエンジニアがプロジェクトに「精神的に」どこまでコミットしてくれるかで、こっちもぶっちゃけトークみたいな指摘ができる気がする。発注する側だけがあけっぴろげでも、場合によってはパワハラと思われかねないやり取りに発展しかねないし、やっぱり大きく出にくい。難しい。
