StockSun
品質ガイドライン

一次返信は3時間以内を目標とする。
遅くとも12時間以内には行う。

※確認事項がありどうしても時間を要する場合、「社内にて確認が必要な内容がございますので少々お時間を頂戴できれば幸いです。」などのフォローを顧客に伝えられるとベター。

一次返信時に、可能な限りにおいて調査を行うことを推奨。

顧客の属性や悩みに合わせた返信をする。
※問い合わせ文言内に質問がある場合、先に返答できるものは返答する。

会議方法、日程、会議のURLなどの情報があらかじめ書かれていない「顧客に手間がかかる返信」はすべてNG。
※候補日程は3つ以上を原則とする。

目標、現状の施策、課題感など基礎的な事項は文面でヒアリングする。

※回答例を記載しておくなど回答しやすい工夫を推奨。
※あらかじめ内部でヒアリングシートを作成しておくことを推奨。
※有意な提案のためには何よりも「目標感」を聞くことが重要。
※クライアントのリテラシーに合わせる前提で、文章ヒアリング時点ではTAM、PoD、ARR、MAU、ROAS、CPAなどの専門用語は使わない。

一次返信後3営業日経過で電話およびメール。

事前ヒアリングを基に、簡易調査を行う。

例）

• 自社状況：自社サイト状況、広告出稿状況、保有SNS、自社の強みなど
• 競合状況：エリア競合、サービス競合、広告競合、SEO競合など
• 市場情報：市場規模、業界のリーディングカンパニー、検索ボリューム、広告単価など

ミーティング前の調査で解消しておくべき疑問点が生じた場合、追加でヒアリングを推奨。

狙いは下記2点。
①事前に回答してもらえれば、提案の精度が上がる
②事前に回答してもらえずとも、質問を先出しすることで答えやすくしたい

ミーティング前にアジェンダを送付することを推奨。
※ミーティング設定時にアジェンダを示すのがベスト。

できれば議事録担当に同席してもらう。
ヒアリングに集中し、相手目線での即時提案に頭をフル回転させるため。

※議事録は、スプレッドシートの共有などで内部で同時閲覧できるようにしておくとよい。

冒頭に自己紹介をするとしても30秒ほどで簡潔に。
すでに自社のことを知っていただけている場合とそうでない場合では、説明内容が異なるため。

以下のヒアリングは必須

①問い合わせ経路・経緯
②現状の課題感
③目標・KPI
④BANT情報
　Budget（予算）
　Authority（決定権）
　Needs（必要性）
　Timeframe（導入時期）

※目標が明確な場合、予算を直接的に聞くことは非推奨。
※経緯の把握で顧客の興味関心やニーズを理解する目的。副次的にはマーケティングデータとして活用したい。

MTG内で提案可能な事項はその場で行う

※提案するに足る情報がそろっている場合はその場での提案を推奨
※その場の提案が不可の場合、「提案のために不足している事項」「検討するために必要不可欠な情報」を明確にしてネクストアクションを定義

よくある質問を先に伝達し安心材料を提供する。
先行して、資料に落とし込んでおくとよい。

例）

• 〇〇以外の領域も支援可能か？
• デザインの修正は何回でも可能か？
• 契約の形態は？
• 途中で解約可能か？

自社で対応不可能な事項や条件があれば先に伝達。
自社に発注することのデメリットについてもこちらから伝達。

例）サイト制作の場合
「設計含め制作全体」ではなく「制作工程のみ」をご依頼される場合、弊社ですと他社よりも若干単価が高いと思われます。というのも、弊社の強みが「マーケティングにも一定習熟しているディレクターをアサインする」という点なので、設計面に携われない場合はバリューを十分に発揮できない可能性があります。

MTG後の具体的な流れやそれに伴う確認事項をすり合わせ。

＃確認事項例

• コミュニケーションツール
• NDA
• 提案提出の方法
• 次回提案日程

＃流れ例

①NDA締結
②各種情報連携
③提案MTG
④申込・契約
⑤キックオフMTG

※特にNDA締結に時間がかかるケースがしばしば見受けられるため、締結が必要な場合は、誰が・いつ・どのように対応するのかをMTG内でクリアにしておくことが望ましい。

予算がどうしても捻出できない場合、代替案の提示で解消余地を探る。

• 業務スコープの調整
• 実施期間の調整
• 実施体制の調整

など。

ただし、提案の大前提として「自分が事業主だとしたらその外注をするのか？」という観点は必ず持つこと。
調整を行うことにより事業成長へのインパクトが著しく低下する場合は、必ず顧客に伝達する。

その場合、必要に応じて「他チームでの対応」を提案も視野に入れる。

相見積もり先の有無は必ず聞く。
具体的な社名も、可能であれば聞きたい。

※その後のマーケティングデータに活かすという点でも重要。

• ミーティングの議事録は、当日（遅くとも翌日）に送付
• ネクストアクションの明記は必須

• NDAや情報連携が必要な場合、議事録に沿って順次やり取り。
• 万が一提案日程を決められていない場合は、早急に提案送付目途と、MTG日程の確定を行う。

• 提案準備中に新規で質問が発生した場合、提案MTGを待たずに質問する。

提案に際して、自社ならではの「お土産」を持っていけるとGood。
顧客の事業や担当者に役立つ情報であればOK。

期日に余裕がある場合は、チーム内メンバーでもよいのでレビューを挟むこと。
レビューを挟むのと挟まないのでは、提案の深さに雲泥の差が生まれる。

以下5点の記載は必須。

①目標に対する勝ち筋
②直近の課題解決案
③中長期の施策イメージ
④スケジュール
⑤予算

※提案施策が上手くいかなかった場合の「代替案」も、例外的な事情がない限りは記載することを推奨。
※事業進行を脅かすリスクが想定される場合は、事前に解決方針を明示しておく。

なお、予算規模が大きい場合は、以下12点を提案に含めることを推奨。

①エグゼクティブサマリー
②与件整理
③As is To be
④直近の課題解決案
⑤中長期の施策イメージ
⑥ベンチマークとなる競合（評価も添えると尚良し）
⑦定量目標
⑧スケジュール
⑨予算（項目は極力細分化し、松竹梅でパターン分けする）
⑩会社紹介または自己紹介
⑪体制図
⑫業界や業態が類似した実績

提案のミーティングは必須。
不明点や疑問点の解消、温度感をお伝えするためにも口頭で説明すること。

※MTGでは決裁時期を必ず確認。
※MTGで解決できなかった疑問点は、引き続きネクストアクションに落とし込み、議事録にて当日内に共有する。

事前に確認していた決裁時期を過ぎても連絡がない場合は、基本的にはリマインドを入れてOK。

依頼意向を受け取った際は、丁寧にお礼メールを返信。
当該メールにて、「ネクストの案内」「理由のヒアリング」も同時に行う。

「契約周り」「キックオフMTGの日程」の2点を案内する。

※可能であれば「キックオフまでの準備物」「キックオフのアジェンダ」も案内する。

弊社に決めていただけた理由についてヒアリングする。

• なぜ選定いただけたか
• もっとも期待している点
• 他社と悩んだ点
• 他社のほうが優れていると思った点

などを聞けるとよい。

失注理由は必ずヒアリングすること。

• なにが決め手となったか
• どこに改善余地があると感じたか
• 評価してもよかった点はなにか
• （もしまだ聞けていない場合）依頼先はどういった会社様か

などについて聞けるとよい。

• 補助金助成金の関係、社内事情の関係などから時期未定となることがあるが、その場合も必ずネクストアクションは決めておく。
• 顧客も具体的な日程イメージが湧かない場合、こちらから「1か月後にご挨拶させていただきます」などの連絡宣言をしておくことを推奨。

信頼性を担保するための情報を掲載する。

＃会社としての信頼度に関わる例
売上、資本金、設立年数、設立経緯、MVV、オフィス、顔出ししている関係者


＃内部体制の信頼度に関わる例
採用フロー、体制図、経理や法務のルール

ターゲットユーザーに合わせてサービス紹介資料を作成するとよいが、注意すべきは、無意味な資料を作らないこと。

広告配信で使う資料なのか、インバウンド問い合わせ後の説明補足資料として使うのか、稟議での検討材料として使うのかなど、必要性に応じた資料作成が望ましい。

例（弊社の定額制Webマーケティングサービス）※広告配信用

サービス紹介資料と同じく、意味が希薄化する資料には注意しつつ作成。

ソリューションごとなのか、業界ごとなのか、会社としての全体的な実績なのか…など、用途によって参考にすべき実績は異なるため、必要に応じた資料作成が望ましい。

経歴、人柄や思考回路がわかる簡単な資料やWebページ等を用意する

※特にコンサルティングは属人性が高いため、パーソナリティも一定程度意思決定に関係しうる。
※取材やセミナーでの発信内容を簡単にまとめておくなども有効。

例（認定パートナー資料、認定パートナー紹介ページ）

個人名での検索結果についても定期的にチェックすること。
主には、Google、Yahoo、Twitter。
クライアント目線で、発注したくなる情報が検索結果に表出しているかどうかを確認。

自社が「業界でどれくらいのレベル感なのか」を知るための仕組みを持つ。

＃知りたい情報の例

• 業界No1の企業がどこか
• その企業がどのような価格感で、どんな役務を提供しているか
• 相見積もりの対象となることが多い会社
• 相見積もりの結果、「なぜ自社が選ばれたのか」「なぜ他社が選ばれたのか」

自分が属している業界の相場を把握する。
そのうえで、適切な価格がつけられているかをチェックする。

※希少価値が高い役務については価格が相場に対して高くとも問題ない。

競合の提供役務の内容を知る。
直近勢いのある企業については情報を把握しておく。

同業他社の知り合いと不定期でも交流する機会を持つ。

契約開始日から即実行開始できるように段取りをすること。

たとえば、「契約開始→キックオフMTG→Todo決め→数日準備→実行スタート」のような形は言語道断。

キックオフMTGは、目的の再確認、メンバー顔合わせなど重大な意味を持つほかメリハリを持たせる意味も持つため、必ず実施すること。

キックオフMTGでは、再度目的やスコープを整理のうえ伝達する。

たとえば新規事業の場合で「撤退ライン」を予め決めてある場合などには、キックオフMTGで再確認し、目標をクリアするための道程を逆算思考ですり合わせることが重要。

顧客含め、プロジェクトを進行するメンバーと各人の役割を確認する。

可能な限り、チームメンバー全員がキックオフMTGに参加すること。
発注者の安心感がまったく異なるため。

※ただし、「無駄に人数が多く見えない必要十分な人数」という点は大前提。各人の役割を透明化する。

スケジュール、マイルストーンは必ず共有し、すり合わせをする。

たとえばLP制作において、サービスのローンチ日が決まっており、PR施策やオフライン施策とも連動しているような場合、制作の期日を遅らせることは100%できない。そういったクライアント特有の事情を再度確認したうえで、マイルストーンをすり合わせのうえ決めていく必要がある。

誤った期待が生まれないように、前提確認をこの時点で再度行う。
また、前提が崩れる可能性が少なからず予見できるような場合は、バックアッププランの確認も行っておけるとbetter。

タスク管理や遂行の方法をあらかじめ顧客と共有しておくことを推奨。

例）

• 大枠のスケジュールはWBSを使って管理
• MTG内で出たアイデアは〇〇のシートに格納
• 週次報告にて、優先度の高いタスクはチャットで報告し、優先度の低いタスクはスプレッドシートで一覧化して報告

レポーティングの内容や頻度を決めておく。
どんな業務でも、定例報告または定例MTGを必ず設置することは極めて重要。
（たとえ月1でもよいので定例化する）

もしMTGが難しい場合は、必ず週に1度などで頻度を決めて定例の報告をすること。

コンサルティングの場合、1週間で「5往復」は最低でもコミュニケーションを取ること。

• 週に1度の定例報告とそれに付随するやり取り
• 細かな気づきや質問事項

をしていれば、5往復を割ることはほとんどないはず。
それを下回る場合、報連相の頻度が著しく少ないという自覚を持つ。

悪い知らせほど、丁寧に・早く・誠実に報告すること。
伝えづらい気持ちは十分にわかるが、悪い事象は時間が経てばたつほど事態は悪化するのみ。とにかく早く報告し、現実的な対処を講じることに頭を使うのが重要。

良い結果でも悪い結果でも、クライアントよりも先に気づく。
そして、クライアントよりも喜び、悔しがる。

施策を推進していく際には、常に「2の矢」「3の矢」を考慮すること。
1つ目の施策が外れた場合に打ち手がなくなるような事態を避ける。

また、可能であれば「奥の手」も持っておくこと。
奥の手は、通常は行わないような手段ではあるが、目標達成のために採る選択肢のことを指す。

例）BtoBマーケティングの流入獲得方法
１：YouTube動画で流入を得る
２：SEOで流入を得る
３：広告で流入を得る
奥：地道にメール営業をする

案件進行中において、目的達成のために必要な手段については積極的に追加提案を行うこと。
最適な施策が状況に応じて変化するのは当たり前。

なにかしらのエラーが起きてしまった場合、まず第一に顧客に報告。
そのうえで、被害最小化→復旧→再発防止の順に対策を講じる。

被害が最小化するための行動をとる。

例）

• インフルエンサーに頼んで拡散してもらったURLがなぜか閲覧不能

→一時的にでもリダイレクト処理をして機能するURLに遷移させる

• アクセスが多すぎてサイトがダウンした

→一時的にお金をかけてでもサーバー容量を大きくする

復旧のための手段を講じるとともに、被害の大きさも算定する。
被害の最小化のために一時的に取ったアクションが不要なものとなった場合は、完全に復旧する。

属人性が高い方法や、実施確認ができない不明瞭な方法はNG。
誰もが判別可能なルールを以て、再発防止策とすること。

施策の振り返りを行う。
事前の目標設定と実際の成果を比較しながら、定量的な観点と定性的な観点から行う。

解析アカウント情報、各種使用ツールや管理画面の情報、Webサイト周りの環境情報など、必要な申し送り事項をまとめて共有する。

顧客より「良かった点」「改善を期待する点」についてフィードバックを頂戴する。

サイト制作の納品のMTGなどの場合、その後の運用やマーケティングについての追加提案を行う。

もし何かしら満足いただけずに契約打ち切りの場合、上記の4点に加え、挽回の方法を探る。

1~3か月後を目安に、再度コミュニケーションを取る。
顧客にとって有益な情報を持ち寄ることを推奨。

例）

• 外部ツールなどを用いて顧客の分析をし、提案をする
• 最新情報や業界情報を提供する
• 上手くいった類似事例を共有する…etc

「1時間は遅め」「3時間を超えると大分遅い」という感覚を当たり前にする。

※どうしてもすぐに有意な連絡を返せない場合は、取り急ぎの「返信目途」を伝える連絡をするだけでよい。

NG例	OK例
※取り急ぎの返信もせず、数時間無視

• 原則として、クライアントとの会話のラリーは最後が自分で終わるようにする。
• リアクションでの返信はNG（特に通知がないプラットフォームでは原則NG）

NG例	OK例

• 質問や確認を断続的に何度も行わない。できる限りまとめて行う。
• 返信不要な連絡については、「返信不要」の旨を記載する。
• 調べればすぐにわかることを質問しない。

OK例

報告・連絡・相談を行う時間やタイミングに関して、相手の状況に配慮する。

例）

• 確認依頼を、土日や連休、あるいは終業時間の「直前」ではなく、余裕を持って確認できるようにする。

顧客とのビジネスコミュニケーションでは、抽象的な表現はできる限り使わないこと。

NG例	OK例

すべてのコミュニケーションにおいて事実と解釈は必ず切り分けること。

NG例	OK例

何かしらのタスクの依頼を受けた際は、必ず期限をつけて返答すること。
もし期限をつけられないものについては、「期限をつける期限」の目安を伝えること。

NG例	OK例

何かしらのタスク依頼を受けた際に、そのタスクの定義や意図、進め方がピンと来ていない際は、返答にてすり合わせをする。不明なまま安易に進めない。

NG例	OK例

タスクの遅延については、遅延しそうなことが判明した時点ですぐに連絡すること。
また、どのくらい遅延するかの目途についてもあわせて通達。

事後連絡は絶対NG。

NG例	OK例

チャットでのビジネスコミュニケーションを取る場合、オープンクエスチョンは相手に返信の手間がかかるため原則NG。
YESかNOで答えられるクローズドクエスチョンを基本とすること。

NG例	OK例

依頼時、受け手が結局何をすればよいのかどうかが明確にする。

※長文で理由を述べたあとに依頼事項を記載するのは、相手への配慮にはならないことが多い。まず結論、次いで理由を述べる構成を原則とすること。
※もちろん相手との関係性や状況次第ではあることは大前提。

確認依頼を行う際は、なるべく相手の手間がかからないように配慮する。

例）

• 該当URLを記載する
• 該当箇所のスクリーンショットを添える
• どのような観点から何を確認してほしいのか伝える

NG例	OK例

• コピー＆ペーストが想定されるコミュニケーションの場合に、コピペをしやすいように連絡する。
• 顧客のスマホでのやりとり頻度が高い場合に、「スプレッドシートのみを送らない」「zipを送らない」などの配慮を行う。

例）

• MessengerでURLとIDとPASSを送る際に、一つずつメッセージを切り分けて送る
  ※スマホの場合メッセージ内の特定箇所を選択してコピーすることができないため
• LINEでファイルを送る場合に、有効期限切れを防ぐためにGoogleドライブの共有リンクを送る

電話での言った言わない問題は、あるある。
電話でコミュニケーションを取る場合、必ず電話が終わったあとに決定事項を文面で送ること。

ビジネスコミュニケーションでは、個別チャットは原則使わない。
第三者に見える場所でコミュニケーションを取る方が効率的。

ただし、

• 秘匿性が相応高いやり取りを行う場合
• 見え方への配慮が必要な場合
• グループチャットでは返信が来ない

など特殊なケースは除く。

Google系をはじめとするツールに関し、閲覧権限を確認したうえで共有する
※秘匿性が高い共有物は「全員への閲覧権限付与」はNG

どんなときでも相手に敬意を持って接する。

時には感情的になってしまうことがあるのは仕方がない。
その場合は背景やその時の事情など相手のストーリーに目を向ける。
理解をするためのコミュニケーションを取ったうえで、冷静に打開策を探す。

タスク管理が不十分だと顧客に不満を抱かれやすい。
顧客から下記文言を尋ねられるのはイエローカードだと認識すべき。

・「完了予定はいつになりますでしょうか？」
・「その後の進捗はいかがでしょうか？」

タスク管理、ネクストアクションが曖昧なため、満足されていない可能性が高い。

漏れがないよう、自分の中でタスクの分類をする。

下記は一例。

①タスクにすらならないタスク
　→すぐに終わらせる
②数分～数時間で終わる、単純タスク
　→カレンダーを即押さえる or すぐに第三者に依頼
③数日を必要とする、単純タスク
　→着手時間と報告時間を取り急ぎカレンダーに記載 or すぐに第三者に依頼
④数分～数時間で終わる、知識集約系タスク
　→カレンダーを即押さえる
⑤数日を必要とする、知識集約系タスク
　→着手時間と報告時間を取り急ぎカレンダーに記載
　→切り分けができないか考えてみる
⑥突発タスク
　→これにより期日に遅れそうな「玉突き遅延タスク」が発生しそうな場合、すぐに連絡

5分以内に終わるようなタスクは、すぐに完遂する。

例）
・簡単なレスポンス
・スケジュールの確認や打診
・第三者への簡単な業務の依頼
・すぐに終わる確認業務

抽象的なタスクは、完了までのステップを逆算して切り分けること。
そのうえで、切り分けた小タスクごとに期日を設定する。

※自分が新しく取り組む業務の場合は、20%ずつのイメージでタスクを切り分け、報告も行うのがbetter。

OK例

月末までに競合企業の調査をしておいてほしい。
↓
承知いたしました！
25日に一度完成状態で報告させていただきます。

NG例

“月末までに競合企業の調査をしておいてほしい。
↓
承知いたしました！

下記のスケジュールで、順に報告させていただきます。
～5日：調査項目の定義、競合企業の社数をざっくり把握
～15日：10社分、調査項目を埋める
～25日：全社分、調査項目を埋める
以降：修正期間＋追加したい会社が出てきた場合の予備期間

＃過去に実施経験がなく、すぐに期日目安がわからない場合
・工数見積もりまでの期日を依頼者に報告する
　※楽観と悲観の幅を持たせて依頼者に伝えるのがbetter
・量が多く、工数見積もりに時間がかかりそうな場合は、まず全体の10％程度になるべく早く着手。そのうえで概算期日を依頼者に伝える
・自身の知識で解決できない場合は、有識者へアポイントを取りキャッチアップする
　→タスクの目的、責任範囲、期日を明確に伝え、概要の手順やキャッチアップの手段を確認する

＃変数が多すぎて見積もりができない場合
・タスクを最小粒度に分解し、すべて書き出す
・最小粒度のタスクの楽観的工数、悲観的工数を書き出す
・上記をもとに依頼者へ期日の相談を行い、タスクの切りだしや、納期の調整等ができないか模索する

NG例

「Webサイトの改善をお願いできますか？」
↓
「かしこまりました。」

OK例

「Webサイトの改善をお願いできますか？」
↓
「かしこまりました。Webサイトの改修工数の見積もりに時間がかかりそうなため、●●時までにご連絡差し上げます。
概算ですが、早いと3日後の●●日●●時、遅くとも5日後の●●日●●時までに対応が可能だと思います。

原則としてすべてのタスクには期日を付すこと。
最悪、目安でもOK。

また、「本日中」「週明け」などの言葉を自分に都合よい定義で勝手に定義しないこと。

原則として、3営業日を自動的な期日設定ルールとし、自ら依頼者に対して期日宣言を行う。

また、3営業日で完了しないボリュームの場合は、タスク自体をフェーズで切り分け、それぞれの期日を依頼者に伝える。

NG例

「このタスクを進めてほしい」

「かしこまりました。すぐに着手いたします。」

※
期日設定が不明瞭なままタスク進行すると、依頼者の時間感覚が期日となるため依頼者、受託者ともにストレスがかかりやすい状態になる。（依頼者があれどうなってたっけ？という状態になる）

OK例

「このタスクを進めてほしい」

「かしこまりました。すぐに着手いたしますが3日後の●●日●●時を期日の目安といたします。」

or

「かしこまりました。すぐに着手いたしますが、少々工数がかかりそうなので、▲までを3日後の●●日●●時を期日に、★までを5日後の●●日●●時を期日目安に進行してまいります。」

前提として、先方が期日を守れず、PJTが後手に回る場合も自身のスケジュール管理に非があると考える。

先方に期日内で対応が可能かリマインドを行う。
先方の連絡が遅い場合は、電話もしくはショートMTGを定期的に組み、スケジュールが遅れないように管理する。

納期が間に合わないと判明した場合は以下の対応を行う。
遅延の事後連絡をした場合は、2度とその依頼者とは取引ができないと思うこと。

・まずは、納期に間に合わせるためにあらゆる手段を模索すること
　※実施タスクをカテゴライズし、想定の工数を書き出し、第三者に依頼するなど
・納期が間に合わないことが予期できた場合、依頼者に真っ先に連絡すること
　※調整後の納期もわかれば合わせて伝える
・手を尽くしても変わらない場合は、依頼されたタスクをさらに分解して段階的に納品をする

※なお、納期を間に合わせるために追加で発生する原価によって利益がなくなっても、納期を間に合わせることの方が重要であると認識する。目先の利益よりも中長期的な信頼貯金の方がビジネスにおける重要度は高い。

原則として、相手の確認・検収があってはじめて完了となるため、報告を以て「完了した」と勘違いしない。

タスクを行う際は、目的を必ず把握すること。
自信がない場合は相手に確認を取る。

目的を知ることで「絶対に遅れてはいけないかどうか」「次に生まれるタスクの有無」などが分かり、優先度の齟齬が生まれにくくなる。

自分のタスクの範囲を具体的に確認したうえで実行に移すこと。

NG例

期日は指定の●●日●●時までに行います。30％程度まで進捗しましたら中間報告をしますが、現状で認識の齟齬がある場合はご教示ください！

※タスクの責任範囲と納品イメージはセットで確認をしないと、認識齟齬が起きてプロジェクト遅延につながる可能性が高い

OK例

今回のタスクでは、以下の納品イメージで作業を進めます。
〜URL入る〜

期日は指定の●●日●●時までに行います。
30％程度まで進捗しましたら中間報告をしますが、現状で認識の齟齬がある場合はご教示ください。
（認識齟齬がない場合は、スタンプ等で反応いただけますと助かります）

なお、●●〜●●については別のご担当がスコープと認識しておりますので、そちらも認識齟齬がないかご確認をお願いします。

前提として、マルチタスクに仕事をすることはできず、常にシングルタスクでしかタスクは完了することはできない。

その上で、

・タスクの整理
　→他者に依頼する内容か、自分で作業する内容かを整理する

・他者に依頼するタスク
　→まず一番初めに他者への依頼をすべてやり切る

・自分が作業する内容
　→他者と依存関係があるタスクを先に完了させ、最後に他者に依存しないタスクを完了する

①タスクとともに背景や目的も伝達すること
②範囲と期日（と報酬）を合意すること
③できればサンプルを共有すること

NG例

A社の件について、対応お願いします。

OK例

A社の件について、対応お願いします。

■目的・背景
・目的：
・背景：

■ご依頼内容
・
・
・希望期日はX/Xです

■補足
アウトプットのサンプルは下記です。
XXXXXXXXXXXXXXXXXXXXX

他者にタスクを依頼したときの管理方法は下記が考えられる。
（特に中長期タスクの場合）

①定例報告
②スプレッドシートなどでステータス管理
③「リマインドする」というタスクを自分のタスクとして受け持つ

※なお、次回以降の期日遅れの予防を目的に、他者に設定した期日が1分でも遅れた場合は必ずリマインドをする。

依頼者から特段の指示がない限り、3日に1回は進捗を中間報告する。
（最低でも週に1度はマストで報告を入れること）

その際に、懸念点の有無等、ネガティブな報告は早めに行うようにする。