ソフトウェアアーキテクチャに関するプラクティスとして、アーキテクチャデシジョンレコード（Architecture Decision Records, ADR）というものがあります。この記事は、それを組織構造に適用してみるとどうなるだろうと考えてみるものです。100%妄想ですので、予めご了承ください。
（↓妄想が湧いたときのツイート）
組織構造についてのアーキテクチャデシジョンレコード（ADR）というプラクティス、あると助かる場面はありそうだなと思いました
— こま (@koma_koma_d) 2021年11月27日
2021/11/30 追記: 数日前に、同じくADRを組織の領域に適用する話が出ていました。
ADRとは？
今回の題材である（本家の）ADRとは、以下のようなものです。
テキストベースの軽量なテンプレートを使用して、アーキテクチャ上の設計判断を記録する。（中略）設計判断を記録していくことで、それらを共有し分析することが容易になる。意思決定の履歴を残すことで、現在のアーキテクチャについてのコンテキストを、その過程と結びつけて提供できる。
（『Design It! ―プログラマーのためのアーキテクティング入門』p.302）
アーキテクチャに関する設計判断は、プロジェクトの最初に一回だけなされるというものではありません。設計判断（およびそれに基づくアーキテクチャの変更）は、コンテキストの変化にも対応しながら、継続的に行われていくものです。ADRは、これらの判断を毎回簡潔に記録していくことで、将来の開発者のアーキテクチャに対する理解や判断を助けてくれます。
なぜADRを組織に適用しようと思ったのか？
『チームトポロジー 価値あるソフトウェアをすばやく届ける適応型組織設計』は、チーム編成は継続的に設計していくべきものであると主張しています。
探索や実行といった、プロダクトや技術のライフサイクルにおける各フェーズをサポートするには、チーム同士のやりとりは時間を追うごとに進化する必要がある。
※『チームトポロジー』については以下の記事をご覧ください
この書籍では、組織内のコミュニケーション（チーム同士のやりとり）の構造がソフトウェアの開発にとって極めて重要であり、開発の中で実現したい事柄に応じてこれを変更していくことが必要であると指摘されています。この言説に従うならば、チーム編成の変更は、偶発的なものではなく、継続的に行われていくものということになります。
また、この主張の背景には、組織のコミュニケーション構造とそれが生み出すシステムの設計との相関を指摘した「コンウェイの法則」（および、その応用としての「逆コンウェイ作戦」）があります。
以上のことから、継続的に行われるソフトウェアの設計に関する判断を記録していくプラクティスが有効なのだとすれば、ソフトウェアの設計と密接に関わっている組織構造（チーム編成）に関する判断（これも継続的に行われる）を記録していくことにも意味があるかもしれない、というのが今回の着想です。
記録するとよさそうなこと
Michael Nygard による本家ADRのテンプレートは、以下の通りです。同じものをベースにして、補足をしてみます。
- タイトル（Title）
- コンテキスト（Context）
- 内容（Decision）
- ステータス（Status）
- 影響（Consequences）
※各項目の訳語は『Design It!』に準拠しました
「コンテキスト」の項目では、本家ADRでは、技術やスキルといったソフトウェアに「近い」内容に限らず、ビジネスの状況などのアーキテクチャに影響を与える要因を記述することが推奨されています。組織構造についての判断についても、ほぼ同様の内容を記述することができるはずです。システムに対する変更の判断が技術以外の要因の影響を受けるのと同様に、組織に対する変更の判断も技術やビジネスなどの要因の影響を当然に受けるからです。
「影響」の項目では、本家ADRでは、判断がシステム、ステークホルダー、チームの状況をどう変えるか（そして変えたか）を記述することが推奨されています。ここも同様の内容を書くことができるでしょう。特に、ネガティブな変化についても記述せよという本家の指摘は、組織に対してこのプラクティスを適用にするときにも重要になると思われます。組織の変更はポジティブな結果を期待して行われるものですが、そこにトレードオフやリスクがあることを（判断する側はもちろん、その他のメンバーも）知っていることは大切です。
何が嬉しい（嬉しそう）なのか？
実践してみたわけではないのですが、本家ADRについて挙げられているメリットや、過去の自身の経験などを踏まえて想像（妄想）してみます。
- 組織構造に対して変更を加えるというのは、一定のポジションにならないと経験しづらいものですが、判断を記録の形式に落とし込むことで、マネージャー以外のメンバーもその判断について理解することができます。
- メンバーは、自身が所属するチームの役割だけでなく、他のチームの役割や、それとの関わり方についての「設計思想」も知ることができます。
- 現時点での組織構造についての歴史的経緯がわかるようになります。歴史的経緯がわかると、今後の方向性について共通認識を持ったり、過去の過ちから学んだりできます。
注意（したほうがよさそうな）点
- 本家ADRに比べて、GitHubなどのコードに近いところで保存しておくメリットは乏しいように思われます
- 本家ADRでは、ADRを（GitHubなどを使って）ピアレビューできることもメリットに挙げられていますが、組織の変更について同様の民主化が完全に可能なのかは不明です
- 最も粒度の小さい変更としての個人の異動については、理由を全て公表することができない場合もありうるでしょうから、そもそも残さないほうが良いようにも思われます
おわりに
以上、組織構造版ADRというプラクティスを考えてみたよというお話でした。
もし、「実践してみたよ！」という方や、「既に似たようなプラクティスをやっているよ！」という方、あるいは「それにはそもそも名前がついていてだな・・・」という方がいらっしゃったら、記事へのコメントないし @koma_koma_dまでぜひご連絡ください（興味本位）。
