RFP完全マニュアル 実践編

目次

• RFP作成後に行う作業：提案書受領までのプロセスをイメージする

  　RFPを作成し，レビューを受ける時期に忘れてならない作業は，ベンダーへのRFPの提示から提案書を受け取るまでの一連のプロセスをスケジュールベースで検討，決定することである。ここには，RFP提示後のベンダーからの質問に対する回答プロセスも含む。プロセスを検討するに当たり，ベンダーがどのように提案書を…

  2010.08.20

• RFP作成後に行う作業：RFPのレビュー

  　RFPチームでひと通りRFPを書き上げたならば，ベンダーに提示する前に，必ず社内レビューを受けることを強く推奨する。レビューの目的は，RFPに記載された要求に，漏れ，偏り，無理，無駄，矛盾がないかどうか，第三者の目を通してチェックすることである。レビューのメンバーとしてはRFPチーム以外に，業務要…

  2010.08.19

• RFP作成前に行う作業：チーム編成と会議体の設定

  　RFP作成やベンダー選定といった調達作業は基本的に複数のメンバーが携わるチームとして行うことが望ましい。どんなに小さな案件であっても，1人の担当者だけで行うと，さまざまな弊害が発生する。実際にRFP作成の作業を1人でやることになっても，少なくともレビューにはエンドユーザーや上司を参加させてチームと…

  2010.08.18

• RFP作成前に行う作業：情報化企画からRFP作成への流れ

  　RFPの作成前に取り組むべき作業について説明する。RFP作成は調達フェーズの作業の一つだが，その「ITリソースの調達」の前工程は一般に「情報化企画」と呼ばれている。情報化企画をひと言で説明すると，「経営戦略や事業目標の実現のために，ITでできることを明確化する」ということになる。

  2010.08.17

• その他のRFP構成要素：特記事項について

  　RFPの構成要素である「特記事項」について説明する。特記事項には，提案書作成を依頼するにあたって，特に留意してもらいたい点や指示を明確にしておきたい点などがあれば記述すればよい。何が必要で，何はダメというような決まり事はない。ただし，RFPを受け取るベンダーにとっては，特記事項に三つの観点の記載が…

  2010.08.16

• その他の運用要求の取りまとめ方

  　ここまで，システム運用，保守・維持管理，移行と運用要求の中でも特に重要なものを説明してきたが，その他の主な運用要求について説明していきたい。

  2010.06.25

• 移行に関する要求の取りまとめ方

  　システム再構築のプロジェクトに一度でもたずさわった経験のあるITエンジニアであれば，移行の難しさを誰もが知っているであろう。純粋な新規のシステム開発であれば，移行は考慮する必要はないし，あったとしてもCSVやテキストデータの取り込み程度の場合が多い。しかし，現実のシステム開発の現場では，新規案件よ…

  2010.06.24

• 保守・維持管理に関する要求の取りまとめ方

  　保守に関するサービスにおいては窓口がどのように提供されるのかは重要な要素となる。ユーザーとしてはできれば窓口は一本化し，提案書を提示するベンダーの窓口に連絡すれば，保守サービスを享受できるようにしたいはずだ。そのためには保守サポートの窓口を一本化するような提案を要求することを忘れてはならない。製品…

  2010.06.23

• システム運用に関する要求の取りまとめ方

  　運用業務そのものをアウトソーシングしたいと考えているケースもあるだろう。特に，システム運用に十分な人員をあてがうことが難しい中小企業においては，「サービス内容と価格が妥当であれば，運用はベンダーに任せてみたいので，ぜひ魅力的な提案をしてほしい」と考えることは多いだろう。アウトソーシングの提案を求め…

  2010.06.22

• 運用要求の概要

  　運用要求とは，システムが完成して実際に業務で利用することを想定して洗い出される，システムの運用にかかわる諸々の要求を総称したものである。当たり前のことであるが，システム構築はそれ自体が目的ではなく，システム構築プロジェクトの期間というのはひと言で言ってしまえば「準備期間」に過ぎない。システムが出来…

  2010.06.21

• 他システムとの連携に関する要求の取りまとめ方

  　新たにシステムを導入する上で，必ず検討しなければならないことの一つが，既存の他のシステムとの連携の必要性である。例えば現行の基幹システムが導入から長い年数が経過し，その陳腐化への対応のために再構築（リプレース）を行う場合，再構築の範囲に入っていない周辺のシステムに注目する必要がある。

  2010.05.21

• セキュリティに関する要求の取りまとめ方

  　セキュリティは現在のシステム構築において，最重要課題の一つと言っても過言ではないだろう。特に個人情報などの漏えいがあった場合は，その関連部門や情報システム部門が批判されるばかりでなく，全社的に企業イメージに深刻なダメージを受けてしまう時代となった。またウイルス被害もますます甚大になってきている。そ…

  2010.05.20

• システム能力に関する要求の取りまとめ方

  　新システムが業務要求をすべて満たし，機能的には問題がないとしても，例えばレスポンスタイムが遅く，画面遷移の度に10秒，20秒と掛かったのでは業務システムとしては使いものにはならない。あるいは1人2人のユーザーだとサクサク動くが，同時利用ユーザー数が増えるととたんに遅くなるというシステムも役に立たな…

  2010.05.19

• インフラに関する技術要求の取りまとめ方

  　インフラに関する技術要求の具体的な例とそのまとめ方について説明していこう。インフラ要求とはその言葉通り，新システムの機器やソフトウエアなどに関して「どのような技術/製品を選択したいのか」を洗い出すものだ。このインフラの要求に関して，一つの大きな判断材料となるのが，既存の他のシステムやネットワークと…

  2010.05.18

• 技術要求の概要

  　技術要求とは，システムに求める機能や性能を総称したものである。また業務要求が機能要求と呼ばれるのに対して，技術要求や運用要求に属する機能は非機能要求と呼ばれることがある。技術要求は細かく挙げていくと種類が多いが，いくつかのカテゴリーに分類できる。まずはその分類例を示す。

  2010.05.17

• RFP作成の七つのポイント

  　本連載も最終回となった。RFP作成の作業で使える手法やテクニック，あるいは留意すべき点などを解説してきた。繰り返しになる部分も多いが，最後に筆者が最も重要と考えているポイントを7つに整理してまとめてみたい。

  2010.01.22

• 読みやすさに気を配る

  　ただがむしゃらに頑張ってRFPや提案書の分量を増やしても，その努力や労力は無駄になり，かえってマイナスの結果をもたらしてしまうことは多い。繰り返しになるが，RFPと提案書は法人間のコミュニケーションのためのツールであることをきちんと認識し，相手の立場で考えることが肝要である。

  2010.01.21

• 分厚いだけのRFPは読んでもらえない

  　調達活動をコミュニケーションの観点で見ると，ユーザー企業とベンダー企業がRFPと提案書という文書をツールとして，企業間のコミュニケーションを図り，両者の利害や思惑が合意できれば契約に進むということである。ただし，それは1対1のコミュニケーションではなく，ユーザー企業（発注側）が1，ベンダー企業（受…

  2010.01.20

• 初期段階のコミュニケーションが重要

  　RFP作成からベンダー選定の期間は，一部の官庁や大企業の巨大システムを例外とすれば，3カ月から6カ月というのが一つの目安になる。ベンダーの提案書作成期間や最終的な社内でのベンダー決定の期間などを考慮すると，実際にRFPを作成するための調査や文書作成の期間は想像以上に短く，余裕はない。

  2010.01.19

• コミュニケーションの観点から見たRFP作成

  　ITエンジニアに必要な基本的なスキルとして必ず挙げられるものに，コミュニケーション・スキルがある。当然のことながらRFPの作成や提案書の評価においても，「読む・書く・話す・聞く」の四つのコミュニケーションは非常に重要である。いやそれ以上に，これらの作業はほとんどコミュニケーション活動の固まりである…

  2010.01.18