細川義洋氏登壇、無料セミナー
『ITプロジェクトの成功は正しいRFPから―紛争事例に学ぶRFPの書き方―』
2/25開催！お申込み、詳細はこちら！
サービス範囲や作業範囲 /役割分担・責任分担
まずは、ベンダのサービスや作業範囲とそれに基づく双方の役割分担・責任分担です。これにはいくつかの切り口がありますが、一般的には、「要件定義」「設計」「実装」「テスト」「ユーザ受入れ検証」「保守」「運用」等のフェーズごとにベンダにやってほしいことを記してあるのをよく見ます(この書き方は、昔ながらのウォーターフォールの開発プロセスで書いていますが、アジャイルプロセスでも、わかりやすく各局を分けで、それ毎にベンダにやって貰うことを書くことに変わりはありません) 。
記述例を見てみましょう。
前述した通り、この例では提案を依頼したい内容を工程毎の作業で区切って書いていますが、もちろん、これをたとえばサブシステムで区切ったり、ユーザインタフェース部分/ビジネスロジック部分といったシステムの構成要素で区切っても構いませんし、それらを組み合わせたものもよく見ます。
ポイントとしては、単に業者に任せたいことだけを書き出すのではなく、対象となる全体の作業やシステムを書いてから提案して欲しい部分を指し示すことでしょうか。そうすることで作業やサービスの範囲やシステムのヌケモレを防ぐことができますし、責任分担も明確になります。
時々見る例として、ユーザと業者の作業範囲を「主体」「支援」という言葉で表すことがありますが、私の経験から言えば、これはあまりお勧めしません。
上表のように書くと、「支援」と言われるものの作業が、具体的に何を指すのか分かりません。現場調査の「支援」とは、単に、ドキュメントを見せて、ヒアリングの場を設定するだけなのか、ヒアリングに実際、参加するのか、調査結果のとりまとめを手伝うのか、レビューは主体か支援か。そのあたりが分からなくなります。
「ユーザのシステム担当者が、要件とりまとめを支援すると言いながら、エンドユーザ達の意見調整をしてくれなかった。それが原因でスケジュールが大幅に遅れた」とベンダが言えば、「支援の範囲に、そこまで含まれるとは言っていない。それはベンダの仕事だ。」とユーザが言い返す。私は、こうしたやりとりを裁判所で何度となく見てきました。やはり、サービスや作業の範囲は、具体的な作業を「主語」がわかるように書き、作業成果物がわかるように書いてもらうべきです。
また、こうした記述はプロジェクト計画書に書くべきで、提案依頼書、あるいは提案書に書く必要はないという意見もありますが、現実的にはこれによって業者の作業工数が大きく変わることもありますから、やはり提案依頼書に書いておくべきでしょう。
