この記事は、Simon Brown氏による、”Do you have a terms of reference for the software architecture role?”を、ご本人の許可を得て翻訳したものです。*1

This article is translated from

”Do you have a terms of reference for the software architecture role?” written by Mr. Simon Brown, with his permission.

---

多くのチームがやってないんだろうけれど…ちゃんと決めておくべき。

私たちがソフトウェア開発のチームに関連付けている多くの役割は、比較的理解しやすいものだ。開発者、テスター、スクラムマスター、プロダクトオーナー、ビジネス・アナリスト、プロジェクト・マネージャーなど。ソフトウェア・アーキテクトの役割はどうだろう？あまり理解しやすいものではないだろう。私は開発チームに対し、ソフトウェア・アーキテクトの役割について取り決められているかを尋ねることにしている。そして普通、回答は「いいえ」か、「はい、でも使ってません」というものだ。しばしば、同じチームの人々でさえ、異なった答えを返すだろう。

通常、ソフトウェア・アーキテクチャを考えることの必要性は認識されているものの、ソフトウェア・アーキテクトの役割に対する責任は明確でないことが多い。私の経験では、これは誰もその役割を引き受けなかったり、役割を引き受けたとしてもどのように引き受けるべきかを理解してなかったりという状況を引き起こす。もし役割が理解されなければ、実行することもできないし、未来のソフトウェア・アーキテクト育成の望みも殆どない。

あなたがそれを何と呼ぼうと（アーキテクトだったり、テクニカル・リードだったり）、私のアドバイスはシンプルだ。もし役割に対する共通理解が無いのならば、チーム内で共通の理解を行うことからはじめること。役割がどんなものかの簡単な開始点を提供しよう。役割については、私の本やInfoQ.comでも取り上げている。

他のやり方は、ワークショップやゲームストーミングで、協力しながら定義を行うというものだ。QConロンドン2012のチュートリアル”あなたはソフトウェア・アーキテクト？”での写真は以下の通りだ。

現実性のあるものとするためにも、どのような役割の定義だろうと、あなた自身の文脈に基づいていることを確認すること。そして、チームにおいて役割がどのようなものであるかを理解したなら、組織を超えた一貫性を達成できるかを考え始めることができる。これは必要／望ましいものかもしれないし、そうでないかもしれない。

（訳注：「私は上級開発者です。最近、アーキテクトに昇進しました。どのツールやソフトウェアに習熟すべきか教えてもらえますか？」）

役割に関して共通理解を作り上げることは、上のような質問や、ソフトウェア・アーキテクトが隙間に陥ってしまう状況を避けることに役立つだろう。　

---

（翻訳者のコメント）

原文では、Software Architectureだったのですが、文脈上ソフトウェア・アーキテクトと訳しました。

アーキテクト系の研修に出ると、「アーキテクチャって何？」と「アーキテクトの役割は？」という問いかけから始まることが多いと思います。なんとなくアーキテクチャという用語を理解したようであっても、改めて問われると回答が難しいものです。

やはりプロジェクトのチーム内では、（呼び名は何であれ）アーキテクトの役割を定義しておくのが大事です。自分の経験では、アーキテクトの役割が明確に決まっていないプロジェクトでは、システムのアーキテクチャそのものが軽視されていることが多かったようです。

また、アーキテクトの役割に「要件の理解」や「コーディング」、そして「デリバリーを通じてのアーキテクチャのオーナーシップ」が入っている点、まさにその通りだと思います。