提案依頼書の作成

提案依頼書は，開発するべき情報システムの要件をベンダ（情報システム開発業務の受託企業）に示して，提案を依頼する文書です。この開発業務を受託したいベンダは，システムの概要，開発期間，見積りなどを含んだ提案書を提出します。その提案書を比較検討して発注するベンダを決定します。
　自動車や什器を購入するのでしたら，既にあるものから選ぶのですから簡単です。特注の生産設備ならば詳細の打ち合わせが必要になりますが，それでも何を条件仕様にすればよいかはお互いにわかっています。ところが情報システムでは，目的も環境も千差万別ですから，不適切な提案依頼書では，ベンダはどのようなシステムを提案してよいかわかりません。それで，提案依頼書の作成が重要になるのです。

提案依頼書の内容

提案依頼書には通常次のような内容が記述されます。その見本は，
★ＩＴコーディネータ協会「ＲＦＰ・ＳＬＡドキュメント見本」（ http://www.itc.or.jp/w_tool/rfpsla/rfpsla_main.html）
を参照してください。

提案書への事務的手続き: 提案書に記述されべき内容・資料，提案期間，当社の窓口，提案に対する評価基準など，事務的な手続きを明示します。提案書の内容には，開発するシステムの提案，品質・性能，開発期間，費用見積などがあります。
システムへの要求事項: 開発するべきシステムの目的，実現すべき事項，システム実現後の業務の流れや必要となる帳票類，それに必要な主要データなどを記述します。社内でのシステム化検討資料を提案依頼書として整理しなおしたものだといえます。
開発環境等: 開発をどこで行うのか，システムの品質テストの方法，ユーザへの教育，保守サービスなどを記述します。
その他: ベンダの参加資格，契約の方法，著作権等ライセンスに関する条項などを記述します。

このように提案依頼書に記述するべき事項は多いのですが，ここでは最も重要な部分である「システムへの要求事項」に限定します。

適切な提案依頼書を作成することの重要性

ベンダは提案依頼書により開発するべきシステムの内容や見積をするのですから，提案依頼書はベンダが対象システムを十分に理解できる内容でなければなりません。

ベンダ丸投げの危険

とかく情報化の経験が乏しい中小企業では，自社で経営戦略や情報化計画の検討をする前に，適当なベンダを呼んで，システム化検討の段階から情報システムに関する分野をすべてベンダに丸投げするのは論外です。これでは，ベンダが自分に提案依頼書を作成するようなものですから，ベンダにとって都合のよいものになりがちで，必ずしも自社にとって適切な提案依頼書にはなりません。
　これは，必ずしもベンダが売上志向だからというのではありません。ベンダが責任のある提案をしようとすれば，ベンダが得意とする製品や技術を用いて開発できる仕様にするのは当然です。

「販売システム一式」的な提案依頼書の危険

丸投げは極端ですが，「販売システム一式，詳細は面談で」というような，漠然とした提案依頼書も多くあります。これは，情報に関する社内成熟度が未熟であり，社内でシステム化検討が十分に行われていないことの証明だともいえます。
　慎重なベンダは，そのような顧客を相手にしたのでは，システム開発で多くのトラブルが発生するリスクが高いと考えて，提案に応じないでしょう。
　提案が得られたにしても，その提案はベンダが適当に類推したシステムですので，自社のニーズに合致した提案になるはずがありません。再度説明を繰り返すことになり，それだけ費用と時間がかかってしまいます。表面的には無料サービスになるとしても，開発契約の金額に上乗せするでしょう。それに，ベンダは受注後のトラブル発生リスクが大きいことを予想して，その費用を上乗せするでしょう。あるいは，顧客が素人であることにつけこんで，２流・３流の技術者を割り当てるかもしれません。いい加減な提案依頼書では，結局は自社の損になるのです。

適切な提案依頼書の効果

十分に検討された提案依頼書であれば，ベンダは状況がよく理解できるし，それに合致した適切な提案をするでしょう。しかも，顧客の成熟度が高いことに応じて，その評価に耐えられるように，十分に検討した提案をするでしょう。
　さらに，適切な提案が得られれば，短期間で適切なシステム仕様書が作成できますので，開発に着手するまでの期間が短縮されます。また，この段階で両社の認識が合致するので，システム開発でのトラブルが少なくなり，期待した費用・納期・品質が達成される確率が高くなります。
　提案依頼書は，ベンダの提案を受けることが目的であり，システム開発仕様書ではありません。専門家であるベンダの創意工夫を引き出すことが目的なのですから，何をしたいのかは十分に提示する必要がありますが，どのようにして実現するかについては，特に重要な事項でない限り記述しないほうがよいのです。

提案依頼書の作成は難しい

このように，システム開発を成功させるには，適切な提案依頼書を作成することが大切ですが，提案依頼書の作成はかなり難しい要因があります。

実務ですら何をするべきかがわからない

「情報化にあたって，目的を明確にすることが重要だ」というが，究極的な目的は明確だ。「儲けたい」のだ。もっと詳細にというのであれば，「今年中に期間損益をプラスにするために○○億円の利益，３年度には累積赤字を解消するために○○億円の利益」と数値的に示すことすらできる。でも，どうしたら儲かるかがわからないのだ（わかっていることは当然これまでにやってきた）。まして，どのようなシステムにすればよいのかなどは見当もつかない。ともかく販売が増加することが儲けることに直結するだろうから「販売システム一式」としたのだ。ベンダは「ソリューション」を売り物にしているのだから，情報化で儲ける算段を持っているのだろう・・・。

これはあまりにも極端な例ですが，これまで経営戦略や情報化構想などに関心を持っていなかった企業では，これに近い状況のようです。このような状況では，適切な情報化は期待できません。それ以前に経営戦略の策定をする必要があります。

どのようなシステムにすればよいのかわからない

当社が部品メーカーである。顧客の納期短縮の要求に応えて欠品を防止すること，コストダウンのために在庫の削減が重要である。そこまではわかるのだが，それを実現するために，どのような情報システムが必要なのかわからない・・・。

コンピュータで需要予測ができればよいのですが，それを直接に解決する情報システムは，現実には存在しないと考えるのが無難です。需要予測ソフトもありますが，そもそも何のデータを用いて，どの期間で，どの程度の精度で予測するのかの検討ができていなければ，天のお告げのようなことになってしまいます。それの入力データが整備していなければ，いかに優れたソフトを用いても適切な予測ができるはずがありません。　それで，「受注状況や在庫を正確に把握する」ための受注システムや在庫システムを構築することになります。このように，ステップ・バイ・ステップで情報化を進める総合的な計画を考えることが肝要です。

どのように説明すればよいのかわからない

受注業務分野の合理化が重要だということになった。現状の受注業務やそれの望ましい形態も検討した。しかし，それには受注の仕方，在庫の確認，伝票のデザイン，過去の受注の分析など，いろいろな改善提案があり，それをどうまとめるのかわからない・・・。
　どのような情報システムがほしいのかがわかったが，情報技術に弱いので，どう説明すればベンダが理解できるのかわからない。ベンダが求める事項を聞き出してほしい。それで「委細面談」としたのだ・・・。

このような要件を調査分析して適切なシステム仕様を設計することは，情報技術のなかでも最も高度な技術ですし，豊富な経験を要求されます。情報システム部門すら存在しない企業に，このような能力を持つ人材がいるとは思えません。
　しかも，提案依頼書作成の解説書などでは，ＤＦＤ（データフローダイヤグラム）やＥＲ図（エンティティ－リレーションシップ図）なども資料として添付するべきだと述べています。これらが完成しているのであれば，システム開発の上流工程はほぼ完成したようなものですから，それができる人材がいる企業は限られています。

どんな情報を提示するのかがわからない

たとえば「画面が出るまでの時間」が必要だということは，いわれれば成程と思うが，事前にそんなことまで気づかない。後になって文句をいっても「提案依頼書にないから・・・」といわれるのでは困る。また，短いほうがよいのに決まっているから３秒と書いたら，それを実現するために途方もない費用を請求されるのでは困る・・・。

情報技術の経験や常識がないと，何を条件にする必要があるのか，条件をどのレベルにしてよいかを示すことは困難です。ところが，それが明確になっていないために，後になって大きな問題になることが多いのです。

ベンダとコンサルタントとの使い分け

自社に情報分野の専門家がいない場合には，外部の専門家の協力を得るのが適切です。それにはコストがかかりますが，不適切な提案依頼書により使いものにならないシステムを開発する危険にくらべれば，保険費用だと考えても安上がりです。
　この場合の専門家とは，ベンダと経営情報コンサルタントになります。ここでは，その両者の特徴と使い分けについて説明します。なお，一般論としては「コンサルタントの利用法」を参照してください。

ベンダに提案依頼書作成を依頼するのは，受注者に発注仕様を作らせることになりますので不適切です。
　ＩＴコーディネータや中小企業診断士などのコンサルタントは，発注側の経営者を支援することが任務ですから，その点では特定のベンダや製品にとらわれない公平な立場にあります。しかし逆に，特定のソフトやハードに関する知識はベンダには及びません。ですから，経営戦略に合致した情報システムの提案依頼書作成までの分野には適していますが，実際のシステム開発を依頼するのには不適切です。
　ベンダは開発業務の受注を期待しているので，提案依頼書作成業務も営業活動の一つだとして費用をサービス価格にすることもできます。ところが，コンサルタントはこの業務だけで収入を得ていますので，一般的にはコンサルタントのほうが費用がかかります。
　このように，業務分野や作業時間などを考慮して，両者を使い分けるのが効果的です。

システム化の検討や提案依頼書の作成は将来も多く発生します。また，システムを開発する段階でも，自社が行わなければならない業務は多くありますし，システム開発以前にできることをやっておけば，システム開発での費用や期間を削減することができます。しかも，自社で行うことにより成熟度が向上するのですから，自社でできることは自社で行うようにするべきです。当初は専門家の指導を受けるにしても，次第に自社でできるように知識の移転を図る必要があります。