プロジェクト管理やソフトウェアアーキテクチャの問題の背後にはトレードオフが隠れているのではないか

プロジェクト管理やソフトウェアアーキテクチャの問題の背後にはトレードオフが隠れているのではないか？

プロジェクトマネージャがシステム開発案件を切り盛りするのは正直大変だ。
どの案件もいつも新しい技術、新しい要件、初めての経験を求められるからだ。
プロジェクトマネージャの頭にはいつもQCDが念頭にある。
QCDという厳しい制約条件をいかに守り抜くか？

アーキテクトがリプレース案件、新規システム構築案件を担当して切り盛りするのは正直大変だ。
どの案件もいつも新しい技術、新しい要件、初めての経験を求められるからだ。
アーキテクトは安定したアーキテクチャが欲しい。
それがあれば、設計者はその安定した基盤上で安心して設計できる。
それがあれば、開発者はその安定した基盤上で安心して開発できる。

安定したアーキテクチャは6つの品質特性という制約条件を持つ。
アーキテクチャは品質特性という厳しい制約条件をいかに守り抜くか？

QCDや品質特性という制約条件は、実際にはトレードオフになりやすい。
どれか一つの要素を重視しすぎるとバランスを崩し、最終的なアウトプットの品質を悪化させる。
線形計画法のように、複数の要素を必要ではあるが十分な量をアサインしてバランスすることで、最適解を求める。

トレードオフがなければ、問題の本質にたどり着かないのではないか。
トレードオフを認識しなければ、バランスを崩すから。

トレードオフになる問題の構造は因果ループ図で書きやすい。
片方の要素が増えて良化すれば、もう片方の要素は減って悪化する。
つまり、トレードオフになる問題は、一つのシステム構造を持つ。

因果ループ図が教える所によれば、因果をループさせる要素を強化したり崩すことで、そのシステム構造を壊して別の変化をもたらすことができる。
つまり、トレードオフの問題構造はシステム構造としてモデル化されるが、そのモデルを故意に壊すことで別の変化をもたらし、新たなシステム構造を生み出す。

トレードオフの認識こそが問題解決の鍵になるはず。