Career Development Talk

そんなタイトルのメールが上司から来たのでクビを覚悟したがそういうものではなく、career development についてできることがないか話し合おうじゃないか、という manager best practice 的なものの実践だったらしい。 1:1 とかの仲間か。

いま検索さんに "career development t" と入力したら "career development talk with manager" と suggest されたので割と一般的なものの模様。ざっと眺めた感じあまりやばい発言はせずに乗り切った気がして胸をなでおろす。幸い自分は本音と建前がさほど乖離せずに済んでいるので、基本的には考えたことを話せば済んだ。

はー給料据え置きで AI 人材になりたいなーみたいなファンタジーはあるわけだが、これは本音とかいう以前になんの現実味もないし上司にできることもないと思うので、もうちょっと現実的かつ生産的なキャリアについて考える。

自分は今のチームにはもう 2-3 年いてもいい気がしている。3 年はちょっと怪しいがたぶん 2 年ならいける。電話機部門が underdog として勝負をしているかぎりいまのチームの持ち物は重要製品のはず。そして飽きっぽい勤務先といえどもあと 2-3 年くらいは諦めずに電話機づくりを続けるだろうと踏んでいる。時間がかかるのはわかっているし、その前提で高い掛け金を積んでいるからね。

そしてスポンサーである会社のやる気は製品への期待値となり、結果それなりに色々やるべき仕事が生まれる。それに便乗してできることを探せばよい。仕事の製品があきらめムードだったり迷走してたりすると会社員として仕事を探すのは厳しい。しかし諦めおよび迷走は現実にはよくある。だから現勤務先内の職としてそれがなさそうなのは良い。

UI とか新機能とかは締め切りも一層厳しいからやりたくない。となると引き続き性能仕事でいいかなと思う。ただ「性能」といったときに面倒を見られる範囲は広げていきたい。あと自分のチームのコードに閉じずチーム外のコードも理解してフルスタックぽく仕事ができるとよい。他のチームの人に直してもらうよう頼んで待つだけとか嬉しくない。(今日も一つやった。)あとそういうのを頼むミーティングとかしたくない。基本的にミーティングとか他人の世話とかしたくないんでクオートアンクオート TL は遠慮させていただきたい。隣の TLM がそういうの得意なんであの人に頼っていいですか。あと性能バグを直し続けるのは sustainable な感じがしないので全体のデザインを見直して性能劣化しにくいアーキテクチャに直していくことにも時間を使いたい。バグ直し続けるの疲れた。ただ妻子あるんでそんなにガツガツは働けません。

というようなことを話す。(TLしたくない、あたりは会社員として意識が低すぎる自覚はあるのであまり強調してない。)

上司のフィードバックとしては

  • 他のチームにフルスタックでやるなら会いに行って話を聴くと良いよ。どの隣接チームも喜んで教えてくれるよ。
  • 性能バグはチームの他のメンバーを訓練して負荷分散できるようにするといいよ、そうやって時間をつくってまとまった仕事をするのが大事だよ。
  • デザインの変更は提案をまとめてチームにプレゼンするといいよ。
  • 家庭優先重要。まえバーンアウトしちゃったひとがいてね・・・

などであった。そっすね・・・まっとうなフィードバックであることよ・・・。

最後のやつをのぞくすべてのフィードバックが他人と/他人になんかしろ、というものである点に苦手意識があぶり出されている。とりあえず人と話すのいまだに英語苦手なんでもし時間をつくれたら英会話行くかもしれないんでそのときは助成金つかうけどよろしくおねがいしますね、と伝える。全額出してもらえる転勤直後にもうちょっと頑張っとくんだった・・・。

自分はフルスタックの理解は人から教わるのでなく自分でコードを読み解く intellectual challenge を重視しているが、まあそれはそれとして全体像を当事者に聴くのは良いかもしれない気はしてきた。ただ単に聞きに行っても時間の無駄になりそうなので準備してインタビューしたい・・・とかいってるといつまでたっても進まなそう。

バグを他人にたらいまわすのもあまり好きではない。みんな忙しいじゃん。開発者が裁かなければいけないバグの絶対量の多さが問題なので、それをシステマティックになんとかしてくれ・・・というのが願いなわけだが、そういう目星はないので他人にたらいまわすのが少なくとも短期的には妥当なのかもしれない。訓練しろと言われてもなあとは思う。

デザインをプレゼンしろ・・・とかいわれてもなー。ただ締め切りのある世界で皆がいじる大きなコードベースを書き換えるのだとしたら、さすがに完全に exploration based ですすめるのが厳しいのはわかる。妥協は必要。一方で自分は design doc の review meeting とか API の deck presentation とかにまったく価値を感じていないので、もうちょっと自分の納得いく方法を考えたい。

など、仕事について考えるいい機会になった。フィードバックも、素直にいうことを聞くことはないにせよ自分の stubbornness と会社員としての期待値のギャップを知らせてくれる点で価値あるものだった。A career development talk with manager, あったらあったでいいものかもしれない。上司への評価がちょっと高まった。

具体的な action item を決めて prioritize するにはもうちょっと考える必要あり。