エンタープライズ

現役コンサルタントが語る

システム開発の落とし穴

2005年12月19日　　文●システムクリエイト代表取締役
田中徹

第1回
ドキュメント不足が招く怖いトラブル（1/2）

はじめての大規模発注の落とし穴

　全国の営業拠点に導入する流通管理システムを発注した流通業の中堅A社は、小さなシステムこそ発注経験はあるものの、今回のような大規模システムの発注は未経験だった。そこで今まで何度か開発依頼をしたソフトウェアハウスではなく、大規模システムの開発経験が豊富にあるシステムインテグレータ（以降、SI）に依頼することとなった。ここでは仮にB社としておく。

　情報システム部門に所属するA社の担当者は、社内で何度もシステムについての意見交換を各部署と行ない、ある程度まとまったところでB社の担当者に構築するシステムについて説明した。その後、B社のSEと発注担当者で数回打ち合わせしてシステムの機能をまとめ上げ、いざ開発という段取りになった。設計からプログラミング、そしてテストと、いずれの工程においても大きなトラブルは発生せず、順調にシステム開発を終えて運用も開始された。

　あとでA社の担当者に話を聞いたところ、この段階でのB社に対する感想は、「さすがに経験豊富なSIであり、すべてを任せることができた」ということであった。全幅の信頼をおき、B社のSEの言うことなら、間違いはないのであろうと感じたとも言っていた。

　開発会社を信頼するのは決して間違いではない。ただ、依存しすぎてしまうと、何か要求があったときに言い出せなくなってしまう恐れがあるし、要求することすら考えつかないという危険性がある。言われるがままの状態ということだ。事実このA社も、運用を開始して半年後に、思わぬトラブルに遭遇することになった。

ドキュメント不足が発覚

　流通管理システムの稼働から半年が経ったとき、A社はシステムの機能強化を図るためにサブシステムの追加を決める。ただ小規模な開発であったため、システムを開発したB社ではなく、以前から付き合いのあるソフトウェアハウスのC社に依頼することにした。

　A社はサブシステムを開発するために、C社からのヒアリングを受けていたが、その中で必要なドキュメント類が不足していることが明らかになった。サブシステムを設計するにあたり、既存システム調査用にもう少し詳しい設計書が必要であると、C社から指摘されたのだ。

　プログラム単位での設計書は揃っていたが、各処理で行なう更新タイミングや、計算用テンポラリ項目の書換えなどといった、特にデータベース周りに関する詳細な説明書が不足していた。今回のような稼動しているシステムに機能を追加する2次的開発の場合、新規機能の設計や開発と同じくらい、既存のシステムに影響を与えないかということに時間を割くことになる。それに必要な資料が不足していたというわけだ。

受け入れられぬA社からの要望

　A社の担当者は早速B社に連絡を入れ、以前作成してもらったシステムのドキュメントが十分とは思えない旨を伝え、作成してもらうように依頼する。しかしB社の答えは、「事前の打ち合わせで取り決めたとおり、ひととおりのものは作成した。新たにドキュメントは作成できない」とのことだった。設計終了時、開発終了時、テスト終了時と、そのつど仕様書なり設計書なりを納品し、検収書まで受け取っていた。さらに詳しいドキュメントを作成するのであれば有償になるという反応だった。

　ドキュメントがなければサブシステムを開発できないため、有償もやむを得ないところであった。ただA社は外部の人の意見を聞いてからA社としての意思を決定することになった。そこで私がコンサルタントとして呼ばれたのである。

　1週間程度をかけ、A社内を自由に歩き回らせていただき、必要に応じて各部署から話を聞いていきさつを確認する一方で、すべてのドキュメントにも目を通し、契約書や検収修了書といった書類も内容を確認した。

　結論から言うと、A社、B社のどちらか一方に非があるというわけではなく、双方少しずつ落ち度があった。どちらかだけの主張を相手側に認めさせるには無理があるし、公平な目で判断しても、それぞれに引いてもらう点があった。次ページから、それぞれどういった落ち度があったのか、解説しよう。