エンタープライズ

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

システム開発の落とし穴

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

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

発注側（A社）の落ち度

　発注主であるA社には、担当者がすべてをB社に任せっきりで、内容の検討をそのつど十分な時間を割いて行なってこなかった点を認識させた。B社に話を聞いたところ、A社は特にフォーマットの決まった仕様書、設計書を持っておらず、B社の提案する形式で了承したこと、用件定義書や設計書を納品した直後にも、あまり質問等がなく、受け取るだけだったことを知った。B社によれば、内容に納得してもらえたものと判断し、製造・テストと次の工程に進んでいったということであった。

　A社としては、「これほどの規模のシステム開発は初めてであり、大量の設計書を見ても我々素人では分からないだろうし、B社を信頼して任せていた」ということになる。ただ、だからといって「いままで比較的規模の小さい開発しか依頼した経験がないので、設計書を見慣れていない」というのは、言い訳にならない。

　設計書はプログラムを作成する土台だが、その中身はプログラマやSEでなくても十分理解できるように作成されている。確かに、一気に全部を理解するのは難しいかもしれない。しかし、業務工程ごとにプログラムを分けて考え、設計書を見てプログラムの内容を把握できるかどうかという視点で見ていけば、仕様書なり設計書なりが不足していることに気づくはずだ。

　また、初めての大規模開発なのでいい機会と捉え、B社に対してそれぞれのドキュメントがどういう役割をするのか、何が書かれているのか、内容を見るときはどうすればいいのかという初歩的なことから質問すればよかったのである。決して恥ずかしいことではない。

開発側（B社）の落ち度

　打合わせを重ねていけば、ある程度A社や情報システム部の担当者のITスキルは判断できるものである。作業工程や開発手法だけでなく、ドキュメント類に関してもある程度の示唆はしてもよかったのではないかと伝えた。そして私から見ても一般的な開発で作成されるべきドキュメントの一部が不足している旨を伝えた。ただ、A社自身も自分たちの体制にも不備があったことは納得済みだったので、妥協点を見出してこの問題を解決しようと持ちかけた。

　B社としても、開発が終了しすでに稼動後のことなので、完全に放っておく姿勢はとらないが、あまり人員も時間も割く余裕がないということであった。ある程度の了解を得られたので、私の判断において有償で作成するものと、不足していたということで無償で作成するドキュメントに分け、A・B社双方に納得してもらうように話をまとめて解決を図った。

SIに依存しすぎず、発注側がリーダーシップを

　今回の事例は、「システム開発はプロ任せ」という依存しすぎた姿勢が後で困ったことになるという代表的な事例の1つだろう。当事者同士での話し合いだけでは「言った、言わない」の繰り返しになったり、お互いの主張だけを言い張るような先の見えない展開になってしまいがちである。そこでシステムコンサルタントなど、外部の人間が入ることで解決の糸口を探ることもできる。

　ドキュメント類に限らず、事前に確認しておくことはたくさんある。代表例とも言えることが、開発後のサポート体制だろう。運用の一部を開発会社に依頼する場合は別途契約を結ぶことになるが、開発終了とともに、開発会社との関係が一時的に切れる場合は、あとになってバグが発生したときに、どういう対応をしてくれるのかを確認しておくことが重要だ。トラブルが発生したときに、それがプログラムバグなのか、運用のミスによるものなのか、何か他の原因によるものなのかは、調査してみないと分からないことが多い。そしてこの調査はやはり開発会社の手を借りることになるのである。そう考えると開発期間中だけのことではなく、運用開始後どういう対応をしてもらえるのか、発注側からどう要求するのかを明確にしておく必要がある。

　開発中や開発後に発生するトラブルの多くは、発注側の意識で防げたものが少なくない。すべてをSIに任せてしまう姿勢や、発注担当者がただの窓口化してしまうと、こんなはずではなかった……ということになってしまう。「発注側がリーダーシップを発揮する」ということを常に意識しておきたいものである。