マネージャーはエンジニアに戻れるのか？元執行役員が今現場に戻る理由
こんにちは、ログラスでエンジニアをやっている飯田 / @ysk_118と申します。2020年10月にjoinし現在2ヶ月ほど経ったところです。
優秀なメンバーに囲まれて毎日焦りを感じながら開発をしています。
私はこの2年ほど開発組織のマネジメント業に専念しており、現場でコードを書くのはかなり久しぶりでした。
このエントリではそんな元マネージャーがなぜ社員数人のどスタートアップに行こうと思ったのか？マネジメントから現場に戻ると何がどうなるのか？について書きたいと思います。
Generalistなマネージャー歴
前職は株式会社クラウドワークスで5年勤務していました。クラウドワークスには第二新卒的な若手枠で転職し、現場の一エンジニアから始まり、スクラムマスターやプロダクトオーナーなど様々なロールを経て2018年から開発組織のマネジメントに関わるようになりました。最終的には執行役員という形で開発組織と経営をいかに接続するか？ということに取り組んでいました。
細かい業務では、日々の1on1に始まり、事業の戦略の話やチームごとの技術的な戦術の議論、さらには会社全体の制度の議論など横にも縦にも幅広くいろいろな業務に携わっていたので列挙するとキリがありませんが、一番大きなミッションは開発の戦略と経営戦略との接続です。
とても雑に表現すると、経営メンバーで議論した方針を現場に説明して各チームの方針に落とし込むことと、各チームから上がってきている課題感を抽象化して経営の議論に持ち上げるということをやっていました。（この抽象度の違うものを同じテーブルで扱えるようにするのがとても難しい。）
5年で現場から執行役員まで経験となると、かなりのスピード感の中で任せていただいた思っていますが、良くも悪くも途中途中の経験はぎゅっと圧縮されていたように思います。
たとえばプロダクトオーナーの期間は1年でしたが理解が進んで面白くなってきたところでマネージャーにシフトしてしまいました。（もちろん自分の選択ですが）
実は前々職でも新卒で入ったWeb制作会社ではエンジニア兼ディレクターといった形で同時並行でいろいろこなすということをしていたので、ばたばたと急ぎ足でキャリアを積んでいく運命だったのかもしれません。
ここまででだいたいお分かりだと思いますが、私はエンジニアとしてはかなりGeneralistタイプだと思っています。
Web制作に関わっていた時は案件ごとに技術スタックが変わりますし、事業会社でエンジニアをやりたいと思って転職したクラウドワークスでも結局はエンジニアの枠に囚われず様々なロールを担当することになりました。
なので、技術に関しては「広く浅く」というかんじです。
大学は物理をやっていたので理論や技術の話はとても好きですが、そこに強く執着していなかった結果このようにいろんな経験をすることになってしまいました。
戦略の課題設定と技術力の関係
さて、そんな「広く浅く」の私ですが、マネージャーになるとあることに困るようになりました。
それは、「戦略の課題設定と意思決定が難しい」ということです。
マネージャーになると戦略を決めて、チームに説明し、チームを動かさなければいけません。そして良い戦略を作るためには、良い課題設定が必要です。
サービス自体がもう何年も運用しているような巨大なサービスでは開発として考えるべきことが複雑化・高度化していきます。
そうすると「広く浅く」でやっていた技術力ではそのフェーズの複雑化した技術課題を手触り感を持って扱うことが難しくなります。
当然のことながらマネージャーなので、自分でその問題を解くのではなく組織がそれを解けるように立ち回るのがやるべきことです。しかし、説明責任を果たすときに課題の解像度の高さというものが必要になります。
結局マネージャーであっても高度化した課題を扱う場合にはそれなりに高度な技術的バックグラウンドを要するという、言葉にすると割と当たり前なことを身を以て実感したわけです。
それが自分が抱えていた課題感でした。
というわけで、これまで会社組織へのコミットメントに集中していたキャリアを、一度今の自分に必要なものを整理してフラットに考えてみようということで転職を考えることにしました。
持続可能なシステム開発に向き合ってみる
SDGsなど昨今は世間でも広く「持続性」を意識したキーワードを聞くことが多くなりましたが、持続性を意識することはシステム開発においても非常に重要です。
システム開発における持続性とは、システムが大きくなったとしても
・開発速度を維持できる
・バグ発生率を増加させない
・システムから得られる利益が維持コストを上回る
ぐらいの観点があげられると思います。
これらへのアプローチ方法としては、まずテストのしやすさ、リファクタリングのしやすさがあげられます。
技術的には型があることで比較的安全にリファクタリングを進められるなどのメリットはありますが、テストもリファクタリングもどこまでやりきれるかは最終的には組織文化次第なところがあります。
したがって、次にトライする環境としては、初期から設計プロセスなどを重視しており、テストやリファクタリングの価値を組織の中で高いベースラインで捉えている、かつ自分が一度型のある言語での開発を経験したかったので型付き言語で開発しているということがひとつの条件になりました。
一方、システム"開発"が持続的であるということは、単にシステムのメンテナビリティが高いだけでなく、組織のメンテナビリティも高いことがセットになります。
そうすると、今すぐじゃないとしてもマネジメント的要素も重要テーマとして認識されていることが2つ目の条件になりました。
これまでであげた、「システムの持続性」「組織の持続性」それぞれの重要性の認識レベルが自分と一致していて、技術的には自分が学びながら還元していくことができ、マネジメントとしては自分からこれまでの失敗経験などを提供できる、というやりたいこととやれることの期待値がうまく擦りあったのがログラスでした。
2年のブランクは埋められたのか？
- 意外とやれたこと
前職はRuby on Railsで、ログラスではSpringBoot + Kotlinという技術スタックなのでかなりギャップがある中でのチャレンジでしたが、実装自体はそこまで重いものでなければ意外とどうにかなっているかなという感覚があります。
一番の理由は久しぶりにコードを書くこと自体を楽しめている、これに尽きると思います。
わからなくてもそれ自体が面白いし、詰まりながらでも寝る間を惜しんで調べてまた書くという懐かしい感じに戻ってきました。
KotlinだとRubyにない概念も多く、目パーサが効くようになるまではしばらくかかりましたが、新しいことを学んでいくということはいつでも面白いものだなと感じました。
マネージャーでもやっている人はやっていると言われたら返す言葉もありませんが、組織の難しい問題を抱えているとマインドシェア的にそんな場合ではないとなりがちです。（実際そんな場合ではないことが多い）
逆にマネージャーなのにマネジメントをおろそかにしてコードを書くことに執着していたらそれは困り物です。
しかし、今回のように一度ラベルを剥がして技術に向き合うのはいいものだなと思いました。
- やっぱり難しいなとなったこと
ログラスでは初期からDDD+オニオンアーキテクチャという設計方針で開発してきていてそこのキャッチアップも楽しみにしていました。しかしながら実際にコードを読んでみると結構迷子になりました。当時はこんなもんかな？と思いながら読んでいましたが、今思うと、
・ユースケースとプレゼンテーションのロジックがファットになりがち
・ネストした大きなTupleが多い
といった細かい課題が散らばっているのだと理解しました。
「ユースケースやプレゼンテーションのロジックがファットになりがち」というのはRuby on Railsでも同じことが言えて、MVCからはずれて異なるレイヤを作ったとしてもでかいロジックがそのまま移動しただけということが起こりがちです。
本質的には小さいユースケースに分割していくことで見通しを良くできるという話ですが、これは言語やフレームワーク関係ない話だなと感じた次第です。
ネストした大きなTupleで見通しが悪くなる問題は、Ruby on Railsの場合に近いケースを考えてみると、巨大なパラメータを扱う時や親子関係が複雑なモデルを複数一気に扱う時が近いかなと思います。これらは、Railから大きく外れなければ少々大きなものを扱ってもそこまで可読性は落ちず、かつデバッグもしやすいということであまり問題になってなかった感があります。
一方、Kotlin(もとい同様の言語仕様を持つ言語)はTupleを多用した場合、型で守っているようであんまり守れていない、かつ構造的な可読性が落ちるという問題があるのでデメリットが大きくなるなと思いました。
作る時はいろいろなものを一つにまとめて返してしまった方が早いということはよくありますが、もう一段踏み込んで正しい名前をつけていくことが必要です。
こういった話はアーキテクチャに限らずもっと細かいレベルでチリツモになるような話です。
いくらいいかんじのアーキテクチャ選定をしたとて、保守性の低いコードは生まれるものです。だからこそ日常的なプロセスとしてのモデリングやリファクタリングが重要になります。
既存コードを変えていくのは勇気のいることです。ログラスではそれに対する心理的安全性は高く保たれていて、古いコードにはリスペクトを、新しいコードにはもっとリスペクトを、といった空気感なので、リファクタリングがとてもやりやすいと感じています。
ちなみに、フォローしておくと上記の課題感は複雑な機能ではそうなっている箇所もあるということで、全体としてはモデリングにしっかり時間をかけ、概念およびレイヤごとの責務を細かく明確化しながら進めているので最近のコードはかなり見通しがよくなっています。
興味のある方はぜひ見に来てください。
(こんな雰囲気でやってます)
- 普通にバリューを出せたこと
マネジメント業の中で、ふわっとしたオーダーの要件整理や作業が見えない不確実性の高い業務などはだいぶ抵抗がなくなってしまったので、わりとすぐにバリューを発揮できた感があります。
関わっていた中で大変だったのはGASベースのアドオンのマーケットプレイス掲載です。
この機能はログラスの予算や見込みなどの計画データに対してスプレッドシートから更新申請を送る機能で、スプレッドシートやExcelなどの表計算ソフトの運用とバランスを取りながらワークフローを組むために重要な機能です。
掲載の審査にはGoogleの審査担当と英語でやりとりをする必要があり、またサービス間連携のUXのレビューも入るので社内でも色々調整したりそれなりに大変でした。とくに、今回の審査担当者の拠点が時差が12時間発生するようなところだったので、キャッチボールのコストがとにかく高かったです。
ただ、こういった技術以外も絡む不確実性の高い業務で力を出しやすいというのはマネジメント系の人の強みになるのかなと思います。そして、スタートアップは結構この手の業務が多いです。
- ギャップを感じたこと
これはほぼネタですが、現場での飲み会のやり方がよくわからなくなってしまった感はありました笑
以前は飲みとなると、マネジメントむずい・・つらい・・みたいなかんじで一人で酒を飲むか、横のマネージャーと飲みに行って一緒にむずい・・つらい・・って飲むか、メンバーと飲みに行ってメンバーが「アレがいけてないんすよぉ〜」って言うのを「せやな、どっかでやりたいな」って言うおじさんになるか、のどれかでした笑
何も考えずにフラットに飲み会に出るというのが久しぶりすぎておろおろしていたかもしれません。
しかもボドゲをやる人が多いので飲みながらボドゲやゲームをやったりするのですが、飲み会というとただ酒を飲むだけだった私からするととても文化的だなと思いました笑
とりあえずカタンは入門したぞ！
元マネージャーがエンジニアとしてスタートアップで働く意義と面白さ
真面目な話に戻します。
マネージャーのキャリアは本当に難しいと思います。
私の場合はマネージャーとしてやっていくにもまだまだエンジニアリングの経験が足りていないということが明確になったのでシンプルにこの選択を取れましたが、すでにもっと技術的バックグラウンドのあるマネージャーの方はマネージャーとしてどうやってバリューを高めていくか悩んでいる方も多いかなと思います。
マネージャーとしてバリューを高めるということは、より意思決定できる範囲を増やしていき、実際に事業と紐づく形でその意思決定に対してコミットメントを生んでいくことです。
もちろん、今目の前にある課題に向き合っていくということも素晴らしいですが、スタートアップでやることの意義はその所有感を最大限高められるということではないでしょうか。
上述の通り、システムの持続性には技術的にも重要テーマがたくさんありますが、それ以上に開発組織のカルチャーが重要です。そして、人が増えるにしたがってそのカルチャーを支えるマネジメントが必要になっていきます。
マネジメント視点も持ちながら現場でコードを書いていくということはある種の強くてニューゲーム的な状態だと個人的には思っています。
なぜなら、組織的な意思決定の力学やその結果発生するイベントについてすでに知っているからです。知っているということはその解釈でもやもやすることがないし、さらには自ら手を打つこともできるということです。
これは開発に集中する上で大きなアドバンテージです。初期から手を打てれば納得感・所有感を持って育てていくということができるようになります。
私個人としては、まだまだやれていないことが多いし、変に過去の経験に囚われている気もしているので積極的にアンラーニングして新たな取り組みにチャレンジしていく所存です。
We Are Hiring
株式会社ログラスではもう一度現場でコードに向き合いたいエンジニアを募集しています。
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか？