前書き

マイクロサービスやらドメイン駆動で頻繁に出てくるこの【境界付けられたコンテキスト】

もっとも関心を寄せるべきビジネス的に＋の意味でも、－の意味でもインパクトのデカいシーンを想定して、
コンテキストの境界をマクロレベルからパッケージというミクロなレベルにおいてそれぞれ定義していく。

UAFでいうとServicesビューやOperationalビュー、Resourceビューで主に扱っていく。
この境界の位置が変化すると自ずとオーナーシップを持つべき責任範囲も変更され、
評価の仕方も変わることになる。

図解

ちょうど組織全体を黒い四角。各事業をピンクの四角。
ブルーが事業を成立させている各チームだとしよう。

こうやって徐々にマクロ～詳細なミクロレベルで境界を定義していく。

また忘れてならないのは、一度定義したコンテキストの境界位置は、
ある瞬間のスナップショットでしかない　ことを忘れてはいかない。

外部環境や内部環境の変化に伴って、その位置は変化してしまう。

境界の位置の曖昧さ

自分たちがビジネスに対して深い理解をできていない状況では、境界の位置はまだ朧気である。

上図のように境界の位置はハッキリしている部分と、そうでない部分とが入り混じっていることになる。

外部環境は時間経過とともに変化してしまうので、
外部環境の変化がゆっくりで近似的に変化が起きていないと見なせる程度の短い期間で
境界の位置を探索しなくてはいけない。
モタモタしていると境界の位置変化を見失うことになり、それが脅威を生みかねない。

ここで言っている境界の位置というのは、プロセスの側面だけに留まらない。
データの観点での境界という意味も込みでの境界である。

変化する環境に伴う境界の位置変化

外部環境や内部環境が変化すれば、考えるべき優先度の高い想定シーン、
ビジネス的に＋の意味でも－の意味でもインパクトのデカいシーンは変化する。

つまり一度定義したコンテキストの境界は位置を変えなくてはいけない。

勿論シーンが変わっても境界位置が不変的に近い部分もあるし、逆にめっちゃ変わりやすい部分だってある。
そのめっちゃ変わりやすい部分の代表例として、【コアドメイン】がある。

コアドメインは、もっとも価値を生み出す領域であり、同時にそこのしがらみによってもっともマイナス価値を生み出しやすい部分でもある。

マイクロサービス化アンチパターン

そんな各コンテキストの形状が朧げなままであるにもかかわらず、
無理にサービスとして分割してしまったがために、
マイクロサービス化しようとして失敗しているプロジェクトはよく耳にするのではなかろうか？

そんなわけで今回は、この位置が曖昧であったり、位置を変えてしまうコンテキストの境界に対して、自分たちはどう向き合っていくべきか？　触れていきたいと思う。

職能別という切り分け方

ドメインごとのサービス境界は、時間経過に伴って位置を変えてしまう可能性が高いが、
環境変化の影響を受けない超汎用的な境界の定義の仕方がある。
それがこの職能別の切り分け方であり、非常に有名な切り分け方である。

メリット

・おのおの自分の専門性という強力な強みを生かしやすい
そのため、素早いデリバリーではなく、運用特性上の品質をみっちり担保したいって時には
適した割方である。

・特定の業種とかドメインに依らない切り分け方
・汎用的でシンプルなため学習コストが低い

デメリット

・自分たちの職能という領域内で最善を尽くそうとするので視野狭窄になりやすい
連携先のことを考えて、全体最適な振る舞いを取りにくい。

・観点の偏りが起きやすい。

・縦割りの分断によって障害時の情報の有機的な連携が困難
それによって何度も同じようなトラブルがつづく、根本解消になりにくい

・変更や拡張性に乏しい

ドメインサービス別の切り分け方

チートポとかで言われている俗にいう【ストリームアイランドチーム】のこと。
単一の価値単位で切り分けられている。

メリット

・各種サービスごとに責務が切り分けられた切られ方なので、素早いデリバリーが実現しやすい
・認知負荷の量が軽減

デメリット

・時間経過に伴う他の優先されるべき品質の軸を見失いやすい
・他のサービスとの横断的な活動を意図的に行わないと、分断が起きやすい
・個々のサービスに集中してしまい、カオスな状況において全体目線で考えにくい

主張

一番最初にまずはわたしの主張を述べたいと思います。

境界の位置が安定した部分でないならサービスとして物理的に切り離しちゃダメ

シーンが変わってもほとんど境界位置の変更が起きないような安定した所しかマイクロサービス化しちゃダメです。
もちろんそれはプロセス面だけでなく、データのコンテキスト境界って意味も込みで。
でないとリスクが大きすぎます。

ましてやその時点で別の組織として切り離してしまうとかはもってのほかです。
組織を超えてのサイロ化を助長させてしまいます。

コラボレーション連携によって境界の継続的骨格の探索
→　境界がハッキリしてきたら徐々にXaaS型の連携

こうなれた時にマイクロサービスのような分散化を検討してもいいかもしれないですが、
そうでないのなら物理的イ分割してしまうのは危険すぎます。

対処法と基本マインド

抽象は具体よりの安定しているという思想を思い出してほしい。
同様にしてミクロレベルの境界の位置よりも、マクロなコンテキストマップの境界位置の方が変化の速度は遅い傾向にある。
しかしながら、だからといって詳細なミクロレベルの境界の位置変化に気づけていないと、
気付いた瞬間には「あれ汗　コンテキストマップレベルの境界の位置が変わってる💦　どうしよどうしよ」となってしまう。
それはまさに外部環境の変化に対して、自分たちの戦略を変えられていないということを表している。

ここのトピックでは、いくつかの対処法や根底マインドについて触れようと思う。

継続的モデリング

チーム内で継続的にモデリングをする。
また時にはチームの壁を越えてモデリングをした上で、
前提となる枠組みであるマクロなコンテキストマップを更新し続けること。
この演繹的なボトムアップの活動を継続的に行うことが重要である。

もしもビジネスサイドと開発者サイドに分断があると感じているなら、
ドメインエキスパートなり、ビジネスに詳しいビジネスアナリストやビジネスアーキテクトを必ず同席させることをオススメする。

ビジネスサイドが持つべきマインド

業務責任者や経営サイドは全体を俯瞰して視なくてはならない特性上、
１つ１つの構成システムの内部がどんな概念で構成されているか？まで神経を張り巡らせることは、正直言ってなかなか難しい。
これをまずは開発者の方々は理解していただきたく思う。
(ビジネスサイドにいるという理由で、味方をしている訳ではないです)

そしてビジネスサイドは、システム側よりも変化が遅い安定した部分を担当しているといえども、このVUCA時代においては素早い価値観の変化へ対応できるようにすること。

「それが決まりだから」「それがうちの強みだから」
みたいなバイアスと向き合うことなくして、システムだけイケているものにしようとしても
大した効果なんて得られない。

むしろこれからは環境負荷軽減への貢献が義務付けられていくと考えたら、
いかにシステムを作らずに、仕組みを創る、文化を再構築するスタンスが求められる。
すなわち、技術的負債を生み出している古き悪しき文化という文化的負債をぶち壊すマインドである。

それを支援するために、制約理論とイベントストーミングとを組み合わせたアイデアを色んなところで自分は語っている。
DDDモデリングの真骨頂だと思っているし、そのポリシー系を炙りだすためにモデリングという可視化手法を使っているとさえ思っている。
詳しくは以下の記事をご覧ください。

評価制度のメンテ

具体的に変えるべき候補としては、エンジニアの【評価制度】などである。
職能別という切り分け方での各種職能内でいくら貢献したか？
という評価をしていないだろうか？

せっかくエンジニアの方々とコラボしてモデリングを行い、
適切なコンテキストの境界の位置を定義してたとしても、
それに伴ってのチームの評価制度の更新をしなくては何にもならない。
わざわざ「皆さん、個別最適な振る舞いをしてください。職能横断的な視座なんて持たなくていいです。」と言っているようなものだと私は感じる。

これはドメイン別の切り分けでも起こり得ることである。
ドメインごとに分けたつもりでも、他のチームとの連携が全くないってことはない。
その境界内で考えたらめっちゃ貢献していても、全体で考えた際にはむしろマイナスのインパクトを与える振る舞いだって当然ある。

だから私は可能な限り、
境界内というスコープでの達成水準として

最低水準以外に、上限水準も定義

することをオススメしている。

上限を超えたものに関しては、費用対効果が下がり始めている。
つまり、既存の評価制度のままでは、

そのチームの生み出すアウトカム　＞＞　そのチームにかかるコスト　
となってしまいかねない。

具体的な評価のロジック内容はころころ変わるかもしれないが、
その上位概念である評価ポリシーは、定性的な表現でも構わないので、少なくとも自社内の従業員には透明性を持たせていつでも参照できるようにしておいた方がいい。