担当はid:hirataraです。
誰が戦略を決めるのか (490ページ) †
要約 †
誰が戦略を決めるのか (490ページ) †
伝統的に基本設計はアプリ開発が始まる前に、組織内でより権力のあるチームから言い渡される物であるが、そうである必要はないし、普通はそうだとうまくいかない。
定義より、戦略的な設計はプロジェクトを横断して提供されなければならない。規範的にはなりたくないが、効率的な決断プロセスには基礎が必要だ。
まず、実践で効力があった二つのスタイルを簡単に見てみよう(よって、「高いとこから知恵が来る」ようなスタイルは無視する。)。
アプリ開発から現れる組織構造 (491ページ) †
よくコミュニケーションが取れて自制が効いているチームは、中央に権限がなくても作業ができるし、EVOLVING ORDER に従って主義を共有でき、命令によってではなく組織的に育つ。
これはXPにおいては典型的なモデルで、組織構造はプログラムを行うペアから自発的に産まれる。チームの一部の人々が広範囲の構造を監視する責任を持てば、組織構造は統一される。XPでは、指導者に当たる人物が自発的にこのような役割になるが、これによって開発チームにはプロジェクト全体の設計の決定を行える権限がある人が少なくとも数人は存在するようになる。
大きな組織が複数のチームを回す時は、互いに提携するチームが非公式に連携し始める。それぞれのチームが広範囲の構造についての考えを持っているが、色んなチームの代表者による非公式なチームが選択肢を議論して決断を下す。このような調整は、少数チームがかかわり合い、互いに調整に同意しており、各設計について比較ができ、各チームの組織化のニーズが十分似通ってるときに機能する。
顧客志向の設計チーム (492ページ) †
戦略を共有するのに中央集権的にやるのは魅力的だが、失敗した「象牙の塔のアーキテクト」のようなモデルだけがそれではない。アプリチームと同等で、BOUNDED CONTEXT 境界としての大きな組織やチームの調和やをまたがる技術的な問題の手助けをするようなアーキテクチャチームでもよい。そうすれば、彼らはアプリ開発を強調する考えを持たなければなららなくなる。
こういうチームは組織図的には伝統的なアーキテクチャチームと変わらないが、全ての活動においてことなる。チームは開発にほんとの意味で協力者となり、開発者とパターンを見つけ、上流に至るまで試行をし、自らの手を汚す。
筆者は、次に挙げるリストのほとんどを実施するアーキテクトリーダーが終わらせたプロジェクトにおいて、こういうシナリオを何度か見た。
担当者のつぶやき †
みんなの突っ込み †
前回のKPTから池田がまとめています。
そもそも戦略的デザインとは？（GLOSSARYより引用）
システムの大部分に適用されるモデリングや設計上の決定．その決定は，全プロジェクトおよび，チームレベルの決定に影響する．
戦略的デザインを決定するのは2パターンある。即ち
- チーム内、かつチーム同士が、よくコミュニケーションが取れている状況にある場合は、アプリチーム（の代表者）
- 各チームに横断的に働きかける中央集権的なアーキテクチャーチーム
蛇足
戦略的デザインと大袈裟な表現をするより、設計方針でいいじゃないか？って思いましたが、軍事戦略の階層によると、PolicyはStrategyよりも上位の概念（因みにtecnologyはtacticsより下位）みたいです。
