このエントリーは with Advent Calendar 2025 の 22 日目の記事になります。

■ はじめに

こんにちは。そしてはじめまして。
新卒で with プランナーとして入社してもうすぐ4年目に突入します、@genpaku_dayo_ne です。
普段は非エンジニアとして働いていますが、このアドベントカレンダーというお祭りを少しでも盛り上げられればと思い、初めて執筆します🎨

今回は、過去の施策開発で痛感した「失敗談」と、それを乗り越えるために実践し学んだ「エンジニア連携のポイント」について共有したいと思います。

「プランナーだけで仕様を固めきろうとせず、連携が必要な箇所を見極めてコミュニケーションする」ことの重要性が、同じような立場の方に少しでも伝われば嬉しいです。

■ 前提

私が所属する with のプランナー職は、いわゆるプロダクトマネージャー（PM）に近い役割を担っています。

企画と開発ディレクションをメインで担当
仕様策定時や開発中の相談など、直接エンジニアとやり取りすることが多い
「いかに企画の質を上げ、開発効率を高めてROI（投資対効果）を最大化させられるか」にコミットする

開発と密接に関わるため、理想を言えば私自身に十分なエンジニアリング知識があれば良いのですが、それは現実的ではないかつ、あったとしても with のエンジニアにしか分からない領域が無限にあると思います。

そのため、プランナーはいかにエンジニアと上手に連携できるかが、非常に重要になります🔥

🌀 きっかけとなった「失敗」

かつて担当した施策にて、開発メンバーで振り返りを行った際に以下のような反省点がありました。

課題	詳細
仕様の考慮漏れ	復帰処理や条件分岐を実装面とあわせて十分に考慮できていなかった。
数値計測の不備	取りたい数値が取れず、振り返り時に追加実装が必要になった。AndroidとiOSでの計測方法が異なっており、アナリストの算出コストが増えた。

▼振り返りの一部

エンジニアやデータアナリスト双方に手戻りや余計な工数が発生してしまったこの経験から
「仕様策定段階でエンジニアと確実に連携し、最適な形を一緒に作るフロー」へ改善しようと試みました。

実体験と改善を実践する中で学んだ2つのポイントを紹介します。

以下は、細かい手法の説明ではなく連携するポイントとその考え方の共有です。
「絶対にこうすべき！」というものでは全くないので、取り組みの一例と認識してください。

✔ ポイント1：仕様の考慮漏れ対策

結論、これに関しては「プランナーだけで完璧な仕様書作成は不可能」です。
ただし、エンジニアと適切な連携をすることで解消できるといえます。
以下は実際にあった事例の一部です。

復帰処理

「どの画面・どんな状態」でアプリをキルしたら、「どの画面・どんな状態」で復帰するのか？
これを実装都合が分からないプランナーがユーザー体験優先で決めると、実は開発上都合が悪い...なんてことが起こり得ます。

【実際にあったエンジニアからの相談】

「A-8画面でアプリキルした場合の復帰先は、A-5かA-8か統一できないか？ A/Bテストでパターンのステップ定義が異なると、実装が煩雑になる」

当初はアプリキルした時のユーザー状況を考慮しベストであろう箇所で定義した結果、A/Bテストで異なる画面での復帰になっていました。
しかし、エンジニアが提案した内容でも大きくユーザー体験を阻害するものではないと判断し、実装負荷の少ない仕様で着地させることができました。

入力の条件、バリデーションの考慮

どんな条件で進むことができて、どんな時にエラーは発生するのか？
仕様策定の段階ではエッジケースなどの考慮が漏れていて、開発途中でエンジニアから指摘してもらう部分がありました。

💡学び

どんな小さな仕様でも、実現したいユーザー体験と開発都合をすり合わせることが重要
- プランナーは、仕様の意図や温度感を共有しておくと良い
想定外は必ず出る＆プランナーだけでは気づけない仕様もある
- 既存仕様との差分や想定外のケースは実装中にエンジニアが気づくことも多い
- すべてのユースケースや考慮事項を事前に洗い出すのは非効率。随時エンジニアと連携して確認することが重要

✔ ポイント2：データ分析・数値計測の不備対策

施策リリース後、「あれ、このデータ取れてない…？」と青ざめる経験はもう二度としたくないですね。
実際に計測箇所を追加してA/Bテストを再実施しました。😢

仮説通りに成功する施策ならまだ良いですが、そうでない場合は学びを得たりネクストアクションにつなげるための要因分析が非常に大事になります。

ここでは改善策として、「実装（How）」の話をする前に「知りたいこと（Why）」を明確にする手順を踏みました。

ステップ①：アナリストとのすり合わせ

まずKPI設定と同時に、「仮説が外れた場合の要因特定のための数値」を洗い出します。
「具体的にどう実装するか」ではなく「これが知りたい」を明確にしておくことで、後のエンジニアとの相談がスムーズになります。

【実際にアナリストとのすり合わせで用いた資料イメージ】

想定されるユーザー課題と指標の組み合わせを作成し、知りたいことをすり合わせました。

ステップ②：エンジニアとのすり合わせ

「知りたいこと」をもとに、どのイベントをどの粒度で実装するか相談します。

イベント追加における観点
- 集計方法の工夫で間違いなく正確なデータがとれるのか
- 増えすぎるとメンテができなくなるので、むやみやたらに増やすのは良くない
- シンプルかつ汎用性があるものが良い。それ専用のイベントとかはあまり良くない
  → 集計方法の工夫で別のデータを取れるメリットがある

【最終的にFIXした実際の内容イメージ】

既存のイベント活用＆汎用的なイベント設計と集計方法を工夫することで、知りたいことに対してかなりシンプルなイベント設計に！

💡学び

どこまでイベントを取得するかは得られるデータの量・質とのトレードオフのため、やりすぎないよう注意する
上記は一例であり、相手や施策規模・状況に応じて柔軟に最適な進め方を模索することが重要
⇒ とにかく相手とのコミュニケーションが大事‼️

■ おわりに

これらの取り組みの結果、エンジニアから以下のような言葉をもらえました。

「プランナー・アナリスト・エンジニアでここまでしっかり時間をとって設計したことはなかった。有意義な時間で良かった」

これだ！という企画になるまでプランナーは1人で模索しがちですが、「仕様を固めてから依頼する」ことだけが正解ではなく、「早い段階で巻き込んで、一緒に設計する」ことが、結果として手戻りを防ぎ、お互いが気持ちよく開発できる近道だと実感しました。

もちろんプロジェクトの規模や状況によりますが、一つの事例として参考になれば幸いです。