目 次

スクラッチとパッケージの同時検討

「迷っているなら、まずはパッケージ導入の可能性を探りながら考えてください」

前回のコラムでこのように書きましたが、どうしても意見がまとまらず「一方だけを選べない」という状況もあるかと思います。

スクラッチとパッケージでは、システム選定の進め方や観点が大きく異なります。

そのためRFPの書き方も使い分ける必要があるのですが、もし同時並行で検討することになったら、どうすれば良いでしょうか？

まずは「スクラッチ用」と「パッケージ用」、それぞれのRFPにおけるポイントを整理してみましょう。

パッケージは「伝え過ぎ」に注意

パッケージ導入に際しては「業務標準化」という狙いがあります。

その際、やりたいこと（To-Be）を事前に作り込み過ぎてしまうと、「To-Be像に合わせてパッケージを改造する」方向で突き進むことになるので注意が必要です。

カスタマイズ費用がかかるだけでなく、パッケージ製品の持つベストプラクティスを見ないまま蓋をすることになり、「業務標準化」という目的も遠のいてしまいます。

パッケージ用のRFPにおいては、理想のTo-Be像を描くことよりも、現状（As-Is）をしっかりと定義する方が重要です。

スクラッチは「伝え漏れ」に注意

スクラッチ開発は要望通りに作る「オーダーメイド」なので、あるべき姿（To-Be）がはっきりしていないと、道しるべがなく迷走します。

To-Be像がぼんやりしていると、あれもこれもと盛り込んでしまい、気が付けば「開発費が当初予定の何倍にも膨れ上がった」という事態になりかねません。

とはいえ、To-Be像の過度な作り込みは禁物です。

「より良いアイディアや提案が出てきたら、その都度柔軟に検討していく」という意識は、常に持っておく必要があります。

スクラッチとパッケージ、両対応のRFPは作成可能

ここまでを踏まえ、スクラッチとパッケージ両対応のRFPを書く場合のポイントを整理します。

1. 現状（As-Is）をしっかり定義する

As-Isが整理されていることは、スクラッチとパッケージ両方において等しく重要です。

要求機能一覧や業務フローなど、出来るだけ丁寧に書き出してください。

2. あるべき姿（To-Be）は書き過ぎない

書く内容は「〇〇業務を自動化したい」と方針を示すまでに留めておきます。

要求の具体的な実現方法まで踏み込んで書く必要はありませんが、やりたい範囲までは必ず明示してください。
（対象範囲を後出しすると、追加要望として扱われてしまうため）

3. どちらか一方でのみ必要な内容は、但し書きを入れて書く

契約不適合責任（旧・瑕疵担保責任）や著作権の帰属先は、スクラッチ開発における必須項目です。

“但し、システムの形態に依る” のように、注釈を入れつつ記載してください。

本来はどちらかに決めてRFPを書くべき

パッケージ導入の目的である「業務標準化」と、スクラッチ開発の強みである「自由度の高さと柔軟性」は、アプローチとしては互いに相容れないものになります。

両対応のRFPを書くことは不可能ではありませんが、本来どちらか一方に意見がまとまってからRFPを作った方が良いのは言うまでもありません。

もし両対応のRFPを書くことになったら、この先どうやって合意形成に至るのか、今後の展開やストーリーをイメージしておきましょう。

合意形成を先に延ばした分、RFPを発行した後こそが本当の勝負どころだと言えます。