Microsoft AustraliaのソリューションアーキテクトであるTom Hollander氏は、TechEd Australiaでアジャイルチームにおけるアーキテクトの役割と題したプレゼンを行った。 氏はこの場でアジャイルチームを率いるアーキテクトとして氏が行っていることについて議論した。
アーキテクトの役割について話すとき、氏が指すのは“ソリューションアーキテクト’、つまりアプリケーションのアーキテクトだ。エンタープライズアーキテクトやある種の専門家(例えばメッセージングやインフラなどの専門家)を指してはいない。
氏のチームは、最後に2、3日のコード凍結を行う、安定した4週間のイテレーションプロセスで、毎日のスタンドアップミーティングや毎日のビルドと自動テストが伴う継続的統合を実践している。氏のチームでは次のような役割を採用している。
- PjM – プロジェクトマネージャ。スクラムマスタに似ている。チームがプロセスに確実に従うようにする。
- PdM – プロダクトマネージャ。顧客、プロダクトオーナとしても知られる。どのような製品にするかを決める。
- アーキテクト – ソリューション/アプリケーションアーキテクト
- Dev – 開発チーム
- テスト – テストチーム
- UX – ユーザエクスペリエンスチーム
- リリース – ビルドとリリースを行う役割。ビルドプロセスの面倒を見る
氏はソリューションアーキテクトがアジャイルチームで成功するための下記のトップ10項目を挙げる。
- “過不足のない”事前設計 – とても小さいシンプルなプロジェクトを除いて、ある程度の事前設計が必要だ。それは1、2週間の間にアプリケーションのタイプに基づいて行われる。例えば、ウェブアプリなのか、スマートクライアントか、モバイルアプリかバッチか、基本的な機能要求は何か、長い期間がかかるソリューションか、すぐできる一時的なプログラムか、というようなことだ。事前設計の目的は、どんな技術を使うか決めることだ。例えば、ASP.NETにするのか、それともMVCにするのか。そして、どんな方式のアプリケーションにするのか決めることも目的だ。例えば、2層にするのか、3層にするのか、サービス指向アプリケーションにするのか。データアクセス部分も同様に方式を決める。ストアドプロシージャか、Entity Frameworkか、それともLINQやDIを使うのか。これらすべてのことを後で参照するために短いドキュメントでまとめてもよい。
- 縦割りスライスから始める – 一部の機能、例えばログインページのような各レイヤが可能な限り分割できる機能から実装を始める。これは前段で採用を決定したすべての技術を結びつけるためだ。こうすることで設計上の決定の正しさを実際に確かめられる。また、開発者向けにこれからの開発の手本になるパターンを示せる。最初の設計が不適切だとわかったら、このタイミングで修正するのがよいだろう。
- イテレーションごとのジャストインタイム設計 – 4週間のイテレーションの中間で、プロジェクトマネージャとプロダクトマネージャ、そしてアーキテクトは次のイテレーションで扱うべき要求について議論する。すべての要求についての考えを擦り合わせ、重要な要求の優先度を上げ、すべての要求について理解するためだ。この会議は現在のイテレーションの裏で1週間くらいかけて行われる。そして、現在のイテレーションの最終週である次の週には、アーキテクトは次のイテレーションの要求をレビューして、チームが次の週から作業を開始できるように設計上の決定を行う。要求が以前のものとかけ離れていたら、アーキテクトはプロトタイプの実装を行って、概念を証明するためにコードを書き、図で示してそれを5ページほどの参考文書としてまとめる。この作業は開発者のために詳細な設計上の決定を行うのが目的ではない。むしろ、新しい要求が全体像の中に調和することを確かめるためだ。
- チームを信頼しつつ、チームのためにそばにいる – これはアーキテクトと開発者の関係に関わる。アーキテクトは役割以上に動き回って開発者から意思決定する喜びを奪わないように注意する必要がある。また、アーキテクトはチームにとって指導者であり、開発者が行き詰まるような難しい問題を解決しなければならない。アーキテクトは毎日、すべての開発者と連絡して、どんな作業をしているのかを把握し実装上の問題があるのなら手助けをするべきだ。特に助けを求めるのを好まず、まるまる1週間かけて自分の力だけで問題を解決しようとする開発者に対応する場合は細かく連絡をとる必要がある。開発者とのこのような関係はPjMやテスト/ビルド/リリースチームとの関係にも適用される。
- コードを書く! – アーキテクトはコードの中身がどうなっているか把握するべきだ。これは自分自身の決定についてより良い考えを持つためだ。またコードを見ることでリファクタリングが必要な時もわかる。コードを書くアーキテクトは開発チームからの信頼が厚い。しかし、そうはいっても氏は役割がなし崩しになるとは考えていない。アーキテクトはあくまでアーキテクトのままであり、普通の開発者と同じようにコードを書く必要はないと考えている。
- すべてに関与する – 設計、開発、コードレビュー、要求計画などのプロジェクトに関連するすべての会議に出席することはアーキテクトにとって良いことだ。そうすることで進んでいる物事について幅広く明確な見取り図が得られる。そして、想定される結果を伝えることで、プロダクトマネージャが間違った決定を下すのを早い段階で阻止できる。
- 文化の質を向上させる – 誰もが参加したいような成功するチームは上質な文化の上に構築される。誰もが手を抜かず、いい加減なコードをチェックインしないチーム、設計上に大きな欠点があっても見逃さずに誠実で開かれた態度でチーム全体で最高の結果を出す方法を探すチーム。このようなチームを構築するのは難しいということは氏も認める。しかし、実現は可能だ。まずはアーキテクトが最初の段階でいくつかのルールを決める。このルールは時間が経っても変わらないルールにするべきだ。開発者がルールを嫌いにならないようにするためだ。例えば、単体テストのコードを書くという決めごと、または、アーキテクト自身のコードを含むすべてのコードをチェックイン前にレビューするという決めごとでもいいだろう。レビューアーにコードが受け入れられなかったら、チームの誰であろうとコードはチェックインできない。
- 変更が要求された時を把握する – アーキテクトはとても柔軟で必要に応じて設計変更ができるようにする必要がある。初期段階のソリューションはもはや適切でないかもしれないし、新しい要求には別の手法が必要かもしれないからだ。
- 外部のランダム化からチームを保護する – これは通常はプロジェクトマネージャ/スクラムマスタの仕事だが、チームが集中力を乱し、実作業の時間を奪いそうな外部の要求からチームを守るのはアーキテクトも行ってもいい。例えば、ある特定のことをある特定の方法で実行したい運用チームからあがってくるさまざまな要求は、いつも妥当であるとは限らないし、障害になる場合もある。
- 誰かが読む文書だけ作成する – 氏はすべてを文書するというという考えも、全く文書を書かないという考えも採用しない。バランスをとって誰かに読まれる、本当に役に立つ文書を作成する、というのが氏の考えだ。データモデルのような設計上の決定の細部を記録するには文書が好適だ。イテレーションの始めにチームとともに議論することで設計が決まるが、この内容を5ページくらいの文書にまとめるのが推奨される。これはアーキテクトの発言を覚えていない開発者がいる場合のためであり、また、初期開発者とアーキテクトが別のプロジェクトへ移行したずっと後になってプロジェクトに参加する開発者が設計上の決定の理由を理解するためでもある。
氏は、アーキテクトは自分自身が実践上も理論上もチームの一部分であるということを確認するべきだ、結論づけている。アーキテクトはすべてのコードを書くわけではない。一部分だけだ。テストは配置をするわけではない。むしろアーキテクトの役割は全体のプロセスが確実に首尾よく進むようにすることだ。