Enabling Teamを立ち上げました

Satoshi Tajima
The Finatext Tech Blog
Dec 11, 2023

--

この記事はFinatextグループ10周年記念アドベントカレンダーの11日目の記事です。
昨日は狩野さんが「1人目QAとして他業種から飛び込むときのマインドセット」という記事を公開しています。

こんにちは、Finatextの @s_tajima です。
今回は、Finatextグループにおいて、「競争優位性を生み出す技術」をより増やしていくためにEnabling Teamを立ち上げた話です。弊社のEnabling Teamが、どんな役割で、どんな特徴を持った立ち上げ方をしていて、どんなテーマに取り組んでいるかといったお話を書いています。

Enabling Teamとは

Enabling Teamは、 Team Topologies で紹介されている組織形体の1つで、以下のように説明されています。

イネイブリングチームは、特定のテクニカル(プロダクト)ドメインのスペシャリストから構成され、能力ギャップを埋めるのを助ける。複数のストリームアラインドチームを横断的に支援し、適切なツール、プラクティス、フレームワークなどアプリケーションスタックのエコシステムに関する調査、オプションの探索、正しい情報に基づく提案を行う。

マシュー・スケルトン,マニュエル・パイス. チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計 (Japanese Edition) (p. 151). Kindle Edition.

つまりEnabling Teamによって、難易度の高い実装や機能を、より適切な方法で実現できる可能性を高められると考えています。

なぜEnabling Teamが必要か

「競争優位性を生み出す技術」になりうるのは、得てして簡単に習得できるものではなく、現時点では組織の中の誰も持っていない、より高度な技術・ノウハウである可能性が高いと考えています。
また、プロジェクトの通常の開発スケジュールの中で、重みのある新しい技術検証→実践導入という対応をするのは難易度が高いと考えています。特定プロジェクトの個別要因に引きづられすぎず、最大公約数的・汎用的な設定やアーキテクチャを突き詰めて考えておくことも大事です。そのために、Enabling Teamをプロジェクトやプロダクトとは切り離し、独立した組織として立ち上げることにしました。

FinatextにおけるEnabling Teamの特徴

FinatextにおけるEnabling Teamの役割は、「今のプロダクト開発の直線的なマイルストーンには乗らない技術を検証し、習得したりノウハウを溜めた上で、これを実プロダクト・実環境に導入するサポートをおこなうこと」です。

これを前提に、大事だと考えているポイントが4つあります。部分的には、一般的なEnabling Teamの役割やプラクティスとは異なる部分もあるかもしれません。

1つ目は、「メンバーがすでに持っているノウハウや知識に頼るのではなく、まずはEnabling Teamにアサインされたメンバーが新たにその能力を習得することを前提とすること」です。Enabling Teamとして取り組みたいテーマは、多くが難易度が高かったり、そのノウハウを保有する人の希少性が高い領域となります。よって、「誰かがすでにその知識を持っていること」を前提とするべきではないと考えました。

2つ目は、「実プロダクト・実環境への導入を(強めの)前提とすること」です。
CoP(Communities Of Practice)やR&Dとして、学習や技術検証やその研究成果の発表までを主な目的とするのではなく、実際に社内のどこかで使われている状況にすることまでをゴールとしています。こうすることで、Enabling Teamが解散してもそのノウハウが社内で維持されることを担保できます。逆にいうと、状況の変化等で実環境への導入の目処がなくなったのであれば、そのテーマへの取り組みは終了させるべきと考えています。

3つ目は、「”Enabling Team” として1つのチームにするのではなく、テーマごとにそれぞれ独立したチームとすること」で
す。Enabling Teamとして取り組みたいテーマは多岐にわたります。すべてのテーマを1つのEnabling Teamとして少数人数で担当するのではなく、それぞれのテーマごとに適任者を見つけてアサインするほうが良いと考えました。一方で、Enabling Teamとしてのメタな技能(スキルトランスファーに長けているとか、プロダクトに特定機能を導入するのがうまいとか)の重要性は感じてはいるので、中長期では専任者を置くことも視野には入れています。

4つ目は、「システムの運用の責任を持たせないこと」です。これは、2つ目で書いた、チームを解散させることを意識しています。システムの運用責任を持つ前提があるのであれば、チームを短期で解散させるべきではないため、これも大事なポイントです。

どのようなテーマに取り組んでいるか

2023年12月現在では、以下のようなテーマに取り組んでいます。

認証・認可基盤

Open ID Connect / OAuth / Financial-grade API / Passkeys といったキーワードを軸に、それぞれの仕様や実装を理解し、プロダクトに適切に導入するチームです。

マルチリージョン

金融庁による「オペレーショナル・レジリエンス確保に向けた基本的な考え方」に記載された内容への対応や、大阪リージョンの拡充をきっかけとして、システムのマルチリージョン化の取り組みをするチームです。

コンタクトセンター

主にAmazon Connectを活用し、より洗練されたコンタクトセンター(≠ コールセンター) の実装をするチームです。
Amazon Qを始めとするGenerative AI / LLMの活用もスコープとしています。

ナレッジベース

社内の知識を管理し、オンボーディングの効率化や、業務プロセスの疑問を解消することを手助けするための仕組みを作ります。
これも、Generative AIやLLMの活用を想定しています。

以上、簡単にですがFinatextグループのEnabling Teamのご紹介でした。
明日は、Takuma Kobayashiによる「Finatextは僕を変えた〜23卒エンジニアの入社エントリ〜」です!

--

--