作戦の核心内容は何か（作戦の目的は何か）

手術の結末は？

運用面では、実はまだ検討すべき内容や課題が山積しています。この記事では、著者が運用に関する自身の見解をいくつか共有します。見てみましょう。企業と運用、運用と製品マネージャーの関係をより深く理解するのに役立つかもしれません。

本日も引き続き、運用に関する見解をお伝えし、皆様のお役に立てれば幸いです。

企業が運用職を持つかどうかは、多くの場合、企業のビジネス プロセスに問題があるかどうかに関係します。オペレーションポジションは、ビジネスポジションの能力モデルがビジネスの継続的な発展に対応できない場合（ビジネスオペレーションで問題が顕著になる場合）にのみ作成されます。そのため、業務のグレーゾーンにオペレーション職が発生するケースが多くなります。

例えば、toCのユーザーオペレーションを見てみると、主に新規顧客の誘致、アクティビティ、プロセス、決済、コンバージョンなどの面で顧客データを改善するためにさまざまな方法と戦略を使用しています。

従来のビジネスでは、新規顧客の獲得やコンバージョンは実際には営業担当者によって行われていますが、営業担当者の能力は個々の顧客での突破口を作ることに集中していることがよくあります。大量の顧客とどのように成約するかという能力要件と方法・戦略の両方が不足しているため、オペレーションを通じて大量のユーザーを誘致し、コンバージョンするという課題を解決するために、Cエンドのユーザー側にオペレーションポジションが設けられています。そのため、会社の事業が非常に順調かつ流動的に進んでいる場合、その会社は業務担当者を採用しないことがよくあります。

これは実際には、toB ビジネスと toC ビジネスの違いによるものです。 C エンドユーザーは個人であるため、ユーザー像は異なりますが、ニーズや人間性は同じです。ユーザーには個性よりも共通点が多いため、Cエンドビジネスではデータを通じてユーザー間の特定のパターンを発見し、製品を最適化できる場合が多くあります。

B 側のユーザーは企業であり、顧客はビジネス上の問題が解決できる場合にのみ料金を支払います。企業によって抱える問題は異なるため、ユーザーの個別性が共通性よりも重要になり、データ分析だけで製品を最適化することは不可能な場合が多くあります。同時に、B 側顧客の平均注文額は大きい場合が多いため、製品の最適化のために運用人員を投入する価値もあります。

実際にはそうではありません。 B サイドの製品オペレーションは、多くの場合、製品マネージャーの補助として機能します。ビジネスの複雑さにより、B サイドの製品の設計はより複雑になることがよくあります。 B サイドのプロダクト マネージャーが C サイドのプロダクト マネージャーのように、製品の設計に加えて、製品のドキュメント作成、ユーザー トレーニング、顧客の問題処理、ユーザー リサーチなどの責任も負う場合、多忙になりすぎます。したがって、B サイドの運用では、製品ツールキットの出力、ユーザー トレーニングと問題の処理、顧客の使用シナリオに関する詳細なビジネス理解など、これらのタスクを担当することがよくあります。両者の協力により、より良い製品を一緒に作ることができます。したがって、製品は子供を産み、オペレーションは子供を育てるので、 C 側よりも B 側の方が適しています。

これは、C エンドのビジネス プロセスが比較的単純であり、製品がリリースされた後に、オペレーションを使用してユーザーのトランザクションを促進できることが多いためです。しかし、Bエンド顧客の意思決定プロセスは複雑であり、顧客の取引や再コンバージョンを促進するためにはマーケティング、営業、実装など複数の部門の協力が必要です。

そのため、一方では、製品の状況をタイムリーかつ正確に各部門に伝える必要があり、他方では、複数の部門の協力と連携に対する要求も比較的高くなっています。そのため、オペレーション部門では、製品トレーニングの実施、販売ツールキットの作成、複数部門間のコラボレーション プロセスの整理と最適化を行う必要があります。

一方で、ターゲット顧客の構成は異なります。私たちは皆これを知っているので、これ以上話しません。根本は、Bサイドビジネスのインターネットレベルがまだ比較的低いことです。 C面のように正規化・デジタル化できないコンテンツも多く、B面の製品運用の作業は非常に重いものとなります。そのため、国は現在、企業がデータをクラウドに移行して製品のデジタル変革を実現し、toBの全体的な効率を向上させることを推奨しています。

オペレーションに数年間携わった後、悲観的になり、最終的にはオペレーションの存在意義がなくなるのではないかと感じていると不満を言う人はたくさんいます。ある観点から見ると、これは確かにその通りです。結局のところ、オペレーションは問題があるために設けられたポジションです。問題が解決されれば、この立場は無意味になります。しかし、別の観点から見ると、理想と現実のギャップは依然として非常に大きいです。オペレーションが不要になるという理想的な状態は実現されない可能性があり、オペレーションの終了は特定の役員職で決まるものではありません。それはむしろ概念やアイデアであり、企業全体の運営は運用担当者の追求です。

最後に、私の意見を述べさせてください。すべては操作可能です。

B サイドのビジネスを例にとると、すべての B サイド企業には、製品の研究開発、マーケティング、販売、実行 (実装)、顧客サービス、その他のサポート部門 (財務、人事など) など、複数の部門が存在することがよくあります。各部門は明確な分業体制を持ち、独自の職務を遂行します。

生産研究部門は主に製品の研究開発と設計を担当し、実際の業務状況と上司のニーズに基づいて製品設計を実行します。設計が完了したら、技術開発が開始されます。発売後の製品プロモーションは他の部門が担当します。顧客の使用期間中、さまざまな要望が継続的に寄せられ、評価を経て製品の改良が行われます。

マーケティング部門は、顧客情報の取得、整理、配布を担当します。多くの場合、アクティビティやコンテンツを通じてオンラインおよびオフラインのチャネルを通じて顧客リードを獲得し、販売コンバージョンを促進します。

営業部門は顧客転換の責任を負います。マーケティング部門から提供された顧客リードや、自らリソースを見つけてターゲット顧客に商品を紹介し、顧客との取引を促進します。

実行部門は、顧客が契約を締結した後、具体的なプラットフォームの構成と使用を担当し、顧客の使用効果に責任を負います。 SaaS 製品の場合は、顧客の使用中の顧客とのコミュニケーションを担当する別のカスタマーサクセス部門が設立されることが多いです。

上記の各リンクには問題がある可能性があります。問題が明白または顕著な場合は、職務要件（運用）が発生します。

R&D 内の製品設計能力の不足、製品機能の複雑化、他部門との連携の難しさなどの一連の問題により、製品マネージャーが製品機能の最適化を支援し、関連する問題に対処し、外部とのコミュニケーションを担当する製品オペレーションのポジションが生まれます。

マーケティング部門が非効率で、リード数が少ない、またはリード変換率が低く、製品の機能を市場行動に効率的に変換できない場合は、製品を市場に変換して運用する責任を負う製品マーケティング運用のポジションが作成されます。

営業部門の作業負荷が重く、業務プロセスが標準化されていない場合は、対応する営業オペレーション職が設けられ、営業プロセスを整理し、関連するSOPを作成し、営業業務の正式化とシステム化を推進する責任を負います。

実行部門の製品があまり使われていない場合や、ユーザーからのフィードバックが悪い場合は、それに応じて実装運用ロールが作成されるか、製品チームが運用担当者にサポートを提供するよう手配します。 SaaS 製品のカスタマーサクセスも代替製品運用のひとつです。

つまり、操作は実際にはどこにでもあることがわかります。重要なのは、運用の立場ではなく、運用の考え方です。さまざまなビジネス シナリオであらゆるポジションを簡単に処理できることが、実際の運用です。皆さんがフルスタック運用の専門家になれることを願っています。

この記事はもともと @思无邪 によって Everyone is a Product Manager に掲載されました。許可なく複製することは禁止します。

タイトル画像は、CC0 プロトコルに基づいて Unsplash から取得したものです。

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