ビジネス課題と問題とドメイン駆動設計

企業において、何かシステムを開発する際、どういった目的で開発するかを考えたことはありますでしょうか。ただ単純に IT 化を命じられたからでしょうか。

多くの場合、ビジネス目標を達成するためであると考えています。それが SoR(System of Record)であろうが SoE(System of Engagement)であろうがです。

ビジネス目標、ビジネス課題、問題、それに関係するドメイン駆動設計の関係を順番に見ていきます。

ドメイン駆動設計自体の説明はこちらを参照ください。

マイクロサービスへの上手な分割手法

ドメイン駆動設計と Red Hat

ビジネス目標とビジネス課題と問題と解決策

ビジネス目標

ビジネス目標は分かりやすいです。

売上高 XXXX 億円、営業利益 XX 億円、営業利益率 XX ％と言ったようなものがこれにあたります。

ビジネス課題

ビジネス目標を達成するにあたって、実施するべきアクション、これがビジネス課題になります。

つまり、上記の売上高 XXXX 億円、営業利益 XX 億円、営業利益率 XX % を達成するには何をする必要があるのか企業は考えなければなりません。これがビジネス課題です。

大抵の場合は数値目標が掲げられています。これに向けて企業は動きます。CxO におけるビジネス課題は大抵ビジネス３賢者に結びつきます。

1. 売り上げ拡大
2. コスト削減
3. リスク低減

想像している課題とは少し違うかもしれません。お客様にとって何か困っていること、これが課題だと思っている人が多いかもしれません。

コンテナ導入における課題とは？

上記の文脈で課題を使っているケースがあります。この文脈では課題ではなく後述する問題がしっくりくると思います。ビジネスでは課題と問題をしっかり区別して使われることが多いと思います。

課題をすぐに Time To Market / Agility に紐づけている方がいますが、必ずしも Time To Market / Agility が課題になるわけではありません。

問題

問題は、ビジネス課題を達成するための阻害要因です。人・プロセス・技術の3種類に分類されます。

例えば、ビジネス目標として営業利益拡大が掲げられていたとします。

CIO と相対しているとします。CIO は営業利益を拡大させるために、OPEX を低減する必要を感じており、外部に発注している運用オペレーションや、自社の運用コストを抑える必要があると考えているかもしれません。

ビジネス課題 : IT 運用オペレーションのコスト削減（XXX億円からXXXX億円へ)

そして、これを阻害するのが、

問題 : サイロ化された組織、サイロごとに張り付いたベンダーがばらばら、サイロごとに採用された HW/MW が（ベンダーのせいで)ばらばら、サイロごとのばらばらな運用手順、サイロごとにばらばらな監視、サイロごとに違う HW/MW/監視ツールの学習コスト

だったとします。

問題は先にあげたように人・プロセス・技術に分類できます。

解決策

問題を解決するのがツールやシステムになります。上記の問題の例ではコンテナオーケストレーションツールが解決策になりえるかもしれません。

問題解決 : コンテナオーケストレーションを導入することにより、開発ライフサイクルをベンダーの垣根を越えて統一化、コンテナ納品、監視、APM をコンテナオーケストレーションネイティブに、一部の運用を自動化(自動復旧、オートスケール、LB自動配備、ミドルウェアの Day1/Day2 オペレーション自動化)

システムやツールを使用して問題を解決すると、課題解決の阻害要因がなくなるため、課題をスムーズに達成できるようになります。これがソリューションと呼ばれているものです。

ここまでが一般的な外資系企業におけるソリューションセリングの手法です。

ビジネス課題とドメインの関係

あまりに役職の低い人は目の前にそびえる問題しか目に見えていないかもしれませんが、役職が変わるとビジネス課題も変わります。

重要なのは役職だけではなく、ドメイン駆動設計におけるドメインによってもビジネス課題は変わるということです。

例えば、EC 企業を例にしてみます。

EC 部門における在庫部門のトップと仕入れ部門のトップでは同じビジネス課題になるでしょうか。在庫部門は在庫回転率向上がビジネス課題になり得ますが、仕入れ部門には在庫の回転率は全く関係ありません。上記で挙げた IT 運用オペレーションのコスト削減は IT 部門以外の部門では課題になり得ないものです。

ドメインごとにビジネス課題が違うのであれば、 問題も当然ドメインごとに違うはずです。

ビジネス目標・ビジネス課題・問題の関係

問題解決のための One Of Them — システム-

各社が開発するシステムはビジネス課題の遂行を妨げる、問題を解決するために取り入れるものです。

ドメイン駆動設計を使えば、ビジネス目標を達成するためのビジネス課題、そのビジネス課題を妨げる問題、問題を解決するソリューションが少なくともドメインのトップレベルで認識できます。

ビジネス課題とドメインの関係

実践ドメイン駆動設計では、問題空間、解決空間という名称を実際に使用しています。

ドメインは、問題空間と解決空間を持っている。問題空間は、解決すべきビジネス戦略上の課題を浮き彫りにするもので、もう一方の解決空間は、ソフトウェアをどのように実装してその課題を解決するかに注目するものだ。

• 問題空間(戦略的フェーズ)
• 解決空間(戦術的フェーズ)

どのフレームワークを使うだとか、どのデータソースを使うと言った話はエンジニアの興味のある領域であって、ドメインエキスパートにとっては興味がありません。重要なのは問題解決であるという趣旨の記載が実践ドメイン駆動設計の本ではされています。

問題が解決できればコンテナであろうが、EKS であろうがドメインエキスパートにとってはどうでも良いことです。

(おまけ)問題・ビジネス課題に合致しないソリューション

前職で、お客様から脱 Oracle/ 脱 Exadata というキーワードを持ってきて安直に私が持っているソリューションを持っていこうとしたケースがありました。私は脱 Oracle / 脱 Exadata の背景を聞いたのですが、想像で答えが返ってくるだけだったので、それだけでは自分が持っていたソリューションが最適とは言えないと考えました。

ビジネス課題「コスト削減」からくる脱 Oracle / 脱 Exadata とビジネス課題「 Time To Market 短縮」からくる 脱 Oracle / 脱 Exadata では課題を阻害する問題が異なるはずです。問題が異なればソリューションも異なります。前者のケースでは、現状の Oracle のライセンスを正しく把握したり、Oracle のサポートを1段下げるといった解決策が考えられます。私のソリューションはコスト削減由来の脱 Oracle / 脱 Exadata だった場合、見当違いにもほどがあるソリューションなのです。

ドメイン駆動設計を使わない

ドメイン駆動設計を利用せずにシステム開発する場合は、一体誰のなんの課題を達成するためのシステムなのだろうかを誰かに説いてみた方がよいと思います。

おそらく、色々なドメインがごちゃまぜ(例えば在庫部門や仕入れ部門)になっていると思います。ドメインがごちゃ混ぜになっているということは、さまざまな人のさまざまな課題達成を実現するために実装されているということです。あるドメインの課題を達成するのに、システムの都合で他のドメインの課題達成を諦めることになるかもしれません。

異なるドメインの問題を解決するために IT 部門や外部ベンダーの都合で一つのシステムとして提供してしまって良いのでしょうか。

昨今の複雑なシステムは複数のドメインが入り混じり、複雑に絡み合った問題を1つのシステムで解決しようとするあまり、生み出されているように感じています。そして結果的に別の問題をさまざまに生み出しているように思います。

特に業務内容的には証券会社よりも単純な銀行のシステムが巨大化している原因はここにあると思っています。

ファットモデルを生み、技術負債を抱え込み、容易に改修できないシステムを自ら進んで構築しているのではないでしょうか。そしてそれに対し No と言えるベンダーがいないのが現状ではないでしょうか。

(おまけ)ソリューション提供企業のインフラ部門が強い理由

問題に対するソリューションを提供するベンダーはいくらでもいます。しかし、総じてインフラ部門の方が強い傾向があるのではないでしょうか。

答えは簡単です。インフラ部門は大抵 IT 部門しか相手にしません。相対する IT 部門というコンテキストにおいて認識しているビジネス課題、ビジネス課題を妨げる問題が IT 部門単体で解決しやすいものが多いためです。

例えば売り上げ拡大に関する課題は IT 部門だけでは解決できません。ビジネス部門が密接に関与する必要があります。つまりアプリケーションが関係する箇所です。アプリケーションが関与すると途端に話が複雑になるのです。

最強の開発者

最強の開発者はドメインエキスパート自身が開発できるケースであると実践ドメイン駆動設計の書籍に記載されています。ドメインに関する知識を豊富に持っており、自信で問題を解決できる開発ができるとなると、課題解決へのスピードを加速度的に上げることができるでしょう。IT 部門と余計な翻訳をして余計な認識齟齬に心を病む必要もありません。

また、他のコンテキスト(ビジネス部門)との連携を非同期で実施していることを自分が一番よく知っています。

これが自社の IT 部門だったらまだしも、外部の IT ベンダーだったらどうでしょうか。きっとドメインエキスパートのビジネス課題やビジネス目標なんてこれっぽっちも理解していないはずです。そもそもドメインエキスパートと会話しているかさえ謎です。

加えて IT 部門やベンダーに丸投げすると他ドメインとのインテグレーションはバカの一つ覚えのように同期処理で実装されます。同期処理で実装するということは他ドメインでの処理が終了しないと自分の呼び出しが終了できず、他の作業ができないことを意味します。

他部門の処理が完了するまで口を開けて待っている状態なんてきっとドメインエキスパートはしていません。他の溜まった業務を処理しているはずです。

ローコード・ノーコード基盤

個人的には、コアドメイン以外における、他社との差別化が不要な部分にはローコード・ノーコード基盤を使って最強の開発者(市民開発者)によって実装してもらうのが近道なのではないかと考えています。よく問題として挙げられる開発者不足、ベンダーの人員不足を解決するソリューションとしても使えそうです。

お金を稼ぐコアドメインだけは、SaaS を使ってしまうと他者との差別化ができなくなってしまうため、極力独自実装するべきです。

ドメイン駆動設計まとめ

• ビジネス目標は全社で一緒
• ビジネス課題は役職によって異なる
• ビジネス課題、問題はドメインごとに異なる
• システムは問題を解決するための一つのツール
• 問題を解決するものがソリューション
• ドメイン駆動設計には現在の問題を表す問題空間とシステムで解決する解決空間の概念がある
• 昨今のエンタープライズシステムは複数のドメインごちゃ混ぜ
• 複数のドメインの問題を一つのシステムで解決するため、複雑なシステムができあがる

ドメイン駆動設計は現在でも非常に優秀なフレームワークであると考えます。