仕事を行う上で、他の人から「〇〇をお願いしたい」と頼まれることはよくあると思います。ただこの与件を鵜呑みにしていませんか？与件を正しく解釈し、的確な答えを出すことで、より仕事が円滑に進みます。
私たちセブンデックスも、クライアントワークで日々顧客の与件に対する最適解を提供し、課題を解決しています。そんな実務経験からどの様に与件を整理すればよいのか、プロジェクトを成功に導く与件整理術をご紹介します。
目次
与件整理の重要性
まずはじめに「そもそも与件って何？」から紐解いていきたいと思います。
与件とは、相手から与えられた前提条件のことです。「売上が伸びない原因がわからないので特定して欲しい」、「会社をさらに認知させたいので手段を考えて欲しい」、「次のプレゼンで部長に納得してもらえるプレゼンをしたい」。会社ごと、サービスごと、フェーズごとにも与件は異なります。
さて、皆さんは与件を聞いた時どうしますか？聞いたことをそのまま実行しようとしていませんか？よくある間違いですし、与件整理が大事な理由です。
与件は正しくまとまっていることが少ない、つまり、相手から語られた与件は大体違うのです。
どういうことかと言うと、相手が語る事は最終的な事象にしか過ぎず、その裏の過程や心理に対してアプローチすることが必要なのです。
例えば「売上が伸びない原因がわからないので特定して欲しい」も、実はたまたま競合が伸びていると言う噂を聞いて「うちは伸びていないんだ」と思い依頼、でも実際は自社も着実に成長していたので、本当にやってほしい事は「競合差分があるかを明らかにする。そこから自社の強みを伸ばす施策を考えて欲しい」だった。なんて事も。この様に相手の事象に対して何が本当に解決したいことなのかを整理し、提示することが、与件整理の重要な役割です。
他にも与件の「〇〇してほしい」の中には様々な隠れた前提が潜んでおり、プロジェクト開始前にそれらを明らかにする必要があります。ここからは与件整理の具体的な方法について紹介していきます。
与件の確認・解釈
まずは相手からもらった与件を明文化します。明文化した与件を元に整理を行います。
今回はケースとして、以下を初回依頼内容として話を進めたいと思います。
「2ヶ月以内に、構想中のサービスの価値検証を行いたい」
「サービスとして成り立つかどうかを判断したい」
「期限は守りたいと思っている」
与件の意味のすり合わせ
まず行うのが意味のすり合わせです。明文化した状態でも、個々の解釈によって差分が生まれます。文章、単語単位で、解釈を揃えていきましょう。
- 構想中のサービス：
- どの段階まで決まっているのか、分かっているのか？（市場、競合、戦略、プロダクト方向性、プロダクト仕様）
- 構想中とのことでどの部分が未確定事項なのか
- 価値検証：
- サービスの肝となる機能は決まっているのか
- 機能に対する根拠付けはできているのか
- 肝となるサービスが価値があるかを検証するのか、それともどれくらい価値があるかを検証するのか
- 肝となる機能のみの体験検証か、機能含めたサービスとして成り立たせるまでの検証か
- 2ヶ月：
- これはどれくらいマストなのか
- コミュニケーション、クオリティー、調査範囲、何かしらを犠牲にしてでも守るべきものなのか
プロジェクト完了時の状態定義
今回はプロジェクト期間を2ヶ月と定めましたが、2ヶ月後のあるべき姿をすり合わせます。観点は大きく2つです。
- プロジェクトが完了した時、相手はどんな状態になっていれば良いか
- 何を持って成功と言えるのか（KPI定義）
プロジェクト完了後の想定ネクストアクション
プロジェクト完了後、得られた結果をどう使うのか、活用までをイメージしましょう。
「○%もニーズがあります」と言う検証結果を使って、部長会議で打診。正式にプロジェクトスタートを狙いに行く。
今回のケースだと、実は本活的な提案の根拠付けで使われるとわかりましたね！
想定するコミュニケーション
進め方はステークホルダーによって様々です。定期的にレポーティングを求める方もいれば、一緒に議論しながら意思決定するケースもあります。コミュニケーション方法をすり合わせ忘れると「頼んだことをやってくれてるかわからない」「勝手に決まって出てくる」など、コミュニケーションエラーに繋がります。進め方に関して、認識をすり合わせた上で対応しましょう。
以下のように、前提や制限事項を加味して明文化します。
今回は2ヶ月と言う短いスケジュールの中でサービスの価値がどの程度あるか検証する必要があります。週次定例で次のゴールを定めた上で、細かな進め方やアウトプットは現場判断で進めようと思います。
スコープと制限事項
ここが一番の難関になります。握りが甘いと、「当初イメージしていたものと違う」「思っていたよりアウトプットがいまいちだった」と期待値がずれます。
また、「これはやってくれるものだと思っていた」とスコープ範囲が膨らみ、想定よりも多く作業を行う必要も出てきてしまいます。
スコープと制限事項では、お互いの期待値が擦り合うまで細かく定義しましょう。ポイントとしてはスコープ外を定義することです。やりたいことベースだとあれもこれもと出てきがちですが、できないことベースで埋めていくとグレーゾーンが少なくなります。依頼者もやりたいことが出てきてもスコープの範囲内で会話をするようになります。
今回のケースだとこの様に定義していきます。
- 観点
- スケジュール
- コミュニケーション方法
- 調査範囲
- デザイン範囲
- 開発範囲
- スコープ
- メインの機能と付随機能を合わせたサービスとして最低限出せる状態を定義する
- 白黒ベースのワイヤーフレームに落とし込む
- ワイヤーフレームを元に、定義した内容がどれだけ市場にニーズがあるかを調査する
- スコープ外
- 具体的に機能をどう実現するのか、実現可能性は算出しない
- 機能の具体的な仕様、（ボタンを押した時の状態変化）は行わない
- ワイヤーフレームにレイアウトやビジュアルデザイン、アニメーションなどUIデザインは行わない
- 主要動線以外（途中キャンセルした場合）の考慮等は行わない
- 制限事項
- 2ヶ月という短期間なので、週次定例間のタスク遂行は現場主導で行う
- コミュニケーションをより密に取りながら進めたい場合は期間を伸ばす、調査範囲を絞らない限り難しい
決定事項を資料化し共有する
ここまでが与件整理のプロセスとなります。本当にやるべきことは何か、明確になりました。最後はこれらを資料化し、共有します。「あれどうしたっけ？」「こういったはずだけど」を防ぐためです。与件を明文化し固めます。
まとめ
今回は2ヶ月のプロジェクトをケースにしましたが、普段の業務内での些細な依頼にも当てはまります。「なぜその依頼をしてきたんだろう」を深ぼることで、本当に解決したい事を特定、提案できます。
日々の業務から与件整理を行い、プロジェクトを成功に導きましょう！
UXUIデザイン支援資料
セブンデックスのUXUIデザインプロセスと実績詳細が解説されている資料を無料でダウンロードできます。
