はじめに
先日 DDDEurope 2022のセッションの１つ、「Independent Service Heuristics」がYouTubeで公開されました。 発表者は Team Topologiesの著者 Matthew Skelton氏と、いくつかの Domain-Driven Design関連の著者Nick Tune氏です。 このお二人がドメイン境界を特定する簡単な方法としてISHを紹介しています。
今回はこのISHをテーマにしてみたいと思います。
Independent Service Heuristics (ISH) とは
Independent Service Heuristics (ISH)は、検討対象となっているサービスが個別のSaaS/クラウド製品として実行できるかどうかを確認しながら、バリューストリームとドメイン境界を特定するために使用できる単純な経験則／手がかりです。 変化の流れが速い組織を設計する場合、様々な変化の流れの間に効果的な境界（ドメイン境界）を見つける必要があります。この分野はDomain-Driven Design（DDD)などが強力な手法ですが、少し難しいところがあります。これに対してISHアプローチは、軽い中級者向けのアプローチです。
使い方
使い方は非常に簡単で、対象となっているチーム／サービスごとに、以下に示す10個の質問に対して「Yes」（緑）「Maybe」（黄色）「No」（赤）で回答していくだけのものです。
これに回答していくことで、どの領域が明確になっていてどの領域がまだ検討不十分なのか、ドメイン境界として適切かといったことが見て取れるようになります。
1． Sense-check
対象を「サービスとして」提供することは理にかなっていますか？
- これは十分に独立していますか？
- 消費者はそれを理解し、評価するでしょうか？
- それは実行を簡素化していますか？
2. Brand
対象がパブリッククラウドサービス（AvocadoOnline.comなど）としてブランド化されていることを想像できますか？
- それは実行可能なビジネス（または「マイクロビジネス」）またはサービスですか？
- それは説得力のある提供でしょうか？
- マーケティングキャンペーンは説得力があるでしょうか？
3. Revenue/Costomers
収益と顧客の観点から、実行可能なクラウドサービスとして対象を管理できますか？
- 有料サービスで実行可能なサービスでしょうか？
- サブスクリプションプランで経常収益をもたらすでしょうか？
- 明確に定義された顧客ベースまたはセグメントはありますか？
4. Cost tracking
組織は現在、類似のものとは別に、対象に対するコストと投資を追跡できますか？
- インフラストラクチャのコスト、データストレージのコスト、データ転送のコスト、ライセンスのコストなどを考慮して、対象を実行するための全コストは透明ですか、または発見することが可能ですか？
- これらは、組織内の他のものから完全に分離されていますか？
- 組織はこれらを個別に追跡していますか？
5. Data
対象が必要とする（他のソースからの）入力データを明確に定義することは可能ですか？
- モノはどのデータソースからも独立していますか？
- ソースは内部（外部ではなく、私たちの管理下にある）ですか？
- 入力データはクリーン（乱雑ではない）ですか？
- 入力データはセルフサービスで提供されていますか？チームは入力データを「サービスとして」利用できますか？
6. User Personas
対象は、ユーザータイプまたは顧客（ユーザーペルソナ）の小さい／明確に定義されたセットを持つことができますか？
- 特定のユーザーのニーズを満たすものですか？
- これらのユーザーのタイプとそのニーズを知っていますか（または簡単に説明できますか）？
7. Teams
チームまたはチームのセットは、対象に基づいてサービスを効果的に構築および運用できますか？
- チームが集中して成功するためには、認知的負荷（トピックの幅／コンテキストの切り替え）を制限する必要がありますか？
- 重要なインフラストラクチャやその他のプラットフォームの抽象化は不要でしょうか？
8. Dependencies
このチームは、目的を達成位するために、ほとんどの時間、他のチームとは独立して行動できますか？
- これは他のものから論理的に独立していますか？
- チームは、プラットフォームからブロックしない方法で依存関係を「セルフサービス」にできますか？
9. Impact/Value
対象の範囲は、チームに影響力のある魅力的な課題を提供しますか？
- スコープは影響を与えるのに十分な大きさですか？その範囲は才能のある人々にとって魅力的でしょうか？
- 価値が明確に認識されるほど、顧客と組織にとって十分な価値がありますか？
10. Product Decisions
対象に取り組んでいるチームは、独自の製品ロードマップと製品の方向背を「所有」できますか？
- 対象は、明確に定義された実行範囲で個別の価値を提供しますか？
- チームは、発見した製品とそのユーザーに最適化されたものに基づいて、（チームが他のチームの要件や優先事項に左右されないように）独自のロードマップを定義できますか？
ここでの検討対象は、必ずしも外部顧客向けサービスに限ったものではありません。 組織内向けのサービスや組織内で利用するプラットフォーム（Internal Develper Platform / IDP）を対象にすることもできます。（Platform as a Productのコンセプトがここで重要になってきます）
参考例として、こちらがある4チームの関係者がそれぞれの項目について回答したものです。
下から2番目のサービスはまだいくつかの項目で「Maybe」（黄色）や「No」（赤）があり、検討が必要です。 もしかするとドメイン境界があいまい、または不適切で独立したサービスになっていないという可能性もあります。もちろん内部の検討が不十分であるという可能性もあります。MaybeやNoの部分を中心になぜそう感じるのか、その原因はなにかをより深く検討したほうがよいでしょう。
そしてもう１つ。こうした回答を複数のチームで回答することで組織的な弱点も見えてくることがあります。たとえばこちらの例では９のImact/Valueの分野が「Maybe」や「No」がつくケースが多いようです。 この場合では、なぜ「Maybe」「No」なのかをより深く議論したほうがよいでしょう。チーム内の議論が不十分で価値をちゃんと定義できていないのかしれませんし、もしかすると組織横断的にこの領域のドメイン境界が適切でないのかもしれません。
これが７や８の部分で目立つようになるとそれはチーム間の認知負荷が不要に高まっていたり、ブロックされることが増えている兆しのこともあります。こうしたことからサブドメインへの分割や、ドメイン間のチームAPIの整備／改善、Platform Teamへの分離などを考えていく必要があると考えられます。
まとめ
ここで見てきたように、１０個の質問の回答から分析していくのでとても軽量です。この軽量さなら複数のサービス／チームで実施し、横断的に見ていくことも可能です。まずは試してみる。そうしたことが可能なツールではないかと思います。ぜひ利用してみてください。
ACS事業部のご紹介
私達ACS事業部はAzure・AKSなどのクラウドネイティブ技術を活用した内製化のご支援をしております。 実はTeam Topologiesもこうした内製化支援の一部です。
また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。
