システムを発注するユーザ企業の経営者や事業責任者にとってIT投資は頭痛の種のひとつであるに違いありません。

「リリースしたはずなのに幾度となく繰り返される追加開発。いったいいつまで続くのか? 結局いくらになるのだろうか?」「社内では新システムの不満こそあれ、良くなったという声を聞かない。本当に投資対効果があったのだろうか?」――このような疑問をもっていらっしゃる経営トップは、決して少なくないと思います。

そうした経営トップの皆様に力添えをすべく、本連載では、経営者の立場からは見えづらいシステム開発の裏事情に触れながら、上記のような事象が発生する原因とその解決策について解説していきます。

開発したシステムに対して、不満や疑問を抱く経営者は少なくないはず。その背後には、経営者からは見えづらいシステム開発業界独特の事情が。

第1回となる今回は、システム開発の現場でよく起こるトラブルを紹介しておきましょう。典型的なトラブルなので、実際に経験した方も多いかもしれません。

システム開発にありがちなトラブル

システムに関連して引き起こされるトラブルは、会社の存続さえも脅かすビジネス・イシューになりかねません。よくある例を2つ挙げておきましょう。

それはたとえば、こんな話です。

何度も追加費用が請求される

月曜日の朝、オフィスに来てスケジュールを見ると、朝一で新しい予定が入っている。開発中のシステムを発注している開発ベンダーのマネージャーとの打ち合わせだ。設定したのは情シス部長。開発中のシステムの費用についての相談だという。

ろくな話ではないだろうと思いながら打ち合わせに参加する。案の定、要件が増えたので5000万円超過するという話だ。

しかし、数ヶ月前に5000万円の追加をしたばかりだ。そのときにこれ以上の追加が発生しないようにしてくれと言ったはずだ。もともとの予算が2億円くらいのシステムなのに、併せて1億円の超過だなんて、常識では考えられない。

開発ベンダーが提示した資料を見る。金額が超過していることはわかるが、明細を見ても細かい機能項目が並んでいるだけで、まったくわからない。

――これはベンダーの見積もりミスじゃないのか?

――基本設計に入って画面を見ている中で要件の修正が出てきたのだから、うちに責任があるって？ そんなこと、そのときに言わずに、なぜ今頃になってまとめて言ってくるんだ?

――そもそも要件定義をしているときに理解できていなかったからじゃないのか?

――1億円の利益を得るのがどれほど大変なことかわかっているのか? やっとの思いで積み上げた利益をこの開発の超過分に使えというのか?

こんなことも起きます。

システムが突然ダウンする

インターネットでの新しいサービスがリリースされ、評判も上々で、アクセスも次第に増えてきた。久々に休みがとれた連休の最終日、深夜に携帯電話が鳴る。営業部門の責任者からだ。

電話に出ると、新サービスのシステムがダウンしたという。とりあえず復旧しているが、休み明け早々に状況を共有して対応策を検討するとのことである。

システムのダウンとそのビジネス上のインパクトについて報告を受ける。ダウンの原因は、連休でアクセスが集中したからだという。一部のユーザからはクレームが来ていて、対応している営業はカンカンに怒っている。

今はアクセスが減ったので落ち着いているが、またアクセスが増えるとダウンするかもしれない。ベンダーからは原因がわからないので、当面サーバーを増強して対応するべき、と提案してきている。ログが出ていないので、分析が十分にできないという話だ。

――サーバー増強の費用はうちが持つんだろう。それで解決できる保証はどこにあるんだ?

――原因がわからないとはどういうことだ? ベンダーの設計ミスじゃないのか?

――こちらが示した非機能要件※1を超えているから責任はないって? 適切な数値くらいアドバイスしてくれるのが、プロがやるべきことじゃないのか?

――お客様の信用を失うことがどれほど重大なことなのかわかっているのか? 今回のシステムでお客様を増やすつもりが、逆に減らしてどうする!


※1 非機能要件: システムの機能面以外の要件。性能、信頼性、拡張性、セキュリティなどが該当する。機能要件がシステム利用者の操作や業務といった観点から洗い出されるのに対し、非機能要件はシステム管理/運用の観点から洗い出されるため、ある程度ITに習熟していなければ定義するのは難しい。

現在、システムの開発は、開発を専門に行うベンダーにRFP（Request For Proposal: 提案依頼書）を提示して提案を競わせ、その結果を見て発注するのが一般的になっています。ホスト時代からオープンシステムの時代になり、技術が多様化する中で、大企業を中心に内部に抱えていた開発部門を子会社化したり、縮小したりして開発をアウトソーシングすることが進められてきました。

システム開発を自社で行うよりも、そのプロである企業にお任せするというのはとても合理的な考え方です。ところが、特に最近、上で挙げたようなシステム開発に関わるトラブルが増えてきています。

知らないフリはもうできない

筆者は、IT業界の中で珍しい立ち位置にある会社に所属しています。

普段はコンサルティング会社として、主に「システムを発注するユーザ企業」を支援するコンサルティングサービスを提供しているのですが、社内には先端技術に習熟したスキルの高い技術者が多く在籍しており、場合によってはシステムの開発を請け負ったりもします。このため、発注側企業の事情も受注側企業の事情も、さらに、そこで働く技術者の事情もわかります。加えて、筆者は小さいながらも関連会社の社長を兼務しているので、経営者の視点も持っています。

そのような中で、あるときは当事者の立場から、あるときは解決を支援する立場から、上に紹介したような様々なトラブルに関わってきました。それぞれの問題にはそれぞれに固有の事情があり、その原因は一言で説明できるものではありません。

しかし、確実に言えることがひとつあります。それは、もはや開発ベンダーに任せきりにして安心していられる時代ではなくなったということです。

今や、システムは、新サービス提供や業務革新を実現するうえでなくてはならない存在になっています。そのシステムの開発が計画通りに進まなかったり、トラブルを起こしたりしているようでは、企業活動の基盤が脆弱だと言わざるをえません。

経営に責任を持つ者として、「システムについてはよくわからないから」と言い逃れをして担当部署と開発ベンダーに任せきりにするといったことは、もう許されないのです。経営トップ自らが関心を持ち、システム開発に積極的に関わっていく必要があります。

そうは言っても、もちろん経営トップが果たすべき責務と、情シス部門や開発ベンダーが果たすべき責務は異なります。経営トップの立場で大切なのは、「情シス部門と開発ベンダーに、高いビジネス価値を生み出すことのできるシステムを確実に作らせるためには何をすべきか」を考えることです。

次回は、これからのユーザ企業におけるシステム開発への関わり方として、「ユーザ主導開発」という考え方と、それを推進する上で経営トップに必要なことは何かを説明します。

(イラスト Hayabusa)

執筆者紹介

林 浩一(KOICHI HAYASHI)
- ウルシステムズ ディレクター


1986年大阪大学大学院卒。富士ゼロックスの総合研究所、外資系データベースベンダーを経て、2002年より現職。インターネット電子商取引、SOAによるシステム連携、XMLによるワークフロー制御、非定型ドキュメント管理などの分野で、理論と実践の両面において深い知見を持つ。

現在、ビジネスとITのギャップを埋めるためのコンサルティング事業部を率い、ユーザー企業に対して「ITを活用したビジネス企画立案」、「PMO組織の立ち上げ」、「企業内標準フレームワーク構築」、「開発プロセス導入」などを中心としたコンサルティングサービスを提供するとともに、関連会社の社長も兼務している。

また、「ビジネスを成功に導くシステムの開発には、発注者であるユーザ企業の主体的な関わりが大切だ」とする考えの下、「ユーザ主導開発」手法の確立に向けた活動を推進。それを担うことのできる高度IT人材の育成にも注力している。

著書に『間違いだらけのシステム開発』(翔泳社刊)、『ITエンジニアのロジカル・シンキング・テクニック』(IDGジャパン刊)がある。