なぜ「判断軸」のないアーキテクチャは破綻するのか？ AI開発時代に残された人間の役割：ディシジョン・ドリブン・アーキテクチャ AI時代の「決める」技術

生成AIの進化でコードや設計案の作成が容易になった一方、トレードオフを分析し意思決定をする責任は人間に残されています。本記事では、設計の破綻を防ぐ「判断軸」の重要性と、意思決定を定式化する4つのステップを解説します。

[前出祐吾, 渡邊泰宏，アクセンチュア]

この連載について

生成AIによってシステムの設計案を作ることは容易になったが、何を優先し何を諦めるかを決める責任は人間に残されている。アーキテクチャに正解はなく、重要なのは「なぜその選択をしたか」を説明できることだ。本連載ではケーススタディーを通じ、トレードオフの可視化や意思決定の考え方を掘り下げ、良い設計を目指すだけでなく、良い意思決定を目指す。

　「なぜモノリスではなくマイクロサービスにしたのか？」

　設計レビューや障害分析の場で、こう問われたときに明確な説明ができるだろうか。

　「前のプロジェクトでも採用していたから」「業界でよく使われているから」「将来的な拡張性を考えて」

　もちろん、それらは判断材料の一つだ。しかし、本当にそれだけで重要な設計判断を説明しきれるだろうか。

　ソフトウェア開発の現場には優れた設計思想が数多く存在する。しかし、プロジェクトにおいては納期やリソースなどさまざまな制約が存在し、必ずしも全てを採用した100点満点のアーキテクチャを維持できるとは限らない。

　設計・開発・テストと進む中で、目先の効率を優先して下した決断の結果、後続のテスト工程で障害が多数発生し、そのつけを払うことになるという苦い経験は、多くの方がお持ちではないだろうか。正しいタイミングで正しい技術選択をするにはどうすればよいのか。

AI時代に残る、エンジニアに求められる役割

　昨今、生成AIは目を見張る進化を続けており、私たちの設計・開発プロセスは激変した。「仕様駆動開発」や「ループエンジニアリング」など、新たな開発プロセスが日進月歩で生まれている。コード生成や単体テスト作成、リファクタリング、ドキュメント作成といった私たちエンジニアが何時間も費やしていた作業の多くはもはや、ものの数分で実行できるようになった。

図1　AI時代におけるエンジニアの役割分担（作成：アクセンチュア）

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

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

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

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

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

• 機能間の業務的な結合度が高くデータモデルを共有しており、アプリケーション上分割しにくい
• 内部通信間のレイテンシ（遅延）も許容できないほど厳しい性能要件がある
• 将来的な保守性よりも、多少コードが汚くてもすぐに機能開発をしてデプロイをしたい

図2　モノリス vs マイクロサービスの評価観点比較 ― どちらが優れているかではなく、背景によって最良解が変わる（作成：アクセンチュア）

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

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

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

図3　背景変化による判断のシフト。判断の正しさはその時点の背景に依存する（作成：アクセンチュア）

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

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

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

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

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

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

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

図4　ディシジョン・ドリブン・アーキテクチャ 4つのステップ（作成：アクセンチュア）

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

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

• 堅牢で高可用であることは絶対。どんなことがあっても止まらないシステムにしたい
• システムの性能は大事にしたい。Webサイトはサクサク動くようにしたい
• ユーザーの要望はすぐ取り込んでいきたい
• 運用はあまり手間をかけたくない

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

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

• 「どんなことがあっても止まらない」は実際には難しい。1日10分ぐらいなら許容範囲にする
• サクサク動くことは重要だが、1秒ぐらいで画面が描画されれば問題ないのでは
• おおよそ1カ月に1回ぐらいリリースできればよい

図5　定性的な声を定量的な指標に変換する ― 比較検討を可能にする第一歩（作成：アクセンチュア）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

著者プロフィール：前出 祐吾（まえで ゆうご）

アクセンチュア デジタルコア シニア・マネジャー。SIerでアプリケーション基盤の構築・プロジェクト展開などの経験を経て2023年アクセンチュア入社。金融系システムを軸としたアーキテクトとしてプロジェクトに参画する傍ら、昨今は生成AIを使ったソリューション開発などにも携わっている。

著者プロフィール：渡邊 泰宏（わたなべ やすひろ）

アクセンチュアデジタルコア シニア・マネジャー。早稲田大学大学院 基幹理工学研究科 修士課程卒業後、2019年アクセンチュア入社。金融系・公共系を中心にアプリケーション領域を軸としたアーキテクトとして、基幹系システム刷新の構想企画から運用保守までデリバリーにおける全フェーズに従事。