前置き

この記事はnealfordの記事の非公式の日本語訳になります。

原文は上記のリンクからご確認頂けます。

Architectural Katasとは

以下のやり取りに端的に示されています。

素晴らしいアーキテクト、素晴らしい設計はどのように得られるのですか？

                         Fred Brooks

自分のキャリアでせいぜい半分以下の時間しか設計を行わない人が、
どのようにして素晴らしいアーキテクトになれますか？

                         Ted Neward

このKatasというのは日本語の「型」を意味しています。
素晴らしいアーキテクトになるためには、設計の経験の数を積むのが近道ではある。ならば、ドリルのような形式でそれを体感することができればいいよね、ということでこのArchitectural Katasが産まれたようです。

ちなみにこのTedさんはアメリカでは有名なソフトウェア技術者で、大規模エンタープライズシステムの開発やアジャイル開発でアーキテクトとしてキャリアを積んでこられた方のようです。

Architectural Katasのやり方

Architectural Katasは3〜5人のグループ作業で行うことが前提になっています。
このプロジェクトチームを4〜10程度用意します。
それぞれのプロジェクトチームは制限時間内で別々のKataに取り組みます。

各プロジェクトチームには、開発を必要とするプロジェクト（多くの点で、提案のためのRFP-Request）が与えられます。プロジェクトチームは「顧客」（モデレーター）の質問をしたり、解決できる技術オプションについて話し合ったり、ソリューションを概観したりすることで、もとの提案にない要件を発見します。

その後、彼らがしばらく議論した後、プロジェクトチームは、そのソリューションを部屋の他のプロジェクトチームにプレゼンテーションし、質問に回答しなければなりません。その後、各プロジェクトチームがそのチームに対し投票を行い、次のチームがプレゼンテーションを開始します。

理解を深めるため、一つだけKataのサンプルを以下に記載します。

※このトレーニングではKataの内容は誰も読んでいない状態で始めるのが最適とされています。ここまでの説明や原文記事で理解できたという方はスキップしてください。

　サンプル

アジャイルデッドツリー

ある出版社が、彼らが持つ版権物のCMS(Content Management System)と顧客の店内での体験を統合し、できるだけ早く書籍を販売しようとしています。

ユーザ
数多くの出版社の従業員、何百人もの作者、何千/何百万の顧客
要件
- 著者は(本ではなく)章単位で原稿を書きます
- 編集者はこれを参照し、校閲し、校閲者に告知します
- 著者は校閲による変更を拒否することができます
- コピーや技術的な編集(原文:copy and technical editing)をサポートします
- 顧客はオンラインで書籍をe-formかdead tree形式で購入できます
- 「β版」を購入した顧客は、上記の著者の章を手にすることができます
背景
- 既に競合が類似の取り組みを行っていることから、このプロジェクトを行うことが決まった
- 著者の奪い合いの競争は非常に激しい
- これは、ビジネスの出版面を近代化するための長期戦略の一環です
- 書籍を発行するために必要な情報（流通、ロイヤルティ、マーケティング）は、電子メールによるExcelスプレッドシートから印刷施設とのメインフレームの統合に至るまで、さまざまなシステムから発生します

ルール

わからないことがあれば、ファシリテーターに聞くことが原則です。

プロジェクトチームを準備する

最初のステップは、あなたのプロジェクトチームを組み立てることです。
あなたのチームの構成に関するいくつかのルールがあります。

同僚や同じプロジェクトに従事している人とチームを組むことはさけてください。
文化が異なるチームの人と会話し、設計することもトレーニングの一環です。
他のプロジェクトチームとは離れた場所で作業してください。
PCは使わないでください。
メモ帳、ホワイトボード、フリップチャートなどの道具を活用し、議論を進めてください。
自分たちんのプロジェクトのモデレータ(顧客役、上司役、プロジェクトマネージャー役、ITオペレーション担当者役の人)の人を、あなたのチーム以外で確保してください。

これが終わったら、任意のKataを選び、ディスカッションを開始します。

ディスカッションする

任意の制限時間内で、プロジェクトチームは与えられたカタの要件を調べ、プロジェクトのアーキテクチャーを設計します。
モデレーターにプロジェクトについての質問をすることができます。モデレーターはあなたの顧客、上司、プロジェクトマネージャー、あなたのITオペレーション担当者です。基本的に、モデレーターはあなた以外の皆さんです。
採用する技術については問いません。要件にかなっているものがあれば、それを採用してください。ただし、なぜその技術を採用したのかという質問には答えられるように準備してください。仮に自分たちが習熟していないものでも、この前提が守られるのであれば問題ありません。
開発チームの技術力や、普段自分たちが一緒に開発している人たちと同程度を前提としてください。
プレゼンテーション中は、タイムキーパーがいます。残り時間が少なくなったら何がしかの合図を受けることができます。

ピアレビューを受ける

あなたの設計について、他グループへプレゼンテーションをします。

あなたの提案のビジョンを示してください。話者が決まってなかったらこのタイミングで決めてください。「簡潔さはウィットのキモ」(原文:brevity is the soul of wit)であることを忘れないでください。可能な限り簡潔に、短く話してください。必要であればモデレーターが顧客要件や顧客の声を説明してくれます。
他のプロジェクトチームからの質問に答えてください。ただしこれらの質問はプロジェクトに関するものであり、技術スキルに関するものではありません。あなたの今のスキルや人格攻撃ではないことを忘れないでください。プロジェクトが実施される前に、その欠陥部分を埋めること、見つけることに専念してください。
あなたがプレゼンテーションを聞く側であった場合、プレゼンテーションについて質問をしてください。建設的な質問をしてください。慎重に検討したり考えなかった可能性のある選択肢や決定については、自由に質問してください。プロジェクトチームは、その前提が明確に綴られていれば、よく知らない技術について何かを引き受けるかもしれないことを忘れないでください。彼らがあなたが偽であると思ったものを仮定した場合は、是非そのことを知らせてください。ただし、部屋の誰かがあなたとは違う経験をしている可能性があります。

投票する

各チームがプレゼンテーションを終えたあとは、投票フェーズに移ります。モデレーターが「1,2,3」と言い、他チームのメンバーは親指を上げるか、横に出すか、下げるかします。

親指を上げる

あなたは彼らがそれを釘付けにしたと思った。彼らは明白な疑問のすべてに対して答えを出し、少なくとも信じられないほど実現可能な技術を選んだ。プロジェクトの明確なビジョンを持っている。
これはすべての答えがあることを意味しているわけではなく、UML図を作成しているということではなく、十分な時間をかけて作成できるという確信があることを意味します。

親指を横に出す

いくつかの考慮漏れがあるが、彼らが実際に何を構築しようとしているのか明確なビジョンを持っていると思った。顧客に聞くためのいくつかの重要な質問を忘れてしまった、彼らはプロジェクトの重要な側面を忘れていた、あるいは彼らはまさに彼らが本当に"持っていた"という気持ちをあなたに与えなかった。

親指を下げる

あなたはそれが間違っていると思った。彼らは決して顧客に何か質問をしておらず、結果としていくつかの悪い前提で時間を費やしてしまった。彼らはアセンブリ言語を使ってウェブサイトを構築することをお勧めしました。あなたはこのプロジェクトに取り組むことは決してありません。

しかし、すべてが完了していない！
投票が完了したら、古代クリンゴンの言葉に注意を払わなければなりません。「復讐は冷たい料理です。」ステージを去ったプロジェクトチームは次のプロジェクトチームを選び、新しいプロジェクトチームのピアレビューフェーズに戻ります。

モデレーターとして主催する

Architecture Katasを主催する場合、以下のようなことに留意する必要があります。
モデレーターであることは難しいことではありませんが、従わなければならない要件がいくつかあります。

あなたはArchitecture Katasの成り行きを座って見守る必要があります。

このルールの理由は簡単です。イベントの様子を全体的に感じることができ、その背後にある「バイブ」のことをもう少し理解することができます。

あなたは自分の頭で考えることができなければなりません。

モデレーターになることの大きな部分は、さまざまな"顧客"の質問に答えることです。Kataの内容はここではあまり役立ちません。そのように書かれているためです。柔軟性と解釈の余地が非常に広がります。それは、あなたの親愛なる司会者が、プロジェクトチームがこれまでに考えたことのない質問をあなたが聞いている間に、即座に回答を作りたいということを意味します（そして、ピアレビューフェイズ中に後で思い出します）。

ファシリテーションをするという意志がなければなりません

司会者の仕事の一部は、グループを迅速なクリップに沿って動かすことです。そのため、すべてのプロジェクトチームは、期限が切れる前にピアレビューフェーズを取得できます。（これは、私が、レコードだけのために、より良くなることを望んでいるものです。）また、会話が邪魔になるときに、会話をリダイレクトする必要があります。グループの議論が迷走したら、ここに正しい方向性を助言したり、ある程度の外交と精巧さが必要です。

あなたのグループは、サイト用の新しいカタが必要です

katasはコミュニティによって生成されるものほど面白くないので、「ライセンス要件」として、katasを実行しているグループがArchitectural Katas Google Groupに移動し、新しいKataのアイデアを提案するようにお願いします。

また開発経験があり、ソフトウェアアーキテクトとして少なくとも少し時間を費やしたことは理想ですが、正直言ってそれが絶対必要だとは思いません。

Kataを選ぶ

Kataはnealfordの記事の「List Katas」か「Random Kata」から一つ選び、これを実施してください。

終わりに

以上で翻訳は終了です。
このエクササイズはある程度の人数が必要になるため、積極的に広めていけたらと思っています。