問いの力で開発チームと「共創」する 〜非エンジニアPdMの実践プロセス〜

テックタッチでPdM（プロダクトマネージャー）を担っているkokiです。
最近は2歳の息子とディズニー映画の『ズートピア』を観るのが日課です。 私が一番好きなキャラはクロウハウザーです。優しくのんびりした雰囲気が和やかで好感を持てます。

はじめに

「技術がわからない自分に、一体何ができるのか？」 これは、非エンジニア PdM なら一度は抱える悩み・不安ではないでしょうか。
この悩みに対する私なりの答えは、技術的な正解（ How ）を出すことではなく、本質的な「問い」を投げかけることでした。 コードは書けなくても、ビジネスとユーザーの視点から「解くべき課題」の解像度を上げ、開発チームのポテンシャルを最大化することは可能です。
本記事では、私（※）が実践している「問い」を起点とした開発チームとの共創スタイルと、その具体的な思考プロセスをご紹介します。 PdM としてのスキルに悩み・不安がある方や、テックタッチの開発文化（ Co-Developers ）に関心がある方の参考になれば幸いです。

※私の経歴などは、入社エントリ（ BizからPdMへのチャレンジ　～なぜテックタッチを選んだか～）をご覧ください。

テックタッチの PdM って何をする人？

そもそもテックタッチの PdM はどんな役割を担っているのかを紹介します。 公開求人（2026年1月時点 シニアプロダクトマネージャー）の情報をもとに、生成 AI に要約してもらいました。

テックタッチのプロダクトマネージャーは、一言で言えば「お客様の『真の価値』を探求し、開発からビジネス展開までを繋ぐ事業推進者」です。 単に機能を作るだけでなく、ユーザーリサーチやデータ分析に基づきロードマップを描き、CS やセールスと連携して「どう届けるか」までを設計することで、非連続な事業成長（グロース）を牽引する役割を担います。

上記の通り、機能開発によるプロダクト価値向上だけではなく、ビジネスの成長にまで寄与することが期待されます。

さらに私なりの解釈を付け加えるなら『チーム全員が当事者意識を持って最高のものを作るための、土壌を整えるファシリテーター』の側面もあります。 私一人が正解を持って指示を出すのではなく、エンジニアやデザイナーがそれぞれの専門性を発揮し、納得感を持って意思決定に関われるように、情報や議論の場（＝土壌）を整えること。 テックタッチでは、そんな「チームでの共創」をリードする動きも求められると考えています。
私の場合、Biz（ビジネス職）の経験はありましたが、開発現場での経験は不足していました。具体的には、以下の経験が希薄な状態からのスタートでした。

• 開発の企画・ディレクション経験
• エンジニア・デザイナーとの実務的なコミュニケーション

Biz の方のなかには上の実務がどのようなものなのか、また、そこでどのような振る舞いが期待されるのかイメージできない方もいるかもしれません。 テックタッチでも上記の経験が活きるシチュエーションは当然ありますが、私はそれを補いながら期待役割を満たそうと今も試行錯誤しています。

プロダクトマネジメントの業務プロセスについて

プロダクトマネジメントの業務プロセスは一般的に以下のようなものになります。
1. Discovery（課題発見）
ユーザーの声やデータ分析から「本当に解くべき課題」を特定し、仮説を立てる。
2. Planning（企画・要件定義）
解決策を具体化し、優先順位と要件を定義してPRD（製品要求仕様書）を作成する。
3. Development（開発・実装）
開発チームと伴走し、とっさの仕様判断や品質確認（QA）を行いながら形にする。
4. Launch & Go-To-Market（展開）
機能リリースに加え、営業・カスタマーサクセスへのレクチャーや販促連携を行い、お客様へ価値を届ける。
5. Outcome（効果検証）
「成果（数値）が出たか」を検証し、その学びを次の改善サイクルへ活かす。

今回は PdM が特に開発チームとの共創を求められる、2の部分にフォーカスして話をします。

小規模な改修であれば、このプロセスは一方通行でスムーズに進みます。 しかし、大規模かつ不可逆な機能改修の場合はそうもいきません。一方通行では「定義漏れによる手戻り」や「情報量過多による認識齟齬」が起きやすくなるからです。
そのためテックタッチでは、要件定義の段階からエンジニアやデザイナーと積極的にコラボレーションするスタイルをとっています。

今回はそういった時の自分の思考や振る舞いを例に挙げて、どのように共創していったのかを記していこうと思います。

非エンジニア PdM が「問い」で共創するための3つのステップ

1. 解きたい課題の解像度を上げる

先述の Planning（企画・要件定義）の開始タイミングでは、PdMである私とエンジニア・デザイナーの間には、当然ながら解きたい課題に対する情報の非対称性が生じています。 ここでいう情報とは、課題の解像度とコンテキスト（後述2のステップ）です。まずはエンジニア・デザイナーの課題への解像度を上げる必要があります。

Planning開始時点で以下の4W（Who、What、Why、When）を説明します。説明の際は文書化に加え、時には図示・モックを利用します。

• Who：誰の課題を解きたいのか
• What：どんな課題なのか
• Why：なぜ解きたいのか
• When：なぜ今なのか

Planning の前に、まずは課題解決の価値を検証します。具体的には事業課題から逆算した優先度評価や、ユーザーインタビューなどを行います。これらを通じて、事業成長に寄与するストーリーを明確にイメージしておきます。そこで紡ぎ出された自分の主張を Planning の開始時点で説明するわけです。これによってメンバーの課題の解像度が上がります。

ちなみに、ここが最も Biz 出身 PdM のバリューを出しやすいポイントかなと個人的には思っています。お客様や自社のビジネスに対してどんなインパクトがあるのかを整理して判断する部分で、お客様や事業 KPI への距離が Dev（開発職）の方に比べると相対的に近いことが多く、イメージを持ちやすいからです。

2. 課題解決に際してのコンテキストを合わせる

解決したい課題の解像度は揃っているのに、なぜか議論が噛み合わないことはありませんか？ それはその課題を解決する際に考慮に入れておくべきコンテキストが揃っていないことに原因があるかもしれません。
例えば、解きたい課題の説明をしたところ以下のような反応が返ってきたとします。

• 今、既にある〇〇という機能を利用すれば、その課題は回避できるのではないか？
• 近接する課題として××というものもあると思うけど、なぜそれは今回解決しないのか？

他にもいろんな反応をもらうケースもあると思いますが、これらはある課題を解決したいときに考慮に入れておきたい前提条件（＝コンテキスト）の認識が揃っていないときに起こります。
コンテキストが揃っていないと、解決手段の制約や期待値にズレが生じ、結果として手戻りや噛み合わない議論が発生します。 技術に明るい PdM なら、技術的制約をある程度予見してカバーできるかもしれませんが、私にはそれができません。だからこそ、事前にコンテキストを言語化し、対話ですり合わせるプロセスを徹底しています。

具体的には以下のようなコミュニケーションをとっています。

• 課題の説明を一定終えた段階で、質問を受け付ける
• 「〇〇という機能を利用すれば回避できるのではと思ったが、確認したところ〜」といった形で想定質問を代弁しながら説明する
• 解きたい課題のスコープの定義で悩ましい部分を共有する

このように、メンバーに思考のきっかけを与え、対話を通じて自然とコンテキストが合うようなコミュニケーションを意識しています。

3. 問いを投げてソリューション案を磨き上げる

ここまでのプロセスを経ると要求及び要件が擦り合わせできている状態となり、PRD もほぼ出来上がっています。 これをもとにエンジニアやデザイナーが検討したソリューション案は、課題の解像度・コンテキストの情報が揃っていれば大きく想定とズレることはありません。

では、技術的に正しい案が出せる状態なのに、なぜ PdM が介在するのか。
それは、「ユーザー体験や事業価値の観点」を注入し、ソリューションをさらに磨き上げるためです。 私が自分で答えを出そうとするのではなく、「適切な問い」を投げかけることで、プロである彼らの思考を刺激し、より良い案を引き出すことに注力しています。
よく投げかける問いのポイントは先述の通り、ユーザー体験と事業に関わるものです。具体例とともに説明します。

ターゲットユーザーは、その機能を問題なく利用できるか

ソリューションは当初想定している課題を解決するものになっていると思いますが、ユーザーが機能を利用しないと課題は解決されません。よって、ターゲットユーザーの普段の行動やシチュエーションを考慮したときに、無理なく利用できるのかといった観点を確認しています。

▼ 問いの投げかけの具体例：
例えば、ユーザーが管理画面で操作できる範囲を制御できるようにする機能開発の検討が進んでいたときの話です。当初エンジニアからは、Slack のように「ワークスペース」を新たに作成できるようにして、ワークスペースごとに操作範囲を制御できるようにするという提案がありました。現行仕様を鑑みたときに当時最も最適、かつ、最小工数で実現できうるソリューション案でした。
しかし、当プロダクトのユーザーにとってあまり馴染みのない概念で、利用するには新たに覚えることが多いと感じられ、リリース後に利用されにくい・されるまでに時間がかかる体験になるのではないかと懸念されました。
その時に投げかけた問いは以下のようなイメージ（※架空の設定）です。

ターゲットユーザーは40~50代で、普段利用するツールは Teams。
管理画面に訪れる頻度は月1~2回程度。
彼らはこの機能を無理なく利用し始められるだろうか。
メンタルモデルと乖離はないだろうか。

ユーザー像や状況をイメージとして共有することで制約を理解することができ、より適した案を考えるきっかけを与えられたのではないかと思います。

コストに見合った開発となるのか

解決する価値のある課題を選定しているため価値があること自体は大きく揺らぐことはありません。しかし、その価値創出に見合うコストになるのかを確認する必要があります。
期待するリターンとその課題解決のソリューション開発にかかるコストを比較するだけならばシンプルですが、ソリューションの検討過程でスコープが当初より拡がってしまうケースがあります。
私が経験したものでいえば、下記のような場合にスコープが拡がったソリューション案になることがありました。

• 将来的に想定されるニーズを考慮した設計となる
• ここまでやらないと意味がない・期待を満たさないのではないかと考える
• このまま対応すると技術的負債になると考える

このとき拡がったスコープを、以下のような観点でエンジニア・デザイナーの意見を聞いて議論します。

• そのスコープの拡がりによって何が解決されるのか、なぜ必要と考えられるのか
• 当初の目的に対して過剰になっていないのか
• 本当に今スコープを拡げて着手すべきなのか、その判断は今できる/すべきなのか

▼ 問いの投げかけの具体例：
例えば、画面の特定位置にバナーを表示する「フローティングバナー」という新機能を開発したときの話です。 ユーザーの実現したいことは「画面のUI要素に依存せず、LP やウェビナーへの導線（CTA）を置きたい」というシンプルなものでした。
しかし、検討過程で「マーケティング施策として使うなら、より CTR（クリック率）を高める工夫が必要ではないか？」という意見が出ました。具体的には、表示時のアニメーションや、操作から数秒後に表示させる遅延実行などの機能拡充です。エンジニアやデザイナーならではの「より良い成果を出せるものにしたい」というポジティブな提案でした。
ですが、当時のリリースの主目的は「CTR の最大化」以前の、「そもそもこの機能が使われるか（UI 非依存の CTA 設置ニーズの検証）」にありました。その時に投げかけた問いは以下のようなものです。

今回検証したい一番の仮説は「リッチな体験による CV 向上」なのか、それとも「UI に依存しない設置場所の提供」なのか。
まずは「置けること」だけで価値を感じてくれる層がどれだけいるかを確認し、利用率などの数字を見てからリッチな機能を追加する判断をしても遅くないのではないか。

この問いをきっかけに、単に機能を削るのではなく、将来的な開発工数や不確実性も加味しながら「今、確実に取るべき実利は何か」をそれぞれの視点から議論することができました。
結果としてこのケースでは段階的な検証・リリースを選択しましたが、議論の末に「開発効率を考えれば、今まとめて実装したほうが良い」という判断に至ることもあります。

PdMの意見を通すことがゴールではありません。専門性を持ち寄り、不確実性とリターンのバランスを見極める。そして、チーム全員が納得できる「最適な着地点」を見つけることこそが重要なのです。

おわりに：技術がわからなくても、「問い」で貢献できる

入社当初、「技術がわからない自分に何ができるのか」と悩んでいた私ですが、1年間の試行錯誤を経て、ひとつの答えに辿り着きました。 それは、「技術的な正解（How）」を出すことだけが PdM の仕事ではないということです。
私たち非エンジニア PdM の最大の武器は、ビジネスやユーザーの視点から「解くべき問い（Issue）」の解像度を上げること、そしてエンジニアが最高のパフォーマンスを発揮できるよう「コンテキスト（前提）」を整えることです。 記事の中で紹介したステップを、改めてTipsとしてまとめます。

1. 解くべき課題の解像度を極限まで上げる
   「誰の・どんな課題か」「なぜ今やるのか」を言語化し、エンジニアと視界を合わせる。
   
2. コンテキスト（制約・前提）をすり合わせる
   議論が噛み合わない時は、前提条件がズレているだけかもしれない。対話を通じて情報の非対称性を解消する。
   
3. 「ユーザー体験」と「事業価値」の観点から問いを投げる
   技術的な提案を否定するのではなく、「ユーザーは無理なく使えるか？」「コストに見合う価値があるか？」という問いを投げかけ、ソリューションを磨き上げる。

これらを徹底することで、コードは書けなくても、チームのハブとなり、プロダクトの価値を最大化することは十分に可能です。

テックタッチには、こうした個々の強みを尊重し、エンジニア・デザイナーとビジネスサイドが対等な関係で議論し合える共創の土壌があります。
もし、私と同じように「技術への不安はあるけれど、プロダクトづくりに熱中したい」「チームで大きな課題を解決したい」と考えている方がいれば、ぜひ一度お話ししましょう。