プランナーの「プロジェクト推進術」

はじめに

こんにちは、Tech blog運営担当の青山です。

スタンバイには、プロダクトの行動指針「START」に基づいて、素晴らしい成果を創出したメンバーを表彰する「START賞」という表彰制度（月次表彰）があります。

また、半期（上期・下期）ごとに、プロダクト部門所属のメンバーの中から1名に「ベストプレイヤー賞（プロダクト部門）」が贈られます。（行動指針「START」の詳細は、「スタンバイのプロダクト本部の行動指針「START」と「Engineering Belt」とは？」にてご確認ください）

本記事では、入社1年未満にもかかわらず、「6月度START賞 MVP」「10月度START賞準MVP」「FY22上期ベストプレーヤー賞（プロダクト部門）」を受賞し、プランナーとして大活躍中の城本さんに、高評価を獲得したプロジェクト「Apply URL プロジェクト」について、インタビューをしていきたいと思います！

-早速ですが、「Apply URL プロジェクト」について、概要を教えてください。

城本： 一言で伝えると「ユーザーの応募体験向上」のためのプロジェクトです。以前、ユーザーインタビューを実施した際に、求職者様より「スタンバイの求人詳細ページの「応募ボタン」を押すと、掲載元の求人詳細ページに遷移してしまう。すぐに応募したいと思っている分、応募フォーム以外のページに遷移するのは分かりにくいし、不便」などのお声をいただいていました。

そのお声をもとに、求人詳細ページの「応募ボタン」を押した後は、掲載元の応募フォームに直接遷移させることを「ユーザーの応募体験向上」のための初手だと考えました。

また、クライアント企業（求人掲載元の企業）様にとっても、求人検索の利便性を高めることは、「企業様と求職者様とのマッチング」の機会を増やすことに直結します。比較的シンプルなステップで企業様が導入できる「Apply URL」は、まさにファーストステップとしてうってつけでした。

-ありがとうございます。求職者様の応募体験を向上させることで、「スタンバイで求人を検索し、応募に進む機会」をより多く提供していきたいですね。次に、多くの賞を受賞することになった「Apply URL プロジェクト」における城本さんの具体的役割を教えていただきたいです。

城本： プランナーの基本的な役割は、施策のROIの見立て、要求・要件の整理、スケジュール管理などです。それに加え、スタンバイには様々なバックグラウンドを持ったプランナーが集まっており、エンジニア出身、デザイナー出身、コンサル出身など各人のスキルによって得意分野が異なり、プロジェクトの内容によっても、プランナーとしての役割は多少変化します。

「Apply URL プロジェクト」においては、機能をリリースするだけでなく企業様に導入いただくことまでを視野にいれる必要があるので、導入率向上を含めた戦略の立案も私の大事な役割でした。あまり具体的に表現するのが難しいのですが、プランナーの役割は、「プロジェクト成功にむけて、開発実装以外はなんでもする人」と言えばよいかもしれません。

-「開発実装以外なんでも」・・・聞いただけでも大変そうですが、その分やりがいがありますね。「Apply URL プロジェクト」のステークホルダーについても教えてください。

城本： 開発部門内だと、自グループ以外の４つのグループが関わっていました。また、それ以外では法務、セールス、CSのグループにご協力いただきました。

-自グループにとどまらず、他に7つのグループと関わりながらプロジェクトを推進されたのですね。城本さんが表彰された大きな理由の1つは、「“Apply URL プロジェクト”をスムーズに進められた」ことだと伺いました。これだけ多くのグループが関わったプロジェクトを成功に導くための「プロジェクト推進術」を知りたいです。

城本： そうですね、まず前提として、過去の経験と比較しても、スタンバイのエンジニアは開発のスピードが速く、プロジェクトにおける提供価値の擦り合わせが完了すれば、要求を基に要件・仕様の提案などを積極的に行って自走していく優秀な方が多いと感じます。また、私のような非エンジニア人材に対しての技術的な説明も分かりやすいので、プランナー側でも設計意図を理解しながら実装を進めることができます。

技術・意識ともにプロフェッショナルな方々と共に進められたことが、プロジェクト成功の大きな要因といえますが、それ以外で「プロジェクト推進」において上手くいった要因を挙げるとするならば、振り返ると3つほどあると思います。

１．40％の完成度でもいい。たたき台を作成する
私には、数値分析やデザインなどの専門性はありません。完成度の高い資料の作成は難しいですが、たたき台やワイヤーフレーム、分析要件など40％の完成度でもいいので、まずはとにかく形にすることを心がけています。

それを基にお願いしたいことを説明すれば議論がしやすくなり、意思伝達のスピードが上がります。自分にないスキルは積極的にスキルのある人や専門グループを頼らせてもらい、40％のたたき台を80％以上のクオリティに仕上げるのです。

また、その40％のたたき台の中にも「ぶれない箇所・要素」はあるので、他グループへの相談を併行しながら、要件整理を進めていきます。これは、コミュニケーションの効率化とプロジェクトの推進スピードの向上に多少ながら寄与したと考えています。

２．なぜやりたいのかを論理的に全力で説明する
「Apply URL プロジェクト」に関しては、当初ステークホルダー全員がポジティブな想いを持っている状態とは言えませんでした。なぜなら、課題に対して多くの解決策がある中で、それがベストな打ち手といえる認識を統一できていなかったからです。

そこで、「仮説の数値を基にした効果」や「他の手段と比較した結果」などを踏まえ「なぜやりたいのか」を論理的に説明することに力を割きました。さらには、このプロジェクトは、「中長期的な視野で、将来につながる」プロジェクトであることを理解してもらうことも欠かせませんでした。

また「Apply URLが今選択しうるベストな打ち手である」というストーリーを考えることは、私にもできることですが、「誰から伝えるのか」は、ストーリーの納得感を高めるためにも、とても重要です。そのため、最終的にはマネージャーやCOOにも協力を仰いで関係者との認識合わせを行いました。

批判や反対意見は、裏を返せばスタンバイを成長させたいという想いがあるからこそ出てくる、有り難い言葉です。そういった意見からプロジェクトのロードマップや機能仕様を適切に変更することができた経験もあります。目線のずれている箇所を洗い出し、すり合わせることに全力で向き合うことで、プロジェクトメンバーの一体感を高めることができたのではないでしょうか。

３．QCDSに沿って、プロジェクトを管理する
最後に基本的なことですが、プロジェクト管理においては、「QCDS」（品質:Quality、予算:Cost、納品:Delivery、スコープ:Scope）という管理指標があります。プロジェクトマネジメントをされている方にとっては当たり前のことだと思いますが、私は基本に忠実に「QCDS管理」を大切にしています。

また、スタンバイのフェーズではMVP（Minimum Viable Product）開発も意識する機会が多いです。MVPとは、一般的に「顧客にとって、価値が提供できる最小単位」として要件を定義することですが、リリースに必要なスコープを絞ることでデリバリーを早め、機能追加・改善のサイクルを早くまわすことができます。

実装が進むにつれて工数の見積もり精度も高くなるため、「リリースするに足る最小単位」の基準を決めておくことで、リリース日の延期が必要かどうかを早めに判断できます。さらに、開発を進めていく中では、「あれもやりたい」「これもやりたい」ということが、常に出てきます。このような場面においても、プロジェクトのMVPやQCDS基準を基に議論することで、「デリバリー期日に間に合う範囲で、このWANT要件を追加できないか」などのスコープ調整の提案もしやすくなります。

プロジェクトが進行する間、共通の判断軸を基に議論することで、結果として手戻りを少なくし、プロジェクトの進行スピードを一定に保つことができます。

-ありがとうございます。言うは易し行うは難しですが、3点とも城本さんは、ごく自然に行動されているなと感じました。上記のような「プロジェクト推進術」をお持ちの城本さんでも「Apply URL プロジェクト」において、「スムーズに進まないこと」や「スムーズに進まなさそうなリスク」はなかったのでしょうか？

城本： 機能をリリースすることに関しては、あまりスムーズにいかないという場面はなかったと思います。ですが、「Apply URL」は、ただ作っただけでは意味がなく、企業様に導入いただかないと求職者様に体験していただけません。導入する・しないはもちろん企業様が判断されるので、導入が進まずに作ったものが無意味になる事態は、このプロジェクトにおいて私の力では調整がしにくいリスク要素だと感じていました。

そのため、セールス部門への相談やヒアリングは丁寧に行いました。機能に対して好意的な印象を持っている企業様や、導入可能性のある企業様とのコミュニケーションを代替していただき、リリースのタイミングについても、他の施策との抱きあわせで、企業様が「このタイミングならまとめて対応できる・導入しやすい」という時期にデリバリー時期をあわせることをプロジェクトゴールに含めました。良いプロダクト作りは開発だけの視点では、成し得ません。開発・企業・ユーザーにとって「三方が良い状態」を目指すことができたことも、プロジェクト成功に起因していると思います。