社会システム共創部 兼 IT戦略チーム コンサルタント 河合一憲
情報化の進展とともに、情報のクオリティ・スピードに対する要求は高まり、今や、規模・業種にかかわらず、PCが1台もない企業を想像することは非常に難しい。企業は、PC端末を用いて、インターネット上で情報を収集し、分析し、資料を作成している。また、さらなる情報の共有・管理の高度化を目指し、システム会社から情報システムを調達している。自社の会計・販売・人事情報の管理のためのパッケージシステム導入や、社員の情報交換の場としてのグループウェアを購入している企業も多いだろう。ところが、これらの情報システムを調達した企業の多くが「調達を失敗した」と後悔している。PC端末は、CPUやストレージ、メモリなどの違いはあるものの、基本的には、どのメーカーのどの製品であっても、企業は使用することができる。しかし、情報システムは自社の特性に合ったパッケージを正確に選定しなければ期待した効果は得られない。失敗したと感じている企業は、システムから出力される情報が期待したものと違ったと考えているケースがほとんどである。
では、なぜそのような結果になってしまうのか。本稿では、システム調達時にシステム担当者が何をすべきなのか、調達前に行うべきことを整理・解説する。
システム調達失敗はベンダーのせいなのか？
唐突な質問だが、システム調達を考える際には、まさにこの問いが本質となる。調達が思い通りに進まなかった企業は「ベンダーが悪い」と考えがちである。「いつまでたってもカットオーバーできない」、「高額な費用を請求された」、「システムに求める機能が全く足りていない」などの結果から、「システム会社のパフォーマンスが悪い」ために、調達に失敗したと結論付けているケースが多い。
確かに、システム会社に非があることもある。システム会社が案件を受注するためにフィージビリティが低い工期や金額を提示した結果、いざ開発に入るとリソースが足りなくなりプロジェクトが炎上、失敗するということは珍しい事象ではない。
もともと、情報システムというもの自体、情報の非対称性が著しい製品である。システム会社は当然、自社のシステムを詳細に把握している一方、企業側は、展示会やパンフレット、HPくらいでしか初期情報は収集できない。このような状況下では、システム会社の言いなりになってしまうことはやむを得ないということもできる。
しかし、冷静に振り返ってみてほしい。自社としてやるべきことは、調達時に十分に果たしただろうか。システム会社のパッケージシステムに情報の非対称性がある一方で、当社の事業についてもアシンメトリーは発生している。システム会社は、当社の置かれている業界、事業環境、社内事情について詳細まで把握できない。そのような事業に関する説明がない状態で、システム構築を進められると「こうしたい」といわれた事項を、単純にシステムに取り込む作業をするしかない。そこであとから、業界の商慣習や暗黙の了解から「この機能は当然あるものだと思っていた」などと言われても、システム会社としては対応できない。もし改修をする必要があるのであれば、追加の人件費等を費用として請求し、追加構築するしかないのだ。
システム調達に満足できなかった経験のある企業、担当者の方はこの点を振り返ってほしい。事前に自社・業界について十分に説明しただろうか、要件は最初に可能な限りリクエストしただろうか、支払方法は契約で明記しただろうか。後出しじゃんけんでは、期待するアウトプットは絶対に出てこないということを理解してほしい。
そういうと、「古くからの付き合いのあるベンダーにお願いしたから大丈夫」と考えている経営者・担当者の方がいるかもしれない。もちろん、それであれば確かに当社の事業については精通しているかもしれない。ここ数年の組織改編や業績、経営計画などは理解しているだろう。だが、本当にそれでよいのだろうか。
システム会社は無数に存在する。それぞれのシステム会社が得意領域・主力製品を掲げ、市場競争を生き抜いている。「古くから付き合っているシステム会社」は、今回調達したいシステムが本当に得意なのだろうか。たとえば、前回は会計システムをそのシステム会社から調達し、結果、成功したかもしれないが、今回調達する在庫管理システムは実績がないかもしれない。もし、実績がなかったとしても、システム会社が「できません」と率直に告白することは稀だろう。これはシステム会社が不誠実ということではなく、目の前に案件や収益源があってそれを逃してはならない、と思うのは、企業であればどこも経験するところであろう。
だからこそ、調達先を決める前に十分にシステム会社そのものを調査する必要がある。先ほども述べたように新システムの情報を取得することは難しい。それでも、できる限り、他社事例を調べ、プロアクティブに情報を収集することが成功する調達の第一歩となる。そのうえで公正・公平な観点でシステム会社を選ぶべきである。
何千万円・何億円の投資になる情報システム調達の失敗を、システム会社のせい、とうそぶいても、その資金と時間が返ってくるわけではない。膨大なリソースを投資するからこそ、万全を期して対応すべきなのである。
調達のボトムアップアプローチとトップダウンアプローチ
それでは、システム担当者は調達時に何を実施すべきなのか。まず、調達をするかどうかの判断から担当者は関わるべきである。
現状のシステムからの変更がなぜ必要なのか、その理由は本当に正当性があるのかということをシステムのエキスパートとして分析する必要がある。
システムが使いにくい、という理由でシステム更改を検討している企業があれば、それは少し待ってほしい。その使いにくさは誰が感じている不満なのか、それにより当社はどのような影響を受けているのか。その不満・課題を社内で共有できているだろうか。
システムに不満のないユーザはいない。読者の方も大なり小なり自社のシステムに不満はあるだろう。ただ、それをボトムアップ形式ですべて次期システムの要件として取り込んでいては、どれだけシステム投資予算を組んでも足りない。企業の目標との整合性など全社的な視点から調達を実施する必要がある。
一方で、トップダウンのシステム投資にも危険がある。経営管理の高度化、予実分析や決算早期化など管理面の課題解決からのシステム投資もあるだろう。それは、確かに理にかなっているが、システムを変更すれば一過性に現状業務に支障をきたすことになる。新システム上でこれまで通りの業務プロセスを採用したとしても、インターフェースが変われば、業務スピードは低下する。また、マニュアルを読み込む時間、ベンダーからの研修を受ける時間も必要だろう。長期的には効果のある投資でも一時的に負の影響が発生することを、マネジメント層に対して、事前に理解をしてもらう必要がある。システム担当者は、軌道に乗り始めた際の効果を定量的に分析し、経営陣に対して、カットオーバー後、どのくらいで効果が出るかを説明しておくことも必要業務となる。
調達関連の文書を作成すべき
システム調達では、システム会社との言った・言わない、の水掛け論が発生しがちである。「その要件は事前に伝えた」、「いや、聞いていない」といったものである。それを防ぐためには事前に文書で記録を残しておくことが必要である。
特に、調達文書として一般的に作成されるのが以下の４点である。
まず、情報提供依頼書（RFI）である。システムは一度導入すれば10年前後使用するものであるし、またそのくらいを想定していなければ投資対効果（ROI）を高めることは難しいだろう。しかし、その10年の間に、極端な話、システム会社が倒産してしまっては保守・メンテナンス対応において支障をきたす可能性がある。そのため、そのシステム会社の財務情報や導入実績などを事前に送付してもらい、その企業の状況を事前に判断することになる。このRFIでどのような項目を盛り込むのか、それを決めるのがシステム担当者の任務になる。企業情報など簡単な概要だけ受領しても表面的で意味のあるものにならず、また、先方から受領する情報ばかりでは、自社のポジティブな面のみを強調した売り込み資料ばかりになり、全く評価項目として機能しないからだ。それを防止するためには、自社が求めるシステム概要とシステム会社を社内で意思統一し、文書化しておくことが欠かせない。
次が、提案依頼書（RFP）である。これは入札資料の中でも特に重要である。期待要件、納期、現状システム構成図、将来イメージ、企業概要などシステム会社が入札の可否を判断するために必要な情報をすべて盛り込んでおく。このRFPを閲覧したうえで、システム会社が入札した場合、システム会社は当社の期待するシステムを構築できると判断したとみなすことができる。もちろん、詳細な要件定義や設計開発段階で多少の機能要求や金額の変動はあるが、ここでしっかりとしたRFPを作成できていれば、今後、金額や仕様などで大きなトラブルになることを防ぐことができる。担当者は、このRFPを作成する責任を保持していると考えるべきである。言うまでもなく、担当者のみで要求機能をまとめることは難しいため、担当者はコーディネート役となり、意思決定は全社で取り組むべきである。
続いて、入札招聘書（IFB）である。これはRFPを送付することで代用するケースもあるが、システム会社に入札を依頼する資料になる。決まった形式はないが、入札説明会の開催日時や入札期日などを記載しているケースが多い。
最後が見積依頼書（RFQ）である。これは、システム調達よりも建設業などのプロジェクトでよく使われている。見積もり、といっても企業ごとにオプションの有無や税込・税抜など多様な見積もり結果が出てきて対照的に比較することができないということが起こりうる。そのため、見積依頼書を記載してもらうことで統一的な金額を横ならべで比較することがある。ただし、これはシステム調達では難しい。建設資材などの調達では比較的使いやすいが、システム調達はシステム会社ごとにパッケージ機能にばらつきがあり、同じフォーマットで記載することが難しい。パッケージシステムの金額だけ記載されても比較しにくいのが現状である。
以上のように４つの調達文書があるものの、システム調達においては、RFI、RFPの2つがとりわけ重要になる。これらは決まったテンプレートを使えばよいというものではない。システム会社にとって分かりやすく、先方の認識に齟齬が出ないものとするべきである。初めにしっかりと合意できていれば、そのあと大きく誤差が生じる可能性が小さくできる。
調達先が決まった後の契約も重要
すべてのビジネス領域において言えることだが、万全な準備をしているからといって、その後のプロセスからリスクが完全に排除されることはない。システムの観点でいえば、期待するものができなかった場合、無駄な出費は極力抑えたいと考えるのは当然である。そのためには調達契約で支払方法を明確にしておくことが欠かせない。国際的に用いられているプロジェクトマネジメントの体系であるPMBOKでは様々な契約タイプが紹介されているが、ここでいくつかご紹介をしたい。
まず、定額契約である。これは、はじめにいくらで調達をする、と決めてしまう契約タイプである。これは調達する側としては、ポジティブな結果になるケースが多い契約である。プロジェクトに参画した人ならお分かりだろうが、プロジェクトは、その金額の大小はあれ、予算よりもコストがかかって終結することが一般的だ。そのため、調達をする側からすると、開始時に支払金額を決めてしまうこのタイプは非常に都合がいい。一方で、システム会社からするとリスクのある契約となり、これで合意ができるケースはほとんどない。そこで、完全な定額ではなく、マクロ環境の変化（インフレ率や原材料コストの変動など）を事前に考慮した経済価格調整付定額契約というものもある。ただし、これでも合意は難しいだろう。確かに市場環境の変化は意識されているものの、システム開発で最も変動リスクのある人件費や工数の増加などは含まれておらず、開発する側からするとリスクは相当程度、残存している。
そこで、定額契約に代わる手法として、実費償還契約がある。実際にかかった費用とシステム会社への報酬分を合わせて支払うという形である。これは、システム会社にとってはかかったコストは回収できるため、非常に安心できる契約体系である。しかし、この契約では、システム会社側のミスでコストアップした場合でも当社は支払いを行わなければならない。当然、調達をする側としては、無駄な支払いは受けいれられないため、「実費の範囲」というものを事前に決めておく必要がある。
定額契約と実費償還契約を掛け合わせたものがタイム＆マテリアル契約（T＆M契約）である。これは、「単価×量」で支払額が決まり、その単価を契約で事前に決めておくものになる。たとえば、期間を決めておけば、システム会社はその期間内に完了するように現場は行動するだろう。人件費単価を決めておけば、人件費の契約後の高騰を抑えられる。可能な限り、キャップ（上限）を設定し、大幅なコスト増加を抑える契約がこのタイプである。ただし、システム会社としては、キャップの限界は請求できるため、コストを抑えるインセンティブは小さくなる。
これらは、あくまで契約の体系であって細かい条項で交渉をする必要があることは言うまでもない。また、このテーマはシステム担当というよりも、法務部の所管になるかもしれない。ただし、システム調達における契約は、金額を調整すればよいというものではない。金額・期間を調整するということは、すなわち、システムのスコープを変更することが必要になる。担当者は、システムのプロフェッショナルとして、スコープ、費用、納期を調整すべきである。契約にも積極的に関与して、のちのトラブル防止につながる役割も担うべきである。調達先が決まったから安心、ということではなく、契約するまでが調達業務であるという意識を持ってほしい。
システム部門は企業の戦略機能の一部であるべき
システム部門は、一般的には管理部門に分類される。営業などフロントで収益を稼ぐ部門を支える裏方的な役割にとらえられることが多い。
もちろん、サーバの保守やネットワークの管理などは縁の下の力持ちとしての面が確かにあり、企業の持続的成長を支える役割を持つ。しかし、システム部門は、企業戦略と同じベクトルを持っていなければならない。「現在の課題を解決する」という「点」の役割と同時に、企業の将来を見据えた「線」の役割があるといえるだろう。
さらに、システムを取り巻く環境変化にも敏感になるべきだろう。IoT・IoA、ビッグデータ、AI、ロボティクスなど、情報システムには、これまででは想像もできなかったドラスティックなイノベーションを起こす要因が待ち構えている。
これからのシステム担当は、これまでのような発生事象に対応するといった後追いの姿勢では企業の期待に応えられない。様々な観点から将来を見据え、企業のあるべき姿を見通し、最適なシステム調達をする、そういった高度な役割が求められている。経営に関与しているという高い意識と自負を持ってシステム調達に取り組んでいただければ、必ずや有意義なシステムを構築できると考えている。
（2016年5月20日「三菱UFJリサーチ&コンサルティング」より転載）