アーキテクチャーオーナー

上の図でおわかりいただけるように、DADの基本的な役割はスクラムのものと似ている。スクラムでは、プロダクトオーナーは何をどの順番で構築するかを決定する。DADではアーキテクチャーをプロジェクトリスクの重要な鍵とし、チームがこれらのリスクに確実に対処することに責任を負う何らかの役割が必要と考えている。結果としてDADプロセスフレームワークには、アジャイルモデリングの役割であるアーキテクチャーオーナーを明示した。アーキテクチャーオーナーはチームのアーキテクチャー上の決定を行い、ソリューション設計全体の構築と進化をファシリテートする役割である。チームリードの役割にあたるメンバーがアーキテクチャーオーナーになることも多いだろう。これは大規模開発ではあまりないが、小規模なアジャイルチームではよくあるケースである。

アーキテクチャーオーナーの責務は以下のようなものである。

  • チームが開発しているソリューションのアーキテクチャー構築/進化をガイドする。アーキテクチャーオーナーは、単にアーキテクチャーに責任があるだけではなく、技術的な議論をリードする役割であることに注意すること。
  • アーキテクチャー上のプラクティスや課題について、他のチームメンバーに助言・指導を行う。
  • 組織のアーキテクチャー上の方向性や標準を理解し、チームがそれらを適切に順守できるようにする。
  • フレームワークやパターン、サブシステムのような企業内にすでに存在する資産を理解し、チームが適切にそれらを使えるようにする。
  • 技術的負債を最小限にするためによい設計とリファクタリングを奨励し、それによってソリューションのサポートが容易になるようにする。
  • ソリューションが定期的に、理想的には継続的インテグレーション(CI)のプラクティスによって、統合されテストされるようにする。
  • 最終的な技術的決定はしつつも、協調的にチームプレイでアプローチするため、アーキテクチャー的な方向性を「指示」することは避けようとする。アーキテクチャーオーナーは、チームリードと緊密に協力し、プロジェクトの重要な技術的リスクを軽減するための戦略を特定・決定する必要がある。
  • プロジェクト初期のアーキテクチャー検討をリードし、初期段階の要件検討を(特にソリューションの非機能要件を理解・進化させる点で)サポートする。

DADにおいてこのような役割を作っている主な理由のひとつは、作業項目一覧(スクラム用語でいうバックログ)に作業項目を追加し優先順位付けするにあたり、プロダクトオーナーと同様アーキテクチャーオーナーにも発言権があるという点である。確かにビジネス価値は優先順位を決定する際の主要な要因ではあるが、技術的リスクを緩和するための作業も同じように重要である。加えて、DADの目標は、単に動作するソフトウェアというだけではなく、使用可能なソリューションをデリバリーすることである。そのため、例えばエラーログや監視などの本質的に技術的な作業項目を追加することも必要になる。もしくは、継続的インテグレーション/デプロイのプロセスを改善するための作業項目を追加する必要もあるかもしれない。我々は、プロダクトオーナー・アーキテクチャーオーナー両方の概念があることで、使いやすさやサポートのしやすさのような機能要件・非機能要件の両方に適切に対処できることに気づいた。実際、私(原著者)の現在のプロジェクトでは、プロダクトオーナー・アーキテクチャーオーナーの双方と連携し、作業中のイテレーションに優先度の高いストーリーを入れるだけではなく、利害関係者にソリューションを提供する移行フェーズに入るための準備として、ソリューションを強化するための作業項目も含めるように、優先順位を交渉している。アーキテクチャーオーナーが役割として明確になっていなければ、作業項目一覧内で重要な技術的項目の優先順位を上げるのは難しいかもしれない。結果として、プロダクトオーナーの知識のみで優先順位付けが行われ、健全なプラクティスとならず、最悪の場合、低品質のソリューションに帰結してしまう。

スコット(原著者の一人)がアーキテクチャーオーナーの役割をより詳細に記述した良記事を書いているので、こちらもご覧いただきたい。

オリジナル:The DAD Role of Architecture Owner

The DAD Role of Architecture Owner


 (翻訳 中佐藤麻記子)

LINEで送る
Pocket