デーブ・ミュアヘッドエンタープライズアプリケーション開発では、アーキテクトは組織の中のビジネスコミュニティと技術コミュニティの架け橋となり、それぞれの感心事を代弁し、守るとともに、両者を仲介しなければなりません。最終的にはビジネスに主導権を与える必要があります。アーキテク卜は、企業の目的と経営の実現に基いて技術的な決定を導いていかなければなりません。ビジネスサイドは、ソフトウェア開発に着手する前に、希望するROI(投資利益率)というものを策定しあmす。アーキテクトは、希望のROIを理解し、それに基づいてソフトウェアがbusinessに与えられる価値の上限を判断し、技術的な決定のために予想超過を起こさないようにする必要があります。ROIは、機能の価値とコストについてビジネスの視点で協議するときや、開発チーム内で技術的な設計や実装について協議するときに、客観的な判断基準の大きな要素として適用させなければなりません。ビジネス側が求めるROIを開発チームに示すには、テスト環境や本番環境における保守費やライセンス料が高いテクノロジーは採用できないといった形にする必要があります。ビジネス側に主導権を握らせ、適切なビジネス上の判断をサポートするためには、進行中の開発作業について、質の高い情報をビジネスサイドにフィードバックしなければなりませんが、これはなかなか難しいことです。透明性が非常に重要になるのはこの場面です。アーキテクトは、開発マネージャーと協力して、規則的なフィードバック手法を作り、維持しなければなりません。リーンソフトウェア開発の様々なテクニックを使えば、これは実現できます。大きなチャート、継続的インテグレーション、プロジェクト初期段階から動作するソフトウェアをビジネスサイドに頻繁に提供するなどです。ソフトウェア開発は、システムが稼働に移るまで、多くの意思決定が継続的に行われるという意味で、根本的にはデザインの仕事だということができます。ソフトウェア・デベロッパーが意思決定すること自体は間違っていませんが、彼らがビジネス上の判断を下すのは避けなければなりません。ビジネスコミュニティが開発チームに対して方向性を示し、質問に答え、ビジネス上の判断を下すという責務を果たせないと、実質的にデベロッパーにその判断が委ねられることになります。アーキテクトは、ソフトウェアアーキテクチャ-とビジネス上の目標をデベロッパーに伝え、それらを守る立場を取ることにより、デベロッパーが下す小さな判断に大きな方向性を与え、デベロッパーがビジネス上の判断を下す事のないように注意を払わなければなりません。課題といったものに対して、技術部門の判断が明確に矛盾するなら、賭けのようなものにお金をかけ、希少な資源を浪費することにつながります。そんなことになれば、弁解の余地はありません。ソフトウェア開発チームの長期的な利益が最も大きく確保されるのは、ビジネスが主導権を握った時です。ソフトウェアアーキテクトが知るべき97のこと当サイトはオライリー・ジャパンによる公式なサイトではありません。個々のエッセイは「CC-by-3.0-US」によってライセンスされています。2プロジェクト・マネジャーが知るべき97のこと。