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


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, 12:36 a.m. 親愛なる友人へ、 いかがお過ごしですか? デイリースクラムの最後の締めの挨拶として「今日も頑張りましょう」といった言葉を使うことはしばしばあります。私も使っていました。しかし、ある日から私はその言葉が使えなくなりました。 「頑張ろう」という言葉が口から出なくなったのです。 どうやっても、「頑張ってください」、「頑張れ」、「頑張ります」という言葉を出そうとしても出ないのです。途中まで言えても、「頑張…」と口が動かなくなります。そして、続いて口から出てくる言葉は、 「頑張らない」 です。「頑張らないでください」、「頑張るな」、「頑張りません」という言葉が出てきます。自分の口から出る言葉だけではなく、他人の口から出る「頑張る」という言葉に対しても私は違和感を抱いてしまいます。 これは、私の心が病み始めたからなどでは、決してありません。むしろ「頑張る」という語の原義に立ち返ることが出来たからです。...

From: Stephen S. HANADA Shinjuku, Tokyo Sunday, 12:40 a.m. 親愛なる友人へ、 いかがお過ごしですか? Kiro、Antigravity、GitHub Copilot、Grok、これらを用いて、ボードゲームの戦略を作り、シミュレーションを実行するために、私は個人開発をしていましたが、そんな中にあって、私は自分の行為に疑問を抱き、嘆きました。 「こんなことのために、 貴重な資源を使っていいのか?」 Issueを作り、CopilotとAntigravityに実装させ、テストさせ、それぞれで出されたPRをGrokにReviewさせ、良い方を採用し、シミュレーションとその結果をAntigravityに実行させる。KiroにSpecから作らせて、後はポチポチとボタンをクリックするだけで済ませることも、別レポジトリでやっています。 しかし、その裏には何があるのでしょうか?...

From: Stephen S. HANADA Shinjuku, Tokyo Sunday, 12:11 p.m. 親愛なる友人へ、 いかがお過ごしですか? 「経済学に科学的モデルはない! 予測もなければ説明もない!」 友人たちとの会話の中で、そのような話が出てきたことを私は記憶しています。 確かに、経済学者の語る予測が当たることも少ないですし、起きている事象の説明もあまり有効ではないように見受けられます。もちろん、経済活動というのは人間の信念や行動、そして、組織、行政、気候も関わりますから、予測も説明も困難かもしれません。しかし、科学的なモデルとして期待しているほどのものは提供されていない、と感じてしまうのは、一定の納得感があります。 しかし、それは経済学だけでしょうか? 物理学や生物学でも予測や説明に失敗することはあります。生物学で言えば、そもそもは記録がメインなところが多い学問です。そして、物理学でも、飛行機が飛べる現象や原理の説明も、結局は飛んでいることをそのまま記述し直しただけであり、説明とは言えないものでしょう。...