こんにちは。東京都よろず支援拠点　コーディネーターの土田哲です。

原材料価格高騰や人手不足は、企業に生産性向上を促しています。また、コロナ禍を経たユーザーニーズの変化は、企業にビジネスモデルの大変革を求めています。それらはいずれも、デジタル投資を伴います。

デジタル投資は、下図１のような山登りに表せます。麓から段階的にデジタル投資を進めていきます。山頂に近づくにつれて、デジタル投資の規模は大きくなり、内容も複雑化していきます。当然、失敗するリスクも高まります。

【図１】デジタル投資を山登りになぞらえた図：Adobe Stock素材をもとに筆者作成

デジタル投資で見落としがちな点

私は、システムエンジニア出身の中小企業診断士として、デジタル化に関する多くのご相談に対応してきました。その経験の中から、デジタル投資を考えている企業が見落としがちな点を幾つかご紹介します。

(1)開発対象機能の見落とし

WEBシステムの構築を考えている企業によく見られる例です。

ユーザーにWEB経由でサービスを提供するようなシステムは、ユーザー以外が使う機能の開発も必要となります。

例えば、宿泊予約システムを構築する場合、①ユーザー側機能、②宿側機能、③運営会社側機能と、最低でも３つの機能を開発することになります。

また、既存システムから新システムへ、ベンダーを変えて刷新する場合、既存システムのデータ移行についても、見落としがちです。データ移行は相当な工数がかかりますので、当然、有料となります。既にサービスを提供している宿泊予約サイトを再構築するような場合、システム切り替え直前までのデータを移行する必要があります。

(2)本番環境以外のシステム稼働環境の見落とし

自社オリジナルで構築したシステムは、本稼働した後も、バグ対応・機能追加などで、随時改修が必要となります。

例えば、宿泊予約サイトのように競合が多いサービスは、ユーザーの使いやすさも差別化の要因となりますので、頻繁なシステム改修が発生します。

しかし、本稼働中の環境で、いきなりシステムの改修を行うことはできません。システム改修用に、本番環境とは別の稼働環境の準備が必要です。

(3)ベンダー選定要素の見落とし

デジタル投資の経験が少ない企業は、ベンダー選定で見積価格を最重要視しがちです。見積価格も重要ですが、他にも重要な選定要素があります。

例えば、同様なシステム構築の実績です。特に宿泊予約サイトのようなニッチな案件ほど、実績の有無が重要となります。

他にも以下のような点を見落としがちです。

• 開発メンバーが固定されていること（プロジェクトの途中で開発メンバーが入れ替わることはシステムの品質に大きく影響します）
• 本稼働後の保守体制（稼働後のシステムに許容できる停止時間を担保できる保守体制となっているか）
• 拡張性（アクセス数増加に伴い柔軟にスペック増強を図れるか）

見積価格に加え、これら要素の総合評価で、ベンダーを選定することになります。

このように、デジタル化の山を登り始めるとデジタル投資の規模が大きくなり、それまでの自社の知見だけでは、見落としてしまう要素が増えていきます。そのようなリスクを回避するために有効なのが、ＲＦＰを作成してベンダーに提案を求めるという方法です。

ＲＦＰとは

ＲＦＰとはRequest for Proposalの略で、日本語では提案依頼書になります。

ＲＦＰには、開発したいシステムの機能だけでなく、発注側の経営課題や機能以外の要件（非機能要件）なども記載します。ベンダーは依頼者の課題解決策を提案します。そのようなプロセスを踏むため、依頼者側の見落としを防ぐ効果が見込めます。

【図２】ＲＦＰで提案を引き出すイメージ図：Adobe Stock素材をもとに筆者作成

それでは、ＲＦＰには何を記載すれば良いのでしょうか？自社だけで作成できるでしょうか？

私の経験上、次のような内容をまとめれば、ベンダーからの提案を引き出せます。システム部門を持たない会社でも自力でＲＦＰをまとめた例を幾つも見てきました。

(1)当社について

当社のビジネスモデル、組織図、経営課題などについてまとめます。

自社の経営課題を整理する必要があるので、役員クラスの方（可能な限り代表）が関与してください。

なお、営業秘密に類する情報を含む場合は、ＲＦＰ提示前に秘密保持契約（ＮＤＡ）締結が必要となります。

(2)システム概要

現行システムの情報、システム化の背景、システム利用者、実現したい機能の概要、効果目標、予算などについてまとめます。

現行システムの情報は、現行システムの機能一覧、稼働環境、利用者等をまとめます。

システム化の背景は経営課題と結びついているはずです。システム化で解決したい経営課題をまとめます。

システム利用者は、新システムを利用する人の情報（部門や場所、人数等）をまとめます。

実現したい機能の概要は、あくまで概要です。仕様書的な詳細な説明は不要です。機能一覧程度の粒度で大丈夫です。仕様書作成はベンダー側に任せましょう。必要機能の検討には、社内各部門からキーパーソンを集めたプロジェクトチームを組成することもよくあります。プロジェクトチームで機能を検討する際には、優先度を付していくと良いでしょう。予算内に収めるために、機能を削ることもよくあるからです。

効果目標は構築するシステムによって違いますが、例えば宿泊予約サイトの場合は、利用ユーザー10万人のように数字で表します。

予算を提示しておくことで、予算に配慮した提案（例えば第1フェーズ、第2フェーズのようにフェーズ分けした提案）を引き出す効果があります。

(3)提案依頼事項

ベンダーに求める提案を記載する部分です。目先のシステム開発だけでなく、導入後まで見据えた提案を求めることが重要です。

以上のような内容のＲＦＰを、複数社に対して送ります。回答のあった提案の中から、総合的に評価して委託先を決定します。

なお、予算規模によっては、ベンダーから対面での提案（プレゼン）を断られる可能性があります。予算規模が小さい（1,000万円未満）場合は、書面での提案を求めた方が、回答率が高まります。

システムに詳しい人材がいなくても、自力でＲＦＰを作成することは十分可能ですが、お近くの公的な経営相談窓口でＩＴ関連の相談が可能でしたら、ご相談されてはいかがでしょうか。東京都内の事業者様の場合は是非、東京都よろず支援拠点にご相談ください。