RFP（提案依頼書）
ユーザー企業がITベンダーに対して、詳細な提案書を求める文書。新システムの目的を文書にして正確に伝えることで、事後のトラブルを最小限に抑えられる。 RFPは「提案依頼書」の頭文字です。ユーザー企業がIT（情報技術）ベンダーに対して、「こういう取り組みをしようと思うので、提案を出してほしい」と依頼する文書のことです。書式は一定ではありませんが、従来システムの現況、新システムの目的、性能や機能に対する要望、プロジェクト体制、大まかな希望納期・予算などの情報を盛り込むことが多いようです。システムベンダーはこれを基に詳細な提案書などを作成し、その内容をユーザー企業が評価します。 効果◆あいまいさを排除 一般に、企業がほかの企業に仕事を依頼する前段階では、調達部門などがRFPに相当する文書を用意することが多いはずです。ただしシステム業界では、“口約束”だけで済ますケースがあり、稼働後に「この機能がな
業務要求の調査対象
実際に業務要求の洗い出しを行う場合の調査対象について説明しよう。調査の対象は，大きく分けて三つある（図3）。 （1）エンドユーザー（実際のシステム利用者だけでなく部門のマネージャも含む） （2）ドキュメント類 （3）現行システム この調査対象は，RFP作成者が誰なのかによって，実は大きな違いがある。例えば，エンドユーザーがRFP作成者の場合は，（1）は自分自身ということもあり得る。そこで，今回の説明では便宜上，RFP作成者は外部のコンサルタントという想定の基で行うこととする。エンドユーザーや情報システム部門をRFP作成者と想定する場合と比べて客観的な立場であり，様々な立場の読者の参考になると考えたからだ。 （1）のエンドユーザーに関しては，本連載中，業務要求の洗い出し・取りまとめのためのヒアリング・テクニックを説明する次回に解説する予定だ。以下では，（2）のドキュメント類から解説していこう
RFPにおける業務要求の洗い出しの目的とは
業務要求の洗い出しといえば，ITエンジニアであれば真っ先に思い浮かべるのは要件定義であろう。RFPの業務要求と要件定義はどこが違うのか。結論から言えば，行う作業やアウトプットは基本的に同じ性質のものである。ただし，RFPと要件定義では目的が異なる。もちろん，RFPと要件定義どちらも最終の大目的は「システム構築を成功させ，そのシステムが経営戦略や事業目標の達成に寄与すること」であるが，短期的な目的で言えば，以下の違いがある。 RFP：提案内容と見積もりから最適なベンダーを選定し，調達を適正に行うこと 要件定義：システム開発の範囲と要求仕様を業務の観点から明確に定義すること RFPは調達フェーズの作業の一つであることをあらためて認識したい（図2）。 また，しばしば「RFPは要件定義をきちんと終わらせてから書くものなのか」「RFPを書けば要件定義はやらなくてよいのか」といった質問を受けることがあ
RFPの基本構造
RFPを作るときに最も重要な項目の一つが，業務要求である。今回は，業務要求の洗い出しと取りまとめ方について解説していく。 業務要求について詳しく見ていく前に，まずはRFPの基本構造について考えてみよう。RFP（Request for Proposal：提案依頼書）を文書として考えると，その最も基本的な構造は図1のようになる。 ビジネス文書の「枕詞」ともいえる表紙・挨拶・目次がまずあり，それに続いてRFPの趣旨（目的・背景・狙い）が続く。前回説明したように，趣旨は非常に重要であり，最初に持ってくるのがよい。次に，RFPの基本要素である「何を・いくらで・いつまでに」を具体的に記載する。特にシステムに求める「何を」は，大きく次の三つに分類できる。 （1）業務要求 （2）技術要求 （3）運用要求 この中で最も重要で，RFPの中心的なコンテンツとなるのが，今回のメインテーマである（1）業務要求である
【連載】今さら聞けない RFPによる調達&提案ガイド (11) 機能要件の実現に必要な機能を定義する要件 | エンタープライズ | マイコミジャーナル
RFPに記載すべき最も重要な要素であるシステム要件は機能要件と非機能要件から構成されています。前号と重複するところもありますが、非機能要件を作成する方法を解説するにあたって、機能要件と非機能要件についておさらいしておきましょう。 前号では機能要件について、「システムを利用して何をやりたいか」を説明したもので、「業務上の付加価値に直接的に関係するもの」だと述べました。例えば、「前日の商品別売上実績を翌日の9時までに見られるようにしてほしい」「従業員の残業時間を翌月の第1営業日までに集計してほしい」などが、機能要件に当たります。 対する今号のテーマである非機能要件とは「その機能をどのような品質で利用したいか」を説明したものであり、「想定される環境下でその機能を問題なく利用し続ける」ための要件となります。 各種標準化団体が非機能要件について定義しているので、以下に紹介しましょう。 非機能要件とは
止まりかけたRFIDの導入案件 気付きを与え、壁を打ち破る
顧客の要望を聞き、営業担当者がまとめたシステム概要図。これを見た顧客はシステム導入計画の“欠陥”に気付いた。さらなる顧客支援が、今度は顧客が突破口を開く後押しとなる。 「我々がやりたかった単品管理は無理だ。このプロジェクトは見送るべきか」。 音頭金属の社長である音頭則靖は、提案書を見つめながら心の中でつぶやいた。提案書は、RFID（無線ICタグ）ソリューションを提案したソーバル（東京都大田区）の営業部第2営業グループ次長である脇義昌が、音頭金属に対し作成したものだ。 音頭が注視するページには生産工程管理システムの概要図があった。音頭の考えるRFIDの活用方法をヒアリングし、分かりやすく脇がまとめたものである。 音頭金属の主力事業は「カウンターウェイト」と呼ぶ、クレーンやショベルなどの重機に取り付けるおもりの製造だ。音頭は脇が作った図を見て、自分たちが想定したRFIDの活用方法では、同社が製
形の上で公平にすると金がかかる - novtan別館
このまま設計できるんでは、と思われるような詳細なRFPを受け取る。なんかこう、出来レースの当て馬にさせられている疑惑とかもある。入札を行っても、一番安いところには必ずしもならない。妥当な提案、特に裏に秘められた意図的なものを汲み取った提案は当然事情に通じているものが有利だったりする。でも、形式上、こういうことをせざるを得なかったりする。RFPを出してからプロジェクトが始動するまでのコストと期間を考えると、もったいないことも多い。 また、予算の効率的な活用および透明性の確保に対し、国民の目が厳しくなっている昨今、官公庁におけるIT関連投資についても見直しが求められるようになりました。こうした世論を受けて、情報システムにかかわる政府調達制度を見直す動きがここ数年顕著になってきており、上記IT戦略にも、効率的な情報システムの調達を目指す政策が盛り込まれています。 公共サービスにおける「システム導
過ぎたるは及ばざるがごとし 作りすぎたRFPの悲劇：ITpro
「これは大作ですね…」と思わず筆者はうなってしまった。本当にRFP（提案依頼書）として作られたものなのか？とにかく分厚い。内容を見ると業務フロー図がその大半を占めている。一つ，質問をした。「この業務フローは誰が作成したのですか？」「エンドユーザー数人に作らせました」と情報システム部のマネージャA氏は回答した。それで筆者は合点がいった。 ある中堅企業B社でのことだ。現行業務システムの陳腐化が目立ち，再構築が必要という判断が下った。情報システム部を中心にRFPを作成することになった。そこでA氏を中心としたRFP作成チームが編成され，RFPを作成した。だが，ベンダー数社を呼んで提案依頼を行ったところ，すべてのベンダーから提案に対して積極的な姿勢を示してもらえなかったのである。 「提案したいが，これはちょっと…」というのが共通した態度であったらしい。その後，どうせ再構築するなら別の業務システムも対
景気後退の局面はユーザ主体でSIがかわる - ひがやすを技術ブログ
日経平均は、7000円割れが目の前ですね。企業の業績の下方修正も相次いでいますが、これらの下方修正は、最近の急激な円高・株安の前に予想したものだと思うので、さらに追加の下方修正が入るのではないでしょうか。 厳しい景気後退の中、われらSI業界が、業績回復に向けて、効率的な開発の方向へ舵を取っているかというと残念ながらそうはなっていない(と思う)のが現状です。 これまでは、多少高くても、安心感やブランドにお客様は金を払ってくれた。そんなこともあって、開発の生産性よりは、生産性が多少低くても確実な開発が好まれました。 例えば、プログラムと一対一に対応するようなプログラム設計書は、書くだけ無駄。そんなものより、プログラムを書いたほうがはやいと私は思っています。しかし、汎用機時代から脈々と受け継がれてきた、そして時代にあっていないプログラム設計書が今でも使われているのは、過去にうまくいっていたことを
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
【連載】今さら聞けない RFPによる調達&提案ガイド (15) 簡単ではない提案書の評価 | エンタープライズ | マイコミジャーナル