この1年、広報業務を勉強しつつの手探りでやってきて、PMとの共通点が多いと感じることがたくさん。

と、いうことで書いてみました！

あくまで私がやっているプロジェクトマネジメントをかいつまんでいるだけなので、会社やプロダクトによっては全く違うかもしれません。
（ディレクションやサービス管理に近いかも）
広報業務を円滑に回す参考になれば幸いです！

細かくやって損はない！要件定義

プロジェクトの最初の最初に行う、肝心要の要件定義。ここで握った内容が実際のコストや納期に跳ね返ってきます。
システム開発の会社などは、要件定義だけで費用請求をすることもあるくらい、要件定義は重要なタスク。

しっかり要望や目的をヒアリングして仕様を確定することで、Too muchで使いづらい、他ツールに埋もれて使われない、などがないようにします。

ここは本当にしっかりやっておかないと、開発途中で仕様の変更・追加の要望などが出た時に追加費用の請求ができなかったり、開発日程が延びたり、メンバーの追加アサインが発生したり…と両社にとって良いことがありません。
炎上プロジェクトに発展する可能性も。
（要件定義をしっかりしたにも関わらず、開発途中で仕様変更が相次いで構築が3ヶ月から半年に延びたことが2度ほど…）

構築から運用まで軸がブレないようにするためにも要件定義は本当に重要。
QCD（Quality・Cost・Delivery）のバランスや優先順位が整っているプロジェクトは、要件定義がほぼ完璧にできていると言っても過言ではない。

要件定義はQCDのQ（Quality＝品質）に関わる部分。

※QCDについては、TAKKさんのnoteをどうぞ。QCDも広報と通じる部分が多いですよ。

少々熱く語りましたが、私がこれまで、チャットボットの案件でどんなことを重視して要件定義をしているかというと、こんな感じ。

これを広報業務に置き換えると、

ね？大事でしょ？とっっっっっても大事でしょ？
会社のブランドイメージやMVVをブレさせずに情報発信をすることは、広報の基礎中の基礎。
プレスリリースや記事の企画〜公開、メディアリレーションなどを、常にこういった考えで行っている方も多いはず。
あなたがやっていることは、広報業務における立派な要件定義です！

この要件定義がちゃんとできていないと、情報発信をしたところで
「こんな記事、よく出したね…」
「これってプレスリリースじゃなくない…？」
「ただのお知らせじゃん」
となるものが世の中に出て行ってしまうことに。

まぁ…広報業務はプロジェクトと違って、社内では経営層と握るべきものが多い上に、関わる社外の相手が見えないから、そう簡単ではありませんがね…

赤字プロジェクトは厳禁！なコスト管理

要件が確定したら、コストの算出。QCDのC（Cost＝費用）です。

会社によって違いはあれど、実際に作業をする制作部門や、クライアントと相対するCS部門などが、メンバーの工数や原価を管理をしているケースが多いと思います。
が、PMは基本的に自分が抱えるプロジェクトの全工数とかかるコストは把握するのが当たり前。

プロジェクトでは

などが主なコストになってきます。

広報業務に置き換えると

といったところでしょうか。

もちろん、見積もりよりも工数やコストが低いに超したことはありません。
広報業務は利益に直結するわけではないので、余計に工数やコストを見られてしまうので、決まっているものはパターン別でコスト算出しておくとベスト！
コストセンターと見られないように、なぜそれだけの工数やコスト、ツール導入が必要なのか理由もしっかり説明できるように準備をしておくと、次年度の予算取りもしやすくなります。

各タスクの進捗が見えるスケジュール管理

QCDのD（Delivery＝納期）に当たる部分。
リリース日から逆算して、工数から作業日数を算出した後に、各タスクを誰が担当してどのくらい日数をかけるか細かくスケジューリングします。

スケジュールやステータスの管理には「WBS」と呼ばれる、ガントチャート形式のスケジュール表を使います。
進捗管理もWBSで行うことが多いです。

クライアントから短納期を希望されたら、交渉して無理のないスケジュールを引いていきます。
どうしても短納期での納品がとなる特殊な場合は、特別料金を請求してリソース追加をしたり、各タスクで起こる確認の日数を短縮させたり、念のために引いておいたバッファをなくしたりすることも。

WBSはとっても便利なので、使ったことがない方はぜひ使ってみてほしい！

例えば、オウンドメディアに掲載する事例記事の場合

のようなタスクが発生しますよね。
「ここまでに公開したい！」という予定を決めたら、各タスクをリスト化して、開始日と終了日をそれぞれ埋めていきましょう。
それによって、アウトプットを出すまでのリードタイムが見えてくるので、事例交渉などもしやすくなるし、自分がどのくらいで作業をすれば良いのかも見えやすくなる！

ここで重要なのが『バッファ』です。
各タスクに対して、ぴったりのスケジュールを引くのではなく、余裕を持って1～3日くらい長めが理想的。
どこかで遅れて別タスクの作業日数を短縮しても、十分に確認時間が取れる＆公開日に間に合うことを考えて、余裕を持ったスケジュール設定がポイント。

クライアント側の広報確認期間やライターさんの執筆日数などは、予め確認してから引くとより変更が少ないスケジュールができますよ。

ちなみに、私は管理用に作成した、リリース・イベント一覧のスプレッドシートに「事例記事」「採用広報関連」と別シートで2つのWBSを作って、取材対象の案件や社員別にスケジュールを組んでいます。
実際のものをチラッと。

一般に公開されているテンプレートは大規模開発で使うようなびっしりタスクが詰まったWBSですが、広報で自分しか関わらない場合はこのくらいざっくりしたものでOK！
案件が増えるごとにコピペして下に増やしていくと、傾向が見えてくるので短縮できるところが分かったり、どこが遅れるとかここでツッコミが入りがち…というクリティカルパスも明確に。
そして次のアウトプットを出すときに対策ができる。
公開されているテンプレートをうまくカスタマイズして自分が管理しやすいWBSを作りましょう。

スケジュール変更は、想定で入れた日程を変更するだけ。
「どこを削れば最小限の遅延で記事を出せるか？」が見えて調整も楽ちん。

ライターさんに執筆を依頼している場合は、WBSを共有すれば、スケジュール相談もスムーズです！
「間に合わない場合は遅くても前日までに連絡ください」と伝えておけば、大幅な遅延を防げます。
（期日が近くなったらリマインドしてあげると、なおGoodです！）

詳しい使い方とテンプレートはこちらが参考になりますよ♪

適切なメンバーのアサイン管理

要件とスケジュールが決まったら、メンバーのアサイン。
スケジュールを引いた期間、リソースが確保できてプロジェクトに適切なメンバーの選定、アサインを行います。

各部門の上司たちが相談してアサインするケース、PMがメンバー選定とアサインをするケース、制作部門のリーダーなどが行うケース…と様々あると思います。
が、広報業務を管理するのは広報担当者！
そう、あなたは広報業務においては、PMなのです。

例えば、取材依頼が来た時は、

など、世の中に記事が出た時のことを想像して、アサインを考えますよね。

私は、取材対象の部門名や案件名に加えて、数名候補者を出して、業務状況や適正に合わせて、その部門のリーダーや上長に判断・アサインしてもらっています。
「顔出しでの取材はちょっと…」という方もいると思うので、全社員の取材OK/NGを記載したリストを作ると便利です！

メンバーが決まらない、テーマが多岐にわたる、業界的な話が飛んできそう…なんてときは、社長がいちばんですけどね！

何も起こらないことを祈りながらのリスクマネジメント

リスクマネジメントは全ての役割で必要なことではありますが…いわゆる危機管理広報のひとつです。

考えうるリスクを想定しているとキリがないし、気が遠くなる…でも準備をしておいて損はない！

構築プロジェクトで起こりうるリスクは

実際に経験してきて、起こる事件はこんなもんじゃないけど…（遠い目）

運用中のプロジェクトで起こりうるリスクは

実際に経験してきたけど、こんなもんじゃ以下略…（遠い目）

これを広報に置き換えると…

など、考えただけでぴえん🥺ってなるよね。

こんなことが起きた場合の連絡先、レポートライン、対処方法を予め考えておくと少し冷静に対処できます。
特に情報解禁に支障が出る場合や、ツールの障害が起こって公開している情報が消えるといったトラブルに備えて、緊急時のフローや連絡先のリスト、やることリストは絶対に作っておいたほうが良いです。
（私もやらねば…）

あとは何も起こらないことをひたすら祈る！！！！！

起きてしまった時のクリティカルマネジメント

どんなに気をつけても起こるのがミスや障害。
起こってしまったら影響範囲や発生時間を最小限にする必要があります。

不具合やシステム障害などの対処方法を事前にフロー化していますが、冷静にフロー通りに動くのはなかなか難しいのが現実。
それでも可能な限り迅速に冷静に、報告～復旧までの対応をしなくてはいけません

例えば、障害発生フローならこんな感じ。

かなりざっくりした内容ですが、実際に障害が起こると
・技術部は深夜でも飛び起きて対応
・案件担当メンバーは影響範囲の確認や現象確認をして社内報告
・運用管理チームがお客様へ一斉連絡
などがほぼ同時に動くので、非常にカオス。
SlackやらメールやらLINEやら、あらゆる連絡手段の通知がしばらく止まりません。

（元旦深夜にインフルエンザで救急搬送され、次の日に退院した途端に障害発生したときは本当にクラクラしたなぁ…クライアントへの連絡は他の方に対応してもらったけど…）

障害対応の流れはこちらのサイトがとってもわかりやすかったので、気になる方はご参考までにどうぞ。

広報業務で思わぬ事故が起きてしまった場合を考えると、

は最低限必須になります。

広報業務での事故は情報が出回ってしまうので、システム障害以上の損害や影響範囲が出る可能性がとっても高いです。
特にプレスリリースの配信ツールを使っている場合は、何か起こった場合にメディア転載で数十件のメディアに転載されてしまうことも。

時間が経てば経つほど情報は広がっていくのがネット社会の怖いところ。

起きてしまったら、とにかく早く動く！時間勝負！
報告内容は正確かつ時系列で！
エビデンスはテキストでちゃんと残す。
電話でやり取りした後はメモを相手に送る！
テンパらずに冷静に。

PMで障害や不具合対応をしてきて、広報になってからも日々メンバーの障害対応の様子を見ていた私でも、毎回慣れないです…青ざめます。

リリース事故が発生した場合のやることリストはこちらのnoteにまとめているので、ぜひ読んでみてください。

まとめ

今回はプロジェクトマネジメントを広報業務に置き換えてみましたが、他の役割の方でも応用できることがたくさんあります！

このnoteで「プロジェクトマネジメントに興味が出てきた！」なんて思ってくれたあなた、こちらを読んでみてください。
ちょっと専門的ですが、分かりやすく解説されています。

それでは！今回はここまで。まったねー！