今回で最終回です。これまで5回にわたってRFPの内容や提案の受け方などについてお話してきましたが、最後にいくつかのTipsを紹介して、この連載を終了にしたいと思います。

第2回で目次と背景について考え、第3回には手続き上のことを整理してきました。今回は、いよいよRFPの核心ともいえる、「要求」について考えてみましょう。

今回は、「背景」についてお話します。提案を要求する背景をRFPで明らかにしておけば、ベンダーからより良い提案を引き出すことができますし、余りにも的を外した提案を抑制することができます。

　システムの品質を上げるには、テストをしっかり行っておくことが重要ですが、要件定義などに誤りがあれば、決めたとおりに出来ていたとしても誤りの作りこみはおこります。必ず原本に戻ってテスト・検証を行うことが大事です。

　よく「いつもと同じ」というニュアンスで要望が出されることがありますが、は「いつも同じ」はいつも同じではありません。なにが「同じ」なのかをはっきりとさせるところがトラブル削減のポイントです。

　システム開発において大切なことは、何を作るかについて開発依頼者と、開発受託者の認識しているものが一致していることです。そのために要件定義書は大変重要な書類となります。

　システム開発は物つくりです。できた製品でシステムの成否が決まります。一方、システムを作る目的は、システム装置を飾るために欲しいわけではなく、それを使って新しいビジネスや商品を実現したいのですから、正しく動いて、期待通りのビジネスや商品が実現する。これが大切です。予算どおり、期限どおりに出来上がっても、不完全なシステムだったら困ります。バグがないことはもちろんのこと、非機能要求などもきちんと分析定義して、使ってみて満足のいくシステムとしなければなりません。直接、要件定義書やプログラムなどを見るレビューに加えて、プロジェクトレビューをうまく使い品質向上を実現しましょう。