電子商取引プラットフォームを0から1まで構築しますか?

この記事の著者は、eコマースプラットフォームを0から1に構築するための要件検討会議のプロセスと落とし穴をまとめています。皆さんの参考になれば幸いです。

新任のプロダクト マネージャーの中には、製品レビュー ミーティングの開催が頭の痛い問題だと感じる人もいます。ミーティング全体をうまく開催できなかったと感じても、何を改善する必要があるのか​​がわからなかったり、ミーティングの開催時に陥りやすい落とし穴に気づかず、知らないうちに陥ってしまい、ミーティングの効率が下がってしまうこともあります。

私は製品レビュー会議をとても楽しんでいます。これはプロダクトマネージャーにとってのハイライトの 1 つだと思います。会議全体の中核的な役割として、会議をコントロールします。しかし、会議の質も完全にあなた次第です。

この記事では、私が以前主催したプロジェクトを例に、要件レビュー会議で従うべき「プロセス」を紹介します。その後、私自身の経験と、他の人が主催した会議に参加したときに発見したいくつかの「落とし穴」に基づいて、皆さんと共有し、伝えていきます。

1. まずプロジェクトの目的、範囲、主な機能プロセスなどを紹介します。

私たちは、参加パートナーにこのプロジェクトの目的、主な機能とプロセスを理解してもらうためにレビュー会議を主催します。したがって、他の人があなたのプロジェクトについて十分に知らない場合は、まずプロジェクトについて簡単に紹介する必要があります。そうしないと、混乱してしまいます。

例：

1. フルカテゴリの電子商取引プラットフォームとして、当社のプラットフォームモデルは、販売者に商品を公開するよう招待し、ユーザーを引き付けて注文を生成し、販売者に支払いを行うことなどです。このレビューは主に、社内で使用されている管理バックエンドに関するものです。
2. データの入力ソースとして、管理バックエンドにはまず、販売者のデータを追加および管理するための販売者管理機能が必要です。
3. マーチャントを追加した後、マーチャントは独自のマーチャントバックエンドを通じて商品をアップロードできます。また、当社が使用する管理バックエンドでも商品をアップロードし、マーチャントがアップロードした商品を管理および確認できるため、商品管理機能が必要です。
4. 製品データがあれば、フロントエンドまたはアプリはこれらの製品を確認して注文できるため、管理バックエンドには注文を発送したり、その他の操作を実行したりするための注文管理機能が必要です。
5. ユーザーは注文後に商品の返品や交換をすることも考えられるため、アフターサービスの管理機能が必要です。
6. ユーザーが支払った注文金額は一旦会社が保管するため、販売業者の支払いを決済するための財務管理機能が必要となります。
7. このようにデータの流れに沿ってプロジェクトを紹介し、参加パートナーによる受信の効率を高めます。

1. 落とし穴1: 関数について直接話す

以前、レビュー会議に参加したときに、これに遭遇したことがあります。新しいプロジェクトでは、モジュールの 1 つが最初から議論されましたが、このモジュールはプロセスの比較的後になってから議論されました。その理由は、このモジュールの内容が少なく、タスクを完了するためだけに議論されたかのようでした。

しかし、初心者の参加者は、プロジェクトが何のために使われるのか、どんな機能があり、どのように使うのかさえ知りません。プロジェクトの内容について推測しながら聞き、自分のこれまでのアイデアを検証する必要があるため、受信効率が非常に低い可能性があります。

それは本を読むときと同じです。最初はタイトルしか知らず、目次さえ知らないかもしれません。読みながら頭の中で目次を埋めていかなければなりません。

2. 落とし穴2: 会議が長すぎて、何を話し合ったか忘れてしまう

小規模なプロジェクトであれば問題ありませんが、大規模プロジェクトでレビュー時間が数時間に及んだり、数日に分かれたりする場合は、この問題に注意する必要があります。私がいつもやっているのは、参加者が前の内容を思い出すのに便利なように、すべてのレベルのメニューを黒板に事前に書き出すことです。参加者は話しながら黒板を指差すことができ、プロトタイプを前後に切り替える必要がありません（プロトタイプのページが多すぎると非常に不便です）。

例えば、2時間前にタグ管理機能についてお話ししました。商品管理で商品を追加することについてお話ししたとき、商品のタグを選択できますが、これらのタグはタグ管理で追加されます。黒板にデータフローの対応する機能を示して、一度復習しました。

2. ページで詳細な機能を紹介する

「データがどのように来て、どのように去るか」という原則に従い、順序はマーチャント、製品、注文、アフターセールス、ファイナンス、マーケティングです。この順序は、参加パートナーにとって最も理解しやすいものです。次に、分類の原則に従って、ページ上のフィールドを紹介します。

例：

図に示すように、これはアフターセールス注文の詳細であり、5 つの部分で構成されています。

1. アフターセールス注文自体の属性：アフターセールス注文番号、申請時間など。
2. アフターセールス注文の構成要素：ユーザーが選択した写真と理由。
3. アフターサービス注文関連情報：ご要望の商品情報、対応注文情報等
4. アフターセールス注文の各ステータスとそれに対応する操作。
5. 操作ログ。

まず、このページのフィールドをカテゴリ別に紹介します。これにより、ページのコンポーネントを大まかに理解でき、ページを開いたときにフィールドが多すぎて混乱することがなくなります。次に、いくつかの重要なフィールドとデータ フローに関連するフィールドの紹介に焦点を当てます。

返金申請金額は、商品の実際の支払金額に基づいて計算されます。たとえば、単価が 100 で、商品を 2 つ購入した場合、支払金額は 200 です。20 クーポンを使用した場合、実際の支払金額は 90 で、返金申請する商品の金額は 90 です。

3. 落とし穴3：導入時に機能間の連携がないため、受け入れ効率が低い

機能 A について説明した後、機能 B、機能 C について説明します。各モジュールは独立したエンティティとして説明されますが、それらの間の接続については説明しません。そのため、各レベルのメニューをあらかじめ黒板に書き出すことのもう1つの利点は、黒板の内容を直接指し示すことができるため、簡単にリンクできることです。

4. 落とし穴4：ページ上のコンテンツが多すぎて要点がつかめず、各機能を機械的に紹介してしまう

まず、レビュー会議の目的は、同僚をガイドし、プロジェクトの内容、主要なプロセス、主要な機能などについて一般的な理解を得ることだけであることを理解する必要があります。数時間でこれほど多くのプロセスと分野を全員が理解するのは不可能です。指導後、プロトタイプを渡して各分野を一つずつ確認してもらい、返答する必要があります。

会議で自分の話したいことをすべて説明しようとすると、会議時間が大幅に延び、他の人は聞き飽きてしまい、集中力が途切れやすくなり、効率が低下します。したがって、ページ上の主要な機能と二次機能、主要なフィールドと二次フィールドを事前にマークし、重要なポイントにのみ焦点を当てる必要があります。

3. 友達の質問に答える

スピーチの後またはスピーチの最中に、参加者は通常、独自の質問をします。需要側、開発、テスト、UI ステーションにはそれぞれ異なる視点があり、異なる質問をします。

5. 落とし穴5: 質問に答えるときに誘導される

会議の主催者としてのプロダクト マネージャーにとって最もタブーなことは、自信の欠如です。他の人の言うことに何でも従ってしまうと、会議での主導権を失い、チーム内での信頼を損なうことになります。

したがって、答えるときは、まず他の人がなぜこの質問をするのかを分析する必要があります。機能が使いにくいからでしょうか?開発は難しいのでやりたくないですか？開発時間が長すぎますか?それとも、データフローの設計に欠陥があるのでしょうか?相手の言うことが理にかなっている場合、相手が提案する解決策は最善の選択肢でしょうか?もっと良い解決策はありますか?

もちろん、他の人の意見にも耳を傾け、より良い解決策を見つける必要があります。これは非常に重要です。プロダクト マネージャーはチームとの繊細な関係を考慮する必要があります。強すぎると、人々はあなたが独断的すぎると考えます。弱すぎると、人々はあなたが自信が足りないと考え、あなたのプロ意識を疑うでしょう。

6. 落とし穴6: 議論に時間がかかりすぎ、会議のペースがコントロールされていない

新しいプロダクトマネージャーの中には、ボタンの配置やタイトルを左揃えにするか右揃えにするかなど、会議中に些細な点について意見が食い違ってしまう傾向があります。言うのは簡単ですが、大勢の人が集まる会議で質問してくる人に出会ったとき、納得できないと感じたり、感情に流されて勝ちたいと思うこともあるでしょう。ですから、感情をコントロールすることを忘れないでください。

すぐに結論を出せない曖昧な機能に遭遇した場合は、その機能を書き留めておき、会議後に話し合うようにしてください。

たとえば、商品情報をセグメントごとに保存するか、追加してから 1 つずつ保存するかについて議論している友人に出会ったことがあります。これには技術的なコストがかかるだけでなく、使用中のユーザー エクスペリエンスとリスクも関係します。また、起こり得るリスクの頻度と、それらが制御可能かどうかを分析する必要があります。すぐに答えを出す方法はありません。このとき必要なのは、まずそれを書き留めておき、会議後に関連部門の担当者を見つけてコミュニケーションを取ることです。

7. 落とし穴7：音に起伏がなく、雰囲気がコントロールされていない

これはプロダクトマネージャーの社外スキルともいえます。レビュー会議の開催はスピーチと同じです。相手に自分の話を聞いてもらい、気持ちよく聞いてもらうことが目的なので、文章の区切りのリズムや話すときの起伏の度合いなどが影響します。

例えば、上の写真のアフターサービスの注文番号や申し込み時間など、重要でない内容を話すときは、止まることなく速いペースで話します。金額などの計算が必要な項目や、計算方法が具体的に決まっている項目に出会ったら、声を大にして「ここがポイントですよ」とみんなに伝えます。

会議が半分ほど進むと、何人かの友人が気が散って携帯電話をいじり始めたのに気づきました。私は突然音量を上げましたが、気が散っていた友人たちはすぐにプロジェクターのスクリーンを見ました。

8. 落とし穴8: 会議中にやり取りがない

会議で議論が長引くのはよくありませんが、まったくやり取りがないのも良くありません。参加者が退屈で、自分だけしゃべり続けると、人々はあなたがただ言葉を読み上げているだけだと感じ、堅苦しい印象を与えてしまいます。

基本的には、重要なページや重要な分野について話し終わった後に、何か質問があるか尋ねます。誰も答えない場合は、関連するフロントエンドまたはバックエンドの担当者に尋ねますし、特定の人に尋ねると誰かが答えます。しかし、毎回ぶっきらぼうに質問するのはやめましょう。雰囲気を盛り上げるために、冗談を言うのもいいでしょう。これらはすべて、会議でのコミュニケーションの効率を高めるためのちょっとしたコツです。

9. 落とし穴9: 非言語的行動

これは個人的な意見の問題です。あなたの目、動き、座り方や立ち方の姿勢が会議全体の雰囲気に影響を与える可能性があります。緊張しているせいか、会議中はきちんと座っていて、声も大きすぎず小さすぎず、内向的なプロダクトマネージャーを見たことがあります。彼らは自信がないという印象を与え、会議の雰囲気はむしろつまらないものでした。

私は会議全体を統率する立場にあるため、会議を主催するときはたいてい立ちます。立っていると下を向いているような感じがしますし、音量を上げた際に全員の注目がすぐに私に向くようになります。重要なポイントを話すときは、プロジェクター スクリーンまで歩いていき、スクリーンを指差すこともあります。こうすると、そのポイントに対する全員の印象が強まります。

4. 各開発者の時間を確認する

レビュー会議が開発者向けのプロトタイプ要件を確認するためのものである場合、プレゼンテーション後にチームのそれぞれの時間を確認する必要があります。

ただし、会議で通常策定されるのは、大まかな時間ノードまたは大まかなプロジェクト計画を決定することであり、これにより、全員がどの期間に何を完了する必要があるかを把握できます。詳細なプロジェクト管理計画は、各自の毎日の正確さが求められるため、実際の具体的な進捗計画は会議後に策定する必要があることに注意してください。

2つの状況があります:

1. 打ち上げ時間が決定しました

まず、特定のモジュールを特定の開発者に割り当て（たとえば、A は製品管理を開発し、B は注文管理を開発し、C は財務管理のテストケースを作成します）、それぞれに必要なおおよその作業時間（インターフェイスの作成時間だけでなく、インターフェイスにかかる時間も含む）を決定し、開発、テスト、受け入れが発売までに完了できるかどうかを評価するためにまとめます。

• 可能であれば、まず大まかなマイルストーン計画を作成し、どのタスクがどのノードで完了するかを決めて、全員が準備できるようにします。
• そうでない場合：まず理由を調べてください。労働時間が足りないのでしょうか？残業する必要がありますか? 優先順位を見直して、まず一部の機能を削減する必要がありますか? 開発に時間のかかる一部の機能を置き換える代替ソリューションはありますか? 人員を増やすことも検討できます。現在のテクノロジーでは一部の機能を実現するのに不十分ですか?一時的に保留にしたり、別の解決策を見つけたりすることはできますか?

2. まだ決まっていない

また、作業を分割し、個別に作業時間を決めて集計し、おおよその完了時間が期待通りか、上司の期待通りかを確認することも必要です。コンプライアンスがない場合は、まず競合ポイントを見つけて、上記のように調整する必要があります。

5. 会議後の振り返り

会議後のレビューは非常に重要です。私は通常、会議全体の良い点と悪い点をレビューします。

• どの地域の参加率が高いですか?
• なぜ会議の後半で全員の集中力が失われ始めたのでしょうか?
• 議論が長引いたために会議が遅れたのでしょうか?
• 話すのが速すぎて、全員が理解する前にスピーチが通ってしまったことはありませんか?
• 他の人と議論するときに、相手の考えを過度に否定したり、遮ったりする傾向がありますか?
• 準備不足による緊張のせいで、分野の重要な部分を見逃してしまったことはありませんか?
• …

それは、教師が講義中に生徒の表情を観察するのと同じように、クラスメイトの表情や雰囲気を通して反映されることが多いです。要件レビュー会議を主催することは、公式さえ知っていれば答えがわかる数学の問題を解くようなものではありません。書道のようなものだと思います。美しく書く方法はわかっていても、練習していなければ書けません。ですから、もっと練習し、もっと要約し、しっかり準備し、十分な自信を持つのがよいでしょう。