こんにちは！プロダクトデザイナーのmoco（@moco_megane）です。
普段はものづくり部／ICTチーム内で、保育園・幼稚園の先生向けのプロダクトのデザインを担当しています。
2人の息子がおり、愛知県からフルリモートで勤務中です。
代打として、デザイナー兼PMを務めることに
私は2023年7月に千に入社し、それ以来一貫して「先生ユーザーが使う画面」のデザインに携わってきました。
しかし、今年の春頃からあるプロジェクトのPMも兼ねることに。
理由は色々ありますが、そこは割愛し……
初めてのPMを務める中で、デザイナーとしてどんな工夫ができたかを本記事では紹介します。
プロジェクトの計画段階でデザイナーのスキルを使う
プロジェクトというと、開始から完了まで一般的にこのような流れで進んでいきますよね。
この中でも、今回は特に「計画」の部分でデザイナーとしてのスキルを使いました。
一度でもプロジェクト型の仕事をしたことのある方はわかると思いますが、プロジェクトは段取り八分です。
ここが上手くいけばその後はスムーズに進行しますし、逆にここでの失敗は長く尾を引きます。
計画の中身
計画段階で行ったことは主に以下の4つです。
- 要求事項の洗い出し
- 成果物の定義
- フェーズ分け
- スケジュールの策定
ここからは、項目ごとの工夫を紹介していきます。
要求事項の洗い出し
まずは、どんなものを要求されているかを確かめます。
営業さんやCSの方からさまざまな要求を受けます。
しかしこれを鵜呑みにすると、本当の意味でユーザーの欲しいものを提供することはできません。
ユーザーが欲しいのは機能ではなく、快適な状態なのです。
というわけで、ここではデザイナーとして前提を疑い、ユーザーの現在や理想に想いを馳せる活動をしました。
具体的には以下のような活動をする中で、常に「本当にそう？」「ユーザーはどう感じる？」を自分やプロジェクトメンバーに問い続けました。
- ステークホルダーインタビュー
- ユーザーインタビュー
- 業務フロー図作成
- 要件定義
- 画面遷移図作成
成果物の定義
プロジェクトには成果物があります。
その成果物は、As Is（現在）とTo Be（理想）のギャップを埋める解決策であるべきです。
成果物のイメージが異なる状態でプロジェクトが進むと、終盤の成果物が具体化した頃に「欲しいのはこれじゃなかった！」と気付く恐ろしい状況に陥ります…！！
ですから、関係者で認識を合わせておくことがもっとも重要です。
ここでの工夫はビジュアルとテキストを用いて確実に伝えることでした。
以下が実際のマスタードキュメントの一部です。
テキストの中に図を差しんだり、やることだけでなくやらないことも定義したり、解釈の幅を狭められるよう頭を捻りました。
弊社は約400名規模の会社です。
このドキュメントが自分の預かり知らない場所で展開されることも十分に想定できるため、「これが一人歩きしても問題ない」と思えるまで表現方法は詰めていきました。
フェーズ分け
今回のプロジェクトは、ざっと見積もって半年規模になりそうな、自分としてはやや大きめのプロジェクトでした。
全てを一気にリリースするのは「お客様へのリードタイムが長くなる」「問題が発生した際、どの変更・開発が原因なのか調査がしづらい」等の理由でリスクが高いと判断。
フェーズを分けた段階的な開発・リリースを提案しました。
ここでの工夫はコンセプトの明示と推し案・捨て案どちらも見せて納得感を得ることです。
まずはフェーズ分けのコンセプトを明示し、どのような意図でフェーズを分けようとしているのかを伝えます。
「なぜ」が伝わらないと、ステークホルダーもプロジェクトメンバーも判断のしようがありません。
また、推し案と同時にあえて捨て案も共有することが大事です。
ここで言う推し案とは、複数案考えた中から自分がもっともおすすめできる案のこと。
捨て案とは、考えてはみたもののいくつかの理由からおすすめできない案のことを指します。
推し案だけを見せると「本当に考え抜いた結果なのだろうか？」「他の可能性もあるのではないか？」とつい疑いたくなってしまうのは、自分自身もよくある経験です。
ですから、ここでは提案される側の気持ちを汲み、先回りして両方の案を見せることでより納得感を得られる方法を選びました。
ここで大切なのは、複数案見せた中から選んでもらうという姿勢ではなく、あくまで「自分はこうしたい」と意思を持って提案することです。
幅広い意見に耳を傾けながらも、プロジェクトのオーナーシップは自分が持つという気概が、結果的にプロジェクトの成功につながると感じています。
スケジュールの策定
さて、ここまででやるべきこととその順番は決まりました。
それぞれをいつまでにやるか・できるかを相談し決めていきます。
弊チームではワークマネジメントツールAsanaを利用しているため、ここにタスクを切り出して登録していきます。
ここでの工夫は、メンバーを集めて同期的に行うこと。
今回のプロジェクトチームは、私を含めフルリモートのメンバーが過半数でした。
リモートの欠点を補うために、お互いの考えていることは150%の勢いで開示する・確認することを意識しました。
正直、工数の見積もりはどれだけ経験を積んでも非常に難しいものであることは、開発に携わったことのある方はよくご存知ですよね。
ここで無理をして工数を少なめに見積ったからといって、開発が早まるわけではありません（大幅な残業でカバーするのであれば別ですが……）。
各メンバーの言葉の内容はもちろん、表情や声色からその言葉をどんな気持ちで発しているのかを汲み取ることで、それが楽観的な見積もりか・悲観的な見積もりかがある程度わかります。
それぞれのフェーズを早くリリースしたい気持ちはあれど、現実的なスケジュールを定められるよう、メンバーの本音を拾い上げながら組み立てていきました。
「計画」ではなく「コントロール」の段階で多少の押し・巻きはありましたが、結果的にプロジェクト全体では大きなズレはなく進行できました。
最後に
この記事を書く中で、まさに本プロジェクトの最後の段階（3/3フェーズ）がリリースされました！🎉
頼もしいチームのおかげで、なんとかここまで来られたことを嬉しく思います。
まだまだ改善活動の真っ只中にはいますが、お客様から有難いフィードバックもいただき、「価値を届けられた！」と実感できた喜びはひとしおです。
この瞬間とビールのために頑張っているといっても過言ではありませんね……
今回の経験で、プロダクトのデザインはもちろん、プロジェクトのデザインをすることも非常に面白い経験だと感じました。
引き続き、自分の活動範囲を狭めず貪欲にトライしていきます💪
ここまで読んでくださりありがとうございました！
