ここから本文です

明瞭な「提案依頼書(RFP)」の書き方--ビジネス文書作成術

5/24(水) 7:10配信

@IT

 連載「エンジニアのためのビジネス文書作成術」、第1回は「議事録」の書き方を、第2回は「要件定義書」の書き方を学びました。第3回は「提案依頼書(RFP)」をWordで作ります。

【段落スタイルの推奨パターン-各スタイルの対象範囲】

 提案依頼書(RFP)とは、発注者(ユーザー)が、自分たちが提案してほしいことを具体的な「内容(要件)」にまとめた文書です。受注者(ベンダー)が「提案書」を作成するためのインプット(材料)になります。

 RFPはシステムの「実装内容」だけでなく、自社とベンダーの「責任関係」を決める文書です。「役割分担」は、そのまま契約内容に跳ね返ります。曖昧な表現や適切ではない割り振りは厳禁です。

 以下は、RFPが曖昧だったために、発注者の意図と違うものが作られた例です。

→敵モビルスーツの攻撃を防ぎつつ反撃できる武器を開発すること byオデッサ基地司令→実装はどうなった?
http://www.atmarkit.co.jp/ait/articles/1705/22/news015.html

 こうした思い違いを防ぐには、ユーザー、ベンダー双方が「委託範囲」をよく理解しなければなりません。「何がベンダーからユーザーへ引き継がれ」「どういった体制・スケジュールの下で行われるか」も明確にする必要があります。「提案ルール」も一緒に提示すれば、ユーザーの期待した形でベンダーは提案できます。

●RFPに含める項目

 RFPは次のような章構成で作成しましょう。

○RFPの章構成
1. 委託範囲
2. 納品成果物
3. 体制・役割分担
4. スケジュール
5. 前提条件
6. 応札要件
7. 費用
8. 提案手続き

 サンプルとして、ITコーディネーター協会が発行する「RFPのドキュメント見本」を参照すると良いでしょう。

 ベンダーはこのフォーマットに慣れ親しんでいますので、似たような形でRFPを示せばベンダーの提案負荷を減らせます。また、「検討漏れ」を未然に防ぐことも期待できます。

 次に、各章の内容を見ていきます。

 システム自体や作成文書に不備がないことをベンダーに必ず保証してもらいたい場合、契約形態は「請負契約」が適しています。そうでないものは「準委任契約」とします。

1 委託範囲

 「委託範囲」で依頼したい提案の「概要」を定義します。「案件目的」「業務概要」「システム化の範囲」「全工程のスケジュール」が当たります。

 「契約委託範囲」「機能、非機能要件」「作業要件」も明文化します。

○必須記述項目
・対象業務名
・対象システム
・調達対象の内容
・情報システム要件
・規模/性能要件
・信頼性要件
・情報セキュリティ要件
・テスト要件
・移行要件
・教育/研修要件
・保守/運用要件

 上記は、必須記述項目です。提案書にどんなプラスアルファを盛り込んでくるかはベンダー次第ですが、最低限の水準は必ず示しましょう。

2 納品成果物

 「納品成果物」は、契約後の「成果物一覧」と、その「納期」です。

 納品成果物の「検収方法」もRFPで指定しましょう。「工程ごとの成果物(検収物)」を指定し、「ユーザー承認に要する期間」も示します。

3 体制、役割分担

 「体制、役割分担」では、委託業務を推進する体制、委託者と受託者の役割/責任分担を定義します。

 「体制図」「役割分担表」「再委託(二次請け以降)の扱い」を指定し、「現場管理責任者」の提示を求めます。

 重要なのは、委託するユーザー企業がベンダーをどれだけ主体的に管理できるかです。

 多重請負構造では、ユーザーやプライムベンダー(直接契約する一次請けベンダー)の統制が現場の二次請け以降のメンバーにまで浸透しないことがあります。これを防ぐため、「参画メンバーはプライムベンダーとその協力会社(二次請け)までに限る」という制約を設けることもあります。

4 スケジュール

 「スケジュール」は、委託業務の「実施スケジュール」を定義します。

 「マスタースケジュール」「マイルストーン」「各タスクの終了条件」を指定し、「順守すべき期日」をベンダーに示します。

 各マイルストーンの達成承認における「合意形成のリードタイム」と「段取り」は、可能な限り明確化しましょう。意思決定の合意形成に1カ月必要なら、それに関係するマイルストーンは実質1カ月前倒しで設定しなければなりません。

5 前提条件

 「前提条件」として、「コンプライアンス規定」「作業関連規定」「その他」を以下の観点で整理しましょう。

・機密情報、個人情報の取り扱い
・セキュリティ対策
・プロジェクト作業場所
・資料提供/返却ルール
・プロジェクト管理標準
・開発標準

 ベンダーに委託する内容に「機密・個人情報」が含まれる場合は、取り扱いルールを必ず定義しなければなりません。

 「プロジェクト作業場所」をどこにするのかは、金銭的に大きなインパクトがあります。

 ユーザーが空室を提供できない場合、ベンダーは新しくプロジェクトルームを契約しなければなりません。20人を収容できるプロジェクトルームを山手線沿線で確保する場合、光熱費込みで月100万円以上は必要です。1年以上続くプロジェクトなら、1000万円以上の追加支出が掛かります。

 「プロジェクト管理標準」は、多くのベンダーが「PMP(Project Management Professional)」を提案してくるでしょう。

 しかし、クイック&多段階リリースが求められるWeb系システムなどは、PMPで用いられる「EVM(Earned Value Management)」による進捗(しんちょく)管理だけでは実情を把握しきれないこともあります。その場合は、ベンダーに知見を積極的に提案してもらいましょう。

 ユーザー企業に「開発標準」があるなら、それを前提としてベンダーに提案してもらうと、過去に構築したシステムの共通仕様と合わせられます。

6 応札要件

 「応札要件」は、委託する業務をベンダーが遂行するために必要となる「条件」を提示します。

 個人情報を扱うシステムで「プライバシーマーク」と「ISMS認証(情報セキュリティ管理に関する認証)」を取得しているベンダーに限定して提案書を受け付ける、などです。官公庁の案件は、「CMMI(Capability Maturity Model Integration:能力成熟度モデル統合)」のレベル3以上を応札要件としています。

 応札要件を指定することで、不測の事態が生じた際にも影響を最小限に抑制できます。

○契約条件に定義する内容
・契約形態(請負契約/準委任契約)
・契約変更/解除ルール
・契約有効期間
・想定外事象発生時の対応(瑕疵担保責任)
・業務委託料、諸費用、支払方法
・成果物権利

 ユーザーのリスクを考慮すると、RFPで依頼する規模のシステム開発は請負契約を採用することが一般的です。

 しかし請負契約は、基本的に成果物の「著作権」はベンダーが所有し、改変や他社への譲渡(運用保守フェースでの他社による改変や引き継ぎ)を認めないとされることもありますので、注意が必要です

7 費用

 「費用」には、提案金額に関する「ルール」を示します。

 「費用総額/内訳を提案書に記載する」「資産と役務を分けて示す」「稼働前費用と稼働後費用を区分する」「見積もり内容は『システム一式』ではなく『明細』と『価格』を記載する」、など期待することをはっきりとRFPに記載します。

 共通の「見積もり入力シート」を各ベンダーに配布すると良いでしょう。

8 提案手続き

 「提案の手続き」は、ベンダーが提案書を提出する際のルールを記します。

・提案書を提出する窓口
・納品方法
・納品期限
・RFPに関する問い合わせ窓口
・提案受領後の選定プロセス
・選定結果の告知

 「納品方法」は、紙媒体/電子媒体の「数」を指定します。容量を勘案し、提案書の一部(エグゼクティブサマリー/見積もり明細など)を別途電子メールで受け取る方法もあります。

 納品期限は日にちだけでなく、「時間」まで厳密に指定しましょう。

●RFPの各項目はスタイルで整える

 Wordの「スタイル」を活用して、読みやすくて分かりやすい「RFP」を作成する方法を伝授します。

 まず、最も利用頻度が高い「段落スタイル」のパターンを作ります。初期設定で表示対象に含まれているスタイルの中から、「図1」で示したものを使い続けます。この中には幾つかのリンクスタイル(段落+文字)が含まれています。

 以下のスタイルを最初に作り、文章を書き加えていくごとに、いずれかのスタイルを割り当てると、読みやすくて更新しやすいWord文書を作れます。

◆1 標準
◆2 ヘッダ
◆3 フッタ
◇4 右寄せ
◆5 表題……………………アウトラインレベル:1
◇6 見だし 0 -文章
◆7 見だし 1………………アウトラインレベル:1 ※章レベル
◇8 見だし 1 -文章
◆9 見だし 2………………アウトラインレベル:2 ※節レベル
◇10 見だし 2 -文章

※階層を深める場合は、アウトラインレベルの3以降を順番に設定したスタイルを作成する
※「◆」は最初から定義されているスタイル(組み込みスタイル)
※「◇」は新しく作成するスタイル

 文書は、階層構造に沿って「見だし」と「文章」のスタイルを使います。

○見だしのスタイル

 見だしのスタイルを設定すると、読みやすい文章になります。

 見だしのない文章はメリハリがなく、どの部分に何が書かれているかを把握するのに時間がかかるため、相手から理解を得にくくなります。

○文章のスタイル

 文章のスタイルを設定すると、相手に伝わりやすい文書を作成できます。

 例として、「段落スタイル:1 標準」を考えます。「標準」スタイルはWord文書で最初から定義されており、他のスタイルでは「基準にするスタイル」に指定されています。このスタイルは、単純にWord文書上で左端から右端までを平文で書くために使うものです。

 文章を見やすく、分かりやすく、伝わりやすくするために、「標準」スタイルに変更を加えます。

 変更するのは2か所。

 「日本語フォントの変更」で、「MS明朝体」を「Meiryo UI」にする。および「グリッド線に合わせる」のチェックを外し、無効化します。

 初期設定の「MS明朝体」はフォントの粗さが目立つので、Windows7以降で標準フォントになった「Meiryo UI」に切り替えます。

 「Meiryo UI」は、字間を読みやすく自動調整します。1行当たりの文字数がバラつくため、文字数を常に一定にしたいなら、「メイリオ」という等幅フォントを指定します。このフォントは日本語文字を全て同じ幅(等幅)で表示できます。

 グリッド線に合わせるチェックが有効になっていると、行間を微修正してもページ中のけい線単位に無理やり修正されます。チェックが有効なままで、前述の「メイリオ」のように文字の上下幅が広めに設定されたフォントを選ぶと、行ごとの間隔が大きく開いて見栄えが悪くなります。

 他の項目も、自分が見やすいスタイルを設定しましょう。

 今回は「提案依頼書(RFP)」の書き方を解説しました。次回(5月29日掲載)は、「謝罪報告書」の書き方を説明します。

書籍
外資系コンサルのビジネス文書作成術
吉澤準特著 東洋経済新報社 1944円(税込み)
大手コンサルティングファームでドキュメンテーションスキルを指導する著者が、ロジックの組み立てと効果的な表現をWord上で思い通りに実現するテクニックを解説する。

連載「エンジニアのためのビジネス文書作成術」は、書籍「外資系コンサルのビジネス文書作成術」(吉澤準特著 東洋経済新報社)を基に、出版社の許可を得て、筆者自身が@IT読者向けに再構成したものです。画像はWindows 7 + Word 2013上のものです。機能はWord 2013、2016のいずれでも使用できます
※書籍では本記事の内容を図解しています。是非ご覧ください。

筆者
吉澤準特
ITコンサルタント
外資系コンサルティングファーム勤務。ビジネスからシステムまで幅広くコンサルティングを行う。専門分野はシステム運用改善をはじめとするインフラ領域だが、クライアントとの折衝経験も多く、ファシリテーションやコーチングにも造詣が深い。
著書『資料作成の基本』『フレームワーク使いこなしブック』(以上、日本能率協会マネジメントセンター)『外資系コンサルの仕事を片づける技術』(ダイヤモンド社)など。

最終更新:5/24(水) 7:10
@IT