ECのプロジェクトマネジメント

現代ECは巨大＆複雑化

現代のECにおけるプロジェクトマネジメントおよびプロジェクトマネージャー（PM）は大変です。私の周りでも、

「今PMが救急車で運ばれました。代わりの人を紹介してもらえませんか!?」

「先日までいたPMが鬱になりました」

「3日間徹夜でくたびれました」

など、壮絶な話は少なくありません。大規模＆複雑化するECのプロジェクトをうまく回すには、どのようにすればいいのでしょうか。依頼する企業側にも問題が多いので、そこをどうするかも含めてお話しましょう。

まず、Web制作とECサイト制作で大きく違う点があります。それは商品を販売して、決済して、物を運び、その商品をお客様に使っていただき、フォローをするという点です。2000年の頃のECサイトはそれほどアクセスもなく、トラフィックも10MBほどの回線があれば十分だったのが、今や大規模ECになれば1GBも優に超えるようにもなってきます。つまり、ネットワークの組み方からサーバの構成といったインフラをどうつくるかもECサイトでは必要になっています。

通常のWebサイトではセッションが長くなっても一人あたり5ページ～10ページ程度ですが、ECサイトの場合には人によっては100ページくらい見ることもよくあるので、この間のセッションを保持する必要があります。ロードバランサだけではなく、どうセッションを保持してデータベース（DB）にどのようなデータを保存するかも考えておく必要があります。PCとスマホでログイン、ログアウトしてどちらでも購入できるようになっているなんて今や普通ですからね。

ECサイトで一番困るのは、TV番組で突然紹介される等でトラフィックが急増し、ECサイトが閲覧不可になり機会損失するという可能性があることですが、とはいえ最初に最大トラフィックをどこまで見ておくか、性能試験をどこまで考えておくかという判断は難しいことです。

また、ECではクレジットカード決済で購入するのが主流ですが、現在のECサイトではほとんどクレジットカード情報を保管することはできなくなっているにも関わらず、個人情報を狙ってマシンガンのようにDDOS（複数のマシンから大量の処理負荷を与えサービス運営を妨害する）攻撃をしてくる輩もいます。このためセキュリティ対策をどうするのかは大きな課題になります。

つまり、インフラ構成からプログラム、DB、フロントだけでなく、受注やサポートを含めてバックオフィスをどうするか、ささげ（撮影、採寸、原稿制作）はどうするかなど、もちろん決済や物流を含めて考えなければならない時代になっています。当然ながら、構築するシステムを考えながらデザインをつくる必要があります（01）。

 

発注企業の思い違い

ECのプロジェクトを進めていくには、上記のように膨大な知識とノウハウ、高いコミュニケーション能力が必要になります。しかも、最近ではグローバルECも視野に入ることも多いので、英語でコミュニケーションが取れることが望まれます。そんなECのPMを年収600万円くらいから募集している大企業もありますが、PM本人からしたら正直なところ割に合いません。

クライアントとのコミュニケーションも一筋縄ではいかないことが多々あります。例えば、ステークホルダーが多くていつまでたっても決まらなかったり、上場会社なのに一族経営なので意思決定はすべてその一族がOKと言わなければ進まなかったり、今どきガラケーしか触ったことがない会長がすべてを握っているため、スマホECの話をしても通じなかったり…。「今日も2歩進んで3歩下がった！」と毎日のように愚痴のメッセージを私に送って来るPMが担うプロジェクトもあります。

しかし、どのような難解なプロジェクトでも進めていくのがPMの仕事です。大きな組織だと、営業とPMが分かれていることも多いのですが、できれば営業の段階で確度の高いプロジェクトが出てきたら、早めにお客様のところへ行ってコミュニケーションを取ったほうがよいです。これはECサイトだけはないと思いますが、実際のキーマンと早めにコンタクトを取っておいたほうが、難しい局面になった時にキーマンの考える方向性がわかっているだけでも展開を考える余地が出てきます。

ECプロジェクトのほとんどは売上アップが目的となっていることが多いので、その目的をしっかり共有できていれば、重箱の隅をつつく話や社内政治で右往左往することは少なくなります。困るのはキーマンが違うとか部署異動してしまったということも多くあります。この場合に備えてお客様の組織体制や組織変更の仕方などを最初の頃に軽く聞いておきます。それだけでも気の持ちようが変わってきます。

 

業務フローに落とし込む

システム面を見てみると、最近のECサイトは一つのシステムだけで構成することは難しく、デザイナーやフロントエンドエンジニアもバックオフィスを考えながら制作しなければいけません。つまりECサイトでどのような運用を行っているかをチェックする必要があります。まずは現状がどうなっているか、それがどうなるのか、がわかる一連のフローが必要になります。

新しいECサイトでは運用が変わってしまうことも多々ありますので、業務内容とECサイトの各項目をあわせておきます。中規模クラスのECサイトプロジェクトにおける簡単なタスク表と業務フロー（02）、役割分担とスケジュール（03）のサンプルを用意しましたので参考にしてください。

ECサイトのプロジェクトで、ボタンの掛け違いは後々少なからず問題になります。やはり、上流工程のディスカッションや課題整理、要件まとめ、ロードマップ、ベンダー選定などはとても大切です。その各工程でそれぞれ必要なドキュメントを残しておく必要があります。打ち合わせや定例会などの議事録はPMやプロジェクトを助けます。

私の周りではドキュメントを一切残さず、お客様任せみたいな進め方をするPMがいますが、それはかなり危険です。ドキュメントはエビデンス（証拠）にもなりますので、できる限りこまめにアップロードしておくのがよいでしょう。

このドキュメントのアップロード先として、私はプロジェクトツールのBacklogをメインに使っています（04）。ECサイトのプロジェクトであればBacklogで十分ですし、タスク管理もしやすくガントチャートも使えて、いつ誰がドキュメントをアップしたか、どれが最新版かといった管理ができます。PM側としてはタスクの追加はPMとプロジェクトリーダーのみといった規制を最低限掛けておけば安心で便利に使えるでしょう。

ただし、Backlogはコミュニケーションツールではないのでコミュニケーション目的で使用するとやりづらい面があるかもしれません。SlackやChatworkなどコミュニケーションツールとして開発されたものを使用したほうが無難です。

とはいえ、BacklogやChatworkといったツールを使用したコミュニケーションとは別に、お客様やスタッフとは対面するか、Webミーティングでの定例会をこまめに行うようにしましょう。ECサイト業界の動きも速いので週1回程度の定例会は行い、進捗確認をしておきます。Webミーティングなら1時間でも話をすればかなり詰められます。

これは要件定義以降の制作や開発、移行、テストなどの各工程でも必要です。このコミュニケーションでも議事録は残しておきましょう。

難しい仕事だからやりがいがある

ECサイトのプロジェクトで忘れがちなのが、受注以降の業務です。得てしてフロントのデザインやJavaScript、jQueryをどう使うかなどに注力しすぎて、多店舗展開の在庫処理、クレジットカード決済以外のID決済、銀行振込やコンビニ決済の処理、倉庫や物流の一部の運用等がプロジェクトから漏れていた、なんていうこともあります。名入れ工程はヒアリングできていたけど、特殊な名入れ工程の一部が変わっていたなんてこともあります。最初の全体整理の中でヒアリングしておき、スコープ範囲を決めておくのがよいでしょう。

意外な盲点としては会計システムや基幹システムとの連携です。例えば、このヒアリングを忘れていて、会計システム連携は後付けのCSVにしたり、基幹システム連携でバージョン確認に時間が掛かったということもあります。最初の全体構成図で関係者にヒアリングしておけば何の問題もなかったのですが、要件定義が終わってから質問が出て、その部分だけやり直しといったことが起きないように準備しておきたいです。

前述の通り、現在のECプロジェクトは規模が大きくなりつつあり、PMに求められる能力や知識も膨大になってきています。そのため、常日頃から国内外の情報を収集しておく必要があります…なかなか大変です。

ですが、最初にECサイト用のプロジェクトタスクやフレームワークを用意しておけば安心です。全体俯瞰からスコープ範囲を決めて、難題については早めに関係者への周知やコミュニケーションを取り、ドキュメント類でエビデンスを積み重ねていくことが重要になります。

難しい仕事だからこそ、やりがいもありますし、お客様からも頼ってもらうことができます。ECプロジェクトのPMの一番のやりがいは、そのプロジェクトで商品が売れてお客様が喜んでくれるという点に尽きると私は考えています。たくさん売れるECプロジェクトをどんどんつくっていきたいですね。