Making Software ―エビデンスが変えるソフトウェア開発

173

結論

領域の端から出てしまうと、プロジェクトの前提が実際には楽観的すぎた場合に、重大な損失が生じる

リスクが高まります。

図

10-10

から分かることをまとめると、プロジェクトの規模、重要性、安定性が大きくなるほど、アー

キテクチャの実現可能性エビデンスを検証することの必要性が高まります。一方、非常に小さな、重要

性の低く、変動の大きなプロジェクトについては、アーキテクティングに工数を掛けることの違いがほ

とんどなく、頻繁な手戻りも必要ないので、アーキテクチャの実現可能性エビデンスを検証するコスト

は全体として引き合わないでしょう。そういうケースでは、

XP

などのアジャイル手法が、より効果的

です。結局、エビデンスに基づく仕様や計画は、直ちにプロジェクトの成功を保証するものではありま

せんが、一般的に言えば、今日のソフトウェアプロジェクトでありがちな完成の遅れや欠陥の多くを削

減してくれるでしょう。

1

つ最後に注意して頂きたいのは、図

10-10

に示したアーキテクティング投資のスイートスポットの

数値は、その

1

つの値だけで万能でありどのプロジェクトでもこの値を見込めばいい、というものでは

なく、アーキテクティングに対する正しい投資計画のための初期段階の指針だということです。プロジェ

クトが詳細計画と予算決定の段階に到達したところで、個人の能力や経験、アプリケーションの複雑さ、

旧版からの移行の難しさ、技術上のリスク、プロセスの成熟度、ツールサポートなど、他のコスト要因

も考慮して、アーキテクティング投資の適切な水準を判断するべきです。より新しいモデルである ...