要件定義のやり直しで追加作業発生！　ベンダーと訴訟沙汰に？ | ECのトラブルお助け

今回の相談者

ケンジさん（男性・29歳）

大手雑貨販売会社EC担当サブリーダー。

自社サイト初のECサイト構築を外注したのですが、ベンダーと揉めて要件定義が終わらないうちにプロジェクトが頓挫してしまいました。ITの守り神様！　どうか助けてください。

IT守り神のアドバイス

要件定義とは、システムやソフトウェアの開発において、どのような機能が要求されいて、実装されるべきなのかを明確にしていく、Webサイトにも共通する作業だ。要件定義は、開発後のトラブルや開発途中での仕様変更などのリスクを低減させることができる非常に重要なプロセスの1つであり、システムを開発する前には、開発者側と依頼者側の双方で協力をして「どのような機能が要求されているのか」「どのような機能が実装されるべきなのか」といった要件をきちんと定義しておく必要がある。

今回のようなトラブルを回避するために重要なポイントは次の3つだ。

1. 信頼できる人を選ぶ
2. ベンダーとの仕事の進め方をひと工夫する
3. 会社としての「要件」を整理するプロセス／考え方を持つ

それぞれについて説明していこう。

POINT1　信頼できる人を選ぶ

まず言えることは、会社ではなく「人」を見てベンダーを選ぶこと。

優秀な技術者が揃っているので何でもできます

うちのECソフトは大手●●社でも採用していて実績もあります

何でもできますと言ったり、パッケージソフトの実績をアピールするだけの単なるシステム屋ではなく、あなたの会社の業務フローを作れるレベルの人を選定すべきだ。また、その人が実現できる要件定義の進め方を確認してから選ぶことも大事。具体的には、「他社でどのように進められていたのか参考にしたいので、作成された要件定義書の実例を見せてもらえないですか」と言ってお願いするのも手だ。自信のあるベンダーなら見本のドキュメントを見せてくれるだろう。

POINT2　ベンダーとの仕事の進め方をひと工夫する

プロジェクトをスタートさせる前に、再度要件定義のプロジェクト期間中の打ち合わせスケジュールや議題、必要参加者など、具体的な進め方を詳細までベンダーと詰めるようにする。

要件定義がまとまらない原因の1つとして、発注側に問題があるケースも実は多い。あれもこれもと思いつきで要望を伝えるのではなく、「ECサイトで実現したいこと（事業目的）」と「スケジュール」を明記した資料を作って、プロジェクト会議のたびにベンダーと共有し、要件を出す時や決める時に照らし合わせる場を作るようにする。

POINT3　会社としての「要件」を整理するプロセス／考え方を持つ

運用担当者の意見は「作業効率の観点」だけに陥りがちだ。それに対して経営層は経営課題である売上拡大や運用コスト削減に終始することが多いため、それぞれの立場の違いを理解して「要件」を整理しないといけない。場合によっては、複数の部署をまとめて、担当作業から整理しなおすといった「要件」もある。

実際のプロジェクトは、ECサイトの運用責任者が中心となって進めることも多いものだが、会社全体としての要件を整理しておくことは必須だ。そのため、担当者には社内整理を行い、ベンダーとのパイプ役になることも求められる。EC担当者が「要件」をきちんと整理しようという姿勢がベンダーに見えれば、悩んだ時でも、メリット・デメリットを一緒に考えてもらえるような関係性を築くことができるはずだ。

良いベンダーの担当者を見分けるためのチェックリスト

• ECサイト構築を担当する「人」の構築実績を聞く

  会社としての実績やパッケージをアピールされても、必ずしもその人の実績ではない。同じ会社でも、担当者によってプロジェクトの進行は変わってくると理解すべきだ。

• 過去の要件定義書を見せてもらう

  ECサイト構築を担当する人が過去に実施した要件定義書を見て、安心して進められるか確認しておくことで、始まった後に発生するリスクを予見できるだろう。ただし、同じ業界であっても会社によって仕事の進め方は異なるため、自社のビジネスプロセスをしっかりと伝えることが発注主に求められる。

• あなたの会社が提示した要件すべてが必要だ、と言っていないか

  「何でもできます」「安く作れます」というベンダーではなく、あなたの会社の業務を理解し、必要に応じて「不要だ」と言ってくれるベンダーと付き合うべきだ。経験豊富な担当者であれば、あなたの会社に最適な要件をアドバイスして提案してくれるはず、疑問があれば遠慮なく質問しよう。

まとめ：要件定義はプロジェクト全体に影響する最重要プロセス

「要件定義」は、ECサイト構築のスタートであり最大のキモだ。ECサイトの要件定義では、たとえば、受注業務として顧客の利便性を高めるために、どんな情報を入力してもらうことにするか（会員登録していたらお届け先住所は入力不要にするなど）が含まれる。

また、運用担当者が効率的に業務運用するために、注文処理業務のどの部分を自動化するか（いたずらで異常な注文数を頼まれている注文を防ぐために、ある一定数を設定して超過した注文データは注文保留にしておき、検索できるようにするなど）を検討する。そういった細かい部分までうまく要件を聞き出してくれ、整理してまとめてくれるようなベンダーを選ぼう。

一方で、どんなにベンダーの担当者が優秀であっても、発注側の協力がなければうまくいかないものだ。発注側のEC担当者は、責任をもって、要件定義の重要性について、上司やシステム部門・運用担当者など各方面に理解を求めよう。業務に関わるすべての部署をまとめるのも、EC担当者の重要な役割である。その際には、次の図を参考にしてほしい。

ウォーターフォール型（V字型モデル）での品質保証体系

この図は、ECサイトに限らず、ソフトウェア開発の最も基本的な開発モデルである「ウォーターフォール型」を表したものだ。最初の「要件定義」が、最後の「総合テスト」にそのまま反映される。つまり、運用担当者が要件定義の重要性を把握しないままプロジェクトがスタートし、最終テスト時になってようやく「これは使えない」「もっとあんな機能がほしい」などの声があがっても遅いのである。ベンダーの選定も大切だが、社内で要件定義の重要さを啓蒙することも大切だ。