アーキテクチャの実践を会話によってスケールする

「従来型」のアーキテクチャアプローチが破綻するとき

正直に言うと、ソフトウェアアーキテクチャに対する「従来型」のアプローチ（つまり、コーディングではない、意思決定を行う、図を描く）は、私にとってはどんなに調子が良くても実現するのが難しいものです。しかし、継続的に自律的なチームをデリバリーしている世界でそれらを使用していると、私は繰り返し、不可能に思えるタスクに直面しました。それは、どこにでもいて、大きな状況の違いを許容し、誰の邪魔もしないことです。

私は疑問に思いました。何か代替案はないのだろうか？

ありました。私はアーキテクチャの決定を下すのをやめました。完全に。

この記事では、この代替的な考え方と、関連するツールと実践を紹介します。それにより、私は「ソフトウェアアーキテクト」の従来の役割を覆すと同時に、ソフトウェアアーキテクチャの実践を開発チーム全体に前面に押し出すことができます。さらに重要なことに、この代替アプローチの中で、すべてが混沌に陥ることなく、誰もが安全かつ効率的に必要なアーキテクチャを作成できる方法を説明します。[1]

もっと多くのアーキテクチャを「行う」方法が必要です。減らすのではなく。

ソフトウェアデリバリーにおける、チームの自律性をますます高める動きは、少なくとも私の考えでは、アーキテクチャの意思決定に対する代替アプローチと組み合わせた、より多くのアーキテクチャ的思考の必要性を高めています。

ソフトウェアチームが真の自律性を経験できるようにすることは、重要な問題を引き起こします。少人数のアーキテクトグループが、価値ストリームに沿った多数の意欲的なチームにどのように供給できるのでしょうか？なぜでしょうか？それは、この環境ではアーキテクト[2]が、これまで以上に多くの場所に同時に存在し、従来の「アーキテクチャ」をすべて行う必要があるからです。

私たちに必要なのは、チームの自律性とその結果として現れるアーキテクチャという、人間的なスケールアップの課題に取り組むための実行可能な方法です。

この記事の残りの部分では、アーキテクチャを実施し、管理する代替の方法を紹介します。それが何であるか、どのように機能するか、そしてどのように自分で採用できるかを詳細に説明します。最も重要なことは、成功するために、失敗する方法を強調します。

最も根本的な要素：「助言プロセス」による意思決定

最大限に独立させることを目指すチームを起点として考えてみましょう。明らかに、このチームはアーキテクチャの思考と意思決定に何らかの形で関与する必要がありますが、どのようにすればよいでしょうか？

これらの「多数の意思決定センター」こそ、まさに私たちが必要としているものですが、すぐに、すべての決定を下す選ばれた全能のアーキテクトグループによる、従来型のトップダウンアーキテクチャは、そのような分散型のモデルとは相反することが明らかになります。「それにもかかわらず」と、課題は提起されます。「決定は依然として下す必要がある。それこそがアーキテクチャなのだ」と。そして、これらの懐疑論者は正しいのです。

これらのアーキテクチャ上の決定は、意図的に下される必要があります。そうしないと、私たちは元の場所に戻るか、さらに悪い状態になるでしょう。したがって、この代替アプローチにおける最初の側面、事実上のその核心的な要素は、意思決定をどのように実現するかを説明する必要があります。それは「助言プロセス」と呼ばれます。

助言プロセスは、このアナーキーで分散型のアプローチの中心的な要素です。その最大の特質は、驚くほどシンプルであることです。それは1つのルールと1つの修飾子で構成されています。

それだけです。それが助言プロセスの全体です。

しかし、この一見単純なことの背後には、明示する価値のある重要な概念が隠されています。意思決定者は、これらの相談された2つのグループの人々が与える助言に同意する義務はまったくありませんが、それらを求め、聞き、記録する必要があります。私たちはここでコンセンサスを探しているのではなく、幅広い意見と声を探しているのです。

このことに対してよく提起される課題は、相談しなければならない人の数です。それは妥当な懸念ですが、軽減可能な懸念です。この手法を展開する際には、意思決定の立場にある人が誰に、どの点について話すべきかを特定するのに役立つチェックリストを作成します。情報セキュリティに影響がありますか？CISOに相談してください。PIIに近づいていますか？データチームのメアリーと法務部のヴァネッサに関与してください。ユーザーオンボーディングフローへの潜在的な変更ですか？UXリードに相談してください。新しいクラウドサービスを採用しようとしていますか？クラウドアーキテクトのクリスとチャットしてください。APIの変更を考えていますか？消費者であるすべてのチームのリードと話してください。

この相談者のリストは長くなることがあります。それはそれで構いません。一部の決定は大きなものであり、助言の範囲はサイズと重要性の両方を明確に示しています。決定がより小さく行われ、その結果として多くが発生することがあります。また、影響を受ける人の数が非常に多いため、決定者は考え直すことがあります。彼らの生活を少し楽にするかもしれないこのことは、それらのすべての人に相談する努力をする価値があるのだろうか？あるいは、この大きな決定を複数の小さな決定に分割できるのだろうか？決定が進行するとき、それらは頻繁に便宜上、適切なサイズになっています。[3]

助言プロセスをさらに推し進めることはできるでしょうか？はい、できますし、そうすべきです。私は常に、それに従う人々に、自分に反対する人を特に探すよう促しています。聞くことに同意する必要がなければ、彼らは必然的により真剣に関与します。その結果、受け取る助言の深さと幅が大きくなります。決定がその結果として損なわれる傾向もありません。彼らの学習も同様です。

これにより、助言プロセスの幅広い利点という話題になります。展開されたとき、私は常に、より良く、より速く、より責任ある決定、そして最も重要なことに、決定を実行する人が理解し、所有している決定を見てきました。それは、意思決定者が責任者であると同時に、必要とする人であるからです。

副作用として、利用可能な意思決定者のプールも拡大します。彼らのそれぞれが、すぐに下す必要のある決定を探し始め、助言プロセスが与える安全なエンパワーメントの感覚を考慮して、それらを提起し、結論に導きます。決定を下す必要性がチーム自身によって満たされるという事実は、適切なレベルの行動への偏りにもつながり、必要に応じて責任がブレーキの役割を果たします。

このようにして作業することで、固定された永続的な階層と永続的なマスター意思決定者の両方の必要性を排除します。分散型意思決定は「アナーキー的」と呼ぶことを目指すものの核心的な要素であるため、助言プロセスがこのアーキテクチャアプローチの最も基本的な要素であるのは、これら2つの理由によるものです。

しかし、待ってください。私たちは一挙に「従来型」のアーキテクトの必要性をすべて排除したのでしょうか？いいえ、まったくそうではありません。しかし、私たちの役割は明らかに変化しました。この記事の次のセクションでは、このアプローチのサポート要素を紹介します。そこでは、チームと彼らが支えるビジネスを、彼らが必要とする場所に到達させるための、活性化された一連の実践とツールが見られます。

これらのサポート要素に進む前に、この分散型アプローチの残りのすべての要素が共有していること、そして核心的な要素と共通していること、つまり会話に焦点を当てていること、そして共有された理解に効率的に到達し、広める上での会話の役割を強調し、議論するために少し寄り道することは有益です。

4つのサポート要素

これが実際にどのように機能するか

これらすべてを踏まえて、実際にどのように機能するのかを見てみましょう。

アーキテクチャに関する決定の必要性が最初に発生したとき、それはおそらく曖昧で、理解が不十分な可能性があります。したがって、すぐに新しいADRテンプレートを開いて、入力してみるのが最適です。

最初に取り組むべきは「コンテキスト」セクションです。これを行うには、バランスを取る必要のある周囲の力だけでなく、決定の「理由」を理解する必要があります。この短いセクションでさえも完了するには、調査を行う必要があることにすぐに気付くでしょう。

この調査の初期段階では、アーキテクチャの原則とレーダーを参照する必要があります。原則は、思い出していただければ、理想的なソリューションが理想的に具現化する方向性を示してくれます。すべてが関連するわけではありませんが、いくつかの原則は意思決定に役立つはずです。複数の技術的な可能性を評価し、最適なものを強調することが、アーキテクチャ原則の主な目的であることを思い出してください。

場合によっては、経験が少し異なることがあります。1つの代替案は、関連する原則が2つのオプションから選択するのに役立たない場合です。その場合、選択するのにほとんど差がないか、原則が十分にS.M.A.R.T.ではない可能性があります。これは原則を見直し、再定義する良い理由です。

もう1つの代替案も、おそらく少し遅れて、原則の再評価につながる可能性があります。これらは、決定を下すために、一つ以上の原則に違反する傾向があると感じた場合に発生します。それでも大丈夫です。優れた決定は原則に反する可能性がありますが、そうするには、なぜこの行動方針が正しいステップだったのかを明確に示す必要があります。原則を覆すことは、一般的な進むべき方向から効果的に逸脱することを意味するため、重大なステップです。したがって、決定と結果のADRは、明確に議論され、強く正当化される必要があります。また、この開発を踏まえて原則を見直す時期である可能性もあります。

対照的に、レーダーはより助言的な性質を持ちます。これは、問題領域で現在事実上の標準となっているもの、過去に何が行われたか、他のチームが実験している可能性のあるものについてのアイデアを提供します。異なる方法に進むことは、眉をひそめられる可能性ははるかに低いですが、ADRで逸脱に対処する明確な理由になります。

これらすべてを踏まえて、オプションを評価するための主要な基準と、代替案のリストを作成し始めることができます。おそらく、宿題をする必要性に本当に気付いたため、何かについて詳しく学ぶために、時間制限付きのスパイクをスピンオフするかもしれません。ADRの考え方は、ここで非常に明確な受け入れ基準を作成するのに役立ちます。スパイクを行う必要がない場合は、代わりに助言を求めることを検討します。

コンテキスト（例えば、技術戦略など）、適用可能な原則、レーダーのブリープ、主要な基準/代替案からのこれらのインプットを持つことで、誰にアドバイスを求めるべきかを考えるのに役立ちます。私の経験では、問題領域やニーズを比較的理解していると確信できるが、特定の解決策に固執しすぎる前に、これに取り組むことが役立ちます。アドバイスを求める際には、あなたに反対する可能性のある人、つまり、異なる考え方をする人や、自分に盲点があることを知っている人に、最も時間と労力を費やしてください。それだけでなく、自分自身に挑戦してください。「この代替案の悪い点は何か？欠点は何か？」と考えてください。あなたの決定に最も直接的かつ根本的に異議を唱える代替案について、最も時間をかけて考えてください。

議論をする前に、ADRを大まかな形で準備し、事前に共有することが役立ちます。これにより、彼らに考える時間を与えることができます。そして、実際に会ったときは、ADRテンプレートのすべての要素を確認してください。コンテキストから何か見落としていませんか？原則/ブリープから？評価基準から？これらすべてについてアドバイスを求め、記録してください。さらに重要なのは、なぜ彼らがこれらの提案をしているのかを尋ねることです。より良いアーキテクチャ上の決定を下すための鍵となるのは、これらの質問への回答です。アドバイザーは、彼らがどのように問題を認識しているか、過去に同様の状況に遭遇したときの経験、さらにはあなたが考えも及ばない側面全体を理解するのに役立ちます。[7]

AAFはどうでしょうか？それはアドバイスを集める場所ではないでしょうか？はい、そして上記で共有したことはすべて、どこで会話をするにしてもあなたを導くはずですが、チームや個人が最初に行ういくつかの決定については、主要なアドバイザーとより的を絞った方法でこれらを行うことが非常に役立ちます。AAFの前に提示するADRは、広く共有される前に本当にしっかりとした、焦点の合ったものになるため、結果として得られるAAFの会話はより豊かで、焦点を絞ったものになるでしょう。AAFでの簡単な会話が、その後のより詳細な1対1の会話につながることもあります。

アドバイスをどこから得たとしても、ADRに取り込む必要があることを忘れないでください。与えられたアドバイスを採用する必要はありませんが、記録する必要があります。ここで優れたプラクティスは、人々が直感的ではない、または驚くべきことだと思うことを優先して書くことです。主要なアドバイスに同意しない場合は、どのように、なぜそうなのかを明記してください。何か新しいことをしている場合は、なぜ現在のやり方があなたには機能しないのかを明確にしてください。原則を使用することを忘れないでください。それらがあなたの決定を支持することもあるでしょう。どのように支持するのかを明確にしてください。場合によっては、それらに反する必要があるでしょう。なぜそうなのかを明確にしてください。あなたの目標は、読者があなたがなぜその決定を下したのかを理解できるようにすることです。この目標を達成すれば、確固たる決定を下すだけでなく、その過程で多くのことを学んでいる可能性が高いでしょう。[8]

このセクションを終える前に、すべての決定は特定の時点でのものであり、誰も将来起こるすべての事態を予見することはできないことを覚えておいてください。しかし、後で振り返ったときに、当時知っていた/理解していたことを考えると、その決定を良かったと感じられるようにする必要があります。この点で、あなたが記録したコンテキストと基準が重要です。この決定の再検討は、もう1つの優れた学習ツールです。後知恵の利点を活かして、「コンテキストを十分に理解していたか？」や「自分たちが知っていることと知らないことについて、十分に正直だったか？」などの質問をすることができます。

失敗する方法

以上が、アーキテクチャに対する私たちの代替的で分散型、アナーキーなアプローチの範囲と、それがどのように組み合わさっているかのアイデアです。しかし、結論を出す前に、最後に1つの側面、つまり失敗する可能性のある主な方法について触れておく必要があります。それらを列挙してみましょう。

実際に見られる失敗の大部分は、経験の浅い人が決定を下すことによって起こる、良い失敗、つまり小さな失敗です。これらが良いのは、このプロセスが、必要とする人による迅速な意思決定を促進し、さらに重要なことに、透明性、失敗の迅速な特定（決定を下した人はそれをコード化する際に問題に気づくため）、そして再検討し、学習を共有するための安全な手段を促進するからです。これらを積極的に受け入れ、具体的に呼び出し、AAFで祝ってください。これは、学習文化を構築するための重要な側面です。

最も効果的に学習するには、安全だと感じる必要があり、集団的に学習するとき、議論に貢献する最も広範で多様なインプットから全員が利益を得ます。このアプローチでは、明示的にコンセンサスを求めているのではなく、広範なインプットと声を求めていることを忘れないでください。ここに次の失敗モードがあり、それは最初の失敗よりもはるかに陰湿で有害です。この2番目の失敗モードは、会話の開始者およびスペースホルダーとしてのあなたの仕事において、貢献し、決定し、学習する必要のあるすべての人を含めることができなかった場合に発生します。このスタイルのアーキテクチャの初期採用段階では、多くの場合、大きな成功のように感じられることがあります。「うまくいっている！ますます多くの人が意思決定を行い、ADRに書き出し、アドバイスをし、AAFで議論している！これまで原則に対するこのような関与を見たことがない！」と。後になって、振り返ってみると、得られるものがはるかに大きかったことに気づくでしょう。この最初の満足感が襲ったときこそ、最も警戒しなければならないときです。本当に、大勢の参加と学習を観察しているのか、それともいつもの中心的なグループだけなのか？この問題は積極的に軽減する必要があります。誰が貢献しているかを注意してください。声を増幅し、静かな貢献者の意見を他の人が聞くようにしてください。影響力が、評判、在職期間、または階層内の地位に基づいていないようにしてください。多くの視点を積極的に奨励し、それがもたらす価値を強調して、それが自立的に維持されるようにしてください。

3番目の失敗モードは、先行する失敗モードに遭遇しているという早期警告ですが、これは望ましいものと望ましくないものの間のグレーゾーンに存在します。この道のりを進むにつれて、あなたはオフグリッドの決定を発見するでしょう。AAFで議題にならず、ADRにも記録されなかった決定です。それらに対処する方法は2つあります。最初の正しい方法は、発見をあなたが望むものであり、正直な間違い、そして学び、他の人に教える機会として扱うことです。おそらく、意思決定者は、それが自分たちが下している重要な決定であることにさえ気づいていなかったでしょう。おそらく、彼らは他の場所からプレッシャーを受けていたでしょう。おそらく、それはそれほど重要ではないと思っていたでしょう。おそらく、AAFで反対されると感じていたでしょう。理由が何であれ、それを彼らとあなたが両方とも学ぶための方法として扱ってください。プロセスを改善するために。これらの扱い方のもう1つの間違った方法は、古いやり方に戻り、支配権を取り戻すことです。これは、このアプローチとそれが約束するすべてを完全に破壊する失敗モードにつながります。

この4番目で最も危険な失敗モードに陥るのは簡単なので、あなたの側で常に警戒する必要があります。これを引き起こすために必要なことは、「大文字のA」の建築家であるあなた自身が、人々を信頼することをやめてしまうことです。それは、あなたが説くことを実践しないことです。それは、前述の小さな失敗とそれに伴う学習機会のための十分なスペースを確保しないことです。それは、他の場所からのすべての兆候にもかかわらず、物事があなたが思うように進むようにするために、舞台裏で「影のアーキテクチャ」を継続することです。この失敗モードの唯一の利点は、上記にリストしたすべての利点が実現しないため、非常に迅速に明らかになることです。

このアーキテクチャへのアプローチを成功させるのが難しいのは、この主要な失敗モードが原因なのかどうか疑問に思っているなら、それは正しいでしょう。私は過去に幸運でした。同僚は、私が他の人のために意思決定をしたときに私を呼び出し、私が知っていることを人々が知らないことに不満を感じている自分に気づきました。しかし、そのとき、私はアーキテクチャの実践者としての自分の本当の仕事に失敗していることに気づきました。つまり、適切な人々と、適切なタイミングで、適切な会話をできていないのです。そのことを覚えておいてください（プロセスを遵守しない場合に他の人にあなたを呼び出すように指示してもかまいません）、そして成功することがどれほど簡単（そして満足感がある）かに驚くでしょう。

5つの要素の再確認と、さらなるステップの可能性

良いものと（潜在的に）悪いもの、そして注意すべき失敗モードのコレクションができたので、結論としましょう。アーキテクチャへの代替アプローチの5つの要素を思い出しましょう。

1つの核となる要素：アドバイスプロセス

4つのサポート要素

• アーキテクチャ諮問フォーラム
• 軽量ADR
• チームソースの原則
• 独自の技術レーダー

これらの要素のどれも（おそらくアドバイスプロセスを除いて）あなたにとって新しいものではないかもしれませんが、非常に異なるものがあることを明確にできたと思います。この違いは、会話、学習、安全を背景にした、これらすべての相互作用/相互補強にあります。少なくとも私の経験では、これが現在および将来に向けて、より確実に展開されたアーキテクチャを提供できる可能性が高いという事実が、魅力的であることを願っています。これは、自分自身を拡大し、私が一緒に働くチームが、結局のところ目標であるユーザーに約束したことを確実に提供するための、私の頼みの綱です。

あとがき：次は何をする？

もちろん、この記事を焦点を絞って書こうと努めてきましたが、さらに深く掘り下げることができます。私は、このように取り組んでいるチームが、自然に自分たちの道を切り開き始めているのを見てきました。つまり、(配信)プラットフォームチームが存在する前に、独自の配信プラットフォームを自己完結的に提供し始めるのです。(私の同僚であるエヴァン・ボッチャーの優れた「私がプラットフォームについて話すときのこと」と、スケルトンとペイズのチームトポロジーで、これについて詳しく説明しています。)

また、チームが独自のアーキテクチャ適合度関数（そして実行コストだけではありません）を導入して、集団的なアーキテクチャが意図された範囲外に逸脱したときにわかるようにしているのも見てきました。

私が学んだ最大の教訓は、人々をエンパワーメントし、成功するための環境を与え、彼らの成功を認識すると、彼らはすぐに、そして集団として、あなたが考えもしていなかったことについて考え始めるということです。それが、この種のアプローチの本当の利点です。つまり、少数のはるかに制限された知性に頼るのではなく、多くの集団的な知性にアクセスすることです。