i3DESIGNで「プロジェクトデザイナー」という仕事をしている今野です。皆さんは「プロジェクトデザイナー」という役割をご存知でしょうか？おそらく一般的にはまだまだ馴染みのない役割かと思います。この記事では「プロジェクトデザイナー」とは何か、なぜ弊社にはこのような役割のメンバーがいるのかを紹介をします。
目次
プロジェクトデザイナーとは
プロジェクトデザイナーは、デザイナーと名乗りますが「視覚的なデザイン」は行いません。ご存知の方もいらっしゃるかと思いますが、デザインという言葉には、「設計」と「意匠」という2つの意味合いがあり、私たちプロジェクトデザイナーの役割は主に「設計」にその軸足が置かれます。
よって「プロジェクトを設計する」人のことをプロジェクトデザイナーと呼びます。
プロジェクトデザイナーの役割をさらに細分化していくと、プロジェクトにおける「何のために作るのか（提供価値は何か）」「ユーザーは誰なのか」「どのようにグロースするか」を明らかにすること、その上でクライアント、デザイナー、エンジニアの目線を合わせていくことです。この3つのポイントを踏まえた上で、プロジェクト全体のファシリテーションを行い、対象プロダクト（Webサイトやアプリ）の体験設計を実施すること、体験設計をUIデザインに落とし込むこと、それら全てを踏まえて開発チームにインプットを行っています。
弊社ではプロダクト開発に対してアサインされることが多い一方、前者の「3つのポイント」が確定しない場合は、サービス設計という形でクライアントの事業における「強みは何か」「ターゲット顧客は誰か」「どうやってKGI/KPIを向上させるか」を定義して、プロダクト開発に繋げていく場合もあります
実際に行う内容の詳細は以下の通りです。
・上流工程のプランニングと手法選定
弊社では、クライアントのビジネス要求、ユーザー要求、UIデザインに関わるコンセプト設計までを上流工程と定義し、プロジェクトデザイナーがプランニングを行っています。
上流工程の目的である「何のために作るのか（提供価値は何か）」「ユーザーは誰なのか」「どのようにグロースするか」を明確化するために、リリーススケジュールを踏まえ、定義を確定するためにどんな手法が適切かを検討のうえ、全体のプロセスを設計します。
・クライアントのビジネス要求
クライアントのビジネスを理解した上で、開発するプロダクトでどんなKPIを達成すべきか、どんなユーザーをターゲットとするかを設定していきます。
「何のために作るのか（提供価値は何か）」と「どのようにグロースするか」の明確化が目的です。 クライアント側で、すでに決定したことを元にご相談いただくことも多く、その場合はクライアントと弊社チームが同じ目線で開発を進めて行くために、ビジネス要求の定義を実施します。 一方で、営業提案時にこの内容が確定している場合も多く、その場合はプロジェクト初回のMTG（キックオフ）でこの内容を再度提示し、共通認識を持った上で進行を進めていきます。
・対象プロダクト（アプリやWebサイト）のユーザー要求
「ビジネス要求」で設定したターゲットユーザーに対して、インタビューを行います。そして、インタビューの内容からペルソナ設計、カスタマージャーニーマップを作成します。
ターゲットというおおまかなユーザーイメージから、より具体的なユーザー像を設計することで、よりユーザーに対する解像度を上げることが目的です。
「ユーザーは誰なのか」を明確化することで、よりユーザー課題が明確になり、設計の優先度をつけやすくなります。
・コンセプト設計
ビジネス要求、ユーザー要求を踏まえた上でUIデザインの指針となるコンセプトを作成します。この時点で「何のために作るのか（提供価値は何か）」「ユーザーは誰なのか」「どのようにグロースするか」が確定しているため、その内容を踏まえて本プロダクトは「何の達成を目標とするのか」、そのためには「どんな画面設計であるべきなのか」をコンセプトとして定義します。コンセプトを立てることで感覚や憶測ではなく、意図をもって設計を行うことができます。クライアントもコンセプトに沿ってレビューを行うため、個人の感覚や好みによるレビューを減らすことができます。
コンセプトがない場合、レビューをする各個人ごとに確認観点が異なり、感覚や好みを軸としたレビューになる可能性が高くなります。
感覚や好みは各個人ごとに異なるため、クライアント側での意見が割れやすく議論も多くなり、レビューにかかる労力が大きく、プロジェクト進行の効率が悪くなる可能性があります。クライアントの負荷を軽減させる意味でも、コンセプトの定義は重要となります。
プロジェクトでの各メンバーの役割やプロセスは以下となります。
「プロジェクトデザイナー」のやることを踏まえた上で、弊社では他メンバーとの関わりや開発プロセスは以下のようになります。
それぞれの役割と分担する範囲
|
名称 |
やること |
|
プロジェクト |
コンセプト（提供価値）の定義、手法の選定、 |
|
UIデザイナー |
ビジュアル・レイアウト・ナビゲーションデザイン |
|
プロジェクト |
スケジュール、タスク管理、チーム運営 |
|
テックリード |
技術要件の定義、品質保証 |
|
エンジニア |
製造、テスト |
UXデザインを行う際の指針となるUXの5段階モデルにおいて、プロジェクトデザイナーが戦略〜要件までを、UIデザイナーは構造〜表層までを担当します。
【UI/UXフェーズ】
UX設計
・調査分析：担当 プロジェクトデザイナー
・ユーザーモデリング：担当 プロジェクトデザイナー
・コンセプト設計：担当 プロジェクトデザイナー
UI設計
・ビジュアル設計：担当 UIデザイナー
・ナビゲーション設計：担当 UIデザイナー
・プロトタイプ作成：担当 UIデザイナー
【開発フェーズ】
開発
・要件定義：担当 プロジェクトデザイナー/プロジェクトマネージャー/テックリード
・設計：担当 プロジェクトマネージャー / テックリード
・実装：担当 プロジェクトマネージャー / テックリード / エンジニア
・テスト：担当 プロジェクトマネージャー / テックリード / エンジニア
▼フェーズごとの担当・期間イメージ
柏木真さんという方の記事で、プロジェクトデザイナーに関する役割やスキルセットは記載されており、とてもわかりやすく弊社の理解とも近いので、こちらも参照してみてください。
https://note.com/memo_notes/n/ne2409a90e24a
弊社でプロジェクトデザイナーの役割が出来た理由
プロジェクトデザイナーの役割ができるまでは、システム開発のプロジェクトマネージャーがプロジェクト全体の進行管理やファシリテーションを行っていました。
弊社のプロジェクトマネージャーは設計と開発を主体として進捗管理を行っており、UXやUIデザインはデザイナーがプロトタイプ上で行うという状況でした。
この場合、プロジェクトマネージャーが得意とする開発の進行以外の領域にもUXやUIの範囲にも関わる必要があり、業務範囲が広くなります。そのため各業務に割けるリソースが少なくなること、それにより以下の懸念点がありました。
- ビジネス要求に割けるリソースが少なくなり、クライアントの要望を十分にヒアリングする時間が減ってしまうこと
- ユーザー要求に割けるリソースが少なくなり、設計における考慮がデザイナー任せになってしまうこと
- 開発工程におけるリソースが足りなくなってしまうこと
- 全体スケジュールの管理コストが大きくなること
リソース不足により、クライアントへのヒアリングやユーザー調査が十分にできなくなることで、クライアントのビジネスやユーザーへの解像度が低下すると、UI設計における提案の根拠が弱くなり、クライアントへ十分な説明や提案が行えません。根拠が弱い説明や提案はクライアントからの承認を得られにくい上、弊社からの提案や説明に対して不安を抱いてしまう可能性もあります。
また、開発も同時に進めるため、スケジュール管理のコストが高く、クリティカルなバグや設計不備がもしあれば、スケジュール遅延も起こりかねません。プロジェクトマネージャーの業務範囲を拡大させることは、プロジェクトの進行にとってリスクが高い状態を生み出してしまいます。
リソースの問題であれば、プロジェクトマネージャーを2名体制にすることも有効ですが、プロジェクトマネージャーの主業務はあくまで開発であり、「クライアントの要求把握」「ユーザー体験の想像」といった分野においては強みを出しにくい状態でした。この状況を改善するために上流工程に特化した役割が必要でした。
上流工程に特化したメンバーがクライアントの要求を把握し、ユーザー体験を踏まえた提案を行い、設計にフィードバックをすることで、「プロジェクトマネージャー」が開発に専念することができるため、全体の品質向上が期待できます。
誰がプロジェクトデザイナーをやる？
前述のような理由で、「ビジネス要求」や「ユーザー要求」に特化したメンバーは必要でしたが、すぐにこの役割にあったメンバーが採用できるわけではありません。
弊社ではWeb開発の上流工程を進行していた「Webディレクター」がこの役割を担うようになりました。
「Webディレクター」と呼ばれていましたが、いわゆるWebサイトに特化したディレクターではなく、Web以外にもWebアプリやスマホアプリの進行管理も行っていたため、期待する役割に近く、「プロジェクトデザイナー」という肩書に変更することで、より役割の定義を明確にしました。
このように定義が明確化された「プロジェクトデザイナー」として、より上流工程の精度を上げるべくUXリサーチの手法やビジネスモデルの研究、ひいては「プロダクトマネージメント」のスキルに関しても実践や研究を行い、ビジネス要求やユーザー要求の精度向上を常に務めています。
営業から、上流工程は始まっている
プロジェクトデザイナーはクライアントやエンドユーザーの課題を特定し、要求を定義することをメインに行なっています。これらの経験はリアリティのある営業提案にも生かすことができます。
実際のクライアントやエンドユーザーの課題や悩みといった知見を基に、プロジェクトデザイナーのメンバーは営業提案の場にも参加して、プロジェクトの開始前からクライアントと接点を持つようにしています。
プロジェクト開始前からクライアントと接点を持つことによって、クライアントのニーズを予め知ることができ、プロジェクトの進行管理がよりスムーズになります。
プロジェクトデザイナーがいることのメリット
ビジネス要求やユーザー要求を通して、論点を明確にすることもまた、プロジェクトデザイナーの役割の1つです。プロジェクトを進める上で、クライアントにデザイン（意匠や設計）の確認と承認をいただく必要があります。確認と承認をいただくためには、承認にいたるまでのロジックが必要です。例として「ターゲットとなるペルソナのXXXというペインを解消し、OOOな体験を提供するために、△△△の機能を実装する。」等があります。
これによるメリットとして、プロジェクト上での手戻りが減ること、クライアント内部での承認プロセスがスムーズになること、クライアントから各作業メンバーが同じロジックを共有することでプロダクトにおける解像度が上がること、が挙げられます。
僕が実際に業務を通じて感じた効果として、上流工程が厚くなることで、UIデザインにおけるレビューが以前よりスムーズになったことです。レビューをする観点が、上流工程で決まっているため、主観的な良し悪しで判断する必要が少なくなったことが要因です。
クライアントも同じ文脈と論点が共有できていることで、議論は建設的になり、効率的にプロジェクトを進めることができます。これにより、クライアントと弊社で、一緒に設計をするようなフラットな関係性を構築することができるようになりました。フラットな関係性を構築できることで、プロジェクトに必要なことであれば言いにくい意見も交換ができるようになり、クライアントに対してより精度の高い提案ができるようになります。それにより新しいアイデアの採用確率が高くなり、新しいアイデアはプロダクトの個性に繋がり、市場における強みになります。
一緒に設計を行うことで、お互いの思考や設計で注意すべき観点を自然と擦り合わすことができます。それにより、クライアントはビジネス観点で、弊社はそれを踏まえて設計や実装の観点での最適解を目指すことで、より良いプロダクトに近づきます。
また、一緒に進行を行うことで弊社のプロセスを通じ、弊社独自の良さというものを感じてもらえると、プロジェクトの担当者として非常に嬉しい限りです。
以上、簡単ではありますが「プロジェクトデザイナー」について、紹介をさせていただきました。プロジェクトの進行やプランニングで悩まれている方に「プロジェクトデザイナー」の役割が一助となれば幸いです。
プロジェクトデザインについては、プロジェクトデザイン部マネージャーの平の記事もぜひ参照ください。
アイスリーデザインが考える「プロジェクトをデザイン」する重要性
