Konifar's WIP

親方!空からどらえもんが!

VPoE READMEを書いて3ヶ月経った振り返り

2022年1月からKyashで VP of Engineering(以下、VPoE)という役割で開発組織全体を見ています。VPoEになった背景はまた別途書くとして、この3ヶ月は反省も学びも多かったので振り返りを書いておきます。

自分がVPoEになった時、VPoE README というドキュメントを社内に共有しました。同じ内容をKyashの採用GitHubリポジトリで公開しています。

github.com

今回はこれを自分で読み返して引用する形で振り返ってみます。先に注意をしておくと、体系だった話やどこでも応用が利くような話というよりは、完全に自分個人の振り返りの内容になっています。

README書いてよかった

READMEを書く目的を以下のように書いていました。

VPoE の最初にやるべきことは、何をミッションにして何をやっていくかを定義し、周囲に理解してもらうことだと考えています。その一環として、このドキュメントを書いています

この目的はある程度果たせていたと感じています。「何を考えているのかわかってよかった」というフィードバックも何人かからもらえました。

抽象度の高い課題に向き合うことが多く、自分自身何を成すべきなのかわからなくなってしまうこともあったんですが、そういった時に立ち止まって読み返す起点を作れたのもよかったです。今もまさに振り返りに使えていますしね。

ちなみにこのREADMEを書くにあたって、何人かの先人の知見を参考にさせてもらいました。特に、以下の方々が公開してくれている情報につよく影響を受けています。

大きな事業貢献はできていない

READMEの中で、ミッションを以下のように書いていました。

  • VPは、経営陣が描いた事業の成長を達成するための『実行』に責任を持ちます
  • VPoE は、その中で『Techチームの関わるプロダクトデリバリー全体』に責任を持ちます
  • たとえばプロダクトの開発プロセスを改善したり品質を向上させたり、あるいはメンバーが楽しく働けるような環境を整備したり、さまざまな期待があるとは思いますが、すべてユーザーに価値を届けるプロダクトデリバリーを目的として取り組んでいきます

この3ヶ月、正直この実行責任は果たせていなかったと感じています。

事業でやりたいことに対して十分な人数のエンジニアがいない中で、2月に開発の組織体制を変更しました。まだ試行錯誤の段階で、自分がVPoEになる前と比較してプロダクトデリバリーの速度や質が大きく上がった、というような結果も出ていません*1

組織の改善と並行して採用活動もリードしていましたが、結果としてはこの3ヶ月でエンジニアの採用人数は0人でした。

そんなにすぐに効果が出るものばかりではないと思いつつも、結果を求められる役割なので経営陣やEM、メンバーにも相談しながら軌道修正していっています。

1年先を見た意思決定ができていない

READMEの中で、ビジョンを以下のように書いていました。

  • 『知り合いを誘いたくなるようなチャレンジングなTechチームを作る』を目標として取り組んでいきたいと考えています
  • 自分の経験上、所属する組織に誇りを持てる状態ができると、プロダクトや事業にも必ずよい影響を与えます
  • そのためにはプロダクトや事業をよくしなければならないという相互の依存関係ももちろんありますが、目標地点は「自信を持って自分の知り合いを誘えるくらいの状態を作る」というところに置いてやっていきます

振り返ってみると、日々やらなければいけない業務に追われて2ヶ月先くらいのことしか考えられていませんでした。結果、事業で必要なプロジェクトをどう進めていくかといった短期的な話に頭を使い、腰を据えてチャレンジをできる組織作りに取り組めていなかったと思います。

ここはかなり反省をしていて、「1年後にどういう状態を目指したいか」を明確にした上で、事業にも貢献しつつ技術的なチャレンジにもきちんと取り組める体制を作ろうとしているところです。

場合によっては、一時的に開発チームでの事業の進みが遅くなることもあるかもしれませんが、1年先の姿を経営陣とすり合わせながらREADMEのビジョンの達成に向けて動いていこうと考えています。

フィードバックは自分からもらいにいく

最後のお気持ちの部分には以下のように書いていました。

  • VPoE という役割自体が自分にとってはチャレンジで、おそらく今後うまくいかないことも多いと思います
    • 日々アップデートしていかなければいけないので、そのためのフィードバックをいただけるととてもありがたいです
    • 「こうしてほしい」「これは嫌だ」「しっかりしろ」みたいな率直な意見を歓迎します。言ってもらわないと気づけないことも多いですしね

3月に入って、自分がCTOの@ymzkmct以外からフィードバックをもらえていないことに気づきました。

そこで、フィードバックを募集していることを周知して協力してくれる人を募り、10人に30分くらいずつ「ネガティブフィードバック縛り」で意見を聞きに回りました。

Kyashのメンバーは良くも悪くも優しい人が多いので、あえて耳の痛いネガティブフィードバックに限定するくらいにした方が自分の改善点を引き出してもらうことができてよかったです。こういうフィードバックは1on1でもなかなか言いにくいみたいなので、フィードバックだけを目的とした場を設定した方がよいんだなと学びました。

情報の透明度が低くなってしまっていた

メンバーからのフィードバックのひとつに、「何をやってるかわからない」「距離を感じる」というものがありました。

READMEには以下のように書いていたので、自分の共有など情報の透明性に対するコミットメントが足りなかったということですね。

VPoE の最初にやるべきことは、何をミッションにして何をやっていくかを定義し、周囲に理解してもらうことだと考えています。

  • 課題を正しく把握することも、自分の役割のひとつだと考えています。もし「なんだか相談しにくいな」と感じたとしたら、それは VPoE としての役割を果たせていないことになるので教えてほしいです

ほとんどの会議や決定事項のドキュメントは公開していましたが、知ってもらう動きが少し足りなかったことに気付かされました。これに対するアクションとして、3月の終わりから週報を書いて今取り組んでいることや悩みを知ってもらったり、開発チームの定例で考えていることを話したりといった工夫をしています。この記事自体も、メンバーへの共有を兼ねています。

また、自分がやっていることや考えていることの共有だけではなく、事業やプロダクトの状況もより透明性を高めて伝えていく必要があると考えています。情報の偏りはメンバーの自走を阻害し意思決定のスピードを鈍らせる上に、組織の歪みの原因にもなりうるからです。自分だけではなく経営陣やEMとともに情報の透明性にはこだわって高めていきたいですね。

ハレーションを恐れすぎ

メンバーからの他のフィードバックに、「ハレーションを恐れすぎ」「ビビりすぎ」というものがありました。要は、「顔色をうかがっていて本来やるべきことを進められていない、または進みが遅い」という話です。

READMEを読み返してみると、スタンスを以下のように書いていました。

一番の優先順位はメンバー

  • メンバー、プロダクト、事業の順に大切に考えます

  • VPoE として大小さまざまな意思決定をしていくことになると思いますが、決定に対する納得感を重視します

ここの考えは今でも変わっていませんが、知らず知らずのうちに説明責任を気にしすぎていて、本来やるべきことを見極めて逆算するというプロセスを踏めていなかったように思います。極端に言えば、説明できるかどうかという観点で意思決定を考えてしまっていたということです。

納得感はもちろん重視するべきですが、それが一番最初にくるべきではないと考えています。まずは実行責任を果たすためにやるべきことを見定めて、その上で意見をもらいながらきちんと説明責任を果たすという順番で考える必要があります。当たり前の話かもしれませんが、自分はマインドを切り変えるのに時間がかかりました。

メンバーからの「ハレーションを恐れすぎ」「ビビりすぎ」というフィードバックは、「まず堂々と考えを示せ」という意味ですから、ありがたいことに背中を押してもらっていると言えます。

権限委譲しきれていない

最近の自分のカレンダーを見ると、週に20〜25時間をMTGに使っていました。内容を分析してみると、長期目線での方針を考える時間を取れず、今困っている課題を何とかすることに時間を費やしてしまっていました。明らかに自分がフォーカスすることを決められておらず、本来自分がやらなくてもよいことをやってしまっていたと思います。もっとメンバーを頼って権限委譲をしていく必要がありました。

READMEには、権限委譲について以下のように書いていました。

頼って委譲

  • 自分が本来フォーカスするべき役割に集中するために、それ以外のことはなるべく他のメンバーを頼って委譲していきたいと考えています
    • 情報の透明度を上げたり、チームやメンバーのミッション・役割を明確化したり、委譲のために必要な仕組みづくりは自分の役割として取り組みます

振り返ってみると、委譲したいと言いつつ「頼みたいけれどやりたくないことじゃないかな。モチベーションを下げてしまわないかな」といった感じで、ここでもメンバーの顔色を伺うような考え方をしていたように思います。

もちろん相手のwillを考慮することは大事ですが、それを最初に考えるのではなく組織としてどうするべきかを先に考えるという順番に最近ようやく切り替えました。その上でメンバーに委譲の提案をしてwillを確認する、という流れで進めています。実際にお願いしてみないことには何もわからないことの方が多いです。実はメンバー自身も自分がやりたいかどうかわからないということもあります。

具体的には、4月から採用活動領域の委譲を進めています。「見極めをいい感じにする責任者」や「面接を受けてくれる人数を増やす責任者」のように役割を切り出して、チーム全員で採用活動に取り組む体制を作っていっています。

実際にこの進め方を試してみて、「相手に期待を伝えると自分が思った以上にそれに応えようとしてくれる」ということを知りました。実際に、自分がリードするよりずっと早くよい取り組みを進められていてとても助かっています。

まとめ

ざっと振り返ってみましたが、反省の方が多いですね。まだ成果が見えないものも多く、"失敗"ですらないという感じです。

3ヶ月やってきて何かしら成果を出したかったですが、VPoEという役割に期待される大きな成果はまだ出せていません。他社のVPoEやEMの方々の取り組みをみると、すごく深く考えて色々なことに取り組めていて正直焦りを感じたり悔しい気持ちになったりすることもあります。まあ今は反省を活かしてフィードバックサイクルを回し、少し先を見てプロダクトと組織の改善に取り組んでいくしかありませんね。

READMEの中のビジョンに書いた以下の思いは変わっていないので、成果を出すまで腰を据えて取り組んでいこうと考えています。

  • メンバーがKyashに所属していたことが、今後の人生で転職や独立などのタイミングでプラスに働くような組織になるとよいなと考えています

なんだか反省の話が多くなってしまってネガティブな印象になりすぎていないかと少し不安ですが、こういうのは正直に書いた上でマッチするか確認するのが一番ですよね。つらそうに思われたかもしれませんが、逆に整理して書いたことで今はやっていく気持ちが高まっています。

ということで何が言いたいかというと、「なんか課題いっぱいありそうだし助けてあげてもいいよという方はぜひ応募してほしい」ということです。カジュアル面談もやっていますのでよろしくお願いします!

2022年4月18日 (月) と 4月21日 (木) に Kyash TechTalk というオンラインイベントをやるので、興味を持っていただいた方はこちらにも是非ご参加ください!

kyash.connpass.com

kyash.connpass.com

*1:日々開発を進めてくれているメンバーに対して結果が出てないと言っているのではなく、自分のミッションに対する評価として書いています。