Andrew Harmel-Law氏は先頃、"アドバイスプロセス(Advice Process)"に基づいた、非集中型で拡張性のあるソフトウェアアーキテクチャプロセスについて解説した記事を公開した。アドバイスプロセスは、ほとんどアナーキーともいえる権限付与を伴った意思決定方法をベースとして、一連の議論を促すことによって、ソフトウェアアーキテクチャを進めていく。
ThoughtworksのテクノロジプリンシパルであるHarmel-Law氏の説くアドバイスプロセスは、構成的には極めて単純で、ひとつのルールとひとりの認証者から成り立っている。
ルール: 誰でもアーキテクチャ上の意思決定を行うことができる。
認証者: 意思決定を行う前には、２つのグループに助言を求めなければならない。ひとつはその決定によって有意な影響を被るすべての人たちであり、もうひとつは決定を行う領域の専門知識を持つ人たちである。
意思決定を行う者は、積極的にアドバイスを求める必要はあるものの、それに対する同意や実施は義務とされていない点に注目してほしい。意思決定者には、自分が適切と考える決定を下す完全な自由があるのだ。結果として意思決定者は、自身のアーキテクチャ的判断と実施を完全に所有するとともに、それに対する責任を負うことになる。
Harmel-Law氏がアドバイスプロセスを提唱する最大の理由は、アーキテクチャ上の意思決定をスケールアップすることにある。組織が成長し、自立した複数のチームが独立的に機能して、それぞれの目標を達成する、というマインドセットを採用するようになれば、個々のチームがアーキテクチャ上の意思決定を行う必要が生じるのは自明である。"従来の"アプローチでは、そのようなスケールアップは不可能なのだ。
[従来のソフトウェアアーキテクチャアプローチを]継続的デリバリを実践する自律型チームの世界で使用する限りにおいて、何度も直面せざるを得ない、対処不可能な課題があることに気付いたのです。それはつまり、どこにおいても実施可能にすること、コンテキスト的な分散を許容すること、他の意思決定を妨げないことです。
そして疑問に思いました。他に方法はないのだろうか、と。
ありました — アーキテクチャ判断を止めればよいのです。それも完全に。
Harmer-Law氏によれば、このプロセスにおいても、従来のアーキテクトが不要になることはない。ただ、役割が変わるのだ。自分自身で意思決定する代わりに、アーキテクトは、関係する意思決定の担当者と適切な議論をして、信頼できるアドバイスを提供することによって、最適な全体ソリューションに開発者たちを導く、という責務を負う立場になる。
Harmel-Laws氏はさらに、アドバイスプロセスを4つの重要なテクニックで補完することにより、より長期的な視点を取り入れた、一貫性のある全体像へと開発者を導く、としている。最初のツールは、思考と認識のツール — アーキテクチャ・ディシジョン・レコード(ADR)である。ADRは軽量ドキュメントで、それが説明するアーティファクトと合わせてソースコードリポジトリに格納されることも多い。ADRのテンプレート構造が軽量であるということは、アーキテクチャ上の決定を記載するだけでなく、チームがそれを読んで理解する上でもメリットとなる。テンプレートは一種の思考チェックリストとして機能する。決定を受ける側に対して、何を考える必要があるのか、さらに重要なこととして、何について議論する必要があるのか、を指示する役割を果たすのだ。
第2のツールは、議論の時間と場所を確保するもの — アーキテクチャ・アドバイザリ・フォーラム(AAF)である。AAFは、定期的なものとして用意される、議論のための場所と時間だ。参加するのは、各チームの選任者と、アドバイスプロセスのチェックリストの主な代表者だ。Hamel-Law氏によれば、"アーキテクチャがここで"実施"されて、そこで得た知見が共有されれば、それで大成功"なのだ。AAFで行われる議論には聴衆がいる。多くの人が議論を聞き、全員で学ぶことができるのだ。"これらのセッションを通じて共有される組織的、ドメイン、レガシ、経験的な情報やアーキテクチャ上のスキル展開の量は、これまで見たことのないようなものです。無味乾燥なものになりかねないミーティングであるにも関わらず、1週間の中で最も多くの人たちが、最も幅広く参加しています。"
第3のツールは、統一的な目標を照らす灯 — チームで作り上げたアーキテクチャ原則である。高度に自律的なチームにおいては、整合性を持ったデリバリの方向性を、アーキテクトによるコントロールなしに実現する方法として、これは不可欠なものだ。
第4のツールは、ThoughtWorksテクノロジラダーをベースにカスタマイズされたテクノロジラダーである。とはいえ、特定の言語やツール、組織が活動を展開するランドスケープに合わせた、特別仕立てのものだ。このラダーは意思決定を行う者に対して、利用可能なテクノロジをナビゲートすることにより、より望ましい意思決定を支援する。このようなラダーを作るひとつの方法は、ThoughtWorksの"build your own radar"だ。
Harmel-Law氏の記事を受けて、アドバイスプロセスとその導入について、氏に話を聞いた。
InfoQ: 記事の中心は"アドバイスプロセス"ですが、これはどのような経緯で作られたのでしょう？
Andrew Harmel-Law: "Reinventing Organisations"という書籍では、信頼型組織(trust based organization)における意思決定という面から、アドバイスプロセスについて論じられています。では、信頼型組織では、意思決定はどのように行われるのでしょう？それは、他の人たちの決定を信頼するのです。スケーラビリティという面から、このアプローチは望ましいものだと思います。この方法によって、たくさんの人たちが意思決定をすれば、スケールアップが可能になるのです。ThoughtWorksに参加する前、私は開発者36人のチームを運営していましたが、その後98人にまで増えました。規模が大きくする必要があったのですが、それに伴って、全員をマイクロマネージすることは不可能になりました。そこで考えたのです — すべての意思決定を行うのではなく、彼らを信じて判断してもらえばよいのではないか、と。そこでまず、部分的にアドバイスプロセスを導入し、それがうまくいったのです。ThoughtWorksに参加して、さまざまなプロジェクトのアーキテクチャやガバナンスに責任を持つようになった時にも、アドバイスプロセスが有効なのではないかと考えて、ユーザと一緒に導入するようになりました。
InfoQ: どのようなタイプの組織に対して、アドバイスプロセスの導入を勧めますか？
Harmel-Law: 私たちはこれまで、さまざまな場所でアドバイスプロセスを導入してきました。超分散的な文化を持ったスタートアップにも、中央集権的文化と集中型プロセスの保守的な組織にも導入しましたが、アドバイスプロセスはどちらにも機能したと思われます。アドバイスプロセス自体はアイデアの核であって、ADRやAAFといった他のツールやプラクティスが、このように多様な環境においても、プロセスをカオスや無秩序な状況に陥らせることなく、適切に実行させる役割を果たしているのです。
InfoQ: アドバイスプロセスは、あらゆる経験レベルの開発者との共同作業に適しているのでしょうか？
Harner-Law: 私たちアーキテクトが懸念とすることは、開発者からも懸念として上がってくると思っています。チームリーダだけではなく、開発者自身からもです。自身が責任を持ち、周囲にアドバイスを求めるようになれば、そういった懸念をすぐに知り、考えるようになります。私の見た最高のADRは、自らの懸念であるという理由から、意思決定と実践を行った開発者たちによるのものです。
これまでのアーキテクチャの原則は、アーキテクチャが開発者に対して遵守するよう言い渡すものでした。開発者はそれを無視するか、嫌々ながら受け入れる、というのが現実だったのです。アドバイスプロセスでは、アーキテクチャの原則はアーキテクトが開発者に言い渡すものではなく、開発者が価値を見出して積極的に受け入れるものです。それというのも、決定を下すのは開発者自身だからです。アーキテクトが開発者に遵守を言い渡すものであった原則が、開発者がその理由を理解することによって、俄に開発者の関心の的になった、ということです。
InfoQ: 記事の中に、"アーキテクチャ判断をやめればよいのです。それも完全に"、という件がありますが、仕事を"手放す"ことのできないアーキテクトはどうすればよいのでしょう？
Harmel-Law: 責任を手放してチームに授ける、という体験は新しいものです。こんな機会は誰も与えてくれません。最近の私のコンサルタント活動の大半は、アーキテクトや技術リーダに仕事を手放させるためのものです。そのための方法は、仕事を少しの間手放すように、アーキテクトを説得することです。そうした上で、万事が滞りなく進むことを納得させるのです。
ほとんどのアーキテクトは最初、カオスに陥るのではないか、と心配するのですが、自律性に慣れていない開発者が尻込みしてしまい、チームが一歩も前に進めないという状況の方が一般的です。そこでアーキテクトは、チームを励まして、意思決定を行うように積極的に求めると同時に、その支援を行うことになります。ただし、あくまでもアドバイスをするだけであって、代わりに意思決定を行ってはいけません。
その結果として、全体像を把握するアーキテクトと、コードベースレベルの複雑性を理解する開発者とのコラボレーションによって、素晴らしい議論が生まれるのです。
コードを実行するだけだったチームが、自分たちだけが知っている問題を解決し、自分たちの望むスケールでそれを修正できるツールを、唐突に手に入れた、ということです。アーキテクトの側は、自分がコントロールを放棄したのではない、自分の考えや知識をこれまで以上に広めることが可能になったのだ、ということを理解します。1か月も過ぎるとアーキテクトは、自分だけが知っていると思っていた問題を他のメンバが持ち出して、全員が気にしていることを知るようになります。
InfoQ: 機能横断的な要件(CFR)についてはどうでしょう？誰がリードすることになるのでしょうか？全体戦略にそぐわない"部分最適化"を克服する手段はありますか？
Harmel-Law: どこへ行ってもCFRは定義されていますが、多くの開発者はそれを知らなかったり、もっと悪い場合には気にかけていなかったりします。アドバイスプロセスでは、アーキテクトが、CFRの存在を前提とした意思決定を現場に求めることによって、そのような事態が発生した場合への対処としています。あるユーザにおいて開発者が、システムの可観測性が不十分であるため、トレースIDの追加が必要だ、と気付いたとします。そうすればアーキテクトは、すでに存在するCFRを彼らに指し示すことができるでしょう。その他のCFRに関しても、的を射た質問やアドバイスの提供があれば、既存のCFR(パフォーマンスやスケーラビリティに関連するものなど)を表に出して、開発側からのニーズというコンテキストで議論が再開する、ということも考えられます。
フィールドからの声だという事実が、導入それ自体への抵抗を和らげるのです。アーキテクトが頑張ってプッシュする必要はありません。議論を始めることがアーキテクトの仕事なのです。