アジャイル アーキテクチャーの３つのポイント

アジャイルアーキテクチャ、特にエンタプライズレベルのアーキテクチャーについて、３つのポイントがあります。

アーキテクチャーを最初から絞り込まない
柔軟なアーキテクチャーを維持する
コーポレートとローカルで継続的に会話する

順番に見ていきましょう。

１．アーキテクチャーを最初から絞り込まない

アジャイルはインクリメンタル開発なので、コード量は増えていきます。そして、コードの内容も変わっていきます。アジャイルは学習を前提とした進め方ですから、プロダクト制作に関わる人達の洞察が増えるに従って、コードは進化していきます。新たな顧客ニーズを発見したり、よりよい制作方法を思いついたりする訳です。そうすると、当初考えたアーキテクチャーがよくないこともあります。従って、顧客やプロダクトの理解が浅い初期段階で、アーキテクチャーを決めきることは大きなリスクを伴います。

２．柔軟なアーキテクチャーを維持する

アーキテクチャーのオプションを複数持ちながら、コードを進化させていく訳ですが、残すアーキテクチャーについて柔軟性を持たせることも大切なポイントです。モノリシックなアーキテクチャーではインクリメンタルな開発が難しくなりますから、「使う分だけ借りる」クラウド化やマイクロサービス化を支援するアーキテクチャーが必要となります。オンプレミスでは設置に時間がかかりすぎるため、スピードゲームの現代では足枷になってしまいます。現代は、プライベートクラウドでなくとも、セキュリティのしっかりしたパブリッククラウドがいくつもあります。ビジネスのアジリティにデリバリーを載せるためには「つくる分だけ使う」、「使う分だけ借りる」という柔軟なアーキテクチャーが必要不可欠です。

３．コーポレートとローカルで継続的に会話する

「アジャイル宣言の背後にある原則」に以下の２つの原理原則があります。

技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます

最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます

書かれているとおり、優れたアーキテクチャーの構築には、自己組織化されたチームによる、日常的に設計を見直す主体性が不可欠です。

しかしながら、数十～数百のプロダクトやチームを抱える巨大企業において、個々のチームでエンタプライズレベルのアーキテクチャーを考慮し判断していくのは困難な部分もあります。そこで、コーポレート標準をもつエンタプライズアーキテクトとローカルの各チームで継続的に会話し、組織全体として好ましいアーキテクチャーを共同構築・維持していくことが必要です。具体的には以下のアプローチをお薦めしています。

プロジェクト初期だけでなく、プロジェクトライフサイクルを通して、コーポレートのアーキテクチャーが継続的にプロジェクトに関与し続ける
ディスカバリーフェーズで、コーポレート・ローカル相互でアーキテクチャーの方向性について話しあうと共に、実行フェーズにおいてもスプリントやリリース毎にアーキテクチャーを評価していく
アーキテクチャーのコミュニティを開催して、組織全体でアーキテクチャーについて話し洞察を深める場を設ける
アーキテクチャーの依存関係のあるプロダクト全体で、スプリントやリリースのケイデンスを同期し、合同プランニングや合同ショーケースを実施する。その際のアジェンダにアーキテクチャも盛り込む

アジャイルでは、「創発的設計」の名の基、あまり思考せずに作り始めてしまったり、作りながら考えるというカルチャーもあります。しかし、プロジェクト・プロダクト開始時に前もってアーキテクチャーの方針を話し合うことはとても大切です。企業レベルのアーキテクチャーの方針を基に、検査と適応を繰り返し、よりよいアーキテクチャーを作っていくことになります。