[8/5] アジャイルなアーキテクチャ。またはそれを作る人とプラクティス：Agile2013 レポート(2)

• セッション：Why We Need Architects (and Architecture) on Large Scale Agile Projects
• スピーカー：Rebecca Wirfs-Brock
  • Web：Wirfs-Brock Associates
  • Twitter：@rebeccawb

『オブジェクトデザイン』というオブジェクト指向方面で有名な本を書いているRebecca Wirfs-Brookさんのセッション。アジャイルでは、アーキテクチャないしアーキテクトをどう捉えていくかという話。

アジャイルというとケント・ベック方面の創発的設計がクローズアップされすぎて、「最初に設計しない」と捉えてしまう人がいるようだ。いや、あとで変更できるようにするにはそこそこ考えて設計しておかないと後で死ぬよ、ということが身にしみている人も多いのではないかと思う。レベッカさんはパターンコミュニティの人でもあるので、「あたりまえの、よいこと」を上手に言葉として抽出してくれるのではないかと期待している。

Rebecca Wirfs-Brookさん

■プロジェクト規模とアーキテクチャの必要性

アリスター・コバーンは、プロジェクトのクリティカルさ（どれくらい致命的な危険性があるか）とグループのサイズで分類した。小さなチームとは、6-8名で、生命に関わるような危険性がないシステムに従事し、アーキテクチャは実装しながら進化する（その間、大きな危険がない）タイプのチーム。

アリスター・コバーンの分類

■まずは小さなチームについて考える

小さなチームではさまざまなプラクティスが使える：

• 設計スパイク：CRCカード、探索的コーディング、ホワイトボードでのスケッチなどを使って数時間から数日で設計を行う
• ブランチでの実験：メインのコードブランチとは切り離して実験を行う
• 漸進的抽象化：リファクタリングで冗長なコードを取り除く
• 技術的負債の管理：実装を進める上で得た新たな知見をコードにフィードバックしないと、積み上がっていく。ウォード・カニンガムが考案した言葉

小さなチームの場合は、チーム全体を巻き込んで主要な課題に取り組み、ふりかえりで前のやり方よりうまくいったかどうかを問う。アーキテクチャを常に心に留め、技術的負債を取り除く。

小さなプロジェクト

■大規模の場合

9人を越えるチームは複数のグループに分割するべき。そうするとグループ間で仕事の調整が必要になる。システム全体を知っている人がいなくなる（専門性の違い、スキルの多様性、専門家）。アーキテクチャは「自然と」組織構造に従いがちになる。

プロジェクトのリスクの主なものは、

• スケジュール＆予算
• オペレーション（実行、リソース、コミュニケーション）
• 技術的（複雑過ぎる、定義不足、誤解）なもの

リスクを管理する方法は

• 避ける
• 共有する
• 見込んでおく
• 減らす・和らげる（継続的統合）

大規模の場合

■アジャイルアーキテクチャ

最も決定すべき時／責任を負える時点（The most responsible moment）で決定する。

Yoder と Foote の共有レイヤー。変化が遅い部分から最も早い部分まで並べた。プラットフォーム、インフラ、データスキーマ、標準フレームワークとコンポーネント、抽象クラスとインタフェース、クラス、コード、データ。

アジャイルアーキテクチャではこの階層を意識する。変化しやすいところがどこかを理解し、安定した部分から変化するところを早く切り離す。難しくて時間がかかるところと、簡単にできるところを分ける。設計しすぎないが、アーキテクテャを無視しない。アーキテクトは継続的に機能と顧客価値を開発し、届ける。

技術的負債と同じように、アーキテクチャ的負債がある。分割ができていなかったり、解析するのに時間がかかる、など。
これを減らすには、

• プロジェクトロードマップを明らかにすること
• 着地点を明らかにすること
• リスク低減バックログ
• セットベース設計、など

Yoder と Foote の共有レイヤー

■プロダクトロードマップとランディングゾーン（着地点）

プロダクトロードマップは、どの機能をいつ作るのかを相対的な時間で表現する。いつ頃、機能が必要になるか？それがアーキテクチャを作る作業に影響する。

また、プロダクトのランディングゾーン（着地点）として、最低限・目標・大成功の３段階を考えておくとよい。主要なシステムの受入条件を数値化する。

よいランディングゾーンの受入条件は「SMART」。

• 具体的（Specific）
• 計測可能（Measurable）
• 達成可能（Achievable）
• 関連がある（Relevant）
• タイムリー（Timely）

機能/ストーリーの受け入れ条件と違い、本番やステージングでの数値的条件を記述する。
アーキテクチャの中で高いリスクを持つ項目を明らかにし、対象の数値について予測値と実測値をとる。アーキテクチャ上のトレードオフとコストを説明可能にし、アーキテクチャが健全かどうかを計測する。後発的設計に対しても再調整し、プロダクトオーナーやステークホルダーと握っておく。

ランディングゾーン受入条件

■アーキテクチャ・スパイク

XPのスパイクと同じように、アーキテクチャでもスパイクがある。プロトタイピング、設計を大づかみに把握する。類例をみる、実験、モデリング、アイデア検証。実現性や妥当な設計手法、代替手段などの情報を得ることに投資する。その結果、見積もり精度が向上し、すべきことが明確化する。

アーキテクチャ・スパイクは、

• 少人数のゴール指向のチームで行う（こちらとあいつら問題を避ける）
• エビデンスをとる（実行可能プロトタイプや既存の類例を使って）
• タイムボックスを決めて行う
• スパイクが失敗することも可能性として許容する

アーキテクチャのスパイク

■アジャイルアーキテクトにとって大事なこと

設計するがやり過ぎないバランス感覚、アーキテクチャの品質を検証可能にしておくこと。プログラミング、設計、コードを読む、その他ものづくりに関わることは、自分で手を動かして確認し続けること。必要に応じてモデルを作る。モデルを作るプラクティスの一つが、CRCカード。インデックスカードを使ってクラスと依存関係を書き出していく。

■まとめ：持続可能なアーキテクテャへ

持続可能なアーキテクチャにするためには、アーキテクチャ的負債を最小限にする。つまり、必要なときに変化できるような状態を保つということになる。また、アジャイルでは最終責任時点まで決定を遅らせるというプラクティスがあるが、最も責任を負える時点で決定する、と考えた方がよい。システムを、ユーザーにとっても開発者にとっても「住みやすい（livable）」ものにし続けたい。

■感想：ロードマップと、ほどよいアーキテクチャ設計がリスクを減らす

設計が徐々に浮かび上がってくるというXPの思想に対し、複数チームで調整が必要な規模になるとアーキテクトによる設計が有効という立場で、アーキテクトはビジネス価値にも貢献するということなので、基本的にはスプリント0でプロダクトオーナーシップの一部として検討され、その後で継続的に見直されるものかと考えられる。

ロードマップと着地点というアイデアは、プロダクトのマイルストーンと同じと考えられるが、ロードマップはアーキテクチャを組み上げる順番に影響し、着地点は非機能要件をあらかじめ考えておいてトレードオフを明らかにしようということだ。これは、たぶん多くのプロジェクトでふつう、検討されているものだと思うが、改めて言葉して整理することが重要だと感じた。

UXの観点とアーキテクチャの観点で予めマイルストーンを組むことで、ビジネス側にとっての選択肢が検討可能になる。作成に時間がかかるようだと使いどころは難しいかもしれない。冒頭に述べられている通り、小さなプロダクトで明確にこれをやるのは不要だろう。

これをしっかりやると、ウォーターフォールと見分けがつかなくなる気もするが、「一定以上の規模はウォーターフォールで」と思考停止するより、どういうことが必要になるのかを具体的に考えることが大事だと思う。

• Blog：kawaguti の日記　(id:wayaguchi)
• Twitter：@kawaguti
  
• 川口 恭伸さんのレポート：http://www.manaslink.com/yasunobu-kawaguchi

もっと知りたい！Agile2013

• Agile2013
  
• #Agile2013
• 小沢 仁さんの連載：Agile2013の歩き方
  
• Agile2013 レポートコーナー