仕事を効率化したい、生産性を上げたい。そのような時にITシステムの導入を検討するケースが多いと思います。
ですが、「ITの知識がないから心配」「どこにどうやって相談すれば良いか分からない」と思われている方も多いのではないでしょうか。
もちろん、発注者側がシステムに詳しい必要は全くありません。
しかしシステム開発はベンダーに丸投げしてもうまくいかず、発注者もプロジェクトにしっかり参画していく必要があります。
この記事ではITシステムの発注者がどのように立ち回れば良いのか、依頼や相談方法のポイントについて解説します。
開発依頼までの流れ
システム開発は一般的に次のようなステップで進めます。
- ベンダーのリストアップ
- 情報提供依頼書（RFI）の作成
- ベンダー候補にRFIの送付
- 提案依頼書（RFP）の作成（秘密保持契約の締結）
- コンペ
- ベンダー決定
- 契約
- 開発開始！
ベンダーのリストアップ
まずは気になるベンダーをリストアップします。
付き合いのあるベンダーや、導入したいと思っているシステムを扱っているベンダーなど、候補を洗い出しましょう。
展示会やホームページなども活用し、幅広く情報を集めましょう。
情報提供依頼書（RFI）の作成
ベンダーを洗い出しと並行し、「情報提供依頼書（RFI）」を作成します。
これはベンダーに対して基本情報や製品情報の資料を依頼する文書のことです。
簡単に言うと「こんなことやりたいから、おたくの資料頂戴！」と言うための資料です。
テレビやエアコンを買う時に、電器屋さんでパンフレットを集めるようなものだと思っていただければOKです。
この資料には、自社の基本情報（住所や主な事業内容など）とシステムを導入、刷新したい簡単な理由や目的を記載します。
基本的には秘密保持を結んでない相手にも送るものになるので、公にできる情報のみ記載します。
ベンダー候補にRFIの送付
情報提供依頼書（RFI）が作成できたら、リストアップしたベンダーにこれを送付します。
いきなり資料を送り付けるのにハードルが高いと感じる場合は、会社のホームページから問い合わせをしてみましょう。
お問い合わせフォームがついているところがほとんどだと思いますので、そこからまずはRFIを送っても良いか聞いてみるのが簡単です。
この時点で、RFIを送るベンダーを絞り込む必要はありません。
資料をもらうのが目的ですから、気になる会社にどんどん送り付けましょう。
ポイント
RFI送付時にいつまでに情報が欲しいか、期日を明確にして依頼しましょう。
希望期日をRFIの中に書いてしまうのが、連絡忘れの心配がなくおすすめです。
期日はRFI送付日の2週間～1ヵ月後くらいを目安に設定するのが一般的です。
ベンダーの絞り込み
ベンダーから資料が届きましたら、良さそうなところをいくつかピックアップします。
どのくらい候補を残すかは自由ですが、あまり数が多いと後述のコンペや決定作業が大変になります。
可能なら、３社くらいまでに絞り込むのをおすすめします。
提案依頼書（RFP）の作成（秘密保持契約の締結）
提案依頼書（RFP）はシステムの導入にあたり具体的な提案をベンダーに求める文書です。
簡単に言うと「ウチは今こんなことになってんだけど、何かいい方法ない？」と言うための資料です。
この資料にはRFIに記載した基本情報や目的に加え、現在の業務フロー、既に導入済みのシステムがあるなら各システム間の連携図、さらにはプロジェクトの体制図や基本方針など、提案の範囲や骨子となるための必要情報を漏れなく記載します。
コンペ
RFPを配り終わったら、コンペの日程を設定します。
だいたいRFP提出から1～2ヶ月後くらいに設定すると、ベンダー側も準備しやすいと思います。
ポイント
RFPの中にコンペの日程を明記しておくと、調整が楽です。
コンペには1社ずつ日程を調整して個別にプレゼンしてもらうパターンと、候補ベンダーをまとめて呼んで一気にプレゼンしてもらう２つのパターンがあります。
どちらが良い・悪いということはなく、それぞれメリット、デメリットがありますので、自社のスタイルに合ったやり方で開催しましょう。
| メリット | デメリット | |
|---|---|---|
| 1社ずつ呼ぶ場合 | ・1社ごとじっくり話を聞くことができる ・競合他社と場を共有しないため、各社の裏事情を聞きやすい（ベンダー側も話しやすい） | ・日程調整に手間がかかる ・コンペ期間が長くなりやすい ・後半のプレゼンで出た質問を前半のベンダーにも聞くなどの手間が発生しやすい |
| 合同コンペを開催する場合 | ・日程調整が楽 ・コンペ期間が短い ・プレゼン中の質問や回答を、全ベンダーから一斉に得ることができる | ・プレゼンの持ち時間や質疑応答に不公平感が出ないよう気を使う必要がある ・時間が限られるため、1社ごとにじっくり話を聞くことができない ・競合他社の手前、あまり深いことが聞けない（ベンダー側も言いづらい） |
コンペには決定権を持つ人だけではなく、実際に現場でシステムを使う予定の人達も呼んで意見を集めましょう。
ポイント
参加メンバーの中にはITやシステムに疎く「話を聞いてもちんぷんかんぷん」という場合があるかと思います。
そんな時は、事前にチェックポイントをまとめたリストやアンケートなどを用意しておくと、話を聞いてもらいやすいと思います。
チェックポイントがまとまっていると、後で比較するのが楽になるのでおすすめです。
ベンダー決定
予定していたコンペが全て終了したら、いよいよベンダーを決める作業に入ります。
関係者を集め、お願いしたいベンダーを決めましょう。
ポイント
価格、システムの使いやすさ、ベンダーが頼りになるかなど、自社が重要視する項目に点数をつけていくと、みんなが納得しやすいものになると思います。
まだ判断材料が足りないと感じた場合は追加で話を聞いたり、メールで質問を投げたりして疑問点がない状態にします。
価格交渉はこのタイミングで行うのが良いと思います。
ベンダーが決定したら、決定したベンダーに採用の連絡いれます。
合わせて不採用のベンダーにも丁寧にお礼と謝罪を入れておきましょう。特にこちらが大事で、今後別のシステム導入でお世話になることがあるかもしれません。その時に悪印象を持たれないようしっかりケアしておきましょう。
契約
採用ベンダーから契約書が届きましたら、内容をしっかりチェックし契約します。
システム開発の契約は主に準委任契約と請負契約に分かれます。
- 準委任契約
業務委託契約の一種で、結果や成果物の完成については責任を求められない契約です。
システム開発では、開発範囲が明確になるまで（主に要件定義完了まで）の契約形態として用いられます。 - 請負契約
請負人がシステムを完成させることを約束した契約です。
システム開発では、主に要件定義が終了後から最後までの契約形態として用いられます。
なぜこのように契約が分かれるかと言うと、システム開発はユーザーが完成形をイメージできてないことが多く、打ち合わせを重ねる中で要件が大幅に変わるケースがあるためです。
そのため要件が固まった後に正確な見積もりを出し、それで双方が合意できたら改めて契約を結び直すという流れが一般的となっています。
注意
決して不安や疑問が残っている状態で契約しないでください！
上述のように契約形態が分かれるなど、人によっては商習慣が独特に感じるケースがあると思います。
後々のトラブルを避けるためにも、用語の一つまでしっかり意味を理解した上で契約することを心がけましょう。
開発開始！
ここまでくれば、後はベンダー主導で開発が進んでいくものと思います。
ただ冒頭でも申し上げた通り、システム開発はベンダーに丸投げするだけでは決してうまくいきません。
ベンダーからの宿題には期日通りにきっちり応え、二人三脚で協力しながら進めるようにしましょう。
みなさまのプロジェクトが成功することを心よりお祈りしております。