丸投げは失敗の始まり――調達マネジメント（1）：プロジェクトマネジメントスキル 実践養成講座（9）（2/2 ページ）
システム構築はRFP作成に始まる
今回は、最近実際にあったプロジェクトでの話をベースにしたケースをご紹介したい。A社ではECサイトを運営している。このたび、業務拡大のためWebサイトの全面リニューアルを予定している。期日は半年後だ。担当プロジェクトマネージャ（初目手部長）はこれまで、主にWebサイトのデザインやユーザビリティを担当してきたが、システム構築の経験はない。
要件の方は、Webサイトの表面的なデザインやユーザーの使い勝手といった部分はおおむねまとまっている。しかし、それ以外の部分、データベースや基幹システムとの連携などは未着手といった状況である。加えて、社内の状況は、経営層から各担当レベルまで各人がさまざまな思いを抱いている。経営層は売り上げに直結する施策を求めているし、現場では日々の業務負荷を軽減する施策を求めている。しかし、全員日々の業務が多忙などの理由から、要件は取りまとまっていない。
このような状況で初目手部長は、何から手を付けてよいかさっぱり分からない状況である。しかし、放っておいても期日はどんどん迫ってくる。そこで知り合いのツテを頼って、業者をいくつか当たってみることにした。まずは矢見雲マネージャとのやりとりを見てみよう。
初目手部長 「Webサイトのリニューアルを考えているのですが……」
矢見雲マネージャ 「お任せください。具体的な要件などもう少し詳しいお話をお聞かせいただけますか。あと文書ベースの資料が何かあればいただきたいのですが」
初目手部長 「デザイン周りやサイトの機能の要件は文書ベースであります。こちらでよろしいでしょうか」
矢見雲マネージャ 「ありがとうございます。じゃあ、後は口頭で説明をお願いします」
初目手部長 「分かりました」
（以下、プロジェクト概要と社内の状況を説明）
矢見雲マネージャ 「ありがとうございました。では、基本はいただいたドキュメントを貴社のご要件と考えて、これを実現するためのお見積もりやスケジュールをご提案という形でまとめてお持ちします。ここに書かれていない要件が出てきた場合は、できる範囲のことは対応させていただきますが、場合によっては別途御見積もりということでお願いしたいと存じます」
初目手部長 「よろしくお願いします」
次は出来杉マネージャ（今回は矢見雲マネージャとは別会社という設定）のケースを見てみることにしよう。
初目手部長 「Webサイトのリニューアルを考えているのですが……」
出来杉マネージャ 「このたびはお声掛けありがとうございます。では早速ですが、まず今回のリニューアルについてお話をお聞かせいただければと存じます。あとRFPのような形で貴社のご要望がまとまっていると助かるのですが、ございますか？」
初目手部長 「残念ながら、RFPという形ではまとまっていません。しかし、デザイン周りやサイトの機能の要件は文書ベースでありますし、状況や要件は私の方で大枠を把握していますので、口頭でご説明させていただきます。」
（以下、プロジェクト概要と社内の状況を説明）
出来杉マネージャ 「大体の状況はつかめました。あといくつかお話をお聞かせください。まず今回のリニューアルの目的はどの辺にあるとお考えでしょうか」
初目手部長 「業務拡大のためです」
出来杉マネージャ 「なるほど。業務拡大とは、貴社のビジネスを考えると取り扱いカテゴリ、あるいは、アイテム数の拡充と考えてよろしいでしょうか。あるいは、新たなビジネスの立ち上げなど別の要素を含んでいるのでしょうか」
初目手部長 「お考えのとおり、取り扱いカテゴリの拡大です。具体的には○○○の販売を開始しようと考えています。まったく新たなビジネスをということではありません」
出来杉マネージャ 「ありがとうございます。いまのシステムでの対応が難しい理由は何でしょうか。例えば、トランザクション増によるパフォーマンス悪化などが考えられますが」
初目手部長 「それもあります。しかし一番の狙いは、サイトデザインや使い勝手を含めたユーザーの利便性向上です。加えて、受注や入金確認、出荷などの通常業務も手作業が多く作業負荷が非常に高くなっています。その結果ミスなども起こりがちなので、これを機に改善したいと考えています」
出来杉マネージャ 「いまのお話で、ユーザーの利便性向上というテーマが挙がりましたが、これは今回の業務拡大との関連というよりむしろ、顧客の満足度を向上させ、売り上げの向上につなげることが狙いというように理解いたしました。つまり、売り上げの向上が本質的な狙いと考えてよろしいでしょうか」
初目手部長 「はい。そのとおりです」
出来杉マネージャ 「なるほど。売り上げの向上に向けた施策といってもさまざまな施策が考えられます。いまのお話はサイトに来たユーザーの離脱防止を図るための施策の1つと考えられますが、ほかにもユーザーの集客、クロスセリングやアップセリングなどの施策も必要になってくるかと考えます。その辺については、今回のプロジェクトでどうするかについてすでにお考えでしょうか」
初目手部長 「そうですね。頭の中にはいろいろとあるのですが、まだ社内でもはっきりとしたことは話ができていない状況です」
出来杉マネージャ 「分かりました。いまのお話以外にもまだいろいろありそうですね。業務負荷軽減の話とか基幹システムとの連携部分なども。いまそろっているドキュメントをベースに開発のご提案書を作成することも可能ですが、ユーザーインターフェイス周りの要件しかそろっていないので、それだけだと貴社の本質的な狙いや課題は解決しないと考えます。
われわれとしては、まず本当に貴社に必要なことは何かということを明確にすることが必要と考えます。
貴社の状況をお聞きすると、弊社がその段階からご支援させていただく、つまりは、プロジェクトの目的や主要施策、要件定義を行い、開発RFPを貴社と一緒に作成していくような提案を考えています」
初目手部長 「ありがとうございます。よろしくお願いします」
より状況を具体的にイメージしていただくため少々ケースの説明が長くなったが、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で記述する内容は、システムの機能要件だけではなく、パフォーマンスやインフラ、あるいは、システム運用に至るまで多岐にわたっており、各領域の担当の複数者によるレビューが効果的である。
●相手への配慮
相手に必要なことを正しく伝えることが重要である。自分の作る文書は以下のようになっていないか確認してほしい。
- 抽象的／あいまいな表現
- 複雑過ぎる図・表の多用
- 長過ぎる説明文／多過ぎる文字
次回は引き続き、調達マネジメントの続きを解説し、特に協力会社の選定とその管理について紹介したい。
今回のまとめ
- 「丸投げ型」調達マネジメントから脱却し、発注者も積極的に関与する「パートナーシップ型」調達マネジメントの実現を目指す
- まず、目的・要件の全体像を明確にする。そのためにRFPという形で「紙に落とす」ことの重要性を再認識する
- RFP作成による主な効果を理解する
- RFPや提案書によって認識のモレ・ズレを防ぎ正しく伝えることができる
- RFP作成作業そのものが、自社に対しては自社の要件整理（定義）となる
- 後々、プロジェクト関係者の共通認識を形成することができる
- 「正しく書く」には「広さ」「深さ」「表現方法」の3つの観点に注意すること
- 以下の具体的なテクニックを活用する
RFP標準文書やチェックリストの活用
複数者によるレビュー
相手への配慮
著者プロフィール
杦岡充宏（すぎおかみつひろ）
スカイライトコンサルティング シニアマネジャー。米国PMI認定PMP。関西学院大学商学部卒業後、アンダーセンコンサルティング（現アクセンチュア）を経て現職。製造業や流通業のCRM領域において、業務改革やシステム構築のPM（プロジェクトマネジメント）の実績多数。特に大規模かつ複雑な案件を得意とする。外部からの依頼に基づき、プロジェクトの困難な状況の立て直しにも従事、PMの重要性を痛感。現在は、同社においてPMの活動そのものをコンサルティングの対象とするサービスを展開している。
Copyright © ITmedia, Inc. All Rights Reserved.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。