情シスが存在しない会社で基幹システムを入れ替えるとどうなってしまうのか？

受け入れテストNG

「もはや、どう進めていいのかもわかりません…」

ある会社から相談がありました。

基幹システムの入れ替えがうまくいかないそうです。

受け入れテストで「検収NG」となり、ベンダーと揉めているとのこと。

「とりあえず話を聞いてほしい」

とのことで話を伺ってみると、想像以上に厳しい状況でした…。

この会社には、ある特徴があります。

それは「情シスが存在しない」こと。

これがシステム導入において、非常に大きな影響を与えるのでした。

情シスが存在しないと、どうなるのでしょうか？

システム刷新の背景

現行システムは、Accessで作った販売管理システムが実に15年、稼働していました。これまで特に大きな問題は発生しておらず、細かな変更に対しては、運用でカバーしていました。

ところが、去年の10月から義務化された「インボイス制度」は、運用でカバーできる範囲を超えていたため、システムの見直しが急務となります。

出社しないと使えず、細かい修正要望も積み上がっていたため、これを機に「Webシステムで刷新しよう！」となります。

Accessを作ったベンダーはすでにいません。そこで、新たにベンダーを探して、開発してもらうことにしました。

ところが、ベンダーと交渉する情シスが存在しません。

そのため、総務の事務職メンバーが担当しました。

ベンダー選定にて・・・

ベンダー選定において、そもそもベンダーに声をかける「基準」がわかりません。

当然、「RFP」という言葉すら知りません。「相見積もり」という発想もありません。

そのため「プログラム開発　会社」で検索ヒットしたある会社を「一本釣り」して、決めてしまいます。

しかし、その会社はプログラマー人材を派遣する「派遣会社」でした。

もはや、ITベンダーですらありません。

この辺りから、聞いていてお腹が痛くなってきました（苦笑）

ベンダーとの開発契約にて・・・

次に、このベンダー風の業者（説明がややこしくなるので、以降は「ベンダー」と呼びます）との契約調整に入ります。

「要件定義をどう進めるのか？」

とベンダーに聞かれたものの、困ってしまいました。

15年前に開発した当時の関係者は誰も残っていません。システムは完全にブラックボックスです。要件定義をできる人がいないのです。

そこで妙案？を思いつきます。

「現行Accessの通りに作ってください」

Accessの画面ハードコピーを渡して、それをもとに作ってもらうようお願いしました。

するとベンダー側はこう言いました。

「それなら費用を安く抑えて提案できます！」

そのため、要件定義をスキップし、開発のみの契約となりました。

「じゃあ、そのシステム開発契約の支払いを止めているんですね」

と聞くと、驚くべき回答がきました。

「契約時に、前金として半額払いました」

さすがに残り半分は払っていないようですが、「検収」という概念がないようです。

受け入れテストにて・・・

次に、受け入れテストの状況を確認してみました。

バグが多発したようです。数字がおかしいというレベルではなく、そもそもボタンを押しても動かなかったり、エラーで途中で止まってしまったり、「単体テストレベル」のバグが続出しました。

もはやユーザーが「バグ出し要員」となり、連日、多くの指摘を行います。修正されたらまた確認し、新たなバグが発見されます。

「ベンダーが単体テストしているかを確認しましたか？」

と聞いてみると

「え？それがフツーなんですか？」

と逆に聞かれました。ベンダーが単体テストをするという概念がなかったようです。

単体テストレベルのバグが落ち着いてきたころ、次に数字がおかしい部分やロジックが不適切な「仕様バグ」について調整しようとしました。ところが、ベンダーの担当者に話が通じません。

業務要件を把握しているベンダー担当者が、誰もいないのです。

仕方なく業務要件の説明資料をつくり、ベンダーに説明をしました。

この繰り返しで、スケジュールは遅れる一方でした。

そして、リリース予定日から6ヶ月が経過しましたが、バグが収束する気配がまったく見えません。もう見通しが立たなくなってしまいました。

根本原因

この話を振り返ってみて、いろいろツッコミどころはあります。

様々な原因がありますが、その中でも根本的な原因は何でしょうか？

私は次の一言に尽きると思います。

『情シス不在』

情シスがないため、システム導入の基本を知らないのです。組織にノウハウが溜まらないのです。

そのため、あらゆるチェックポイントがスルーされ、制御不能に陥っているのです。

その中でも、大きなミスを2つ犯しました。

その一つは「要件定義スキップ」です。

要件定義スキップの代償とは何でしょうか？

それは「ベンダーが業務を覚えない」ということです。

そのため、業務を知らない人が作ったシステムは、業務考慮が漏れ、仕様バグが多発するのです。

それを是正しようにも、話が通じないので「モグラ叩き」でしかありません。表面的なバグを指摘しても、コアロジックが間違っているので次から次へと新しいバグが顕在化します。

さらにベンダー側にとっても「要件定義」というハードルがないことは、悪い方向に作用しました。「システムエンジニア」よりも単価が低い「プログラマー」だけを集めて利益を最大化しようとします。

そのため、課題が発生してもユーザーと調整できるレベルのメンバーは不在です。具体的な指示待ちのプログラマーでは、状況を打開できないのです。

そして、もう一つが「ベンダー選定ミス」です。

システム導入は金額が大きいゆえに、慎重にベンダーを選定する必要があります。それが、RFIやRFP、そしてベンダー提案評価などの各種ノウハウにつながります。

これらがないまま、不適切なベンダーを選んでしまったなら、もう手遅れとなります。いくらユーザーが頑張っても、ベンダー側の実力不足で品質が確保できなくなります。

これらは、情シスにとってみると当たり前のことです。

情シス不在の穴は、非常に大きいのです。

仕切り直し

「この開発費用は安いんですか？」

最後に聞かれました。

「安すぎます。これで作れたら奇跡です。通常はこの2倍、3倍はしますよ」

と答えると、相談された方は唖然としていました。

この会社は、仕切り直しをすることになりました。

今度はきちんと適正な予算を確保し、進めていきます。

そして、情シス担当を1名育てることにしました。

その前に、ベンダーとの関係をどうするのかも決めないといけません。

課題は山積みですが、きちんとステップを踏んでいく他はないのです。

明けない夜はありません。

頑張っていきましょう！