シェア
はてブ
6月28日（金）から29日（土）にかけて、ファインディ株式会社主催の「開発生産性Conference 2024」が虎ノ門ヒルズで開催されました。二日目の11時20分からは、後の7月26日に東証グロース市場へ上場し注目を浴びることになったタイミーが登壇。同社のVPoEである赤澤剛さんが「実践チームトポロジー：プラットフォーム性とイネイブリング性の戦略」と題して、エンジニアチームで必読書としている『Team Topologies』に沿ったエンジニア組織の実践を紹介しました。
■プロフィール
赤澤 剛（あかざわ ごう）/@go0517go
株式会社タイミー エンジニアリング本部 VP of Engineering
2009年から株式会社ワークスアプリケーションズにてSWEおよびVPを担う。
2018年にLINE Financial株式会社でTechnical PjM。2020年に株式会社ユーザベース、株式会社アルファドライブにて執行役員CTO。2024より現職。プロレス・ゲーム・アニメ・漫画・特撮ヒーローが好き。仕事でも「ええやん！」が口癖で、最近はVP of Eeyanといじられることもある。
利用率とリピート率でスキマバイトNo.1の「タイミー」
赤澤：本日は、チームトポロジーという組織モデルをベースに、タイミーで取り組んでいる内容をご紹介します。皆さんのチームや個人に少しでもプラスになればと思います。他にも素晴らしい面白そうなセッションがたくさんある中、このセッションを選んでくれた時点で、僕は皆さんのことが大好きです。何か（ネガティブなリアクションを）ぶつけられても、皆さんにありがとうと言い続けます。
改めて、赤澤剛と申します。タイミーは4社目でして、最初はワークスアプリケーションズという会社で、人事労務や会計のソフトウェアからキャリアをスタートしました。その中で3年間はシンガポールやインドで、研究開発拠点の立ち上げや海外、特にアメリカ向けのお客様の機能開発などをしていました。
全体のキャリアとしてBtoB領域に長く携わっていますが、エンジニアとしてはtoC領域の開発にも関わりたい。欲張りとは思いつつも、両方を得られる会社に行きたいと考え、その後はLINEで金融事業を担当し、今年の1月まではユーザベースという会社の中でBtoBのSaaSを作ったり、NewsPicksという経済ニュースサービスの開発などもしていました。
2024年2月からタイミーにジョインして、今はCTOのkameike（亀田 彗）とともに組織全体を見るVPoEとして活動しています。プロレスやゲームやアニメ、漫画や特撮ヒーローが好きで、中学生くらいの（趣味の）まま大きくなった感じです。仕事でよく「ええやん！」という言葉を使うので、口癖になりすぎてVP of Eeyanといじられることもあります。
ドメイン領域、つまり特定の専門性やドメイン知識が大好きなのですが、領域としては多方面に渡ります。ただ、そのドメインに自分が燃えられる、「こうしたら絶対良くなるやん」という確信が持てる領域に関わっています。共通点は１点だけあり、自分の技術やプロダクトによって「いろいろ大変なこともあるけど、今の仕事は悪くないかな」と思える状況を増やせる、ということ。現職であるタイミーは、その思いを一番感じられています。
ここからはタイミーの紹介をしていきますが、「タイミー知ってるよ」という方は手をあげていただけますか。ありがとうございます。私の力ではなく、ブランドやサービス、プロダクトの素晴らしさですね。おそらく、「お仕事」や「アルバイト」というワードと共に想起いただくケースが多いと思っており、当然その通りです。その上で、タイミーで最も大切にしている概念は「時間」なんです。
赤澤：今のプロダクトでフォーカスしているのは「仕事」ですが、「今日、時間空いちゃったな」という時間と「今日入るはずだった方が来られなくなっちゃってどうしよう、誰か助けて」という時間、この2つを適切に結びつけて両者の人生で有意義な時間に変えていく。それを目指したサービスです。最終的には「仕事」という形で表出しますが、時間を大切にしている、ということが重要なポイントになります。
タイミーには様々な特徴があります。今すぐ仕事が見つかって、面接なし履歴書なしで働いていただける。また、お給料は即日入金です。クライアント様、つまり企業様にとっては、手数料は月末に一括払いです。この差分が、タイミーというプラットフォームが介在する価値のひとつになっています。
赤澤：10代の方などがアルバイトで使ってくださるイメージが強いかもしれませんが、実は、学生と同じくらいの比率で会社員の皆さまが使ってくださっています。年齢で分けると、30代以上が半数を占めています。アルバイトというよりは、大人向けのキッザニアのような、仕事を見つけたりお試しするという使い方もあったり、これは私の友人の例ですが、劇団員の方が本職の稽古とタイミーを組み合わせているといった形で使ってくれていたりします 。お仕事を適切に手段として組み合わせて、自分の人生をより有意義にするよう活用いただいていると考えています。
ありがたいことに、利用率、リピート率でNo.1。（2024年4月時点で）導入事業者数は98,000企業、ワーカー数は770万人にものぼり、昨年度はコロナ禍においても、募集人数の観点で2.2倍の成長率を達成しています。これも皆様のおかげです。
「はたらく」を通じて人生の可能性を広げるインフラを作る、がミッションです。このインフラ性が重要なポイントで、「はたらく」は目的でもありますが、人生の可能性を広げる手段にもできる。そのようなサービスを提供することをミッションとして掲げています。
書籍『Team Topologies』の概念を組織へ適用
赤澤：本セッションは、書籍『Team Topologies 価値あるソフトウェアをすばやく届ける適応型組織設計（以下、Team Topologies）』を読了しているか、組織への適用を実施、あるいは検討している方を対象としています。最低限の解説として、チームトポロジーの概要に触れますが、セッションでは事例含めて個々のパートを取り上げますので、詳しくは書籍をご覧ください。
まず、タイミーの事業やプロダクトの現在地点をご紹介します。その上で私たちは、市場環境のさまざまな変化に対して適応的な開発を継続的に強化するため、チームトポロジーを組織へ適用しています。
特にフォーカスするのは、タイミーでのストリームアラインドチーム（以下、SAチーム）のあり方と、その文化形成の仕方。プラットフォーム性とイネイブリング性の使い分けです。書籍内ではプラットフォームチームとイネイブリングチームと表現されていますが、あえてここでは性質という意味で「性」を使っています。
タイミーのプロダクト開発組織では、2冊の必読書を定義しています。1冊は『LeanとDevOpsの科学』で、もう1冊が今回のテーマとなる『Team Topologies』です。
赤澤：この2冊は私もタイミーにジョインする前に当然読んでおり、特に『Team Topologies』は前職でのCTO時代にも、組織を作る上での必須書籍としていました。特に、この後に触れるイネイブリングSREの部分で、SREをSAチームへ埋め込み、実装していく課程で特に活用していました。
読んで感銘を受けたというよりは、私自身のありたいエンジニア像やエンジニア組織像と、この書籍で語られているSAチームという概念に共通点があり、組織を目指す上での課題とアプローチに関して適切に示唆をもらったと考えています。
「チームトポロジーの原則では……」のように、書籍に沿った組織にこだわったコミュニケーションではなく、先ほどのSREの事例などにおいて今の組織状態を的確に表現する共通言語を得た点でメリットを感じています。例えば、「SAチームにファシリテーションするより、コラボレーションしていく支援が必要なんじゃない」などと話すことができます。
会場内で、書籍を読まれた方はどれくらいいらっしゃいますか。（90％ほどが手を挙げる）みなさん素晴らしいですね。実際、組織に提要している方はいらっしゃいますか。（10％ほどが手を挙げる）ありがとうございます。読んでいらっしゃる方が想定よりも多くてありがたいです。未読の方は、本著の共訳者でもある吉羽龍太郎（＠ryuzee）さんのスライド『30分でわかった気になるチームトポロジー（https://www.ryuzee.com/contents/blog/14566）』を参照してから書籍に入るのもおすすめです。書籍を読んでから、スライドをサマリー的に読むのも理解が深まります。
チームトポロジーとは
赤澤：チームトポロジーとは、「ソフトウェア開発において素早く安定した価値提供フローで、顧客価値の最大化を実現するための適応型の組織設計モデル」となります。「つまり、どういうことだ」と思われると思うので、ポイントを３点にまとめます。
1つめは、そもそも、技術や人、ビジネスにおいて、特にタイミーの場合は競合環境が激しくなっているのはみなさんもご存知の通りです。この変化に継続的に対処し、お客様に対して素早く安定的に価値を提供し続けられる組織を作るためには、組織自体も変わる必要があります。これを適応型という言葉で表しています。
2つめは、チームの目的と責任を明確にして、チーム間の相互関係の効果や効率を向上させましょう、という観点です。
3つめは、唯一絶対のトポロジー型モデルではなく、常に適応型組織モデルのテンプレートとして捉えること。自分たちの組織やプロダクト、事業に適切な組織を考え続けるためのテンプレートとして認識しています。
フロー実現の上でチームトポロジーが中心に据えたものには、次のようなものがあります。
赤澤：特に、今回フォーカスするのは、核論であるチームファーストという考え方と、4つのチームタイプのうち、特にストリームアラインドチーム（以下、SAチーム）とプラットフォームチーム、イネイブリングチームの部分、さらに3つのインタラクションモードの使い分けについて、タイミーの実例も含めてお話しさせていただきます。
4つのチームタイプと、3つのインタラクションモード
赤澤：4つのチームは、ネットで調べればいくらでも出てくるので簡単に紹介します。こう言うと語弊があるかもしれませんが「SAチームと最強の仲間たち」です、以上！と言っています。
最も大事なのは、ビジネスの主な変更フロー、すなわちバリューストリームに沿って配置されるSAチームです。本書ではフィーチャーチームやプロダクトチームと違う、とあえて明言されていますが、（重要な点ではありつつ、）この場では話をわかりやすく進めるために、主にプロダクトでお客様に価値提供するチームだと思ってください。
このチームは職能横断型で、他のチームを待つことなく要求探索から本番運用までのデリバリー一式を担います。４タイプの中心であり、他のチームはSAチームを強化する役割を担う、というのが私の解釈です。
プラットフォームチームは、わかりやすく言うとインフラや共通的な基盤、サービスなどを主にSAチームに提供します。SAチームがその詳細を知らなくても、安定的かつ高速にデリバリーを担えます。
イネイブリングチームは、他のチームに対して新しいケイパビリティの獲得、たとえば新技術やスキルを導入します。主な構成メンバーは特定のスペシャリストで、組織においてはCenter of Practiceを担います。
コンプリケイテッド・サブシステムチームは、タイミーでは明示的に存在しませんが、複雑性が高い高度な専門スキルやドメイン知識が必要なサブシステム、コンポーネントを提供します。前職でも明示的にはしていませんでしたが、たとえば決済基盤などが該当するのではないかと思います。
次に紹介する3つのインタラクションモードは、4つのチーム間のコミュニケーションや連携方法を定義して分類化したものです。
コラボレーションモードは、共通の目的に対して他のチームと綿密に協力し合い、ぐっと中に入っていきます。素早く探索や検証が進み、初期フェーズにおいては有効です。ただ、責務境界を曖昧にして一緒に取り組むので、短期的な生産性が落ちる場合があります。
次のX-as-a-Serviceは、まさにサービス提供です。何らかのサービスをブラックボックスとして提供し、全体の組織間で使ってもらう関係性です。ブラックボックスによって、相手の領域に踏み込まない責務のバリアが働きやすくなります。ここで、境界面のイノベーションが起こりにくくなる現象を避ける施策も、大切なポイントです。
ファシリテーションモードは、あるチームが他のチームに対して、新技術や能力を獲得させるべくティーチングやコーチングなどで支援します。イネイブリングチームが効果的に利用するモードです。
これらを典型的なチーム連携にすると、SAチームはバリューストリーム（＝ある“価値を提供する継続的な流れ”）に沿って価値提供しており、プラットフォームチームは基盤をX-as-a-Serviceとして提供しています。イネイブリングチームはSAチームに対しファシリテーション、コーチング、ティーチングして適切にリードします。コンプリケイテッドサブシステムはプラットフォームチームとは役割が異なりますが、同様にブラックボックスとして複雑性の高い機能やサービスを提供します。
タイミーの開発組織の全体像とチームトポロジーの適用
赤澤：ここからは、タイミーの話になります。このスライドは採用資料などにも載せているもので、Tribeという単位のチーム群と、その中でSquadという実行単位のチームに分かれます。
Tribeは3つに分類されます。1つはSAチームであるマッチングTribeで、出会いを最適化しスケールさせます。厳密にはtoC、toBという分け方ではありませんが、主にはtoCを担っています。
スポットワークシステムTribeは、バックオフィス業務も含めた手続きを担います。つまり、実際にお仕事をしていただき、お金を支払うまでの滑らかな手続きの提供をバリューストリームとしています。
さらに、QAやSRE、DRE、開発基盤などを担うのが、開発プラットフォームTribeとなります。
先ほど紹介した典型的なチームトポロジーの図に合わせて、タイミーの開発組織を表すとスライドのようになります。
（スライド２６）
マッチングTribeとスポットワークシステムTribeは、同じSAチームの大きな単位であり、時にAPIの提供でX-as-a-Serviceとして振る舞うこともあれば、密にコラボレーションして、ディープダイブする場合もあります。イネイブリングチームは、スライドにある紫色のファシリテーションと緑色のコラボレーションの2つを意図的に混ぜています。
まず、SAチームのあり方と文化形成についてお話しします。タイミーでの標準的なSAチームは、人数は8±4名程度の構成です。前述した通り、他のチームを待たずにお客様に対する価値探索からデリバリーまで一気通貫で担えます。チームとしてフルサイクル性を持つ必要があるので、職能横断的なチームとしています。バリューストリームを対象として、お客様に集中するチームです。先ほど説明したTribeという単位の中にあったSquadというチームが、この8±4名という構成になります。
ところで、なぜバリューストリーム、なぜSA（＝ストリームアラインド）チームなのでしょうか。エンジニアとして、価値提供の手段は基本的にプロダクト開発やフィーチャー開発です。ただし、必ずしも機能ではなく、導入のしやすさや、CS部門のサポート効率化なども包含的に提供します。お客様への価値提供は機能であることが多いものの、そうでないものもある。そのため、我々はバリューストリームに沿ったSAチームであり、フィーチャーチームではない、という言い方をしているのです。
では、もう少し具体的にお見せしていきます。例えば、先ほどのマッチングTribeの中では、バリューストリームによってさらに分割されたSquadが内包されています。「Work Well Squad」では、クライアントの皆様がタイミーを活用してくださり、さらに利用拡大していくときにボトルネックとなりがちな様々な手続き、提出物の回収などを円滑にして、働くに至るまでのワーカー・クライアント両者の体験を向上して価値提供の品質を上げていきます。
赤澤：その右側の「Working Relations Squad」では、ワーカーとクライアントの求人をより効率的、効果的にマッチングして、お仕事に至る体験を向上させるバリューストリームを担っています。
チームに不足したケイパビリティの診断と獲得
赤澤：ここで、ケイパビリティという重要なワードを扱います。組織全体の能力、と表現してもいいでしょう。チームに不足したケイパビリティを診断するなかで、SAチームは自分たちが定義したバリューストリームに沿った価値提供を素早く行うため、不足したケイパビリティを自己判断できなくてはなりません。
PdM、スクラムマスター、エンジニアはいずれも主体となってケイパビリティの診断と獲得に取り組みますが、タイミーでは特に、各Squadに配置された専任のエンジニアリングマネージャーがその役割を担います。
さらに、不足したケイパビリティを認識できる状況を両サイドから作っており、1つは今説明した通りSAチームが行う自己判断で、それをプラットフォームチームやイネイブリングチームに対して言語化して連携します。もう1つは、プラットフォームチームとイネイブリングチームが、SAチーム外から課題を適切に認識してSAチームと共通認識を作り、支援していくことです。
自分の教訓であり戒めでもあるのですが、ケイパビリティの不足とリソースの不足を混同しないことは――頷いている方がいらっしゃいますが――とても大事です。課題に対して、すぐにリソースを増やそうと考えがちですが、チームトポロジーはコミュニケーションコストを効率化するための手法でもあるため、不用意に人を増やすのは当然ながらアンチパターンになります。リソースの投入だけでは、人が増えてコミュニケーションコストや認知負荷が上がり「あれ、人は増えたけど当初の目的には達しない」という結果になってしまう。これは、わかりやすくケイパビリティの不足とリソースの不足を混同されているケースでしょう。
ケイパビリティを獲得するための手段はいろいろあります。採用は当然ながら大事ですし、私自身も最重要視しています。ただ、一時的に外部人材の知見を借りたり、組織内で人材のアロケーションをしたり、チームメンバーに成長・挑戦してもらったりすることも大切です。スライドの「育成・自己学習・新領域への挑戦」の部分ですね。チャレンジや失敗を歓迎するのも組織の強さの1つだと思っています。さらに、イネイブリングチームによる学習サポートや、プラットフォームチーム、コンプリケイテッド・サブシステムチームによるサービス提供も、SAチームの不足したケイパビリティを担う手段になり得ます。
ケイパビリティとリソースは密になっているものの、レイヤが違うので混同しないようにしたいものです。
タイミーにおけるプロダクトエンジニアの定義とは
赤澤：文化面の話として、お客様の課題解決のために、プロダクトエンジニアという言葉を用いて「専門領域や役割を広げる越境性を持ってプロダクトの成長に取り組むエンジニア」と定義しています。SAチームのエンジニアには、プロダクトエンジニアという考え方に共感してほしいと考えています。
前述したように、チームの責務領域やAPIを明確にしたX-as-a-Serviceの場合、境界面のイノベーションが起こりにくい可能性がありますが、境界面の連携でイノベーションが鈍化したり、ボールが落ちたりしないよう、適切にオーバーラップさせていきます。
また、裏返しの意味もあり、自分が越境する側でなく越境される側だった場合、越境してくるメンバーを歓迎し、適切なインタラクションで問題解決を加速できる振る舞いが必要です。例えば、野球の守備でぶつかった時に「なんでぶつかってくるんだよ」と言うのか、「こいつは俺の領域までカバーしてくれようとしてくれて、なんていいやつなんだ」と思うのか……。自分が越境していくことと、越境してきた人に対して「ありがとう」と言うことは、SAチームを構成するカルチャーとして非常に大事にしています。
また、プロダクトエンジニアは、フルスタックエンジニアでも、フルサイクルエンジニアでもありません。ともすると、「なんでもできなくてはいけない」という不安をメンバーが持ってしまいがちです。プロダクトエンジニアでフルサイクル性を持つのはSAチームであり、個人ではありません。チームを構成する個人は、尖っていてもいい。特定領域の高い専門性や専任性も明確にプロダクトエンジニアのあり方で、「最高やん」と、等しく歓迎しています。
また、SAチームがファシリテーションモードを受ける際、イネイブリングでの新しい技術や知識の獲得・学習に対してオープンなマインドを組織文化として醸成しなくてはなりません。書籍でも触れられていますが、これは当たり前ですよね。このようなカルチャーがないと、そもそもチームトポロジーは成立しません。
このような文化の話を間に話している理由は、組織（構造）じゃない課題を組織（論）で解こうとすると、何度組織を変えてもうまくいかない、というケースが起こるためです。
プラットフォーム性とイネイブリング性の使い分け
赤澤：ここまではSAチームにフォーカスしてきましたが、ここからはプラットフォームチームと、イネイブリングチームについて解説していきます。
赤澤：タイミーでは、代表的なプラットフォームチームとイネイブリングチームは4つあります。Process Enabling（＝適応型開発の推進）を担うAgile Practiceチーム、QA Enablingチーム、Platform EngineeringとEnabling Site Reliability Engineeringを含むDev Platformチーム、学習文化の推進などを担うDev Enableチームです。
名前にPlatformやEnablingを冠しているのは、それぞれの専門領域においてSAチームを支援する目的があるからです。「SAチームを強くすればいい」という考えはやや乱暴な言い方ですが、大事なポイントです。完全にPlatform、あるいは完全にEnablingというより、それらの両方を持っています。SAチームへの支援を最大化するために、振る舞いとして強い方の名前を冠していますが、内部的には混ざっているわけです。
チーム間のコラボレーションでは、典型的なものと偶発的なものが存在します。コラボレーションをおさらいすると、各チームにディープダイブし、責務の境界を意図的に曖昧にして探索や新領域の導入を一気に加速させるモードです。短期的には生産性が落ちる可能性もある、と説明しましたが、中長期的には加速させる側面があります。
イネイブリングチームとプラットフォームチームは、不足したケイパビリティの把握、提供するサービスの利用促進、新しい知識の獲得のため、適切にコラボレーションを使う必要があるでしょう。いきなり綺麗なファシリテーションやティーチング・コーチングをしようとすると、やはり距離ができてしまう。特に初期はコラボレーションの活用を重視し、意図的に使うようにしています。
赤澤：私は申し訳ないことに書籍の原書を読んでいないので、使われている英語と違っているかもしれませんが、「偶発的」という言葉は、Accidentallyというより、Intentionallyというイメージです。この「偶発的」と書かれた部分は、フェーズやチームの成熟度に応じて、意図的に使ってもらっています。
赤澤：例えば、Agile Practiceチームの例を挙げると、「スクラムマスター」というメンバーの役割があります。タイミーの組織で言えば、適応型の組織作りを推進するための専門チームがAgile Practiceです。アジャイル開発のCenter of Practiceになっており、SAチームの成熟過程の初期では、専任のスクラムマスターとしてSAチームにEmbedする形で入り、内部からリードします。
赤澤：チームが成熟するにつれ、意図を持ってインタラクションモードを段階的に変えていきます。例えば、最初はSAチームではほぼ全てにおいて専任スクラムマスターが関与していましたが、SAチーム内のエンジニアやエンジニアリングマネージャーがスクラムマスターを担ってファシリテーションモードで連携するパターンに遷移していたり、SPACEフレームワークを用いたダッシュボード提供の部分でX-as-a-Serviceとしての振る舞いが増えていたりします。まさに今取り組み中です。
チームトポロジーの原則に従って動いているというより、これらチームの変化を表現するために『Team Topologies』の共通言語を活用している状況です。
QA Enablingチームも、イネイブリング性とプラットフォーム性の両方を持ちます。プラットフォーム性の部分では、品質分析や、SET Infraの提供、SETライブラリの開発を担っています。イネイブリング性では、そのライブラリやインフラが浸透するようにティーチング・コーチングしたり、中に入ってインプロセスQAに取り組むことも、QAコーチとしてファシリテーションモードで振る舞う場合もあります。
赤澤：QAファンネルにおける現在のQA Enablingチームの主な役割は、インプロセスQAとして開発組織に常駐しながらQAの実業務と品質文化を担っていたり、そこから少しティーチング・コーチングにシフトして、QAコーチとして振る舞っていたりします。この先は図の下側に行くほど良いというわけではなく、今の組織に合わせて柔軟に取り組んでいます。今後はよりプラットフォーム性の振る舞いを増やしてQA Platformチームになるかもしれません。あるいは、チームの成長より拡大の方が大きいという理由から、もっとインプロセス性を上げるかもしれません。
QAコーチの例としては、一緒に品質ディスカッションをしてアドバイザーとしてリードしたり、一緒にトレーニングの計画を担当したりします。
赤澤：Dev Platformチームでは、プラットフォーム性を持つものがわかりやすく、共通的な基盤の提供といった言葉でまとめてきました。Platformチームとしては、CI/CD Pipelineの提供、SLI/SLOのダッシュボードを提供するIaC基盤――うちの場合はTerraformですね――の提供、シグナル基盤や収集基盤の提供を役割として担っています。
赤澤：イネイブリング性としては、先ほどの観測性の部分をガイドしたり、モニタリングとアラートのために把握すべき状態と改善方法をリードしたりする部分を担当しています。現在、SAチームがもっと実装完結できるようにSREの役割を持ち、意図的にイネイブリングの性質を増やすべきなのではないか、とDev Platformチームの責任者と検討しているところです。
切り取られると怖いのですが、自分でデリバリーの責任を負えないSAチームのことを「靴紐を結べないランナー」と表現することがあります。皆さんも経験がないでしょうか、「なんかPipelineこけたんですけど」と「靴紐がほどけたんですけど」みたいな言い方で言われること。「いや、自分で結んでや」と言いたくなリます。自己完結してデリバリーの責任を負えるチームを作るためには、SREのケイパビリティを持たなくてはいけないでしょう。強いプラットフォームチームを組成するのも重要ですが、あくまでSAチームとして自走できるようにイネイブリング性を高めよう、という話もしています。
プロダクト開発メンバーの進化に特化した専門部署「Dev Enable室」
エンジニアの本業務は、当然ながらエンジニアリングです。エンジニアリングに集中できる環境を作りたい意図と、プラットフォーム性とイネイブリング性の両面から、タイミーでは「Dev Enable室」という部署を設けています。さらに、「TDE10（Timee Dev Enable 10）」という名前で10大施策に取り組んでいます。わかりやすい手当や、リモートワーク環境の設備備品のサポート、出張時の申請手続きなどバックオフィス業務の代行などです。また、今日の発表で私も助けてもらった制度ですが、伝えたい内容にフォーカスできるように表現のアドバイスなどをくれる文豪待遇制度もあります。これも、イネイブリングとしてエンジニアがエンジニアリングにフォーカスできる状況を作るための施策の1つとなります。
赤澤：最後に、タイミーでのチームトポロジー実践のポイントを改めてまとめます。1つ目は、SAチーム足りうるために、不足ケイパビリティの自己診断と獲得を継続的に強化していきます。プロダクトエンジニア的な思考文化を用いるとともに、継続強化はエンジニアリングマネージャー、スクラムマスターの役割とします。
２つめは、唯一絶対の静的なチーム構造やインタラクションに固定しません。ビジネスの状況やチームの成熟状況に応じて、インタラクションモードだけでなく、そもそものチームタイプ（イネイブリング性/プラットフォーム性）を意図的に使い分けます。場合によってイネイブリングチームからプラットフォームチーム、あるいはその逆にシフトすることもあれば、イネイブリングチームとプラットフォームが別々の組織として存在する場合もありえます。
3つ目です。プラットフォームチームとイネイブリングチームは、初手からX-as-a-Serviceやファシリテーションモードで綺麗に振る舞おうとするとなかなかうまくいきません。コラボレーションモードを意図的に使ってSAチームにEmbedし、ディープダイブして課題の把握と解決を一緒に担うのがポイントです。
ケイパビリティとリソースの話や、他チームから見たSAチームのケイパビリティ、課題の把握、本日は触れられなかったコンウェイや境界面の話も、またどこかで深掘りしてお話しできればと思っています。本日は、ご清聴ありがとうございました。
