【35】大きなスコープは敵

デーブ・クイック

　スコープとは、プロジェクトの規模のことです。どのくらいの時間、作業量、リソースが必要か。どの程度の品質でどのような機能が必要か。実現がどの程度難しいか。リスクはどの程度か。どのような制約があるか。これらの問いに対する答えが、プロジェクトのスコープとなります。

　ソフトウェア・アーキテクトは、大規模で複雑なプロジェクトに挑みたがります。評価を得ようと、プロジェクトの重要性を増すためにわざとスコープを広げようとさえします。しかし、スコープを広げようとすると、失敗の危険性は予想以上に速く拡大します。ですから、スコープの拡大は、成功の敵だと言っても間違いはありません。プロジェクトのスコープを倍にすると、失敗の危険性は桁違いに大きくなります。

　なぜそんなことになるのでしょうか。いくつか例を考えてみましょう。

直観的には、スコープが倍になれば、時間やリソースも倍になるだけだと思うかもしれません。しかし、歴史が示すところによれば、スコープ拡大とその影響は比例ではありません。たとえば、4 人のチームで必要なコミュニケーションの量は、2人のチームの倍以上になるでしょう。
見積もりは、科学的に正確な事実とは大きくかけ離れているものです。予想よりもずっと実装が難しい機能を見たことがない人はいないでしょう。

　もちろん、それなりの規模も複雑度もなく、最初からやる価値のないプロジェクトはあります。テキスト入力機能を持たないテキストエディタは簡単に作れますが、それではテキストエディタにはなりません。では、現実のプロジェクトでスコープを縮小するか、管理できる範囲に押しとどめておくためには、どのような戦略を取ればよいのでしょうか。

本来のニーズを理解する。　プロジェクトが提供しなければならない機能は、要件として提出されたものです。要件は、機能と機能の品質を規定します。計測可能な値で説明されていない要件については、顧客に質問しましょう。企業収益のために効果のない要件は、要件ではないはずです。
分割統治する。　仕事を独立した小さな部分に分割するチャンスを探すようにしましょう。相互に依存し合う部品が絡み合った 1 つの大規模プロジェクトよりも、複数の独立した小規模プロジェクトを管理する方が簡単です。
優先順位を付ける。　ビジネスの世界の変化は急です。大規模プロジェクトの要件は、完成するまでに何度も変わります。通常、ビジネスに変化があっても、重要な要件は変わりませんが、そうでない要件は変化しますし、消えてしまう場合さえあります。優先順位を付ければ、もっとも重要な要件を満たす機能を先に引き渡すことができます。
限り早く成果を引き渡す。　普通の人は、実際に手にするまで自分が欲しいものが何かわからないものです。顧客の言ったことやプロジェクト内のさまざまな役割の人々が理解したことに基づいて、ぶらんこ製作プロジェクトがイメージしたぶらんこがどのようなものかを見せる有名なマンガがあります。「顧客が本当に欲しかったもの」というタイトルの最後の絵は、古タイヤを使ったシンプルなぶらんこです。顧客が何かをやってみようと考えたとき、ソリューションは予想よりもシンプルな場合があります。もっとも重要な部分を先に作れば、もっとも大切なフィードバックがもっとも必要な早い段階で手に入ります。

　アジャイルの推進者たちは、「使えそうなものの中でもっともシンプルなもの」を作ることを提唱しています。複雑なアーキテクチャーは、単純なアーキテクチャーよりもかなり高い確率で失敗します。プロジェクトのスコープを縮小すれば、多くの場合、アーキテクチャーも小規模になります。スコープ縮小は、アーキテクトが成功の確率を上げるためにできるもっとも効果的な戦略の 1 つなのです。