システム開発に,トラブルやアクシデントはつきもの。スケジュール通りの稼働に向けた懸命の徹夜作業にもかかわらず,大きな障害が立ちはだかり本番稼働が危ぶまれることもしばしばだ。そんな時,「納期遅延は契約違反。損害賠償を請求するぞ!」と顧客から迫られたS子さんは…。

イラスト 野村 タケオ

 S子さん(32歳)が企業のシステム開発を受託するITサービス企業のF社に入社してから,10年が経った。元々は文系だったS子さんだが,生来の真面目さと負けん気の強さで実力をつけ,今や押しも押されもしない中堅エンジニアである。そんなS子さんは2002年9月から,K社における販売管理システム刷新プロジェクトでチームリーダーの1人として奮闘している。

 K社は若い女性から圧倒的な支持を得ている衣料品メーカーで,近年の消費不況にもかかわらず業績はすこぶる順調だ。同社が新たな販売管理システムの導入を決断したのは,受注から出荷指示,納品,請求・売掛管理までを,一気通貫で処理する体制を整えるため。取引先が,出荷状況をWebで確認できるように,物流システムと連携させる構想だった。システム管理コストを削減することも,今回の刷新の狙いである。

 開発を受託したF社は,K社向けに「受注」,「物流」,「売掛管理」という3つのサブ・チームを編成した。その中でS子さんが率いるのは,受注システム開発チームである。5人のチーム・メンバーとともに乗り込んだS子さんは,K社から提示されたシステム要件の確認作業から着手し,設計,開発と続く作業を着々とこなしてきた。ほぼスケジュール通りの進ちょくに,S子さんは満足していた。

勝手な変更にユーザーが激怒

 事件は,2003年8月の月例進ちょく会議で起きた。プロジェクトが,システム・テストに差し掛かったころである。K社のシステム部長であるY氏は,会議の始めに立ち上がるとこう切り出した。「受注システムの機能が,基本設計と大きくかけ離れている」。ITベンダー出身のY部長は,システム開発プロジェクトの内情にも精通していた。それだけに,進ちょく会議での発言は厳しく,F社のメンバーを震え上がらせていた。「受注担当者の業務効率を上げるため,顧客情報画面から受注入力できるよう設計したはずなのに,今のプログラムでは商品別の受注が優先されている」。

 Y部長は,いらだった声で続けた。「もう1つ驚いたのは,受注の取り消し手順だ。受注取り消しは,受注センター長の承認があって初めて実行できるように決めていた。ところが,完成したプログラムをテストしてみたら,担当者がその場で受注をキャンセルできるようになっている。これでは受注確定があやふやになって,クレーム対応が混乱してしまう」。いつにも増して不機嫌なY部長は,「基本設計通りにやってくれなければ困るじゃないか。一体,誰が担当しているんだ!」と声を荒げた。

 S子さんはおずおずと手を挙げ,「その部分は,御社の担当者から依頼を受けて修正したのですが…」と発言した。それが,Y部長の逆鱗に触れた。「何を言っているんだ。そんな変更は聞いていないよ。正式な仕様変更でもないのに,勝手に手直しをされては困る。F社のプロジェクト管理は,随分いい加減だな」。まくし立てるY部長に,S子さんは「誠に申し訳ありません」と言うのが精一杯だった。

 さらに,「元の仕様に戻すのに,どれだけかかるんだ?」とたたみかけてくるY部長に,S子さんは蚊の鳴くような声で「2週間ほどだと思います」と答えた。Y部長はS子さんをにらみつけると,「手戻り作業にかかる工賃は,そちらに負担してもらうよ。もし予定通りカットオーバーできなかったら,損害賠償を請求するからね。契約書には,ちゃんとそう書かれているんだ」と言い放った。「損害賠償」と聞いて,S子さんの頭の中は真っ白になった。自分が裁判沙汰の当事者になるとは考えたこともない。どう対応してよいか分からず,ただうろたえるばかりだった。

 ここで,S子さんの上司で今回のプロジェクト・リーダーを務めるQ課長が助け舟を出した。「Y部長のおっしゃることは分かりました。すぐに原因を調査して,善後策を講じます」。会議終了後,Q氏はS子さんにプログラムを変更した経緯を詳しく調べるよう指示した。

詳しい報告を怠った

 改めて調べた結果,K社側の担当者の思い込みと,S子さんたちの誤解が重なったことが今回の事件を引き起こしたと分かった。プログラムは当初,設計段階で固めた処理手順通りにできあがっていた。ところが,K社の受注担当者が「これまでの手順と違う」と変更を要求してきた。要求を受け付けたメンバーは,「おかしいな」と感じて何度も確かめたが,K社の担当者は頑として譲らない。このため,「K社の方針が変わったのかな」とその申し入れを受け入れてしまった。その後,S子さんもメンバーの報告をそのまま理解し,“バグの修正”ということでプログラム変更を了承した。

 S子さんは,叱責を覚悟して調査結果をQ氏に伝えた。Q氏は,「なるほど。顧客からの要望に,できるだけ応えようとしたんだね。ただそこで,それが正式な変更依頼と誤解してしまったのはまずかった」とS子さんたちの不手際を指摘した。「はい。大きな変更なのに,正式な手続きを踏まず自分たちの判断で実施してしまいました。それに,“バグの修正”としか報告しなかったのは,私の落ち度です」と素直に認めるS子さんに,Q氏は「そうだね。『おかしい』と思った時に一言相談してくれれば,こんな大事には至らなかった」とうなずいた。

 すっかり肩を落としたS子さんに,Q氏はこう言った。「でも,いつまでもくよくよしないことだ。Y部長へは,僕から事情を説明するよ。彼は損害賠償と言っていたが,話し合う余地は十分にある。君たちは,リカバリー作業に専念してくれ。よろしく頼むよ」。プロジェクトを窮地に追い込んだ自分を,Q課長はまだ信頼してくれている。そう痛感したS子さんは,申し訳ない思いと感謝の念で深く頭を下げた。

今回の教訓
・システム開発で発生した問題は,その本質を把握してから解決策を考えよう
・トラブルの原因は,“思い込み”がほとんど。基本の手順を遵守しよう。“急がば回れ”だ
・契約書には,一度は目を通しておこう

岩井 孝夫 クレストコンサルティング
1964年,中央大学商学部卒。コンピュータ・メーカーを経て89年にクレストコンサルティングを設立。現在,代表取締役社長。経営や業務とかい離しない情報システムを構築するためのコンサルティングを担当。takao.iwai@crest-con.co.jp