誰もがみんなアーキテクト(ただし、彼らがそうじゃないときを除いて)

この記事は、Simon Brown氏による、”Everybody is an architect, except when they’re not”を、ご本人の許可を得て翻訳したものです。*1

This article is translated from ”Everybody is an architect, except when they’re not” written by Mr. Simon Brown, with his permission.


単一責任点(Single point of responsibility)か、それともチームでの共有か?

私は、先週行われたQCon London 2011カンファレンスの”Software Craftsman”トラックで、いくつかの素晴らしいプレゼンテーションに参加した。それは、ソフトウェア・アーキテクチャがどのようにして現代のソフトウェア開発チームにフィットするのか、とても簡単に説明する方法を提供してくれるようなものであった。

誰もがアーキテクト

最初のGlenn Vanderburg によるCraft and Software Engineeringセッションは、物理的な建築とソフトウェア開発における、工芸と工学の関係と対立について調査したものであった。非常に面白いセッションなので、是非スライドをダウンロードするか、機会があれば見てみることをお勧めする。 私にとって、一つのわかった!(eureka)という瞬間は、彼が自身のエッセイであるExtreme Programming Annealedから引用した、この絵を示した時であった。大筋として、この図はXPのプラクティスが有効に働く規模を表している。

私は、共同所有権(collective ownership)の箇所を強調しておいた。そう、それはコードに関することであるが、共同所有権とは、チームの全員が、少なくとも基本的な”全体像”を理解していることを意味している。あなたの今のプロジェクトを考えてみて欲しい。あなたはコードベースの任意の場所を参照して、何が行われているかを理解することができるだろうか?

あなたのチーム・メンバー全員が、全体像を理解している、経験豊かなソフトウェア開発者チームからなるような場合を想像してみて欲しい。正真正銘の、実践的なアーキテクトからなるチームだ。このチームは驚異的で、あなたが通常ソフトウェア・アーキテクチャ(非機能要件や制約など)に関連付けるような関心事は全て対処され、何かが隙間に落ちてしまうようなことはないだろう。技術的な観点から言えば、これは自己組織化チームである。彼らは、流れの速い川をせき止める、何も逃すことのない頑丈なコンクリートのダムみたいだ。

ただし、彼らがそうじゃないときを除いて

自己組織化チームのアイデアについて、私にとって大きな問題なのは、実際のところそのようなチームをほとんど見たことがないということだ。これは、チームがプロジェクトごとに変わってしまい、特定の顧客のもとで数ヶ月以上を過ごすことがないような、コンサルティング環境で働くということの副作用なのかもしれない。もしくは、自己組織化チームというものは、非常にまれなものなのではないかと思っている。自己組織化チームであろうとすること自体は賞賛されるべきことである。ただし、ほとんどのチームはより大きな問題を抱えているのだ。私の最近のSoftware Project SOSセッションで展開されてきたような種類の状況が、この問題を暗示している。

2番目のセッションは、ギター演奏をする*2Roy OsheroveによるTeam Leadership in the Age of Agileであった。このスライドもダウンロード可能である。このセッションは、全てのチームが同じわけではないという事実を踏まえた上で、あなたがソフトウェア・チームをリードするために何をすべきかというものであった。Royはチームをシンプルな成熟モデルに分類している(詳細は、The 3 maturity stages of a software team and how scrum fails to identify themで見ることができる)。 成熟に関する3つの段階は、混乱的、学習中/成熟中、自己組織化/成熟である。本質的に、各成熟度に応じて、異なったリーダシップのアプローチが要求される。

私が上に述べたように、全員が経験豊かなソフトウェア開発者/アーキテクトであるようなチームは素晴らしいが、私はそのようなチームを見たことはない。意味を成さないコードベース(大きな泥玉)、不明確な設計、遅いシステムなどからも明らかなように、多くのプロジェクトでは、誰もがこの”全体像”に関する経験があるわけではないのだ。私はこのような状況を多数見てきた。私は、技術的な観点から言って、チームにソフトウェア・アーキテクトの役割に責任を持つ人間を、一人置くことを推奨する。Royもまた、多くのチームが混乱的な段階におり、早い段階でのより直接なリーダシップのアプローチが必要だと主張している。

あなたがチームのリーダシップ、もしくは技術的なリーダシップ、いずれのことを言及する場合であっても、原則は同様である。混乱的なチームは、流れの速い川を、小枝の束で堰き止めようとしているようなものだ。つかの間は水の流れを緩めることができるだろうが、すぐに非効率になってしまい、現状維持で精一杯になってしまうだろう。早い段階でのより直接的なリーダシップのアプローチは、あなたが見えないものを示し、早急に埋めるべき穴に対する、確かな助言を可能にするだろう。

アジャイルなプロジェクトは、今もなおソフトウェア・アーキテクチャを必要とする

残念ながら、多くのチームが”全体像”に関する技術スキルを、本質的な補完物というよりは不必要な悪とみなしている。これはおそらく、過去に彼らが”事前の大規模設計”(BDUF:Big Design Up Front)によって、苦しめられたことがあるからだろう。また、ある人々は”アジャイル”であることを強く望みすぎて、ソフトウェア開発プロセスにおける他の面を無視してしまう。 自己組織化チームよりむしろ混乱的なチームが、より直接的なリーダシップのアプローチの必要性に挑戦的だ。 結局のところ彼らとって、アジャイルであろうと努力することと、技術的な面に関して単一責任点を持つことは、アジャイルチームとしてのあるべき姿と矛盾してしまっているのだ。この矛盾は人々に、アジャイルとアーキテクチャは反発しあうものであり、どちらか一方しか選択できないと考えさせてしまいがちなのである。アジャイルと反発するのは、アーキテクチャではなく、BDUFなのだ。

重要事項を優先しよう。アジャイルなソフトウェア・プロジェクトは今もなおアーキテクチャを必要とする。なぜならば、扱いが難しい懸念事項や、複雑な非機能要件、制約が無くなってしまったわけではないからだ。異なるのは、アーキテクチャの役割を実行する方法だけである。

Royが彼の話の中で言っているように、自己組織化チームは専門のScrumマスターを必要としない。同じように、専門のソフトウェア・アーキテクトも必要としない。 コードの共同所有権により、全員がアーキテクチャ・レベルで働くことができるため、全員がアーキテクトである。 しかしながら、自己組織化の段階でないチームが急ぎすぎると、苦しむことになる。 アジャイルであろうという人々の熱意にもかかわらず、コードの共同所有権やアーキテクチャの役割の分配は、混乱的なチームにとっては助けになるよりも妨げになりそうだ。混乱的な段階にあるチームは、より直接的なリーダシップ・アプローチを必要とし、ソフトウェア・プロジェクトの技術的な側面においては、単一責任点から利益を得ることができるだろう。 他の言い方をすれば、彼らはソフトウェア・アーキテクチャの役割を果たす一人の個人から、利益を得ることができる。理想的には、彼が他人をコーチすることで、コーチされた人がこの役割を助けることができるようになる。

一人のソフトウェア・アーキテクトか、複数か?単一責任点か、チームでの共有か?アジャイルであろうとなかろうと、ソフトウェア・アーキテクチャの役割は存在する。状況だけが、あなたに正しい答えを告げるのだ。


(翻訳者のコメント)

全員が優れた開発者であったり、アーキテクトであったりするチームは素晴らしいと思います。ただ、現実のプロジェクトでは様々な制約により、このようなチームが実現することはほぼ無いでしょう。僕個人も、残念ながら自己組織化の段階にあるようなチームで働いた経験はありません。自己組織化の段階に到達していないチーム(つまり、現実のほとんど全てのチーム)では、ある程度中央集権的なリーダシップの方が効率的だという意見は、頷けるものがあります。

*1:原文公開日:2011年3月14日。

*2:Youtubeなどで彼の過去のプレゼンを見たところ、プレゼン中にギターを演奏することがあるようです。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です