生成AIによってシステムの設計案を作ることは容易になったが、何を優先し何を諦めるかを決める責任は人間に残されている。アーキテクチャに正解はなく、重要なのは「なぜその選択をしたか」を説明できることだ。本連載ではケーススタディーを通じ、トレードオフの可視化や意思決定の考え方を掘り下げ、良い設計だけでなく、良い意思決定を目指す。
「なぜモノリスではなくマイクロサービスにしたのか？」
設計レビューや障害分析の場で、こう問われたときに明確な説明ができるだろうか。「前のプロジェクトでも採用していたから」「業界でよく使われているから」「将来的な拡張性を考えて」――もちろん、それらは判断材料の一つだ。しかし、本当にそれだけで重要な設計判断を説明しきれるだろうか。
ソフトウェア開発の現場には優れた設計思想が数多く存在する。しかし、プロジェクトにおいては納期やリソースなどさまざまな制約が存在し、必ずしもすべてを採用した100点満点のアーキテクチャを維持できるとは限らない。
設計・開発・テストと進む中で、目の前の効率を優先して下した決断の結果、後続のテスト工程で障害が多数発生し、そのつけを払うことになるという苦い経験は、多くの方がお持ちではないだろうか。正しいタイミングで正しい技術選択をするにはどうすればよいのか。
AI時代に残る、エンジニアに求められる役割
昨今、生成AIは目を見張る進化を続けており、私たちの設計・開発プロセスは激変した。「仕様駆動開発」や「ループエンジニアリング」など、新たな開発プロセスが日進月歩で生まれている。コード生成や単体テスト作成、リファクタリング、ドキュメント作成といった私たちエンジニアが何時間も費やしていた作業の多くはもはや、ものの数分で実行できるようになった。
一方で、品質の高いコードを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枚作り、判断の妥当性を検証できる状態になることを目指す。
