バクラクにおける Enabling Team の役割

バクラクの Enabling Team は Team Topologies を端に発して組成したチームです。従来式の Platform Engineers と Product Engineers にとって、円滑油のような働きをもたらします。 Team Topologies では、 “Facilitating” と呼ばれる関係で、メンターとして Product Engineers に関わるチームとなっています。

バクラクにおける Enabling Team の役割を改めて考えたときに、”Facilitating” やメンターという表現ではしっくりこなかったため、チームでインセプションデッキを整理をし、しっくりくる役割の表現を探しました。 Team Topologies では、チームの生産性がスケールしない原因に Cognitive Load (認知負荷) に着目しています。

認知負荷を “最適化” する

認知負荷については、以前CTO Week でも話したので、詳細は https://logmi.jp/tech/articles/328828 を参照してください。

エンジニアが開発をするとき、頭の中にあるワーキングメモリを使って考えています。その時にワーキングメモリにかかる負担が認知負荷です。ワーキングメモリには限界があるので、例えば「デプロイの手順がわからないので調べて実行する」などにメモリを使ってしまうと、本来の実装に使うメモリが足りなくなってしまいます。

開発のパフォーマンスを上げるには、認知負荷にかかるバランスにおいて、よりドメインロジックを考える割合を大きくしていく必要があります。

Ref: https://carlosgrande.me/team-topologies/

そこで、バクラクにおける Enabling Team は、プロダクトエンジニアがより本質的なことにワーキングメモリを使うために、様々なツールを作ったり、開発手法や技術をプロダクトエンジニアに選択肢として提供し、発生している不要な認知負荷を極力取り除きます。ワーキングメモリの大半を開発や実装に使えるようにすることをチームの存在意義にしました。

インセプションデッキ

チームの存在意義を考え、他のチームに理解をしてもらうために、Enabling Team でインセプションデッキを作ったのですが、以下にその一部を紹介します。

我々はなぜここにいるのか

エレベーターピッチ

エレベータピッチでは、従来の横軸チームと比較して、プロダクト開発と伴奏するチームとして価値を生み出すことを定義しました。

やらないことリスト

やならいことリストには、 Enabling Team が単なる技術支援やスペシャリストチームにならないように、いくつかの点を入れています。

Enabling Team はあくまでプロダクトチームと価値観を共にして伴奏するチームなので、“Enabling Teamだけで実現すること” や “Enabling Teamメンバーしかできない解決方法” は原則やらないことにしました。

トレードオフスライダー

横軸チームは、ともすれば中長期的な視点に重きを置いてしまいがちです。優先度に対する考え方はとても重要です。現状のバクラクの状態を見て、今は短期的な課題解決を優先すべき、と考え、以下のようなトレードオフスライダーを作りました。（このスライダーは 2023 初期に作ったものなので、現在は変化しています。）

チームの動き方

Enabling Team として認知負荷を下げるために、様々な活動方法があります。 Team Topologies では、プロダクトチームに参戦し、 Facilitating というモードで一緒に活動する、と定義されています。バクラクでは、 Enabling Team は原則プロダクトチームのスクラムに参加し、メンバーの一員として一緒に開発をしています。

Enabling Team にとっての直接的なお客様は、プロダクト開発を日々行っているエンジニアです。プロダクト開発の一員として動くことで、現状の課題に対して、より解像度の高い理解をすることができ、現場に必要となる Enabling 活動ができています。

お茶会文化

チームは半年に1回のペースで「お茶会」と称して、様々なチームと、カジュアルなセッションを通して、今感じている課題をヒアリングしています。プロダクトチームのヒアリングを元に、解決すべき Issue を書き出し、常に必要なことに優先的に取り組めるようにしています。

最近では、プロダクトエンジニアだけでなく、カスタマーサポートチームとお茶会を開催するなど、よりプロダクトの広い範囲で Enabling できることはないかの模索もスタートしています。

重要なのは、 Enabling Team が “もし良かったら使ってみてください” という提案型のチームであり、プロダクトチームが常に選択の自由を持っている、という点にあります。お茶会は、そんな Enabling Team の方針を実現するための重要なイベントになっています。

のびしろと課題

ここまで Enabling Team が上記のような方針で活動してきて、プロダクト開発組織がスケールする状況で非常に有益だと感じています。新たな仕組みが生み出され、プロダクトチームに展開され浸透しているものもあります。

この活動そのものは終わりがなく、より最適な認知負荷を目指して出来ることは無限にあるため、伸びしろも無限大です。

一方で、仕組み化を伴う認知負荷の改善には課題があると感じています。それは、仕組み化が優秀であればあるほど、仕組みの変化やイノベーションを生み出しづらい、という課題です。技術の分野ではよくありますが、新しい技術や方法論を導入するときには、かならず一時的に認知負荷のバランスが崩れます。新たなものを学ぶための負荷が増大するからです。したがって、 Enabling Team が持つ課題は、成功している仕組みを壊すという負荷を受け入れながら、変化と改革を続けるということの難しさ、にあると感じています。

この解決は、開発組織の文化やプロダクト開発におけるエンジニアリングの立ち位置などで解決していくものだと思っていますが、その話はまた別の機会にできればと思います。