Clean Architecture 2つの価値
2つの価値
すべてのソフトウェアシステムは、ステークホルダーに2つの異なる価値を提供。
振る舞い
アーキテクチャ
ソフトウェア開発者は、この2つの価値を維持する責任がある。
振る舞い
プログラマは、マシンがステークホルダーのためにお金を生み出したり節約したりできるように、マシンに振る舞いを与えるために雇用されている。そのためにプログラマは、ステークホルダーが昨日仕様書や用件文書を作成するのを支援する。その後、ステークホルダーのマシンが要件を満たせるように、プログラマはコードを書くことになる。
アーキテクチャ
ソフトウェアという言葉は「ソフト」と「ウェア」の複合語。「ウェア」はプロダクトを意味する。ソフトウェアは「ソフト」になるように考案されたもので、マシンの振る舞いを簡単に変更する手段になることを目的としたもの。ステークホルダーが機能を変更したいと思えば、その変更は簡単でできるようになっておくべき。変更の更新度は、変更の形状ではなく、変更のスコープに比例しなければいけない。
大きな価値
機能とアーキテクチャどちらが価値が大きいか？。
完璧に動作するが、変更できないプログラムは、要件が変更されると機能しなくなる。修正することもできず、いずれ役に立たなくなる。
動作しないが、変更が簡単なプログラムは、要件が変更されても修正は可能なで、動かし続けることができる。これからも引き続き役に立つ。
アイゼンハワーのマトリックス
私には緊急と重要の2種類の問題がある。緊急と重要は違う。重要なことが緊急になるわけではない。
この古い格言には真実が数多く含まれている。緊急なことが重要になることはほとんどない。重要なことが緊急になることもほとんどない。
ソフトウェアの1つ目の価値(振る舞い)は緊急だが、常に重要とは限らない。
ソフトウェアの2つ目の価値(アーキテクチャ)は重要だが、常に緊急とは限らない。
緊急かつ重要なものもあるが、緊急でも重要でもないものもある。この4つの組み合わせには、以下の優先順位を付けることが出来る。
- 緊急かつ重要
- 緊急ではないが重要
- 緊急だが重要ではない
- 緊急でも重要でもない
コードのアーキテクチャ(重要)は、1と2、コードの振る舞い(緊急)は1と3に位置する。
ビジネスマネージャーや開発者がよくやる間違いは、3の項目を1に昇格させること。つまり、「緊急だが重要ではない」ものと「緊急かつ重要」なものを区別できないもの。こうした間違いは、システムの重要ではないことを優先して、システムの重要なアーキテクチャを無視することにつながる。
ソフトウェア開発者のジレンマは、ビジネスマネージャがアーキテクチャの重要性を評価できないこと。そのためにソフトウェア開発者雇われている。したがって、ソフトウェア開発チームには、機能の緊急性よりもアーキテクチャの重要性を強く主張する責任が求められる。
アーキテクチャの戦い
この責任を果たすことは「戦い」に足を踏み入れる事を意味する。
マネジメントチームも、マーケティングチームも、セールスチームも、オペレーションチームも常に闘争
ソフトウェア開発者もステークホルダーであることは忘れてはいけない。
ソフトウェアアーキテクトは、システムの機能よりも構造にフォーカスするもの。アーキテクトは、機能を簡単に開発・変更・拡張できるアーキテクチャを構築するもの。
アーキテクチャを後回しにすると、システムの開発コストは高くなり、システムの一部または全部が変更不能になる可能性がある。