【17】ビジネスサイドに主導権を渡せ

デーブ・ミュアヘッド

 エンタープライズアプリケーション開発では、アーキテクトは組織の中のビジネスコミュニティと技術コミュニティの架け橋となり、それぞれの関心事を代弁し、守るとともに、両者を仲介しなければなりません。もっとも、最終的にはビジネスに主導権を与える必要があります。アーキテク卜は、企業の目的と経営の実現に基づいて技術的な決定を導いていかなければなりません。

 ビジネスサイドは、ソフトウェア開発に着手する前に、希望する ROI(投資利益率)というものを策定します。アーキテクトは、希望の ROI を理解し、それに基づいてソフトウェアがビジネスに与えられる価値の上限を判断し、技術的な決定のために予算超過を起こさないようにする必要があります。ROI は、機能の価値とコストについてビジネスの視点で協議するときや、開発チーム内で技術的な設計や実装について協議するときに、客観的な判断基準の大きな要素として適用させなければなりません。たとえば、ビジネス側が求める ROI を開発チームに示すには、テスト環境や本番環境における保守費やライセンス料が高いテクノロジーは採用できないといった形にする必要があります。

 ビジネス側に主導権を握らせ、適切なビジネス上の判断をサポートするためには、進行中の開発作業について、質の高い情報をビジネスサイドにフィードバックしなければなりませんが、これはなかなか難しいことです。透明性が非常に重要になるのはこの場面です。アーキテクトは、開発マネージャーと協力して、規則的なフィードバック手法を作り、維持しなければなりません。リーンソフトウェア開発のさまざまなテクニックを使えば、これは実現できます。例えば大きなチャート、継続的インテグレーション、プロジェクト初期段階から動作するソフトウェアをビジネスサイドに頻繁に提供するなどです。

 ソフトウェア開発は、システムが稼働に移るまで、多くの意思決定が継続的に行われるという意味で、根本的にはデザインの仕事だと言うことができます。ソフトウェア・デベロッパーが意思決定すること自体は間違っていませんが、彼らがビジネス上の判断を下すのは避けなければなりません。

 しかし、ビジネスコミュニティが開発チームに対して方向性を示し、質問に答え、ビジネス上の判断を下すという責務を果たせないと、実質的にデベロッパーにその判断が委ねられることになります。アーキテクトは、ソフトウェアアーキテクチャーとビジネス上の目標をデベロッパーに伝え、それらを守る立場を取ることにより、デベロッパーが下す小さな判断に大きな方向性を与え、デベロッパーがビジネス上の判断を下すことのないように注意を払わなければなりません。ビジネスコミュニティが出し続ける指示、期待、現実的な課題といったものに対して、技術部門の判断が明確に矛盾するなら、賭けのようなものにお金をかけ、希少な資源を浪費することにつながります。そんなことになれば、弁解の余地はありません。

 ソフトウェア開発チームの長期的な利益がもっとも大きく確保されるのは、ビジネスが主導権を握った時です。