@sunaot です。『「継続性アーキテクト」という生き方』や『アーキテクトを目指すエンジニアの最短ルート』が興味を持ってもらえたので、この記事ではアーキテクトの仕事の重要な一部だと考えている「ビジネスの構造をアーキテクチャで表現する」ということについて書いてみます。
ビジネスの構造と書いてしまうと、業務のモデリングの話かなと思われるかもしれません。実際、設計手法について書かれている書籍では業務のモデリングの話が中心です。その時代の前提は、要求を持っている人としてのユーザーがいて、業務があって、そのシステム化をしていくというものでした。現在、サービス開発をしていくという中で直面している仕事はやや性質が変化していると感じています。正解となるサービスの姿というものはなく、やっているビジネスの状況やユーザーの関心も変化する中でサービス開発をし、サービス自身も変化をしていきます。サービス開発年代のモデリングでは、ビジネスの構造とサービスを利用するユーザーへのモデリングというのを意識していく必要があります。
まずは、ビジネスの構造をモデル化するとはどういうことかの説明から始めます。
ビジネスの構造をモデル化する*1
Martin Fowler のアナリシスパターンでは、モデリングの原則としてこのように書いています。
多くの企業において、このような基礎的な法則はほとんど理解されていないし、それを明らかにするにはかなりの努力を要する。このために概念モデルを作成する。概念モデル、すなわちメンタルモデルは、問題を理解可能にし、単純化する。
アナリシスパターン (Martin Fowler) 第一章導入より
これは重要な原則を示している。すなわち、正しいモデルや誤ったモデルというものは存在せず、目的の仕事にとってどの程度使いやすいかの違いだけである。
モデリングの原則モデルは正しいか誤っているかではなく、使いやすいか使いにくいかである。
アナリシスパターン (Martin Fowler) 第一章導入より
これにならって表現すると、「ビジネスの構造をモデル化する」とは、「ビジネスの成功へ使いやすい構造を見つけ出し、ソフトウェアアーキテクチャとして表現すること」です。
ビジネスについて、そのビジネスに関わるものを通して目的（ミッション）を達成するための構造を明らかにします。営利企業である場合は、多くの場合に儲けの構造も含まれます。ただ、それ以外も含めた成功の構造を表現することになります。
どんなアクターがいて、どういう行為を行って、それによる相互作用はどのようになって、そこへどんな意思を入れていき、目的の達成（ビジネスの成功）へたどり着くのか。そのストーリーを理解し、概念を見出し、名前をつけていくことです。また、業務というのはこの実現のための個々のプロセスのことになります。
たとえば、SNS のサービスを開発しているとします。そこには複数の「お知らせ」が届く inbox があり、その中には有償版へのアップグレードの訴求メッセージが届いていたり、つながりのあるユーザーからのメッセージの通知が届いていたりします。
また、サイドバーには「広告」を掲載するための領域があり、表示の都度違う広告が表示されたりします。広告の内容にはそのサービスのアドオン機能の利用を働きかけるようなものがあったり、広告主の顧客から出稿されている広告があったりします。
このときに「お知らせ」や「広告」を機能として実現し、その内容はそれぞれの機能へ入力されてきたテキストとして表現するか、それともなにかしらの概念をコンテンツの中身の分類に見いだしていくかというのを考えることが、ここで言っている「ビジネスの構造のモデル化」になります。
その SNS が Twitter のような相互のつながりとそのインタラクションが価値のキーになっているものであればユーザー間のインタラクションへの柔軟性と拡張性を担保できるような設計が適しているでしょうし、 LinkedIn のようなクライアント企業からの売上を収益モデルとしているようなものであれば一見同じような機能でもユーザー接点は貴重な広告枠にもなるためそれを考慮した設計が適しているでしょう。
これをアーキテクチャの中で別のサービスとして分離するのかレイヤーとして表現するのかクラスの中で概念を表現していくか、あるいはあえて抽象化をしないのかというのは場合によりますが、少なくともそれを判断できる程度に自分たちのビジネスがどういう性質と構造を持つものなのかを理解することが重要になります。
なぜビジネスをモデル化することが重要なのか？
自分たちのビジネスがどういう性質と構造を持つものなのかを理解することが重要と書きました。また、内容としても「モデリング対象を理解しそれを設計で表現する」ということであれば、業務のモデリングと変わることはなさそうに聞こえます。どうしてわざわざビジネスの構造のモデル化を取り上げて重要性を語る必要があるのでしょうか。
理由は、ビジネスは成功に向けて時間の経過の中で変化する必要があり、モデリングする対象自体が変化するからです。ビジネスは事実をどう解釈するかによって、ビジネスのモデル化された姿自体が変化し得るものです (そのビジネスをどういうものだと見るかという解釈が幾通りもありえます)。業務も時系列では要求が変化しますが、ある時点というスナップショットでは事実が観測できます。なにが行われているかという事実は観測することができるものの、それをどういうものだと見做すかという点で解釈の仕方に幅があるビジネスのモデル化というのは「現在の姿」でも不確かな部分があります。さらに、顧客となるユーザーとの関係性や他者との競争のポイントが変わってくる点も含めて「将来の姿」を考えようとすると、より大きな変化の動機になりうるので、それをモデル化し反映していくことが重要になると考えています。そして、業務や機能のレイヤーで考慮するよりもその前提となるものとして、自分たちのビジネスをどう解釈しているか、どう扱うか、アーキテクチャの中での位置づけを考えておくことが大切です。
ビジネスの意図をアーキテクチャで表現する
ビジネスをモデル化し続ける場合、ビジネスとソフトウェアアーキテクチャを写像のように一致させ続けることになります。ビジネスの変化に応じてソフトウェアが変わっていくために、変化のポイントを理解し、変更と拡張に対して設計をしていきます。
このためにはビジネスの意図というのが機能とは別のレイヤで存在し、それをソフトウェアアーキテクチャで表現する必要がある視点を持つこと、それからそれができるくらいに自分たちのサービスの性質と構造を深く知りにいくことが必要になります。
仮にそうしない場合にもビジネスの要求自体はなにかしらの形でサービスへやってきます。構造の理解が甘いままにそれを機能として実現し続けていくと、本来は隠れていた関心事があちこちのコンポーネントやモジュールに散らばり、その歪みが長期的に変更や拡張を妨げていくことになります。
ビジネスの意図を理解し、その構造をモデル化していくことを実践するときにもっとも重要なのは、ビジネスを深く知り、自身でもビジネスの不確実性を含めて予測をし、その上で設計判断をすることです。そして、ソフトウェアエンジニアの眼によって、現実世界のビジネスを分析・解釈していくことです。
ソフトウェアアーキテクチャとして表現する
焦点を置くべきはプログラムの品質、正しさ、僕たちがメンテナンスしたり変更を追加できる能力です。
ソフトウェア企業が長期にわたって価値を提供し続けるためには、ユーザーへの貢献・ビジネスの成長、そのストーリーとソフトウェアとの整合をとり続ける (写像) ということが非常に大事になってきます。
ここは「ユーザーへの貢献・ビジネスの成長、そのストーリー」にはっきりと意思があれば、踏み込めば踏み込むほど面白くて、その方針の不確実さと実現コストと後への影響を同時に評価し続けながら、具体化していくステップの踏み方を考え、一緒に議論し、それがビジネスとしてのストーリーにまた反映されていくことになります。そして、そこで得た理解と見通しから、またソフトウェアアーキテクチャを更新していきます。
これは、技術に精通していて具体化をしていくときの手段について、会話の中で評価可能なエンジニアだからこそできる仕事になります。
この記事を読んでいる人の中にも、ビジネスの方針が伝えられたときに「これは後々困ったことになるな」と感じたことがある人は多いでしょう。むしろ数え切れないほどあるのが通常かもしれません。ビジネスの方針を考えている人はソフトウェアへ無関心だから仕方のないことなのでしょうか？ 私はそうは考えません。たしかにソフトウェアの設計そのものへ関心がある人は少ないかもしれませんが、その結果、将来のビジネスの制約が増えてくると知ったら当然関心があるはずです。
このビジネスのストーリーをソフトウェアの設計へ織り込もうとすると、いくつかの選択肢があって、Aの選択肢をとったときには実現までの時間がかかる。Bの選択肢の場合は実現は手軽だが将来の選択肢や開発サイクルへの悪影響が考えられる。一方で、このストーリーははたしてどのくらいビジネスの中で重要なものなのか。今のテーマの中で順序をつけるとすると何番目のものなのか。インパクトと実現の確かさの見込みはどの程度のものなのか。そのときにA、Bの選択肢はインパクトや実現の確かさの見込みに対して筋の良いものなのか。他の選択肢はないのか。 こういったことを会話しながら今とるべき行動を決めていきます。
ソフトウェアの困難として目に見えないこと（不可視性）が言われますが、実はビジネスの構想も目に見えないものです。実現するまで検証ができないという点もよく似ています。共に不確実なものを扱っているので、それぞれに専門性を持つ人同士が今評価できるかぎりを評価し、いかに早く実際に試してみて市場からの結果で評価をするところまでたどり着くのかが大事なのだと思います。
ビジネスの意図、ソフトウェアアーキテクチャの中でのその表現の仕方、実現のしやすさと将来への影響、実行する場合の具体的なイメージ。これらを行ったり来たりしながら具体化するまでの道筋をつくっていく仕事がサービス開発年代のアーキテクトの仕事だと考えています。
終わりに
ここまで書いてきたことは、従来のアーキテクトの仕事の文脈から外れた新しい概念かというと、実はそんなことはありません。従来から優れたアーキテクトであれば実際の仕事の中で自身の仕事のスコープへ入れていたはずの話になります。
たとえば、増田亨さんのTweetでは
良い設計とは何か
— 増田 亨 (@masuda220) 2021年3月17日
価値は
事業貢献
発展性
事業に貢献する設計原則は
事業方針との整合性
事業との直接的な写像
事業ついての能動的注意
発展性を生み出す設計原則は
関心の分離
一箇所に書く
分かりやすく組み立てる
の中で、
- 事業に貢献する設計原則は
- 事業方針との整合性
- 事業との直接的な写像
- 事業ついての能動的注意
としてその仕事に言及されています。
また、事業会社で働くアーキテクトであれば、当事者として自身がビジネスの設計とソフトウェアアーキテクチャの設計を行き来している人がいることも知っています。
ただ、「わかっている人はやっている」ものの、あまり文書としてそれが説明されたものを見たことがなかったため、あらためてサービス開発の時代のモデリングの話として書いてみました。
ソフトウェア設計の能力を磨いた人がその優れた設計能力の先に発揮する価値の一つの選択肢として、ビジネスをモデル化することに興味を持ち、楽しんでもらえたらと思います。また、実際にエス・エス・エムでやっているビジネスはどういうもので、システムアーキテクチャとしての設計判断というのはどういう風にしているのかという話に興味のある方はぜひ話を聞きに来てください。
*1:ビジネスモデルという呼び方があり、言いたいことは大筋違っていないのですが、ビジネスモデルも含めたビジネス全体の構造のモデル化を指したいのであえてその呼び方を使っていません
