オリエンシートの書き方｜課題・対象者・予算をまとめる依頼概要の記入例

「動画を作ってほしい」「サイトを新しくしたい」という依頼だけでは、何を解決する制作なのかが伝わりません。オリエンシートは、目的、対象者、課題、条件をそろえ、受け手が必要な質問や解決案を出せるようにする依頼概要です。細かな仕様を先に埋めるより、事実と仮説を分け、決まっていることと提案してほしいことを明確にします。

オリエンシートの役割とRFP・要件定義との違い

オリエンシートの役割は、依頼の出発点を共有することです。誰に、どんな変化を起こしたいのか、その背景、制約、今回頼む仕事を伝えます。複数候補へ正式に提案を募って比較する条件はRFPへ、動作や納品の合格基準は要件一覧へつなぎます。概要だけで契約や検収の条件がすべて決まるわけではありません。

最初の依頼は動画という手段が固定されています。二つ目は解きたい問題から考える余地があります。ただし動画が必須である理由が実際にあるなら、その条件を隠す必要はありません。配信先や既存契約などの理由を書いたうえで、表現方法を提案してもらいます。

一枚に収めること自体を目的にせず、概要は判断しやすく短く、必要な証拠は別添に分けます。対象者の情報が足りないのに仕様を細かく書くより、何を調べてから方向を決めるかを残す方が、受け手は計画を立てやすくなります。

事実・顧客課題・仮説・期待する変化を分ける

事実は観察や記録に基づく内容、課題は対象者が困っていること、仮説は原因や解決案の推測、目標は将来の期待です。たとえば「資料請求が30件」は集計の定義を持つ事実、「説明が難しいから少ない」は仮説です。この二つを一つの文にすると、原因を確かめずに制作方法が決まってしまいます。

対象者を「すべての企業」とせず、業務、立場、利用場面、判断に必要な情報へ具体化します。まだ調査していない対象像は仮置きと記載します。属性だけで困りごとを決め付けず、ヒアリングや営業現場の質問など、確かめる方法を添えてください。

目標は期間、基準、定義をそろえます。問い合わせの目標を置くなら、有効な問い合わせとは何か、迷惑送信や同じ企業の複数送信をどう数えるかを定義します。達成したい数を、すでに得られた実績や制作による保証として書かないことが大切です。

目的、対象者の情報、制約、測定を整理する参考として、英国政府のコミュニケーション標準GovS 011があります。伝達手段を先に固定せず目的に沿って検討する考え方を参照できますが、日本の案件へ特定の手段や成果数値を義務付けるものではありません。

架空案件で読む一枚の依頼概要の記入例

以下は架空の法人向けサービスの依頼概要です。企業像、件数、金額、担当は例示用であり、実在するサービスの実績や相場ではありません。最初の説明に使い、根拠や詳細は別添資料で補います。

「LPの案2方向」は、両方を実装することとは異なります。どこで一つの方向へ絞るか、誰が判断するかを確認します。目標の40件も、提出した制作案だけで保証できません。対象者の反応、集客、サービスの条件などを見て、検証と改善を続ける前提にします。

記入できない欄には「未確定」と置き、決定者と必要な調査を付けます。仮説を事実として埋めてしまうと、後から変更理由が見えなくなります。根拠となるヒアリングの日時や対象範囲も、必要に応じて別添へ残してください。

予算・対象範囲・対象外・支給物をそろえる

総予算は、制作物の費用と媒体などの実施費用を分けます。架空の配分は600,000 + 500,000 + 100,000 = 1,200,000円、すべて税抜です。予算配分を示しても、各項目をその金額で調達できる保証にはなりません。見積を受けた後に範囲と配分を調整します。

原稿や画像の支給は、所有していることと、外部へ渡して指定用途で使えることを区別します。守秘契約があるだけで、顧客データや第三者の資料を何でも共有できるわけではありません。必要な情報だけに絞り、匿名化、利用権、共有先、保管方法を確認します。

納期は初稿提出だけでなく、説明会、発注側の回答、方向決定、修正、最終確認を含めます。依頼側に決める時間がない場合は、その制約を隠さず伝えます。手段の比較を頼みながら、公開日や予算が動かせないなら、比較できる余地も明示してください。

説明会の質問と変更履歴を承認する

説明会では、受け手が質問できる時間を設けます。「読めば分かるはず」と扱わず、誤解された箇所を概要の改善へ使います。質問への回答が依頼条件を変えるなら、本文の版と変更記録へ反映し、関係者へ同じ情報を渡します。

変更記録は、日付、理由、対象、影響、判断結果、版を残します。「話したから伝わった」とせず、改訂した概要と次の担当をそろえます。複数候補へ依頼している場合は、共通条件を公平に共有しつつ、各社の機密情報を混ぜないようにします。

追加要望の受付と実施承認は分けます。良いアイデアでも、予算、納期、品質確認へ影響があれば、承認者がその条件を判断します。変更をすべて拒むためではなく、何を採用した結果、何を調整するかを共有するための記録です。

配布前に判断できる依頼になっているか確認する

配布前には、対象者、課題の証拠、期待する変化、提案の余地、予算、範囲、支給物、判断者を読み直します。受け手が「何を提案すべきか」「何を質問すべきか」「何を含めないか」を説明できる状態が目標です。形式を整えるだけで、良い提案が保証されるわけではありません。

具体的な手段を指定している箇所には、指定理由を置きます。目標には基準と期間、仮説には検証方法、未確定には担当と期限を付けます。制作担当と事業担当が別なら、両者の確認をそろえてから説明します。

依頼後は、合意した方向を制作工程へ渡し、公開予定やレビュー日を共有します。まず一件の依頼で、既存の「欲しい制作物」を「対象者の課題と期待する行動」へ書き直してみてください。手段が必要な理由まで説明できると、受け手が判断できる概要になります。

次の作業に合わせて、RFPの書き方｜必須条件・評価表までそろえる提案依頼書の記入例、コンテンツカレンダーの作り方｜公開予定・レビュー・更新を管理する記入例、制作進行管理のやり方｜工程・次の担当・滞留日数を追う管理表を参照してください。