ユーザー企業における企画から要件定義、ＲＦＰ作成までの進め方
０．前置き
私は長年ユーザー企業のシステム開発・運用部門の長を若い頃から勤めてきました。外資系ベンチャー企業から始まって、スタートアップ企業の役員、外資系大手映画会社のインターネット事業部における技術部長、大手通信教育企業のＣＤＯ、海外に開発拠点を持つスタートアップ企業の製品担当役員等を歴任してきました。
「ＩＴベンダーへの丸投げ体質」そのものを体現するシステム部門における経験
自社開発体制を整えている経験
の双方を体験しています。
ここでは、これらの経験（反省）をもとに、ユーザー企業における企画からシステム開発の要件定義、ＲＦＰ作成までどのように進め、どのように開発外注会社さんに開発を依頼するのかを説明したいと思います。
また、基幹システム系の経験より、サービス提供システム系（ユーザーシステム系）の経験が多いため、スピード重視・作って常に改善していくアジャイル開発（後述）的な発想の説明になっていることはご了承ください。
基幹システム系（Backend System系）はもう少し慎重に時間をかける必要があると思います。
なお、自社で開発体制をどのように整えていくかは、次の機会にお話したいと思います。
１．開発手法（ウォーターフォールvsアジャイル）
２．「顧客が本当に必要だったもの」〜要件定義の大切さ
以下は、要件定義の難しさを風刺した絵です。
顧客が説明した要件が、それぞれの立場の捉え方・考え方次第で全く違うものになってしまうという皮肉です。ちなみに、ブランコの形態はソフトウェア・システムの構造・機能・使い勝手・規模などを比喩したものです。
３．企画書を確認
まず、ビジネス側との「システム開発」のゴールを共有するために、企画書を確認します。企画書もない場合がありますので、簡易的にも作って確認すべきです。
PMBOKでいうところの「プロジェクト憲章（Project Charter）」や「プロジェクト計画書」に近いが、予算とかリスクとかが含まれない、そこまで硬いもので、ビジネス側が何を求めているかを作り手側とビジネス側との間で確認できるものであれば十分です。
企画書の内容は以下のようなものです。
①企画（プロジェクト）の名称
②なぜ・目的
③何を
・目的達成のために作るもの
・作るものの説明
・作るものを利用する人
・利用する人が得られる便益
④どのように
・作るための体制
・期限
例としては以下のようなものです。
４．要件定義
定義にもよりますが、自分はここから以下のステップを要件定義だと考えています。
ベンダー依存が高い企業に所属していた際は、これ以降の全工程を既存ベンダーに要件定義フェーズ内として依頼していました。
しかし、これ以降の部分もしっかり自社で描かない限り、ベンダー丸投げ体質・ベンダーロックからは脱せません。
ですので、ここから下のステップをしっかり自社で実施し、ナレッジとして貯めていくことが企業価値を高めると信じております。
４．１ 全体像を描く
関連システムを含めたシステム全体を俯瞰的に見れる鳥瞰図のようなアーキテクチャー図と、今回の対象システムにフォーカスした機能概要図を用意すべきです。
場合によっては、大きな図面の中に機能概要図を含めた全体アーキテクチャー図を作成することもあります。
以下に例を示します。
４．２ 実装技術の決定
（場合によっては要件定義時点でベンダー相談もあり）
全社的にインフラはAWS上に構築するとか、今回はAI系システムのためGCPを使いたいとか何かしら技術要件（技術条件）があると思います。
そういった実装に関わる技術要件を決定（定義）する必要があります。
４．３ やりたいことを一覧にする（機能一覧）
外注開発会社に見積依頼する際に、この「機能一覧」を作成しておくと見積比較がしやすいです。
ただし、昨今の流れとしては、基幹系システムやバックエンドシステムでないコンシューマ向けシステム、つまりユーザーインターフェース（ＵＩ）をもつシステムであれば、次の「ＵＩを決める」とあわせて、プロトタイピングを実施することをお勧めします。
４．４ ＵＩを決める
典型的なのは画面遷移図を作成することですが、意外と画面遷移図を作成するのは敷居が高い場合があるので、プロトタイプツールを使いプロトタイピングすることをお勧めします。
プロトタイプツールもいくつかありますが、私は日本製である株式会社グッドパッチの「Prott」をお勧めします。理由としては、
まず日本製であること
全て日本語で表記されているため、ステークホルダーにも使ってもらいやすいです。
手書きの画面をスマホで撮影し、そのまま画面として定義できること
ＰＣとスマホの両方で扱えること
編集するときはＰＣで、プロトタイプを触ってもらうときはスマホで行うことができます。
（プランによって制限がありますが）チームで共同作業が簡単であること
Prottの使い方に関しては、グッとパッ様本体のHPのリンクを掲載しておきますので、こちらを参考にしてください。
５．開発外注会社への開発依頼
5.1 ＲＦＰとＲＦＩ
ここまで社内で作り上げてきた資料をもとにＲＦＰ（Request For Proposal：提案依頼書）を作成します。ベンダー選定をしない場合であっても、簡便でもＲＦＰを作成すべきです。
なお、あまり条件が固まっていない場合はＲＦＩ（Request For Information：情報提供依頼書）を作成して開発外注会社様から情報をもらって、その後ＲＦＰへ仕上げていくという手段もあります。
（ＲＦＩとＲＦＰの違いは以下を参考にしてください。）
RFIは製品やサービスの情報を幅広く収集することが目的であるのに対し、RFPはベンダー選定が目的となります。一般的に RFIで得た情報をもとにRFPを作成し、再度企業に提案を依頼するという流れとなります。
5.2 ＲＦＰ作成
これまで作成した
企画書
アーキテクチャー図
機能概要図
を社外に出して良い形に修正し、ＲＦＰ本紙を作成します。
また、
プロトタイプ
により、企業側の要望をきっちり見える化出来ます。
また、提案内容の精査をするために作成済みの
機能一覧
を「提案シート」と称してExcelファイルを作成しておきます。
場合によっては開発提案金額の明細の雛形としても利用できます。
また、提案金額も事前に以下の例のようにフォーマット化して、同じ提案シートに入れておくことをお勧めします。
特に、ベンダー選定をする際の比較の際にはこの提案シートがとても役に立ちます。
これら全てをまとめてＲＦＰ一式とします。
RFP本紙
プロトタイプ
提案シート（機能一覧表および提案金額表）
このＲＦＰ一式が揃っていれば、少なくとも開発外注会社様との相談はとても効率的かつ有益なものになるはずです。
６．おわりに
ここまでざっと「ユーザー企業における企画から要件定義、ＲＦＰ作成までの進め方」をご説明しました。
何よりもユーザー企業が何をやりたいのかの意思・意図をしっかり持ち、その意思・意図をしっかり開発外注会社さんに伝えられるかがとても大事です。
そのため、個人的にはプロトタイプを作ることをとてもお勧めします。
RFP本紙や提案シートも大事ですが、結局動くプロトタイプがあれば、ユーザー企業側の意図は視覚的に全て説明してくれますし、それをもとに実現性のディスカッションとかもとてもやり易くなります。
では、「施主責任」という言葉を大事に、ユーザー企業側が主体となってシステム開発を進められることを望みます。