アジャイルアーキテクチャー

設計やシステム開発における創発は事実として認識しなければならないが、少し計画を立てることで多くの無駄が省けることがある。

─James O. Coplien, Lean Architecture

アジャイルアーキテクチャーの概要

アジャイルアーキテクチャーとは、システムの設計やアーキテクチャーを、新しいビジネス機能の実装と同時に、積極的に進化させるための、価値やプラクティスである。このアプローチでは、システム(大規模なものも含む)のアーキテクチャーが、現在のユーザーニーズを同時にサポートしながらも、だんだんと進化していく。これによって、事前の大量の設計(Big Upfront Design:BUFD)や、ステージゲート手法の開始/停止を避けることができる。システムを常に実行できるため、継続的な価値のフローをサポートできる。

アジャイルアーキテクチャーでは、創発的設計と意図的アーキテクチャーという両端の間でバランスを取ることで、インクリメンタルな価値納品が可能になる。創発的設計は、完全に進化型のインクリメンタルな実装アプローチの技術基盤であり、目の前のユーザーニーズに設計を対応させるのに役立つ。システムの構築と配置を行う間に、設計は創発的に生じる。しかしそれと同時に、組織は新しいビジネスの課題に対応するため、大規模なアーキテクチャーの取り組みを実施しなければならない。それにはいくらかの意図性と計画が必要である。意図的アーキテクチャーは、アジャイルなプログラムやチームにとって、技術構成全体に関する指針や技術ガバナンスになる。その結果、アプローチに共通性が生まれ、重複が排除され、システム全体の堅牢性が向上する。この2つが一緒になって、チームがビジネス価値をより早くより確実に納品するために必要なアーキテクチャー滑走路が作成される。

協調や、創発的設計、意図的アーキテクチャー、設計のシンプルさ、テスト容易化設計、プロトタイプ作成、ドメインモデリング、イノベーションの分散などのすべてが、リーン-アジャイル開発のこの重要な基礎を支えていて、それがSAFeのアジャイルアーキテクチャーの原則に現れている。それについてこのページで説明する。

詳細

アジャイルアーキテクチャーというリーン-アジャイルなアプローチでは、創発的設計と意図性のバランスを取ることで、エンタープライズソリューションの構築という複雑な作業に対処する。従来型の開発につきものの、事前の大量の設計や、開始と停止の繰り返し、大きなブランチとマージといった問題を回避する。現在のユーザーのニーズをサポートしながら、同時に近い将来のニーズを満たせるようシステムを進化させるというアプローチである。創発的設計と意図性を同時に取り入れることで、アーキテクチャー滑走路が継続的に構築、拡張され、それが今後ビジネス価値を開発するための技術基盤となる。

アジャイルアーキテクチャーはSAFeのすべてのレベルに関係する。以下に挙げるアジャイルアーキテクチャーの原則は、SAFeのアプローチの基本原則となる。

  1. 設計は創発的に現れる。アーキテクチャーは協調作業である。
  2. システムが大きいと滑走路は長くなる。
  3. 正しく動作し得る中で最もシンプルなアーキテクチャーを構築する。
  4. 疑わしいときはコードを書くかモデルを作成して確認する。
  5. 構築したらテストする。
  6. イノベーションに独占はない。
  7. アーキテクチャーフローを実装する。

原則1─設計は創発的に現れる。アーキテクチャーは協調作業である。

従来のステージゲート開発方法論では、たいてい、事前の大量の設計(BUFD)を行って、将来的なシステムのニーズに完全に対処できるはずのロードマップとアーキテクチャーインフラを作成する。この先何年もシステムをサポートできるだけの要求とアーキテクチャー計画を、一度の作業で作成できるというのがその信念である。

しかし、この方法には多くの課題がある。1つは実装の開始が遅れることである。2つ目は、計画上のアーキテクチャー、つまり、推論に基づいて将来を考慮した構成要素の大きな集合が、現実の世界に触れたときに発生する。そして、設計はすぐに脆くて変更困難なものになり、いずれは、大きなブランチとマージによって推論に基づく新しい想定事項を作り上げることが日常的な行動となる。SAFeでは、創発的設計と意図的アーキテクチャーを組み合わせ、協調によって推進することで、この問題に対処する。

創発的設計

アジャイル宣言[2]の11番目の原則「最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます」は、創発的設計の概念の重要な原動力である。これには次の意味が含まれる。

  • 設計は、もっとも近くにいる人によってインクリメンタルに育てられる。
  • 設計は、ビジネス機能と共に進化する。リファクタリングテストファースト継続的インテグレーションによって、絶えずテストされ、実現される。
  • チームは、現在判明している要求に従って、設計を素早く進化させる。機能の次のインクリメントを実装し検証するのに必要なだけ、設計が拡張される。

創発的設計というこの新しいプラクティスは、チームレベルで効果を上げる。しかし、大規模システムを開発するには、創発的設計だけでは不十分である。

  • 予想できたはずの事柄に対応するための再設計が過剰に行われる可能性がある。その結果、経済性が悪化し、市場投入までの時間が長くなる。
  • チームがいつも互いに同期できるとは限らず、推測が無秩序に行われ、アーキテクチャーが発散していく。
  • 近付きつつある大きなビジネスニーズにチームが気付きさえしないことがある。チームの視界にない要因から今後のアーキテクチャーのニーズが生まれる。
  • 共通のアーキテクチャーの土台があると、複数のシステムからなる大規模システムの使いやすさ、拡張性、パフォーマンス、保守性が向上する。
  • 新しい横断的なユーザーパターンが今後の目的適合性に影響する。
  • 合併や買収により、統合が進み、インフラの共通化が必要になる。

意図的アーキテクチャー

そのような理由から、創発的設計だけでは複雑な大規模システム開発に対応できないときがやってくる。単純に言って、チームが自分たちの環境の外で起きる変化を予測するのは不可能だし、個々のチームがシステム全体を完全に理解して、重複や矛盾の含まれるコードや設計を作成しないようにすることも不可能である。そのために、意図的アーキテクチャーが必要になる。これは、ソリューションの設計やパフォーマンスや使いやすさを向上し、チームをまたがって設計や実装を同期する際の指針となる、目的をもって計画されたアーキテクチャーの取り組みである。

アーキテクチャーは協調作業である

もちろん、創発的設計を素早くローカルで制御することと、意図的アーキテクチャーをグローバルな視点で見ることが両立するのが最善である。両方を組み合わせることで、システム全体が概念的に整合が取れていて有効であることを保証するために必要な指針が得られる。図1に示すように、創発的設計と意図的アーキテクチャーの適切なバランスを取ることで、システムが効果的に進化する。

図1.  意図的アーキテクチャー、創発的設計、協調作業がシステムの進化を支える

 

図1を見ると、これらが独立した要素ではないことが分かる。意図的アーキテクチャーは創発的設計の制約となるが、それは非常に抽象度が高いレベルなので、チームはその「意図的」な部分を自分たちのコンテキストにうまく適合させることができる。それと同時に、創発的設計は、意図的アーキテクチャーに影響を与え、誤りを修正する。また、今後の中央集権的な意図的作業に新しいアイデアを送り込む。

創発的設計と意図的アーキテクチャーの間でこのような深い相互関係が生じるのは、アジャイルチームシステムおよびソリューションアーキテクチャーエンタープライズアーキテクトプロダクトおよびソリューション管理の間で協調作業が行われている場合だけである。アジャイルリリース列車によって、このような協調作業を促進する「チームのチーム」環境が作成される。

原則2─システムが大きいと滑走路は長くなる。

アーキテクチャー滑走路が存在するといえるのは、企業のプラットフォームに十分な技術インフラが存在し、遅延につながる大きな再設計なしに、バックログ内の最も優先順位の高いフィーチャーやシステム能力の実装をサポートできる場合である。ある程度の滑走路を実現するには、企業は、既存プラットフォームの拡張作業と、進化するビジネス要求に必要な新しいプラットフォームの構築および配置作業に、継続的に投資しなければならない。

リーン-アジャイルな企業でアーキテクチャーの取り組みの実装が複雑化するのは、「事前にビッグバンを起こしてブランチとマージ」というウォーターフォールのアプローチを捨て去っているからである。その代わりに、企業は、アーキテクチャーの取り組みをメインコードベース内でインクリメンタルに実装することに全力を注ぐ。そのためには、アーキテクチャーの取り組みをイネイブラーフィーチャーに分割しなければならない。このイネイブラーフィーチャーによって、新しいビジネスフィーチャーを実現するために必要な滑走路を構築する(図2)。

図2.  今後の機能をサポートできるようアーキテクチャー滑走路は絶え間なく進化する

各イネイブラーフィーチャーは、システムが常に(少なくともPIの境界では)動作するよう、1つのプログラムインクリメント内で完成しなければならない。そのため、場合によっては新しいアーキテクチャーの取り組みを断片的に実装することになり、実装を行ったPIではユーザーに公開されないこともある。こうすると、出荷が可能な状態を保ちつつ、アーキテクチャー滑走路を舞台裏で実装してテストし、次のPIなどで十分なフィーチャーやシステム能力ができあがってからユーザーに公開することができる。

滑走路の概念は、大規模開発において、意図的アーキテクチャーと創発的設計が効果的に補い合う様子を示している。つまり、将来の機能をサポートする高いレベルの意図的なアイデアは、アジャイルチームによって適合させられ具体化される。また、最適な創発的設計を作り出せるよう、アジャイルチームに権限が委譲される。

原則3─正しく動作し得る中で最もシンプルなアーキテクチャーを構築する。

要求の変更はたとえ開発の後期であっても歓迎する(アジャイル宣言[2])。それはもちろんそうだが、システムの設計が理解しやすければ、変更もしやすくなる。ケント・ベックが言うように、「シンプルがよいのであれば、システムはいつも、現在の機能をサポートできる最もシンプルな設計にしておこう」[3]。実際、大規模システムでは、設計のシンプルさは贅沢品ではなく、生き残りのためのメカニズムである。生き残るためには多くのことを考慮しなければならない。以下に挙げるのはその一部である。

  • シンプルな共通言語を使ってシステムを記述する
  • ソリューションモデルをできるだけ問題領域に近いものにする
  • 絶えずリファクタリングする
  • オブジェクトやコンポーネントのインターフェースが明確に意図を表現するようにする
  • 昔からの優れた設計原則に従う[4、5]

ドメイン駆動設計[6]、デザインパターンの利用[4]、メタファーの適用[3]といったシステム設計のアプローチを採用すると、設計やチーム間のコミュニケーションがシンプルになる。設計をシンプルにすることの「ソーシャル」の側面は重要である。それによって、コードの共同所有が可能になり、結果としてコンポーネントではなくフィーチャーを重視する姿勢が育成されるからである[7]。保守と拡張の容易なソリューションへと進化させるときに大切なのは、協調するエンティティの集合としてシステムをとらえることである。こうすることで、データベース層でロジックに集中しすぎる、機能を満載したUIを作成する、大きくて管理しきれないクラスを作るなどの、典型的な設計の欠陥を防ぐことができる。シンプルにするには設計のスキルと知識が必要である。そのベストプラクティスを作成して普及させるには、専門技能コミュニティーが役に立つ。

原則4─疑わしいときはコードを書くかモデルを作成して確認する。

よい設計判断について合意に至るのは難しいことがある。どの行動方針が最善かの意見はさまざまで、それも当然である。正しい答えがないことも多い。また、アジャイルチームやプログラムはリファクタリングを苦にしないが、必要のないリファクタリングはもちろんしたくないと思っている。

判断するために、アジャイルチームは通常、コードを書いて確かめる。それには技術や機能のスパイクを利用するか、ときにはラピッドプロトタイピングを行うこともある。短い反復で小さいスパイクを実施し、客観的な証拠による素早いフィードバックを得る。それをさらに、チームや設計者やアーキテクト、さらにはユーザーによる、A/Bテストの対象にすることもある。

設計変更の範囲が広くてコーディングやスパイクやプロトタイプ作成では不十分な場合には、問題についてモデルを作成し、実装前に影響の見込みを理解しておくと有益である。図3に示すドメインモデリング(指針のページで取り上げる)やユースケースモデリングは、特に有用な軽量アジャイルモデリング概念である。

ソリューションの意図にモデルを記録する

もちろん、誰も見つけることができないモデルは役に立たない。そのため、モデルや、技術的知識、さらにはさまざまな設計判断を、ソリューションの意図に記録する。これがコミュニケーションの中心点となる。しかし現実には、技術情報は、ドキュメントから、スプレッドシート、上記のモデルまで、さまざまな形式で表現される。ドキュメントやスプレッドシートは、記述する側にとっては作成しやすいが、リーンなシステムエンジニアリングに必要な知識移転や継続的協調に必ずしもつながるわけではない。

それより役立つアプローチがモデルベースシステムエンジニアリング(MBSE)である(これについては独立したページで取り上げている)。

MBSEでは、ソリューションの意図にさまざまな種類のモデルを記録する。また、情報を整理してリンクするオプションも数多く存在する。一般に、モデル情報や組織の記述から品質の確保までの作業は、システムおよびソリューションアーキテクト/エンジニアが責任を負う。アジャイルチームは、それぞれの持つ知識や情報をモデルに追加する。

原則5─構築したらテストする。

設計が実際にうまく動くかどうかを見分ける責任は、共同でアーキテクチャーの作業を行っている人たちが負う。システムアーキテクチャーのテストには、規模が大きくなったときに機能/非機能の運用、性能、信頼性に関する要求をシステムが満たせるかのテストが含まれる。それを行うには、継続的にシステムレベルのテストを行えるよう、可能な限り自動化されたテストインフラも構築しなければならない。また、アーキテクチャーが進化するのに合わせて、テスト方法やテストフレームワークやテストスイートも一緒に進化させなければならない。そのため、システムアーキテクトやアジャイルチームやシステムチームは、積極的に協力して常にテスト容易化設計を行う。

原則6─イノベーションに独占はない。

アーキテクチャーの最適化は、アジャイルチーム、アーキテクト、エンジニア、利害関係者が協力して行う。それにより、誰でもどこでもイノベーションを起こせるという、イノベーションの文化を育むことができる。

アイデアは誰からも出てくるが、それを取り込んで広めるには、コミュニケーションを行いシステムの意図に記録することで、ある程度の一元管理をする必要がある。エンタープライズアーキテクトの責務の1つは、チームレベルで現れたイノベーションアイデアや技術改善が見過ごされることなく、アーキテクチャー滑走路の構成要素として組み込まれるような環境を作り上げることである。また、アジャイルでは「緊急の反復という名の専制」を助長しがちなので、イノベーションのための計画的な時間を、予備的なイノベーションと計画策定の反復に組み込むべきである。

原則7─アーキテクチャーフローを実装する。

エンタープライズレベルのアーキテクチャーの取り組みを成功させるには、アジャイルリリース列車や価値のストリームをまたがった連携が必要である。このようなアーキテクチャーの取り組みのフローを効果的にするには、ポートフォリオカンバンを使って可視化する。このカンバンにおいて、プログラムおよび価値のストリームのイネイブラーフィーチャーやイネイブラーシステム能力は、調査、洗練、分析、優先順位付け、実装という一般的な作業フローのパターンをたどる。さらに、カンバンシステムには「プル」の性質があるため、プログラムではWIP制限を使って処理能力を管理できる。これによって、システムに負荷をかけすぎるのを防ぐことができる。

このポートフォリオカンバンと、プログラムと価値のストリームのカンバンシステムが一緒になって、SAFeのエンタープライズ内容ガバナンスモデルを構成する。これは経済的枠組みの一部を具体化したものであり、意思決定を分散するのに役立つ。このどちらも、持続可能な速い価値のフローを実現するのに欠かせない。


さらに知りたい場合

[1] Leffingwell, Dean.Agile Software Requirements:Lean Requirements Practices for Teams, Programs, and the Enterprise.Addison-Wesley, 2011. (邦訳:アジャイルソフトウェア要求:チーム、プログラム、企業のためのリーンな要求プラクティス、翔泳社、2014)

[2] アジャイルソフトウェア宣言:http://agilemanifesto.org/.

[3] Beck, Kent.Extreme Programming Explained:Embrace Change.Addison-Wesley, 2000.(邦訳:XPエクストリーム・プログラミング入門―変化を受け入れる、ピアソンエデュケーション、2005)

[4] Bain, Scott.Emergent Design:The Evolutionary Nature of Professional Software Development.Addison-Wesley, 2008.

[5] Shalloway, Alan, et al.Essential Skills for the Agile Developer:A Guide to Better Programming and Design.Addison-Wesley, 2011.

[6] Evans, Eric.Domain-Driven Design:Tackling Complexity in the Heart of Software.Addison-Wesley, 2003. (エリック・エヴァンスのドメイン駆動設計 (IT Architects’Archive ソフトウェア開発の実践)、翔泳社、2011)

[7] Larman, Craig and Bas Vodde.Practices for Scaling Lean & Agile Development:Large, Multisite, and Offshore Product Development with Large-Scale Scrum.Addison-Wesley, 2010.

[8] Coplien, James and Gertrud Bjornvig.Lean Architecture:For Agile Software Development.Wiley and Sons, 2010.

Last update:27 October 2015