サービスデザインプロジェクトにおけるPMの役割を考える
この記事はGoodpatch Anywhereアドベントカレンダー2日目の記事です。
普段自分は株式会社Goodpatchのフルリモートデザインチーム Goodpatch Anywhere で主にプロジェクトマネジメントの役割を担っています。
昨年夏にジョインして1年半が経ち、携わってきたサービスデザインプロジェクトで気を付けている点をまとめる機会があったので書いていきます。
対象とする範囲
この記事でお伝えするノウハウは新規サービス立ち上げに外部パートナーとして関わる場合を想定しています。さらにこれを1.仕様を固めていくフェーズと2.実装していくフェーズに分け、それぞれで気をつけている点をまとめました。
既存サービスのフルリニューアルや改善チームに加わる場合の心得は別の機会に書こうと思います。
1.仕様を固めていくフェーズの心得
1-1.ロードマップを描く
UXドキュメント作成やプロトタイピングを繰り返すサービス立ち上げ期は、検討すべき内容も集めるべき情報も膨大です。これらは同時並行で走るためPFD（Process Flow Diagram）を応用してカオスな状況下での筋道を定めています。PFDについてはこちらのSlideShareに詳しいのでご覧ください。
簡単に言うと「プロセス」と「成果物」を線で繋ぎ、カオスなToDoとその相互関係を整理する図示の方法を指します。上記のスライドでは丸などの図形で分けられていますが、自分はプロセスを黄色で成果物を緑でかき分け、2つセットで描いたりしています。
↑PFDを応用したロードマップの例
なんとなくペルソナを作りましょう、ではなく「何に活かすために作成するのか」活用の目的まで可視化できるので重宝しています。これを最初に描くだけで暗中模索感が薄れます。
このPFDは都度アップデートをかけますし、なぜそのプロセスを経る必要があるかは事前に説明し、お互いに納得して決めていきます。どうしても時間を優先したい場合はプロセスを省略したり、割く時間を調整していきます。実務では先ほどのプロセスに目標期限を書いてスケジュール引きにも利用します。
1-2.十分な選択肢を提供する
当たり前ですがサービスの仕様を決める決定権は自分たちにはありません。意思決定はプロダクトオーナーや現場の責任者の方が担っています。
ユーザー視点を盛り込みながらサービスデザインを行うのが自分たちの職能ですが、彼/彼女らに良質な意思決定を下してもらうために何ができるでしょうか。
悪い例をまず上げてみます。
AとBはUIでもグラフィックにまつわるものでもなんでも良いのですが選択肢を示すだけの役割では不十分と考えます。
責任者に良質な意思決定をしていただくためには大事なポイントがあります。
忙しい責任者のために案を絞ってあげる優しさも存在しますが、責任者は選んだ理由をチーム全体に説明する必要があります。手前で捨てたC案やD案も残して共有していきます。
そんなことは失礼だと思うのであれば、それは共有できるくらい柔軟な体制ができていないと言えます。心理的安全性が十分に保たれていればどんなアイデアでもクラウドに上げて良いのです。
齟齬を生まないようMTG頻度は多めにとりましょう。案件ボリュームによってまちまちですが、自分たちは毎日30分はZoomをつないで議論・共有する場を設けています。
そして選択肢自体の質についてはデザイナーのスキルに寄るところが大きいです。シニアであるほど各案の考えの深さと実現可能性が高い傾向にありますが、結局チーム全体で質は高められるので、とにかくアイデアを素早く共有することがサービスデザインにおいては正しいのです。
1-3.判断材料/評価項目を提供する
絞った案を選択する際、評価すべき軸が必要になります。よく行うのが図のようなマトリクスですが、そもそもこの評価項目は最初からはっきりしているわけではありません。
いくつか案を出して良し悪しを議論していく中でこれらも明確になり、新しい評価項目を鑑みた別案が生まれたりもします。これをクリアにしていくのも私たちが役立てますし、UXデザイナーであればここにユーザー視点での評価あるいはヒューリスティック的な評価を持ってくることが可能なはずです。
こういった選択肢とそれを選択するための評価項目を用意した上でサービス設計を一緒に行えれば、サービスデザインに関わる者として価値を発揮できている状態と言えます。
1-4.意思決定の期限を定める
仕様を決めていくフェーズは文字通り、PFDに沿って選択を進めていかなければなりません。契約期間内で成果を上げるためには、遅れずに決めていただく必要があります。
決められない場合、選びうる選択肢が足りないか、判断材料が足りていない状態です。それぞれサポートできるのであれば対応します。それでも決まらない場合どうするかと言うと可逆な選択であれば仮決定としてでも前に進めます。配色ルールやフォントサイズなどスタイルに関することは可逆な選択であることが多いです。
不可逆あるいは修正コストが大きいような意思決定は少し慎重になるべきです。十分な選択肢や論点はもちろんですが、コンディションも大切です。仮釈放を許可する割合が裁判官の休憩前後で差が出たという研究もあります。
人は疲れている時や空腹時にはより安易な意思決定に走りがちなのです。金曜の夕方に不可逆で重要な意思決定を強いるくらいであれば、月曜の朝イチに決めてもらった方が良いと考えます。
2.実装フェーズの心得
2-1.タスク全量の把握
ある程度初期リリースのサービスの仕様が固まったら、いよいよ実装を進めていくことになります。この頃になるとタスクと進捗、担当者を明確にしたガントチャートに近いものが有用になってきます。
自分自身はGoogleスプレッドシートにページ、パーツ、TODOなど単位も揃えず並べて管理することが多いです。全員が扱えて最新状態に保ちやすく汎用性が高いですし、全量を俯瞰するにはスプレッドシートでないと難しいくらいです。
理論上、タスクを網羅しスケジュール通りに進めば実装時に大きな遅延が起こることは稀です。
遅れの原因として頻出するのは、後から出てきたひょっこりタスクと工数見積もりの精度が低い状態で放置したパンドラの箱タスクでしょう。
これについてはどれだけ慎重に進めても出てきてしまうものです。プロジェクトマネジメントを担う者としては彼らに太刀打ちするためにバッファを確保しておく必要があります。
2-2.スケジュールにバッファを持たせる
余裕を持ったスケジューリングはPMの基本ですが、少し整理してみます。
1つ目はPM自身のバッファ。自分はデザイナーとしてのバックグラウンドがあるPMなため、プロジェクト後半に出てきたひょっこりタスクには率先して戦いにいきます。そのためひょっこりの出現に備えてPM自身の稼働に余裕を持っておくようにしています。
2つ目はプレイヤーのバッファです。手を動かさなくても良い期間は少し稼働を抑え、作業が忙しくなる後半にかけて稼働が厚くなるスケジューリングをしています。さらにAnywhereでは契約期間内の稼働の使い方も各人に任せているため、各人がベストパフォーマンスを出せるように時間の使い方を工夫してバッファを生み出します。
3つ目は助けを呼ぶバッファです。プロジェクトメンバーだけではどうしようもない場合、頼れる存在があると精神的にも心強いものです。スポットでも力を発揮できる「XXXに強い人」が社内にいて頼める状況にあるとベストです。これができるのがデザイン会社の強みとも言えます。
これらのバッファは何事もなければ終盤まで余ります。その時は残っているバッファ分を用いて、さらなるブラッシュアップやラバブルな仕掛け作りに時間を割いています。
最後に
自分たちに依頼してくださるのは事業会社の方々です。重要な意思決定を重ねるのはハードですし、それを継続的に行いながらサービスを運営・改善・継続されている方々のタフネスさを尊敬しています。
ここまで新規事業立ち上げ時にサービスデザインをお手伝いする際、気をつけている点を書いてきましたが
カスタマーサクセスの先に、良質なユーザー体験が生まれる。
のだと考えています。頼ってくれているパートナーを安心させ、提供価値に満足してもらってからがスタートラインです。
それでは
ちなみにこの記事中の図はすべて Strap というオンラインホワイトボードで作成しています。簡単にそれなりの図が描けるのでおすすめです。
この記事が気に入ったらサポートをしてみませんか？