結論から言うと、少なくとも現時点では、インフラをアジャイルで構築することは現実的ではない。この点を間違え、泥沼にはまっているチームもある。インフラを決めずにアジャイル開発に入ると、大きな手戻りや無理のある実装として歪みが現れる。

　この問題が表面化したのは、割と最近のことだ。少し前まで、Webシステムの利用技術は決まり切っていた。IAサーバー上のJava＋Spring＋Oracle Database、あるいは.NET＋SQL ServerやLAMP環境が“鉄板構成”だった。インフラ面の不都合が後から判明するとしても、サーバーのサイジングがうまくできていないという程度だった。

　しかし、今はインフラ技術が格段に進化して多様化した。データベースはRDBだけでなく、NoSQL DBも使う。検索やバッチ処理に分散処理技術を使うことも珍しくない。これらを動かす環境はオンプレミスの物理サーバーだけなく、パブリッククラウドやコンテナー技術を使ったりもする。目的に特化した専用技術を利用する時代になってきたのだ。

　その結果、アジャイルかどうかに関係なく、インフラを含めて「システムがどう動くか」を検討するアーキテクチャー設計の重要性がとても大きくなっている。例えば、商品数もアクセス数も多いECシステムを作りたいとする。昔ながらの鉄板構成でRDBを採用すると、だいたいの場合で読み出し時間に問題が発生するだろう。現実的には、そこからメモリー増設やリードレプリカの設置などの施策を追加していくことになる。だが、そもそも読み取り専用のデータをRDBに持つ必要があったのか。検討をそこに戻すには、残念ながら開発が進みすぎていることがほとんどだ。

　「パブリッククラウドなら後からでも変えられるのではないか」と思うかもしれないが、根本的なアプローチの転換は困難を極める。現実的に変えられるのは、仮想マシンの台数、CPUといった処理能力程度。DockerやOpneStackといったインフラのアジリティを高める技術も出てきてはいるが、基本的に短い反復で開発できるのは、アプリケーションだけと考えるべきだ。インフラはアプリケーション開発が始まる前に、方針を決めておく必要がある。

　こうした、想定する利用環境でのシステムの基本的な構造や動作について、最適なインフラ技術やミドルウエアを決定するのがアーキテクチャー設計だ。状況によるが、筆者は開発着手前に1カ月の期間（パブリッククラウドを採用する場合）を設定して、プロダクトバックログ（要求）の整理と同時にアーキテクチャー設計を必ず実施する。

　アーキテクチャー設計のプロセスは仮説検証型で進める。想定する動作シナリオを作り、それを実現可能なシステム構成をモデル化して机上で検証する。懸念がある箇所はPoC（Proof Of Concept）で実際に動かして検証する。PoCで確認したシナリオを積み重ねていくことで、堅牢かつ柔軟なアーキテクチャーが組み上がっていく。

　アーキテクチャー設計で作成した設計図はそのままアプリケーション開発のガイドラインになる。これがないと、インフラに不確実性が残ったまま開発を進めることになる。アジャイルは不確実性に対処する開発プロセスだが、あらゆる不確実性を飲み込めるわけではない。インフラはあらかじめ除去すべき不確実性の代表格なのだ。