イネーブリングチームの考え方と実践例 — 組織の価値提供能力をいかに高めるか

これは mybest BlogKaigi 2024 4日目の記事です

はじめに

弊社マイベストでは、エンドツーエンドの機能開発チームとは別で、組織の価値提供能力を高めることを目的としたイネーブリングチームがあります。（と言ってもまだ他チームとの兼任メンバーがほとんどですが）

イネーブリングチームは、バックエンドやフロントエンドなど、領域ごとに技術課題を解決すべく活動していて、自分はフロントエンド領域を担当しています。

これまで様々な活動を行ってきたので、その考え方を整理しつつ、フロントエンドイネーブリングの実践例をご紹介したいと思います。

参考：マイベストのチーム構成イメージ（記載は一部のみ・名称は仮です）

「イネーブリングチーム」とは

イネーブリングは『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』、通称チートポから持ってきた名称なので、まずはチートポをベースにその役割を説明します。

https://amazon.co.jp/dp/B09MS8BML8

チートポでは、機能提供をするチームをストリームアラインドチームと呼びます。（※本記事の主旨から外れるので乱暴なまとめ方をしています）
そのストリームアラインドチームが、「その時点で持っていない必要な能力を獲得するのを助ける」のがイネーブリングチームとされています。
大抵の場合、ストリームアラインドチームは複数あり、チームを横断してギャップを埋める役割を担うのがイネーブリングチームです。

イネーブリングチームには以下のような特徴があります。

• 特定のテクニカルドメインのスペシャリストから構成される
• 複数のストリームアラインドチームを横断的に支援する
• 適切なツール、プラクティス、フレームワークなどの調査・オプション探索・提案を行う

また、イネーブリングチームのゴールはストリームアラインドチームの自立性を高めることです。
そのため、イネーブリングチームへの継続的な依存関係（サポートが無いと機能開発できない状態）は作るべきではない、とされています。

イネーブリングの考え方

ここからは筆者なりに整理した考え方です

イネーブリングの基本的な役割

チートポの話を踏まえて、役割を一言で言えば、「組織の開発レベルや生産性を上げ、（エンドツーエンドの）価値提供能力を高めること」だと思います。

そして、組織の価値提供能力は大雑把に以下のように表すことができるかと思います。

価値提供能力 = メンバーのスキル - 開発の難易度

そのため、アプローチは

• メンバーのスキルを上げる
• 開発の難易度（ハードル）を下げる

と大きく2つに分けられるので、この2つに取り組むのがイネーブリングの主な活動になります。

※組織によっては、特定領域における横断チーム（QAなど）の0→1立ち上げ（弊社はまさに今ココにも取り組んでいます）、などもイネーブリングの範疇かもしれません。

アプローチの優先順

イネーブリングが果たすべき具体的な責務は、組織の状態によって変わってくると思います。

先ほどの2つのアプローチのうち、取り組む順番としては、以下が良いと筆者は考えています。

開発のハードルを下げる → メンバーのスキルを上げる

理由としては、開発ハードルが高い＝複雑性が高い状態だと、学習コストも高いので、スキルアップの効率が悪いからです。

極端な例を挙げると、Linterが導入されていなければ「末尾にカンマをつけるかどうか」みたいな話からする必要がありますし、
VueからReactへ移行途中であれば両方を学ぶ必要があるので、早く移行を終わらせた方が学習しやすいです。

組織の状態に合わせた責務

優先順を踏まえつつ、具体的な取り組みを計画する上で、
筆者は組織の状態を3段階のレベルに分けて、それぞれイネーブリングとしてやるべきことを整理しました。

組織レベル1

組織の状態： 技術的負債が大きく、普段の開発に支障が出ている（バグの頻発・生産性の低下）

この時やるべきことは、負債解消です。
まずは大きな負債を解消すべく、リアーキテクチャやツール・ライブラリの導入によって、根本的に開発のハードル下げるべきです。

※リアーキテクチャは導入初期に学習コストがかかる（=生産性が一時的に下がる）可能性が高いので要注意です。
その分、その後の取り組みをしやすくするのが目的なので、評価をどの時間軸でするかが重要で、なるべくリアーキテクチャ後の取り組みも含めた評価ができると良いです。
また、イネーブリングチームや技術課題の取り組みがまだ組織に浸透していない場合は、スモールウィンを考えてもっと単純な負債解消から始めると良いと思います。

組織レベル2

組織の状態： 目に見えて大きな負債は少ないが、生産性には改善の余地が大きい

この時やるべきことは、効率化です。
生産性を上げるためには、開発フローやルールを整え、組織的・継続的にリファクタリングしていくことが必要です。
同じ方向を向いて細かい改善をたくさんすることが求められるので、開発のハードル下げとメンバーのスキル上げの両方が有効なフェーズです。

※根底にある考え方として、内部品質を上げることで開発スピードが上がり、価値提供能力が上がる、と考えています。（有名な「質とスピード」に学ばせてもらっています）
https://speakerdeck.com/twada/quality-and-speed-aws-dev-day-2023-tokyo-edition

組織レベル3

組織の状態： 一定効率良く開発できており、効率以外の側面でチャレンジする余力がある

この時やるべきことは、自律支援です。
多様なテーマに取り組むには、メンバーの自律的なチャレンジが不可欠であり、それを支援する必要があります。
このフェーズでは、メンバーのスキル上げが主になってきますし、支援の仕方もテーマによって変わってくると思います。

補足

分かりやすさのために、チームビルディングにおいて有名なタックマンモデルになぞらえて整理すると、以下のようになります。

フェーズ	タックマンモデルにおける説明	イネーブリングの役割	やるべきこと
形成期	チームとして動き出している	無し	機能開発に集中
混乱期	認識のズレや衝突が起こっている	レベル1	負債解消
統一期	方向性が揃い出している	レベル2	効率化
機能期	チームとして機能している	レベル3	自律支援
散会期	チームが解散し始めている・次のPJTが始まっている	無し	次のPJTに備える

※参考： https://www.jmam.co.jp/hrm/column/0053-teambilding.html

このレベル分けは厳密なものではないので、例えば一度レベル2の状態になればリアーキテクチャが不要になる、といったようなものではありません。

イネーブリングの実践例

ここからは、フロントエンド領域での弊社の実践例を簡単にご紹介します。

弊社には現在イネーブリングチームが有りますが、イネーブリングチームという名前が付くよりずっと前から技術課題には継続的に取り組んでいます。
その中でも上記のレベル分けは意識しながら取り組んできたので、以下、時系列にそれぞれの取り組みをご紹介します。

なお、現在の弊社の技術スタックは以下の記事で紹介されています
https://zenn.dev/mybest_dev/articles/1fda6f67c82724

リアーキテクチャ（レベル1・負債解消）

弊社は2016年設立・サービス提供開始ですが、3年目の頃から積極的にリアーキテクチャ・リプレースを行ってきました。
例を挙げると、

• CoffeeScriptからTypeScriptへ
• jQueryからVueを経てReactへ
• RailsによるViewの描画からNext.jsのSSRへ

また、新しいツールやライブラリの導入も進めてきました。
こちらも例を挙げると、

• GraphQL / Apollo Client
• GraphQL Code Generator
• Jest
• Storybook / Chromatic
• Radix UI

今では弊社にとって当たり前となったこれらの技術ですが、
導入を進めたことで、その後の開発ハードルが下げられたと思います。

また、それぞれの移行や導入の際に、なるべく単純な実装になるように意識をしたので、
個人としての開発しやすさだけでなく、チームへの共有コストも下げられたと思います。

ドキュメント整理（レベル2・効率化・ハードル下げ）

弊社は初期の頃からドキュメントを書く文化が有りましたが、特に4年ほど前からはGraphQLを中心に実装方針を整理・共有するためのドキュメントを多く書いてきました。

コーディング規約というよりも設計寄りの内容が多く、例えばディレクトリの構造やファイル分割のルール、ページネーションの実装方針（カーソルかオフセットか）などの考え方が書かれています。

ディレクトリの構造については以下の設計思想に基づいてルールを整理しました。
https://zenn.dev/mybest_dev/articles/c0570e67978673

GraphQLのドキュメントについてはLTをしたスライドが有るので置いておきます。
https://speakerdeck.com/teppeita/graphqlnoshe-nei-dokiyumentowozuo-tutahua

その他にも以下のようにページを整理し、社内で共有することで実装方針を整理しながら、組織全体で同じ方向を向いてリファクタリングに取り組めるようになりました。

弊社NotionのWebフロントエンドのトップページ

実装パターン整理会（レベル2・効率化・スキル上げ）

これは今年から取り組み始めたもので、まだ明確な成果は見えていないものの、ユニークな取り組みかつ個人的には手応えのあるものなのでご紹介します。

実装パターン整理会は、フロントエンドの開発効率とコードレビュー効率を底上げするために、
既存の実装パターンを皆でドキュメント化して共有しようというものです。

フロントエンドは実装時のパターンが決まっている部分が多いので、それらを整理・共有することで、
輪読などの勉強会よりも業務で適用しやすい内容で、かつコードレビューで確認する内容も単純化できて効率が上がります。

リストアップ・整理会の進め方としては以下のようにしています

• コードスニペット的な形式でリストアップ
• 参加者を募って、皆でリストアップし、勉強会のようなスタンスでリストアップしたものを確認する会を実施
• 一旦はカテゴリや粒度は気にせずに洗い出していて、後から整理しながら会自体をブラッシュアップする予定

簡単な例： 「指定回数のループ処理を実行する場合」

コツコツと取り組みを続けており、だんだん実装・レビュー時に使えるものになってきています。
また、実装方針について問い合わせが有った時も「ちょうどこないだ整理したページが有るので見てください」と渡すことで、やり取りが非常にスムーズに済んだ場面も何度か有りました。

さいごに

弊社ではようやくメンバーも増えて基盤も整ってきたので、今はレベル2が中心ですが、今後はレベル3として各メンバーがチャレンジしたいことに取り組めるようにしていきたいと考えています。

デザインシステム、a11y、E2Eテストなどなど…様々なテーマの取り組みを通じて、組織の価値提供能力を高められるように取り組んでいきます。

今後それぞれのテーマに関する発信もしていくので、ご興味ある方はXのフォローやDMお待ちしています。
https://twitter.com/_teppeita

また、弊社は絶賛採用中なので、上記のテーマに一緒に取り組んでいきたい方がいればぜひ下記よりご応募ください！
https://www.notion.so/mybest-information-for-Engineers-8beadd9c91ef4dc2b21171d48a4b0c49