製品運用の仕組み（To B企業向け製品管理システムの構築方法）

To B企業向け製品管理システムの構築方法

2023年9月9日〜10日、Everyone is a Product ManagerとTencent Lecture Hallが共催する【2023 Product Manager Conference（北京駅）】が盛況のうちに終了しました。崑崙デジタルインテリジェンスの製品管理専門家であり、IPDシステム構築プロジェクトのプロジェクトリーダーであるBian Quanzhou氏が、「B企業が製品管理システムを構築する方法」と題した講演を行いました。この記事はスピーチの書き起こしです。会議の録画が視聴可能になりました。購入してリプレイを視聴するには、ここをクリックしてください: https://996.pm/7gX2B

本日ご紹介するトピックは「B 企業が製品管理システムを構築する方法」であり、次の 3 つの部分に分かれています。

多くの企業はプロジェクトから始まります。プログラムを開発する場合、同じ機能上の問題に対して、初期段階でコードを記述することで、その問題を解決することができます。問題が頻繁に発生するにつれて、コードは徐々に API へと進化します。プロジェクトでも同様です。お客様への納品にあたっては、同じ問題領域のプロジェクトを完了した後、後続の類似プロジェクトが多数あることがわかった場合は、どのように製品化するかを検討します。

このロジックはビジネス ユニットまたは BG に拡張でき、次のパターンになります。

まずビジネスバリューチェーンに焦点を当てます。通常、企業が十分に大きくなると、組織的な分割が発生します。組織区分は一般的にバリューチェーンに基づいています。

同じビジネスドメインでも複数のプロジェクトが発生しますが、プロジェクト間の要件は異なります。特定のベースライン バージョンに基づいて反復的なアップグレードが行われると、複数のバージョンが表示される場合があります。バージョンが複雑になると、コアコードを担当する担当者に業務が過度に依存することになり、人事異動や退職調整などに頭を悩ませることになります。時間が経つにつれて、納品コストがどんどん高くなる可能性もあります。現時点では、企業は製品化を検討する必要があります。

製品化する必要はあるのでしょうか？今後プロジェクトがない場合は、現在のプロジェクトを完了するだけでよく、製品化する必要はありません。しかし、同社がこの分野でさらなるチャンスを発見し、将来的にさらに多くのプロジェクトが生まれる可能性があると判断した場合、コスト削減を検討する必要がある。

理想的な形では、異なるビジネスドメインの製品間の共通性に基づいて、製品プラットフォーム、さらにはテクノロジープラットフォームを形成できます。これにより、特にコンポーネント化後の全体的な配信速度が向上し、安定した品質の配信を実現できます。

まとめると、事業部門の観点から見ると、重複開発が削減され、コストが効果的に削減され、同時に、高効率と優れた品質により、顧客は自然に満足することになります。

上図は「細い腰の図」とも呼ばれ、ビジネス階層化とも呼ばれ、内部レベルと外部レベルに分けることができます。

社内の観点から見ると、企業はさまざまな製品をサポートするためのテクノロジー プラットフォームと製品プラットフォームを構築する必要があります。製品は外部の顧客にサービスを提供し、顧客中心であり、顧客の視点から新しいソリューションを模索する必要があります。

解決策は何ですか?水平ソリューションと垂直ソリューションの 2 つのタイプがあります。製品の組み合わせに基づいて形成される比較的固定されたソリューションを水平ソリューションと呼びます。ある意味、水平ソリューションは特別な製品です。垂直ソリューションは、より多くのサービスを追加し、配信指向および業界指向です。

製品タイプ HPCM に重点を置くこともできます。

• H（専門サービス） - アクセンチュア、ChinaSoft International、カスタマイズ開発などの人材増強。
• P (ソリューション タイプ) – SAP などの付加価値パートナーによる実装が必要です。
• C (製品タイプ) - トレーニングを必要とする、JIRA や Glodon などの標準化された製品チャネル追加タイプ。
• M（プラットフォーム型）——BaiduやWeChatなどのサーバー追加型。

モデルの境界は必ずしも明確ではなく、中間に遷移状態が存在する場合もあります。

では、製品化によってどのようなメリットがもたらされるのでしょうか?顧客満足度の向上、運用コストの削減、収益性の向上に役立ちます。最終的には、すべてが会社の成功につながります。

製品は、製品マネージャーと製品オーナーによって管理される必要があります。製品管理はローカルな視点に限定することはできません。製品管理をうまく行う方法について議論する前に、まず会社がどのように製品を開発しているかを理解する必要があります。

製品を開発するには？現在広く認識されているアプローチの 1 つは、統合製品開発 (IPD) です。

『偶然から必然へ：ファーウェイのR&D投資と管理の実践』という書籍には、ファーウェイの製品開発プロセスが紹介されています。

1. 市場管理プロセス、何をすべきかという問題の解決。
2. 需要に基づいた需要管理プロセス。
3. 製品開発プロセス：製品を作ることを決定した後、どのように段階的に順序立てて進めていくか。
4. 技術開発プロセスでは、技術開発と製品開発の間に非同期の協力関係が存在します。

では、IPD は本当にソフトウェア業界には適していないのでしょうか?基本的にはIPDが適していますが、HuaweiのIPDは適していません。 Huawei の IPD は、強力な Huawei 特性を備えたベスト プラクティスです。

どの企業も独自の統合製品開発システムを構築できます。たとえば、ソフトウェア分野では、3 カ年計画を SP、年間運用計画を BP と呼ぶ DSTE 戦略計画プロセスを確立できます。 DSTE プロセスを通じて、作りたい製品を輸出し、製品を合理的に計画し、製品開発プロセスに従って製品ライフサイクルを管理し、技術開発プロセスに従って技術開発を行い、製品開発と非同期に連携することができます。

すべての製品開発モデルは、企業の現実とビジネスの性質と組み合わせてベストプラクティスを形成する必要があります。例えば、ある有名なソフトウェア会社は2012年にHuaweiのIPDプロセスを導入しました。何年もかけて、HuaweiのIPDの考え方とソフトウェア業界の実際の状況を組み合わせて、自社のソフトウェアに適した開発方法を形成しました。また、外部の専門家とのコミュニケーションや社内交流を実施し、比較的安定したソフトウェアIPDフレームワークを形成しました。

計画プロセスでは、どのような製品や技術を使用するかという問題を解決し、社内開発、サンプル顧客検証、大規模プロモーション、上場廃止などの段階に応じて製品ライフサイクルを管理できます。 C 企業の場合はグレースケールを検討し、B 企業の場合はモデル顧客とモデルチャネルを検討する場合があります。

ソフトウェア業界はハードウェア業界とは異なり、またソフトウェア業界内の企業間でも違いがあるため、ビジネスドメインの性質に基づいてベストプラクティスを形成する必要があります。

Huawei の IPD 開発プロセスにおける憲章段階、つまり「プロジェクトの確立」にも特別な注意が必要です。この概念は、インターネット製品分野におけるバージョン概念とは異なります。インターネット製品分野やソフトウェア分野では、製品コンセプトは主に市場セグメントに従って定義され、問題領域は安定しており、バージョン反復は製品のバージョンステータスのみを参照します。しかし、Huawei の IPD プロセスはまったく異なります。製品は異なるバージョンを指しますが、ソフトウェアインターネット分野では、WeChat 9.0 と WeChat 10.0 は同じ製品です。

製品開発の仕組みがわかったところで、プロダクトマネジメントの目的について考えてみましょう。製品の企画や製造には、特定の方法と原則が必要です。下の図に示すように、レイヤーの 1 つは需要管理です。戦略計画、ロードマップ計画、製品プロジェクトの確立、製品ライフサイクルにはすべて、需要の入力が必要です。製品チームは需要管理方法に従って作業し、会社の管理チームも需要管理方法に従って管理する必要があります。

大規模な組織にとって方法論は非常に重要です。チームであれ、上級管理職であれ、管理と統制をうまく行うには、方向性が正しいか、進捗は正常か、ルール通りに物事が進んでいるかに注意を払う必要があります。管理および制御プロセス中にギャップが見つかった場合、管理チームは権限委譲の次のステップに備え、ビジネスを詳しく調査し、協力し、結果に焦点を当て、能力に焦点を当てる必要があります。現時点では、会社の製品管理を担当する製品管理の専門家の専任チームが社内に存在する可能性があります。もう一つの重要な活動は、製品マネージャーのチームを構築し、彼らを選定、トレーニング、維持、および排除することです。製品の数が増えるにつれて、デジタル製品の管理もしっかり行う必要があります。

戦略的な計画が主な方法論です。業界には、下図に示すように、BLM モデルという一般的なモデルがあります。

BLM モデルを実行するときは、まずギャップ分析を行う必要があります。1 つはパフォーマンス ギャップ、もう 1 つは機会ギャップです。このうち、パフォーマンスギャップとは戦略サイクルで設定した目標結果と最終的な実行結果のギャップを指し、機会ギャップとは前回の戦略サイクルでは特定されなかったが、現在の実行プロセスで発見された要因を指します。

ギャップは、正のギャップと負のギャップに分けることもできます。目標が達成されるかどうかに関わらず、その理由を見つける必要があります。

さらに、ギャップを見つけるには内向きに目を向ける必要があり、市場の洞察を得るには外向きに目を向ける必要があります。市場洞察は、顧客、市場、競合など、外に目を向けます。これを読んだ後、ギャップに基づいて戦略意図と戦略サイクルを策定し、イノベーションの焦点を形成し、どのアイデアとリソースが比較的優れていて、目標をよりよく達成できるかを考え、ビジネス設計を形成する必要があります。

ビジネス設計を行った後は、BEMデコードを実行し、ビジネス設計を実現するためにどのような人材や組織が必要かを考える必要があります。戦略計画を目標として考え、その目標から逆算して、翌年の目標を細分化することができます。

分解プロセスでは、財務、顧客、内部業務、学習と成長の目標の定義を明確にし、それらの間のサポート関係を見つけて、現在の目標を完了する必要があります。同時に、会社の開発機会が良質かつ持続可能であることを明確にし、現在の目標を達成しながら継続的な発展を確保する必要があります。

さらに、収益経路とアクション プランを細分化して、製品マネージャーと地域マネージャーが「メッシュ」を形成し、戦略の実現可能性を向上させる必要があります。正確な業績予測は、市場価値管理が求められる上場企業にとって特に重要です。

製品ロードマップの計画レベルでは、各製品をどのように計画するかを明確にする必要があります。優れた製品ソフトウェアは、反復のためにモジュールを徐々に追加することで、より多くの顧客の問題を解決できます。これらの問題に独立した価値ポイントがある場合、それらを市場セグメントと呼ぶことができます。製品実装の過程では、市場セグメントの参入ポイントを見つけ、どのように拡大・運用していくかを考える必要があります。

1. 単一の市場セグメントを拡大するにはどうすればよいでしょうか?
2. 市場セグメントはどのように進化するのでしょうか?
3. すでにリードしている市場でどのように事業を展開すればよいでしょうか?

製品プロジェクトを立ち上げる際に市場をセグメント化するにはどうすればよいでしょうか?次の図のロジックに従うことができます。

個人的には、市場を特に狭い範囲に細分化するのは難しいと思うので、顧客層を細分化して、市場に足がかりを築き、自分たちの特徴を形成していくべきだと思っています。

製品、価格、チャネル、マーケティング、サービスがポジショニングをサポートします。その中で、価格は非常に重要です。価格は顧客に価値を提供するだけでなく、私たちの利益を決定します。したがって、価格設定はビジネス運営において非常に重要なテーマです。

製品プロジェクトが開始された後、段階的にどのように市場に投入すればよいでしょうか?ソフトウェア企業、特にSaaSサブスクリプションモデルを採用している企業は、プロジェクトの設立と研究から技術検証、代表的な顧客の検証、代表的なチャネルプロモーションに至るまで、一連のリーンプロセスをマッチングさせるのに適しています。その後、顧客への提供プロセス中に価格の合理性を証明する必要があり、モデルチャネルは企業のチャネルマーケティングに引き継ぐことができます。

需要管理は、需要の無限の流れをどのように管理するかという問題を解決します。特に、単に需要を機能に変えるのではなく、需要から価値へと問題を解決することが必要であることが強調されています。

管理および制御システムの構築には、気象ステーション、管制塔、リソース スケジューリングという 3 つの概念があります。

その中で、気象観測所は、製品登録、製品の進捗状況など、さまざまな手段を通じて、最も現実的で包括的な情報をタイムリーに取得することを指します。管制塔は測定です。専門チームは専門的な方法を使用して、場所間のギャップがあるかどうか、問題がどこにあるのかを調べ、その後のスケジュールと解決策を作成する必要があります。

その中で、管理と制御も階層化する必要があります。たとえば、大規模な企業では、会社がベースラインの問題を管理している一方で、事業部門は一般原則に基づいて異なる実践を行っている場合があります。製品管理チームをサポートするには、専用の管理および制御チームが必要です。製品の技術表は、製品の内容、製品テンプレート、製品ソー​​ス、製品後の戦略計画の調整など、管理と制御にとって非常に重要です。

下の図は IPMT の動作メカニズムを示しています。企業は、図に示すように階層的な管理と制御を実装できます。

PMBP は製品管理エキスパートの略です。このタイプの専門家は、チームに直接参加し、製品ラインに入り、協力して問題を解決することができます。

プロダクトマネージャーのチーム構築では、選択、トレーニング、維持、排除に重点を置く必要があり、また、プロダクトマネージャーの資格についても指導する必要があります。

図に示すように、BPは各事業ライン、各部門に配置され、同時にSSCを支援する必要があります。 SSC は日常的な管理と制御を担当します。 COE は方法論と専門的な指導を担当します。

会議の録画が視聴可能になりました。購入してリプレイを視聴するには、ここをクリックしてください: https://996.pm/7gX2B

この記事は、[2023 Product Manager Conference (北京駅)] で現地で共有されたコンテンツを、Everyone is a Product Manager のインターンである @张慕兰 が編集して公開したものです。

タイトル画像はカンファレンスサイトから引用

この記事で述べられている意見は著者自身の意見のみを表しており、人人士品夢家プラットフォームは情報保存スペースサービスのみを提供します。