RFP作成後に行う作業：RFPのレビュー
RFPチームでひと通りRFPを書き上げたならば，ベンダーに提示する前に，必ず社内レビューを受けることを強く推奨する。レビューの目的は，RFPに記載された要求に，漏れ，偏り，無理，無駄，矛盾がないかどうか，第三者の目を通してチェックすることである。 従って，レビューのメンバーとしてはRFPチーム以外に，業務要求の洗い出しのときに協力してもらったエンドユーザーに参加してもらうことが望ましい。さらにエンドユーザー部門，情報システム部門のマネジャーにも参画してもらいたい。可能であれば，実際に調達の段階で最終的な決裁権を持つ経営者や上級マネジャーに参加してもらえるとなおよい。それによって，調達の最後の段階（ベンダー決定から発注金額合意の段階）になって「俺は聞いていない」とすべてをひっくり返されるリスクを解消する事ができるからである。 プロジェクトを推進していて何が最もつらいかといえば，最後になって事
セキュリティに関する要求の取りまとめ方
セキュリティは現在のシステム構築において，最重要課題の一つと言っても過言ではないだろう。特に個人情報などの漏えいがあった場合は，その関連部門や情報システム部門が批判されるばかりでなく，全社的に企業イメージに深刻なダメージを受けてしまう時代となった。またウイルス被害もますます甚大になってきている。それらのセキュリティに関する技術要求の具体的な例とそのまとめ方について説明していこう（図6）。 （1）セキュリティポリシー 大企業や中堅，中企業クラスの規模であれば，ほとんどの企業が全社的なセキュリティポリシーを作成しているはずだ。企業によっては全社の汎用的なポリシーとは別に情報システムに係るセキュリティポリシーを保有しているところもあるだろう。例えば，セキュリティパッチの更新基準などのルールを厳格に定めているなどだ。基本的に新システムは最低でも全社的なセキュリティポリシーの下で管理されることになる
他システムとの連携に関する要求の取りまとめ方
新たにシステムを導入する上で，必ず検討しなければならないことの一つが，既存の他のシステムとの連携の必要性である。例えば現行の基幹システムが導入から長い年数が経過し，その陳腐化への対応のために再構築（リプレース）を行う場合，再構築の範囲に入っていない周辺のシステムに注目する必要がある。基幹システムなどの場合は，他の周辺システムにデータを渡したり，その逆にデータを受け取ったりしているケースが多い。そのようなデータの受け渡しが行われている場合は，新システムにおいても当然そのデータ連携機能が必須となってくる。 これまで述べてきた技術要求と違って，他のシステムとの連携というのはほとんどの場合，発注側企業の固有の事情となる。そのため，RFPの段階であってもなるべく正確に要求を伝える必要がある。特に連携するシステムが複数ある場合などは，漏れがあったり，混同したりなどのミスがあるとベンダーの見積もりが大き
システム能力に関する要求の取りまとめ方
新システムが業務要求をすべて満たし，機能的には問題がないとしても，例えばレスポンスタイムが遅く，画面遷移の度に10秒，20秒と掛かったのでは業務システムとしては使いものにはならない。あるいは1人2人のユーザーだとサクサク動くが，同時利用ユーザー数が増えるととたんに遅くなるというシステムも役に立たない。システムの適切なパフォーマンスとキャパシティを確保するために，RFPではこれらの要求を具体的に記述するべきである。 まず，パフォーマンスに関する技術要求の具体的な例とそのまとめ方について説明していこう（図4）。 （1）画面遷移のレスポンスタイム（通常時） 一般にエンドユーザーが業務としてシステムを利用する場合，ストレスを感じない画面遷移の時間は3秒以内といわれている。これが一つの目安となろう。ただし，業務によってはもっと速いレスポンスタイムが必要な場合もあるし，逆にもう少し遅くても許容されるケ
RFP作成の七つのポイント
本連載も最終回となった。実践編ということで，RFP作成の作業で使える手法やテクニック，あるいは留意すべき点などを解説してきた。繰り返しになる部分も多いが，最後に筆者が最も重要と考えているポイントを7つに整理してまとめてみたい（図5）。 （1）RFPは手段であって目的ではない 極論を言えば，最適なパートナーとなるベンダーをひと目で見抜くことができるのであれば，RFPなど不要である。しかし，いろいろな要望や利害が複雑に絡み，コスト的にも経営に大きなインパクトを与えるシステム調達の決定は容易ではない。だからこそRFPが有効な手段として機能するのである。ただし，あくまでもRFPは手段であって，目的は最良のベンダーを見つけることであり，ひいてはシステム構築を成功させることだ。それによって，経営戦略や事業目標を達成させることが最終目的であることを常に意識しなければならない。 （2）趣旨（目的・背景・狙
読みやすさに気を配る
前回「分厚いだけのRFPは読んでもらえない」の項で述べたように，ただがむしゃらに頑張ってRFPや提案書の分量を増やしても，その努力や労力は無駄になり，かえってマイナスの結果をもたらしてしまうことは多い。 繰り返しになるが，RFPと提案書は法人間のコミュニケーションのためのツールであることをきちんと認識し，相手の立場で考えることが肝要である。ひと言で言ってしまえば「読みやすく書く」ということである。まったく当たり前のことで，拍子抜けする読者もいるかもしれない。しかし，そのような読者が今まで目にしてきたRFPや提案書は読みやすいものばかりであったか，と問えばそうではないだろう。 むしろ，何をアピールしたいのかポイントがよく分からないものや，ゴチャゴチャと細かい字と意味不明の図が詰め込まれたものを目にすることが多いのではないだろうか。それらは自分（自社）が書きたいことを一生懸命書いているだけであ
ここまでやればRFP作成工数は削減できる
システム化の第一歩は社内用語の統一から 複数の関係者が共同作業をするには、そこで用いられる用語（概念）があいまいだと、互いに誤解を生じる危険があります。特に情報化ではベンダとの共同作業になりますが、自社内では常識であることがベンダにも常識だとはいえません。バベルの塔になるのを防ぐためにも、用語の統一が必要になります。これは、情報技術の知識は不要ですので自社でできることですし、自社固有のことなので自社でなければできないことなのです。 1.「ホモニム」と「シノニム」をなくす
現場に蔓延する“ひどいRFP”
ITproの読者で「RFP（提案依頼書）」という言葉を知らない人は少ないだろう。それだけ，RFPが市民権を得た結果と言える。しかし，RFPの活用が広がる一方で，悲鳴を上げているベンダー担当者も増えているように感じてならない。悲鳴を上げているのは，コンペによって競争にさらされているからではない。“ひどいRFP”によって不当な提案を強いられたり，迷走プロジェクトに巻き込まれたりしているケースが目立つからである。 現場ではいったい何が起きているのか。記者は5月某日，RFPの読み手であるベンダー担当者3人を招いて，覆面座談会を開いた。テーマは「現場に蔓延する“ひどいRFP”」。すると，実際に出くわした“ひどいRFP”が，次から次へと挙がった。以下では，その典型パターンをいくつか紹介しよう。 ケース（1） 担当者の思いだけで記述 一つめは，担当者の“思い”だけがRFPに書かれていたケースである。大手
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
