プロジェクト開始前の段階からスコープやコスト，スケジュール，組織体制を十分に検討することは，プロジェクトのスムーズな立ち上げに欠かせない。ベテランのプロマネが，提案・契約に至るまでの計画作業を現場の経験を基に解説する。
布川 薫／日本IBMゲスト執筆者：神野 幸英／日本IBM
プロジェクト・マネジャーに任命されたものの，すでに提案・契約が完了しており，プロジェクトのスコープ（範囲）や新システムの稼働スケジュール，コストなども決められてしまっていた…。読者の中にはこんな経験をした人はいないだろうか。
これは請負型のシステム開発プロジェクトのあるべき姿ではない。請負型のシステム開発では，プロジェクトの提案・契約を実施する「プロポーザル・マネジャー」と，実際にプロジェクトを遂行していくプロジェクト・マネジャーを，一貫して同じ人が担当するのが本来の姿だからだ。
プロジェクトの計画を別のプロポーザル・マネジャーが決めると，プロジェクト・マネジャーは無理な開発スケジュールや開発コストの過少見積もり，技術者不足などに悩まされ，大変な苦労をする可能性が高い。一歩間違えば，失敗プロジェクトの道をひた走ることにもなりかねない。
とはいえ社内の事情により，別の人が担当せざるを得ない場合も多いだろう。そうした場合は，プロジェクト・マネジャーに任命される予定のエンジニアが，契約前の早い段階から積極的にプロジェクトの提案や計画に首を突っ込み，「それはできない」，「こうすべきだ」と，堂々と主張するべきである。他人の作った計画に従って仕事を粛々とこなすだけでは，プロジェクトの成功はおぼつかない。
今回は，前回に続いてゲストに神野幸英氏を招き，プロジェクト開始前の計画作業の進め方と，主要な作業項目について解説してもらう。
ここで取り上げた作業は極めて多岐にわたる。「時間と予算が限られ，受注できるかどうかも分からない提案段階で，こんなに多くの作業は実施できない」と思われるかもしれない。しかし，プロジェクトをスムーズに立ち上げ成功に導くためには，本来はここで説明したすべての作業を実施するべきだ。少なくとも，受注の可能性が高い案件や戦略的に重要な案件については，なるべくすべての作業を実施するよう努力して欲しい。（布川）
開発のスコープを決める
プロジェクト開始前の計画作業は，プロポーザル・マネジャーを中心に，技術スペシャリストや営業担当者で構成する「プロポーザル・チーム」が担当する。プロジェクト発足後は，プロポーザル・マネジャーがそのままプロジェクト・マネジャーになり，技術スペシャリストもチーム・リーダーとして残るのが普通だ。
図1に，筆者がこれまでに実施してきたプロジェクトにおける計画作業の手順を示した。以下，図に沿って説明していこう。
 |
| 図1●プロジェクト開始前に実施する計画作業 |
最初にプロジェクトのスコープ（範囲）を明確にする。この作業では，まずユーザー企業から受け取ったRFP（提案依頼書）に基づいて，システム化対象となる現行業務や現行システムの資料（現行業務フローや業務手順書，業務改革や改善の方針など）を分析する。この際，他社のシステム事例の調査や，ユーザーへのヒアリングを行うこともある。次にこの分析結果をもとに，プロジェクトが対象とする業務やシステムの大枠を把握したうえで，データや機能を洗い出して開発範囲を特定する。
もちろん，より具体的な開発範囲の決定は要件定義作業の中で行うわけだから，この時点では概要レベルの範囲（主な業務名や主な機能／データ）を特定できればよい。提案段階で開発範囲を詳細に決めすぎると，かえってプロジェクトを制約してしまい，プロジェクト開始後にコスト，スケジュール，開発の優先付けを柔軟にコントロールできなくなる。これは，システム開発プロジェクト全般に通じる鉄則なので，ぜひ守って欲しい。
日本IBMでは，開発範囲の概要を決める作業にDFD（Data Flow Diagram）を活用している。本連載ではDFDを用いた図表を多数掲載しているので，読者にはおなじみであろう。DFDを実際に書いてみるとすぐに分かるが，データが欠落しているとプロセスやファイル同士がつながらない。このため，どんなデータが欠落しているのかを即座に見付けることができる。この欠落部分をユーザー側に確認しながらDFDの作成を進めれば，システム化を予定する部分／しない部分を含めて，対象業務全体を把握しやすくなる（図2）。
 |
| 図2●不明点や範囲を明確化していくためのDFDの例 [画像のクリックで拡大表示] |
「ユーザーはDFDを理解できないのではないか」と思われるかもしれないが，表記自体は4つの記号しか使わないシンプルなものだ。普通は簡単な説明で理解できるようになる。
この段階のDFDは，見積もりの根拠を示せる程度の詳細さでよい。筆者の経験では，DFD1枚につき7つ程度のプロセスを配置するとして，10数万から数十万ステップ規模程度の開発で数枚～10枚程度，それ以上の規模でもせいぜい20枚前後のDFDを書けば，全体を見渡せる。
ソリューションを最適化する
開発範囲を決めたら，次に適用可能な各種のソリューションの検討を行う。新システムを実現するためのシステム形態（Webシステム，クライアント／サーバー，ホスト集中など）や対象業務のクリティカル度合いのほか，トランザクション・ボリューム，パフォーマンス，品質，セキュリティなどを十分考慮したうえで，ハードウエアやOS，ミドルウエア，ネットワーク，開発ツール，開発言語，パッケージ適用の可否などを，具体的な製品名や数量，キャパシティまで含めて決定する。もちろんこの段階での詳細さは，提案書に記載するシステム構成やソフトウエア構成，ネットワーク構成を決められる程度でよい。
ここで重要になるのは，コスト削減や納期短縮，品質向上の観点での「最適化」である。例えば，「必要以上に余分な機能を作らないためにはどうすればよいか」，「既存のソフト部品を購入して早く安く作れないか」といったことを検討する。最近のプロジェクトは，この検討を十分に行ったかどうかで，その成否がほぼ決まってしまうと言っても過言ではない。
もし，プロポーザル・チームに最適化のための知識が不足していれば，遠慮なく他のメンバー，例えば他部署のスペシャリストの知恵を借りるべきである。筆者の担当したプロジェクトでも，自社製品にこだわらないオープンな視点に立ったスペシャリストの意見を聞きながら，市販のミドルウエアや開発ツールの採用を比較・検討したことが，大いに役立った。
開発範囲の特定とソリューションの最適化は，開発規模の見積もりやコスト計画，要員見積もり／手配のベースとなる重要な作業である。実際のプロジェクトでは，プロポーザル・チームが総がかりで，数日間（極めて大規模な場合でも数週間以内）といった短期間に集中して行っている。
