会社のシステム導入（顧客管理システム・販売管理システム等）は、株式会社ネーブルスへご相談ください

• サイトマップ
• お問合せ

• 
• 
• 
• 
• 
• 

要件定義について前の記事でご理解いただけたかと思います。
私も、この会社を始める前は、別の会社に勤めており様々なプロジェクトへ出向していた経験があります。
そんな長い経験の中で、実際に私が見た失敗事例をご紹介します。

要件定義が業務会議

システム制作会社が、時々、遭遇するよくある例なのですが、
要望を聴取する目的で打ち合わせにお伺いすると広い部屋に通されて、お客様側からは、十数人の方が参加されます。
参加人数が多いと必ずそうなる訳でもないのですが、その時点で若干嫌な予感がしてきます。
要望の聴取を始め、お客様側の担当の方が、要望を伝えていると他の方から意見が出てきます。

「そこの業務をシステム化するなら、あちらの業務もシステム化しないとデータが集まらない。」

など、当初、とても建設的な意見が出て良好な打ち合わせなのですが、白熱してくると。

「あの業務自体が無駄な事で、担当は１人で十分でしょう。」
「完了確認報告書の提出自体が必要あるのでしょうか？」
等、

業務自体の打ち合わせになってしまうお客様もいます。要件定義の打ち合わせ回数もシステム会社は、ある程度予測して納期や見積もりを提出しています。
本来の目的以外の内容をシステム会社との打ち合わせ時に行ってしまっては、納期を遅らせてしまう原因となります。
自社内の業務の精査をするのであれば、システム会社との打ち合わせの前に行っておく方がよろしいかと思います。

お任せ

以前、お伺いした会社様の担当者から要件をヒアリングしていた時の事です。
要件としての概要は理解したので、細かいところを決めようと画面や印刷物の表示に必要な項目を決めて頂こうとした時、

「お任せします。」

を言われて、その先、全く項目について要件を頂けませんでした。
何とか必須項目の数個の項目を聞きだしてシステムを制作し納品すると。

「あれ？あの項目がないね。あの項目必要だから入れてよ。」

結果的に有料で修正させて頂きましたが、お客様にとっては、追加の出費となってしまいました。
要件定義時に言って頂いていれば有料にはならなかったのにと後悔した事があります。

要件が変わる

要件のヒアリングのためにお打ち合わせを行い、要件定義書のレビューにお伺いすると、

「ここは違う、あそこは違う」

と指摘され、前回、この様におっしゃっておられたので、その様にしてありますと説明すると納得されるのですが、

「やっぱりこうしてほしい。」

となり、修正した後に、再度、レビューにお伺いすると、また別のところを変えてほしいと依頼が来ます。
実は、要件定義とは、本来、こうあるべきで、要件を確認し、要件定義書で正しくシステム制作会社に要望が伝わっているかを確認します。
本来要望する内容の通りではない場合には、内容を修正し、再度要件定義書の確認を行って頂きます。繰り返して要件をしっかり詰めていくための工程が要件定義なのです。
熟慮された要件定義書は業務においても、次の設計工程においても有意義なものになります。

しかし、前回、こう修正して欲しいと言った事を、次回に撤回し、また、その次に戻しと言う事をされるお客様がおられます。
良く吟味されるのは良いのですが、納期もありますのでレビューの度に変わってしまうのは若干問題と思います。

製造途中の要件変更

要件定義も終了し、設計も終了した後に、お客様から了解を頂いて製造をスタートし完成間近で、要件の変更の依頼が来る事があります。
これは、お客様側の要件定義時の熟慮不足となってしまいます。
この場合、一度完成した後の修正となり追加の料金が発生する事は必至です。
同じ金額で一度に制作できるところを、追加の料金で後に修正する事は、非常に無駄な出費となってしまいます。それであれば、要件定義時にしっかりと検討、考察されていた方が賢明と考えます。

使わない項目

この事案は、必ずしもお客さんだけがいけない訳ではありません。要望を聴取しているシステム制作の担当者にも責任があると思われます。
お客様から要件定義時に沢山の項目を管理したいとの依頼を頂いたので、そのまま鵜呑みにして要件定義を行い、納品の後、保守がスタートしました。しかし、数ヵ月後にお客様から、

「この項目表示させない様に出来ますか」

との依頼を頂き、結果的にいくつかの項目を表示させない様に対応しますが、表示のバランスも悪くなり、使いづらい画面になってしまいました。

当初、要件定義時に、そのお客様のクライアントのお悩み相談応対用の項目がたくさんあり、クライアントのお悩み事の検索や趣味嗜好等の分析用に使いたかったのですが、実際には使う機会がそれほどなく、データもほとんど集まらなかった様で、結果的に使用しなくなってしまいました。

お客様の「あれもしたい。これもしたい。」の要望から出てきた項目だったのですが、予定をシステム化してしまったため使用しない機能分が金額に上乗せされてしまった例です。
この場合、システム制作担当者としては、データが集まってから機能追加を勧めるか、現段階では、それらの項目を、ひとまとめにテキストとして備考にしておくかをお勧めした方が良かったかもしれません。

HOME> Webシステム開発導入読本>システムの使いやすさ（速度） ↑Webシステム開発費用の概算をオンラインでご提示致します。（無料）

注意したい要件定義

• 要件定義が業務会議
• お任せ
• 要件が変わる
• 製造途中の要件変更
• 使わない項目