https://note.com/fukuharatamanegi/n/n57ad71eeaa9d
ひろゆきさん含め、テック界隈で引用された記事です。
私も以前には困ったエンジニアがチームにいる経験がありました。マネジメントではない側だが、フォローに余計な労力をかかってた印象です。
一方、会社研修ではポジティブに人を伸ばせようという話もありました。
この話はエンジニアに限らずだと思いますが、ラウンジの皆さんはどういうマインドなのか気になるところです。
172票
25
コメント一覧
前提がシアトルのAmazonなんで、そりゃ世界中から優秀な人間がいくらでも集まるんで、下位数%を切っても成立するよなと思いました。
世の中ビッグテック以外の会社が
当たり前ですが多いので、ビッグテックの流儀を一般化するのは難しいと思いますね。
一般論としてはジュニア比率が高いチームだと少ししんどいなぐらいの気持ちはあります。
(編集済み)
投稿者
選択肢作る時に、「売り手側か買い手側かにいるか次第」を加えるか迷いました。
多すぎると選ぶのに迷うから、コメント任せにしました。
やはり人を選べる会社もあれば、選べるない会社もありますよね。
現実問題として、出来ない人のフォローは周囲にとってかなりのストレスになりますし。。過去の会社でいろいろ経験しました。
いまの会社で最も気に入っているのは、「全員がリーダーとして振る舞うことができる」ところです。自分の周囲には実際に各社の元リーダークラスのメンバーが集結しており、何においてもとても話が早いですし、つまらないことで時間を取られることが少ないです。
その代わりに自分がパフォームできない側になったら居場所がなくなる覚悟もしています。
投稿者
一緒ですね。
中途半端なスタートアップからメガベンに入って、「話が早い感」はあります。
----
自分は以下のことで思いがかなり揺れてます。
ネットでよくある仮説:
賢い人は、どのレベルの人にも上手に説明できます。
仮説からつけた結論:
仕事できない人をフォローできない自分が悪い。
仕事で実感したパターン:
仕事ができる人は、説明が少なくてもすぐ全貌を掴めます。
掴めた内容も上手に伝達していきます。
生産性があがり、むしろ自分は相手のアウトプットから学びが多く、刺激を受けます。
(昔の自分のメンターや自分がメンター務めた時にフォローした例)
できるエンジニアはマネジメントやってて、メンバーはみんなゴボウくんみたいな企業の方が多いんじゃないでしょうか。
日本の会社はこのケース多いですね。勿体無い。
その他→何もしなくても(PIPで)いなくなるよね。
思考がビッグテックに染まり過ぎてる自分に気づいた。。
1人ダメで5人優秀って比率だから成り立つ話。逆の会社が多いよね。
コメントはユーザーに削除されました。
すみません、単純な疑問としてできない人が多様性で保護されるは聞いたことないんですが、Googleではそうなんでしょうか？
それとも女性・黒人・メキシコ人・アジア人等の白人健常男性以外の人は絶対できない ということなんでしょうか？
PIPなどで勝手にいなくなるの待ちますね
フォローした方が自分の都合良ければフォローすると思いますが基本的に個人プレーだと思ってます
あくまで入社直後の基本的なサポートはする前提です
困ったエンジニアが情報漏洩やセキュリティインシデントのようなマイナスの生産性をもたらしたことが複数回あったので、早く外したいと感じます
日本でかつサービス開発チームではないという違いはありますが、｢まあそうなるよな｣という感覚は共通にあります。私はAWSですが、お金と知名度を武器として、role & responsibilityにたいしてオーバースペックな人を採る傾向が強いです。その結果として、職務に必要な能力が不足した人がとてもレアです。レアケースの是正なので、｢単に外す｣という組織運営が成り立つのかと思います。
クライアントワークのPjMですが、若手なら育てよう、シニアなら使い所を探そう、いずれでもチームのパフォーマンスに無視できないマイナス影響を与えているならリジェクトしよう、という感じです。
どうしても使ってくれとマネージャーが言うなら、対価(追加予算、スケジュール、マネージャーの直接フォローなど)を要求します。
サービスチームのプロジェクトマネージャーができない人だとわりとよく悲劇が起きます。（というか起きてました）。
そういうリソース管理をする本人が1番リリースされた方がいいのに、それができないので😭
記事を拝見した上で、
-プロジェクトの状況
-チームのゴールが何か
な気がしております。
記事では、デッドラインが決まっており、リリース優先であるため、教育コストに労力を避けないフェーズだったので、このプロジェクトに置いてはタイトル通り出来るエンジニアだけがいた方が良かった？のだと思います。
ただし、チームとしてのゴールが今後のメンテナンスも含めて長期的なものであった場合は、タスクを分割してでも小さいものをアサインすべきでは、と個人的には思います。
(記事だけでは全てのコンテキストがわからないのであれですが)
コメントはユーザーに削除されました。
書いていないけど、ゴボウくんはPIPされたんでしょうね。
コメントはユーザーに削除されました。
これとか有名だと思うので、ぜひいろいろ意見聞きたいです。
・ジュニアを受け入れないのはミスを受け入れない会社の文化の現れ
・ジュニアを受け入れないのはキャリア構築に理解のない会社文化の現れ
・シニアの給料はジュニアの給料に対して生産性が比例しない
・ドメインに慣れたジュニアがコードを書く方がドメインに慣れていないシニアがコードを書くよりも生産性が高い
https://portalshit.net/2018/10/02/we-should-hire-junior-engineers
初めて読みました。
ジュニアを招き入れ育てる事が会社にとって良い事だと理解しつつも、その理由を文化の醸成とかフレッシュな活力をもらうとかフワッとした説明しか聞いた試しがなかったので、この記事はロジカルに言語化されていてとても腹落ちしました。
ジュニアでもピンキリで、1年2年経ってもずっとジュニアなジュニアと、半年くらいでシニアと遜色ないレベルになるジュニア、言ってしまえば仕事ができるジュニアと、仕事ができないジュニアがいるんですよね…。。
その違いが出るのが個人の理由だけじゃなくて組織・チームに起因する原因もあると思いますが、ジュニアにしろシニアにしろ仕事出来ない人とのコミュニケーションはシンプルに楽しくない…w
たしかに、「ジュニア:シニア = 仕事できない:仕事できる」ではなく、4象限で、重要なのは仕事ができる人であること、というのがミソっぽいですね笑
興味深い文書ですね。｢ジュニアなメンバーがチームに多様性を注入してくれる｣、｢開発プロセスの堅牢さを試されるからより良い仕組みになっていく（はず）｣などは、面白い視点でした。後者については、よっぽど上手くやらないとプロセスや仕組みが重くなっていってみんなが不幸になりそうな気もしますが。。。
ちなみに、元投稿の記事では｢ほぼ全員が30歳以下｣と書かれていて、この記事のテーマとはちょっと異なる状況かもしれません。AmazonではNewGradsも取っていて、ただし途方もなく優秀な上澄みだけを採用しているんですよね。。。私はシニア層に当たりますが、今どきのNewGradsと同じ土俵で勝負しなくて済んでほんとによかったとひそかに胸をなで下ろしています。
思いましたが、会社や雇用主視点ではジュニアなエンジニア、給料が安いエンジニアを雇うことも理に適う一方、開発チームの一員としての雇われの視点では、できない人の尻拭いが発生したりなども想像つくので、必ずしも好ましいとは言えなさそうですね。
チームメンバー全体のスキルアップがされれば自分のため会社のためにもなるためできない人でもワンチーム、育成に力を入れます！
という顔をしながら作業や最低限のドメイン知識は教えますがキーとなる技術の部分は自力でなんとかしないなら放置、またはいなくなるように根回しします
私は氷河期末期、自己責任世代ですからね
本心では将来自分の代替になりうるような人材をわざわざ育成する気はありません
