Team Topologies で社内ユーザ向け業務システムを開発する組織を再設計してみた

この記事は株式会社エス・エム・エス Advent Calendar 2024の11日目の記事です。

エス・エム・エス BPR推進部システム機能開発チーム長としてマネジメントを担当している及川と申します。

システム機能開発チームでは、「ナース専科転職」や「カイゴジョブエージェント」等、医療・介護業界の人材紹介事業を運営する社員に向けた社内業務システムを提供しています。

本記事では組織のケイパビリティ向上を目指し、Team Topologies という考え方を軸として、開発体制の再設計を実現した事例をお話しします。

なぜ再設計したのか

以下の図は再設計前の開発体制を表しています。この時の体制は、開発のライフサイクルの単位で分割されていました。※紙面の都合上、一部の組織課題にフォーカスしています。

本記事での開発のライフサイクルとは、機能を開発し、改善し、メンテナンスを行うといった活動が挙げられます。それらが個別のチームとして組成されていることで、いくつかの問題が生じていました。

新機能開発チームは複数のプロジェクトを同時進行することで多くのビジネス要求に応えていました。プロジェクト型で進行していましたが、リリースが完了するとプロジェクトメンバーは解散するのでナレッジは組織ではなく個人に蓄積していく過程で、属人化が強化されていました。
運用保守チームは新機能開発チームが担当した機能の追加要望を対応していました。チームの数は１つだけでしたので、複数プロジェクトから生まれる改善要求はバックログに溜まる一方でした。製品品質の向上を優先し技術的負債が積み上がった結果、「新しい要求の調査に2週間かかる」ような複雑なシステムに成長していきました。
スパゲティのように絡み合ったシステムをリファクタする専門チームが生まれましたが、巨大化した技術負債に埋もれていました。改善を実現するためには沢山のステークホルダとの調整が必要で、見積もると数ヶ月〜年単位かかるものばかりでした。その間も新しい要求が新たな負債を生み続けていました。

これらの事象は個人の働き方や考え方が要因ではなく、組織構造の問題、つまり仕組みから生み出されるものでした。事実、チームのメンバーは総じて目の前の課題解決に一生懸命で、構造が生み出す問題に対してやりきれない気持ちを抱えている様子が見て取れました。

こうした課題を解決するために注目したのが Team Topologies です。一言で、「製品開発における価値提供の流れをスムーズにするための組織設計の指南書」といえます。開発組織の活動を単なる機能開発ではなく、市場や顧客の課題解決や新たな価値の提供として捉え、課題発見から解決までの流れを迅速かつ効率的に進めるためのチームの役割やチーム間の関係性が明確に書かれています。

どのように再設計したのか

Team Topologies は価値提供の流れに沿ってチームを組成する考え方です。この分け方には正しい答えはありませんが、価値の最小単位とは何か、そして、１つ以上の価値が集まることで大きな価値となる単位は何か、だと考えていました。

これを整理するために３つの活動を行いました。

最初に、既存の機能をドメインモデリングで整理することで価値の最小単位を発見しました。更に、関連する複数の価値をグルーピングすることで大きな価値としてまとめた時に何が生み出されているのかを俯瞰しました。

次に、課題発見からエンドユーザへの価値提供の流れを Value Stream Mapping を用いて可視化し、その中にどんな価値が含まれるのかを確認しました。これを行うことで、あるチームが１つの価値提供の流れを担当するときに独立して開発のライフサイクルを回せるかを検討しました。

最後に、価値提供の流れを補完するアイデアとして、通称「リボン図」と呼ばれる、人材紹介事業のビジネスモデルから価値提供の流れの着想を得ました。

図中の１つ１つの四角の部分が、ビジネスモデルの活動のなかで生み出される価値といえます。

左側の活動から、求職者をウェブサイトや合同説明会などに「集め」て求人案件を紹介することで、事業所との面談に向かって求職者を「動かして」いきます。右側の活動から、働き手を必要とする事業所に営業活動を行うことで「集め」、彼らが欲しい人材の情報を頂戴し、求職者に紹介することで「動かし」ていきます。そして、求職者と事業者双方が気に入り入所の手続きを経る（「結ぶ」）ことで、我々は手数料としての対価を得ます。これがリボン図の中身になります。

以上、ドメインモデリングの考え方、バリューストリーム、ビジネスモデルの３つの材料がお互いの反証にもなっていることで、新開発体制の設計のロジックとしては充分と考えました。

最後に、現在のチーム体制の図を示します。

価値提供の流れにそって単独で価値を生み出すことができる体制 (Stream-aligned team)が６チームあり、それを支える体制(Complicated-sub-system, Platform, Enabling)が３チームある構成になります。 ※これら名称は Team Topologies で規定されているもので、詳しい説明は本編に譲ります。

価値の単位で組成された各チームのメンバーの最大人数は両手で数えられるほど少なくなりました。コミュニケーションパスが減り議論しやすくなりました。チームメンバーは固定で、ナレッジがチームに溜めやすい構造になりました。

ライフサイクルを分割せず、夫々のチームで新機能の開発と運用保守を担当するようになりました。新しいビジネス要求の対応と技術改善を同時並行することができるようになりました。

最後に、夫々のチームの機能スコープは価値提供の単位で制限されているので、認知負荷が下がりました。ステークホルダの数も減り、課題の解決が容易になりました。