プロセスと仕様は単なる保証ツールであり、方法論ではありません。

目的から始めて意味を明確にする

世の中に道はないが、歩く人が増えれば道になる。

魯迅先生の著作は、いわゆる業務規範や業務手順に関して実は非常に有意義な内容です。

数日前、WeChat Moments で死ぬほど笑ってしまう投稿を見ました。

あなたの会社は従業員が6人しかいないのに、張小龍の「KPIとプロセスに注意」という記事が大々的に出回っています。真剣に研究し、反省すべきです。それでは、まずは従業員数を1,000人以上に増やすことを優先しますか？

私は嬉しそうに親指を立てました。

なぜ？

まず、他の人が言うと愚かに聞こえることも多くありますが、張小龍が言うと真実になります。

第二に、ある言葉が真実になると、信者はそれを何の差別もなく受け入れるでしょう。

例えば、もし私がいつか張小龍の半分くらいすごい人になったら、他の人と議論するときに私の記事を引用する人がたくさん出てくると思います。

見て！偉大なる神もそうおっしゃいました！

しかし、この記事の結論は私自身、あるいは他の人によって覆されている可能性が非常に高く、あなたがそれを知らないだけという可能性もあります。

操作プロセスと仕様について話す前に、まず次の点を明確にする必要があります。

このテーマには絶対的な真実はありません。プロセスと標準は必要性から生まれますが、常に必要なわけではありません。落とし穴がなかったら標準は存在しないでしょうし、問題がなかったらプロセスも存在しないでしょう。

次に、次の点について考える必要があります。

運用にはプロセスや規制が必要ですか?プロセスと標準を確立するプロセスは、具体的にはどのようなものであるべきでしょうか?プロセスと規制を制約ではなく促進要因にするにはどうすればよいでしょうか?

次に、私はナンセンスを話し始めました。

落とし穴なし、規制なし、責任なし、プロセスなし

標準は非標準化を防ぐためのものであり、プロセスは責任の不明確さを防ぐためのものです。

これら 2 つの前提が理解されなければ、すべての議論は無意味になります。

イベント企画提案の仕様を例に挙げてみましょう。

『Starting an Operation from Scratch』を読んだことがあるなら、イベント企画提案の標準的な構造を私が提供したことを覚えているでしょう。

イベントテーマ: イベントのテーマとそれがユーザーにとって魅力的かどうかを理解できるようにするイベントコピーの一部です。アクティビティの対象者: アクティビティの対象グループを明確にして、ユーザーが理解し、把握し、リーダーが認識できるようにします。アクティビティ時間: アクティビティの開始時間と終了時間、報酬が発行される時間、報酬が受け取られる時間。イベントの説明: ユーザーが参加するかどうか、また参加方法を理解、決定できるようにするためのイベントコピーの一部。ルールの詳細: アクティビティコピーの一部はユーザーと開発者が理解できるもので、コンテンツの一部はフロントエンドに表示され、残りの部分では開発者がアクティビティの実装方法を理解できるようにします。流通チャネル: 市場や自分自身に明確にするために、流通時間、流通チャネルの選択、予算が必要です。リスク管理: 開発者にリスクリンクが何であるか、またそれを解決するための適切な対策があるかどうかを理解させます。監視指標: 配信チャネルの監視、ユーザー参加の監視、報酬分配の監視など、最も関連性の高い指標をカバーします。データを表示するときに問題点を見つけ、その問題を解決するきっかけを与えることができます。費用の見積もり: アクティビティにかかる費用と 1 人あたりの費用。非常に正確である必要はありませんが、費用がかからない活動もあることを認識する必要があります。費用がかかる場合は、活動の能力、指標にどのように役立つか、これらのメリットを得るために会社からどれくらいの資金援助が必要かを理解する必要があります。効果評価：コストがかかるところにはメリットがあります。活動の目的は、Web サイトや製品の指標に役立ちます。それをどのように反映し、リーダーの承認を得るかを検討する必要があります。 FAQ: イベント参加時にユーザーが抱く可能性のある混乱を解決するために、別のドキュメントを用意してカスタマーサービスまたは関連担当者に提供することができます。 FAQ は詳細かつ標準的な内容である必要があります。イベントが大規模でFAQだけでは不十分な場合は、事前にカスタマーサービスのトレーニング資料を用意し、積極的にコミュニケーションを図る必要があります。

実際のところ、この構造自体がさまざまな落とし穴の結果なのです。

活動テーマ、活動対象、活動時間、活動内容、活動ルール（実際は賞品設定もあるが、企画提案書では検討費用に含めている）。これらの内容は主にユーザー向けで、一部は開発者向けの内容となっている。これらの部分に漏れや不備があると、開発者もユーザーも理解できず、必ず問題が発生します。

配信チャネルでは、イベントを企画する際に、運営スタッフがイベントターゲットや関連予算を十分に考慮し、それに応じた配信を行う必要があります。漏れや不備があれば、自社のリソースを持つ大規模プラットフォームでなければ、プロモーションが失敗する可能性が高くなります。

リスク管理と監視指標は、開発者と運用保守担当者が確認するためのものです。同時に、特定の監視指標の異常の原因も把握しておく必要があります。この 2 つの項目が設定されると、比較的完全なプロセスでアラームメカニズムが機能するようになります。アラームが発生したら、常に問題がどこにあるのか、誰に対処すればよいのかを把握しておく必要があります。

コストの見積もりと効果の期待はリーダーが見るものです。あなたのリーダーは張小龍ではないので、お金が無駄になることはありません。張小龍や馬化騰のような精神とレベルに達しなければ、リーダーがROIを追求するのは避けられず、ROIを追求する必要があります。コスト管理の意識がなければ、コスト見積もりに戸惑うことになります。ここで戸惑うと、10回中9回はリスクがどこに現れるかわからないため、監視指標を設計できないか、ランダムに設計することになります。

FAQ は、運用保守、カスタマーサービス、自分自身、または残業中の同僚のためのものです。誰かが問題に遭遇したり、アドバイスを求めてきたりしたとき、常に答えを用意しておく必要がありますよね? FAQ 操作をしない人は、アクティビティとカスタマーサービスの関係を理解していないため、間違いなく上級オペレーターではありません。したがって、この仕事に長く携わっていないに違いありません。そうでなければ、カスタマーサービスで徹底的に叱責されるでしょう。

規範の確立には、多くの場合、誤り、事故、悪影響が伴うことに気づくでしょう。

そのような問題がなければ、仕様を定める必要はありません。結局のところ、10人の小さなチームが効率的であり、バグが提起され、修正され、テストされ、オンラインでリリースされるまでに24時間もかからないと張小龍は言います。

はい、それは当時、その製品にトップマネジメントの目が行き届いていなかったため、少人数のチームでやらせてしまったからです。そうでなければ、本当にリリース事故が起きたら、誰が責任を取るのでしょうか？

ああ、すみません、プロセスについて話しました。

プロセスについてお話ししましょう。

プロセスの核となるのは「追跡可能性」と「説明責任」です。

開発者は開発が完了したらパッケージ化してサーバーにアップデートすることはできないのですか?

はい、しかし誰がテストを行うのでしょうか?共通例外処理がカバーされていないために何か問題が発生した場合はどうすればよいですか?運用と保守の責任者は誰ですか?サーバーは全部で100台ありますが、各サーバーごとに自分で開発してアップロードするのでしょうか？間違ったバージョンのパッケージを転送した場合はどうすればよいですか?

したがって、専門家が専門的なことを行えば、少なくとも何か問題が発生した場合、責任は全員ではなく関連するノードに帰せられることになります。

たとえば、次のようなシーンです。

A は商品の価格を変更したいと考えましたが、ゼロを忘れていました。システムには価格の異常を自動的に検出する機能がなかったため、A のリーダーである M の承認が必要でした。

MはAがいつも信頼できると感じていた。会議に出席するために急いでいたところ、Aが商品を棚に並べるように促した。承認されたので大丈夫だとMは思った。

その結果、商品の在庫は完売となりました。

上司が追及すれば、A は破滅し、M も逃げることはできない。

M がプロセスを承認したからです。

しかし、プロセスがなければ、それは終わりであり、証拠は残りません。

したがって、このプロセスは、誰が責任を負うのかを明確にするものです。

効率性と公平性

規範やプロセスは、問題や影響がすでに発生している状況に基づいて確立されることが多いです。

そのため、効率性と公平性を可能な限り確保することを目的として、同様の問題の再発を防ぐための標準とプロセスが作成されます。

しかし、実際には、リスク管理に基づいて設計された規制やプロセスは、必然的に効率性に影響を与え、企業がいかに強力であっても、その結果、必然的に効率性が低下します。

これは正常です。

張小龍は不満を言うことも知っています。10人のチームが問題に遭遇した場合、数歩歩いて責任者を呼び寄せ、ホワイトボードに問題を描き、雑談して、一緒に仕事を始めることができます。しかし、100人のチームになると、問題を解決するために会議の予定を立てる必要が生じます。もちろん、この効率は小規模チームほど良くはありません。

言うまでもなく、チームには 1 つの製品、1 つの操作、1 つの開発、1 つの設計があります。少なくとも、問題が発生した場合に誰に相談すればよいかは全員が知っています。

4つの製品、4つの運用、4つの開発、4つのデザインを目指してみませんか？一日を通して 16 人が同じ席に座っているのを見る機会すらないかもしれません。

しかし解決策はないのでしょうか?

実は、そうです。

方法も非常に簡単です。

標準とプロセスは保護のためのツールとしてのみ扱い、運用方法論として使用しないでください。

正直に言うと、上に書いたイベントプランってこんな構成にしなくてはいけないのでしょうか？

必ずしもそうではありません。私が述べた潜在的な落とし穴をカバーできる限り、好きなように書くことができます。

ルールに縛られると、あなたは本当に愚かになります。

率直に言うと、プロセスが通過するまで何もせずに待たなければならないのでしょうか?

必ずしもそうではありません。一部のプロセスについては、イベント後のレコードとして扱う必要があります。

たとえば、あなたが SMS チャネルを担当するオペレーターで、一日中他の人のリリース要求を受信しているとします。標準の手順では、要求書を受け取ってからでないと何もできません。