システム外注、ＲＦＰ
ＲＦＰ（Request For Proposal：提案依頼書）は、なぜ、何をしたいのか（Ｗｈｙ、Ｗｈａｔ）を示し、提案書はどのように解決しいくらかかるのか（Ｈｏｗ、Ｈｏｗ Ｍｕｃｈ）を示すものだといえます。ＲＦＰは業務要件を示したものであり、提案書はそれを情報システム開発の観点からシステム要件として再定義したものだともいえます（参照：要件定義でのトップダウンとボトムアップ）。
ビジネスの課題をＩＴを活用することで解決したいが、その対応策を提案してほしいし、その実現の費用を知りたいために、ＲＦＰを作成するのですから、解決すべき課題と開発すべき情報システムに必要な機能を明確に示し、開発者（受注者）が開発費用を適切に見積もるための情報を提供する必要があります
（具体的内容）。
ＲＦＰにより提案書が作成されるのですが、内部検討が不十分なままに「販売システム一式」的なＲＦＰにしたのでは、ベンダはどのようなシステムにしてよいかわかりませんから、適切な提案は得られません。
ＲＦＰと提案書に基づいて相談し、それにより開発すべきシステムの仕様書が作られ、それに基づいて契約が行われ、システム開発が行われるのですが、あいまいなＲＦＰや提案書では、システム仕様書になるまでに大きな手間や費用が発生します。
システム仕様書があいまいなままにシステムを開発したら、役に立たないシステムになる危険があります。
また、提案書には見積金額が記入されています。その後、契約にいたる段階で再見積が行われますが、提案書の金額がベースになるため、ＲＦＰの内容が、金銭的なトラブルの原因になることが多いのです。
この工程にかかる費用は開発費用に加算されるでしょうし、発注者の能力を危惧して割高な見積をしたり、甘く見て開発に初心者を割りつけたりするかもしれません。
適切なＲＦＰを作成するには、自社に高い能力が求められます（注）。特に人材が乏しい中小企業では、ＩＴコーディネータなどコンサルタントの協力を得るのが適切でしょう。しかし、その場合でも、そのコンサルタントに適切な説明ができなければなりません。
発注を予定しているベンダに依頼するのでは、ベンダに都合のよいものになるのは当然ですので、絶対に避けるべきです。ところが、現実には、自社でＲＦＰを作成しているのはむしろ少ない状態です。それどころか、発注先にＲＦＰ作成を依頼していることもあるのです（図表）。
ベンダに依頼する場合には、
・ＲＦＰ作成を委託するベンダと実際の情報システム開発を委託するベンダを別にする
・開発予定ベンダの場合は、要件定義は自社で行い、文書化だけをベンダに依頼する
などが求められます。
（注）成熟度が未熟な企業が適切なＲＦＰを作成するときに当惑する事項
・実務ですら何をするべきかがわからない
☆
・どのようなシステムにすればよいのかわからない
☆
・どのように説明すればよいのかわからない
☆
・どんな条件を提示するのかがわからない
☆
「情報化にあたって，目的を明確にすることが重要だ」というが，究極的な目的は明確だ。「儲けたい」のだ。もっと詳細にというのであれば，「今年中に期間損益をプラスにするために○○億円の利益，３年度には累積赤字を解消するために○○億円の利益」と数値的に示すことすらできる。でも，どうしたら儲かるかがわからないのだ（わかっていることは当然これまでにやってきた）。まして，どのようなシステムにすればよいのかなどは見当もつかない。ともかく販売が増加することが儲けることに直結するだろうから「販売システム一式」としたのだ。ベンダは「ソリューション」を売り物にしているのだから，情報化で儲ける算段を持っているのだろう・・・。
これはあまりにも極端な例ですが，これまで経営戦略や情報化構想などに関心を持っていなかった企業では，これに近い状況のようです。このような状況では，適切な情報化は期待できません。情報化検討以前に経営戦略の策定をする必要があります。経営戦略の策定やそれを受けた情報化戦略の策定にはいくつかの方法がありますが，その説明には膨大な紙面を要しますので，別の機会に譲ります。
当社は部品メーカーである。利益を上げるには，顧客の納期短縮の要求に応えて欠品を防止すること，コストダウンのために在庫の削減が重要である。それには需要が予測できればよい。ここまではわかるのだが，需要予測をするためにどのような情報システムが必要なのかわからない・・・。
コンピュータで需要予測ができればよいのですが，それを直接に解決する情報システムは現実には存在しません。そもそも需要予測をするには，需要を左右する要因は何か，その要因に関連する先行情報は何か（数値データだけでなない）などがわかっていなければなりません。需要予測のためのソフトもありますが，その多くは過去の実績を統計的な手法を用いて予測するものです。そのような単純な手段が現実に役立つことは稀でしょう。
それで，需要予測に直接応えるのではなく，それの前提の一つとして「受注状況や在庫を正確に把握する」ための受注システムや在庫システムを構築する必要があります。このように，ステップ・バイ・ステップで情報化を進める総合的な計画を考えることが肝要なのです。
受注システムや在庫システムを構築することになった。現状の受注業務やそれの望ましい形態も検討した。しかし，それには受注の仕方，在庫の確認，伝票のデザイン，過去の受注の分析など，いろいろな改善提案があり，それをどうまとめるのかわからない。どのような情報システムがほしいのかがわかったが，情報技術に弱いので，どう説明すればベンダが理解できるのかわからない。ベンダが求める事項を聞き出してほしい。それで「委細面談」としたのだ・・・。
このような要件を調査分析して適切なシステム仕様を設計することは，情報技術のなかでも最も高度な技術ですし，豊富な経験を要求されます。情報システム部門すら存在しない企業に，このような能力を持つ人材がいるとは思えません。
たとえば「画面が出るまでの時間」が重要だということは，いわれれば成程と思うが，事前にそんなことまで気づかない。後になって文句をいったら「ＲＦＰで要求されていないから・・・」と逃げられては困る。また，応答時間は短いほうがよいのに決まっているから適当に１秒と書いたら，それを実現するために途方もない費用を請求されるのも困る・・・。
情報技術の経験や常識がないと，何を要件にする必要があるのか，どのレベルにしてよいかを示すことは困難ですし，開発に関する条件や契約事項に何をあげればよいのか当惑します。しかも，それらが明確になっていないために，後になって大きな問題になることが多いのです。