はじめに
こんにちは！e-dashのGroup managerをやってる石田です。
本記事では、チーム立ち上げ時に僕が失敗したことと得た学びについて記載します。
僕自身恥ずかしい話ではありますが、読者の反面教師になればそれに越したことはありません。
チーム立ち上げ時に取り組んだことも記事にしてますので、👇もよければ一読ください。
新チームを軌道に乗せるためにとった７つのアクション
失敗１：複数システム間の影響観点を自分は把握・対処できるという驕り
先に前提のシステム構成の話をすると、以下の図のような構成になっています。
僕は、Aプロダクトでは１年近く、Bプロダクトは立ち上げ初期から関わっており、両方のプロダクトについては過去の経緯も踏まえ、弊社の中では知見がある方だという自負はありました。
そこに、今回新規Cチーム立ち上げる=深く関わるという形になります。
また、１プロダクト内に閉じたプロジェクトも２プロダクト横断的なプロジェクトも経験してきたので、「１も２もできたら、３も一緒じゃない？」という驕りがありました。
結果的に、仕様設計上の不備が自分の予想外のところから次々とやってくることになりました。
設計漏れがないのは難しいですが、にしても多かったです。
振りかえる
どういう違いに気づけるとよかったのか？を振り返ってみます。
１プロダクトに閉じるプロジェクトを以下のような図でリーダーが見ているとします。
1プロダクトに対する目線の数なので当然１つになります。
リーダーはプロジェクトへの要求・要件を満たそうと、１プロダクトの範囲でリードすることになります。
これを基準に、２プロダクト以降見ていきます。
２プロダクト間のプロジェクト
では、２プロダクト間に跨るプロジェクトはどうなるでしょうか？
例えば、内部APIを通す、キューを介してデータを同期する、DBを共有してるシステムの機能改善、といったプロジェクトが挙げられます。
この時、リーダーには２プロダクト間の双方向の観点として、２つの目線が必要になります。
横断的なプロジェクトだとしても、通信の矢印が一方方向だったり、目線の数も減ります。
それでも、両側の立場から見て、要求・要件に対し様々な観点で問題ないか？を考えるのはなかなかハードなものです。
3プロダクト間のプロジェクト
以上を踏まえて、３プロダクト間をみてみるとどうでしょうか？
目線の数は最大３ではなく６（=プロダクト数の階乗）というのに気づくかと思います。
この目線の数を一人が同時・継続的に担うのは不可能です（少なくとも僕は）。
簡単な計算なんですが、当時はこの考えはありませんでした。
どうすべきだったのか？
３プロダクトのエンジニアが自律的に仕様を詰めていってくれたおかげで、進まないことはありませんでした。これは、プロダクト間の仕様整理はそのエンジニア同士に任せていたことが功を奏したためで、再現性のない結果と捉えています。
目線の数 = 複雑性や難度があることを念頭に、協力を求めるという動きができていれば良かったのかと考えています。
失敗２：責任範囲への考慮不足・早合点
チーム発足の経緯は前の記事にも記載してるのですが、新チーム発足理由の一つにCo2排出量に関わるドメインロジックの共通化があります。
基盤チームの責任範囲を決める際に、最初は、ドメインロジックだけでなくほぼ全てのデータを基盤チームが持つとしていました。
理由としては組織的・アーキテクチャの面では合理性があったからです。
当時は、組織と全体構成の大きな括りに頭がいって、この「ほぼ全て」というデータ量やコード量に目がいかず、マネージャー間で合意してしまったのがよくありませんでした。
合意して少ししてその膨大な量に気づき、ロジックの共通化という投資に対して価値提供までのリードタイムがあまりにも長いとわかりました。
アーキテクチャや組織に対する大きめの決定を覆すのは気が進みませんでしたが、関係者を再招集し、
- 前回の決定はあるべきとしては正解。でも、3プロダクトの価値提供が遅くなる
- これは全員が望んでないはず
- 少し構成は汚いかもしれないが、早い価値提供を踏まえた案で合意したい
という点を伝え、限定的なデータの責任範囲に落ち着き、事なきを得ました。
今回のケースでは、組織やアーキテクチャのあるべき論に向かいすぎたために起きたと考えていて、具体的にどう移行するか、といった現実的な策にも頭を巡らすべきだったと反省しています。
失敗３：横断したプロジェクトの情報共有を各チームにせず、不安にさせた
プロジェクトの中間を過ぎたあたりから、
- SchemaはもらったけどAPIって疎通できます？
- Schema渡したけど、実装て進んでるんだろうか。
- Queueの先ってそろそろ実装終わってるんだっけ。。
といった、チームでの会話やslackでチラチラ見え始め、レトロで他チームの状況が見えない、という声が聞こえてました。
最初は、schemaベースで開発を進めてるし、他チームの状況も見れるし、大したことではないとは思ってました。
しかし、メンバーの立場を考えると、プロダクト間の疎通も合わせて動作を確認したいので、ずっとタスクが滞留することになります。実装はDoneだけど、リスクが残った状態になるのでよろしくありません。
つまり、個々のタスク単位の不安と、それが増えていくことによる全体的な不安感（残存リスク）につながったのかなと思います。
３プロダクト全体の状況は僕が俯瞰して見ていて、そのステータス（DoneかInprogressか）といった表層的なことに目を向けてはいたものの、各チームへの不安感には寄り添えてなかったように思います。
対策として
- 15min程度の定例で共有する
- タスクの依存関係をlinearで設定する
なども考えましたが、ミーティングや管理業務を増やさずに何かできないかと考え、
現在は朝会で他チームのupdateがあれば軽く共有する、という形をとっています（検証中）。
最後に
それぞれの失敗は、時にプロジェクトの進行に大きな影響のあるものだと考えてます。
でも、他のメンバーに支えられたり、辛いけど判断を覆したり、小さく対策を打って緩和したり、
となんとかやっております。
こんなマネージャーですが、プロダクトを前に進めることには本気で向き合っております。
ぜひカジュアル面談に来ていただけると嬉しいです。助けてくれる方お待ちしてます。
Discussion