意思決定を組織の機能として据えて開発が顧客と事業に向かい続ける体制を作る
マネジメントが掲げる事業ゴール、顧客が本当に求めている価値、開発チームがいま開発しているものが、少しずつ乖離していきます。そのズレを解消し、開発リソースが顧客の幸福と事業成果のための仕事に集中している状態をお客様と共同で実現します。代行・アドバイザリー・組織設計を事業段階と体制に応じて組み合わせます。
プロダクトマネジメントは、限りある開発リソースを顧客の幸福と事業成果のための仕事に集中させ続ける組織の機能です。
開発リソースは有限で、放置すると目の前の要求や割り込みに消費されていきます。その流れを顧客の幸福と事業成果へ向け直し続けるのが、この機能の役割です。
これは PdM を誰か 1 人の職能として配置するだけでは実現しません。顧客に提供する価値の定義と管理、意思決定の権限・責任・基準・場、検証のサイクル、実施しないことの管理を、組織の機能として設計してはじめて、開発リソースが 2 つのゴールに向かい続けます。
最優先事項が年度中に何度も変更され、意思決定のたびに前提が変化する
マネジメントが示すゴールと現場が理解しているゴールが乖離し、四半期の話をするたびに議論が最初からやり直しになる
追っている KPI の理由が顧客・競合・事業モデルの視点から言語化されておらず、施策の議論がマネジメントの直感に依存する
遵守すべき規制・コスト・技術的制約が明文化されておらず、実装フェーズで「そもそもこれは無理」が発覚する
四半期ロードマップが毎月変更され、気が付くとリターンの低い機能と施策ばかりが増加する
開発スプリントの半分が割り込み対応に消費され、事業成果を左右する施策が翌四半期に先送りされ続ける
技術負債・アーキテクチャ選択・コスト制約が優先度の議論から欠落し、後で「開発できない」が発覚してロードマップを組み直すことになる
実施しないと決定した施策が半年後に静かに復活し、同じ議論を反復している
週次の会議も意思決定ログもなく、重要な意思決定ほど月単位で停滞し組織が前進しない
現場が意思決定待ちで作業を止め、開発リソースが事業成果ではなく効果の薄い作業に消費される
何を検証するための機能・施策なのか定義されておらず、実態として同じ仮説検証を反復する
意思決定の根拠と採用されなかった選択肢が記録されず、後から誰も検証できない
外部支援や 1 人の PdM に依存しており、その人の離脱や支援の終了とともに意思決定のサイクルが止まる
意思決定が特定の人に集中し、他の人への知識とスキルの移転が進まない
意思決定の一部を現場に委ねたいが、委ねるための情報と権限の設計がなく、マネジメントが最後まで意思決定に張り付く
PdM を採用したい / 育成したいが、そのための型が組織に蓄積されておらず、後任が着任しても同じ議論を最初からやり直す
KDOT の PdM 支援の担い手は、スタートアップなどのマネジメントに当事者として関与した経験を有するメンバーです。様々なビジネスドメインと事業ステージで培った技術力をもとに、意思決定に参画します。開発リソースを顧客の幸福と事業成果のための仕事に集中させ続けるうえで、KDOT 固有の強みは次の 3 つです。
外部からの分析ではなく、実際に事業ゴールを設定し、投資を意思決定し、組織を構築してきた経験を有するメンバーが意思決定に参画します。意思決定責任を負ってきた経験から、事業視点をそのまま提供します。
KDOT は建設テック、不動産、金融、SaaS、メディア、EC など様々なビジネスドメインで、ゼロイチのスタートアップから成熟期の企業までのプロダクト開発に携わってきました。どのドメインのどのステージでどんな技術意思決定が事業成果に結びつくかのパターンが経験知として蓄積されており、特定業界だけを経験してきた立場では得られない、意思決定の精度と選択肢の幅を有します。
多様なドメインとステージを経験してきたからこそ、実装や運用のフェーズで顕在化する問題を、優先度議論の段階で先読みできます。実装段階で実現できないことが発覚してロードマップを組み直す、リリース後に運用コストが急増する、事業ステージの変化にアーキテクチャが追随できない、といった問題を意思決定の段階で防ぎます。
対象事業の意思決定でどこがボトルネックになり、事業成果や顧客の幸福とどこで乖離しているかを、マネジメント・現場・技術それぞれの視点から分析します。表面的な課題ではなく背景の制約や暗黙の前提までステークホルダー間で言語化して合意します。この段階で把握した問題の精度が、支援スタイルの組み合わせ方と、プロジェクト全体のリターンを左右します。
顧客・競合・事業モデルの理解を組織の共通言語にし、顧客に提供する価値、なぜこの指標を追うのか、何の制約があるのか、どの問題に対して誰が最終意思決定責任者かを明文化します。皆が同じ言葉で同じ問題を理解することで問題解決の前提をそろえます。
大方針が確定した上で、日々の意思決定を運用する仕組みとして、ロードマップ、仮説検証と調査実装のプロセス、会議体、意思決定に使用する資料を設計し、実際の運用を開始します。設計だけで終わらせず、仮説検証による優先順位の変更や、戦略転換が発生した際の更新プロセスまで、最初の数サイクルで実装します。
運用サイクルを数回転させ、レビューが次の検証に結びついて学びが組織に蓄積される型を安定させます。並行して、意思決定の遅延・前提の齟齬・優先度の揺れをふりかえりから抽出し、会議設計と意思決定ルールを、事業成果と顧客の幸福の両方を目指す意思決定が継続する状態へ調整します。
意思決定権限、意思決定ルール、学びの共有と引き継ぎを組織側に定めます。PdM を担う人が交代しても、意思決定の質と顧客理解の反映が維持され、学びのループが回り続ける体制を残します。必要に応じてアドバイザリーで並走し、体制が維持されているかを確認します。
このサービスで取り組んだ事例です。
製造業向けにソフトウェア製品を提供する企業との取り組みです。同社は工場の電力を見える化する機能を製品に追加したいと考えていましたが、社内の開発者だけでは手も知見も不足していました。電力計の接続から、データを工場の判断に活用できる形にするところまでを開発支援会社の KDOT に一括で委託し、同社は着手から約 4 か月でこの機能を製品に追加して工場へ販売できるようになりました。納品後の約 9 か月は KDOT が運用を担い、支援が終了した現在は同社が自ら運用を継続しています。
事業の課題や技術的な悩みなどどんなことでもお聞かせください
