top of page

業界的に当然という常識から要件定義で機能の洗い出しを見落とし訴訟スレスレまでこじれた失敗例


【失敗例】常識のすれ違いで要件定義から必須機能が漏れていた


ホテルの予約管理システムについて開発依頼が入りました。ホテル業種の開発は前例がありませんでしたが予約システムについては飲食店舗にて構築前例があったので社内で、開発可能として案件の参画を決めました。


先方は業務システム部がなく、系列のホテル内から経験値の多い支配人とIT知識がある現場担当者がプロジェクトの管理者としてアサインされてました。


企画から実装されるべき機能は先方の要件定義においてまとまっておりましたが、いくつか機能実現に対して確認しなければならない点があったため要件定義の取りまとめに1か月ほど要しました。


要件定義がまとまり基本設計が滞りなく進み、成果物に対してクライアント合意を得ながら詳細設計に取り掛かりました。


成果物として納品した詳細設計において問題なく合意が得られたため、構築(開発フェイズ)に取り掛かりました。


構築では多少の遅れはありましたが、なんとか納期内で結合テストまでこぎつけました。


しかしそこで突然、先方からある指摘がはいりました。


曰く、キャンセルに関する処理プログラムが実現できていない、というものでした。


ホテル業界ではキャンセルに対して10日前、1週間前、3日前、前日など日数によりキャンセル料金が変更になるとのことでした。


日数に対するキャンセルテーブルが実装されていないことが指摘内容でした。


しかし成果物として納品している要件定義書、基本設計書、内部設計書などにおいてその事は指定されていなかったため機能実現は、通常のキャンセルフラグのみの実装でした。


先方からは早急に修正してほしいとの依頼がありましたが、そもそも要件定義でその事が記載されていないことや開発日数の増加から、追加開発としての見積もりを提案したところ却下されてしまいました。


理由としてはホテルの予約システムを開発するのであれば当然知っていて然るべきことであり、要件定義にキャンセル処理とあるだけでキャンセルプログラムの仕様を理解すべき、とのことでした。


先方の主張も一定の理解はできるのですが、工数的にかなりの修正が必要であること、既存の仕様における成果物が先方から了承を得ていることから100%過失ではないという判断から追加見積でなければ対応できないと連絡をしたところ、訴訟問題になるかもしれないと言われました。


訴訟問題に発展すると言われてしまったため、弁護士に相談を行い過去の判例の洗い出しをしてもらうことになってしまいました。


最終的に業界内においての通例は必ずしも他業種において通例ではないという判決がでたケースがあることから、訴訟対策に入りました。


この問題が解決するまでストップしていた開発ですが幸いにも訴訟に発展せず、先方から折り合い提案が入り訴訟問題に発展することはありませんでしたが、結果として納品後の保守はいただけず関係値も悪くなってしまい、以降の取引はなくなってしまいました。


【失敗の理由】同業種の開発事例はトラブル回避の最良薬となり得る


今回はホテルの予約システム開発を例としましたが、業種の通例は必ずしも通例ではないということを知っていただければと思い書きました。


ただ、この問題はあるあるで、金融業種や医療業種といった特殊な業界での開発経験が無いとトラブルリストの上位になることがあります。


開発会社の目線からすれば、要件に記載されている機能と基本設計で了承を得ているわけですからその範囲内で構築を進めるしかありません。


自己過失はないと考えるのは当たり前のことです。


今回のケースで言えば、キャンセル機能、とだけ記載があったということですから開発会社からすればキャンセルボタンの操作によるキャンセルフラグのon/offで処理することは何ら問題がありません。


しかし、ホテル側からすればキャンセルが予約日に近づくにつれ料金が異なることなどからキャンセル処理は1つではなく複数であることは常識だったのです。


常識とはあえて言わなくても広く一般知識として知られている情報という意味です。


果たしてこれは常識の範疇だったのでしょうか。


そして、このズレは単にコミュニケーション不足により発生したと言えるのでしょうか?


私は決してコミュニケーション不足が原因ではないと思っています。

コミュニケーションをいくら綿密にしていてもおそらく今回の問題を洗い出すことはできなかったと思っています。


では、どうすればよかったのか?


これについては企画、要件定義の段階で理想としているシステムが既存にあるのか、目に見えてわかるようなモデルシステムがあるのかを先にヒアリングすることで情報差異を小さくすることが出来ると考えます。


システムの開発ではよく、


参考にしてるシステムはありますか?


と、質問します。これは弊社だけではないと思います。


世の中にこれだけたくさんのシステムが稼働しているのであれば、どこかに必ずモデルとなるシステムがあるものです。


特に今回のケースではホテル側担当者はシステム構築経験者ではありません。


ということはほぼ確実にモデルとなるシステムが存在しているものです。これは私がこれまでに携わってきた経験からなので何らかの形で立証しろと言われても難しいのですが。。。


エンジニア経験を持たれていない担当者さんとお仕事をする場合、作りたいものというのは、●●社のシステムみたいなものを作ってほしい、となることのほうが多いです。



失敗しないためにはまず、先方がモデルとしているシステムを聞き出すことが大切です。



そこで得た情報からどのような機能があるかを洗い出したり、各機能の詳細を把握することが大切です。


時にはそのシステムの登録をするなどして機能確認をすることも調査の1つだと思っています。

※そのための調査費用は自社持ちなのか先方了承なのかについてはまた別問題です。



単に、キャンセル機能とだけ記載するのではなく、他社のシステムの稼働をよく分析してどのように稼働しているかを把握することで以下のような落とし込みが出来るはずです。


・複数のキャンセルテーブルの作成

・テーブルごとの処理プログラム

・フロントの構成


本来、洗い出しにはこれ以上にもっとたくさんあるのですが紙面上、詳しく書くと文字数ばかりかさんでしまうので割愛します。


大事なことは、ホテル側の「いわなくても常識でしょ」と思っている部分に対して開発会社が見落としをしないようにしっかりと光を当てるとです。


特殊性が高い業種ほどこの傾向は強くなりますので案件に参画する際には、常識のズレを意識してヒアリングするようにするだけでも失敗確率は下がります。


余談になりますが今回のケースではあわや訴訟問題となるところまで問題が深刻になってしまいました。


失敗ケースではあまり触れてはいませんが、過去にこのような問題から実際にトラブルになったケースが存在します。



そのケースでの争点が「常識の範疇」でした。


分かりやすく言えば、


ウチの家の常識がお隣さんの家の常識とは限らない


ということです。


つまり、裁判所はその業界での常識を他業種に押し付ける行為は認められない、と判断したのです。


ちなみに弊社では


ブログで何度も書きましたが、ヒアリングはとても大事なことです。


そしてヒアリング方法もまた大事なことです。



基本的に初めての業種でのシステム開発というのは苦労が多いことのほうが多いです。



苦労が多いということは工数が上がることを意味します。

つまり開発資金の高騰化を招く要因になります。


弊社ではだれも得をしないような仕事を好みません。



そこで、案件の依頼をいただいた段階で弊社があまり得意ではないと判断すると、協業会社(パートナー企業)に案件相談を行います。


協業会社さんの中で過去に同業種の開発を行っていたり、似たようなシステム開発実績を持っている会社さんに対して積極的に案件参加をお願いしています。


過去に開発経験を持っているわけですから、見えないところが見えるわけです。


これが一番、大切なことです。


日本では5割が結果として失敗開発、炎上開発などと言われるほど、システム開発はトラブルと表裏一体です。


弊社のスタンスでは、トラブルを回避するためにしなければならないことは何か?を常に考え、回避するためにはどうすればよいか?を突き詰めることに時間を惜しみません。


最終的にそれが失敗しないシステム開発につながっていることを知っているからです。



bottom of page