Quantcast
Channel: Web担当者Forum
Viewing all articles
Browse latest Browse all 1122

要件定義のやり直しで追加作業発生! ベンダーと訴訟沙汰に? | ECのトラブルお助け [IT守り神がお助け! EC担当者のホントにあった大トラブル] | Web担当者Forum

$
0
0


この記事を読むのにかかる時間: 約 5 分
IT守り神がお助け!EC担当者の本当にあった大トラブル

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

IT守り神

IT守り神
ビジネス街の片隅にあるIT神社の神様。

ケンジ
今回の相談者

ケンジさん(男性・29歳)

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

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

それは大変だね。

うわ! 誰ですかあんた。

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

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

ふむふむ。

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

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

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

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

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

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

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

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

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

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

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

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

今回の失敗で発生した問題
  • 要件定義のやり直しによる追加作業費用発生。
  • ベンダーとの費用交渉の労力。
  • リリース時期の変更によって、自社の事業計画の見直しによる機会損失や計画の再策定作業が発生。
主な原因
  • 本来守るべきスケジュールと費用を考慮しながら、ベンダーとプロジェクトを進められなかった。

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

IT守り神IT守り神のアドバイス

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

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

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

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

POINT1 信頼できる人を選ぶ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

日本電気株式会社(NEC)
http://www.nec.co.jp/

大塚達

大塚達(おおつか とおる)
小売業ソリューション事業部 プロジェクトマネージャー

流通業・サービス業を中心に、NECのECサービス「NeoSarf/EC」のコンサルティング、システム開発に携わり、プロジェクトリーダとして数多くの大規模ECシステムの開発、導入経験を有する。

NeoSarf/ECサイト http://www.nec.co.jp/neosarf/ec/

近々の展示会イベント、ECセミナーについては以下を予定しています。ぜひご来場下さい。

セミナー
展示会
この記事に関連する他の記事を見る

※このコンテンツはWebサイト「Web担当者Forum - 企業ホームページとネットマーケティングの実践情報サイト - SEO/SEM アクセス解析 CMS ユーザビリティなど」で公開されている記事のフィードに含まれているものです。
オリジナル記事:要件定義のやり直しで追加作業発生! ベンダーと訴訟沙汰に? | ECのトラブルお助け [IT守り神がお助け! EC担当者のホントにあった大トラブル] | Web担当者Forum
Copyright (C) IMPRESS BUSINESS MEDIA CORPORATION, an Impress Group company. All rights reserved.


Viewing all articles
Browse latest Browse all 1122

Trending Articles