パートナー企業を選定する
IT開発するパートナー会社を選定することにした。既存システムの保守をしているパートナー企業もいるが、不満はないが満足もしていないこともあり、他社と一緒にコンペには参加してもらうことにした。
契約は要件定義フェーズと、開発フェーズに分けて契約することにした。最初から請負契約にすると、ベンダーはリスクを乗せてくるので割高で妥当性のない金額となるからである。
コンペ大会を開催するにあたり、山田マネジャーが中心となってRFPを作成することになった。しかし、一人では無理なため、他の情報システム部の仲間にも協力をお願いした。
本来ならRFPで、詳細な見積もりが出来るレベルを求めているが、そのためには基本設計レベルまでしなければならない。これでは、ベンダーに設計してもらう必要はなくなり、ベンダーとしての価値は開発することだけになる。とはいえ、情報システム部門で設計を終わらせることは非現実的である。よって、コンペ参加企業には、最低限の実現したい内容を伝えることにして、提案の反応を見ることにした。意図は、これから長くお付き合いするパートナーになるので、スキルを見極めるためである。
D社小林から、パートナーに求めるレベルを決めておいた方が良いと助言があった。ベンダーは要件にあることは開発するが、それ以上でも以下でもない。しかし、発注する側は、それ以上のことを期待する。期待の差は、業務を知っていると思っていることである。ベンダーは、お客様の業務を知らないので、業務ヒアリングをして把握する。つまり、発注する側は、ヒアリングをしたので、知っているはずだ。と認識する。しかし、ベンダーは完璧に理解できるわけもなくシステム設計の視点で見ているで、この業務で何をするか、会社から何を求められているのかまで理解できない。ヒアリングでは一般論の回答になるので、発注者の知識とは差がうまれる。これが、仕様の齟齬となり不満へと発展していく。だから、ベンダーに期待するレベルを決め、提案時に期待レベルに達するスキルがあるか見極める必要がある。
山田マネジャーは、D社小林からの助言を聞いて前職で過去に失敗した経験を思い出した。ユーザー部門はITに詳しいわけでもなく、でもベンダーは専門用語で説明し、期限までに要件を提示しろと言うだけだった。リスケをしてなんとか運用開始までこぎつけたが、このベンダーに保守は任せられないと思いコンサルタントに支援していただき、保守ベンダーと体制の見直しをした。コンサルタントが、経験をいかして新旧の交渉にも支援してもらったことで、結果的にコストも削減することができた。
山田マネジャーは、佐々木マネジャーにベンダーには開発とベンダー側のプロジェクトマネージメントだけを期待したいと話をした。
しかし、ベンダーが苦手な分野である業務改善、社内外の調整等々については、プロジェクトメンバーと情報システム部門だけでは対応仕切れない量であるため、D社小林に相談したところ、S社の立場で支援する数人のコンサルタントを探してもらえることになった。足りない量、補う業務のスキル、規模、コストもあるので、状況をみて判断することにした。とはいえ、コンサルタントは今日声をかけて明日からというわけにはいかないので、情報収集することにした。
システムポリシーを決める
山田マネージャー、佐々木マネージャー、情報システム部門のメンバーは、D社小林から重要なことを助言された。
ベンダーは、開発する範囲で正規化した設計をする。つまり、開発範囲内での最適化である。しかし、ITは時代の変化で改修して育てていくことが必要不可欠である。ようは、個別最適化と全体最適化の両立をするように言われた。
D社小林が過去に知っているプロジェクトで、ほぼ99%が言われた要件の正規化をしたがる。説明しても理解できなかったベンダーも少なくなかった。たとえば、会員データベースの設計で、店舗と密結合をすると、ECやコールセンターを始めた場合に、会員データベースを利用する機能はほぼ改修が入る。しかし、疎結合にしておけば影響は少ない。全てを疎結合にするのではなく、一部の優秀なERPのように目的別に疎結合と密結合を使い分けることが重要である。
これは、経済の流れに迅速に適応することにある。疎結合にもデメリットはあるが、迅速に適応できないことに比べたら、比較にならないぐらいに小さなことである。また、IT投資は期間に比例して金額も上がる。このことは、同じ効果のITを割安に構築できるということにもなる。つまり、全社・部門戦略に迅速に適応し、しかも投資を最小にする重要な考えである。
山田マネージャーは、このことをRFPに追加して、ベンダーの提案をみることにした。
保守体制と版権
本番稼働後の保守内容と体制について検討した。一般的にベンダーは保守契約を勧めるが、保険のようなもので、正直いえば保守の金額に見合った恩恵を受けることは少ない。よって、パッケージの保守は結ばないこととした。その分の費用で、エンジニアに常駐してもらうことにした。このことで、本番運用開始後に発見される仕様ミスの早期改善、新規要件の早期対応が見込めるためである。
また、この体制を実施するために、パッケージを利用する場合にはソースコードの公開とカスタマイズを可能とすることを条件とした。
コンペ大会
コンペ大会には、既存ベンダーを含め5社にすることにした。他の4社の内1社は田中部長が前職でお付き合いのある会社とした。理由は、全くお付き合いのない会社には不安があるからである。また、1社は以前に営業をしてきた会社とした。取引実績はないが、名刺交換をしたのでコンペの1社とした。残りの2社は、インターネットで探した。キーワードは、オムニチャネルを必須として、実績が豊富な企業と、考え方に共感する企業を選んだ。
選定方法は一次選考で2社に絞り、残った2社で最終プレゼンをして決まることとした。一次選考は情報システム部と、佐々木マネジャーで決めることとした。
RFPには下記の内容とした。
- 目的
- 非機能要件
- A41枚程度のやりたいこと（箇条書き）
- 簡単な構成図
- 要望として、成果物のサンプル
- 要望として、PMの経歴と紹介
- 保守内容と体制
- 版権（ソースコード公開とカスタマイズ権利）
NDA締結をして5社の営業と会った。それぞれに同じ資料と話をし、幾つかの質疑応答をして、各社とも持ち帰りをした。1週間後に一次提案書をお願いした。
ベンダーからすれば、要求が曖昧で工数が見積もれないと思うかもしれないが、企業の情報システム部の従業員は大人数ではなく最低限の人数であることや、基本設計レベルまで落とさなければならない。とはいえ、ベンダーは設計の妥当性や、把握のために時間とコストを要求するので、2重コストとも考えられる。このため、要件定義のまとめからパートナー会社には参画してもらうことを想定している。
翌日、C社の営業から電話があり、打ち合わせさせて欲しいとのことだった。翌日なら時間が取れるので、調整した。翌日、C社営業、開発部の部長、PM候補、若手エンジニアの4名がきた。RFPは理解しているが、不明点をヒアリングに来たのである。山田マネジャーと佐々木マネジャーは、答えられる範囲で答えた。
1週間後、提案を受けることにした。
- 既存ベンダーのA社は、既存のお付き合いを前面に提案書を記載してきた。しかし、S社のPMとの連携しているようには感じられなかった。A社に期待していたのは、既存を知っているメリットを活かした提案であったが、他社と同じような提案だった。
- B社は、営業と面識がある企業である。パッケージにカスタマイズする提案だった。提案は網羅性があり、枚数が多かった。また、営業の気合が入っていて、価格交渉を前提としていた。交渉次第では、最安値になる可能性があった。
- C社は、他社と違って追加ヒアリングをしているので、ポイントを押さえた提案だった。
- D社は、経験が豊富にあるので、事例を前面に出した提案だった。ただ、汎用的な提案書のようで、S社ならではの記載が乏しかった。
- E社は、RFPに忠実な提案書だった。しかし、不明点は不明と記載されていて、正しい回答かもしれないが、C社のようにヒアリングすれば良いのにと思ってしまった。
また、D社小林は、全ての企業に「セキュリティ」「パフォーマンス」について質問をした。目的は、技術と経験を確認するためである。教科書通りの回答の場合は、知識はある。実践的なことを回答したら場合は、経験があると判断するためである。もし、実践的な回答が得られなかった場合には、たとえ別の項目での評価が良くても不合格にする予定であった。
一次選考会を開催した。
斎藤財務部長「安くできるのならB社にすれば良い。」
山田「安かろう悪かろうでは困る。経験のあるD社がリスクも少ない。」
佐々木「C社が一番イメージが湧いた。」
その後も意見はあったが、多数決で決めることにした。結果、C社とD社が選ばれた。しかし、財務を預かる齊藤としては、B社から離れられない。そこで、D社小林が、最終プレゼンには3社にしてはどうだと提案した。渋る人もいたが、納得してもらった。結果を5社に一次選考の結果を連絡した。
プロジェクト計画書に記載する概算は？
5社の概算の妥当性を確認した。また、自分たちで計算した概算と比較した。自分たちが計算する数字は、業務を知っているからこその設計工程に無駄がない工数になる傾向がある。しかしながら、実際に蓋開けてみると、知っているつもりだったが、想像と違うことが多々あり、思った以上に工数が上振れするのが現実である。このことから、概算は自分たちで計算した数字を使い、但し書きとして上振れ要素を数値化して示すことにした。つまり、最小と最大を示すことになる。少し幅があり、意思決定者としては判断しづらいかもしれないが、これが実態である。
数字は一人歩きするので、最大だけを示した場合は高いと判断し、値引き交渉をするように指示するか、投資しない判断もある。逆に最小だけを示しても、安くといって投資をしたが追加投資予算が申請され、結局のところ想定以上の投資になってしまい、計画していた財務諸表を変更しなければならないことになる。このことを考えると、経営陣への示す場合には、正しい現実を示すことが大切である。
