2022
5/29
プレゼンのアジェンダをベンダーに提示する
プレゼンの目的が明確である以上、プレゼンはその目的にそった進行をしなければなりません。ベンダーに自由にしゃべらせてしまうと、確認が十分におこなえず、消化不良のまま時間切れとなります。
ベンダーの立場でも、何を中心に、どのようなタイムスケジュールで進めてよいかがわからないと、逆に困ってしまいます。そのため、こちらから何も指定しないと「当日はどのように進めたら良いでしょうか？」と質問がきたりします。
ベンダーとしても、目的やタイムスケジュールがあったほうが準備がしやすく、当日も堂々と話しやすくなります。
そこで、ベンダーから提案書を受け取り、プレゼンの日程を調整するタイミングで、プレゼン当日の「アジェンダ」を提示します。
プロジェクトの性質によって多少のアレンジは必要ですが、基本的には次のようなアジェンダとなります。
アジェンダ（サンプル）
（※ 画像をクリックすると、大きな画像が表示されます）
アジェンダ項目の解説
1. 提案書をもとにプレゼン
このアジェンダの重要なポイントは、プロジェクトマネージャーに「しゃべらせる」ことです。そのため「1.提案書をもとにプレゼン」で直接説明してもらう項目をあらかじめ指定しておきます。
なぜなら、放っておくと全部営業の方がしゃべって、全部の説明が終わってしまうことがあるからです。
通常、プレゼンでは営業担当者が同席して、プレゼンの場をリードします。営業の立場としては「見込み客」に対して積極的にコミュニケーションをとることが仕事です。そのため、営業の方が話す時間が多くなるのは、ある程度は仕方ありません。
営業として、会社として売り込みたい部分、宣伝したいページがあることは理解できます。会社の歴史や強み、基本情報などは、むしろ営業が説明した方が分かりやすく、営業も説明に慣れているでしょう。
しかし、油断すると提案書の説明のほとんどを営業の方がやりかねません。
そこで、百歩譲って、営業が話すのは認める。でも、プロジェクトマネージャーの「人となり」も確認したい。
では、どこをプロジェクトマネージャーに話してもらうべきでしょうか？
それが「プロジェクト計画」です。
今後、そのプロジェクトを任せて、ゆだねる相手がプロジェクトマネージャーです。そのプロジェクトマネージャーが、プロジェクト計画を一番熟知していないのはおかしい。
どのように考え、どのような言葉を用い、どのようなトーンや表情で話しをするのか。その計画は具体性があり、自信に満ちているのか。
つまるところ、プロジェクトが始まった後の定例会の「予行演習」でもあります。このプロジェクトマネージャーに任せた場合の、将来のイメージを重ね合わせていきます。
また、プロジェクトマネージャー自身の「プロフィール」を、本人からきちんと説明をもらいたい。紙面上では経歴を盛ることができるので、具体性があるかどうかを、本人の説明で確認していきます。
「開発の進め方」もプロジェクトマネージャーのノウハウや経験がにじみ出るので、具体的に話してもらいます。
近年は、ウォーターフォールではなく、アジャイルやスパイラル開発も一般的になっています。その進め方の説明が具体的かどうかで、本当にやったことがあるのか、上っ面だけではなく、現場で指揮をとってきたかどうかが分かります。
「データ移行」は、プロジェクトの難所の1つです。経験者はわかると思いますが、必ずタフなシーンが訪れます。
現行データの不備だったり、マッピングができなかったり、コード変換やステータスの思想の違いなど、移行は課題のオンパレードで、とても苦労します。
このデータ移行を当事者として経験しているなら、エピソードを交えた説明や具体的に想定するタスクなど、話しのネタには事欠かないはずです。
ここをさらっと表面的な話で逃げるか、力説してくれるかで、プロジェクトマネージャーの力量がにじみ出ます。
それ以外にも、プロジェクトの特性に応じて、プロジェクトマネージャーに確認したいことがあれば、質問を準備しておきます。
例えば、次のような質問です。
「要件定義後の金額の上振れをおさえるために注意するポイント」
「今回、活用するローコードツール○○○の詳細」
「現場個別のやり方やイレギュラー業務をどうやったら標準化していけるか」
ここで、経験に基づく具体的な回答が得られたら、信頼度が高くなります。
2. 画面デモ
「2.画面デモ」ですが、パッケージを想定した項目となります。
スクラッチ開発の場合は画面を見せることが不可能なので、その場合は、この項目は無くして、「1.提案書プレゼン」の方に時間を多く割きます。
この画面デモも、ベンダーに好き勝手にしゃべらせるのはもったいないです。
自由にデモをさせると、そのパッケージの「良いところ」だけしか説明されません。
つまり「印象操作」されやすくなってしまいます。
そこで、どんなデモをやってほしいかを、こちらから指定します。
一番てっとり早いのは、RFPで渡した「業務フロー」のうち、「ここからここまでの流れを画面で操作してほしい」と指定することです。
例えば「入金消し込み」を指定して、「手動で消し込む場合と、自動で消し込む場合の両方を見せてほしい。自動消し込みはパターン登録の方法からやってほしい」など、具体的な注文をつけることが効果的です。
現場ユーザーが自身の業務と重ね合わせることで、導入イメージをしやすくなり、質問も活発になるからです。
3.質疑応答
最後に「3.質疑応答」の時間をたっぷり設けます。
ここで、提案書や当日のプレゼン、画面デモについて、不明点をどんどん聞いていきます。私はたいてい、アジェンダ上ではこの質疑応答を「30分」と指定します。しかし、実際ははるかにオーバーして「60分」コースとなります。
でも、それでも良いと思っています。「30分」という制約を設けることで、質問するメンバーにも自制心がはたらきます。「時間オーバーしてスミマセン～」と、「巻き」で話してくれます。
それに、アジェンダに最初から質疑応答「60分」と書くと、参加者に重たい印象を与えてしまいます。かといって「15分」だと短すぎるので、「30分」がちょうどいいのです。
そのため、全体としてはだいたい「1時間30分」としておき、いつも裏では会議室の予約を2時間で押さえています。
プレゼンも「アップル to アップル」にする
これらをアジェンダとしてメールに書いて、ベンダーに通知しておきます。
事前に伝えることで、ベンダー側は求められていることのみの説明に専念できるので、準備しやすくなります。自社も聞きたいことを効率的に聞けて「アップル to アップル」で評価もできるようになります。
つまり「Win-Win」となります。
ベンダーにプレゼンをお願いする際は、必ず事前に「アジェンダ」を伝えるようにしましょう。
（プレゼン評価の関連記事）
【プレゼン評価1】プレゼンの効果を高める5つの観点とは？
【プレゼン評価2】ベンダープレゼンAgendaの作り方（サンプル画像付き）
【プレゼン評価3】プロジェクトマネージャーにどんな質問をするか？
【プレゼン評価4】パッケージベンダーにどんな質問をするか？
（プレゼン評価の関連コラム）
RFP後のベンダー提案プレゼンで話しているのは誰？
＊＊＊＊＊
※ 弊社で公開しているサンプルについては、基本的に画像のみの提供とさせていただいております。ファイルデータのダウンロードを可能とすると、内容の吟味をせずにそのまま流用し、トラブルに発展する可能性があるためです。画像データから文字起こしを行う過程で、それぞれのプロジェクトの状況に合わせてアレンジしていただければ幸いです。
