KabuK Styleのプロダクト開発をとりまくチームのトポロジー
KabuK StyleのCOO兼CTO 後藤です。前回の記事で、CTO直属のチームDigital Service Unitについて簡単に紹介しました。
今回の記事では、KabuK StyleにおいてHafHというプロダクト開発を担っているProduct Unitと、Digital Service Unitとの役割分担の設計や、ワークさせるための方針を紹介します。この設計は将来のための一手ではありますが、あくまで今の事業・組織のフェーズにフィットする設計に過ぎません。チーム設計の良書『チームトポロジー』にもある通り、組織自体がセンシングする能力を身に着け、変化に適応しながら全体最適な方向へ一歩づつ進化させていきます。
また、1点お断りしておくと、KabuK Styleのプロダクト開発組織のサイズはまだ20名程度で、さほど大きくありません。皆さんの環境と比べると、問題の難易度や複雑度はまだそれほど高くないフェーズかと思います。
チームトポロジーは静的なものではなく、状況に合わせて変えていくものだ。
Digital Service Unitって、プラットフォームチームでしょ？ いえ、違います
最初に勘違いしやすそうな点として、Digital Service Unitがいわゆるプラットフォームやインフラチームのように見えてしまう事があります。この記事を読んで頂ければ分かるのですが、これはある側面では正しいのですが、組織設計の基本コンセプトとしては全く異なっています。
単一のプロダクト開発組織、またはエンジニアリング組織だと扱いづらくなる問題たち
いきなりですが、具体例から入っていきます。KabuK Styleで開発しているHafHというサービスで、次の2つの機能やそれらに対する要望の例です。
施設の検索機能
HafHは、登録いただいたユーザーに様々な施設に宿泊いただけるサービスです。このサービスにおいて、施設を検索する機能は、ユーザーに価値を提供するまさに入り口であり、ユーザー目線での検索体験の向上はとても重要です。
検索に使われる情報は、HafHに登録頂いている宿泊施設およびやり取りしているKabuK Styleのメンバーが登録を行います。登録する情報の種類、登録のしやすさ等、宿泊施設側を使いやすくすることで、情報の正確性や鮮度が向上し、結果としてHafHユーザーの検索体験も向上します。
しかし、宿泊施設向けの改善は、HafHユーザーの体験向上への寄与としては間接的であり限定的とも言えます。HafHユーザーの体験を大きく向上することを主眼に置いた優先順位をつけると、どうしても低いところに設定されてしまいます。
チャネルマネージャーとの連携機能
チャネルマネージャーとは、サイトコントローラーとも呼ばれ、宿泊施設の宿泊プランを複数のOTA（オンライントラベルエージェント、booking.comやじゃらんのような旅行予約サイト。HafHもこのカテゴリ）へ掲載し、それらからの予約処理を管理するシステムです。OTA側としても、サポートするチャネルマネージャーを増やすことで、宿泊施設側がどのチャネルマネージャーを利用していても、HafHに負担なく加入できることにつながります。
チャネルマネージャーのサポートを拡充することは、HafHユーザーの体験を部分的に向上しますが、例えばこれによって加入ユーザーが一気に拡大するほどのインパクトは持ちません。したがって、プロダクト観点での優先順位は低く設定されてしまいます。
似たような状況はあらゆる組織で起こっていると思います。ロジカルに物事を判断すれば必ずそのような考えになるからであり、判断ツールの一つであるアイゼンハワーのマトリックスを使うと一目瞭然です。例えばプロダクトや事業周辺にある諸々の課題が、以下のように分類されたとしましょう。なおこの時点ですでに、Product Unitの観点が入っています。Product Unitは、プロダクトのユーザー（旅行者）に対して価値提供することが他のすべてに優先されるミッションであり、このミッション達成に対して潜在的なインパクトの大きさが「重要度」、またシーズナリティや競合状況などから「緊急度」が得られますが、これらはあくまでProduct Unitのミッションを基準にした尺度になります。
プロダクトマネジメント界隈ではRICEなど様々な優先順位付けフレームワークが検討されています。ここで取り上げたアイゼンハワーマトリックスは分かりやすい例として使っているだけで、KabuK Style内でこれをプロダクトマネジメントに使っているわけではありません。
アイゼンハワーのマトリックスでは、「重要かつ緊急」であればまずすぐに取り組む。同時に「重要だが緊急ではない」課題についてもスポットをあてなければならないと言われています。
第 2 領域：重要だが緊急ではない（スケジュールに入れておくべきタスク）に分類される場合、それは重要度の高い長期的な目標やタスクです。ただし、明確な期限が決まっているわけではないので、作業日をスケジュールに入れておいて後で取り組んでもかまいません。たとえば、業務で使う資格の取得のほか、予算の削減といった長期的なビジネス目標を計画する場合などが該当します。
しかし人的リソースは限られ、またできるだけ一人の人間が扱う問題のコンテキストが散らばらない方が良い（認知負荷を低減する）ことなどから、このような組織に通底する力学として、Product Unitで取り組む課題は、基本的に「重要かつ緊急」に分類された課題のみになっていきます。
では「重要だが緊急ではない」課題はどうするのか。放置してよいのでしょうか。
そこでDigital Service Unitiの出番です。「重要だが緊急ではない」と分類されている課題を拾い、事業や組織全体として中長期に対して手を打てている状態を作ることが、このユニットの最もシンプルなミッションになります。
Digital Service UnitとProduct Unitとの責任境界の設計
DIgital Service Unitは、Product Unitの優先順位ではこぼれ落ちてしまう課題を拾う。一見すると分かりやすいルールですが、このような定義のままチームでの仕事を進めると、いずれ機能不全に陥ります。なぜなら、Product Unitとは独立したチームを標榜していながら、自分たちが取り組む課題や責任を決める基準が、Product Unit側の優先順位という尺度になっており、受動的な定義になってしまっているからです。これでは、常にProduct Unitにおうかがいを立てて仕事をするハメになってしまいます。
自分たちのチームのミッションを明確にするためには、Product Unitとの間に何らかの「節理面」を見出し、事業やプロダクトの特定の部分に対して、Digital Service Unitが自分たちの責任範囲であると主体的に定義できなければなりません。では、その節理面をどのように見い出せばよいのでしょうか。
ステークホルダー観点での節理面
結論を書くと、今回は「プライマリーステークホルダー」という考え方によって節理面を見出しました。『チームトポロジー』で紹介されている節理面は以下に掲載する8つで、この中では「ユーザーペルソナ」とほぼ同じニュアンスの分離方法です。
ビジネスドメインのコンテキスト境界
規則遵守
変更のケイデンス
チームの地理的配置
リスク
パフォーマンスによる分離
技術
ユーザーペルソナ
前節で取り上げたProduct Unitの課題分類は、ステークホルダーという観点では、HafHというサービスを利用する旅行ユーザー（当社ではネイバーと呼びます）をプライマリーステークホルダーとする立場で、各課題をカテゴライズしています。
他方、HafHというサービスを成立させるには、宿泊施設にHafHに参画頂き、宿泊プランを掲載頂く必要があります。この時点で、宿泊施設はHafHというプロダクトのステークホルダーです。プロダクトの機能としては、管理機能の一部である宿泊施設情報や宿泊プラン情報入力機能は、宿泊施設向けのものです。また、ネイバー向けの宿泊プラン検索機能は、入力した施設や宿泊プラン情報に基づいて動作します。検索するのはネイバーですが、どのような検索結果になるのかという点で、宿泊施設は検索機能の重要なステークホルダーです。また、ネイバーからは直接見えない、チャネルマネージャー連携といったバックエンドの機能は、ネイバーはあくまで間接的な受益者であり、プライマリーステークホルダーは宿泊施設といえます。
同じように、社内のカスタマーサポートチーム、会計チーム等、他にもステークホルダーがいます。
プライマリーステークホルダー観点での節理面とは、明らかに一つのステークホルダーだけにフォーカスしている組織を見出し、そのフォーカスを促進するように、他のステークホルダーに対する責任を切り離す、このステークホルダーの分け方です。
今回KabuK Styleでは、Product Unitが「ネイバー＝旅行ユーザー」というプライマリーステークホルダーへフォーカスすることを促進し、Digital Service Unitがそれ以外のステークホルダーに対する責任を一手に担う形になっています。
このようにプライマリーステークホルダーによってチームの責任を分割することで、Digital Service Unitは、Product Unitから独立した観点で課題の優先順位付けを行えるようになります。
節理面による分離の度合い
上で述べたステークホルダーによる節理面は、現状、仮想的な分離基準にとどめています。ソフトウェアの分割は基本的には行っておらず、モノリスのままです。現時点でこの節理面に沿ってソフトウェアを分割する計画はありません。この意味で、我々が実施したプライマーリーステークホルダーによる節理面は、現在のところ分離によって一般的に得られるメリットは弱くなっているでしょう。このような分離の度合いに留めていることには、理由があります。
最も大きな理由は、トートロジーですが、それがソフトウェア的な節理面ではないからです。これは我々のビジネス特性による影響もあります。HafHというサービスは、旅行ユーザーに対して価値を提供するものですが、旅行ユーザーが宿泊する施設抜きにはサービスが成立しません。さらに我々のサービスは価格のあり方にアプローチしており、宿泊施設のビジネスに無視できない影響を与えるものでもあります。宿泊施設の検索という機能一つを取り上げたとき、旅行ユーザーの利益を100%優先して開発すればよいとは我々は考えておらず、旅行ユーザーの利益と、宿泊施設の利益とを、バランスをとりながら設計するものだと考えています。一方でこの二者はある側面では利益相反の関係にもあり、ここに緊張関係があります。
複数のステークホルダーの利益を統合して捉え、理想的には三方良しの設計を行う。これが我々が目指している世界です。そのためには、機能のオーナーシップにある程度の曖昧さを残しておく組織設計が重要だと考えています。
このような理由から、プロダクトのソフトウェアを分割するという決定は今は行っていません。
Digital Service Unitと他組織とのインタラクションモード
Digital Service Unitは、『チームトポロジー』におけるチームタイプとして、4種類のすべての側面を持ちます。それぞれDigital Service Unitが持つ責任の例と合わせて記載します。
ストリームアラインドチーム
中長期の事業展開を視野に入れた第2第3のプロダクト開発
社内ステークホルダー向けの業務効率化、自動化
コンプリケイテッドサブシステムチーム
HafHのコイン数算出ロジック
HafHのビジネス会計を新収益認識基準ベースで実施するためのシステム
チャネルマネージャーサポート
イネイブリングチーム
社内のデータ活用力向上のためのアクティビティ
チーム全体に渡るデータ活用や業務効率改善の主導
プロダクトの技術設計のレビュー
プラットフォームチーム
ビジネス可視化のためのダッシュボード整備
データドリブンな意思決定を促進するためのデータ分析基盤整備
システムのプロダクション、ステージングおよび開発環境整備
システムの可用性向上にまつわる作業
インタラクションモードとしては、どちらかというとX-as-a-Serviceとなるように重心を置いていますが、連携先のチームの課題に応じて異なるやり方も併用しています。
ファシリテーション
主にイネイブリングチームとしての役割を、ファシリテーションによるコミュニケーションで実施しています。例えば、データ活用力向上アクティビティは、チーム主催で毎週定期でSQLの練習時間を設け、参加者が問題を持ち寄って自身でSQLを書けるようになることをサポートしています。
コラボレーション
プロダクトの技術設計レビュー等は、コラボレーションの側面もあります。
コラボレーションよりも2歩踏み込んだモード：オウンド（Owned。筆者による命名）
コラボレーション先に対して、相手の課題の難易度や求められる解決スピードなどによっては、責任の共有度合いを高めるやり方もあるかと思います。1歩踏み込んだコラボレーションのあり方としてエンベデッド（Embeded）があります。相手先のチームの一員として一定期間仕事をするコラボレーションです。そこから更にもう一歩踏み込んだコラボレーションとして、オウンド（Owned）という形もありえます。相手チームに対して、一時的に一部または全部の責任者となることで、強力に変革を推進するコラボレーションモードです。
現在、Digital Service Unitのメンバー1名は、他チームのサブリーダーという形で一定の領域のビジネス的な責任まで持ち、データ活用や業務プロセス改善などを含めた総合的な変革を担っています。
おわりに
企業が事業を行い、それをスケールさせていく上で、様々な課題が立ち現れます。事業戦略上重要な課題を特定することはもちろん、それらの課題に対して、組織がなめらかに対応できること、別の言い方をすると、組織が自律的にそれらの課題を解くよう設計されていることが重要です。銀の弾丸はありませんが、事業戦略と組織の構造、そこにいるメンバーたちと向き合い続け、最適解を探し続けることが肝要かと思います。
それから、チームの設計を語るための共通言語として『チームトポロジー』は有用です。まだ読まれていない方はぜひご一読をオススメします。
合わせて以下の記事もどうぞ
チームのPdM Bucciのインタビュー
KabuK Styleの最強チームDigital Service Unitで、自分の持っている潜在能力を200%発揮するような仕事をしてみたい方、是非カジュアルにお話しましょう!!!
エンジニアも募集しています!
この記事が気に入ったらサポートをしてみませんか？