【読書記録】Amazonのすごいルール
おはようございます。
GWに突入し、思う存分読書できるかと思いきや、実家に帰省しての付き合いや、家族サービスに追われて普段よりも1人の時間が少なくなっております。。笑
実は私は結婚しておりまして、そろそろ第一子が生まれるということで、準備にてんやわんやしております。
GW4日目にして、ゆっくりした自分の時間ができたので、合間合間に読んでいた『アマゾンのすごいルール』について、印象に残ったポイントをnoteにアウトプットしていこうと思います。
1.高速PDCA
少し長くなってしまいましたが、本書から引用しています。
最近は雑記として残しているnote記事にも書いていますが、進捗管理方法について、本書に書かれていました。
進捗管理をするための大前提として、あらゆるタスクを定量化し、数値を用いて進捗管理をできるようにすることが第一歩です。これについては、以前にも様々な記事を調べる中で私も理解していました。
本書での新しい発見としては、常にバックアッププランを持っておく必要があるということです。
今までは、進捗管理をしていて、遅れを発見した場合には関連部門(特にアウトプット先)にできるだけ共有し、納期を調整する。という流れになると思っていました。
あとは、それと同時に遅れが発生してしまった原因を分析し、その遅れが再発しないような改善プランを立てて実行に移すことが進捗管理担当者が実施すべきこと、といったところでしょうか。PDCAのCとAにあたる行動がこれになると思っていました。
チームの業務をできる限り細分化し、工数を出し、さらにある程度のバッファを持たせた上で立てた計画ですので、遅れが出る前から遅れた時のバックアッププランを考えておくということは考えていませんでした。
確かに、遅れが発生してから関連部門と調整して、計画を修正する。をおこなっていると、短期的なプロジェクトの場合は調整している間に元々の納期を迎えて後手になってしまったり、大規模なプロジェクトの場合は調整自体にもかなり時間がかかるので、計画の修正に1ヶ月とかかかってしまうこともありそうです。
上記のように書き出してみると、計画の段階からバックアッププランを考えておくということは合理的ですし、マネージャーとしては必ず押さえておかなければならないポイントだなと感じました。
プロジェクトマネジメントについて、また一つ新たな気づきを得ることができましたので、すぐに本業の方で実践しなければと思います。
2.”評論家”は最低評価を下される
こちらもとても印象的な言葉でした。
仕事はもちろんチームとして進めていくことがほとんどですので、上位者になればなるほど、個人としての成果よりもチームとしての成果が求められます。
そんなときに、主体的に考える習慣がない人は、人の成果に対してマイナスとなる問題点を指摘するだけで、それをどうやったら解決できるのか、自分がその成果に対してどのような形で協力できるのかを考えていないです。
今の会社で働いていても、開発中の機能設計を終えてレビューに持っていくと、検討しきれていない細かい点に対する指摘をされたり、どのような案であってもデメリットはつきもので、メリットとのトレードオフを考えて意思決定をしていくべきなのにも関わらず、デメリットに対してばかり指摘し、メリットに目を向けてくれない。その結果、その場で意思決定ができずに再検討を課されることもあります。。
もちろん、再検討に協力してくれるわけではなく、再度レビューに持っていった際に同じようにデメリットに目を向けた指摘ばかりされてしまい、結果的に納期が迫っていると言う理由でその時点での最良の案と考えられるもので渋々進めるといったこともあるのです。
このような人を評論家というのだなぁと思いますし、評論家がいるとチームとしての意思決定が遅くなるばかりではなく、各個人のモチベーション低下にもつながりかねないということは身をもって実感しておりました。
アマゾンではこのような評論家が評価されないということが分かりましたので、自分が薄々感じていたことはあながち間違っていなかったのだと分かりました。
反面教師として、チームとしての成果を最大化するために、どのように各個人に貢献できるかを考えながら、本業に臨もうと思います。
以上、2点、本書を読んで感じたことをアウトプットしました。
それでは。
この記事が参加している募集
この記事が気に入ったらサポートをしてみませんか?