ECサイト構築フローをPM観点で整理してみた(中編)

2022年2月14日 13:17

ECサイト構築プロジェクト：いよいよ始動！

前編では受注までのフローでしたが、中編ではECサイト構築プロジェクト受注後の「キックオフ」〜「リリース」までを整理してみます。前編がまだ方はこちらから。

●ECサイト構築フローをPM観点で整理してみた
■前編：https://note.com/masa_pencil/n/n45d45df5f70e
■中編：https://note.com/masa_pencil/n/ndd901628adba
■後編：https://note.com/masa_pencil/n/ncd3927a87ff8

５：キックオフ

ECサイト構築を正式に発注いただいた後、まずキックオフミーティングを社内、クライアントと２回に分けて行います。

●１回目：社内キックオフミーティング
■過去のEC構築プロジェクトの振り返り
■プロジェクトの共通理解（目的・目標・体制・スケジュールなど）
クライアントとの前に、開発パートナー含めまずは社内キックオフミーティングを行います。
過去のプロジェクト振り返りはKPTAでまとめているのでそれを見直して今回のプロジェクトに活かす注意点をメンバー間で共有します。（KPTAは「後編」で整理します。）
また今回のプロジェクトで想定される独自のリスクなどもメンバーと洗い出しと対策を考えておきます。

●２回目：クライアントとのキックオフミーティング
参加者はクライアント・パートナー含め全員参加いただき以下の内容の認識合わせをします。
認識が違っている前提で関係者全員の意識合わせする気持ちで進めていきます。

●アジェンダ例
■目的・目標・ゴール
・提案時の目的・目標を再提示し、プロジェクトのゴールを明確にします。
■スケジュール
・マスタースケジュール
・各工程の説明
■体制図
・会議体の種類とそれぞれ参加いただくメンバーの説明
■役割・責任範囲
・だれに何を聞けばよいか？
・だれがどの領域に責任を持っているか？
■ツール・ルール
・ツール：推奨ツール利用可能かの確認
・ルール：ファイル管理・議事録作成のルールなど
■意気込み宣言
・このプロジェクトにかける意気込みを参加者それぞれ発表。

大方針として議事録やドキュメントなど可能な限りクラウド上にし管理工数を削減します。もしクライアントの都合上できない場合は調整が必要になります。

議事録は「打ち合わせ終了と同時に完成させる」ルールをメンバーに周知します。そのため参加者全員が閲覧・編集できる環境を用意し、決定事項・タスクは参加者全員の前で明確にします。

システムに関わる打ち合わせの場合、終了した後から議事録完成させようとしても参加者の認識違い・忘れる・確定まで時間がかかるなどの問題がでてくるのでメンバー全員に協力いただいています。

また、最近はオンライン会議ですすめることが多く、アジェンダやオンライン会議URLなども毎回案内するのは面倒です。
そこでアジェンダにオンライン会議のURLを記載し、メンバー誰もが毎回連絡受けなくてもクラウド上にあるアジェンダの場所にアクセスできるような仕組みにしています。

細かいことですがなくしても問題ない連絡は減らす積み重ねも長期間のプロジェクトでは大切な取り組みです。

私がPMとしてECサイト構築プロジェクトに関わらせて頂く場合、このキックオフミーティングはかなり気合が入ります。
プロジェクトメンバー全員の意識がバラバラの状態でスタートしますが、リリースに向けて徐々にメンバーの意識が統一されていく過程を体験できるのがPMの醍醐味だと個人的に思っています。

６：要件定義

キックオフミーティングの次からいよいよ要件定義が始まります。領域が多岐にわたるので大きく３つの領域に分け要件定義終了時に「要件定義書」としてドキュメント一式を納品します。もちろん案件によってドキュメント類は変わるので以下は参考までに。

●デザイン要件
　■制作要件
　■デザイン方針
　■サイトマップ導線設計
　■画面構成
　など

●機能要件（ECシステム関連が中心）
　■フロント画面・機能要件
　■データ連携要件
　■管理画面機能要件
　■マスタ・データ移行
　■バッチ処理・メール機能
　など

●非機能要件（インフラ・セキュリティ・リリース後の運用など）
　■セキュリティ
　■ハードウェア
　■運用保守
　■リリース後の運用関連
　など

上記はあくまで例ですが、私は要件定義からリリースまでの期間でECサイト構築プロジェクト用の「帳票」をGoogleスプレッドシードで一元管理しプロジェクトメンバー全員が常に最新の情報にアクセスできるようにしています。

この帳票は、メンバーの連絡先・ツールアカウント・QA・機能一覧・テストシナリオ・テスト結果・リリース計画など可能な限りすべての情報を管理していきます。スタート時は数個しかないシートも終盤は何十ものシート数になります。
こういったやり方で「あのファイルどこにある？」とメンバー間での発言がなくなるように心がけています。
といいつつ実は私が一番「あのファイルどこにある？」と聞いて回っていたのでそれを無くすためにやりだしたんですがね。。。

７：設計

各種設計書をドキュメントにまとめていきます。設計書も案件によって必要なものが変わりますので、こちらもあくまで参考までに。
■EC-基幹連携設計書
■コード定義書
■データ移行
■データ連携
■バッチ処理一覧
■フロント機能一覧
■管理画面設計書
■金額計算
■軽減税率
■購入割引
■購入特典
■自動返信メール一覧
■入力フォーム定義書
など

私はプログラム経験がなくシステム領域は詳しく無いので、機能要件リーダー、非機能要件リーダー、開発パートナーの力をかりまくってドキュメントを作成していきます。（ほんと頼りになります）

ECサイトの場合、会員登録・カート・マイページなどの機能は必須ですがこれら設計時に、プロモーション、サイト分析、基幹連携、出荷処理、CRMなど、ユーザーがサイト訪問・注文・商品受け取り・フォローまでのフローを考えながら詳細設計していきます。

８：製造

製造も「デザイン要件」「機能要件」「非機能要件」にわけて整理してみます。以下も案件によって必要なものが変わりますので参考までに。

●デザイン要件
■キーデザイン
■フロント系ページ（トップ・カテゴリトップ・商品詳細ページなど）
■フォーム系ページ（会員登録・カート・マイページなど）
■メール

●機能要件
■アプリケーション開発
■マスタ整備
■管理画面

●非機能要件
■インフラ構築
■基幹システム連携
■分析設定

９：テスト

テストは「単体テスト」「結合テスト」「運用テスト」の３つに分類し新ECサイトのクオリティを上げていきます。

●テストシナリオ
テストをメインで行うチームに要件定義・詳細設計のドキュメントを共有しテストシナリオ作成を依頼しますが、丸投げするのではなくPMもPLも一緒にテストシナリオを考えます。
要件定義から打ち合わせを重ねているので気づくテストパターンなどもあるのでそういった意味でチームとしてシナリオも精度上げていきます。

●課題管理と課題つぶし
テストは可能な限り多くの方に協力いただきます。いろんな視点でチェックするのが理想です。不具合は大小に関わらず徹底的に洗い出し、１つ１つ潰していきます。
心が折れるぐらい膨大な課題数がでてくるので「覚悟」しておきますが、リリース後のトラブルを防ぐにはここで見つかってよかった！と思うようにしています。

この膨大な課題を効率的に潰せるように案件やチームにあったルールを作っていたほうがよいです。

私の場合、テスターが発見した課題は、Googleスプレッドシートに全員が同時に閲覧・編集できるようにし、課題単位でBacklog起票していきます。

このルールで全課題数・完了数・残件数・完了率・優先度を「課題一覧表」で管理します。課題は数百にもなるので焦らずプロジェクトチーム全員で手分けしながら潰していきます。

ここまでくると、メンバーと毎日朝会で進捗状況共有と課題つぶしを行います。日々残課題数が増えたり減ったりするので、この完了率を常にクライアントと共有しつつ最終的にリリース判定会議で公開できるかどうか判断いただきます。

１０：リリース

リリース判定会議で公開OKいただくと、いよいよECサイトのリリースとなるので、このときまでにリリース計画も同時進行で準備しておきます。

私が関わる案件のリリース計画では以下のようなものを用意しています。
●リリースチェックの事前準備
データ移行などがある場合、その検証できるように事前に必要なアカウント・注文情報などをリリース直前までに作っておきます。

●作業分担表
各社がどの領域の作業をするのか一覧表にまとめます。

●タイムスケジュール
各リリース作業工程と予定時間を記載し、リリース時はこの予定時間に対し予実管理していきます。

●リリース時チェック
リリース作業が完了し一般公開する前に関係者のみアクセスできるようにした本番環境で基本的な動作検証（会員登録・購入・注文変更など）を行います。

●リリース時のメンバー稼働スケジュール
深夜のリリース作業中にトラブルが発生した場合連絡が取れるように、プロジェクトメンバー全員の緊急連絡先・連絡が取れる・とれない時間帯などをまとめておきます。
あまり使うことは無いのですが用心のため準備しています。

これまでのPMの経験上、リリース判定でOK頂いていればリリース作業時に大きな問題はないですが多少のトラブルはつきものです。

トラブルは必ず起きると「覚悟」してリリース作業メンバー全員で乗り切ります。

●リリース後
無事リリース完了するとクライアントへの報告をします。リリースは早朝に完了することがほとんどなので、リリース直後の午前中は何か問題が発生してもすぐ対応できるようにメンバーで待機しますが、午前で退勤・午後出社と入れ替わり対応できるメンバーのタイムスケジュールも作成しておきます。私はだいたい午前で退勤して自宅で爆睡する方です。

これまでリリース後は打ち上げを行っていましたが、最近はなかなか難しいので、自分へのご褒美として好きなお酒を買うようになりそれなりに増えてきました。（入れ替わりサイクルが短いですが・・・）

いかがでした？

「中編」はここまでですが、いかがでしたでしょうか？
プログラマー未経験のPM観点でECサイト構築フローをまとめましたが少しでもみなさんの参考になれば嬉しいです。

次回「後編」は「ECサイトリリース」してからのフローを整理していきます。