逆コンウェイ戦略の誤り; 変化に対応する構えとしてのアーキテクチャ


From:

Stephen S. HANADA

Shinjuku, Tokyo

Sunday, 07:00 a.m.

親愛なる友人へ、

いかがお過ごしですか?

アーキテクトの業務に関する書籍を読んでいた私は戸惑いを覚えていました。

「こんなの、

普通のエンジニア

やっていることじゃないか?」

要望から要求へ、要件へ、そして仕様へ、という分析や、コードの構造設計や同期/非同期等を含めたインフラ設計についての判断・決定、そして、実装やテスト、デプロイにおけるプラクティスの適用、他にも色々な業務がありますが、全部、普通のエンジニアがやっていることで、そして、出来て当然のことばかりです。

これらがアーキテクトの仕事、とでも言うような文章を見た私の戸惑いは上述の通りですが、その他に思ったことが2つあります。1つは、もしかしたら、私がこれまで同僚や部下に対してめちゃくちゃ多くの仕事や能力を要求してきたのではなかろうか、という不安です。しかし、このことは、裏を返せば、これくらい要求することは信頼していることなのかもしれませんし、そう受け取られていたかもしれない可能性があります。また、出来て当然という態度とそれに伴う権限の付与は、成長やチャレンジを求めてスタートアップに来る人にとっては嬉しいことなのかもしれません。

そして、もう一つ思ったことが重要です。それは、普通のエンジニアに出来て当然ならアーキテクトの仕事はなんなのか、という疑問です。各業務が普通のエンジニアでもやることであるとすれば、アーキテクトの業務を集めて集合をとっても、アーキテクトの仕事を十全に定義することにはなりません。

ISO/IEC/IEEE 42010にあるアーキテクチャの定義によれば、entityの基本概念や、entityとそれに関連するサイクルプロセスの実現・進化を統率する原則がアーキテクチャですから、類推するに、システムやプロダクトの各種業務を行うだけではなく、その進化と実現に責任を持ち、そのためにあらゆることをすることが、アーキテクトの仕事になるのでしょう。しかし、視座や目的を追加しただけのこの言明では、まだ和集合による定義を超えていません。そこで、もっと1つの領域に踏み込んで考えてみましょう。

もし、アーキテクトのしごとが、その目的のためにあらゆることをするならば、アーキテクトはシステムやプロダクトを扱う側の人や組織の方にも当然目を向けなければなりません。その前提を置いて思い出されるのが、数年前に流行った「逆コンウェイ戦略」です。その内容を簡単にまとめると、次のようになります。

望ましいシステムアーキテクチャを実現したいなら、先にそれに合わせて組織構造を変えるべき。

しかし、これの何が、コンウェイの「」なのでしょうか? 私は「逆」とは全く思いません。「コンウェイの法則」と呼ばれるものをコンウェイ自身が発表した1968年の論文"How Do Committees Invent?"の結論の中には次のように述べられています。

(組織を)設計するマネージャーが自身の組織をリーンかつ可変に保つことに対して、報酬を与える方法を見つけなければならない。
Ways must be found to reward design managers for keeping their organizations lean and flexible.

コンウェイの言っていることは、「逆コンウェイ戦略」を射程に入れつつ、それ以上のことを言っています。つまり、一度の変更をするだけではなく、複数回の変更が出来るようにすること、そして、その状態に保つことへの報酬を組織設計・評価設計に含めることを述べています。

もちろん、アーキテクトが組織設計に責任や権限を持つことはほとんどないでしょう。しかし、少なくともアーキテクトはシステム・プロダクトの次元において、組織の変化に対応できるようにしておかなければなりません。部分最適でも全体最適でもなく、変化への対応として最適なシステム設計、つまりは「構え」を提供し続けなければなりません。これが、私の考えるアーキテクトの仕事です。

変化に対応できる「構え」を提供し続けられるようにするのがアーキテクトの仕事であるとするならば、今回述べた組織とコンウェイの主張についてのみならず、ビジネス、人、技術、これらの変化への対応もまた、アーキテクトの仕事で、それらをケアしているはずです。

そうだとするならば、アーキテクトの認知空間や情報空間はどうなっているのでしょうか? そして、アーキテクトを取り巻く環境はアフォーダンスという観点からはどうなっているのでしょうか? これらの疑問は純粋に認知として興味が抱けます。

また、一方で、アーキテクトが扱う記号やモデルは、企業や開発の文脈では、ある種の世界観を提示するもので、その世界観を周囲の人達は受容し、理解し、その実現に向かいます。これはアーキテクトに対して求められていることの1つでしょう。他方で、それがうまくいかないケースもあります。この差異が一体どうして生じるのか、ということは、モデル論の哲学としても興味深いです。

Philosophy of Software Architectureに対する私の興味・関心は高まりつつあります。もはや、取り憑かれつつあります。これからもっと深く探求したく、私は思っています。

それでは、

青を心に。

Stephen S. Hanada

"Gentleman Philosopher"

 「知の前駆者」の真正の記録を配信する"Weekly Newsletter from Stephen S. HANADA"を登録してくれてありがとうございます。
 メールアドレスなどの変更が必要になったらPreferencesから変更できます。もうメールを受け取りたくなくなったら、Unsubscribe もできます。
Shimoochiai, Shinjuku, Tokyo 98104-2205

Gentleman Philosopher

I'm a developer, entrepreneur, and writer who loves to talk about business & entrepreneurship, philosophy, and technology. Subscribe to my newsletter.

Read more from Gentleman Philosopher

From: Stephen S. HANADA Shinjuku, Tokyo Sunday, 11:47 a.m. English letter follows japanese. 親愛なる友人へ、 いかがお過ごしですか? 私がどのような人なのかを表現する言葉は人によってだいぶ異なります。思想が強い人、人を大事にする人、よく分からない人、哲学を実践している人、冷酷な人。 そして、私はそれらの言葉に対して動じることはありますが、しかし、「その言葉で以て、他人の心や行動を支配しようとしていないだろうか?」と口に出して問いかけたり、心の内に留めたりします。しかし、残念なことに、この問いかけやその姿勢自体が、私のことを「冷酷な人」と表現する人にとっては、「冷酷」なのでしょう。なぜなら、私はその人や、その人がやろうとしている評価関数や評価の順序の捻じ曲げの試みに、同調しないからです。...

From: Stephen S. HANADA Shinjuku, Tokyo Sunday, 11:05 a.m. English follows Japanese. 親愛なる友人へ、 いかがお過ごしですか? Gentleman Philosopherである私の平日日中の仕事の一つには、Engineering Managementがあります。教科書的に言えば、この仕事にはいわゆるPeople Managementが含まれています。経験学習を促進したり、フィードバックを提供したり、コーチングをしたり、と色々なものが要求されています。そして、その業務に携わる中で、社内においても社外からも、「チームメイトのモチベーションをどう維持するか、高めるか」といったことが問われることがあります。私はそのような業務や問いに対して、イライラした感情を向けてしまいます。というのも、次が私の結論だからです。 「モチベーション」という概念は脆く、そして、あったとしても無力。 そして、「モチベーション」が問題になっている時、それを語る意味はない。...

From: Stephen S. HANADA Shinjuku, Tokyo Sunday, 12:22 p.m. Remark: English Letters are Below 親愛なる友人へ、 いかがお過ごしですか? 「2026年から2027年で、根本的により有能な(capable)モデルが登場する」 「2030年の終わり(the end of the decade)までに、50%の確率で、AGIレベルのシステムが登場する」 世界経済フォーラム、通称ダボス会議で、AnthropicのCEO、D. Amodeiは楽観的な発言をし、DeepMindのCEO、 D. Hassabisは慎重ながらも楽観的な発言をしていました。他方、エンジニアたちは、生成AIの登場当初と比べて多少落ち着いたとは言え、一定数が困惑を覚え、エンジニアもエンジニア以外の人達も多くが、今後の自分のキャリアについて悩んでいます。...