どうアジャイルとアーキテクチャは袂を分かち、最後に友好関係を築いたか

人々はアーキテクチャを定義すること、もしくはソフトウェア設計を行うことの必要性をアジャイル宣言の不正確な解釈のために止めてしまったと、Software Architecture for Developersの著者であるSimon Brown氏は主張した。多くのソフトウェア開発者はプラクティスの十分な工具箱を持っていると思っておらず、ソフトウェア業界にはソフトウェアアーキテクチャに対する十分な共通言語が欠落している。良いアーキテクチャはアジリティを高める。方向性を設定するための強固な基盤を構築するのに必要十分な事前設計が必要である。

Brown氏は、どうアジャイルとアーキテクチャが袂を分かち、最後に友好関係を築いたかに関するオープニングの基調講演を、サウスウェールズで開催されたソフトウェア開発者、ソフトウェアアーキテクトプロジェクトマネージャ、アナリストやコンサルタントのためのアジャイル開発とソフトウェアクラフトマンシップの会議であるSwanseaCon 2016で行った。InfoQはQ&Aや、まとめ、記事によりこの会議について伝えている。

早期に学習できることを最適化するというのがウォーターフォールの背後にある考え方である。早期に開発に時間を使うことで後段のコストを削減可能であるとBrown氏は述べた。例えば、彼は構造化システム分析及び設計(SSADM)について言及し、これはソフトウェアを開発するためのウォーターフォールを基礎にしたアプローチである。この手法はシステムの管理の概念を流用した全体ライフサイクルを提供し、ソフトウェアソリューションを構築する各段階における活動について検討することを可能とする。Brown氏は反復型かつインクリメンタルなフレームワークであるラショナル統一プロセス(RUP)についても触れた。RUPはカスタマイズされるべきだったが誰も行わなかったため、結果としてプロセスが大きくなり過ぎたととBrown氏は述べた。

ウォーターフォールの主要な問題は長大なフィードバックループにある。ウォーターフォール手法の構造と厳密さは高品質な製品の開発を支援するが、フィードバックがないため誤った製品を開発するリスクが存在する。

アジャイル宣言は、プロセスとツールはアジャイルにおいてもまだ重要であるが、個人と対話は更に高い価値を持っていると述べている。しかし多くの人々はアジャイル宣言を不正確に解釈しプロセスはもう必要ないと考えてしまっている。宣言はまた"包括的なドキュメントよりも動くソフトウェアを"と述べており、人々をアーキテクチャを定義すること及びソフトウェア設計を行うことの必要性を顧みないようにさせた。このことによりアジャイルとアーキテクチャの間の摩擦が発生したとBrown氏は述べた。

第一の摩擦はチーム構成に関するもので、ソフトウェアアーキテクト専従者が必要なのか、全員がソフトウェアアーキテクトであるのか?という疑問である。宣言の原則11は"最良のアーキテクチャ・要求・設計は自己組織的な組織から生み出されます"と述べている。宣言がアーキテクチャと設計に言及しているのは良い点だとBrown氏は述べている。彼は役割が分散された成功したチームを見たことがあるが、アーキテクチャと設計に対する責任がなく、皆が別の誰かがアーキテクチャに対する配慮をしていると思っているチームを見たこともある。

第二の摩擦はプロセスについて取り組むべきことである。歴史的に、前もって長大な設計を行う行為(BDUF)を行う傾向があるとBrown氏は主張し、これは人々が青写真を定義するために全てのことを前もって理解しようとすることである。人々はアジャイルでは前もって設計を行うことは許されるのかどうかを疑問に思った。進化的な設計はある設計を行うことにより解を導こうとする。しかしアーキテクチャが誤っていることがわかったときにはソフトウェアを変更するのは困難である。リファクタリングにはコストがかかる可能性がある。核となる基盤は最初から構築された場合に最も良好に動作する傾向があるとBrown氏は述べた。

Brown氏はテスト駆動開発(TDD)を行うときにアーキテクチャは必要ないということに賛成しない。彼はアーキテクチャを前もって定義することでTDDが境界内で動作できるようにすることを提案する。また、Brown氏はアーキテクチャに関する決定をできるだけ"責任の範囲内での最後の瞬間"に行うこと(これは"ずっと決断をしないようにするようにしよう"と解釈されうる)ということに強く反対している。

アーキテクチャにより問題を修正するために、アジャイルが本当は何であるかを理解する必要があるとBrown氏は述べた。彼が提案する核となる定義は以下である。

素早く動き、変化を擁護し、頻繁にリリースし、フィードバックを得ること。

アジャイルはソフトウェアを届けるための軽量なアプローチであり、継続的な改良を行っていくという価値観と文化に基づいている。アジャイルをするよりもアジャイルであるというのが重要であるとBrown氏は述べた。しかしアジャイル宣言の言葉は不幸なことに人々を混乱させた。"xよりもyに価値をおく"というのはしばしば間違って解釈された。

宣言の原則9は"技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます"と述べている。優れたアーキテクチャは機敏であることを可能するとBrown氏は主張した。彼によれば、アジリティは"非機能"もしくは"品質"要件である。アジャイルではどのくらい素早く行動する必要があるかということと、求められるソフトウェアの要求品質の間で決定を行う必要がある。

Brown氏は設計の復活があるかどうかを問いかけた。なぜならDSDM Atern, Disciplined Agile Delivery (DAD), and the Scaled Agile Framework (SAFe)のような手法の全ては設計要素を内包しているからである。彼は以下のように述べた。

完璧な終了状態、フレームワークや完全なアーキテクチャを作り出すことではありません。チームのための開始点が必要であり、チームとして共に正しい道を歩むことができるようにするために構築しているものなのです。

リーンとアジャイルは双方とも価値を付け加え無駄を省くことを目的としている。開始点を適宜することには価値がある。方向性を設定するための強固な基盤を構築するために十分な設計を前もって行う必要がある。

Brown氏はWikipedia上のソフトウェアクラフトマンシップの定義はコードに焦点を当て過ぎていると述べた。多くのソフトウェア開発者はプラクティスの十分な工具箱を持っているとは思えない。ソフトウェアを文書化する方法はたくさんあるが、人々をはしばしばこれらに気づいていない。もし彼らにどうソフトウェアを設計しているのか尋ねたら、彼らは"ホワイトボードを使っている"や"コンポーネントを表現する箱を描いている"といった答えが返ってくるだろう。彼の経験では多くの人はどう分割するか、それにはどんな基準が使えるかを知らない。例えばクラス-責務-コラボレーション(CRC)を聞いたことがない。

Brown氏は"同じ方向に素早く動くには良好なコミュニケーションが必要である"ことを示唆した。ソフトウェア業界はソフトウェアアーキテクチャのための共通の語彙が欠けている。ソフトウェア開発はエンジニアリング分野だと考えられるべきである。彼はMary Shaw氏のソフトウェアのエンジニアリング分野へのあゆみのトークに触れた。これにはInfoQのまとめ(Software ・Is it "engineering" yet)でも触れた。Shaw氏は何がソフトウェア開発がエンジニアリングのになるために何が必要かを要約した。

私たちはエンジニアリング分野のある点に存在していますが、エンジニアリングに関連した社会的契約を満足する品質を、計算システムに対して保証する実践のレベルを絶えず獲得することはまだできません。ソフトウェアの設計と解析に科学と体系化された知識を入れ続けていくことが必要です。

アジャイルとアーキテクチャは袂を分けたかも知れないが、これらは15年の歳月を経て最後に再び友好関係を築いているとBrown氏は述べた。彼はこのように述べた。"過去の経験を無視するよりもむしろ学んでいこう"と。