設問とコンテキスト
あるB2B SaaS企業は、1,200社の顧客と85,000人の週間アクティブユーザー（WAU）を抱えています。カスタマーサクセス、サポートオペレーション、アカウントマネージャーの各チームが「業務効率化のための社内ツールが必要だ」と主張していますが、共通した課題は言語化されていません。あなたには2週間のディスカバリー期間と、実装を担当するエンジニアリング1スクワッドの6週間が与えられています。ツールは既存のCRMおよびチケット管理システムを再利用する必要があり、人員の追加やプラットフォームの再構築はできません。
どのような質問をし、実際の業務フローの課題をどのように特定し、どのユーザーを最初に支援するかを説明してください。また、MVPと成功指標をどのように定義し、どのタイミングで継続、方針転換、または中止を判断するかを述べてください。
面接官が見ているポイント
- 曖昧なリクエストを、ユーザー、タスク、頻度、ペイン、ビジネス成果へと分解できるか。
- 「ツールの構築」を前提とした解決策をそのまま受け入れず、客観的根拠に基づいて問題を検証できるか。
- 2週間のディスカバリーと6週間のエンジニアリング期間内で納品可能なMVPのスコープを適切に定義できるか。
- チーム間の相反する目標やシステムの統合境界を適切に管理できるか。
- リリース実績や満足度だけでなく、セグメント別指標や撤退・停止ルール（stop rules）を設定しているか。
最初に明確にすべき質問
- ここで言う「効率」とは何を意味するか：処理時間、重複入力、エラー率、応答待ち時間、あるいはシステム間の切り替え負担か？
- どの職種が最も頻繁に課題に直面しており、その頻度と影響（損失）はどの程度か？
- 現在のワークフローはどのように実行されており、CRM、チケット管理システム、スプレッドシートの間でどのようなステップが発生しているか？
- この問題は収益、解約抑止（リテンション）、コンプライアンスに影響を与えているか、それとも単に従業員の利便性の問題にとどまるか？
- 2週間の調査期間中に何人のユーザーとどれだけのアクティビティログにアクセスでき、どのデータの閲覧が許可されているか？
- 6週間後の成果物は実際に稼働するワークフローである必要があるか、それともインタラクティブなプロトタイプと人力運用の組み合わせでも許容されるか？
30秒回答フレームワーク
私はまず「効率化」を観察可能な具体的タスクに変換し、職種、発生頻度、ビジネスへの影響度に基づいて優先順位をつけます。2週間のディスカバリー期間中に、ヒアリング、業務フロー観察、チケットデータ、CRMデータを組み合わせて、誰が・どのような状況で・何を損失しているかを検証します。MVPでは、発生頻度が高く測定可能な単一のワークフローを解決対象とし、既存システムのインターフェースを再利用しながら人力でのフォールバック手段を確保します。指標としてはタスク完了時間、重複入力、エラー率、利用率、ユーザー成果を追跡し、投資の継続・方針転換・停止を判断するルールをあらかじめ定義します。
ステップ別の詳細解説
ステップ1：リクエストを課題仮説として再定義する
「社内ツールが必要だ」という要求を、「特定の職種が、あるタスクにおいてフリクション（摩擦）を経験しており、それによって成果が悪化している」という形に再定義します。アカウントマネージャーはCRMとチケットシステム間で情報を二重入力しているかもしれず、サポートオペレーションはチケット割り当ての遅延を問題視しているかもしれません。複数の仮説を立て、実装形態そのものを課題として扱わないようにします。
ステップ2：根拠の強さに基づいてディスカバリーを計画する
まず実際の業務フローと最近の事例を観察し、半構造化インタビューでその要因を掘り下げ、ログ、チケット、CRMデータを用いて問題の規模を見積もります。表明された希望や意見は手がかりに過ぎず、需要の証明ではありません。各仮説について、裏付けとなる証拠、反例、未解決の疑問、および次の検証ステップを記録します。
ステップ3：ターゲットユーザーと優先順位の決定
頻度、影響度、アプローチのしやすさ、改善の実現可能性に基づいてワークフローをランク付けします。既存システムの制約内で改善可能であり、明確な影響力を持つ高頻度のワークフローを最優先します。頻度は低いもののリスクが高いワークフローについては、セキュリティやコンプライアンスの観点から個別に評価を行い、対象ユーザー数が少ないという理由だけで安易に除外してはなりません。
ステップ4：6週間のMVPスコープの策定
MVPは、チケットから顧客のコンテキストを読み取り、定型化された処理下書きを生成し、従業員の確認を経てCRMに書き戻すといった、1つのエンドツーエンドのタスクを対象とすべきです。この段階で新しい権限管理センター、包括的なレポート機能、複数チーム向けの共通プラットフォームなどを追加してはなりません。連携が失敗した場合に備えて従来の作業経路を残し、従業員が結果の確認、編集、取り消しを行えるようにします。
ステップ5：チーム間の利害対立と連携制約の調整
機能リストの比較ではなく、共通のワークフローマップと指標ツリーに基づいてチーム間で議論を行います。CRMおよびチケット管理システムの権限、書き込みルール、レート制限、データ保持ポリシーを確認します。6週間以内に安全に連携できない要素はすべて、データエクスポート、目視確認、または将来のスコープへと切り離します。
ステップ6：指標と停止ルールの定義
先行指標には、対象ワークフローの利用率（Adoption）、完了時間、重複入力回数を含めます。成果指標には、エラー率、顧客応答時間、手戻り作業（Rework）を含めます。ガードレール指標としては、権限エラー、データ漏洩インシデント、従業員の苦情、システム障害率を設定します。利用率が上昇してもエラーや手戻りが閾値を超えた場合は、展開を一時停止し、課題の再検証に戻ります。
ステップ7：検証とロールアウトの計画
プロトタイプと人力シミュレーションを用いてフローを検証し、1つのチームと1種類のタスクに限定してパイロット運用を実施します。ベースライン、対照群、または事前事後の比較を設定し、職種やタスクごとに結果をセグメンテーションします。毎週エビデンスをレビューし、展開の拡大、仮説の修正、人力運用の継続、またはプロジェクトの中止を判断します。
高品質な回答例
私は「ツールの構築」をそのまま課題定義とは捉えません。まず効率という概念を具体的なタスクへと分解し、どの職種が重複入力、待機、またはエラーを発生させているかを特定した上で、2週間の業務観察、ヒアリング、CRMデータ、チケットデータを活用してその規模を検証します。頻度、影響度、アプローチのしやすさ、6週間での実現可能性に基づいて選択肢をランク付けし、測定可能な成果が見込める高頻度ワークフローを1つ選択します。MVPは既存システムからコンテキストを読み取り、編集可能な下書きを生成し、従業員の承認後にのみ書き込みを行う形にします。権限エラーや書き込み失敗が発生しても従来のフローで業務が継続できるようにします。指標には利用率、完了時間、重複入力、エラー率、手戻り、顧客応答時間を設定し、権限エラー、データ漏洩、システム障害をガードレールとします。1チームでのパイロット運用を行い、拡大・変更・停止の閾値を事前に設定した上で、効率化と同時にエラーや手戻りが増加した場合は拡大を一時停止します。
よくある失敗
- 「社内ツールの作成」を要件そのものとみなし、すぐにUI画面や機能の設計に入ってしまう。
- 現場の業務を観察せず、マネージャー層へのヒアリングだけで済ませてしまう。
- 行動データや成果指標の代わりに、単なる満足度アンケートで効果を評価してしまう。
- 3つのチームすべてに同時に対応しようとして、6週間でエンドツーエンドのフローを1つも完成できない。
- CRMやチケットシステムの権限設定、書き込み制約、データ保持制限を無視する。
- エラー、手戻り、プライバシーに関するガードレール指標を設けずに利用率だけを追跡する。
- 撤退・停止ルールを持たず、これまでのサンクコストを理由に開発を継続してしまう。
追加質問と回答例
3つのチームすべてが自らの課題が最優先だと主張した場合はどうしますか？
各チームに対し、頻度、影響度、エビデンス、実現可能性という共通の基準で具体的な事例の提示を求めます。検証可能な成果と6週間でサイクルを完了できる能力を重視して優先順位を決定し、それ以外は政治的な力関係で決めるのではなく、将来の検証仮説としてバックログに記録します。
ビジネス側がプラットフォーム全体の同時納品を主張した場合はどうしますか？
共通の制約条件と最初のワークフローを切り離します。まずは変更の取り消しや効果の観測が可能な単一の垂直スライス（Vertical Slice）を提供し、実際の数値で価値を証明した上で、どのインターフェースや権限にプラットフォーム投資を行うべきかを判断します。6週間以内に安全に検証できないスコープは約束しません。
ヒアリング時の評価は高かったのにMVPの利用率が低い場合はどうしますか？
実際のタスク実行経路、起動タイミング、書き込み権限、エラーログを確認し、単なるツールの認知と実際の業務での利用を区別します。承認の手間や既存ワークフローの分断が障壁になっていないかを調査し、プロモーションを増やすことで行動の乖離をごまかすのではなく、フリクションを取り除いた上で小規模な実験を行います。
効率は向上したもののエラー率も上昇した場合はどうしますか？
職種、タスク、エラーの深刻度ごとにセグメンテーションを行い、リスクの高い領域での展開を一時停止します。エラーがガードレールの閾値を超えた場合は、人の手による確認プロセスを復活させるか、スコープを狭めるか、フローを変更します。エラーが許容範囲内に収まり、成果指標が継続的に改善されている場合にのみ投資を継続します。