EnterpriseZine(エンタープライズジン)

EnterpriseZine(エンタープライズジン)

テーマ別に探す

RFPで提案を依頼したい事項 その1

  2016/02/10 06:00

 さて、前回までの「基本情報」「提案の主旨・目的」では、自分達の組織がなぜ新システムを導入しようと思ったか、それを入れてどんな業務プロセスを実現し、どんな課題を克服しようと考えているかを提案者に伝える部分について書きました。これ以降は実際に提案をしてほしい事項、ベンダにやってほしい事項とその範囲などについて書きたいと思います。

細川義洋氏登壇、無料セミナー
『ITプロジェクトの成功は正しいRFPから―紛争事例に学ぶRFPの書き方―』
2/25開催!お申込み、詳細は
こちら!

サービス範囲や作業範囲 /役割分担・責任分担

 まずは、ベンダのサービスや作業範囲とそれに基づく双方の役割分担・責任分担です。これにはいくつかの切り口がありますが、一般的には、「要件定義」「設計」「実装」「テスト」「ユーザ受入れ検証」「保守」「運用」等のフェーズごとにベンダにやってほしいことを記してあるのをよく見ます(この書き方は、昔ながらのウォーターフォールの開発プロセスで書いていますが、アジャイルプロセスでも、わかりやすく各局を分けで、それ毎にベンダにやって貰うことを書くことに変わりはありません) 。

 記述例を見てみましょう。

 前述した通り、この例では提案を依頼したい内容を工程毎の作業で区切って書いていますが、もちろん、これをたとえばサブシステムで区切ったり、ユーザインタフェース部分/ビジネスロジック部分といったシステムの構成要素で区切っても構いませんし、それらを組み合わせたものもよく見ます。

 ポイントとしては、単に業者に任せたいことだけを書き出すのではなく、対象となる全体の作業やシステムを書いてから提案して欲しい部分を指し示すことでしょうか。そうすることで作業やサービスの範囲やシステムのヌケモレを防ぐことができますし、責任分担も明確になります。

 時々見る例として、ユーザと業者の作業範囲を「主体」「支援」という言葉で表すことがありますが、私の経験から言えば、これはあまりお勧めしません。

 上表のように書くと、「支援」と言われるものの作業が、具体的に何を指すのか分かりません。現場調査の「支援」とは、単に、ドキュメントを見せて、ヒアリングの場を設定するだけなのか、ヒアリングに実際、参加するのか、調査結果のとりまとめを手伝うのか、レビューは主体か支援か。そのあたりが分からなくなります。

 「ユーザのシステム担当者が、要件とりまとめを支援すると言いながら、エンドユーザ達の意見調整をしてくれなかった。それが原因でスケジュールが大幅に遅れた」とベンダが言えば、「支援の範囲に、そこまで含まれるとは言っていない。それはベンダの仕事だ。」とユーザが言い返す。私は、こうしたやりとりを裁判所で何度となく見てきました。やはり、サービスや作業の範囲は、具体的な作業を「主語」がわかるように書き、作業成果物がわかるように書いてもらうべきです。

 また、こうした記述はプロジェクト計画書に書くべきで、提案依頼書、あるいは提案書に書く必要はないという意見もありますが、現実的にはこれによって業者の作業工数が大きく変わることもありますから、やはり提案依頼書に書いておくべきでしょう。

※この続きは、会員の方のみお読みいただけます(登録無料)。


※この続きは、会員の方のみお読みいただけます(登録無料)。


著者プロフィール

  • 細川義洋(ホソカワヨシヒロ)

    ITプロセスコンサルタント 東京地方裁判所 民事調停委員 IT専門委員 1964年神奈川県横浜市生まれ。立教大学経済学部経済学科卒。大学を卒業後、日本電気ソフトウェア㈱ (現 NECソリューションイノベータ㈱)にて金融業向け情報システム及びネットワークシステムの開発・運用に従事した後、2005年より2012年まで日本アイ・ビー・エム株式会社にてシステム開発・運用の品質向上を中心にITベンダ及びITユーザ企業に対するプロセス改善コンサルティング業務を行なう。現在は、東京地方裁判所でIT開発に係わる法的紛争の解決を支援する傍ら、それらに関する著述も行なっている。 おもな著書に、『なぜ、システム開発は必ずモメるのか? 49のトラブルから学ぶプロジェクト管理術』 日本実業出版社、『IT専門調停委員」が教える モメないプロジェクト管理77の鉄則』。

バックナンバー

連載:RFP書き方指南
All contents copyright © 2007-2022 Shoeisha Co., Ltd. All rights reserved. ver.1.5