Strategic Designに関する意思決定をするための６つのエッセンス (p.492) †
要約 †
決定はチーム全体に行き渡らなければならない。
- strategyは全員が知る必要があるが、「象牙の塔のアーキテクト」になってしまうとうまく行かない。
- コミュニケーションがうまくいっているプロジェクトでは、Strategic Designはアプリケーションチームから発生する。
- どんなシステムであっても大切にしなければいけないのは、マネジメントによって与えられた権利よりも、開発者が実際にStrategyに対して持つ関係である。
決定のプロセスはフィードバックを吸収しなければならない
- ドメインに関する深い知識を持っているのは、アプリケーションチームである。だから、アーキテクチャチームがつくったアーキテクチャではうまくいかないことがほとんど。
- Strategic Designは技術的なインフラやアーキと違ってそれほどコードを書かないのだから、アプリケーションチームの人を巻き込むべき。熟練したアーキテクトならば、発想を吸い上げて、全体に適用できるソリューションを見いだせる。
- かつてアーキチームのメンバーがアプリケーション開発チームに交互に入っていたことがあった。これはうまく行ったし、Strategic Designも同じようなフィードバックループが必要。
計画は進化を許容しなければならない
- ソフトウェア開発はダイナミックなプロセス。意思決定が固定してしまっては後の選択肢が狭まる。EVOLVING ORDERによって後に得られた深い洞察に対応できる。
- デザイン上の意思決定を先に多くやりすぎると柔軟性がなくなってしまう。調和は大事だが、開発に合わせて成長し、変化しなければならないし、またアプリケーション開発者から権力を奪ってはならない。
- 強力なフィードバックによって、障害に突き当たった時や予期せぬチャンスが見つかった時にイノベーションが得られる。
アーキテクチャチームが優秀な人材を吸い上げてはいけない
- このレベルのデザインができる人は限られている。マネージャは優秀な開発者をアーキテクチャチームやインフラチームに入れようとするし、それは開発者本人の意思に従うものでもある。
- その結果、アプリケーションチームに技術的に劣った開発者しか残らない。しかし、良いアプリケーションを作るのにも技術がいるのだ。
- 逆に、アーキ／インフラチームに、技術は無いかもしれないがドメインに詳しい人が入らない。Strategic Designは純粋に技術的なタスクではない。ドメインに対する深い知識を持った開発者から引き出すべきだし、ドメインエキスパートも必要。
Strategic Designはミニマリズムと謙虚さを求める
- Strategic Designにとってミニマリズムは殊更に重要。わずかな不整合も致命傷になり得るのだから、アーキテクチャチームが分かれている場合には特に注意しなければならない。それと合わせてアーキテクトの責任感からオーバービルドがなされ、結果として生産性を下げるケースを何度も見てきたし、やってしまったこともある。
- デザインをより一層明確するものだけしか含めないように自分を律しなければならない。自分が最も優れていると思う者が誰かの邪魔をするかもしれないということを認識するには謙虚さが必要だ。
オブジェクトはスペシャリストであり、開発者はジェネラリストである
- 優れたオブジェクトデザインの本質は各オブジェクトに対して明確で限定された責務を割り当てることであり、相互依存関係を極限まで少なくすることだ。時にチーム間の関係も同じようにしようとしてしまうが、良いプロジェクトはもっと混沌としている。
- Strategic Designとそれ以外のデザインを区別したが、人を区別しろということではない。個人が把握できることには限界があるから、デザインエキスパートとドメインエキスパートを区別する必要はあるかもしれないが、ドメイン駆動デザインによって専門の垣根は越えられる。
同じことは技術的なフレームワークにも言える †
- フレームワークはアプリケーション開発の助けになるが、アーキテクチャはドメインモデルを表現するように実装し、容易に変更することを妨げることがある。これは、フレームワークがドメインレイヤやアプリケーションレイヤに踏み込もうとしていなくても起こり得る。
- 進化、ミニマリズム、アプリケーション開発チームの参加によってサービスは継続的にブラッシュアップされ、アプリケーション開発を妨げないルールができあがる。この流れに従わないアーキテクチャは開発を妨げるか、捨てられるかしてしまう。
- フレーウワークを破滅させる態度が一つある。
サルでも分かるフレームワークを作ってはいけない
- アプリケーション開発が難しいということを甘く見たチーム分けは失敗する。設計できるだけの技術力がない人間はソフトウェア開発にアサインしてはいけないのだ。逆に技術力があるのなら、甘やかしても邪魔をするだけだ。
- この態度はチーム間の関係も悪くする。実際自分の経験でも、傲慢なチームになってしまい、会話の度に開発者に頭を下げていたことがある。
- 関連性のない技術的な詳細を隠蔽化するということは、私がけなしているプレパッケージングとは根本的に違う。フレームワークは優れた抽象化とツールを開発者に提供し得る。一般化するのは難しいが、設計者に聞いてみるといい。フレームワークの利用者に対する高度な尊敬の念を持っているなら、多分正しい道を歩んでいる。
マスタープランに注意せよ †
- Christopher Alexander氏率いる建築家グループは、建築と都市計画の分野における散発的な発展の擁護者だ。彼らは、なぜマスタープランが失敗するのかについて、非常にいい説明をしている。
- 実践的にはマスタープランは失敗する。それが生み出すのが、全体主義的な秩序であって、有機的な秩序ではないからだ。あまりに厳格すぎて、自然で予想できない変化に対応できない。しかし、コミュニティーの生活の中ではそういった変化があらわれてくるのは避けられないのだ。
- 有機的秩序を生み出すには、マスタープランは厳格過ぎるか、不正確であるかのどちらかだ。全体像は厳格過ぎるのに、詳細は不正確なのだ。
- Alexander氏とその同僚が代わりに擁護しているのは、あらゆるコミュニティメンバーが、散発的な発展の活動に対して適用できる諸原則だ。それによって、環境に合った「有機的秩序」が現れてくるのである。
担当者のつぶやき †
- 「 開発の中で現れてくるものを本質として最重要視し、なおかつそれを生み出す力を信じる。」結局、最後はそこなのか・・・という感じです。個人的に最も衝撃的だった一言はこれでした。"If those people are not smart enough to design, they shouldn't be assigned to develop software"(p.496)（強調は引用者）そんな無茶な（笑）。
- 追記：こういう引用の仕方は誤解を招く恐れがあるので追記しておきます。確かに本文中にはこう書いてありますが、Evansが言いたいのは「技術のない人にコードを書かせるな」ということではなく（少なくとも強調点はそこではなく）、「フレームワークが難しくて、アプリケーションが簡単なんてことは断じて無い」ということですね。
- 「傲慢なアーキテクト」というキャラが見え隠れしますが、実際にはアーキをやっている人はみんな、多かれ少なかれ信念を持ち、痛みも感じているように思いますけどね。
みんなの突っ込み †
- original news, -- ключи и логин для nod32?
