はじめに
「何から始めればいいかわからないから、まずはベンダーに相談してみよう」という進め方は、一見合理的に見えます。しかし、要件を固めずにベンダーへ相談を持ちかけると、多くの場合、思っていたのとは違う方向に話が進んでしまいます。なぜそうなるのか、そしてどう進めればよいのかを整理します。
「相談してみよう」が丸投げの入り口になる
発注側が「丸投げ」になってしまう組織構造の問題でも触れたとおり、依頼したい内容が固まっていない状態でベンダーに声をかけるケースは、現場で非常によく見られます。人手が足りない中、「とりあえず相談してみよう」という軽い気持ちで持ちかけた相談が、気づけば本格的な提案依頼になっている、ということが起きます。
この進め方自体が悪いわけではありませんが、構造的なリスクをあらかじめ理解しておく必要があります。
ベンダーは「聞かれたこと」にしか応えられない
要件が固まっていない状態でベンダーに相談すると、ベンダー側は限られた情報の中で、手探りで提案を組み立てることになります。ベンダーは専門家であり多くの引き出しを持っていますが、発注側の本当の課題や制約を深く理解しているわけではありません。
結果として、次のようなズレが生まれやすくなります。
- 発注側が本当に解決したかった課題と、提案の方向性がズレる
- ベンダーが「できそうなこと」を軸に提案を作るため、必要以上に大きな（あるいは的外れな）スコープになる
- 複数ベンダーに相談した場合、聞いた相手ごとに前提がバラバラで、比較にならない
これらは、ベンダーの能力の問題ではなく、発注側から十分な情報が渡っていないことに起因する問題です。
相談する前に、最低限整理しておくべきこと
ベンダーに相談を持ちかける前に、せめて次の3点だけは自分たちの言葉で整理しておくことをおすすめします。
① 何が課題なのか
現状、何に困っているのか。感覚的な「使いにくい」ではなく、具体的にどの業務のどの部分で、どういう不都合が生じているのかを言語化します。
② どうなれば解決したと言えるのか
理想の状態を具体的にイメージします。「速くなる」「楽になる」といった曖昧な表現ではなく、可能な範囲で定量的・具体的な目標を設定します。
③ 譲れない制約は何か
予算感、稼働開始までの時間的制約、既存システムとの連携必須条件など、絶対に外せない前提条件を洗い出しておきます。
この3点が整理されているだけで、ベンダーからの提案の精度は大きく変わります。ベンダーからの提案書、どこを見れば「本気度」がわかるかでも触れたように、発注側が渡す情報の質が、提案の質を決めます。
整理した内容は、そのまま終わらせず、形にしておくことをおすすめします。要件定義ワークショップを成功させる進め方で整理した要件を土台に、RFP（提案依頼書）の作り方に沿って文書化しておけば、複数のベンダーに同じ前提で相談でき、比較もしやすくなります。
「相談ベース」で進めてよい場合もある
一方で、課題自体が曖昧で、課題発見そのものをベンダーに手伝ってもらいたいケースもあります。その場合は、「要件定義を一緒に進めてもらう」という前提を明確にし、どこまでが無償の相談で、どこからが有償の作業になるのかを、早い段階でベンダーと合意しておくことが重要です。曖昧な相談を無償で引き出し続けると、ベンダー側の協力姿勢が長続きしないという点にも注意が必要です。
実際に使っている機能要件・非機能要件一覧とRFPテンプレートは、noteで配布しています。相談前の整理から、ベンダーへの文書化までを一貫してサポートする内容になっています。
まとめ
要件を固めずにベンダーに相談を持ちかけると、提案のズレや比較のしづらさといった問題が生じやすくなります。相談前に課題・理想の状態・制約の3点を整理しておくこと、課題発見自体を依頼する場合は無償・有償の境界を早期に合意しておくことが、ベンダー相談を有効に活用するためのポイントです。
執筆者プロフィール：SIer（元請け）とITコンサルファーム（発注側支援）、両方の立場でプロジェクトに従事（通算9年）。要件定義からベンダーマネジメントまで一貫して対応し、基幹システム刷新・DX推進プロジェクトに多数従事。
コメント