こんにちは。UXデザイナーのくろだです。
最近はUXデザイナーという役割上、プロジェクト進行をリードする事が多い今日この頃です。

今回はプロジェクト進行で重要な「プロセス設計」について、工夫している事をご紹介させていただきます。
主に上流工程に関わるPdM、デザイナー、ディレクター、エンジニアの方々のお役に立てれば幸いです。

プロセス設計とは

プロセス設計とはプロジェクト成功の道筋を計画する事を指しています。

プロセスは、プロジェクトの目的、期間、品質、メンバーの人数によっても異なります。プロジェクト毎にオーダーメイドですよね。

これがないと、行きあたりばったりな進行になり目的を果たせなかったり、コストが肥大化する危険があります。そのため、この設計がプロジェクト品質を左右すると言っても過言ではないと、個人的には思っています。
特にUXデザインではメンバー参加型のワークショップを開催する事が多くあり、巻き込む人数が多ければ多いほど影響は大きくなるので私は計画を重視しています。

属人化しがちなプロセス設計

リーダーが一人で考える？

プロセス設計、みなさんはどのように行っていますか？

一般的には、プロジェクトリーダーが考えてメンバーに展開する事が多いのではないでしょうか。

一人で考える事で、素早く一貫性のある計画ができるのはメリットですが、反面、品質がリーダーに依存してしまうデメリットがあります。

ベテランならこれまで培った経験で何をすればいいかスラスラ思い浮かぶと思いますが、初めてプロジェクトをリードする人にとっては、何が必要なのかも手探りなのではないでしょうか。プロジェクトに参加した経験はあっても、リードする側に立って見る景色は一味違います。

こういう段取りも必要なのか〜！ここはこんなに深く議論する必要があったのか〜！！なんて、実際に経験しないとと分かりません。そもそもプロジェクト設計の必要性について、最初の頃の私は理解すらしていなかったかもしれません(！)

経験が浅ければ浅いほど、できることなら、悩みの種になりそうなものは事前に察知して対策しておきたいですよね。

ノウハウ展開がしづらい？

また、プロセス設計のノウハウがリーダーだけに蓄積され、チームに還元されづらいという実態もあるのかと思います。リーダーが考えて経験を経て学んで終わる。意識しなければ、チームへ学びを還元する事が難しいのかと思います。

私の関わっているプロジェクトは3〜4ヶ月、長いものでは1年程度動きます。そのため、プロセス設計の機会も限られます。
その貴重な機会で得られる経験を、自分だけ独り占めにするのは組織として見たらもったいない。また、リーダーがプロジェクトから外れた時、ノウハウが共有さていなければ組織のプロジェクトレベルが振り出しに戻ってしまう。これまたもったいない事です。

一人でプロセス設計する際の課題をまとめます。

プロジェクト品質がリーダーの手腕に依存する
リーダー一人で悩みを抱えがち
プロセス設計をリーダーしか考えられない
リーダーしか成長できない（学びがチームへ還元されない）

プロジェクトの品質を左右する設計なのに、一人で立ち向かわなければいけないのは辛くなっちゃいます。

同じ役割で集まって設計してみよう

上記のような課題を解消すべく、デザイン領域のプロセス設計をする際に私達は、デザイナー同士が集まって一緒に考えています。

主な目的は3つです。

専門家(エキスパート)間で意見交換し品質を高める
経験値をチームで共有する
相談できる場所を作る

私達の組織には3名のデザイナーがいます。（会社全体ではもっと在籍しています）
普段は別々のプロダクトを担当していますが、プロジェクト始動時にはその垣根を超えて3名一緒にデザインプロセスを考えるようにしています。

f:id:AdwaysEngineerBlog:20220407171420p:plain

同じ知識を持った者同士だからできる突っ込んだ話や、より深い議論が行えるのが大きなメリットで、品質向上に一役買っていると実感しています。

また、私が一番いいなと思っているのは、プロセス設計を通して擬似的にでも経験値が得られる事です。
このプロジェクトに対して自分だったらどう動くか。実際にどうなったか。改善すべき動きは何か。

これらを自分事化して考えられるかが、成長の鍵だと思っています。
数少ない経験値を得られる場を、メンバーで共有して一緒に成長できたら最高ですよね！

（もちろん、プロジェクト成功と事業貢献を目指す為だという事は大前提ですが！）

プロセス設計と振り返り

一連の流れは、設計と振り返りの二部構成になっています。

1.プロセス設計の流れ

プロダクト/プロジェクトのドメイン知識の共有
プロジェクト目的の共有
必要タスクの発散
タスクをグルーピングし時系列に並べる
全体の流れ/タスクの手法やポイントについて深堀り・意見交換
スケジュールを考慮し、必須タスクを決める（プロジェクト責任者と一緒に決める）

f:id:AdwaysEngineerBlog:20220407171438p:plain

※黄色の付箋がプロセスの候補、緑色の付箋が必須プロセス

まず最初に行うのが、ドメイン知識のインプットです。
プロダクトの現状、戦略、プロジェクト始動の背景など、プロセス設計に必要な情報を参加者全員が理解し、その次に、今回のプロジェクトの目的の共有を行います。

この2点は、プロジェクト間で接点が全くないと理解まで大きな労力がかかってしまいます。説明する側も、どこまで説明すれば議論できるレベルになるのかを見極めるのがとても難しいです。
ただ、一度このサイクルを回してしまえば後々に蓄積されていくものだと思うので、徐々にコツが掴めてくるのかと思います。

その後、このプロジェクトで必要だと思うタスクを各自で書き出し、グルーピングを行い時系列に整理し、議論を行っていきます。
この発散と収束をしっかり行う事で、自分が見落としていた観点に気づけたり、他デザイナーからアドバイスをもらったり、意見交換ができます。

最後に、時系列に並べたタスクの中で、スケジュールを考慮して必須タスクを選定します。
この時に私達は、意思決定者であるPdMと相談しながら決めるようにしています。

2.プロセスの振り返り

プロジェクトが一段落した後、設計したプロセスがどうだったか、プロセス設計したメンバーで振り返るようにしています。

この振り返りが、経験値の共有と学びを定着させる上でとても重要です。
計画と実際の動きを照らし合わせながら、下記のような点を話し合います。

良かった事
悪かった事
プロセスの過不足
工夫点
次に挑戦すること

この取り組みへの振り返り

プロセス設計を一緒に行っているデザイナーで、この取り組みに対して振り返ってみました。

良かった事

観点を持ち寄る事で、品質を高めることができる
デザイナー経験値UP
相談できる環境づくり。この場以外でも相談しやすい
お互いの業務理解・孤立を防ぐ

狙い通り品質の向上とデザイナー経験値についてが良い点としてありました。

その他、孤立を防ぐという点も上げられていました。

これは相談できる環境づくりにも近いですが、異なるプロダクトで業務を進めているとデザイナー間でもお互いどのような業務を進めているのか分からなくなってきます。その結果、分からないから相談しない、相談できる相手がいなくなる、さらに孤立し分からなくなる。。という負のスパイラルを引き起こします。

このスパイラルを断つ為の、お互いの業務理解・孤立を防ぐ場にもなっているという事でした。

課題・問題な事

プロダクトのドメイン知識・状況共有
コストがかかる
プロセス計画後の関わりの深さ

一番難しいと意見が上がったのが、ドメイン知識・状況共有をどこまで細かく説明するかです。

状況をちゃんと理解していないと的外れなプロセス設計になってしまうかもしれません。
説明する側も、理解してもらうにはプロダクトのドメイン知識、市況、戦略、どこまで話せば良いのでしょうか。準備するにもコストがかかります。要点を抑えて…ただちゃんと理解してもらう必要がある。。悩ましいです。

ここについて、明確な解決策は見つかっていませんが、一旦動きながらトライアンドエラーで過不足を話しながら練度を高めていこうと考えています。

また、プロセス計画後の関わりの深さについても課題として上がりました。

プロセス計画後に、実際の会議や作業にも参加する事で経験値を更に高める事ができます。
しかし、自分の業務もある中、どこまで参加すれば良いのか分からなくなるという意見でした。
ここは確かに参加すれば勉強にはなると思いますが、無理して参加しなくても良いのかなと思っています。振り返りのタイミングで、出来事や工夫点などを共有するようにすれば補えそうですね。

このように課題はありつつも、目的通りの良かった付箋が上がって、この取り組みの意義を改めて感じました。