やったこと

• Design It! 13章 チームのアーキテクト力を強める 読了

学んだこと

ポイント

• 現在、アーキテクトに求められる役割、仕事
• なぜ、チームのアーキテクト力を強める（高める）必要があるのか
• チームのアーキテクト力を強める（高める）ために何ができるか

学び

• 現在では、チームのアーキテクト力を強める（高める）ことが求められる
  • チームを成長させ、価値を生むアーキテクチャを設計できるよう導くことが、アーキテクトに求められる
• チームのアーキテクト力を高めると、以下の効果がある
  • チームに、「自分たちのシステム」という意識が芽生え、以下の効果が得られる
    • 皆が設計の意図を理解でき、設計の一貫性を保ちやすくなる
    • コミュニケーションが効率化される
  • アーキテクチャを批評できる人間が増え、以下の効果が得られる
    • 品質が向上する
    • 設計判断が早くなる
  • などなど
• チームのアーキテクト力を強める（高める）ために、アーキテクトは以下を実施できる
  • チームに、「自分たちのシステム」という意識を持ってもらう
  • 「自分たちのシステム」という共同所有意識を持ってもらう
    • そのために、チームメンバに多くの学習と成長の機会を与える
  • チームの成長度合いに応じて、適切に権限を委譲していく
  • アーキテクチャを協働で設計する

メモ

現代ではコンテナやクラウドの台頭により、様々な技術を手軽に利用できるようになった。
私たちは、これらの技術を使用して、強力なアーキテクチャを構築できる。
同時に、私たちは、様々な技術の中から、自分たちの問題を解決できるものを適切に選択できる必要がある。

現在、開発者とアーキテクトの違いは希薄になっている。
アーキテクトに求められ得る役割は、以下のように変化している。

• 従来 : トップダウン型のリーダー
• 現在 : 一緒に設計でき、チームの能力を向上させることができるリーダー

そんな現在のアーキテクトは、コーチであり、メンターであり、技術の第一人者である。

アーキテクチャを理解しているメンバーが増えるほど、チームは難しい問題へ取り組むことが可能になる。
こうした理解は、システムを共に設計することによって生まれてくる。

この章では、チームを成長させ、力を与える方法に触れていく。

アーキテクチャ思考を促進する

メンバー全員がアーキテクチャに関心をもち、アーキテクトであろうとするチームは、以下の恩恵が得られる。

• ソフトウェア品質が向上
  • ソフトウェアを批評できる人間が多いほど品質が向上する、という意図
• 迅速な設計判断
• 共同所有意識が高くなる
  • => 「自分たちのシステム」という意識が芽生える

「自分たちののシステム」という意識が芽生えた結果、誰もが設計の意図を理解でき、設計の一貫性を保ちやすくなる。
コミュニケーションが効率化され、開発のベロシティも向上する。
メリットは非常に大きい。

大まかな方針は、「チームの設計スキルを高めながら、同時にそれを使ってアーキテクチャを設計していく」こと。
これを実現するため、チームが順調に進む手引きを行い、学習と成長の機会を与える。
（設計判断を全部監視したりしない）

意思決定を促し、スキルの成長を促進する

共同所有意識を高めるには、チームに学習と成長の機会を与える。

普通のソフトウェアアーキテクト	優れたソフトウェアアーキテクト
チームの手を借りることなく、一人でパターンと技術を選定する	チームの意見に基づいて協働してパターンと技術を選択する
詳細なドキュメントを書く。ドキュメントを完璧に完成させ、一度だけリリースする	チームでドキュメントを作成、レビュー、更新する。得た知見から、チーム用のテンプレートを構築する
全ての設計判断を下す	チームに判断方法を教える。設計判断を行うために必要な情報をチームに提供する。レビューとフィードバックに努める
誰が特定の要素を構築するか決める	チームが自己組織化し、自分でタスクを選択できるようになるよう手伝う
アーキテクチャへの変更を避ける	アーキテクチャを変更しやすくする
技術的な判断を下す	技術的な判断について合意形成を行う

優れたアーキテクトになるために何が必要なのか？
これを、チームが学んでいく必要がある。
学ぶために必要なことは、「練習」である。

安全に実践する機会を作り出す

設計判断を学ぶため、練習の機会を設ける。
練習には、以下のような手段がある。

• ペア設計
  • 経験あるメンバーとペアとなって設計作業を行い、学びを得る
• 足場を作る
  • 学習促進及び強化を目的とした支援構造
    • 設計作業をサポートするためのテンプレート作成
    • 建設的な批評
    • スケルトンコード作成
    • 良い例と悪い例を共有
• アーキテクチャのガイドレールを導入する
  • 設計の選択肢を制限し、目的範囲から逸脱しないことを助ける仕組み
    • 設計ポリシー ... やるべきことや避けるべきことを説明した指示。シンプルだが強制は困難
    • コードに対する静的解析の導入
• 説明会（勉強会）を開く

設計権限を委譲する

大事なのは、重要な品質特性（つまりアーキテクチャ）を危険にさらすことなく、できるだけ多くの設計権限をチームに委譲すること。
「権限の7つのレベル」という考え方がある。
この考え方から、委譲すべき権限、そうでない権限を判断できる。

権限レベル	名前	概要
1	指示する	アーキテクトが設計判断を下し、チームに指示する
2	説得する	アーキテクトが設計判断を下し、その判断が正しい理由をチームに示す
3	相談する	設計判断を行う前にチームに意見を求める。設計判断はアーキテクトが行う
4	合意する	チームと協働し、チームの判断として設計判断に合意する
5	助言する	アーキテクトは助言や知見共有に留まり、設計判断はチームが行う
6	尋ねる	チームが行った設計判断に対して、アーキテクトは、その判断が正しい理由をチームに尋ねる
7	委譲する	アーキテクト以外のメンバーで設計判断を行う。チームが、判断に責任を持つ

状況に応じて、適切な設計権限を適切なレベルで委譲する。
「適切」を把握するには、試行錯誤が必要。

以下のような場合では、設計権限を維持する方向で検討すると良い。

• 失敗のリスクが高い場合
• チームが未熟な場合
  • 権限レベル1,2,3 ぐらいでよい

確信が持てない時、「適切な機会が現れるまで設計権限を維持する」という判断を下すのは悪くない。

反対に、以下のような場合設計権限を委譲する方向で検討すると良い。

• チームが既に経験を積んでいる場合

チームがアーキテクチャについて学ぶようになり、チームを導け得る自信が得られてきたら、共同ワークショップを実践すると良い。
共同ワークショップの中で、権限レベル5,6,7辺りで振る舞うことが出来る。
（この時、アーキテクトはファシリテーターとしてチームをサポートすることになる）

意思決定プロセスに複数のステークホルダーを巻き込む例

• アーキテクチャについての会話もするよう、チームに働きかける
• 協働ワークショップへの参加を働きかける
  • デザインスタジオ、リスクストーミング、シナリオウォークスルーなど
• チームの影響力を確認し、発生していることを理解する
  • アーキテクチャーブリーフィング、サニティチェックなど
• 良い例が存在する場合には、成果物の作成を委譲する

共にアーキテクチャを設計する

顧客に価値を届けるのはアーキテクチャであり、アーキテクトではない。
チームが価値を生むアーキテクチャを設計できるよう導くことが、アーキテクトの仕事である。

アーキテクトの重要な責任を次のように見直す。

エンジニアリングの観点から問題を定義する

アーキテクトには、アーキテクト上重要な要求、特に品質特性を鄭ぐする責任がある。
ステークホルダーの真のニーズを見誤らないよう、人間中心の設計手法を駆使して要求を収集する。

システムを分割し、要素とチームに責任を割り当てる

チームを導き、望ましい品質特性を促進するパターンを見つけ出す。
重要な品質特性が確実に達成されるよう、最小限のアーキテクチャを設計し、その他のすべての判断を後続の設計者に委ねる。

全体に目を向け、設計の一貫性を保ち続ける

設計が現れてくるタイミングでは、それをしっかり把握する。
アーキテクチャを実装するタイミングではチームを手助けする。
チームやステークホルダーに適した最も軽量な文書化を行い、設計判断を正確なモデルとして記録する。
記録したモデルから、システムを見通したり、判断を評価したり、リスクを明らかにしたりする。

品質特性間のトレードオフを決定する

設計判断を重ね、アーキテクチャが進化する中で、チームがトレードオフを調整するのを助ける。
リスクを使い、どれくらい設計するかや、何に専念するかを決定する。

技術的負債を管理する

やむを得ず負った技術的負債を認識し、返済の戦略を立てる。
技術的負債を、「成功のために避けられない結果」と捉え、負債を負うことと返済をうまく計画に組み込み、戦略的に管理するよう努める。

チームのアーキテクチャスキルを高める

チームに、「自分たちのシステム」という意識を持ってもらえるよう、働きかける。
チームのためにアーキテクチャを設計するのではなく、チームと共にアーキテクチャを設計する。