このエントリでは、Yegor Bugayenkoによる記事、What Does a Software Architect Do?を紹介する。 (Yegorから和訳と転載の許可は得た。) 以下はその全文の和訳だが、意訳超訳が混じっているので、もとのニュアンスを知りたければ元記事を読んでもいいし、読まなくてもいい。

君のプロジェクトにはソフトウェアアーキテクトが居るだろうか? 必要だと思う?

まあ、ほとんどのアジャイルチームはそのような役割を明確には定義せず、民主的な感じで働く。 全ての重要な技術的な意思決定はチーム全体で議論され、最多数の投票を得た解決策が採用される。 しばらくして、このようなチームが「ソフトウェアアーキテクト」バッジを誰かのTシャツに付ける事に決めたときは、もっとも評判のいいプログラマがそのバッジを手にする。

このバッジが彼の責務を変えることはまれだけども。 結局、チームは同じように働き続け、全員を巻き込んだ技術的議論を楽しむ。 つまり、ソフトウェアアーキテクトは責務が明確に定義された役割というよりもステータスになる。 それは最年長で最も権限のある人へのチームメンバからの尊敬の印になる。そうだろ?

全く間違っている!

アーキテクトは品質の責任を負う

普通はアーキテクトは最も知識、スキル、経験、権限がある人がなるということは明らかだ。 もちろん普通はアーキテクトは他の人よりもものを知っていて、必要に応じて外交的指導的手腕を発揮してその知識を伝達する。 アーキテクトは普通はチームの中で最も賢いやつだ。

しかしこのことは、彼をアーキテクトたらしめているものではない。

そして、チームに必要なものでもない。

私のソフトウェアアーキテクトの定義こうだ。 アーキテクトは品質の責任を負う人だ。

「責任 (blame)」を職責 (accountability) とか 責務 (responsibility) と言い換えてもいいが、私は「責任 (blame)」という言葉を使うのがいいと思う。 なぜなら、開発中の製品の全ての品質問題がアーキテクトの個人的な失敗であることをより強調するからだ。 もちろん、その責任の対価として、品質がよかった場合には満足した顧客からの称賛は全てアーキテクトのものだ。

これがチームに必要なものだ。 開発するソフトウェアの品質に対して誰かが個人的に責任を負うのだ。

プロジェクトマネージャの仕事は、アーキテクトによる全ての技術的決定に対して誰にも不信を抱かせないようにすること

アーキテクトが他のメンバにどのように責任を委譲するかはアーキテクト自身の仕事だ。 知識やスキル、品質管理ツール、ユニットテストフレームワーク、権限、コーチング、体罰、何を使おうとも、それが彼の仕事だ。 プロジェクトマネージャは品質管理をソフトウェアアーキテクトに委譲した。 それをさらにどう委譲するかはソフトウェアアーキテクト次第だ。

ソフトウェアアーキテクトの役割は全てのプロジェクトにおいて重大だ。 たとえたった二人のプログラマが同じデスクで働いている場合でもだ。 二人のうち一人はアーキテクトでなければならない。

理想的なアーキテクトは上記の長所の全てを持つ。 彼は全員の意見を聞いて考慮に入れる。 彼はよいコーチであり先生だ。忍耐もある。 彼は効果的な伝達者であり交渉人だ。 外交官だ。 技術的な領域のエキスパートだ。

しかし、たとえこうした長所全てを持たなくても、彼の決定は常に最終決定だ。

そして、プロジェクトマネージャの仕事は、アーキテクトによる全ての技術的決定に対して誰にも不信を抱かせないようにすることだ。 これが委譲というものだ。 責任には常に権力が伴う。

プロジェクトマネージャは定期的にアーキテクトの成果を評価すべきだ。 チームで開発中の製品の品質はアーキテクトの個人的な(!)責任だということを思い出してほしい。 どんな問題であっても彼の問題だ。 彼を責めたり罰したりすることを恐れてはいけない。 ただし、罰を有効なものにするためには、アーキテクトの行動に対して全力で応えるべきだということをを忘れてはいけない。 繰り返すが、彼の決定は最終決定だ。

もしプロジェクトマネージャが製品の品質に満足せず、またアーキテクトがその状況を改善しないなら、アーキテクトを交代させる。 彼をプログラマに降格させ、他のプログラマをアーキテクトに昇格させる。 ただし、チームにアーキテクトは常に一人だけで、彼の決定が最終的なものであることを忘れてはいけない。

それが完璧な製品を作れる可能性をもつただ一つの方法だ。

以上がYegorの記事。

スタンドアップミーティングに関する記事でも言っていた責任の委譲がこの記事でも触れられている。 プロジェクトマネージャは技術的な責任を誰かに委譲して、そいつをアーキテクトと呼べということだ。 責任には権限が伴うので、アーキテクトは技術面での最終決定権を持つ。

それだけ。Yegorの他の記事に比べてシンプルな主張。 もう少し、アーキテクトが品質を確保するために何をすべきかといったことが書いてあると期待してたが。

責任を委譲してそれに権限が付随するのか、権限を委譲してそれに責任が付随するのか、という細かい疑問はあるが、この記事の主な主張に対しては特に何も言うことがない。