【Clean Architecture】2章 2つの価値
「Clean Architecture」の学習記録。
「第2章 2つの価値のお話」のまとめ。
機能とアーキテクチャ
機能とアーキテクチャ、どちらが重要か？
ビジネスマネージャは機能だと答えるがこれは間違っている。
- 完璧に機能が動作するが変更できないプログラム:
→要件が変更されると機能しなくなるため修正できない。このプログラムはいずれ役に立たなくなる。 - 機能は動作しないが、変更が簡単なプログラム:
→要件が変更されても修正は可能なので動かし続けられる。このプログラムは引き続き役に立つ。
アイゼンハワーのリクス
ドワイト・D・アイゼンハワー大統領による「重要度と緊急度のマトリクス」がある。
| 重要 緊急 |
重要 緊急ではない |
|---|---|
| 重要ではない 緊急 |
重要ではない 緊急ではない |
「私には緊急と重要の2種類の問題がある。緊急と重要は違う。重要なことが緊急になるわけではない。」
この古い格言には真実が多く含まれている。緊急なことが重要になることはほとんどない。
重要なことが緊急になることもほとんどない。
- ソフトウェアの1つ目の価値（振る舞い）は緊急だが、常に重要とは限らない。
- ソフトウェアの2つ目の価値（アーキテクチャ）は重要だが、常に緊急とは限らない。
緊急かつ重要なもの、緊急でも重要でもないものもある。
この4つの組み合わせには以下の優先順位を付けることができる。
- 緊急かつ重要
- 緊急ではないが重要
- 緊急だが重要ではない
- 緊急でも重要でもない
コードのアーキテクチャ（重要）は1と2、コードの振る舞い（緊急）は1と3に位置する。
ビジネスマネージャや開発者がよくやる間違いは3を1に昇格させることである。
つまりシステムの重要ではない振る舞いを優先して、システムの重要なアーキテクチャを無視することにつながる。
ソフトウェア開発チームには、機能の緊急性よりも、アーキテクチャの重要性を強く主張する責任が求められる。
アーキテクチャの戦い
この責任を果たすことは「闘争」に足を踏み入れることを意味する。
優れたソフトウェア開発チームは、真正面から闘争に立ち向かう。
ステークホルダーたちと対等に、ひるむことなく口論する。
ソフトウェア開発者もステークホルダーであることは忘れてはいけない。
保護すべきソフトウェアに対する責任がある。
それがあなたの役割であり義務であり、あなたが雇われている大きな理由である。
ソフトウェアアーキテクトは、システムの機能よりも構造にフォーカスするものである。
アーキテクトは機能を簡単に開発・拡張できるアーキテクチャを構築する。
アーキテクチャを後回しにすると、システムの開発コストはますます高くなり、システムの一部または全てが変更不能になっていく。
このような状態が許されている場合、ソフトウェア開発チームが自らが必要とするアーキテクチャのために懸命に闘わなかったということである。
