仕組化のフレームワーク

サマリー

やれ仕組化だと言われるなか、どうやって仕組化するべきなのかを教えてくれるものはあまりなかった気がする。Amazonで学んだ仕組化のためのフレームワークと、重要なポイントを説明。 仕組化をするには：
①Inputと期待するOutputに変換するツールがあり、
②その仕組が組織に浸透する設計となっており、
③継続的Outputの質を見直すような体制が必要。

何かのアクションを頑張るなどの人の善意（Good intention）に任せるのではなく、スケーラブルな仕組みをベースに、Inputの質を向上させより期待するOutputを出すことで組織は成長する。

はじめに

今や猫も杓子も仕組化を唱える中、Amazonでも例に漏れず仕組化（メカニズム）が叫ばれていた。

ベゾスの有名な言葉にもGood intentions don’t work, you need good mechanisms to make everything happen. というのがある。
意訳すると”善意だけでは十分ではない。何かを実現するためには仕組づくりが重要だ”といったところだろうか。

Amazonでもぱっと思いつくだけで下記にあげるような様々な仕組みが存在する：

• 自動的に価格が最適になる仕組み、

• 在庫水準が適切かどうかを判断するための仕組み、

• 自動的に発注が出る仕組み、

• 採用のときに候補者の体験が一定水準に保たれるような仕組み、

• マネジャーによって評価の偏りが出ないようにするための仕組み、などなど

仕組化仕組化と叫ばれる世の中で、仕組化の重要性は言われても、どのようにしたらいいのかを教えてくれる書物は少ない気がした。

今日はAmazonでこれら仕組みをつくる際にAmazonで気をつけられていたフレームワークや、その際に重要となるポイントについて書いてみた。
仕組化に困っている方々にとって、少しでも参考になれば幸いだ。

他にもAmazonでのお仕事や、10Xでのお仕事についてつぶやいているので、NoteとTwitter (@mani_0417)をフォローください。

仕組化を進めるためのフレームワーク

今日の記事を書くにあたり、こちらの記事に海外のAmazonianがAmazonにおける仕組化（Mechanism）を説明されていたので参考にさせてもらいつつ、自身の経験を付け加えてみた。

💡 仕組化（Mechanism）とは、Inputを期待するOutputに変換するような継続的に改善させていくプロセスである。適切な仕組化には以下の３つの要素が必要である： 　
①Tool：InputをOutputに変換するツールがある
②Adoption：仕組みを利用するインセンティブをつくる
③Inspection：適切なOutputがでているか継続的な確認ができている

①Tool：InputをOutputに変換するツールがある

仕組化についてググるとたいてい出てくる”いつ、どこで、誰がやってもできる状態にする”というやつ。これを読んでくださっている方も見たことがあるかもしれない。
これをAmazonでは”再現性があり、スケーラブルなプロセスが構築されている”と定義されていた。
例えば、以下のような２名がインタビュープロセスにいるとしよう：

• 天才的にバイイングの嗅覚があり、独自の視点や経験に基づいて前職の部門において抜きん出たトラックレコードがある方（リファレンスもあり）

• 常に自身の思考プロセスを言語化し、自身が３ヶ月後にいなくなったとしても再現性があるようクエリやエクセルで分析の型を作って、どこのカテゴリーにどれだけ伸びしろがあり、アプローチ可能なブランドとその攻略方法を言語化していた方

もちろん上記の文章だけでは判断がつけられないが、Amazonの面接でリーダーシッププリンシプルに則ると、恐らく後者の方の方がよりオファーを出してもらいやすいだろう。

これは社内での評価も同じであった。
再現性があり、自身の担当カテゴリーを超えて、部門全体、事業部全体、カントリー全体、ひいては全世界のAmazonでもスケールできるような仕組みを作り上げている人が、出世している人の共通点として挙げられる。

商材や国が違ったとしても、同じようなInputを放り込むと期待されるOutputが帰ってくるようなTool、これが仕組化に欠かせない要素だ。

②Adoption：仕組みを利用するインセンティブをつくる

もう一つの重要なポイントが上記のToolを組織に浸透させるための工夫だ。
これは一見当たり前のようだが、４年間のAmazon生活でもToolはつくられても仕組みになりきらないものは多数見た。（というかほとんどがつくられては闇に葬られていった）
要因としては例えば：

• Inputがあまりに煩雑すぎて、作業者が入力するのが面倒（Toolにこだわりすぎて入力が面倒な設計になっているケースはどの組織でもアルアル）

• Toolの使用者やその結果を判断する人の論点をとらまえられておらず、期待されるOutputがだされない（設計者がみたい数字や粒度のデータが出てきており、Steakholderのみたいものとずれているのもよくあるケース）

これらを克服するために前回のNoteの”構造の理解”と”共通理解の積み上げ”が非常に重要になる。

多くのケースでここをすっ飛ばして、利害関係者の見たいものではなく、設計者が見せたい仕様になっているが故、仕組みとして機能していないToolが多数存在していた。

③Inspection：適切なOutputがでているか継続的な確認ができている

最後に最も重要な点がこれだ。
これにはいくつか補足したいポイントがある：

• 仕組みを因数分解できる：Inputを入れてみたときに期待通りのOutputが出ない場合、Inputを因数分解し、どこは確からしく、どこに改善余地があるかどうかを探索する必要がある。往々にして事業は不確実性を多くはらんでおり、一度スタンスをとって進めてみたとしても、継続的に微修正していくことが重要だと思う。しっかりと要素が因数分解できる仕組みが存在していれば、どのInputが悪かったのかをWeek over Weekで確認しながら、少しずつ探索的に改善に繋げられる。たとえ失敗したとしても、前に倒れれば良いというわけだ。

• 最初から完璧を求めない：仕組化と聞いて、バージョン１からカリカリにチューニングされているものを持っていこうとする人がいる（僕が完全にそれで苦しんだ）。これだと、そもそも構造を理解できているかもわかりきっておらず、かつ共通認識の積み上げが利害関係者間でできていないので、納得感が得られにくい。Amazonでも70％をとりあえず目指せと言われていいた。Leadership PrincipleのBias for Actionでも表されているが、完成度は70％を超えると急激に変化角度が緩くなりそれ以上の改善は時間がかかる。まずは息を止めて70％までの情報で走り出し、走り続ける中で解像度をあげ、共通認識を積み上げ、チューンアップしていくのだ。

• Outputが出ないときは仕組みのせい：仕組みのよいところは、特定のアクションによって期待されたOutputが出ない場合は、担当者のせいにせず、仕組みを見直すという思考が働くこと。Amazonの会議において、期待されるOutputがでていないときに「もっとアクション頑張ります」とか「もう少し深堀ってみます」みたいな発言はほとんど出てこなかった（かつ、この類の発言はなんの意味も持たない）。これらの発言は、人のGood intention（頑張ってみるという善意）に基づく発言となるっているからだ。なので、誰かにプレッシャーをかけて数字を作るということはせず、適切に仕組みを見直し、長期的に結果が出るようなビジネスにする、ということだけにフォーカスしている。

これらの仕組化のフレームワークと重要なポイントは、今働いている10Xでも毎日意識していることだ。

ビジネスの課題では、これまでの経験をつかって小売パートナーに対してのコンサルでマネタイズしたとしても、それは自身の過去の経験を食いつぶしているだけ。コンサルのノウハウを仕組化し、他の人も使えるようなやり方を考える。

組織の課題でも同じだと思う。
まだまだ仕組化の余地のある部分を特定し、とりあえず仕組化してみる。
するとちゃんとその仕組みから出るOutputに対して組織の人からフィードバックが入って、よりよいOutputを出すためのInputをみなで考えることができる。

こうやって、少しずつ少しずつ前に進んでいる感を感じられるのがスタートアップの醍醐味なんだと思っている。

最後に

Biz Devとしての新規事業、プロダクトマネジャーとしての新規プロダクトや機能の開発、そもそものスタートアップのお仕事全般、そのどれをとってもこうやったらうまくいく、なんてことがわかっていることは少ない。

そのような世界で、なにか一発逆転ホームランを狙い続けるのではなく、仕組化によってそれぞれのInputの解像度を上げながらOutputの質を高め、予定調和を積み上げながら不確実な未来の解像度をあげていくことが、継続的にビジネスを成長させる近道なのだと改めて思った。