DX推進:「作ってもらう技術」を知る_#5_一緒に頑張るパートナーをちゃんと選ぶ
この本の醍醐味とは作らせる側が責任を持つ「要求定義」
と気づいてから、連呼しています。
システムを作らせる側が特に注力すべき要求定義のまとめ方をFM（Functionality Matrix）という強力なツールで学ぶことができました。
今回からはいよいよ要求定義後のフローとなります。
以下は参考として載せておきます。ここから読み始めた方は参考②は事前に目を通してもらえると嬉しいです
文字数：約6,000
参考①：PMの役割の説明
参考②：そもそもDXとは
参考図書
1．全体フロー（今回は⑤）
①Concept Framing（ゴール明確化）（C章）
②Assessment（現状調査）（D章）
③Business Model（構造策定）（E章）
④Scope（要求定義）（F～M章）
⑤PEW（製品選定/ベンダー選定）（N～R章）
⑥BPP（プロトタイプ検証）（S章）
⑦Design〜Depolyment（開発）（T～W章）
⑧Rollout（稼働）（X章）
ISBN 978-4-532-32399-8
P31〜38
Ｎ章 PEW （Partner Evaluation Workshop）：パートナーの1次選定
【狙い】
・世の中に無数あるパッケージやベンダーの中から提案依頼を3社ほどに絞りこむ作業
・1次選定の対象企業は多く、手に入り易い情報で自分たちがやりたいことにフィットしているか判断しなければならない
ISBN 978-4-532-32399-8
P203
1．選定の13ステップと把握しておくべき難しさ
・これから紹介するベンダー選定は全部で13ステップもある
・これほどまでにステップを設ける理由は、ベンダー選定/パッケージ選定の難しさにある
困難①パッケージ機能だけを見てはダメ
・機能の多さだけを見てはいけない
・ベンダーのプロジェクト遂行能力、保守体制、セキュリティなど多様な観点で調査する必要がある
困難②本当のことが見えにくい
・ベンダーも商売をしているので、良いことをアピールしてくる
・いかに情報を集めて整理するかが重要
困難③独断でなく、巻き込みと合意形成が大事
・今後プロジェクトで影響を受ける人をなるべく巻き込んで、全員が納得するベンダー/パッケージを選定する
困難④必ず予算オーバーする
・最初の見積は粗いので、無駄な機能や作業を精査し縮めていくが、ここが苦しい作業になる
困難⑤：ベンダーの売り手市場
・提案に向けて本気になってもらうための丁寧なコミュニケーションが必要になってきている
ISBN 978-4-532-32399-8
P201～202
PEW_STEP1：ロングリスト作成
・対象としているシステムを構築・提供できるベンダーを広く洗い出す
・情報源は、ネット、過去の取引、人脈、セミナーなど何でもよい
・少しでも可能性のあるベンダーはすべて洗い出し、少なくも10～20社程度抽出しておく
・記載しておくべき内容は、製品特徴、導入実績、連絡先、HPなど
ISBN 978-4-532-32399-8
P203～204
PEW_STEP2：評価基準設定（一次選定）
■一次評価の4つの評価基準
①必須条件を満たしているか
・「この条件を満たしていない場合は選択しない」というノックアウトファクターを確認する
②概算費用
・この時点では正確な投資額を見積もることはできないが、過去の同規模のプロジェクトの費用感は提示してくれるので、桁感は確認する
③機能カバー範囲
・求めている機能を提供できないこともある
・その場合は2次選考に進めないか、あるいはベンダーの組み合わせになる
④企業評価
・システム稼働後も長い付き合いとなるため、安定した関係を築く必要がある
ISBN 978-4-532-32399-8
P206～208
PEW_STEP3：RFI (Request For Information：情報提供依頼書）
・一次評価の基準が決まったら、ベンダーに対してRFIを提示する
・RFIに回答するのもベンダーに作業を強いる
＜RFIの掲載項目＞
①プロジェクト概要
・会社概要、主要製品、従業員などの会社概要、プロジェクトの発足背景・目的など情報提供を依頼する前提の情報を掲載する
・特に「どの業務をシステム化の対象としているのか」は必ず明記する
②現行調査結果
・現行業務の概要、現行システム構成、主要課題などを掲載しておく
・この時点では時間をかけずに回答してほしいので、調査結果をすべて掲載する必要はなく「解決したい課題」「重要施策」をまとめれば良い
③システムへの要求
・将来のシステム構成や期待する主な機能、必須条件、制約条件を掲載する
④提供依頼情報
・ベンダーにどんな情報を提供してほしいか記載する
・「会社概要」「製品情報・特徴」「業界での立ち位置」「事例・実績」「概算費用」などを含むと良い
ISBN 978-4-532-32399-8
P208～212
PEW_STEP4：一次選考
・評価基準に沿って、ロングリストから3~4社に絞る
・この段階では、RFIの情報だけでは足りなくなる
ISBN 978-4-532-32399-8
P212～213
O章 提案を依頼する
【狙い】
・RFP （Request For Proposal：提案依頼書）を作成し、1次通過したベンダーから詳細な提案を受ける
・すべての関係者が納得する決定を心がける
ISBN 978-4-532-32399-8
P215
PEW_STEP5：複数のパートナーの組み合わせ
・このステップは実施しないケースもある
・プロジェクトの対象業務が広く、1社ですべての領域をカバーできない場合、複数のベンダーを組み合わせるケースがある
・複数のベンダーのいいとこ取り（Best of Breed）することで、安くて良いシステムになることもある
・一方で、複数のベンダー調整は発注者側の仕事になるため、プロジェクトのリスクは高まる
ISBN 978-4-532-32399-8
P215～217
PEW_STEP6：評価基準設定（2次選定用）
①機能の実現性（FMレベル）
・ベンダーが提案するパッケージがどの程度のカバー範囲かをFMを使って確認する
・パッケージの標準機能で対応できない機能は諦めるか、カスタマイズ（アドイン）機能を別途発注するかを決める
②非機能要求の実現性
・機能の実現性と同様に、事前に定義した非機能要求に対しての適合率を見る
・機能要求と異なり、セキュリティが担保できないなど1項目がノックアウトファクターになる可能性がある
③柔軟性、操作性
・パッケージ標準機能で微妙にやりたいことが実現できない場合、パッケージを工夫して実現できないか？と考えることが重要
・パッケージの柔軟性や操作性は機能一覧を見ても分からないので、デモで確認するしかない
・必ずカスタマイズも含めたデモを見せてもらうというシナリオを用意しておく
④プロジェクト体制/技術力
・ベンダーのプロジェクトマネージャーやエンジニア、会社のバックアップ体制なども重要な評価基準となる
・長く付き合うパートナーとなるので、人の相性、会社同士のカルチャーが合うかは重要
⑤イニシャルコスト・ランニングコスト
ISBN 978-4-532-32399-8
P217～219
PEW_STEP7：RFP（Request For Proposal：提案依頼書）
・1次選定を終えた時点で、迅速に詳細な提案を依頼し、そのタイミングでRFPを提示する
■RFPに記載する7つのこと
・ベンダーに良い提案とブレが小さい見積を出してもらうことが重要となる
・RFIは15ページ程度だったが、RFPはFMなど参考資料も加えるため100～300ページになる
①プロジェクト概要
・会社概要、プロジェクト概要などRFIと同じ内容で良い
②システム機能要求
・FM、FSを提示し、要望する機能を具体的にベンダーに知らせる
③移行方針
・データ移行は発注側で対応するケースもあるため、ベンダーに依頼する範囲を提示する（W章にて後述）
④前提・制約
・イニシャル/ランニングコストを見積るために、データのボリュームやユーザー数、保守/運用の役割や期待などが重要な情報となる
⑤提案依頼内容
・2次選考では「RFPへの回答 ≒ ベンダーからの提案」となるため、回答書に記載してほしい情報について明示する
⑥見積り
・見積対象の範囲と見積り粒度
観点1）優先する機能としない機能
観点2）業務の範囲（領域ごとに複数のベンダーに分散するとき）
観点3）ハード、ソフト、人件費（できるだけ項目分けしてもらい、特に人件費に注目）
⑦通則
・窓口との連絡方法などを記載しておく
ISBN 978-4-532-32399-8
P219～222
PEW_STEP8：Q&A対応
・ベンダーからRFPへの回答作成のために質問が寄せられるので、今後長期の関係を築くことになるパートナーとして真摯に対応する
・ベンダーも正確な見積り・工数を出すために、詳細な質問が来るので、対応だけに相当な労力が取られることは覚悟しておいた方がよい
ISBN 978-4-532-32399-8
P222～223
PEW_STEP9：Fit&Gap
・パッケージソフトと機能要求とにどれくらい乖離があるのかを明確にするステップ
①機能の実現可否の明確化
・FMのすべてのセルの実現方法について以下の様に分類する
a）カスタマイズなしで実現できるか
b）設定すれば実現できる
c）追加開発や複雑な設定をすれば実現できる(バージョンアップ保証内)
d）追加開発をすれば実現できる（バージョンアップ保証外）
e）何らかの制約があり、このパッケージでは実現できない
・これの分類方法をベンダーに伝えて、RFPに添付したFMの各セルにベンダー自身に回答してもらう
②総合評価
・①が完了したら、システム全体のフィット率を定量的に表現する
・重みに優先度（高：10、中：5、低：2）など設けて、適合率との積の総和など
ISBN 978-4-532-32399-8
P224～226
PEW_STEP10：デモ実施
・デモの目的は自社の業務シナリオに沿ってパッケージを動かしてもらい、対面で質問することでパッケージの理解を深めること
・ベンダーもプロなので、良い機能はアピールし、悪いところは隠す。つまりベンダーにデモストーリーを任せると、各ベンダーのアピール合戦になってしまい評価できなくなる
・デモは本物の機能でなく、紙芝居でも良い。ただしベンダーにも準備の時間は必要なので、準備期間は確保する
＜デモ当日のコツ＞
①幅広い関係者に参加してもらう
②確認ポイントを決めておく
③評価結果の記録を残す
ISBN 978-4-532-32399-8
P226～232
P章 パートナーを決定する
【狙い】
・RFPへの回答、デモを通じてベンダーからの情報を横並びで比較できるようにする
・ベンダー選定は会社同士の付き合いになるので、合意形成が重要
ISBN 978-4-532-32399-8
P234
PEW_STEP11：投資額シミュレーション
＜システム費用パターン＞
①買い切り型
②買い切り・バージョンアップ型
③利用料型
・これらが一番どれが安いかは、システムを何年使うかによって変わる
・ビジネス特性を考慮したシステムを廃止するまでの総コストシミュレーションが必要
ISBN 978-4-532-32399-8
P234～235
PEW_STEP12：評価表の作成
・ベンダー選定の難しさは、「価格」「フィット率」「ベンダーの信頼性」など異なる基準で比較することが原因
・評価項目をしっかり定義し、定量的に表現した評価表を作成することで、ベンダー選定の確度を上げる
・評価項目ごとの配点は、評価項目の全てが同じ重要度ではないため、項目ごとに差をつけると良い
・またコストは評価表の項目から外しておいた方が、コストの配点時点での歪みを起さないので、評価表の評価 × コストバランスで評価する
ISBN 978-4-532-32399-8
P238～240
PEW_STEP13：最終選考
①コアメンバー内の意思決定
②意中のベンダーとの交渉
③説明資料の作成（社内共有用、経営会議用）
④経営会議での決裁
⑤関係者への説明会
ISBN 978-4-532-32399-8
P243～245
参考：SaaSの選定
＜SaaS型の特徴＞
・インターネットを通じて、提供されるサービスを使わせてもらう
・導入に手間がかからないので、迷ったら使ってみる
・初期費用が小さくて済むので、丁寧な選定プロセスを実施するより、まず使ってみる
・SaaSでも導入に手間がかかることもある（自社用の設定が必要、他のSaaSとの連携が必要など）
・SaaS型でPEWを実施する注意点
＋そもそもライトなのでPEWが不要なケースもある
＋SaaSベンダの思想を理解した上で共感できるか確認する
＋SaaSはサービスなので、導入後に（勝手に）仕様が変わる
＋選定の段階で使い勝手を検証しても、1ヶ月後には変わっているが、サービスの根幹をなす思想は変わらない
＋SaaSは通常パッケージと比較して、追加開発がしにくいので、Fit&Gapの結果をデモできちんと裏取りしておく
ISBN 978-4-532-32399-8
P247～248
＜#5_一緒に頑張るパートナーをちゃんと選ぶ所感＞
一緒にプロジェクトを進めるパートナー選定は本当に重要です。
本書にもありましたが、作ってもらった後のフォローが怠ると、結局現場からの不平不満が大きくなり、PMがますますやりにくくなってしまいます。
いきなり業務100%フィットしないのは当たり前なので、どのくらい修正してもらえるかを重要な指標にしたいです。
とは言え、このセクションもこんなに丁寧に記載したものは見たことがないので、大変勉強になりました。
要求定義にしっかり時間をかけて、合意形成の下、資料作成しておけば、かなりスムーズに進めることができると思いました。
本書内では、各ステップに参考の図や表も含めてくれているので、いざという時は見返すことになりそうです。
結婚とは別次元の話ではありますが、ちゃんとパートナーを選ばないといけませんね。
※結婚相手探すために、こんなにチェックされたらイヤですけど、ビジネスでは重要です。
この記事が気に入ったらサポートをしてみませんか？