ブランディング×PMの自分的心得
ご無沙汰しております。きたかわです。
（久しぶりすぎて毎回noteのテキスト修飾パターン忘れる...）
今日は最近棚卸した、仕事で気を付けていることをお伝えします。プロジェクトワークでコミュニケーションで齟齬が特に起こっている様子がない、加えてステークホルダーの皆さんとお話していて反応はなかなか良いとコメントもいただいているので、これは自分の気を付けていることはあながち方向性間違っていないだろうということで、整理したものです。
これを読んでどなたかの役に立つことがあれば、うれしいです:)
自分的PMの心得一覧
＜仕事の原則編＞
1. 明日死んでもいいように仕事する(電子化、オープンな場での共有、フォルダ整理)
＜PMとしての原則編＞
2. 誰かに仕事を任せても、自分がリカバリできるように準備をする
3. 自分がPMのときは特に、質疑応答は全部自分ができるようにしておく
4. 全員ができるだけ同じ景色を見られるように原則情報は自分から渡しに行く
＜他の人を巻き込む編＞
5. 議事録は必ず自分がとる
6. 会議のアジェンダ、ディスカッションポイントは必ず前日から半日前には展開する
7.他の人がリードの打合せでもアジェンダの展開は基本自分からする
8. 構造化がすべて。伝えるときに分かりやすく
9. 何かを伝えるときは背景を必ず説明する
10. 今全体のここでこの部分をお願いしたいと説明する
11. コミュニケーションが滞ったら必ず誰かに遅れていることを共有する
12. コミュニケーションが滞る原因ほど気軽に早めに潰しておく
＜反省・成長編＞
13. 進行に関して定期的にフィードバックをもらう
意外と多くて目がちかちかしてきた...
かいつまんで説明していきます。
仕事の基本は、自分が死んでもすぐに回るように
はい、タイトルの通り。これは仕事する私の根本の姿勢です。プロジェクト始めるときは特に、これ意識してやっていますね。よく組織やチームの立ち上げをやるのですが、任されたときの私のミッションは、「私が今すぐいなくなっても誰かがドキュメントを見ればなんとなくできちゃうようにする」「私が今すぐいなくなっても会社が困らないようにする」だと思っています。
これなんでこう思い始めたのか、心当たりが2つあるんですけど、1つは新卒でBPO（ビジネス・プロセス・アウトソーシング）のビジネスに従事していたからですね。アウトソーシング業なので、業務の可視化が当たり前。仕事を部品のように切り分けて出せるようにする/出される仕事です。多くの人は出された仕事をまずこなせるようにするということから慣れていくと思うのですが、私はいきなり仕事を出してもらう→出せるようにするという段階から入りました。提案営業をやっていたんですね。そこで初めて仕事って「合理的に切り分けできるんだけど、非効率なやり方とか非効率な慣習とかに縛られて切り分けできないことって多いな」、「合理的に仕事したいと思えている人、少ない？」、「合理的っていう判断基準も人それぞれ違うっぽいぞ？」 と感じ始めます（ちなみに最終的に確信するのは26-27歳）。じゃあドキュメントに残さないと言質もとれないし、空中戦になるよなあということで可視化することを覚えます。
それから、もう一つは退職時に引継ぎがえらい面倒くさい。これを避けるため。笑 過去のnote読んでくださった方はご存じだと思いますが、社会人3年で3回、毎年転職してきています。ということは退職時の引継ぎを3回やってきているんですけれど、まあ、人間関係がよくない会社にいるときほど引継ぎが長引くし、面倒臭い。
要は、日頃から引継ぎしている状態にしておこうっていう話なんです。そこでまた可視化しようと思いました。そしてコンサルを1年かじってみたときに、頭のいい人たちのドキュメント、そして日本の大企業で、かつ大企業から様々な企業のコンサルティングをしてきた人たちのドキュメントを見て、構造化するということを学びました。
余談になりますが、ドキュメントは多くの人の目に触れて洗練されていくんだなと思いました。それが重なると一人ひとりの質が良くなって、凝縮されたフィードバックになるし、いいドキュメントも生まれやすくなるんですね。
とまあ、この2つのきっかけから
・ドキュメントを作って可視化
・電子化してオンラインで共有できるようにする（変更履歴も自動で残るメリットもある）
・中身は構造化して整頓しておく
ということを意識するようになりました。
自分が死んでもいいように、というのは転職を繰り返して、いつでも辞められるようにとか、それから他の人もそれぞれの人生があってそれぞれのタイミングで辞めていくし、それから本当に今日死んでしまうこともあると思っているので、残しておこうよということですね。
これがチームでできるようになると、自分が誰かのリカバリをすることもできるし、他の人が自分のリカバリをしてくれるときも、スムーズになります。
具体的には、打合せがあるタイミングだったり、大体週1～隔週くらいでなんとなく見直してますね。運用していて使い勝手が良くないのは生産性が下がるので、気づいて1週間くらいフォルダの使い方を見てから整理しています。
よくコンサルとしてクライアントのフォルダの権限を付与してもらうことがありますが、フォルダが散らかっていたり資料が散漫になっている企業は情報集約ができていなかったり、組織・チームのガバナンスが効いていないことが多いように思います。個人的な感想ですけど。
PMの役割は、全員が同じ土俵でそれぞれの専門性を発揮できるようにすること
さて、次はPMとして原則何を気を付けて行動しているかという項目に移りたいと思います。
私はプロジェクトマネジメントの自分ルールがあって、それがこの3つに反映されている感じですね。
2. 誰かに仕事を任せても、自分がリカバリできるように準備をする
3. 自分がPMのときは特に、質疑応答は全部自分ができるようにしておく
4. 全員ができるだけ同じ景色を見られるように原則情報は自分から渡しに行く
特に2について。私はプロジェクトは自分がリカバリできない、またはリカバリできなくてもすぐに・同等の質を期待できるリプレイス先を知らない、場合、そのジョブを自分のプロジェクトのスコープに含めません。含めたくないです。どうしてもそのジョブをやらないといけない場合、クライアントには必ずリプレイスが効かないということを事前に伝えます。
この考えの背景も、前段の考えがあります。私も明日死ぬ可能性があれば、その他の人も突然いなくなってしまう可能性も否定できません。そこまで極端でなくてもご本人の体調不良やご家族の方をサポートするために抜けますとか、生きていれば当然ありえることなんですよね。
とはいえ、私は優秀なデザイナーでもなければエンジニアでもなく、ブランディングプロジェクトといえば両者とも関わる場合がありますが、その場合はできるだけ工程、難易度をその人たちと同じ判断軸、基準で同じくらいの理解をできるように努めます。進捗管理がしやすくなるというのと、リプレイスするときに引継ぎしやすいからです。何か問題が起きても自分が実際に手は動かせなくてもこれからどのようなリスクが新たに発生するかということも含めて他の人に説明しやすいです。
これは3にも関わるところですね。あと、これはその場の雰囲気もとい、クライアントやプロジェクトメンバーとの関係性、キャラクターなどにもよるのですが、直近のプロジェクトは基本的に私が冒頭サマリをしたり、メンバーの主要の説明があった後、補足で説明をしたりしています。
これをするのは、クライアントに安心してもらえる、それからフラットな目線で説明をするためです。デザイナー、エンジニア、、といった立場からだけでなくプロジェクト全体から見るとこうですよという説明が必要な時は補足しています。ただこれはプロジェクトメンバーにできれば行ってほしい部分でもあるので、様子を見ながらです。
そして最後、情報を平等に伝達するということです。情報の伝え方には特に気を遣っています。というのは、情報は常々アップデートされるものなので、どのタイミングで、誰から伝わってきたのかということが受け取る側が気にするところだと思います。
そのため、プロジェクトメンバーに基本秘密はありません（隠すべきものは隠しますけど）。何か情報が発生したら、できるだけ同じタイミングで、同じ表現で、自分から、プロジェクトメンバーに伝えるようにしています。
プロジェクトメンバーが増えると自分の手間にもなってしまうので、オープンに伝えられる情報は表現など気を付けて、一斉にFYIしてしまうようにしています。センシティブなものはさすがに個別に連絡しますが。
プロジェクトマネジメントって人間関係の問題が一番解決しづらくて一番厄介だと思っているので、それぞれの人たちがPM中心に律しあって作れるチームが一番動きやすいんじゃないかと思ってます。全部オープンにしてしまえば、楽です。監視員じゃないので、適切な全体像と情報を全員に渡してしまえばいいと思うんです。成果だけ管理。
PMがやるのはいろんなものの整理整頓、概念を示すこと、そして仲間を漏らさずゴールに導くこと
よく、PMの仕事は地味なことを拾っていくと言ったりしますが、自分だったらなんて言うだろうかとまだ迷っています。タイトルに納得いっておりません。仮と思ってください。
この適当なタイトルで何を伝えたいかというと、日々日々の仕事はコミュニケーションやステークホルダーの人たちの頭の中の整理、それから（新しい）共通概念を提供することだと思っています。
まず日々日々やっていることを書きます。
5. 議事録は必ず自分がとる
6. 会議のアジェンダ、ディスカッションポイントは必ず前日から半日前には展開する
7.他の人がリードの打合せでもアジェンダの展開は基本自分からする
8. 構造化がすべて。伝えるときに分かりやすく
9. 何かを伝えるときは背景を必ず説明する
10. 今全体のここでこの部分をお願いしたいと説明する
11. コミュニケーションが滞ったら必ず誰かに遅れていることを共有する
12. コミュニケーションが滞る原因ほど気軽に早めに潰しておく
個人的に議事録を制すものは会議、プロジェクトを制すと思っています。だからこそ議事録を必ずとり、TODOはすぐ配布し、会議の骨子となるアジェンダは事前に収集して展開します。
プロジェクトの進行を会議を軸にすると、議事録はステークホルダーの頭の中を同じトピックで占有できる貴重な機会なんですね。だからこそその思考を揃えた証拠になる議事録は、ステークホルダーの思考を操作できるのでとても大事だと考えています。
だからコミュニケーションの交通整理と、（新しい）共通概念を提供するです（新しい概念は創造的でとても難しいと思うので、括弧をつけました）。
プロジェクトの失敗はコミュニケーションの齟齬であることが多いと思います。
※根拠となる具体的な数字を出せればよいのですが、「プロジェクト」というとシステム開発のプロジェクトを指した文献のみで、ブランディングのようなプロジェクトを対象にした調査は見つけられませんでした。
余談になりますが、「ブランディング_PM」という求人ってほとんど見かけないので、世の中にこういうプロジェクト、そしてこうい類のPMは珍しいのだと推測しています。
ちなみにこちらの記事によるとソフトウェア開発系のプロジェクト成功率はおよそ3割、失敗する原因の1位は要件定義ということですから、広くコミュニケーションの齟齬にプロジェクト失敗の原因があるというのはあながち間違っていないような気もします。、
上記でまとめて記載したことについては、細々語るというよりは、ここで問われているのはPMで大事にしているのはコミュニケーションで、その姿勢としては、誰にとっても分かりやすく伝えること、そしてプロアクティブに先手先手で課題とかリスクを拾いにいったり、それらを抱えている人を助けにいくことだと思って書いたという意図をお伝えしておきたいと思います。（いい加減文章が長くなってきたのでサボって...はないです。はい）
この段落のタイトルに「仲間を漏らさずゴールに導くこと」と書きました。先手先手で課題とかリスクを拾いにいったり、それらを抱えている人を助けにいくことが大事だともお伝えしたばかりですが、でもチームにスキルがあまりに合わない、志向性が合わない人、スキルの成熟度が低いほうで合わない人がいた場合は、一定対応をした後でメンバーから外れてもらうことも検討します。厳しいかもしれませんが、プロジェクトの目的はプロジェクトで設定したゴールの達成が目的であって、誰かに何かをやらせるため、お勉強のためではありません。
特別教育のためという意図が事前にあってそのためのリソースも確保しているのであればやぶさかではありませんが、純粋に目的を達成するためのチームであれば、そういった判断も途中で出てくるということは頭の隅っこに置いておいています。個人的にはみんなでゴールしたいんですけどね。
PMの自分の成長、成熟のために
さて、ようやく最後の項目です。これは挙げておきながらとても難しいことだと思うのですが、PMに対する評価をもらうということです。
13. 進行に関して定期的にフィードバックをもらう
誰からもらうのかというのは、メンバーを指しています。フィードバックをそもそももらえるのかということも含めて、日頃からどう思われているかが試される時かと思います。
もらいやすいようにするために、またあまり言及したくはないのですが、私の年齢も一応若いこともあって、ヒエラルキー型の組織やカルチャーはまず作らないようにしています。
どうやっているかというと、
・基本的に成果に対する事前チェックや確認をさせてくださいとは言わない
・PMを介さずコミュニケーションをしてもらうように促す
この2点をやっています。
皆さんプロですよね、と信頼しているのは一番大きいかもしれませんが。まずやっていただいて、難しそうであれば成果に対する事前チェックや確認は入るようにします。ですがお仕事を任せるというのは、内容についてまで手を入れてしまうとそれは自分の仕事になってしまうので、加えてPMという役割を果たすため、また他の人の役割を侵食しないためにも、できる限りそういう場面を作らないようにしています（メンバーの人選や、事前の情報インプットに時間を割くなどして）。
それでもメンバーの皆さんが正直に思っているフィードバックをもらえるかは分かりません。その点、PMをやっていて常に感じているのは危機感で、その危機感があるために今日挙げた13の項目を軸に行動していると言ってもいいと思います。
まとめ、PMって。
プロジェクトの目的を達成するための施策はたくさんアイデアがあり、メンバーが変わればやり方も変わったり、やり方が一緒でも人が変われば面白い結果が目に見え、プロジェクト運営はとても楽しいものだと思っています。
このプロジェクトを楽しめるものにするため、そして同時に目的を達成させるためにPMがいると思っています。だからこそ人に信頼されない、疑いの目を向けられる、裏があるように思われて期待する行動をしてもらえないなど、そういったことがあってはならないと思います。それがゴールに向かう最短距離を邪魔するから。
今はこの13個がそのための行動指針となっていますが、もしかしたら将来は変わるかもしれませんね。プロジェクトの内容や何より人が変わればPMの立ち回りも求められるものが違ってくるかもしれません。ただ今のところはベーシックなところをベーシックにやる、チームの中のこぼれそうなものを拾いにいく、そんな姿勢を持ってPMをやっていきたいと思っています。