プロダクト開発を円滑に進める、社内コミュニケーションデザイン
こんにちは！カミナシでPMをしているかもしー (@96kemu96) です！
今回は、プロダクト開発のデリバリーフェーズで社内のコミュニケーションデザインをしたので、やってみてわかった5つのポイントを紹介します。
コミュニケーションデザインというと、一般には「企業と顧客との間のコミュニケーションをデザインすること」ですが、ここでは広義の「人と人のあいだのコミュニケーションをデザインすること」という意味で使っています。
誰のためのnote?
ステークホルダーが多くて伝書鳩🕊️になってしまう
PdMとしてアカウンタビリティ（説明責任）を意識したい
プロダクト開発に関わる人が多く情報格差が起きてしまう
なぜコミュニケーションデザインが必要だったのか？
プロダクト開発がデリバリーフェーズになったことで、開発メンバーやCSとコミュニケーションをとる機会が増えただけではなく、課題探索フェーズとにはなかった新しいリスクが増えました。（ここで言うリスクは、デメリットや懸念ではなく「不確実性が高いもの」という意味です。）
具体的には、以下のようなリスクがありそうでした。
開発・デザインの遅延リスク
チームがぶつかり合うリスク
要件の軌道修正が遅れるリスク
その他、課題解決が遅れるリスク
※ちなみに今回は開発に数ヶ月かかる中規模なもので、事業計画にもアラインしているため、目標のスケジュールがある開発でした。
リスクがあることは分かっているので、先に手を打ちたい！！
どうしたらよさそうかを考えた結果、個人ではなくチームとして成果を出すことと、そのためのコミュニケーション設計がキモになるだろうと思いました。
各リスクに対応するコミュニケーション設計をした
上記で書いたような各リスクを解決するために必要なコミュニケーションはなにか？という視点で、同期的コミュニケーション（ミーティング）と非同期的なコミュニケーション（ドキュメント、Slack）を設計しました。
やってみて良かった5つのポイント
1.チームでコミュニケーションワークを行ったことで、ミニトラブルを防げている気がする
私たちはオンラインで仕事をしているので、基本的にはslackのコミュニケーションがメインです。
みなさんはテキストコミュニケーション、得意ですか？
ちなみに、私は苦手意識があります。
テキストコミュニケーションだと、思っていたとおりに伝わらなかったり、誤解してしまったり。
また、仕事で小さなストレス溜まる時って、だいたいコミュニケーションに問題があるんじゃないかなと思ってます。
そのため、不要＆不毛なトラブルを事前に防いで楽しく働くためには、「お互いに、好きな/嫌いなコミュニケーションスタイルを理解すること」が大事です。
ということで、コミュニケーションワークをチーム全員でやりました！
やり方
・（事前）用意した質問に回答する
・（当日）発表する ＆ 参加者からの質疑応答
・強み
・弱み
・好きなコミュニケーション
・苦手・不安なコミュニケーション
・どういうふうに仕事をするのが好きか？
・どういうふうに仕事をするのが苦手か？
実はこの最後の「質問」が大事です。なぜ◯◯なコミュニケーションが好きなんですか？と聞くことで、価値観をお互いに理解する糸口になります。
意外と長く仕事をしてきた仲間でも、そういう一面あったんだ！そういうコミュニケーションが苦手なんだ！という気づきがありました。
※余談）似たワークとして、ドラッカー風エクササイズ、学習する組織のパーソナルマスタリー、人生のモチベーショングラフ、なども有名ですが、今回は日々の仕事の基本である「コミュニケーション」に特化したワークを選定しました！
2.重要な意思決定に関することは、別々にコミュニケーションをするのではなく、全員集まる場で
これは山口周さんの「外資系コンサルが教えるプロジェクトマネジメント」を参考にしました。
各ステークホルダーと別々にコミュニケーションをとると、前提のずれや意思決定に必要な情報の差が生まれるため、「あの時はこの情報がなかったのでAと決めたが、この情報があるならBが良さそうだ」というようなブレが生まれます。
気づいたら伝書鳩をしていた、ということありませんか？
そうなると、どうしても意思決定の速度と精度が落ちてしまいます。
特に要件定義に関しては総合的（開発観点、課題の深さ、UX観点など）に意思決定をする必要があるため、スピーディーに軌道修正できるよう、定期的に各ステークホルダーと一気に話せるミーティングをセットしました。
仮説を持っているステークホルダーが複数人いる場合は、基本的にはオープンな場で議論して意思決定までを仕切ることが、最短で最も良い意思決定ができる方法だと思っています。
3. 必要になったら、ではなく定期的なMTGをセットした
これは上記ミーティングの「頻度」についてです。
必要な時にミーティングをセットできればいいですが、各ステークホルダーとの調整が一番大変な作業だったりしませんか？
どの予定はずらせるのだろうか…とカレンダーとにらめっこ👹しがちですよね。
そのため背景を伝えた上で、時間を先に仮抑えさせてもらうことにしました。課題が発生した時にスピーディに必要な情報を収集できるよう、都度ミーティングをセットするのではなく、定期予定として週次でセット。
これは、緊急度が高いものに対応できるようにするためなので、流会にすることも多々あります◯
4. とにかく要件定義や意思決定の履歴を、ドキュメントに残した
「要件定義でAかBかCか悩んで、〜〜の理由でBを選択した」や「〜〜の理由で〜〜をやらないと決めた」という意思決定の履歴をできる限り残しました。
実際にドキュメントを書いて得られたものは、こんな感じです。
ステークホルダーではない人にも、非同期で情報共有ができる
後からjoinする開発メンバーも、やっていることの納得感を持ちやすい
PdMとして意思決定がブレなくなる
変更する際、意思決定の軌道修正がすぐできる
特に「意思決定の軌道修正を的確に行うため」にやってます💡
意思決定がブレることは、開発メンバーや各ステークホルダーに対して不信感を生んでしまったり、事業としても正しく走れていない状態だと思っているためです。
✍書く内容はこんな感じです。
・サマリ（決めたこと、理由、ネクストアクション）
・背景
・課題
・考えられる解決策
・意思決定の軸（UXの観点、開発工数の観点、汎用性の観点など）
・意思決定の前提条件（どのような前提があると考えたのか。「◯◯な利用ケースは少ないと考えた」等）
5. slackのチャンネルを目的別に分けた
最後はslackの話です。
ステークホルダーが多くなると、Slackで扱う情報も多く見落としが発生する可能性が高まります。「それここで言ったんですけど」というコミュニケーションはお互いに避けたいですよね。
また、いろいろな種類の共有や依頼や相談が一つのチャンネルに流れてくるのって、情報理解に時間がかかりませんか？
人によるかもしれないですが、slackを開き情報を読む時「えーっとこれは？依頼か」「これは共有ね、ふむふむ」「これは・・」と情報を仕分けするのは地味にコミュニケーション速度を落とす気がしています。
そのため、扱う情報別にチャンネルを3つに分けました。
開発やチケットに関するチャンネル
要件定義に関するチャンネル
PJに関するチャンネル
特に「要件定義に関するチャンネル」を分けたことは良く、細かいデザインの調整や挙動の確認を全部ここで集約することで、情報を見つけやすくなりました。
最後に
コミュニケーションの適切なあり方は、状況によって異なると思います。実際にMTGやドキュメントを一度やってみたけれど、状況が変わって不要になりやめたこともありました。
逆に、なんだかすれ違いや温度差があるなーと思った時は、コミュニケーションのあり方を都度見直しています。
コミュニケーションは沢山とれば良いのではなく「継続的にとる」ことと、「質」と「量」が両方大事だと思うので、これからも良いあり方を模索していきたいと思います！
この記事を読んで良かった！という方はぜひ「スキ」を押してくださると嬉しいです！😊
カミナシはPM/UXデザイナーを大募集しています！
カミナシのPMチームはまだ立ち上がったばかりで、0→1の環境です。
面白そう！と思った方がいましたら、カジュアルにお話しましょう！🍵
求人一覧
PMエントランスブック