プロダクトマネージャーの面接：課題・指標・優先順位をケースで答える

「顧客から自動PDF出力を頼まれています。次の開発で入れますか」。プロダクトマネージャーの面接でこの問いを受けたら、機能一覧や優先順位の点数から話し始める必要はありません。誰が何に困っているか、何を改善と呼ぶか、限られた開発時間で何を確かめるかを、一つの判断として説明します。

この記事では、現場作業の報告を承認するSaaSを題材に、要望の確認、指標の定義、開発候補の比較、検証後の判断までをつなぎます。結論は「PDFを作らない」ではありません。現時点では信頼性の修正と課題調査を先に選び、別の証拠が出たときに決定を変えられる状態にする、という提案です。 How would you prioritize and test features?を練習先にして、以下のケースで判断の根拠を組み立ててみてください。

証拠の区分： GOV.UKの公開ガイダンスとMicrosoft Researchの実験研究は、調査・測定の方法を説明する一次資料です。日本企業の選考形式を定める資料ではありません。本稿には同じ採用時期の候補者報告に基づく出題頻度や合格基準の主張はありません。顧客、件数、工数、比較結果はすべて架空の練習条件で、提案はその条件からの推論です。

最初に確認するのは、PDFの用途と困っている人

今回の練習条件は、作業員が写真と作業内容を提出し、管理者が承認するサービスです。大口顧客6社から「承認済み報告書を自動でPDFにしたい」という要望があります。一方、運営側は報告の差し戻しが多いことを課題としています。

ここには少なくとも、提出する作業員、内容を確認する管理者、報告書を受け取る取引先という違う立場があります。管理者の転記時間を減らす話と、作業員の再提出を減らす話では、必要な機能も成功の測り方も変わります。6社の要望を、6人の独立した利用者の声として扱う前に、一社の窓口が誰の困りごとを代表しているかも確かめてください。

面接では、まず「PDFは承認前と承認後のどちらで使われますか。誰に渡すもので、現在は何分かかりますか」と聞けます。続けて、提出期限、現在の代替手段、必須の書式、契約上の約束の有無を確認します。必須書式が存在するとはまだ仮定しません。面接官から追加条件が出たら、その条件を意思決定に反映します。

公式方法論： GOV.UKのユーザーニーズのガイダンスは、既存の証拠、利用者への聞き取りや観察を使い、解決手段より利用者の問題に注目するよう説明しています。この考え方を今回の要望確認に応用します。

「PDF化したい」を、暫定的に「管理者が承認済みの内容を取引先へ渡す際、手作業で転記している」と言い換えると、必要な調査が具体的になります。現場の報告提出自体に問題があるのか、承認後の共有に問題があるのかを分けて確かめられます。

100件の報告から、観測と原因の仮説を分ける

基準となる提出コホートについて、次の架空データがあるとします。各報告は初回提出から7日間を観測済みで、今回はすべて初回の承認か差し戻しが確定しています。大口・小口は初回提出時の契約区分で固定します。

差し戻し40件のうち、26件には「写真不足」という理由が付いています。残る14件は他の理由か理由不明です。26÷40は65%ですが、これは差し戻しの分類割合です。写真不足が全提出の65%で起きた、あるいは写真の必須チェックだけで差し戻しを65%減らせる、とは言えません。

ケースからの推論： 写真が撮られていない、アップロードが失敗した、写真はあるが必要な箇所が写っていない、という別々の原因が候補になります。提出ボタンを無効化するだけでは、通信失敗や承認条件の不一致を直せない可能性があります。分類は原因の証明ではありません。原因を取り違えると、提出を止めるだけの修正になりかねません。

次に見る証拠は、差し戻された報告の写真保存状態、アップロード失敗の記録、承認者の指摘、現場での提出操作です。少数の実例を作業員と管理者の両方に確認し、理由コードが実態と一致するか調べます。顧客データを扱う場合は必要な範囲に絞り、写真に含まれる個人情報や業務情報を無関係な相手へ共有しません。

大口6社だけの要望にも偏りがあります。小口の承認率が低いから小口を優先すべきだ、とも即断できません。契約区分で作業内容、承認基準、導入時期が違うかもしれません。まず両区分の提出・承認の流れを比較し、声を上げていない利用者の困りごとも確認します。

指標は名前より、分母と観測期間を説明する

このケースの主指標を「初回提出した報告のうち、7日以内に差し戻しを受けず最初の判断で承認された割合」と定義します。7日は練習上の観測窓です。実際の業務で妥当かは、承認にかかる時間や提出期限を調べて決めます。

7日を超えてから初回承認された報告は、この指標では分子に入りません。しかし分母には残ります。これは「永遠に承認されなかった」という意味ではありません。承認までの時間や最終承認率は、別の指標として追います。対象件数がゼロなら率を0%と表示せず、算出できないと示します。

主指標だけを上げる施策にも注意が必要です。写真を必須にして提出できない人が増えた場合、提出された報告の承認率だけは上がるかもしれません。そこで、対象期間に報告義務のある作業に対する期限内提出率、写真保存の失敗率、入力開始から提出までの時間も確認します。未提出の作業が分母から消える指標では、業務全体の改善を説明できません。

公式方法論： GOV.UKの成功測定の説明は、性能指標とユーザー調査を併用し、デジタル分析だけに頼らないことを勧めています。このケースでも、承認率と現場の操作観察を一緒に見ます。数字で変化を捉え、観察でその理由を確かめるためです。

5人日の制約で、何を今やらないかを決める

今使える開発時間を5人日とし、写真保存の既知の不具合を直す作業に2人日が必要だとします。これはケースの前提であり、26件すべての原因がその不具合だという証拠ではありません。工数は実装・確認を含む仮の見積もりで、担当者と見直す余地があります。

この条件での提案： 既知の不具合を直し、残る時間で事例調査と測定整備を行います。写真チェックは既知の不具合修正と合わせて5人日に収まりますが、「入る」と「選ぶ理由がある」は別です。必要な写真の条件が未確認のまま強制すると、提出を妨げる可能性があります。

調査は無期限にはしません。差し戻し理由と実際の写真状態の対応、作業員が撮影を省いた理由、PDFの現在の手作業と期限、イベントの記録漏れを確認し、次の優先順位を決められる成果物として共有します。PM自身が行う聞き取りと、開発者が行う計測の修正を分け、2人日の見積もりに何を含めたかも説明してください。

優先順位を変える証拠も挙げます。たとえば、取引先への提出でPDFが必須で、確認済みの期限が迫っているなら、現在の容量を超えるためスコープや他の作業を調整する判断が必要です。「大口だから全部先にする」ではなく、確認された業務上の制約と延期の影響を示し、決定権を持つ人と選びます。逆に写真不足が撮影漏れに集中していれば、次の開発枠で写真チェックを小さく試す根拠になります。

60%から68.75%に上がっても、改善とは限らない

次の比較用コホートを想像してください。これは施策を実行した実験結果ではなく、集計の落とし穴を確認するための架空データです。観測窓と指標定義は先ほどと同じとします。

各区分の率は同じですが、もともと承認率が高い大口の割合が増えています。基準コホートの構成比、大口60%・小口40%で比較側の率を重み付けすると、0.6 × 0.75 + 0.4 × 0.375 = 0.60です。全体の上昇だけで機能の効果を断定できません。

面接官から「8.75ポイント改善しました。全社展開しますか」と聞かれたら、「構成が変わったことを確認し、区分内の率と提出率を見ます。この表だけでは施策による改善と判断できません」と答えられます。比較する定義、観測期間、計測漏れが同じかも確認します。構成比を揃えた計算は診断の一つで、観測されていない違いまで消して因果関係を証明するものではありません。

本稿ではPythonで有理数計算と小さな分類関数を実行し、24項目が期待結果と一致することを確認しました。件数・率・工数の計算に加え、7日ちょうどの承認、保留、期間を超えた承認、観測期間不足の扱いを検証しています。検証したのは架空データの計算と定義です。実顧客の行動、実験の検出力、売上効果は検証していません。

小さく試した後の判断まで、先に言葉にする

写真チェックを試す段階では、どの作業にどの写真が必要かを先に確認し、通信失敗時の扱いを設計します。写真の存在だけで内容の妥当性を保証せず、失敗した保存を成功と表示しないことも条件です。現場の操作を観察し、提出が進まなくなる場面がないか確かめます。

効果を比較するなら、同じ会社の承認者が複数の作業員を見ている点も考慮します。作業員ごとの割り当てで運用が混ざるなら、会社単位の割り当てが候補になりますが、独立した会社数が少ないと判断に必要な情報が足りない可能性があります。単位、必要件数、観測期間は分析担当者と検討します。「6社あるので十分」「一週間で有意差が出る」とは約束しません。

公開研究の方法論： Microsoft Researchの実験ガイダンスは、主指標のほかにデータ品質、診断、ガードレールの指標を扱い、区分ごとの分析も重視しています。ここでは提出率や保存失敗も見る設計に応用します。同研究の実験期間を、そのままこの業務の適切な期間とはしません。

割り当て比率の不整合や計測欠落があれば、効果判定を止めて原因を調べます。これは前の表の顧客構成の変化と同じ問題ではありません。前の表は二つの提出コホートの比較であり、無作為割り当てした二群ではないからです。実験を計画する場合は、何を誰に割り当て、何を観測できたかまで追えるようにします。

事前の判断は三つに分けると話しやすくなります。定義した結果が改善し、提出の妨げが見つからなければ次の対象へ広げる候補にする。承認率が上がっても未提出が増えれば、入力条件を見直す。件数不足や記録漏れなら、改善したとも失敗したとも断定せず、必要な観測を追加する。停止条件の具体値は、業務への影響と基準値を確認して合意します。

面接での回答例と、追加質問への返し方

次の回答は暗記用の正解ではなく、このケースの条件をつないだ例です。実際の面接では、先に聞いた追加条件に合わせて短くします。

まずPDFが必要な場面と利用者、現在の代替作業、期限を確認します。今回は差し戻しも課題なので、初回提出100件のうち承認60件という基準を、大口と小口に分けて見ます。写真不足26件は原因が確定した数ではありません。5人日のうち2人日を既知の保存不具合に使い、2人日で理由と写真状態の調査、測定整備を行う案です。写真チェックは容量内でも、条件が未確認なので先に強制しません。次の比較で全体の率が上がっても、構成比と提出率を確認します。PDFが確認済みの業務要件なら、延期の影響を示してスコープか容量の調整を相談します。

「ではPDFをいつ作るのか」と聞かれたら、日時を作って答える必要はありません。「調査で共有の負担と必須条件を確認し、最小の出力範囲と工数を見直した時点で判断します。今は実装日を約束できません」と返せます。確認する担当者と結果を見直す場を示せば、依頼した相手にも次の動きが伝わります。

「売上の大きい顧客の要求を断れますか」には、契約、継続利用への影響、現在の回避策を確認したうえで、選択肢と失うものを説明します。未確認の解約リスクを数値化して点数に入れないことも大切です。「開発者が3人日では無理と言ったら」には、見積もりの前提、検証範囲、依存作業を聞き直し、容量表を更新します。初めの提案を守ることより、証拠に合わせて判断を更新する姿勢を示してください。

PracHubの5問で、判断の根拠を言い直す

以下は関連する練習先です。企業名のあるページも、今回のケースがその企業で出題される証拠ではありません。まず今回の数字で答え、次に各問題の条件へ戻って違いを説明してください。

次はHow would you prioritize and test features?を開き、5人日の制約を残したまま、「今選ぶ案」「延期する案」「判断を変える証拠」を声に出して説明してみてください。相手が確認できる根拠を示せれば、提案への追加質問にも答えやすくなります。

Sources and Further Reading

• GOV.UK — Learning about users and their needs：問題と解決手段を分けるユーザー調査の公開ガイダンス。
• GOV.UK — Measuring the success of your service：指標とユーザー調査、複数のデータ源を組み合わせる説明。
• Microsoft Research — Patterns of Trustworthy Experimentation: During-Experiment Stage：指標の種類、区分分析、データ品質と実験中の判断に関する研究者の解説。採用手順の資料ではありません。