ITCの動き方 業者選定編
これはITCが仕様書を取り纏めてから業者選定に至るまでにどのようなステップを踏んで進めていくのかを紹介するものです。事例をもとに構成していますが、説明用に加えた点や事情により省いた点もあり、事実そのままを示すものではありません。
企画作成からシステム化の着手に向けた仕事には、大きなものが二つある。
ひとつはＲＦＰ（提案要求書）を作成してＳＩ業者を選定する「調達」のステップであり、もうひとつは導入を予定するシステムについて投資と効果を明確にして会社としての意思決定を得る「承認」のステップである。
承認のステップ
承認は本来は社内の手続きであり、外部の人間が口を挟むことではないかもしれないが、資料の準備や進め方についてはＩＴＣの支援が期待されるところである。調達前にシステム導入の十分な効果を説明できないと投資費用について保守的な経営層を納得させられないし、疑念を抱かれたままで進めると後になってプロジェクトに余計な干渉を招くおそれもある。
○費用対効果の見積り
今回、経営トップは計画に賛同していたが、いざ投資となると考え込む幹部もおり、そんな予算があるなら製造設備を買ったほうが良いのではという声まであった。そのために導入の費用対効果を明確にすることが必要であった。それも、どうしても金額でみたいという要望が出ていた。
システム投資について費用を出すことはそれほど難しくはないが、効果を見込むことについては難しい面がある。一昔前であれば、業務効率化で○○人削減で良かったが、最近は省力化だけでなく高度化を狙うシステムも多いので、合理化だけでは十分な効果を説明できない場合も増えている。また、プロジェクトの目的はシステムの導入ではなく新業務の実現であり、その中からシステムの直接効果だけを抜き出すことも難しい。
そこで、新業務全体のメリットを中心におき、そのためにシステムは必須であることを説明するようにした。そして新業務の効果額は、アクションプランで設定した施策の指標からロジックを想定して金額換算した。
これで納得を願った経営者には失礼なことだが、所詮は見込にすぎないので、合理的に説明できる程度で良く、あまりに精緻に計算を行う必要はないと思う。
調達のステップ
○ＲＦＰの作成
調達については、先ず、これまでに検討した新業務の内容を整理してＲＦＰを作成した。
記載項目についてはＩＴＣＡが提供している雛形も参照したが、そのままでは細かすぎる部分もあったので適当に項目を取捨選択した。
また、雛形では仕様の説明と提案手続きが一緒になっているが、これは別々に「システム仕様書」と「提案要領」に分けて作成した。システム仕様書はそのまま開発の基本になるが、提案要領は手続き面を説明するもので、決まる手順も別だし、手続きは変更される場合もあるためである。
記載内容については、別紙１「提案要領sample」を参照のこと。（「仕様書」については前掲の企画編に添付している。）
なお、今回は予算枠を提示したが、提示すべきかどうかは考えものである。業者によってはその金額に収束するように中身を調整して作成してくるものもあり、提案の自由度を奪う可能性もある。企業規模（売上や収益、人員）を示せばだいたいの目安は付けられるので、内部で予算枠を設定しておくことは必要だが、ＲＦＰに盛り込む必要はないかもしれないと感じている。
○提案依頼先の選定
提案依頼先については、これまでに関係のあったところや、企画段階から情報提供を依頼していた会社など１０社程度を選定しお願いした。
仕様書には企業の経営計画が盛り込まれているので、外部に対しては秘密厳守にしないといけない。そのため、依頼先とは先ず覚書を交わして情報漏えいを防ぐ約束をとったうえでＲＦＰを送付した。
依頼をかけた先の中から仕様書を見ての辞退が数社存在した。この仕様書は詳細とまでいかなくても、経営目標を実現する施策の折込みや、現状かかえている問題点の解決策を求めていたもので、生半可な対応では提案にはならない。そのために２週間程度も作成期間をとったうえで依頼したが、辞退した会社の多くは仕様書を甘く見て、自分たちが使用している簡単な提案書の雛形を流用すればすぐに書けると思っていたのだろうと推測している。
業者の選定
提案書は６社程度から提出され、次のように業者評価を行って調達先を選定した。
業者評価については、評価の客観性と結果に対する合意形成（納得）のしやすさが必要になる。そのために、評価基準を具体的に記述したいくつかの項目に分けて設定し、かつ、点数で評価を行うことで客観性をもたせることにした。そして、各人の個別評価を積み上げて全体の評価に集約する過程をとることで結果に対する合意が得やすいようにした。
選定のために、評価項目（評価の視点）を整理した評価シートを作成し、各項目の重要度に応じて点数には重み付けを行った。評価項目は、各部署の担当が主体でみるもの、情報システム担当でないとわからないもの、全員で評価するべきものがあるのでシートも数種類を用意した。（評価シートの例については別紙２を参照）
なお、ＩＴＣは評価シート作成などの準備作業や評価後のまとめについて支援を行ったが、特定のベンダに肩入れしているような印象をもたれたくないので、評価そのものには参加しなかった。
○業者評価は以下の３つの面に分けて実施した。
①提案書の評価
提案依頼に記載した項目を満たしているかどうか、記述内容が理解しやすく納得ができるものかどうかをチェックした。この提案書の段階で数社に絞り込む場合もある。
②デモによる確認（パッケージを使用する場合）
うまく業務が処理できるか（業務処理に適合しているかどうか）、システムの使用感はどうか（使いやすさ、わかりやすさ）を実機でみてチェックした。
③プレゼンにおける評価
業者からの提案プレゼンを聞き、取り組み度合い（熱意が感じられるか）、提案内容に対する説得度（説明のわかりやすさ）をチェックし、その場での質問に対する回答も参考にした。
①については評価項目ごとに提案書のどの部分を見るべきなのかなどのコメントを付しておけば、確認もしやすくなる。そのために、提案書の目次はある程度まで統一するようにＲＦＰの中で指示しておいた。
また、見積書についても比較検討がしやすいように、大きな区分をＲＦＰで提示しておいた。
○業者評価
プレゼンの終了後、評価シートを回収し、各社の点数を集計した。
そして、この評価点に見積内容を合わせて総合評価で業者選定を行った。
見積は一次的には開発費用をみるが、導入後の運用コストも参考とした。
総合評価は、単に価格の安さだけでなく、評価結果とのバランスで最適な業者を選択するものであり、価格が高くても予算の枠内であり、評価結果が良ければ選択とする考え方である。
結果、今回の調達先は同業種での導入実績が多いパッケージを適用した大手ベンダに決定した。会社の信用力、パッケージの導入実績と担当者の印象が決め手となったようだ。
業者決定後に、システム調達を分かる人が少ないため、一般の購入品と同様に買い叩こうという動きがあったが、人がやることなので無理を強いると品質面に影響が出かねないし、やりきれなくなった場合にはお互いに不幸なことになるので、ほどほどにするようにお願いした。
業者決定後の動き方（開発中の支援）
調達先が決まったあとの開発工程はベンダ主体の作業になるが、ＩＴＣも立ち上げ時期には積極的に参加する必要がある。
開発開始当初は、ユーザはベンダを業者扱いして無理を言うことも多いし、ベンダはユーザへの警戒感から保守的になる傾向がある。あまりユーザが無理を通すと意図通りのスケジュールで進まなくなるし、ベンダが殻にこもると柔軟な見直しが通りにくくなり、目的にあったシステム機能が実現できなくなる。そこで、ＩＴＣはベンダとユーザの信頼関係ができるまで、積極的に間にたって利害を調整してプロジェクトをうまく運営していくことが求められる。
開発工程が進んでくると検討範囲が広がり、内容も細かくなるので全ての打ち合わせに参加することはできない。そこで、週次で進捗会を設定し、その中で開発の進み具合や問題点を確認することになる。進捗会で明らかになった重要な課題については、別に検討の時間を設定し、ＩＴＣはそこに参加して解決を補助するような動きをした。
次は、開発されたシステムを企業に導入する作業に入ることになる。
ITC の動き方 導入編
参考：提案内容サンプル 評価シート実際のものとは内容は変更しています。 |
