こんにちは、きくちはらです。
このブログは、数字の苦手な経営者さんに話題のニュースを基に、会計的視点、マーケティング的視点、マネジメント的視点などから、あなたのビジネスのヒントになる情報をお届けしています。
お友達も募集中！
ｱｸｼｭ( ´ー｀)⊃⊂(´ー｀ )ｱｸｼｭ
部下にこんな指示を出してませんか？
あなたは、部下に指示を出す際「もっとがんばれ」とか「しっかりやれ」とか曖昧な指示を出していませんか？
きっと部下の人は「はい、がんばります」とか、「もっとしっかりやります」とか答えるでしょう。でも、あなたの思った通りの成果が出せていないのではないでしょうか？それもそのはず。あなたの「がんばる」と、部下の人の「がんばる」は違うのです。もし…
・あなたにとっての「がんばる」＝死に物狂いで結果を出す
・部下の人にとっての「がんばる」＝いつもより余計にやる
という認識だったら…、いつまでたってもあなたが望む成果は出ませんね。
Amazon流の管理術とは
日本人は長時間労働の割に生産性が低いということをよく言われます。その理由を「労働者ではなく、企業の仕組みに問題がある」と指摘するのが、元Amazon社員の佐藤将之さんです。そして佐藤さんが語るAmazon流の管理術というのがコレ
↓↓↓
「次から気をつけます」は「改善」ではない──アマゾンのPDCA管理術
『アマゾンのすごいルール』著者 佐藤将之
佐藤はアマゾンジャパン17番目の社員として2000年から同社の成長に貢献。その内実を公開した『アマゾンのすごいルール』（宝島社）は、アマゾンのビジネス書「企業動向」カテゴリで売り上げ1位にも輝いた。
PDCAを回し尽くすアマゾンの圧倒的な働き方。その真髄はどこにあるのか。2回にかけてお送りする。
愚直にPDCAサイクルを回し続けたから、成長できた──日本の会社とアマゾンジャパンの働き方で、一番違いを感じた点はどこでしょうか。
「数字」に対する意識ですね。アマゾンでは社員のあらゆる行動を「メトリックス（KPI）＝数字」によって測り、徹底したPDCAサイクルを回しています。
──数字による管理とPDCAサイクルは、多くの日本企業でも重視されていますが……？
Amazonの場合、きちんと「確認（Check）」がなされるから、本当にサイクルが回るんです。私が見た限り、日本企業の多くはPDCAの「確認（Check）」と「改善（Act）」がおざなりになっています。
これは評価される人材の定義が、日本の企業とアマゾンでは全く異なるからです。
日本で評価されるビジネスパーソンの多くは、「計画（Plan）」と「行動（Do）」に長けている、つまり綺麗な計画書を書いて周りに作業を振るのが上手い人ですよね。ですが、それをカタチにする下請けの作業はブラックボックスになっており、ブラック労働の温床になっています。
アマゾンで評価されるのは、PDCAサイクルを高速で回し、「数字」で結果を出せるメンバーです。社内のあらゆる要素が数値化されているのは、「改善」を効率よく繰り返すためにほかなりません。
全ての仕事は、「y=f(x)」で表現できる
──とはいえ、「確認」と「改善」の仕組み化は簡単ではありません。チェックリストなどを用意しても、最終的には上司から作業者に「これからは気をつけろよ」と注意喚起して終わりになってしまうことも多いですよね。どうすれば意味のある「確認」を徹底できるのでしょうか。
アマゾンでは上司が部下に、失敗した理由と具体的にどのような対策をとるのかを必ず尋ねる習慣があります。PDCAサイクルが機能していない企業は、この「確認」が形骸化しているのではないでしょうか。とりあえず部下を問い詰めるだけ問い詰めて、「次は頑張ろう」と励ますだけでは、「改善」につながりません。
私は、全ての仕事は関数「y=f(x)」で表現できると思っています。私が最後の10年に担当していたフルフィルメントセンター（倉庫）でのオペレーションを例に挙げると、売り上げや倉庫内での事故件数や誤発送件数、返品件数といった大きな目標が「y」として表されます。
──目標値の設定自体は、多くの企業でやっているはずですが……？
アマゾンがすごいのは、目標を達成するための要素も全て数値化することです。これが「x」にあたります。
例えば在庫品質という大目標を良くするための「x」は、商品を誤って棚に入れてしまった回数や棚出しに間違えた回数、一度棚に入れたはずの商品を別の棚に入れてしまった回数（これをアマゾンでは「プットバックエラー」と呼んでいます）などです。これらの細かい数字を常に観測し、「改善」するから、サービスの精度を絶えず高めることができます。
「x」を発見するためには、とにかく業務を因数分解しなければなりません。数字でKPIを表しているのになぜか効果が現れないという企業は、「x」の特定が不十分なのではないでしょうか。
──棚から誤って商品を取り出した回数まで数値化するというのは、すごいですね。
そのおかげで、実際に大きな「改善」も行われているんですよ。例えば、倉庫から落とした商品をその場で戻すことは一切禁止されました。発送のために倉庫から商品を取り出す際に、誤ってその横の商品を落としてしまったとします。その場合、落としたものを棚に戻すのではなく、新たに設置した「迷子ボックス」に入れなければなりません。
ボックスに入ったものは、後から担当者がデータを確認しながらまとめて棚に戻します。これは在庫品質という「y」を構成する数字の中でも、プットバックエラーの回数（x）が多かったから導入された施策です。
──その場で棚に戻してしまった方が、時間の削減になりそうですが……
いいえ。それは「改善」ではありません。不確定で曖昧な個人の「注意」に頼っても成果が出るかはわからないですよね。
ポイントは、プットバックエラーが多いからといって「商品を落とさないよう気をつけるように」と作業者に注意喚起するわけではないということ。システムそのものを見直さなければ、本当の意味で「数字に」はコミットできないのです。
引用元：https://forbesjapan.com/articles/detail/21322?n=1&e=21266
まとめ
・日本企業の生産性が低いのは「仕組み」のせい
・とりわけPDCAサイクルのまわし方が甘い
・P（計画）、D（実行）はいいが、C（確認）A（改善）が徹底できていない
・全ての仕事は関数「y=f(x)」で表現できる
「y=f(x)」とはんぞや
・電気＝f（天気）
・元旦＝f（簡単）
・鼻血＝f（話し）
これらの式で「f」に何が入るか分かりますか？
カッチ、カッチ、カッチ…
そうです。「f」には「濁点」が入ります。では、
・客単価＝f（もう一品おすすめトーク）なら「f」に入るのは…
そうです「回数」です。感じ良い「もう一品おすすめトーク」をすればするほど、客単価はアップしますよね。この時「客単価」は「もう一品おすすめトーク」の関数であるといいます。「もう一品おすすめトーク」は原因で、「客単価」は結果です。結果をコントロールすることはできないけれど、原因をコントロールすることはできます。
おそらくAmazonでは、この関数を用いて「原因と結果の関係」を突き止め、原因に当たる行動を日々改善しているのでしょう。
数字で管理してみよう
検証の結果、「もう一品おすすめトーク」は客単価アップに貢献していることがわかったら（貢献していない可能性もありますが）、部下がトークを言えた回数の管理をすればいいわけです。上司はトークを言えた「結果」を検証します。たとえば、客単価目標を達成していない場合、「その理由は、トークの回数が足りないからだ。」といったことを明確に指摘できます。もし、トークを言えた回数が目標通りなのに、客単価の目標が達成できていないのなら、「トークの内容」に問題があるのでは？という考え方ができますね。
あなたが数字を上げたいと思っている項目は何ですか？その項目は、どんな行動をすれば上がりますか？管理すべき「原因と結果」が決まったら、それを1週間単位でPDCAを回してみてください。業績は上がって当たり前、悪くなるはずがないのです。それがAmazon流のPDCAです。
PDCA回したいなら
ポチッとな！
ｱｸｼｭ( ´ー｀)⊃⊂(´ー｀ )ｱｸｼｭ
&nbs