マネジメントとしての意思決定振り返り

Engineering Manager Advent Calendar 2023 15日目の記事です。

KyashでEngineering Managerとして1年半、VP of Enginneringとして2年やってきました。

体系的な話は HIGH OUTPUT MANAGEMENT やエンジニアリング組織論への招待、エンジニアリングマネージャーのしごとといった素晴らしい書籍にまとまっているので、自分はケーススタディとしてVPoEになってからの具体的な意思決定の記録を残しておきます。EMの時の話は過去にまとめています。

先に書いておくと、綺麗にうまくいった / いっているという話はそんなに多くはありません。マネジメントに限ったことではないですが、常に意思決定と修正の繰り返しを続けています。うまくいったかダメだったかという2択ではなく、「うまくいくまで色々なトライを続けている」という感覚が近いかもしれません。まわりから見ればめちゃくちゃ小さな話と感じる意思決定もあると思います。ちょっと緊張しますが、もしかしたらこのケーススタディが誰かの参考になるかもしれないと割り切ってエイヤと書きます。

チーム体制を皆で考えるワークショップをやった

2022年1月にVPoEになった時、何人かの頼れるメンバーの退職と事業の方針変更が重なり、メンバーも不安を感じていて少しカオスな状態でした。

1on1などで話を聞いて現状を確認してみると、次のような課題が見えてきました。

Product、Design、Techのチームが縦割り構造で、受発注関係になりやすい。結果、目標に対して自律的にコミットしづらい
プロジェクトごとにアサインを決めて対応したら解散するので、メンバー個々人が長期目線で物事を考えにくく、前のめりな提案もしにくい
EMとPjMがアサインやスケジュールを中央集権的に調整しており、マネジメント負荷が高い。結果として、意思決定する人、説明される人という関係性になりがち
ちょっとした調査などの"こぼれ球"タスクが入ってきた時に都度優先順位の議論が発生し、合意形成に時間がかかり柔軟に動きにくい
決済や帳簿まわりなど、本来専任で見るべきチームが確立できておらず、必要になったタイミングで特定のメンバーが"パワー"で解決している。負荷が高く本来やるべきタスクの進みにも影響が出る上に、ナレッジも溜まりづらい
全てのプロジェクトを優先順位順に並べて上から順に取り組む方針なので、施策の実行に関してPdM個々人がコントロールしにくい。意思決定にコストもかかり、モチベーションも下がりやすい

これだけ見ると色々なアンチパターンを踏み抜いているように見えますね。しかし、事業を伸ばそうとしてきた方は経験があるかと思いますが、事業計画や組織状態を見てその時々の意思決定を積み重ねていると、理論ではわかっていてもハマってしまうことはあります。

わりと皆の課題感の認識が揃っていたので、じゃあどうするかというところを一緒に考えるワークショップを実施しました。4人くらいずつのグループに分かれて課題の認識合わせ、konifarの考えるスローガンを共有した上で、1人ずつ「俺の考える最強の体制」を考えて発表していく形式です。この内容をもとに最後はkonifarが決めるという説明もその時にしていました。

やってみた結果としては、考慮事項や考えを一気に把握できてよかったと思います。何人かのメンバーが 「全ての懸念を解決できるように良いところどりして決めることはできないからどういう優先順位で考えるか」という話をしてくれていたのが印象的でした。また、採用を頑張らないとまずいよねという認識を皆で揃えられたのもよかったです。意思決定 => 説明責任を果たすの順番ではなく並行して説明もできたように思います。

自分の学びとしては、もっと普段から皆の持っている情報を揃えておかないと議論できないことが身にしみてわかりました。ここから、事業の状況やマインドシェアを定期的に社内ドキュメントに書きなぐって共有していくようになりました。

技術的な課題を横断的に解決していくチームを作った

上のワークショップを経て、プロジェクトごとではなくミッションごとのチームを作り、4ヶ月ほどプロダクトを作っていきました。

メンバーと定期的に話してみると、 開発組織がコントロールできる生産性の課題には長いこと手をつけられておらず、結果として事業推進の速度にも影響が出ている という声を何度も聞くようになりました。いわゆる技術的負債と言われるものですね。

これに対して、Kyashでは週に1日時間をとる、四半期に1週間解消祭りをやるなどやり方を変えて解決を模索してきました。しかし全体のデータベースが関わる課題、複数のマイクロサービスにまたがる課題などには手がつけられていなかったのですね。そこで、 もうチームを分けて注力するぞ という意思決定をして、CTOとも合意して専任の横断解決チームを作ることにしました。

こういう方針でチームを作ろうと思うんだけどどうかなという発信をしたところ、 「俺にリードをやらせろ」 と連絡してきたメンバーがいたのがめちゃくちゃ嬉しかったです。彼にリードをお願いしてチームを作り、four keysの計測や検証環境の整備などが進みました。

blog.kyash.co

実は彼は退職してしまっているんですが、今も他社で生産性改善チームをやっています。Kyashでのチャレンジが少しでもプラスになったのだとしたら嬉しいかぎりです。

一方でマネジメントの目線で評価してみると、もともと解決したかった技術的な課題をあまり解決できなかったとも感じています。これはメンバー個々人の問題というよりもマネジメントとして目標と計画をうまく立ててリードしきれなかったところが大きいです。

また、four keysの計測もできるようにはなったものの、皆がそれを意識して振り返るような動きにはなっていません。事業と組織状況の変化もあり、チームを分離して実行するというこの方針はいったんやめることとしました。今またプランニング中ですが、やることとスケジューリングをもう少し明確にして進めていこうと考えています。

決済の専任チームを再結成した

もともと決済まわりの専任チームはあったのですが、先のプロジェクト制の方針で形骸化してしまっていました。幸い決済まわりの大きなインシデントは起きてはいませんでしたが、当然サーバーサイドのメンバーからも不安の声が上がっていました。

チームトポロジーを何人かで輪読し、「決済のComplicated Subsystem Teamは必要」という認識を合わせ、これもCTOとすり合わせてミッションを整理しチームを再結成することにしました。

今振り返ると、この意思決定はもっと早くにするべきでした。当時の自分は「年内は事業優先で何とかやってほしい」といった経営からの要望に自分のマインドが引きづられすぎていたのだと思います。1年以上のタイムスパンで考えると、Kyashにおける決済というのは事業の要であり、その安定に長期的に投資することは開発部門をマネジメントしている立場としてもっと早いタイミングで提案するべきでした。

振り返ってみても、決済のチームを作ったことはとてもよかったと感じています。Visaが絡む部分の改善も進みましたし、CSやリーガルなど他の部門から決済に関する質問の窓口もわかりやすくなりました。チームメンバーとEMに感謝しています。

採用活動のリードを分担した

チーム体制を皆で考えた際に 「採用してチームを作っていかねば」 という認識が揃いました。

全員で徹底的にやっていくために、採用活動を分割してリードを置いてメンバー主体で進めていくことにしました。具体的には、次の4つに役割に分割してメンバーにミッションとキャリア上のメリットなどをお伝えして改善を進めてもらいました。

『受けてもらう』
- Kyashを認知し興味を持って、面接を受けてもらう人数を最大化する
- 例: 発信を増やす、面談プロセスを改善する、リファラルの促進、スカウトの旗振り
『見極める』
- 面接に来た人が入社後に活躍できるかどうかを正しく見極められる状態を作る
- 例: 構造化面接のブラッシュアップ、面接担当者の教育、コーディングテストの検討
『選んでもらう』
- 面接が進んだ人にKyashの魅力を正しく伝え、Kyashを選んでもらえる人数を最大化する
- 例: 他社と比較したKyashの推しポイントの明確化、勝つべき競合と負けてもいい競合の明確化、オファー後のアトラクト会議の実施・改善、CEOの有効活用方法を決める、オファーレターの改善、選ばれなかった、選ばれた理由の分析
『活躍してもらう』
- 入社後のコミュニケーション、キャッチアップのフローを整え、活躍できるまでの時間を最短にする
- 例: オンボーディングフローの運用・改善、メンターの役割明確化、フォローアップ、入社3ヶ月後のパフォーマンス検証、入社後ブログを書いてもらう

『選んでもらう』の部分は役割の特性上マネジメントが担った方が改善しやすいと判断してkonifarがやることにしました。

この方針はうまくワークして、方針を打ち出してから6ヶ月で9人にオファーを受諾してもらえました。もちろんオファーを受諾していただいた本人の意思決定が一番大きいところですが、役割を明確にして分担したことで全員で採用に取り組むという意思を統一しやすかったと感じています。

ちなみに個人的に嬉しかったのは、 「受けてもらう大臣の◯◯です」 のようにアナウンスするメンバーが出てきて、大臣という呼び名が自然と定着したことです。こういう楽しそうなやっていき姿勢を示してくれるのは非常にありがたかったです。

一方で、実は事業状況の変化もあり退職が続いてしまうことがありました。そのため、組織として成熟できてきているかというとまだまだ課題は残っています。皆でよくしていくしかないので、2024年も取り組んでいきます。

リグレッションテストの自動化を始めた

事業を推進していくうえで改善したいポイントとして、 QAで手動で行っているリグレッションテスト項目が肥大化している という課題がありました。2人で2~3日くらいかかるようになっていたんですね。

これに対して、リグレッションテスト項目を見直し、Autify for Mobile を利用してそれらのテストを自動化していくことにしました。

自動化を進めるべくSETチームを組成し、繰り返し実行するためのユーザー作成・ステータス変更のツールなども作っていっていましたが、結果としてリグレッションテストを自動化して運用に乗せることはできず、半年ほどチャレンジして断念しました。

原因は色々あるのですが、大きく次の要因が影響していたと思います。

KYCステータスの変更を管理画面で行うテストケースなどは当時の Autify for Mobile で満たせなかった
アプリの操作をトレースしてテストを組むことができないケースがあった
複数のチームの変更に追従しきれずメンテナンスコストが高くなった
繰り返し実行するためにツールを充実させる必要があり、そこに適切な人と時間を投資できなかった

もっと早く判断できずSETチームのメンバーには申し訳なかったです。振り返ってみると、 「リグレッションテストそのものを自動化する」というアプローチが今のKyashでは筋が悪かった と考えています。

まだ過去のリグレッションテストで拾えた不具合をすべて分析できているわけではないですが、ざっと見てみるとフィーチャーフラグまわりの問題、APIとMobileの実装齟齬の問題、デプロイの不備の問題などで発生していることがわかってきました。手動で実施しているリグレッションテストをそのまま自動化する必要はなく、サーバーサイドのAPIテストとMobileのAPIとの接続部分のユニットテストの拡充という方針がよいのではないかと考えて準備を進めています。必要なのは 手動テストの自動化ではなく、自動テストを前提とした再設計 だったということです。

その一環として、APIのテストをscenarigoを利用して拡充していっています。トライとしてKyashコインの開発では開発と並行してSETのメンバーがAPIのテストをガシガシ書いていくという動き方をしていました。

blog.kyash.co

実装中の不具合の検知件数を見てもこの取り組みはうまくいったと判断しています。2024年はMobielのAPI接続まわりのテストと、繰り返し実行するためのツールの拡充で再チャレンジしていく予定です。

1週間コスト改善に集中した

2023年4月に全社的にコストを見直すことになりました。

コスト削減は早く取り組むほど効果を得られるものなので素早くやろうということでコスト改善プロジェクトを立ち上げ、10人のメンバーを集めて1週間で一気に成果を出す方針を経営に提案し、進めていくことにしました。

月曜にアイデアをリストアップしてカテゴリに分けアサインを決め、朝会以外の全てのMTGを取っ払って取り組んでいきました。

インフラ
- AWS/GCP
- データセンター利用料
CI/CD
- CircleCI
- GitHub Actions
外部サービス
- SMS送信関連
- メール・Push通知関連
- Datadog関連
開発ツール
- Dockerライセンス
- GitHubライセンス
- Golandライセンス

結果を金曜にとりまとめ、次の結果が出ました。

調査したアイデア数 : 31
- 1週間で対応完了 : 8
  - 4月以降の削減効果 : -¥133万/月
- +1週間で対応完了 : 7
  - 5月以降の追加削減効果 : -¥113万/月

ある程度の成果を1週間で出せたので、タスクフォース的に一気に取り組むという意思決定はよかったと思います。

振り返りでは 「楽しかったしタスクフォースにならないように普段から定期的にやりたい」 という声が出ていました。ここはまだプランニングできていなくて、どうしていくか考え中です。

業務委託メンバーを増やした

これはかなり意思決定に悩んだところですが、事業と開発組織の状況を鑑みて一時的に正社員の採用から業務委託の追加に方針変更をしました。

一般論として、外部委託メンバーが増えると開発のナレッジが蓄積しづらく、プロダクトへの深いコミットを期待することも難しい傾向があります。長期的に見れば色々な課題が出てくることも当然想像できますが、次の理由で今は委託のメンバーに入ってもらう方がよいと決定しました。

参画までのリードタイムが正社員採用と比べてかなり短い
契約しているパートナーからの業務委託メンバーがいい感じに機能している
業務委託メンバーの中で組織づくりにも興味のあるメンバーがおり、増員時の業務委託の中での横のフォローアップ体制も作れる

経営の描く事業計画の遂行の手段のひとつとして意思決定しましたが、正直自分もこの決定がよかったと言えるのかはまだわかりません。選んだ決定を正解にしていく気持ちでよいチームを作っていこうと考えています。

自分がプレイヤーとしてガッツリ開発に入った

VPoEという役割は組織によって様々ですが、2023年内はチームの成果を最大化するために自分がプレイヤーとして入るのがよいと判断してサーバーサイドの実装にガッツリ入っていました。

多言語化対応とKyashコインのリリースに関わり、今も年内のリリースに向けて別の開発に入っています。マネージャーがコードを書くべきかという議論をしばしば目にしますが、自分の考えは 「成果を最大化するために自分がコード書くかどうかもマネージャー自身が決めればよい」 です。その裁量や選択肢を持っているのがマネージャーです。

で、やってみた結果なんですが、プレイヤーとしてもそれなりに貢献ができているとは思います。社会人歴もエンジニア歴もKyash歴も長いので当たり前ではあるんですが、プロダクト開発を推し進める手数が多いことに加えてサーバーサイド、Android/iOS、QAなどすべてひととおりプレイヤーとして経験してコードをかけるようになっていたのも大きかったです。さらに、ChatGPTやGitHub Copilotによって自分のコードを書くスピードが体感3~4倍になったのも最高でした。いい時代になりましたね。

ただシビアな評価としては 「短期的にはそれなりに貢献できているものの、組織全体への大きな貢献にはつながっていない」 と感じています。今よりさらにプレイングの時間を増やしたとしても、新規のAPIを1日に2本仕上げられるくらいが自分の今の実力です。

年内の成果の最大化を考えた意思決定としては悪くはなかったですが、1年半後くらいを見据えるとこの方針は筋が悪く、組織の負債を溜め込むことになりそうです。2024年はプレイヤーの選択肢は取らずに少し先を見たマネジメントに集中しようと考えています。

プレイヤーとしてメンバーとコードを書くのは非常に楽しく高揚しました。サーバーサイドのコードの解像度も上がり、普段チームメンバーでいかに頑張って開発してくれているかも身をもって知れたのもよかったです。2024年はマネジメントとして何の成果を出すのかをきちんと説明して、常に状況を共有していくつもりです。

おちこんだりもしたけれど、私は元気です

振り返ってみると、いつも悩みながら方針を決めて何とかやってきました。VPoE README にも書いたとおり、なるべく説明責任を果たすつもりでやってきましたが、意思決定の中でメンバーを混乱させてしまうことも多かったと思います。この半年はさらにﾊﾁｬﾒﾁｬがやってきていて大変でしたが、メンバーの頑張りのおかげで事業としてはよい方向に進んできておりめちゃくちゃ感謝しています。

最近は自分の意思決定をよりよいものにしていくために他社のCTOやVPoE、EMの方とお話させていただく機会を増やしています。もしオフレコで泥臭い話をしたいという方がいれば気軽に @konifar までお声がけいただけると嬉しいです。他社のマネージャーが事業と技術のバランスをとって見事に組織を作っている話を聞くと、正直焦燥感に駆られて悔しい気持ちになることも多いですが、そのぶん学びも多く思考整理も進むので続けていっています。

引き続きうまくいくまで様々なトライを続けていきます。

では、最後はいつものようにこれを置いておきます。Let's Kyash!

kyash_id: konifar