我々の製品を設計し、構築し、リリースするまでの道のりにおいて カスタマーエクスペリエンスプラットフォーム, Trustyou HOSPITALITY AI解決策の柱の一つとして、我々は製品開発とエンジニアリング部門全体を変革し、迅速かつ革新的なアプローチに適合させるため、働き方を一新した。.
今日は、ここ数年で最も影響力の大きかった変更の一つを紹介したい。それは「“臨時チーム”—あるいはTチームという概念だ。.
一時的なチームとは何か？
A Tチーム は 限定期間チーム 設計された 協力を促進する 特定の目標を達成するために必要な個人たちの中で。これは達成される。 技術者を集める 明確な目的を持ってフルタイムで働く。.
我々はTTeamsを構築する 明確に定義された範囲 数週間以内に納品できるものだ。範囲が確定したらチームは解散する。あるいは初期作業後に新たな発見で中止になるか、予算内に収まるよう範囲が再定義される。.
Tチームとは 部門横断的な そして チーム横断 異なるスキルセットを持つエンジニアや、プロダクトマネージャーやプロダクトデザイナーといった他の役割、さらには必要な知識やスキルを持つ他部門の同僚も加えたチームを編成する。各Tチームにはプロダクトリードとテクニカルリードが配置される。これらの役割は必ずしもTチーム外でのリーダーシップポジションを意味するわけではなく、エンジニアが明確な文脈の中でリーダーシップスキルを磨く機会を提供する。.
長続きするチームと一時的なチーム 製品開発のために
我々は構造を維持している。 長続きするチーム 処理する ローカルな変更、長期的な技術戦略と運用 各サブシステムごとに、明確な責任範囲を持つ。長期間存続するチームは 知識の錨 サブシステムのうち。一方、, 一時的なチーム 我々に可能にする 集中力と流れを高める 最も複雑な機能を設計し実装する際に。.
Tチームが活動中は、メンバーは所属する長期チームの日常業務から離れる。各Tチームは独自の働き方を決める。通常は非常に実用的で無駄を省く：専用のSlackチャンネル、アイデアの共有と議論のためのMiroボード、タスク管理用のシンプルなカンバンボード、そして定例会議よりもペアプログラミングやワークショップを重視する。.
Tチームが解散すると、各メンバーは元の長期チームに戻り、通常の職場環境では得られなかった貴重な知識やインサイトを持ち帰る。.
実例 集中とフロー
例を挙げて説明しよう。我々が機能の一つを構築しリリースした過程を見てみよう： アンケートのクチコミを不適切としてマークする.
この機能はCXPプラットフォームの受信箱から起動される。アンケートクチコミが不適切とマークされると、承認フローと通知を経る。承認されると、そのクチコミはdashboard全体のKPI計算から除外され、受信箱で特定のステータスが付与される。.
この機能の実装には、異なるチームが担当する複数のプラットフォームコンポーネントの変更が必要だった。.
典型的な 長寿命チームによるエンジニアリング体制, この機能を実装するためのタスクは 複数のチームのバックログに分散されている. 作業の調整には 追加計画 各チームの通常スケジュールに加えて会議を行い、事前に調整する。 インターフェース、テストデータ、その他の依存関係. 機能開発に携わるメンバー間の必要不可欠な接点は、長期間にわたるチーム内での日常業務における「オーバーヘッド」であり例外でもある。その結果、優先順位の相違、タイムラインの不一致、見落とされた依存関係が生じる。 しばしば遅延や不満を招く.
我々のケースでは、この機能を構築・リリースするための一時的なチームを編成した。このTチームには、影響を受けるサブシステムを担当する各チームから、異なるスキルを持つエンジニア4名が参加した。それらのチームのリーダー1名とプロダクトマネージャー1名が、兼務としてリーダーシップを担った。.
三週間以上, 臨時チームは協力して働いた。 機能を設計し、実装し、テストし、リリースする。 単一優先度, 定期的な同期、そして オンデマンドのペアプログラミングとグルーミングセッション. 障害要因は特定され、直ちに対処された。また、誤解は早期段階で発見され、修正された。. 皆が同じ方向に向かって力を合わせた, その結果、成功裏に、かつ予定通りにリリースされた。.
主な成果と得られた教訓
一時的なチームの概念は、特に以下の課題に取り組む際に、我々にとって画期的な変化をもたらした。
- クロスチーム機能： 複数の長期にわたるチームにまたがるエンジニアの専門知識が必要な機能の場合、TTeamsは依存関係を解消し、待機時間や障害を減らす。タスクを複数のバックログに分割する代わりに、TTeamsは全員を共通の目標に向けて一致させる。.
- 不確実性が高い、あるいはリスクの高い作業： 不確実性やリスクが高い状況では、Tチームは形式的な手続きを減らし柔軟な働き方を可能にする。この焦点化により、チームは複雑な問題に集中して取り組むことができる。.
もちろん、すべてが完璧だったわけではない。私たちが直面した主な課題には以下のようなものがある：
- チームが多すぎる。 TTeamsの可能性を見出した後、我々は当初、一度にあまりにも多くのチームを立ち上げた。範囲管理、キックオフ、解散を適切に行うには時間と労力がかかる。過剰なTTeamsは混乱を招いたが、優先順位付けと稼働中のTTeams数を制限する管理策を確立するまで続いた。.
- 計画不足： 初期段階では、既存チームへの影響を考慮せずに、急いでTTeamsを立ち上げた。今では数週間前から計画を立て、予期せぬニーズが生じた場合でも、混乱を最小限に抑えるようタイミングを慎重に検討している。.
試して学べ！
チームは重要な資産となった。 集中力と流れを高める 当社の製品・エンジニアリング部門の。.
しかし、, テスト＆ラーニングは、Trustyouにおける中核的価値観の一つだ。, そして我々は、この手法を臨時チームの概念に適用し続けている。我々は定期的に振り返り、学び、そしてそれらを活用する方法を洗練させている。.
もし、例で説明したような長期間活動するチームに似た状況に直面したら、一時的なチーム形態が有効かどうか検討する価値があるかもしれない。.
