6月から、 株式会社ココペリ というところで働いています。
mobile.twitter.com
これまで働いた FOLIO や CADDi に入社した際はサーバーサイドアプリケーションエンジニアのポジションから始め、エンジニアリングマネジメントも行うようになっていたのだが、ココペリに関してはオファーの段階でエンジニアリングマネージャー (EM) のポジションの話を頂いた。実際に、入社してから (たぶん) 1行もコードは書いておらず、日々 EM としてのあれやこれやに取り組んでいる。
ココペリに加入した時点で私が組織内で唯一の EM となる状況もあり、エンジニアリング職のメンバーのみならずそれ以外の方々も含めて、「こいつは何をやるヤツなんだ？」という視線を多かれ少なかれ感じながら、日々の業務にあたっている。
これまでの職場では「必要に応じてサーバーサイドエンジニアとして働くことも、エンジニアリングマネジメントをすることもできますよ」というスタンスで働いていた。特に CADDi に加入したときには、CTO からは「ゆくゆくはマネジメントを担ってほしい」という期待値を確認しつつ、最初は現場のエンジニアメンバーからの信頼を得るためにエンジニアとして手を動かすようにしましょう、という配慮をしてもらい、機能開発やテスト改善を実行しつつ開発プロセスの中に入って一緒に整理をしたり、持ち回りの勉強会に早めに登場したりしていた。
対して、ココペリに転職するに際してはマネジメントに専念することもあり、会社で利用している技術要素と自分の経験が全く重なっていないことを転職のブロッカーとしないことを決断をした。実際、私が職務として主に経験してきたのは JVM 系の各言語 (Java, Scala, Kotlin) と Rust だが、一方でココペリのプロダクトはほとんど PHP で動いており、一部 Go を使った新規サービスや、既存サービスの書き換えが行われていたりする。そんな経験言語のギャップの話を自己紹介やメンバーとの初回 1 on 1 でも包み隠さず伝えていることもあり、余計に「こいつがマネージャーに入って何ができるんだ？」と思われても不自然ではないような状況だと認識している。
そんな折、 Scala関西Summit でもお話したことのある id:daiksy さんが、同じように EM として転職された話を書かれているのを目にした。
daiksy.hatenablog.jp
自分の悩みは だいくしー さんと比べれば足元に及ばないような話ばかりかもしれないが、共感できる部分が多くて、「あぁ、方向性は間違ってないんだな」と安心したりしている。
「観察」自体は成果を産まない
入社してすぐは、正社員/業務委託/派遣 など雇用形態を問わず、私がレポートライン上関わることになるメンバー20人弱や、部署こそ違えど同じミッションを担うメンバー、ほぼ全部署のマネージャーとの 1 on 1 を通して現状の確認を行った。何事もまず「観察」であり「計測」である。過去に起きた出来事や足元で起きている事象も、視点が変われば見え方も変わる。会社設立から14年、ソフトウェアによるサービス開発・提供が始まってから約6年というココペリの歴史は、上場企業としては短く思われるかもしれないが、その間にも組織は様々なイベントを経験しており、知るべき歴史的経緯は掘れば掘るほど出てくる感覚がある。私自身が最近勤務していた2社が創業して3~4年のスタートアップだったこともあり、大河ドラマのような重厚感さえ感じることも多い。
いろいろな気持ちを抑えて「観察」を重視するスタンスを保っているのがこの1ヶ月であるが、観察するという作業こそ、その作業自体が成果を生み出さない最たるものであり、ソフトウェア開発に於ける「テストは品質を向上させない」という至言に近いものを感じている。マネージャーの仕事の大部分は成果が見えづらい中で、実際に成果に結びつかない作業が多くを占めているタイミングなので、感じる不安も大きい。
しばらくはこのことに耐えるしか無いのだけれども、自分は だいくしー さんよりもビビりなので (たぶん)、入社1ヶ月のタイミングを待たずに、入社初日から日報を社内グループウェア (Notion を使っている) に投稿して、その日に行った仕事を振り返るようにしている。ちなみに、そんな私の様子を見たメンバーもひとり、ふたりと真似して日報を書いてくれるようになったのは、意図していなかったけれども嬉しいことだった。
日報を積分すれば月間の振り返りになるわけでもなく、手を止めてじっくり振り返って見えてくることもあると思うので、自分もそろそろ1ヶ月の振り返りを書いてみるかな… と思っている。
「観察」と「直接的な干渉」と「間接的な干渉」
前述したような「こいつは何する人？」という視線が多少なりともあることを自覚していることもあるし、いきなりポジションをかざしながら大鉈を振るうようなコトをしても何の成果も出ないだろう。
一方で、刻一刻と悪くなっていく状況が目下で繰り広げられている中での「観察」は、まさに「指を咥えて観ているだけ」になってしまう。ではその状況で直接手を出してよいのかと言えば、だいくしー さんの言うようにそれがメンバーのストレスになることもあるし、チームが自律する機会を失う可能性もある。特に自分が唯一の EM ともなれば、大きな組織のごく局所的な問題の解決に奔走したために全体がうまく回らなくなるリスクだってある。なので直接的ではないアプローチで様々な働きかけをしたいのだが、それはそれで成果が出るまでのリードタイムが長くなるから焦る気持ちも生まれる。
問題がどの程度致命的かという問いに対する回答は定量的には下せないことも多いので、最後の最後には少なからず主観的な選択をしなければいけないことも自覚しつつ、観察と干渉のバランスや、干渉の直接的なアプローチと間接的なアプローチのバランスは本当に難しいなと思っている。
思考 (およびインプット) をする時間
先日、日々つけていた「日報」と、「自分がやりたいこと/やるべきことバックログ」(個人的な「ざっくりリスト」を持っている) を見返していたときに、日々「観察」の作業を重視するあまりに思考する時間が取れていないことに気がついた。最近の仕事は、メンバーと隔週で設定している 1 on 1 と、状況把握のための各種ミーティングへの出席、そして入社当初から具体的に動ける採用活動が大半を占めてしまっている。しかし観察するのは何らかの成果を出すためだ。そして、成果を出す行動をするためには、観察の中で目についた表面的な事象に対応するのではなく、事象の根本に横たわる問題への理解とアプローチが重要だし、根源的な問題にアプローチすることで複数の問題を解決できる可能性だってある (そうでもしないと時間と気力が足りなくなる)。「観察の作業をしただけで仕事をした満足感を得てはいけない」ことは、言葉にすれば当然のことであるが、改めて自分の肝に命じたいなと思った次第だ。
採用PR
ということで、ココペリではソフトウェア・エンジニアリングに関わる職種は (リクルーティングサイトに載っていないポジション含めて) 全方位募集中です。少しでも気になったら、すぐの転職の機運がなくてもぜひ声をかけてください。本稿は文量が増えちゃうのも良くないと思い、なんで私がココペリに入ったのかとか、何が面白いと思っているのかについては言及しませんでしたが、そこらへんの話もできるかなと思います。
www.kokopelli-inc.com
それでは。
