前々から、ソフトウェアプロジェクト・マネージャはアーキテクチャの知識が必須だと考えている。
製品アーキテクチャをプロジェクトマネジメントの道具箱に入れるのはおかしいと感じるかもしれない。しかし、プロジェクト全体の規模と共に、製品の技術的アーキテクチャは、製品やプロジェクトの成功と深く関係している。
――アジャイルプロジェクトマネジメント 最高のチームづくりと革新的な製品の法則 / ジム・ハイスミス
ソフトウェアプロジェクトは、常にたった一つの誤りでプロジェクトそのものが破壊されることがある。そういう意味では医療と近いものがあって、何かを間違えてしまうと場合によってはプロジェクトは死んでしまう（実際には死ぬわけではないのだけれども、ビジネスとして大きな被害を発生させることがある）。
プロジェクト管理では、うまくやれば発生した誤りを早期に発見し、適切な処置をすることはできる。じかし、より確実に成功するためには「予防」することが重要である。予防は、例えば作業プロセスのガイドラインなどでも可能であるが、一番確実なのはソフトウェア・アーキテクチャに対策を組み込んでしまうことである。作業プロセスに組み込まれた対策は、状況や作業者の能力によって無効化されてしまうことがあるが、アーキテクチャに組み込まれた施策は環境として常に有効になる。
また、チームビルディングの観点でもアーキテクチャの知識が重要となる。ソフトウェアプロジェクトチームの構成は、要求の構造（たとえば機能カテゴリの数）とアーキテクチャによって決定される。業務機能別のチーム構成とするのか、技術要素別のチーム構成とするのか、共通的な役割のチームが必要なのかの判断には、アーキテクチャの知識は必ず必要である。
ということを、アーキテクトがプロジェクトマネジメントをしたら - arclampを読んで考えたのであった。
