チームの境界線で考えた

先日、「EMゆるミートアップ vol.5」というイベントに登壇してきました。

その発表の中で、他のチームのヘルプを行った話をしました。

ヘルプ先のチームのプロダクトバックログからヘルプ対象のPBIを自分たちのチームのプロダクトバックログにもってくる。
自分たちのチームのPdMと業務を調整する。
ヘルプ先のチームのEMと進め方について合意形成する。
自分たちのチームのメンバーがポテンシャルを最大限発揮できるよう観察し支援する。
ヘルプ先のチームのメンバーに実施してもらったほうがいいタスク（QA、プルリク確認など）の実施依頼をする。

ヘルプというのは、オーナーシップを曖昧にするリスクを伴う行為です。かといって「これはそっちの役割、これはこっちの役割」という線引をあまりきちっとやりすぎると柔軟な動きがしづらくなる。この塩梅が難しいな、とヘルプ業務を通して考えました。

オーナーシップは明確にしておく

ヘルプ業務にありがちなのが、ヘルプ期間が終わってもズルズルとヘルプした側への依存が継続してしまう事象。越境するときに境界線を曖昧にした結果、いつまでもヘルプした人への依存が発生してしまうケースです。

今回、ヘルプを行う際には、開発面では同じチームであるかのようにコラボレーションしつつも、タイムラインでのオーナーシップを明確にするという点に気をつけていました。

前述の図で示したように、まずはオーナーシップをほぼこちら側で持ちました。
一方で、「品質」に関わる部分、QAやコードレビューの承認権限はヘルプ先にオーナーシップをもってもらいました。これは、最終的なオーナーであるヘルプ先が品質について握っていることが適切だという判断からです。

オーナーシップのトランジションをイベント化する

そして、開発完了後には合同開催のふりかえり、そして申し送り事項の引き継ぎを明確に実施しました。この時点をもってオーナーシップは完全にヘルプ先に移譲しますよ、ということがイベントを通して実感できるように設計しました。
それが功を奏してか、引き継ぎを終えたあとにズルズルと質問がくる、依存関係ができてしまっている状況は発生していません。

シナジーを生む越境関係は残った

じゃあヘルプ先との関係がその時点で途絶えたかというと、そうではありません。このヘルプ業務をきっかけに交流が活発化し、お互いにお互いがやっているよい取り組みを取り入れるなど、シナジーを生む関係性が芽生えました。

オーナーシップを明確にしたうえで越境する。越境の目的を完遂したら、もとの状態に戻す。仕事の責任範囲、オーナーシップはもとに戻すけれど、コラボレーションできる関係性は保ち続ける。

今回、意識的にこの状態にたどり着いたわけではありません。ですが結果として非常によい地点に着地できたので、今後どこかとコラボレーションする機会があれば、今回うまくいった要因である「オーナーシップの明確化」「トランジションポイントを明確に設ける」というのはやっていこうかとおもいます。