意思決定のプロセスを定式化する「ディシジョン・ドリブン・アーキテクチャ」の4ステップ

一方で、品質の高いコードをAIに作成させるには、AIが自ら決めきれない論点のつぶし込みを事前に実施し、情報を言語化し、コンテキストとして渡す必要が出てきた。結果、人間が今まで暗黙の了解で実行していたものも含めて「トレードオフを分析し意思決定すること」がこれまで以上に求められるようになった。

この意思決定においては大なり小なり、必要な観点を漏れなく挙げるだけではなく、複雑かつさまざまな背景情報を基に優先度をつけ、必要不可欠な情報を記録するという、現状のAIにさせるには骨の折れる活動が含まれる。

これらの活動がどういうものか目線を合わせる上で、冒頭で挙げた「アプリケーションのアーキテクチャをモノリスにすべきか」「マイクロサービスにすべきか」という問いに戻ってみよう。

確かに適切に設計されたマイクロサービスアーキテクチャであれば、一部の機能を独立してデプロイ（配置・公開）することが可能になり、改修時の影響を最小化できる。

一方で、常にマイクロサービスアーキテクチャを導入すべきとは一概には言えない。例えば、以下のような事情があるプロジェクトでは、マイクロサービスではなくモノリスが選択される可能性もある。

機能間の業務的な結合度が高くデータモデルを共有しており、アプリケーション上分割しにくい

内部通信間のレイテンシ（遅延）も許容できないほど厳しい性能要件がある

将来的な保守性よりも、多少コードが汚くてもすぐに機能開発をしてデプロイをしたい

上記のようなケースでも、データモデルが強く結合している状態はシステムとして好ましい状態ではないので、フェーズによっては腰を据えてマイクロサービスに移行する選択もとり得る。

このように、複数のアーキテクチャや要素技術から意思決定をする上では、比較、評価するための観点はもちろん、プロジェクトのフェーズなどを基にどの観点を優先するかといった背景が非常に重要であることが分かる。

この意思決定のベースになる背景は時々刻々と変化する。ファーストリリースは開発効率を意識してモノリスを選択したとしても、今後予定される大規模な機能拡張でシステム全体に影響が及ぶのは耐えられないので、一定の範囲をマイクロサービスとして切り出すといった方針転換もあり得るだろう。

もともとモノリスを選択していたこと自体は間違いではない。意思決定の背景が変化し優先度が変わったがゆえに、マイクロサービスがより適した選択に変わったのだ。

一方で、このレベルの方針転換は簡単にできるものではない。この時に、背景情報まで含めて意思決定の経緯を記録していたかどうかが生きてくる。

過去にモノリスにしたときにはどのような観点があったのか。マイクロサービスの何が課題だったのか。今の背景に照らしたときにそれらは解消できるのか。以前の経緯が分からないとまたゼロから再検討することになり、途方に暮れるだろう。

ディシジョン・ドリブン・アーキテクチャの4つのステップ

上記の意思決定を基にした活動を推進するとき、各ステップを定式化していくことや組織的なガバナンス構築も含めた、広い意味でのアーキテクチャが必要になる。

本連載ではそれを「ディシジョン・ドリブン・アーキテクチャ」として、現場で実行可能な内容まで腹落ちできるよう、一つ一つ深掘りしたい。

初回の今回は、モノリスとマイクロサービスの例を基にたどった意思決定のプロセスを、4つのステップに定式化するところから始める。

Step1．要件を定量的に定義する

意思決定の際にプロジェクトが求めていることを整理、数値化する。例えば、クライアントやその先のシステムユーザーと会話すると、以下のような声が聞こえてくる。

堅牢で高可用であることは絶対。どんなことがあっても止まらないシステムにしたい

システムの性能は大事にしたい。Webサイトはサクサク動くようにしたい

ユーザーの要望はすぐ取り込んでいきたい

運用はあまり手間をかけたくない

いずれもプロジェクトやユーザー、顧客が抱えている課題であり、システムにおける非機能要件とも捉えられる。これらの内容は主観的であり、システム仕様に起こすのは困難だ。

これらを具体的に定量化することで、比較検討できるようにする。

「どんなことがあっても止まらない」は実際には難しい。1日10分ぐらいなら許容範囲にする

サクサク動くことは重要だが、1秒ぐらいで画面が描画されれば問題ないのでは

おおよそ1カ月に1回ぐらいリリースできればよい

Step2．意思決定に必要な評価軸を決める

挙げられた要件は、あらゆる場面で常に重要とは限らない。意思決定をする際の背景に応じて、どれを重視するかが決まってくる。

例えば、アプリケーション処理で利用するデータストレージを決定する時のことを考えてみよう。金融系システムで資金移動を伴う処理であれば可用性やデータ整合性が求められるし、オンラインゲームであればレスポンスタイムが最も重要になるだろう。

挙げた要件も全てを同列に評価するのではなく、重み付けをする必要がある。同じプロジェクトでも、「どのサブシステムの話か」「どういった業務・処理なのか」「プロジェクトはどのようなフェーズなのか」といった背景次第でどの要件を大事にするかが変わる。

Step3．アーキテクチャ案を比較し意思決定を行う

優先度付けした要件を基に検討案を幾つか策定し、意思決定をする。さまざまな要件を満たし実現可能な候補を漏れなく整理することはエンジニアの腕の見せ所の一つだ。

例えば、データベースの選定であれば、RDBだけではなく、Document DB、キャッシュ系DB、ストレージサービスなども選択肢に挙がりうる。製品軸は分かりやすいが、何らかの軸に基づいて候補を漏れなく挙げ、これらのどれが今回相手にしている要件を解決するのか丁寧に選別する。

こうして残った案を、Step1で優先度付けした観点を基に比較して評価し、その時々のベストの案を決めていく。

Step4．意思決定の結果を記録する

最終的な判断結果とそこに至るまでの経緯を記録として残す。いわゆるADR（Architecture Decision Record）だが、ここで残した内容は後続で別の課題が発生したときに適宜見直し、適切な意思決定が導かれるようにする。

「なぜ判断プロセスが必要か」を示し、4ステップの全体像を簡単な例とともに手触りをつかんでもらった。しかし読者の中にはこう思った方もいるだろう。

「評価軸や重みは、どう決めればいいのか？」

4ステップの骨格は分かった。だがステップを実際に回そうとすると手が止まる。軸をどこから引き出すか。重みをどうチームで合意するか。「本当にこの結論で大丈夫か」をどう検証するか。

次回はこの「手が止まるポイント」に対して、明日のレビュー会議でそのまま使えるテンプレートと、チームの認知的な落とし穴を回避するための仕掛けを提供する。読み終えた時点で、読者は自分のプロジェクトで実際に評価表を1枚作り、判断の妥当性を検証できる状態になることを目指す。