製品運用に関する記事 (2 年! 製品から運用までの道のりで何を学んだか)

2年です！製品から運用までの道のりで何を学んだのでしょうか?

プロダクトマネージャーの仕事は複雑で、オペレーション業務もそれほど良くないと言われています。筆者は制作部門で2年間勤務し、苦痛で断片的な仕事も経験してきました。この記事は彼女の個人的な経験をまとめたものであり、皆様のお役に立てれば幸いです。

気がつけば、この職に就いて2年が経ち、最近、皆さんにお伝えしたい新たな知見がいくつかあるのです。

今日はオペレーションにおける最大の神話についてお話ししましょう。

実際には業務の成果の一部であるにもかかわらず、測定が難しく、体系的な結果を生み出すのが難しい些細なことに直面したとき、私たちは何をすべきでしょうか。

オペレーション業務に携わった学生たちは、次のような気持ちを抱いていると思います。

• 私は一日中雑用をこなし、些細なことで忙しく、体系的な成果は出ません。
• 手術の敷居がすごく低い気がします！どのインターンでもできるようですか？
• では、私たちの価値はどこにあるのでしょうか?未来はどこにあるのでしょうか？

プロダクト業界で10年以上働いてきたベテランとして、オペレーションに転向した後、新鮮さや情熱が薄れていくにつれ、この戸惑いを感じ始めました。

たとえば、あるとき、OKR 指標とは直接関係のないデータ指標が大きく変動していることが判明し、誰かがすぐにその原因を特定する必要がありました。たまたまデータチームの全員が非常に忙しく、私も非常に興味があったため、2時間以上かけて作業し、ついに隠された理由を見つけました。

たとえば、この仕事を終えると、他の部門が毎日私たちのところに来て、システムのバグやオペレーターのエラーの疑いがあると指摘し、原因と解決策を見つけるのを手伝ってほしいと頼んできました。そのため、毎週の日常業務では、誰かが監視する必要があるオンラインオンコールが常にいくつかあります。関連チームの製品と研究開発を促さないと、誰もタイムリーな応答を返せず、最終的には顧客体験と関心に影響を与えるからです。

根本的な視点から言えば、お客様や事業部門にとっての現実的な問題を解決することが重要です。

しかし、労働者の観点から見ると、それはそれほど重要ではないようです。これらは通常、OKR とは直接関係ありません。実利的に言えば、要約を書くとき、作業負荷はせいぜい 1 文でしか書けません。xx 製品の xx モジュールの xx データ指標の変動を毎日特定し、xx、xx およびその他のチームに毎日の最適化を指示します。顧客からのフィードバックを通じて x 個の製品のバグを発見し、修正を完了します。

それはごく普通の日常的なルーチンのように感じられ、驚くべき結果は生み出しません。

多くのチームリーダーの目には、これらの作業は労力に見合うものではないが、誰かが行う必要があるように映ります。そのため、運用部門では、これらの日常的な「価値の低い」作業を完了するために、敷居の低い人材を採用する必要があります。

残念ながら、仕事でそのようなことに対処するために多くのエネルギーを費やす必要がある場合、私たちの将来は終わってしまうのでしょうか?

実のところ、私はそれほど悲観的ではありません。私はこれらのことを次のように考えています:

何よりもまず、運用は商業運営において必要な保証です。コア目標の達成であれ、顧客体験の保証であれ、それらはすべてオペレーション（運営）の機能範囲に含まれ、報酬を受け取ったら必ず実行しなければならない仕事です。

第二に、労働者の観点から、日々の生産量とコア生産量のバランスをどのようにとるか？

ポイントは2つあります。

どんなに些細なことがあっても、毎日 OKR に目を配り、OKR に関わる事項を最優先に考えなければなりません。たとえば、これらのことに費やさなければならない時間は毎日 2 時間決まっています。さまざまな些細な問題が私たちのところに持ち込まれると、当然ながら、私たちはそれをタイムリーに処理できないかもしれません。時間に余裕があれば、興味のある「些細な」ことに取り組むこともできます。 「面白い」から、退屈ではないのです。おそらく、これらのことに取り組むことで、予期せぬ新しい情報が発見できるかもしれません。たとえば、バグのトラブルシューティングを手伝うことがとても好きだった時期がありました。この機会を利用してプラットフォームの製品アーキテクチャと R&D 実装ロジックを理解し、将来他の作業を行うための強固な基盤を築きたかったからです。

不可欠でスケーラブルな自動化ソリューションを見つけるにはどうすればよいでしょうか?これはプロジェクトを立ち上げて成果を上げる新たな機会となるかもしれません。

些細なことは怖くない。恐ろしいのは、些細なことが私たちを、毎日山に石を登るシシュポスのように、考えることができない道具に変えてしまうことです。

些細なことはさておき、毎日少なくとも 10 分間は「どうすればこれらの些細なことをなくせるだろうか」と考えてみましょう。 （責任転嫁以外にも）予想外の利益が得られるかもしれません。解決策には次の 2 種類があります。

1) 自動化された大規模なソリューションの試み:

例えば、データアトリビューションの一時的な需要に遭遇し、その後「自動アトリビューションデータ機能構築」に関する特別プロジェクトに拡大しました。手動の帰属ロジックを徐々に自動化機能に変えていきました。将来的には、この作業に私が必要なくなるため、比較的高価な人的資源を節約できます（？）。また、問題の原因をより迅速に提示し、要求者が自ら解決できるようにもなります。そうすればみんなが幸せになるのではないでしょうか？

2) 本質的な解決策を見つける:

多くの場合、表面上に見える問題は本質的な問題ではありません。さらに「なぜ」を問うことでのみ、「症状は治療するが根本的な原因は治療しない」という悪循環から抜け出すことができます。

たとえば、繰り返し発生するシステムバグや人為的な操作ミスは、システム設計やオペレーターのプロセスに重大な欠陥があることを示しているため、散発的な問題よりも警戒する価値があります。クラスタリング現象に関しては、その影響の大きさをデータを通じて十分に裏付けることができます。これが大きな問題領域であることがわかったら、このシナリオの設計を覆す必要があるかもしれません。これはまた別の大きなプロジェクトではないでしょうか?

実際、些細なことこそが世界の真実であり、抽象化は人為的な帰納法です。些細な操作作業も貴重です。些細なことをてこや橋に変えるのが上手であれば、良い結果を達成することができます。

コラムニスト

蘭おばさん、WeChat パブリックアカウント: 蘭おばさんのプロダクト講座、『みんながプロダクトマネージャー』のコラムニスト。彼はテンセント、Sogou、Guazi などの企業で働いたことがあります。インターネット製品マネージャーとしての 12 年間のキャリアの中で、私は大企業、中規模企業、小規模企業で働き、毎日数千万人のアクティブ ユーザーを抱える製品に携わり、0 から 1 までの道のりを何度も経験してきました。

この記事はもともと「Everyone is a Product Manager」に掲載されました。著者の許可なく複製することは禁止します。

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

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