この記事は「Gaudiy Advent Calendar 2022」の18日目の記事です。
こんにちは。ファンと共に時代を進める、Web3スタートアップのGaudiyでエンジニアをしている勝又（@winor）です。11月初めごろから、いちエンジニアをしていた自分が、社内で「代表Dev」と呼ばれている技術責任者になりました。
今まで明確なマネジメント経験がない自分がストレッチなロールを任されたところもあり、苦戦しながらも日々を過ごしているので、今回はその振り返りができればと思います。
かなりリアルでハードな話になってはいるのですが、同じような境遇の方やこれから遭遇するかもしれないどなたかの参考になれば幸いです。
- 1. 代表Devが新設された背景
- 2. 代表Devになる前はどんな役割だったか？
- 3. 代表Devになって最初に躓いたこと
- 4. 代表Devになって変化したこと
- 5. 今後の課題と向き合い方
- 6. まとめ
1. 代表Devが新設された背景
これまでのGaudiyは、CEO以外の役職や階層がないフラットな組織でした。プロダクト開発組織は、Stream aligned teamが複数存在するのみで、チーム内のロールはPdM、UI・UXデザイナー、エンジニアとシンプルなメンバー構成でした。この状況でもメンバーのオーナーシップは非常に高く、他職能メンバーとのコラボレーションを頻繁に行い、個々人が効率的に成果を生む自律的な組織だったと思います。
（その頃の組織体制については、こちらの記事をご参考ください。）
しかし、シリーズBを迎え急激に組織も拡大していった結果、頻繁なコラボレーションが認知負荷の増大を招いたり、合意形成に時間がかかったり、生産性が低下したりする問題が発生してきました。
この問題を解決するために、完全フラットな組織から、各チームの代表者を立てて意思決定の所在と責任を明確にし、よりスピーディな意思決定ができるような自律分散型組織へと移行しました。
この結果として、Stream aligned team以外にもDevやDesignなどの職能横断の組織と、責任者である「代表」という役割が誕生しました。その開発組織の代表が、自分が担う「代表Dev」になります。
また、この組織設計のGaudiyらしいユニークなところは、各組織の代表は各組織にいるメンバーから「選挙」で決定される点です。こうすることで、成果だけでなくメンバーからの信頼を得ないと続投ができない設計になっています。
この理由も詳しくあるのですが、少し本筋とズレてしまうので興味ある方は下記の記事を参考にしていただければと思います。
2. 代表Devになる前はどんな役割だったか？
振り返りをする前に、前提情報として、代表Devになる前の自分はどんな役割だったか？について触れることで、なぜ後述する課題にぶち当たってしまったのかの参考になればと思います。
基本的には前述したStream aligned teamに所属をし、アウトカムのためのデリバリーを達成するためにはなんでもするようなエンジニアでした。他のメンバーからは、「不確実性に対して推進力がある」みたいなところは評価いただくこともありました。
チームでは暗黙的に開発のリーダーのような役割を担うことはありましたが、明確にマネージャー的な役割を経験したことは、前職も含め今までのキャリアでは一度もありませんでした。
3. 代表Devになって最初に躓いたこと
3-1. ボールを打ち返すことに精一杯になっている
最初に躓いた点は、様々な課題や要望に対するボールを打ち返すことに精一杯になってしまうことでした。
最初はなにかあったときの一次ボール受けになっていて、スピーディーに打ち返していくように頑張っていたのですが、当たり前ですがわりとすぐにこれだとスケールできないなということに気づきました。
この課題は、今では役割を分けて権限委譲したことによりある程度は解決できています。とはいえ、リソースが限られた開発組織ですべてのボールを打ち返せるかというとそれは難しく、ボールに対して優先順位をつけたり、まとめて解決できるようにしていくことなども大切でした。
3-2. ピープルマネジメントを重視せず、問題が大きくなって気づく
元々の意思決定では、ピープルマネジメントに時間を割かないようにしていました。理由としては、今思うと自分目線の考えだったなと思うのですが、Gaudiyの開発組織でそういった問題が発生しないだろうと考えていたためです。
ただ結果的には、自分が観測できていなかった開発組織内の課題が大きくなり、問題が発生してから気づくケースが複数件ありました。この結果を踏まえて、開発のメンバーと1on1を行うようになり、継続的に開発組織の課題を検知することに対して優先度を上げるようにしています。
失敗をして気づいたことでもありますが、「エンジニアリングマネジメントトライアングル」という、エンジニアリングマネジメントで必要な3つの役割（Technology、Product、Team）の軸をつないだ図から考えても、TeamとProductをつなぐTeam Development的な部分を軽視していたということがわかりました。
また、これを参考にすると、今なにが足りていないのか？ 本当にそこが足りていなくて良いのか？という視点が得られ、それ以降の開発組織や仕組みの改善への参考となりました。
4. 代表Devになって変化したこと
4-1. 開発組織と隣接組織の成果の総和という考え方を持てた
本や記事を読んで学んだことですが、EM的なポジションになりたての方などでよくありがちなのが、コードを書く時間が減って自分のアウトプット量が減ることにより、フラストレーションが貯まることです。この点に関しては、会社や事業の目標を達成するためにできることを行うという考え方を元から持っていたのでそこまで問題はなく、開発組織全体の成果を上げていくことが重要だと考えていました。
一方で、HIGH OUTPUT MANAGEMENTという本を読み、少し考えが変わったことがあります。それは開発組織だけでなく、開発に影響力が及ぶ隣接する組織の成果を挙げることも、代表Devのロールに対する成果として大事だということです。
最終的に会社として達成すべきことは、事業目標を達成することであり、Gaudiyで言えばミッションである「ファンと共に、時代を進める」ことが最も大事です。そして、この事業目標の達成に必要な価値は、各組織から直接的に生まれることはほぼなく、ある組織で生まれた価値を他の組織がまた違う形に変換をしていき、ユーザーに届くことによって生まれます。
例えばGaudiyの開発組織でいえば、社内の管理画面開発を怠ることでコミュニティ内での施策を回すスピードが落ちてしまい、CS組織の成果を落とすような影響があったり、他にも、デザインシステムの運用を怠ることでUIデザインとプロダクトの乖離が発生し、デザインのチェックコストなどにリソースを使ってしまい、デザイン組織の成果を落とすような影響などがあったりします。
開発組織の影響は、直接的な事業への貢献と隣接する組織への貢献の2種類あり、これらを最大化していくことが大事であるという考え方を持てたし、課題が発生したときの優先順位の軸として重要な要素だと考えることができました。
4-2. 開発の役割を明確化し、様々な開発施策をクオリティ高く実行できるようになった
以前はボールが集中する課題もあったため、開発組織内の役割を新設して、開発メンバーを頼るような形に変えていきました。
プロセスとしては、開発、組織、プロダクトなどの課題などから必要な役割を逆算していきました。例えば、Stream aligned teamのデリバリーに責任をもつ開発リーダーや、BE・FEの各リーダーなどの役割を明示して、各々のメンバーに責任の範囲で自律的に動いてもらっています。
彼らのおかげで開発の施策や仕組みづくりがクオリティ高く行われるようになり、最もうまくいった改善点ではないかとも感じています。
5. 今後の課題と向き合い方
5-1. 中長期的な意思決定ができていない
代表Devとして改善しなくてはと思っている一番の課題は、中長期的な意思決定がうまくできていないという点かなと思います。この理由はいくつかあるのですが、
- 改善すべき大きな課題はありつつも、その中でどこがボトルネックなのか？が特定できていない
- ヒアリング過多になっていて、意思決定の収束までが遅い
が主な要因だと考えています。
ここは自分の力量が本当になかったなと思うところはありつつ、他の方からフィードバックをもらって変えていこうと思ったのは、不安なところがあると、逃げのヒアリングを行ってしまい、とりあえず課題を探ろうとしすぎている点です。
マーケティングやR&Dなどでも、「仮説を持たずに調査やヒアリングばかりを行うのは、すべての課題を揃えて解決策を出していくことになり、効率が悪い意思決定になってしまう」というアンチパターンが実際にあるといいます。
課題を揃えていくことも重要だとは思いますが、事業やプロダクトの不確実性が非常に高いスタートアップの環境では、意思決定を素早く行い、実際に検証をして改善していくことも非常に大切です。そのため、今後はこの考え方も取り入れて意思決定をしていくことが大事だと痛感しました。
5-2. 副業メンターの方がいることで、自分の行動やモヤを振り返られる
代表Devとして今までとだいぶ違った動きをしているところもあり、モヤや躓きが多かったのですが、こういった点を他の方に相談して意見をもらえるのは本当にありがたかったです。飲み会で率直に色々とダメ出ししてもらったりしたことは本当に感謝しています笑。
また、Gaudiyで副業をしていただいてるEMの@yowrb_0905さんと週1で1on1を行っているのですが、メンタリングをしていただいたり、EMとして働かれている経験から新しい考え方に気づかせていただくことが多く、1on1をしてもらう重要性も再認識できました。
6. まとめ
今回は代表Devになってみての振り返りをまとめてみました。良かったところもありましたが、全体的に反省点や自分の至らなさで失敗してしまったところはやはり多いなと感じました。
ただ個人的には、Gaudiyの「ファンと共に、時代を進める」という壮大なMissionに共感しており、この実現にはエンジニアリングの力が本当に大切だと考えています。そのためにも、選挙で変わる可能性はありますが、どんな形でも強い開発組織を作っていき、少しでもVisionの実現に近づけていきたいと思っています。
また、強い開発組織を作っていく文脈でもエンジニアの採用は非常に力を入れていますので、ぜひ興味ある方は下記リンクか自分（@winor）へ連絡でもいただければと思います！
明日のアドベントカレンダーはエンジニアの並木さん(@ruwatana）が担当します。
