【危険】甘く見るとシステム開発で失敗します！要件定義にまつわる本当にあった怖い話3選

「要件定義がシステム開発の成功を左右する」と言っても過言ではないほど、システム開発において、要件定義は重要です。しかし、システム開発の経験が少ないと、なぜ要件定義が重要なのか、要件定義を怠ると何が起こるのかわからない方も多いと思います。

そこで今回は、システム開発で実際にあった、要件定義にまつわる怖い話を紹介します。これらは本当にあったお話ですので、皆さんにも同じことが起こるかもしれません。

要件定義の重要性が分からない
システム開発で失敗したくない

そんな方がこの投稿をご覧いただきますと、システム開発における要件定義の重要性がご理解頂けますので、ぜひ発注者である主人公になったつもりで最後までご覧ください。

怖い話その1　エンジニアに常識が通じない

怖い話その2　各社の見積金額に10倍の開きがあった

怖い話その3　要件定義の後、見積金額は当初の3倍になった

まとめ

※このコラムの内容は動画で公開しています。Youtube版はこちらをご覧ください。

いつぞや、同じIT業界の人と話した時「要件定義は細かいことは話さない、基本設計で詳細を詰めます。」と仰っていました。その前提が、アジャイル開発であるならばまだしも、ウォーターフォール開発だと言うのです。その時は、特に議論するような状況でもなかったので、そのままスルーしました。

しかし、私が考えるに要件定義が大雑把であれば、その後の設計、開発に大きなリスクをはらんでいると断言します。それは何故か、ということをこれから実際にあった3つの怖い話でお伝えします。

怖い話その1　エンジニアに常識が通じない

みなさんは、もしかするとSEやプログラマは、誰もが例外なくWEBサイトのこと、アプリのこと、そしてパソコンやスマホのことをよく知っていると思っていませんか？それは大きな間違いです。家電量販店に勤めているからと言って、冷蔵庫、洗濯機、TV、掃除機、電子レンジなどなど、そのお店に置いてあるもの全てに詳しいでしょうか？違いますよね？

それと同じで、システム開発に関わっているからと言って、「全てのエンジニアがWEBサイトやアプリについて詳しいはず」「少なくとも素人の自分よりは詳しいに違いない」と考えるのは幻想にすぎません。しかし残念ながら多くの方は、その業界にいる人間は、その業界に関することを何でも知っているのが当然という意識が頭の中にあるのではないでしょうか？

だからこそ、こんな怖い話が起こるのです。発注者とSEが行った要件定義についてのお話です。それは、会員登録の機能についてのことでした。

発注者はメルカリをよく使っており、いらないものを出品し、ちょっとしたお小遣いにしていました。そんな話しをよくしているので、他の人にも使い方を聞かれ、親切にアドバイスするほど詳しい人でした。一方、開発者はメルカリどころか、あまりアプリにも詳しくなく、会員登録と言えば随分昔にYahoo!でアカウントを作ったくらいでした。

開発者がこんな流行りのアプリのことを知らないわけがない、そう思いますか？そんなことはありません。プログラム開発をしていても、ガラケー派だったり、LINEを使ってない人はいますし、細かいことに興味を持たないエンジニアは、登録した時の流れを覚えていないというのは全く珍しいことではありません。

さて、メルカリ大好きな発注者と、興味がない開発者。この二人が要件定義を行った際、まさに細かいことを話さず「よくある会員登録機能」という程度の表現で要件定義を終えていたのです。そこで、何が起こったのでしょう？発注者が考えていたよくある会員登録機能とは、

AppleIDでサインアップ可
Facebook、Google、dアカウントなど他のアプリのIDを使って登録でき、メールアドレスでの登録は当たり前
さらに、携帯電話番号へSMSのショートメッセージを送り、本人認証を行う

というものです。このようなSNSアカウントで登録・ログインができる方法はメルカリに関わらず他のアプリでも多いですから、発注者が疑問を挟む余地はありませんでした。

一方、開発者はメルカリどころか、最近会員登録すらしていないので、メールアドレスと名前・住所くらいが登録されればいいと考えていました。

その後、開発が始まり画面のデザインを進める時に、この隔たりが大きいことに初めて気が付きました。エンジニアは自分が考えた会員登録のレベルでの工数を見積もっていましたが、発注者が求めるものは、そんな工数では済まない内容だったのです。「そんな話しは聞いていない」と多少抵抗はしたものの、「エンジニアなんだから、これだけ流行っているアプリの会員登録は知っているのが当然だよね。常識だよね。」と強く迫られ、泣く泣く開発したとのこと。（ちなみにこれは私の知人の話しです。）

このケースは開発規模が大きくなく、その先の開発にはさほど影響がなくて、開発側が膨らんだ工数分を飲んでくれたからいいものの、頑なに「追加費用を出してくれないなら開発しない」とされたらどうでしょう？

発注者は追加の予算が必要になるわけです。それもこのくらいで済んだからいいかも知れませんが、他にも自身が考えるシステムの機能の常識がエンジニアと一致していなければ、その先に待ち受けるのは、両者の「これは常識だろう」「いや常識ではありません」という不毛な議論、そしてその後システムができあがったとしても後味の悪い結果が待っています。怖い話ですね…。

怖い話その2　各社の見積金額に10倍の開きがあった

あるお客様から、WEBサイトの新規構築案件の提案の機会を頂きました。知人からの紹介でした。勉強熱心なビジネスパーソンであれば間違いなくご存知なサイトです。WEBサイトと言っても単なるホームページとは違い、コンテンツ単位で課金する仕組みのシステムであり、このビジネスモデルは当時画期的でした。

こんなサイトを作りたいと頂いた企画書は25ページ程度のボリュームがある内容。丁寧な説明をして頂きました。著名なお客様でもありましたし、当社としても絶対にこの案件を獲得したいと、相当に力を入れて提案書を作成したことは記憶に残ってます。

苦労して提案書を作り上げ、提案をしました。10社程度が参加したコンペでした。当社は、名もないベンチャー企業でしたが、コンペの参加社には東証一部上場のSIerやそのグループ企業も数社参加しており、勝ち目がなさそうなものでした。

その後、そのお客様から連絡があり、お呼びがあったのです。決して明るい雰囲気でもなかったので、これはダメだったかと思いながらお話を伺いに出向きました。そこで出たのは、「相談がある」とのこと。尋ねてみると、各社提案が揃ったのはいいけれど、何と見積もり金額に10倍の開きがあると言うのです。これだけの開きがあると、どの金額が妥当なのか判断できないので稟議を上げることもできない。そのため、この案件をどう進めていいかわからない、ということでした。

下は1000万から、上は1億とのこと。確かにその通り。仮に中間の見積額　5,000万で稟議し、結果的に1億になってしまった、というと倍の違い。それも5000万の倍です。逆に一番安いという理由で、1000万で稟議し、倍になっても追加1000万で済むから安全か？と思ったところで、もし一番上の1億が妥当だった場合、10倍になる。そうなったら、開発も中断されることもあるでしょう。

この状況だと、どのような選択をしたとしても稟議で説明できる状況にないのです。お客様は困り顔で「なぜ、これほど開きがでるのでしょうか？」と尋ねられました。その質問に、私はこう答えました。

「1番の理由は要件定義がされていないこと、そしてコンぺ参加社の企業規模です。」
要件定義がされていないとの指摘にお客様は、「こんなに資料を用意しているのにダメですか？」と仰いました。対象となる規模感で言うなら一つ一つが独立したサイトとして運営できるだけのコンテンツがあるサイトが10数サイトを統合したほど。提案時ご用意いただいた資料は、それらのコンテンツの説明と、会員、非会員のコンテンツアクセスについての説明など、サイトのユーザーが見たら、そのサイトの魅力が伝わるには充分なものでした。

しかし、これではシステムの見積もりをするには十分ではありませんでした。このように、提案する側がシステム開発の見積もりのための情報が十分ではないと考えた場合どうするかと言うと、

このサイトを運営するための業務は何が考えられるのか
そこにはどんな機能が必要なのか
どれくらいのアクセスがあるのか

つまり、業務要件、機能要件、非機能要件がない状態で、提案する側はそこを想像しなければならない。ましてや、このようなサイトは世の中にはまだ少なかったため、提案する各社は確たる見積根拠を想定できず、各社が考えるイメージがバラバラだったのは間違いないと思います。

また、想像から出来上がった要件に対する見積もりは、想像でしかないのですから、いざ開発が始まったら、追加の機能やら何やら出てくるのは間違いありません。それに対して各社は経験値に基づいて、リスク分を上乗せをします。経験値と言うのがポイントで、ご想像どおり経験値はバラバラですから、一概に各社何割り増しのように言えません。

こうして出来上がった各社の提案、見積もり金額は開きがあって当然のことと言えます。さらに、見積もり金額を拡大させたもう一つの要因。それは、提案各社はベンチャーから一部上場企業まで、コスト体系が異なる企業が混在していたと言うことです。

ベンチャーは、間接部門がいない、家賃などの固定費が安いなどから、単価を安く抑えることができる。一方で、上場企業はベンチャーよりは、間違いなく高コスト。

一人のエンジニアで十分な内容の案件であっても、上場企業は毎回の打ち合わせに、4名が参加していました。リーダー、担当者、新人担当者、営業という面子です。これは、高コストになるのも当然です。

上場企業側、ベンチャー企業側、両方のコスト体系を知っていた自分としては、ベンチャーと上場企業が混在して提案する見積なら3倍以内に収まれば妥当だと考えていました。

「やはり10倍は不適当であり、その理由はこうです。」と、先述の内容を説明しました。これにお客様はご納得いただき、「ではどうすればいいか？」と質問され、迷うことなく、開発と切り離して要件定義を行うべきだと答えました。

要件定義を詳細に行わないことで、1つ2つの機能の認識相違どころか、見積もりに10倍の開きが発生し、稟議すらあげることができなくなる。怖い話ですね…。

怖い話その3　要件定義の後、見積金額は当初の3倍になった

怖い話その2の続きです。見積もりに10倍の開きがあったため、「開発と切り離して要件定義をすべきである」という提案をしてから間も無くして、それを御社にお願いするといくらかかるのかと聞かれました。そして、当社が要件定義フェーズを受注したのです。

1、2ヶ月だったか明確には記憶していませんが、この案件のみに2名が集中し、毎日のように膝詰めで、打ち合わせを重ねました。出来上がった要件定義書は450ページにわたるボリューム。かなり詳細に定義しました。

納品後、この要件定義書は最初に提案した会社から半分に絞られた各社に配布され、当社も含め改めて開発フェーズのコンペとなったのです。2回のコンペでは出てきた見積もりは、最大、最初の見積もりの3倍になった所もあったとのこと。要件定義前から、要件定義後に3倍に膨れ上がる見積もり、怖い話ですね…。

しかし、3倍になったと言うのは、単にこの数字だけで見ると怖い話なのですが、考えてみてください。今回のケースでもし、要件定義を行わず値段だけで最も安い所に発注していたとしたら、ほぼ間違いなくこの開発は頓挫していたでしょう。

要件定義フェーズを開発に切り離して実施したことで、結果的にバラツキは残ったものの、お客様に説明した通り、上から下までの見積もりの開きは3倍以内に収まり、ベンチャー企業と上場企業が混在する中でも見積もりは妥当な範囲にキッチリ収まったわけです。

もし、要件定義で細かいことを話さず、基本設計で詳細を詰めていくようなことをしていたら、設計以降どんどん開発規模が膨らみ予算の追加、追加となり、場合によっては、この開発は中断ということにもなりかねなかったでしょう。