ページの先頭です。
サイト内の現在位置を表示しています。
  1. ホーム
  2. EC・通販統合ソリューション NeoSarf / DM
  3. コラム記事
  4. EC構築・運用コラム 第1話
ここから本文です。

EC構築・運用コラム 第1話

第1話 要件定義のやり直しで追加作業発生!ベンダーと訴訟沙汰に?

東京は田町の片隅に小さな神社がある。一見パッとしないが、EC担当者の間で「トラブルから救ってくれる」という言い伝えがある神社だ。
今日も「神頼み」へとやってきた、トラブルにあった歴代のEC担当者たちのために、IT守り神からのアドバイスをお届けする。

イメージ:ケンジ

<今回の相談者>
ケンジさん(男性・29歳)


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

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

イメージ:IT守り神

IT守り神(ビジネス街の片隅にあるIT神社の神様)
それは大変だね。

イメージ:ケンジ

うわ! 誰ですかあんた。

イメージ:IT守り神

ぼく? ぼくはIT守り神だけど、呼ばれたので出てきたんだよ。

イメージ:ケンジ

なんか軽い守り神だなあ……。まあ、とにかく聞いて下さいよ。
実はECサイト構築のプロジェクトを進めていたんですけど、ベンダーと要件をうまく整理できなくて、時間ばっかりかかってしまったんです。

イメージ:IT守り神

ふむふむ。

イメージ:ケンジ

そうしたら上司が、「これではサイトオープンのスケジュールに間に合わない!」って怒り出してしまって。でもこのままの要件定義だと、ぼくたちの求めてるものとはまったく違うシステムができ上がってしまう。
それでベンダーに「もう一回作り直しして下さい!」って告げたら、「それでは追加費用をいただきます」と返されてしまったんです。間に入ったぼくはもう大変で……。

イメージ:IT守り神

なるほど。で、要件定義のやり直しになったの?

イメージ:ケンジ

いえ、「そんな追加費用なんて飲めない!」って上司がさらに怒って、ベンダーと決裂状態になっちゃって……。いま、訴訟沙汰になりそうなんです。

イメージ:IT守り神

うわー。あなたも生きた心地しないでしょ(笑)。

イメージ:ケンジ

だからこうして拝みに来たんじゃないですか! 笑うところじゃないですよ! そもそもなんであんなベンダー選んじゃったのかなあ。

イメージ:IT守り神

最初は「何でもできる」みたいなことをアピールしてきたんじゃない?

イメージ:ケンジ

そうなんですよ。うちはこれだけ大きな会社と契約しているとか、最適なパッケージがあるとかすごい自信たっぷりでした。ついついそれを聞いて安心してしまって。でも、ぼくたちの進め方にも問題があったかも。

イメージ:IT守り神

あとになってから「あれも、これも」って感じで、パラパラと追加の要件が増えていったんでしょ?

イメージ:ケンジ

大枠を決めてから細かいところを追加していったんですけど、「これとこれを忘れてた」「じゃああれも必要だ」みたいな感じでプロジェクト会議が進まなくて。で、冒頭のように決裂しちゃったわけです。

イメージ:IT守り神

うーん。恐らく新しいベンダーを選んで、いちからやり直しってことになりそうだね。

イメージ:ケンジ

はい。次はもう絶対に失敗できないんです。

イメージ:IT守り神

じゃあまず、今回のことを整理してみようよ。

今回の失敗で発生した問題

  • 要件定義のやり直しによる追加作業費用発生。
  • ベンダーとの費用交渉の労力。
  • リリース時期の変更によって、自社の事業計画の見直しによる機会損失や計画の再策定作業が発生。

主な原因
本来守るべきスケジュールと費用を考慮しながら、ベンダーとプロジェクトを進められなかった。

イメージ:IT守り神

選んだベンダーもまずかったし、ベンダーとの仕事の進め方もうまくなかったということだね。せっかく拝んでくれたことだし、ご利益のあるアドバイスをしてあげよう。

IT守り神のアドバイス

イメージ:IT守り神

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

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

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

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

POINT1 信頼できる人を選ぶ

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

  • 優秀な技術者が揃っているので何でもできます
  • うちのECソフトは大手●●社でも採用していて実績もあります

何でもできますと言ったり、パッケージソフトの実績をアピールするだけの単なるシステム屋ではなく、あなたの会社の業務フローを作れるレベルの人を選定すべきだ。また、その人が実現できる要件定義の進め方を確認してから選ぶことも大事。

具体的には、「他社でどのように進められていたのか参考にしたいので、作成された要件定義書の実例を見せてもらえないですか」と言ってお願いするのも手だ。自信のあるベンダーなら見本のドキュメントを見せてくれるだろう。

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

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

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

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

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

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

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

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

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

  • 過去の要件定義書を見せてもらう
  • あなたの会社が提示した要件すべてが必要だ、と言っていないか

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

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

イメージ:IT守り神

あとは、あなたががんばって、しっかり社内や社外との交通整理をすることだね。
ベンダーを動かすために、運用担当者や判断者(上位者)とのパイプ役をつとめようとしている担当者には、どんなベンダーも協力を惜しまないものだよ。

イメージ:ケンジ

なるほど。たしかに、会社の実績ばかり気にして人を見てなかったかも。ぼくの仕事の進め方も悪かったみたいです。
けれど、IT守り神様に教えてもらったことに注意すれば、次はきっとうまく行きますよね。

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

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

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

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

イメージ:ウォーターフォール型(V字型モデル)での品質保証体系【ウォーターフォール型(V字型モデル)での品質保証体系】

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

ページの先頭へ戻る