丸投げは失敗の始まり――調達マネジメント（1）：プロジェクトマネジメントスキル 実践養成講座（9）（2/2 ページ）

システム構築はRFP作成に始まる

　今回は、最近実際にあったプロジェクトでの話をベースにしたケースをご紹介したい。A社ではECサイトを運営している。このたび、業務拡大のためWebサイトの全面リニューアルを予定している。期日は半年後だ。担当プロジェクトマネージャ（初目手部長）はこれまで、主にWebサイトのデザインやユーザビリティを担当してきたが、システム構築の経験はない。

　要件の方は、Webサイトの表面的なデザインやユーザーの使い勝手といった部分はおおむねまとまっている。しかし、それ以外の部分、データベースや基幹システムとの連携などは未着手といった状況である。加えて、社内の状況は、経営層から各担当レベルまで各人がさまざまな思いを抱いている。経営層は売り上げに直結する施策を求めているし、現場では日々の業務負荷を軽減する施策を求めている。しかし、全員日々の業務が多忙などの理由から、要件は取りまとまっていない。

　このような状況で初目手部長は、何から手を付けてよいかさっぱり分からない状況である。しかし、放っておいても期日はどんどん迫ってくる。そこで知り合いのツテを頼って、業者をいくつか当たってみることにした。まずは矢見雲マネージャとのやりとりを見てみよう。

　次は出来杉マネージャ（今回は矢見雲マネージャとは別会社という設定）のケースを見てみることにしよう。

　より状況を具体的にイメージしていただくため少々ケースの説明が長くなったが、A社の混とんとしている状況がお分かりいただけたと思う。

このケースにおける問題点は、発注側で「何を狙いとして何をやるべきか、その全体像が明確になっていない」ことに尽きる。いろいろな関係者が日ごろ口にしていることが断片的に頭の中にある状況である。

　家を建てる話で考えてみよう。全体としてどういうコンセプトでどういう家にしたいのか、あるいは、部屋は何部屋必要で、どういう間取りにするかも決まってないのに、外観は茶色いタイル張りでということだけ決まっているような状況といえよう。このような状態で建築をお願いするとまず何が必要か。それは、基本的な方向性や要望の確認である。そしてここから設計図や完成予想図などの形で可視化されていくのである。

　システム構築においても同様で、まず目的・要件を「RFP」という形で「紙に落とす」ことから始まる。筆者はこの「紙に落とす」ことの重要性を強く訴えたい。

なぜ紙に書くのか

　図1と図2は、発注者から受注者への要件の伝達度を、伝達手段別にイメージ化した図である。

図1　発注者から受注者への要件の伝達のされ方と、その要件が実現されるまで

図2　発注者から受注者への要件の伝達のされ方と、その要件が実現されるまで。発注者、受注者双方で漏れや誤解が生じているが、図1に比べると漏れや誤解は少なくなっている

　図1は以下のことを表している。

　「実現すべき要件」には、発注者の「頭の中」で認識していることもあれば、気付いていないこともある。それを口頭で受注者に伝達する場合、認識していることのいくらかは漏れが生じる可能性が高くなる。そして、受注者は口頭で伝達されたことにより、誤解、聞き逃しなどによる漏れが発生する可能性が高くなる。そうして設計・開発された成果物は、発注者が実現すべき要件のうち、抜け落ちたり誤って実装されたりする部分が結果として大きくなる可能性が高い。過去、あるいは周りのプロジェクトを思い返すと当てはまるプロジェクトも多いのではないだろうか。

　一方、図2は、口頭ではなく「RFP」「提案書」という文書ベースでコミュニケーションすることで、双方が確認・検証可能となるため、口頭ベースでのコミュニケーションと比較して、漏れや誤解の可能性は小さくなることを表している。

　われわれコンサルタントは何にせよ、「紙に落とす」ことを極めて重要視する。それはなぜか。もちろん、相手にいいたいことを伝えやすくするためでもあり、後々に残すためでもある。しかし同様に重要なことは、書くことで自分の考えが整理できることにある。自分の考えが整理できていないと、口頭ではなんとなく表現できても紙に落とせない。ここでの考えとは、自分の理解、意見、主義・主張、認識している問題などを意味する。

　「正しく書けないことは、正しく話せない。正しく話せないことは正しく相手に伝わらない」のである。

　RFPの話に戻すと、RFPを文書化することのメリットは、大きく以下の3つにあるといえる。まずはこのポイントをご理解いただきたい。

• 相手に対して口頭や簡易的なメモなどで伝達する場合と比較すると、認識のズレを防ぎ正しく伝えることができる
• RFP作成作業そのものが、自社に対しては自社の要件整理（定義）となる
• 後々、プロジェクト関係者の共通認識を形成することができる

　RFPとは本来発注側が作成し、受注候補企業に提示するものである。最近は徐々に発注側の意識も向上してきているものの、ちまたのプロジェクトではまだまだ口頭や簡易なメモベースでRFP提示とするケースも少なくない。ここでいいたいことは、だからといって、発注側に責任を押し付けることではない。発注側のRFP作成と同様、受注側も「提案書」という形で自らの理解と主張を明文化する必要があるため、受注側も協力する必要があるということだ。

　相手の狙いやいっていることが分からない状態で作成した提案書に基づいたシステム構築が、どんな結果となるかはいうまでもないだろう。

RFP作成の勘所

　発注者と受注者は、RFPと提案書という文書を通じてお互いの理解と主張を確認する必要がある。その目指すべき形は図3のようなイメージとなる。

図3　RFPの目指すべき方向性。発注者から受注者への要件の伝達のされ方と、その要件が実現されるまでに、漏れや誤解がないことが分かる

　では、具体的にRFP（あるいは提案書と読み替えてもらって構わない）をどのように作成すればよいのか。ただ書けばよいというものでない。ただ分量が多いだけの文書はかえって逆効果にもなり得る。すでに多くの読者が経験していることと推察するが、「正しく書く」ということは非常に難しい作業である。以下にその勘所を解説する。

　「正しく書く」というためには、「広さ」「深さ」「表現方法」という3つのポイントがある。「広さ」とは、何について書くべきかである。RFPでいえば、要件といってもシステム機能要件から、業務要件、パフォーマンス要件、インフラ要件、データ移行の要件まで幅広く存在する。簡単にいってしまえば、目次レベルや項目レベルで必要なことは何かと考えればイメージしやすいであろう。「深さ」とは、どこまで書くかということ、つまりは記述レベルである。また、「表現方法」は、相手に誤解なく容易に伝わるかということである。

　さらにRFP作成に役立つ実践的なテクニックを紹介しておく。

●RFP標準文書やチェックリストの活用

　「広さ」「深さ」という観点で正しく記述できるように、社内や組織内でRFP標準文書（テンプレート）やチェックリストを準備し活用できるようにするとよいだろう。残念ながら組織に存在しない場合は、外部団体が提供するテンプレートの活用も可能なので以下に紹介しておく。

●複数者によるレビュー

　RFPで記述する内容は、システムの機能要件だけではなく、パフォーマンスやインフラ、あるいは、システム運用に至るまで多岐にわたっており、各領域の担当の複数者によるレビューが効果的である。

●相手への配慮

　相手に必要なことを正しく伝えることが重要である。自分の作る文書は以下のようになっていないか確認してほしい。

• 抽象的／あいまいな表現
• 複雑過ぎる図・表の多用
• 長過ぎる説明文／多過ぎる文字

　次回は引き続き、調達マネジメントの続きを解説し、特に協力会社の選定とその管理について紹介したい。

今回のまとめ