LayerX エンジニアブログ

LayerX の エンジニアブログです。

バクラク事業部のEMは難しくて面白い!魅力と伸びしろのご紹介 #LayerXテックアドカレ #のびしろウィーク

こんにちは!バクラクの認証基盤や各種マスタデータを取り扱う「共通管理」というプロダクトチームでエンジニアリングマネージャー(以下EM)をしています @ar_tama です。最近ついに我が家でもドラム式洗濯機を導入しまして、動かすたびに文明だ〜!と叫んだり、せっせと回るドラムを見つめたりする日々を過ごしています。

この記事はLayerXテックアドカレ(概念)の40日目の記事となります。昨日はyyoshiki41の「マイクロサービス間でのデータの変更イベントと同期」をお届けしました。明日は@toshi1127がフロントエンド領域の伸びしろについて書いてくれる予定です。

さて、今回はLayerXの「のびしろウィーク」企画の一貫で、EMについての伸びしろについて書いてみたいと思います。「のびしろウィーク」については、チームメイトのid:convto33日目に詳しく書いてくれているので、併せてご参照ください。

バクラク事業部のEMロール

バクラク事業部には、約10名のEMロールを担うメンバーが在籍しています。現在、事業部全体のエンジニアの数が35名ほどですので、その比率に驚かれることもままあります。

そのうち約半数はストリームアラインドの形式であるプロダクト付のチームに所属しており、私もその中の一人です。プロダクトはそれぞれに独立して価値を提供していながらも、互いにデータや業務フローを連携させながら新しい価値を生み出しており(コンパウンドスタートアップ戦略)、したがってチーム同士も、基本は独立しつつも互いに「全体最適を諦めない。常に横を見る」の姿勢で日々コラボレーションしています。チームは主にPdM・デザイナー・EM・エンジニアで構成されており、プロダクトに関する意思決定の大部分がチームに移譲されていることも特徴です。

ミッションは「アウトカムの最大化」

EMというロールのミッションはシンプルながら難しく、「チーム(プロダクト)の生み出すアウトカムを最大化させること」。前述の理由から、隣接チームのアウトカムも同時に上げていくことも求められます。Konifarさんが自身のスタンスと称されていた「成果を最大化するために自分がコード書くかどうかもマネージャー自身が決めればよい」を地でいくスタイルで、プレイングの割合からメンバー・他チームへの関わり方に至るまで、責任範囲と裁量が大きく与えられています。

EMが関わるマネジメントは大きく分けてテクノロジー・ピープル・プロジェクト・プロダクトの4種あると言われていますが、私達はチーム全員でこれらの役割を分担したり、足りないところを埋めたりすることで、アウトカムの最大化に責任を負っています。加えて、たとえチームでカバーできない領域があれば、リソースを外から確保することも含めて期待されており、そのためチームに必要な役割の言語化を、各自が丁寧に行う傾向があります。

「コードも書くEM」

先日の「EMゆるミートアップ」にて@sh_komineがお話ししていたように、バクラク事業部のEMは、皆コードベースに一定以上習熟していることが求められています。

またプロダクトは「作って終わり」ではなく、お客様のもとに価値が届いて初めて真価が発揮されます。そのためコーディングによる技術的なプロダクト理解に加え、商談動画などによる顧客・ディストリビューションへの理解、ユーザーヒアリングへの同席、事業戦略の理解などを通じドメインに深くダイブし、日々の意思決定の材料としています。

チームサイズを下げ、ロールの再現性と意思決定スピードを上げる

これらの遂行はとっても難易度が高そうに思われるかもしれませんし、実際難しくはあるのですが、LayerXではこのロール設定に再現性を持たせるために、「チームサイズを小さく保ち、(ピープル)マネジメント対象を減らす」というアプローチを取っています。これはマネージャーの負荷を下げるだけでなく、プロダクトにおける意思決定のスピードを落とさないためにも大事なプラクティスです。

個人的には、役割ごとに人をアサインするというよりは、複数の役割を持つことができる人々が、フェーズに併せて分担し合う・カバーし合うチームの方が、変化に対するレジリエンスも高くなるためより理想に近いと考えています。そういった意味でも、いかにチームサイズを小さいままに効率よく大きな成果を上げるかという考え方が重要です。正直、今まで全く経験のない頭の使い方をしており、試行錯誤や失敗を繰り返しているのですが……、だからこそ挑みがいがあり楽しいと感じています。

EMをサポートする制度や環境

「なんでもできる」からこそ「選択と集中」が必要なバクラク事業部のEMロールですが、これらを助けるためにEngineering Officeという部署が存在しています。いわばエンジニア組織のイネーブルメントを担う役割で、よりよいマネジメント実務遂行のための型の定義・浸透や、横断での採用広報といった役割を担ってくれています。それにより、これまで個人技だったマネジメントスキルが定型化され、 プレイヤーとしてだけでなく、マネージャーとしても成長しやすい環境、負荷が個人に集中しない環境 が整いつつあります。

VPoE小賀の「マネジメントサイクル」説明資料より

「のびしろ」と挑戦

これまで述べてきた役割を、マネージャー全員が十全に果たせているかというとそんなことはなく、それぞれに課題を抱えています。以下に自身の伸びしろだと感じている要素や、他のマネージャーから多く寄せられたお悩み・課題をピックアップしてみました。

のびしろ① 短期・長期の目線を同時に持つことの難しさ

書籍「駆け出しマネジャーの成長論」では、マネージャーが立ち向かうべき課題のひとつとして「プレイングとマネジメントのバランスを取ることの難しさ」が挙げられています。

私の所属するチームはPdM・EM・エンジニアの3名、最小人数で構成されていまして(絶賛仲間募集中!)、その中でより素早く価値をユーザーへ届けるために、今私はマネジメントよりプレイングの割合を意識的に増やしています。ここで問題になるのが、プレイングに集中しすぎると意思決定がどんどん近視眼的になってしまう、ということ。タイムスパンが「スプリント」や「個々のチケット消化」に寄ると、中長期の視点を見失いがちです。このバランスを取るのもEMの役割であるはずですが、これがなかなか難しい。そのため、PdMと一緒に中長期に思いを馳せる会を定期的に開催したり、必然的に視点が広く・深くなるような仕事を間に挟んだりしています*1

タイムスパンの短いタスクは一般に不確実性が低く判断が楽なものも多く含まれます。人間は易きに流れる生き物なので、気づくと目の前の仕事ばかり追いかけて「仕事した気になってしまう」こともしばしば……。この課題に対しては、自身とチームの振り返りサイクルを確立させ、自身の立ち位置やチームとして取り組むテーマの優先度を再確認する試みをしています。

のびしろ② 個々人のプラクティスの形式知化・横の連携

チームサイズが小さいということは、マネージャーの数も比例して増えるということ。仲間が沢山いることは心強いことですが、横で目線を揃える難易度が上がり続けているのも事実です。

目線揃えの場として、週次でマネージャー同士が知見共有や相談を行う定例が設けられてはいます。しかし参加人数とトピックの多さから、それぞれの深い議論は個別に人数を絞って行われる傾向にあります。場において意思決定とその経緯について共有はできても、個々人が再現可能な「型」に落とし込むまでにはまだ数ホップ距離があると考えており、これはとても大きな伸びしろだと感じています。

また、週次定例だけでは、日々様々な葛藤をもって意思決定をしているマネージャー同士の、具体シーンにおけるプラクティスが共有しにくいという課題もあります。チームによってフェーズや取り組むドメインが異なることもあり、詳細レベルまで完全に理解し合うことは難しいのですが、これらは例えばEM同士でもスクラムを部分的に援用するなどで一定カバーできる兆しがあり、年明けからテストしていきたいと(勝手に)考えているところです。

のびしろ③ 必ずやってくるサイロ化の誘惑に抗い続ける

バクラクでは「コンパウンドスタートアップ戦略」の実践により、しばしば組織・プロダクトを横断した領域を主眼とした開発タスクが発生します。これらは「ボールがチーム間で落ちやすくなってしまう」というような「横断あるある」の課題から、「どちらのプロダクト(ドメイン)にも一定以上習熟していないと、最適な体験をデザインできない」という難易度の高い課題までを抱えており、私たちもまだこの領域に相対する上でのベストプラクティスを確立できていません。 こちらについては、@ysakura_が詳しく書いてくれているので、ぜひ併せてご覧ください!

前述のようにEM本人もドメインに習熟する手段の一つとしてコードを書いてはいるものの、こうした横断プロジェクトに深く関わるかどうかはその時の状況に依るため、メンバーの動きが一定見えにくくなることもあります。こうした場合にこそチームをまたいだマネージャー同士の連携が重要なのですが、その型化までには至っておらず、EM個々人の「よしなにする力」に委ねられてしまっています。これらは、例えば横断のプロジェクトも一つの「ストリームアラインドチーム」として(EMも込みで)チームを組成してみることや、メンバー視点でEMに求める動きを掘り下げてみるなどのトライが有効かもしれません。

私たちのチームは、認証基盤や複数プロダクトから使われるマスタデータ*2の管理を行っていることから、日常的にプロダクトごとのデータの使われ方を把握しておくことが必要とされています。そしてこれらの取り組みにおいては、個々のプロダクトへの習熟はもちろん、起きた・起きうる問題を抽象化して捉え、「同じ問題を再生産しない」ことが重要なのですが、まだまだ試行錯誤の最中です。こちらについてはid:convtoが具体に踏み込んで書いてくれているので、ぜひ読んでみてください。

また先日、マネージャー同士のディスカッションの中で、プロダクト企画部の部長が「これからプロダクトが更に増え組織も拡大していく中で、(難易度の関係で)連携を諦めたくなる力学が働くはず。気持ちが折れないようにすることと、連携の難易度を下げられるような仕組みを整えていくことが重要になりそう」と発言していたのが個人的に印象に残っています。

責務を小さく切り分けていくと、全体に対して主体性を持って取り組むことがどんどん難しくなっていきます。その中でも、プロダクト、事業、会社(複数事業の掛け合わせ)によってユーザー・社会へどんな価値を提供したいのか・していけるのかというマクロな視点を持ち続けること。メンバー全員がその視点を持ち続けるために、自ら橋渡しや翻訳をしていくこと。マネジメントスキルとして、この2つの重要性がどんどん高まっていっているのを肌で感じています。

おわりに

今回は、バクラク事業部のEMというロールが持つ面白さと難しさ、もっとよくできると感じている「伸びしろ」について、できるだけ赤裸々に書いてみました。個人的には、難易度は高いながらも頼れる仲間と明確な羅針盤、適切なフィードバックループのおかげで、ストレッチゾーン(ラーニングゾーン)の中で試行錯誤を繰り返せており、日々楽しく取り組んでいます。

バクラクは今後もプロダクトをどんどんと立ち上げ、シームレスな連携により顧客への提供価値を非線形に向上させていきます。これは既存プロダクトの継続改善、横断機能の開発、そして新規プロダクトの立ち上げと、プロダクト開発におけるほぼ全てのフェーズが同時多発的にやってくる、稀有で面白い環境です。そんな状況ですので、率直に言うと仲間が足りていません…!

私たちに加え、まだ見ぬEMロールを担う皆さんと一緒にこれらの伸びしろに向き合うことが叶えば、バクラクを通じて「ハタラクをバクラクに」できる範囲や深さを更に広げることができ、ひいては「すべての経済活動を、デジタル化する」というミッションの達成に一歩でも近づけるという確信を持っています。一緒にチャレンジしましょう〜!

オンラインで雑談したい方は、こちらからお気軽にどうぞ! jobs.layerx.co.jp

オフラインで雑談したい方はこちら。次回開催は年明け1/30です!ご参加希望の方は @ar_tama までご一報ください🙋 jobs.layerx.co.jp

*1:このブログもその試みのうちのひとつ

*2:ユーザー情報や権限管理など