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

174

10

章 アーキテクティング：いつ、どれだけ

?

というものです。ただしこの比率は、初期段階で要求とアーキテクチャに対する検証と妥当性確認によ

り多く投資することで、著しく軽減できます。図

10-6

の

CCPDS-R

プロジェクトのデータが示す通り、

早期に高リスクの修正に取り組むことで、上記の比率をより小さくできます。

小さなプロジェクトに対するエビデンスでは、上記の比率は一貫して

1:5

程度ですが、これについて

も、優れた人材を起用し、かつ、たとえばペアプログラミングと継続した統合などのアジャイルメソッ

ドを用いて修正までの期間を短縮することで、比率を小さくできます。小規模で重要度の小さなプロジェ

クトでは、アーキテクティング活動をリファクタリングという形でライフサイクル全体に渡って行うこ

ともできますが、「最も簡単なものからやる」形で、スケーラビリティのない

COTS

やセキュリティ的

に問題のあるデータ構造・制御構造にコミットしてしまうなど、アーキテクチャに

関するコミットメン

トを行ってしまい、それが後から容易には直せなくなるという事態に注意する必要があります。

たとえば

CCPDS-R

についてなどの、アーキテクティングとリスク解決のための作業との間のペイ

オフに関して最近提供されたエビデンスは、「どれだけアーキテクティングを行えば十分か？」の最も高

いペイオフであるスイートスポットの位置が、プロジェクトの大きさと重要度の関数であること（大き

く重要なプロジェクトほどアーキテクティングに多くの投資を必要とする） ...