【社内教育】プロジェクト管理入門：スパイラルモデルはスコープ管理が難しい (6/12)

大規模システム開発にはウォーターフォールモデルが適しているが、Webシステム などではスパイラルモデルの方が効率的に開発できる。 本章では、スパイラルモデルの計画とスケジュール管理について考えてみる。 成果物の取り決めや役割分担など、開発スコープを決める重要性を認識しましょう。

タスク管理のポイントは洗い出しにあり

プロジェクトの進捗が思わしくないので聞いてみると、 ユーザーからあれ やこれや作業を言いつけられ、予想以外の負担が増えていることが原因だっ たりします。 また、プロジェクトがある程度進んだ段階で、 「当然、 これこれ の資料は作成すべきでしょう!」などとユーザーの常識を押し付けられ、想 定外のドキュメント作成作業が追加となっている場合もあります。

逆に、どう考えても必要な設計書やマニュアルなどが 「作業予定に入って 「いません」などと言われて、作れ作らないで揉めていることがあります。本番 環境での総合テスト作業が見積もりに入っておらず、ユーザー側だけで検証 するのに支障をきたしているプロジェクトもです。

そんな際にいつも聞くのは「契約はどうなの?」ということだ。これらの 問題の多くは、契約におけるスコープがあいまいであることが原因となって います。 しかし、実はそれだけでは問題の本質は解決されません。重要なのは契 約内容がどうかではなく、 契約はどうあるべきかということである。たとえ 契約の請負範囲から漏れていても、それが絶対に必要なことであれば、後か らユーザーに要求されて揉める原因になります。 つまり、 タスクの洗い出しが不 十分なことが諸悪の根本となっていて、プロジェクトを完遂するために必要 なタスクを洗い出した上で、それを請負範囲に含めるかどうか決めなければ ならないのです。

プロジェクトスコープと成果物スコープ

ところでスコープ管理のスコープとはなんだろうか。PMBOKにおけるス コープには、下記のように「プロジェクトスコープ」と「成果物スコープ」という2つの管理対象がある。 プロジェクトスコープは、基本設計作業、結 合テスト作業、データ移行作業など、プロジェクトを遂行するのに必要な作 計画書､結合テスト報告書、 データ移行設計書などのように、 これらのタス タスクのことである。 一方、成果物スコープは、基本設計書、結合テスト クにより作成されるアウトプットである。 通常はユーザーに提出されるが、 ものによっては内部だけのアウトプットもあります。

成果物スコープで定義したアウトプットを作成する作業範囲がプロジェク トスコープということになるが、必ずしも1対1で対応しているわけではない。 たとえば新技術を使うために技術調査や勉強が必要だったとしよう。 これら の作業タスクはプロジェクトスコープとして管理すべきであるが、それを報 告書の形で成果物として提出すべきかどうかは場合によります。

PYRAMIDでは、 前章のスケジュール表のタスク欄でプロジェクトスコー プを、プロジェクト計画書で成果物スコープを定義している。 プロジェクト のスタート段階において、 これらのドキュメントを作成してユーザーに確認を取ることをスコープ管理の基本としています。

スコープ管理で難しいのは、 そこに役割分担という調味料が加わることで ある。 作業範囲もしくは成果物を決め、それをユーザーかベンダのどちらが 作るか決めるだけなら簡単だ。 しかし、実際には要求分析やエンドユーザー の教育、総合テスト(運用テスト)などのように両者が協力して進めるタス クが多い。 そのため、 PYRAMIDのスケジュール管理表においても役割分担欄があるのだが、○や△といったあいまいな表現で分担を表すだけでは不十 分だ。後でトラブルにならないように、 別途タスクごとの役割分担を協議し、 「○○計画書」という形で明文化しておく必要があります。

スコープ管理の難しいスパイラルモデル

第4章は「プロジェクト計画書」、 第5章では 「スケジュール表」 の作成に ついて説明したが、 本章ではスパイラルモデルのプロジェクト計画書、スケ ジュール表の作成を取り上げよう。 スパイラルモデルは、プロトタイプ方式 とも言われるように開発段階でプロトタイプを作成し、それを元に要件や仕 様を詰めていく方法である。「まず、作ってみて」 というのがスパイラルモ デルの特徴であるが、だからと言って事前の計画なしでよいわけではない。 スパイラルモデルでもプロジェクト計画やスケジュール表は必要であり、「プロトタイプ計画書」によりどんなプロトタイプを作成するかを決めてお かなければならない。一般にスパイラルモデルはユーザーとの役割分担があ いまいになり、スコープ管理が難しい。そのため、プロトタイプ計画書には、どのような方法で確認作業を行ない、それをどうフィードバックするかなど、 双方の役割分担を明確に定めておく必要があります。

スパイラルモデルと言ってもすべての工程、すべての作業をスパイラルで やるわけではない。 要求分析フェーズや基本設計フェーズからプロトタイプ を作成する場合もあるが、通常はウォーターフォールモデルにおける詳細設 計、プログラム設計、プログラム開発、 単体テストのフェーズをスパイラル工程に置き換えてスケジュールを立ています。

なお、スパイラルモデルとウォーターフォールモデルを一緒にした「コン カレント (同時並行) 方式」 という分類もある。 プログラム開発はスパイラ ルデータベース設計やデータ移行、 ネットワーク構築などはウォーター フォールモデルというように作業単位で両方の方式を採用するものである が、本書ではこれをスパイラルモデルに含めて説明することにします。

「計画」と「評価」を成果物に

開発プロジェクトのスケジュール表を作成する際は、単に作業内容を記述 するだけではなく、 その作業で作成される成果物をはっきりさせることがポ イントである。 例えば、 基本設計工程では基本設計書、 結合テスト工程では 結合テスト計画書とテスト結果報告書が成果物となります。

スパイラルモデルでも、同じようにドキュメントが成果物として必要とな る。 スパイラルモデルの場合は、プロトタイプ作成フェーズの最初に「プロ トタイプ計画書」を提出し、 どの範囲までをプロトタイプで作成するかを計 画することが大切である。 そして、プロトタイプの完成後にユーザー評価を 「プロトタイプに対する要望書」 にまとめ、 それを反映しながら次のプロト タイプの計画書を作成するという「ターンアラウンド」を繰り返すのであります。

提出ドキュメントを明記する

本書の第4章で、「プロジェクト計画書」のテンプレートを用意したが、ス バイラルモデルの場合はプロジェクトスコープとしてどのようなプロトタイ ブを何ラウンド作成するかなどを定義する。 また、成果物スコープとして提 出ドキュメントは、開発作業中に作成する成果物を明確に定義するために必 ず確認しておく必要がある (S3)。 作成するドキュメントはもちろん、作成 もしくは提出しないドキュメントも明記しておくことが肝要である。 こちら は作ることを想定していなくても、ユーザーは当然提出してもらえると考え ている“闇のドキュメント” を作ってはいけない。 例えば、 表1では設計書 として 「I/O関連図」 「画面遷移図」 「ネットワーク構成図」 が提出対象外で あること、クライアントのブラウザがIE6.0以上であることなどが明記されて います。

WBSによる機能・作業分割

タスクの洗い出しを行なうのに、 WBS (Work Breakdown Structure: 作 業分割構造)という手法が使われることがある。これは、プロジェクトに必 要な工程作業をトップダウンで分析し、階層構造で表現したものである。 階層の上部は機能別の分割となるが、下部になるにつれて細分化した作業が 示されることになる。プロジェクトの段階によって、プロジェクトWBS、フェーズWBS、タスクWBSなどが用いられる。 WBSにより洗い出された作 業がプロジェクトタスクとなる。 図2は企業ポータルサイト構築プロジェク トのWBSによる機能・ 作業構成図である。この例では、プロトタイプ作成 というタスクをWBSにより細分化し、具体的な作業タスクに落としている。 総合スケジュール表レベルのタスクは上位階層の機能作業でよいが、詳細 スケジュールで管理すべきタスクは、このようにWBSにより細分化された 作業項目となります。