未来永劫

メリーバッドエンドが好きです.

クロスファンクショナルなチームでTLをして半年が経った

最近何してたの?

題目通りで,PO, PM, Branding team, Backend team, Client team, ML team, Scrum masterから成るチームのTLをしてた.直近だとコンテンツマーケティングに関わる方とも協業している.
どんな機能を作ってたかとか,何がどうなるみたいな話は当然ここでは出来ないので,ツラツラと気持ちの棚卸しをしたいと思う.

クロスファンクショナルとは

一般には「課題解決のために特定の役職にとらわれず必要なメンバーを集めて構成されるチームであること」だと思うし,ここでも同義として扱う.
今の社は基本的にどの部署も特定ドメイン単位で分割されているので,そのドメインでTLをすると言うことは必然的にクロスファンクショナルなチームでTLをすると言う事とほとんど同義になっている.

TLとは

特にこの言語定義は人によって異なると思うので予め自分自身が想定する単語とその認識をメモしておく.
個人的に解釈するのであれば ある特定の技術領域(任意の機能でもPlatformでも可)に関して,技術を駆使しオーナーシップを持って働ける人 だと思っていて,例えば「"その時々にあった正しいアーキテクチャの設計" ができ,"コードの品質管理" や "チームの生産性にコミットできる" のがTLである」と言うような表現は狭義的で好きではない.
オーナーシップを持つと言うところが大事で,それは当然技術的な意思決定に対してでも,メンバーとのコミュニケーションに対してでも適用されると思ってる.
これは特定の職位では無く役割,振る舞いの一つだと思うので,定義に則りオーナーシップを持って働くために必要なのであれば何でもすべきだと思う.

お気持ちまとめ

人が多いと大変

当たり前である.
当たり前なのだけど,大きなサービスになればなるほど一つの機能追加や実験がその関係者だけに閉じる現象はほぼ起きないと思っているので,「大変さ」についてもう少し要素分解したいと思う.
「人が多いと大変」に感じる理由は大きく分けると2つで「個々人がそれぞれ意思(意見)を持っている」ことと「ポジショントークが発生する」ことだと思う.

個々人がそれぞれ意思(意見)を持っている

何か1つの機能を作るのだとしてもその人ごとに「現時点で持っている解像度」や「今後将来にわたる展望」があるので今回のような複数の人たちがいたらまとまらない.
ただ,そこの事実を認識しているのであれば,大切なことは「その解像度と展望の擦り合わせ」である.
したがって,擦り合わせに非常に多くの時間を投資するのが大変と言う結論になる.時間がかかるものは大変なのでそれはそう.

ただし,TLであるならば,認識を共通化することが出来ないと別の誰かが同じ立場でTLを担う時にまともにワークできない可能性がある.
この投資は大事だと思うし,全てのメンバーが場合によってはTLを任されてもいいような状態になっている事を目指すのがオーナーシップを持っている状態だと考える.大変だ.

ポジショントークが発生する

これは先述した項目と要素が従属しているかもしれないが,大事なので書く.自分はこの点に関して楽観的に見積もりすぎていて後悔している.
組織に属する以上,何かしらの役職を持っているはずなのでポジショントークが発生することは仕方がない.

ポジショントークとうまく向き合うためには,その人の思惑を引き出し切ることでしか対処不可能だと学んだ.
こういったトークで必要なのは「新たに何かを提案する」のではなく「その人と交渉すること」なので,いかに相手の立場を理解し,いかに共感するように振る舞えるか,そしていかに受け入れてもらえるかだった.

例えば,技術的な「アーキテクチャの正しさ(質)」と「実装スピード」は一見短期的にはトレードオフに見える*1ため,PMと言うポジションから同じ物事を見た時には早く機能をリリースしたいと言うモチベーションが高まるのは当然なので,その共感をした上で説明をしないとお互い終わらないプライドバトルになってしまう.
オーナーシップを発揮するためにはこのような政治レイヤーまで介入していかないといけなかった.大変だ.

コンテキストスイッチの切り替えが大変

先述したTLとして振舞っているとあらゆる連絡が飛んでくる.
基本的な機能開発に関してのレビュー依頼やディスカッションはもちろんのこと,関連する他チームとのやりとり,長期的なロードマップへの雑談,各ポジションのメンバーからの要望,スケジュールの進退,突発的に発生した問題の対処,開発チーム内でのファシリテート…などなど.
「技術のみの連絡窓口」という振る舞いをすることも可能だったが,それは決して私の考えるTLではなかったので私に頼るべきと判断してくれたメンバーをリスペクトし真摯に対応した.

その結果として発生したのは過剰なコンテキストスイッチの切り替えとそれに伴う記憶喪失であった.
一日仕事して,次の日になると昨日何をやったのか忘れる.それが3ヶ月くらい続いた.もちろん仕事をしているので進捗自体は当然あるのだが,思い出すのに時間がかかる.
あらゆる人とあらゆるコンテンツについて常時議論をしているせいで,自分がその間にどのタスクを葬ったのか忘れてしまうのだった.

余談だが,よりハイコンテクストな領域にオーナーシップを持っている方達と定期的にディスカッションしていると「これなんの話だっけ?」みたいな事を聞かれるのが時たまあり,「この人の事信頼していいのか?」と思っていた時期もあったが,彼ら/彼女らは過剰なコンテキストスイッチの切り替えを行い続けなければならず,自分自身で記憶し続けるのが難しいのだと悟った.

これを防ぐために,付け焼き刃だがカンバンのチケットの大半を管理し常に最新の状態に遷移させる事で記憶を忘れても良い状態を作る事を心がけた.
他に提案してもらった方法として,Evilな方法であるが他者の外部記憶を利用することも方法として存在する事を知った.「他者に内容を伝えていれば自分が忘れていても必要なタイミングで再度連絡が来るため,結果存分に忘れられる」といった具合に.
何れにせよ,抽象領域が広くなればなるほど,(例えば実コードレイヤーのような)特定の事象にDeep diveするとその後別の事象にDiveするのがしんどくなるし,次々と忘れていくので記憶/記録方法に関しては学んだ方が良い分野だと感じた.大変だ.

まとめ

組織で目に見えたインパクトを出す仕事をするには政治レイヤーをやるのが当然大事で,その何をすべきなのかが分からない状態が分かるようになったのは経験として大きかった.
それから,「技術的に成長できるか否か」と「プロダクトとして貢献する」事には相関関係が全くないので,あくまでTLとして振る舞う割切りが大事だと思う.
振る舞いができないのであればメンバーが疲弊するので引き受けるべきではないし,仮に引き受けてしまっても振る舞いの話なので別の人に移譲できる状態であれば降りて良いと思った.
また,今回の件も自分と同じ境遇になる人はほとんど居ないと思うので,その人なりに役割を解釈して働けると良いと思った.サラリーマンは大変.皆様もご自愛ください.

*1:よくある質とスピードの話. 実態は保守性を高めるようなアーキテクチャとして実装できればリリースサイクルは早まるのだが,そういった案よりも直感的に簡単な実装の方が好まれたりする.そしてそれは中長期にわたり負債となる.