ここ3年ほど仕事でやっていること
僕は2018年から仕事で技術的にあまり新しいことには取り組んでなくて、新技術にもあまり興味が持てなくなってきてて、もしかしたら軽いミドルエイジクライシス的なものかもなあと思ってますが、2020年からマネジメントっぽいことをやってるのでそれについて書いてみたいと思います。
2018年からエンジニアリングマネージャーを1年ほどやり、その後組織改変があってマネージャーから外れて、2021年から再度マネージャーをやっとりますが、まあそんな大層なことはしてなくてそれよりもどちらかというと今僕がやっているのはTechnical Program Manager (TPM) に近いような気がしますが、項目を分けて書いてみます。
- ピープルマネジメント
僕の理解ではエンジニアリングマネージャーと他のプロダクトマネージャー、プロジェクトマネージャー、Tech Lead、Individual Contributor(IC)、etcとの一番の違いは人事評価を含めたピープルマネジメントをするかどうかだと思う。
カジュアル面談や面接を含めた採用関連の仕事は別にマネージャーじゃなくてもやるけど、人事評価、メンバーへのタスクアサイン、チーム異動などはエンジニアリングマネージャーが担当する。
僕はメンバーが少ないこともあり、楽な方だと思う。
なお1on1は評価の時期ぐらいしかやってない。つまり半年に1回ぐらいかな。
マネージャーによっては2週間に1回やる人もいるけど、僕はやってない。
僕のマネジメントスタイルはマイクロマネジメントはせずにメンバーの自主性に任せてて、それは意識してそうなったというより会社のカルチャーがそうだし、僕自身歴代の上司の顔を思い浮かべても、特にマネージされた記憶がないのでそうなっている。
もちろん僕の知らぬところでうまくマネージしてくれた可能性は大いにある。
1on1やらない上司もいたし、そんなもんだと思ってたら周りのマネージャーは意外と1on1してた。すごい。
この手の選手に任せて放任する型のマネジメントスタイルはサッカーの監督に例えるとベンゲル、森保、ジーコ、の流派であって、ペップ、クロップ、ブレンダン・ロジャーズ、デ・ゼルビの系統ではない。前者のタイプは戦術が無いと批判されることもあるが選手の調子がいい時は特に問題ない。
プロダクトマネージャーとプロジェクトマネージャーの違いは僕もフワッとしかわかってないが、プロジェクトは期限があってプロダクトは期限がないものだと思ってる。
受託案件で請負契約で何月何日までにシステムを納品するなんてのはプロジェクトで、そういう場合はプロジェクトマネージャーが顧客から要求を聞いてそれをシステムとしてどう実現するかをQuality, Cost, Deliveryのバランスを見て調整する必要がある。
納品したら終わり。もちろん納品後に保守のために準委任契約で何人月とかそういうのはありえるが、それはまた別。
プロダクトは例えば何らかのWebサービスで、サービス終了にならない限りは続く。
ユーザに目に見える部分の機能開発については2週間ごとにsprintして、releaseしてというのはよく見るケース。期限に間に合わないfeatureは次のsprintに回す。こういうのは受託案件のプロジェクトマネジメントではできないこともあるだろうが、自社開発ものなら可能。ただ期限が延び延びになってグダる危険性もある。
僕は2020年から内製のクライアントログ収集システム、簡単にいうとGoogle Analyticsみたいなもののプロダクトマネジメントに関わっていて、iOS/Android/JSの3種類のSDKをクライアント開発者に開発してもらってそれをクライアントアプリに入れてログをとばし、バックエンドのデータ分析基盤に取り込むということを3年ほどやっている。
これ以前にも内製のクライアントログ収集システムはあってまあ今も現役なのだが、それをリニューアルしようとしている。
2週間ごとにsprintとかは特にやってなくて週次の定例でissueを確認したりSDKのupdateが必要そうなら対応をお願いしたりしている。
複数のチームをうまく調整するのが僕の仕事で、specが曖昧ならwikiにspecのたたき台や疑似コードを書いて定例の場で議論してfixするようにしている。
良くも悪くもマイクロマネジメントしてないので、そんなにかっちりと何月何日にどの機能がリリースされるかは決まってない。
なので他のチームから見てるとアウトプットが見えづらい可能性はある。
僕はバックエンド側はともかくクライアント側のことは門外漢だったがたまにクライアント側のコードをチラ見することもあり、Java/KotlinはともかくObjective-C/Swiftは全くわからんなと思いながら見ている。
iOSとAndroidだとアーキテクチャも違うし、Apple QAもあってbug fixできたからすぐリリースされるかというとそうでもないし、リリースできたとしても古いバージョンのアプリを使い続けているユーザはどうしてもいるので、その辺の考慮が必要になってくる。
バックエンドについては僕自身がコードを書くということはないものの、ある程度は把握している。一応pull requestのreviewerにはなっているがコードチラ見してapproveしてる。
ただkubernetes周りはあまり分かっておらず、まあこれもステートレスなAPIサーバーを動かすならともかく、FlinkやAirflowのようなミドルウェアをk8s上で運用するのはちょっと手間がかかるというか、例えばk8s nodeが不調になったときにアプリが不安定になることがあるようでノウハウが必要そうだなと思っている。
どんな言語、ライブラリ、フレームワーク、ミドルウェアを採用するかは基本的には当事者であるメンバーが決めることでマネージャーがトップダウンで決めるということは原則としてない。
ただとはいえあんまりいろんなものが乱立しては困るので、どれかに選択と集中していく傾向はある。言語はJava or Kotlinが多く、ミドルウェアというかストリーミング処理の方法としてはFlink使う方向になっている。
Table FormatはIcebergを使っている。
Hiveはまだまだ現役だが、段々とSparkに移行することにはなるだろう。ただSparkの場合JDBCなりREST APIの口がないというか決定打がないので、そこがHiveからSparkへ移行する際に障壁になる可能性は高い。Kyuubiでいけるならそれになるかも。
テクノロジーマネジメントとはちょっと違うかもだが、月一ぐらいの頻度で社内でカジュアルなTech Meetupを僕主催でZoomでやっていて、各チームでやっていることを僕がwikiで見つけて面白そう、他のチームの人にも役立ちそうだったら発表をお願いするというようなことをやっている。発表に立候補してくれる人もいて嬉しい。リモートワーク時代だけど良い技術交流の場になってるといいな。
僕自身がどうやって新技術をキャッチアップしてるかというと、仕事に関連するプロダクトの社内wikiを見てそこで使われている技術をググったりコードをチラ見したりSlackでの議論を追ったり、上記Tech Meetupで勉強したり質問したりしている。
自分で手を動かしているわけではないので、表層レベルにとどまっているとは思うが、それほど勘所は外していないつもりではある。まあ僕の意見で採用する技術ががらっと変わるということもないと思うし、今のところはそんな感じの落とし所になってる。
