元外資系コンサルのガラクタ箱

要件定義ヒアリング成功の鍵はできあがりイメージを合意すること

要件定義時にヒアリングしておくべきことリストを紹介して下さい、とお問合せを受けました。

ありがとうございます(こういうお問合せは歓迎ですのでお気軽にお寄せ下さい)。

たしかにヒアリング時に聞き漏らしてしまうと、後での揉め事の原因になってしまうので注意が必要です。

しかし、リストを見たい気持ちをぐっとこらえてお付き合いください。いきなり一覧に行く前に少しずつ考えを進めさせて下さい。

先にリストを見たい方はこちらをどうぞ。

ヒアリングは要件定義アウトプットを作成するために行う

ヒアリングは何のためにするのでしょうか。それは要件定義アウトプットを作成するためでしょう。

では要件定義アウトプットとは何でしょうか。新システムで実現したい内容を定義したものです。

新システムで実現したい内容はどれだけ具体化しているでしょうか。要件はユーザ企業が決めるものです。

要件は決まったものがあるわけではなくベンダが支援しながらユーザと定義していく

しかし既に決めた要件が存在するわけではないのです。ユーザ企業の担当者は要件定義の前に出来上がっている要件をベンダに伝えるわけではなく、要件定義を通じて要件を考え確定させるのです。

要件定義を受託するシステムベンダならば、早く答えである要件を欲しくて当然です。そして一度もらった要件は変更しないでほしいものです。「客が要件決められない」とか「ポリシーないから言うこと変わる」という声も、限られた予算と期間でシステムを構築する以上、ぼやきたくなるのは理解します。しかし、現状で存在しない「要件」を社内の利害関係者と合意形成する大変さは想像に難くないと思います。

だからこそ、ヒアリングする際には、そのヒアリングに回答することでどういうアウトプットにつながるのかを説明し、できあがりイメージをお客様としっかり合意することが重要です。

それでは、要件定義でヒアリングしておくべき項目に進みます。

ところで定義すべき要件とは何でしょうか?

・業務要件 or システム要件

・アプリ要件 / 帳票 / IF / 移行 / インフラ

次記事では定義すべき要件の分類について触れていきます。

mhisaeda

電子書籍「システム導入のためのデータ移行ガイドブック」著者。

新卒から外資系コンサルティングファームに所属。15年に渡り販売物流、特にCRM領域のコンサルティングに従事。 100名を超えるプロジェクトのPMOなど全体を推進していく役回りや、ユーザ企業への出向を通じた実務経験を持つ。

このブログでは、自身がかき集めた知識や経験を共有する。クライアントへの提案やソリューション開発に直結しないガラクタのようなもの。将来再利用する自分のために。同じような悩みを抱える誰かのためにブログ「元外資系コンサルのガラクタ箱」を運営。

カテゴリー

モバイルバージョンを終了