エンタープライズ

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

システム開発の落とし穴

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

第7回
小規模開発の落とし穴（2/2）

事例2：仕様確認を怠ったケース

　もうひとつ紹介するのは、大手商社の子会社で、ビル管理・マンション管理業務を行うA社があるソフトウェアハウスに発注した件だ。A社には情報システム部門といった部署がなく、ビル管理事業部がその役目を担った。

　ソフトウェアに開発を依頼した内容は、区分所有者で作る管理組合が扱う出納関係と、それにともなう帳票の出力である。さらに管理組合と、売り主や地元自治会との取り決め事項を後から活用できる形で保存する仕組みを構築するといった内容である。

　開発内容は小規模で、また特に業務知識を必要とする開発内容でもない。依頼を受けることになったソフトウェアハウスの担当SEは、プログラマから数えて10年のキャリアがあり、幅広い業種を担当してきた人物である。SEとしてこれからの活躍に期待といったポジションであろうか。

打ち合わせから開発へ

　A社の担当者は、発注窓口という立場に据えられてしまったが、気負うこともなく、また知識がないことの裏返しで見栄を張ることもなく、ソフトウェアハウスのSEに接していった。「システムを発注した経験もありませんので、色々ご相談しながら進めて行きたいと思います」と言われれば、SEとしても精一杯協力して、できる限りのことはしようと思うはずである。

　両者の打ち合わせは、A社から必要なこと、やりたいことを述べ、ソフトウェアハウスのSEが技術的手法の解説や、機能同士の繋がりを説明しながら進めるという会話が中心となり進んでいった。また、ひととおりの要望を聞き出したところで、それらを実現させるために導入するデータベースについても説明した。ただA社の担当者はデータベースについて漠然とした知識しかなかったため、SEはデータベースの初歩から説明した。利点や有効利用の方法、さらにはデータの種別やリレーションというものにも触れて話を進めていった。

　機能がまとまったところで、ソフトウェアハウスが開発スケジュールを作成し、両者納得の上で開発が進められていった。A社の担当者がシステム発注に不慣れなことなどを考慮し、毎週進捗報告を兼ねてそのときまでにでき上がっているところまでを見てもらうという提案がSEから出された。

終わらない要求

　さて、問題は毎週1回開かれる進捗報告が何度か開催されたときに起きた。プロトタイプ版までは言えないが、ある程度画面の操作ができる頃になると、A社の担当者から活発に意見がでるようになった。

　「使用するのは管理組合の理事たちなので、PCの操作には不慣れということを考慮した操作性にして欲しい」「利用頻度の高い画面とそうでない画面をメニューで分類して欲しい」など、言われれば確かにと思える意見も出た。しかし「この帳票にはオプションでこっちのデータも表示できるようにして欲しい」「画面操作・帳票出力のいくつかには、セキュリティの意味を兼ねて、パスワードを設定したい」というような、実際の画面を操作して気づいた点などの要望も出てきた。

　進捗報告と現在の開発段階の確認の場が、いつの間にか要望を引き出すミーティングとなってしまっていたのである。SEとしては、相手は発注に不慣れでこちらを頼っているのが分かるので、要求を無下に突っぱねられない。しかし納期は迫っているし、いつまでもこのままの状態でいいわけがない。

仕様書未作成の落ち度

　この事例のようなことは、意外と多いのではないだろうか。事前のヒアリングでは十分な意見が聞き出せず、開発中に要求・要望が出てくる。発注側の担当者が不慣れであれば、開発側も仕方がないと思いつつ「何とかしてあげたい」と必死に頑張ってしまうもの。わざと後から要求を小出しにしているわけではないので、対処が難しい。

　このような事態を避けるためには、たとえ規模の小さい開発でも、ちゃんと仕様書や用件定義書といったドキュメントを作成するべきである。その前に仕様書の何たるかを発注側に説明し、仕様書に書かれた内容・範囲で開発が進み、それ以上の要求には別途見積もりが必要であることを納得してもらうべきであった。それなら発注担当者も、もっと事前に機能を拾い上げるなり、別の形で開発側に相談するなりの方法があったと思われる。発注者側が慣れていない＝開発側主導でプロジェクトが進む、とは限らないのである。