日本で仕事をしている必ず出くわす超有名フレームワークが「PDCA」です。
この記事では「PDCA」サイクルを上手く廻すために、最も注力するべきポイントについて解説します。
PDCAサイクルとは
色々な定義がありますが、どれも概ね似通っているいますので、ここでは最もシンプルに定義しているWikipediaの内容を引用させていただきます。
PDCAサイクル（PDCA cycle、plan-do-check-act cycle）とは品質管理など業務管理における継続的な改善方法。Plan（計画）→ Do（実行）→ Check（評価）→ Act（改善）の4段階を繰り返して業務を継続的に改善する方法。
Wikipedia/PDCAサイクル
PDCAの中で最も重要な要素は「Check」
結論から言うと、最も重要だと思う要素は「Check(評価)」です。なぜ重要かという点をお話する前に、PDCAを回そうとしている時の環境や前提について、共通的な項目を挙げたいと思います。
- 不確実性の高い状況においてPCDAは使われることが多い
- だいたい思った通りにはいかない(=計画どおりにいかない)
- 実行してはじめて分かる重要なことが多い
- 思い通りにいかないという小さな失敗の中にこそ、改善のヒントがある
- 改善をする試行回数が多いほど、物事はうまくいく
「計画を外したことなんで1度もないぜ！」という超人さんもいらっしゃるかもしれませんが、私自身の経験に基づく話しではあるので、あしからずご承知おきください。
繰り返しになりますが、最初の計画はだいたい外れます。それゆえに、改善という名前の軌道修正を繰り返し行うこと前提としたサイクルの設計をしておくことが、とても大切だと考えています。
上で記載した各項目を前提として、「Check」が重要だと考える理由は次のとおりです。
- PDCAの中で「Check(評価)」の方法だけが、事前に設計し、コントロール出来る
- 「Check」の頻度は、「Act(改善)」の回数に直接的に影響するため、仕事の成否に大きく関わってくる
- 無形サービスのクライアントワークを行う場合、「Check」の際に提出するレポートこそが唯一の物質的な成果物となり、その「Check」品質が高ければ、クライアントからの評価を得やすい
実際、私が新しい事業に携わったり、新しいクライアントのコンサルティングに入る際は、何よりも最初に、自分自身が「Check」ができる環境を作るようにしています。
それが出来るようになったら、クライアントを含めたチームが同じように「Check」出来ようにしていき、チーム全体で改善へと素早く取り組んで行けるようにしています。
上手く廻るための「Check」の作り方
PDCAを回す中で要となる「Check」ですが、それではどうやれば良い「Check」を構築することができるでしょうか。良い、つまりは仕事がより上手くいくための「Check」を作るには次の各要素を満たす必要があります。
改善につながる適切な情報を用意する
「Check」の目的は、事前に立てた「Plan(計画)」と、「Do(実行)」自体の上手く行かなかった点を洗い出し、適切な「Act(改善)」を引き起こすことです。その目的を満たすことのできるレポート項目を、適切な粒度で設計する必要があります。
また、適切な粒度は見る人の立場によって異なります。例えば、事業責任者と中間管理者、現場担当者では、見たい項目もタイムスパンも当然違ってきますので、見る人が改善に移す事ができる粒度にすることも、とても重要な点です。
良いレポートの構成案については、改めて別記事も書きたいと思います。
適切な頻度で行えるようにする
繰り返しになりますが、「Check」の頻度は「Act(改善)」の回数に直接的に影響を及ぼします。改善の回数は多いと良いと言いましたが、さすがに限度はあります。仕事のサイクルに合わせた適切な頻度を見極めて、その中で可能な限り多く「Check」機会を作っていくべきだと考えています。
私自身の具体的な経験でいうと、広告配信に関わるサービスなどのセールスチームに関わる際は、まずは「日商」を見られるようにします。
大抵のセールスチームでは、「月商」を基準とした管理を行っていたりますが、チームの日々の活動は、割と早い段階で「日商」に反映されてきます。「日商」であれば、すぐに結果が分かりますし、目標と実績の乖離がある場合でも、乖離金額が割と小さくなったりするため、各セールスメンバーで改善案が考えやすなります。
ただ、これを「時間商」とかにして、毎時ごとにセールスチームに告知し、改善案を求めるのはやりすぎになります。
「Check」を上手く廻せる手帳術に関する記事もありますので、ぜひ御覧ください。
手間を最小限する
「Check」は最小限の手間で、レポートが出力される必要があります。「Check」出すために時間を使うより、結果を考察し「Act(改善)」を実行することに、より多くの時間を使うべきです。
また手間のかかる「Check」は、面倒くさいという気持ちを引き起こし「Check」そのものを行わないということにも繋がりかねません。
まとめ
PDCAをより良く回すための「Check」の重要性と、良い「Check」を作るための要素を書いてきましたが、これらはスプレッドシート、QUERY関数、AppsScriptを使うことで実現ができます。(ここで、ようやくこのブログの本筋に戻りますｗ)
私自身も元々はエンジニアリングやプログラミングからは縁遠い世界で生きてきましたが、経験の中で(必要に迫られて)覚えてきました。なんとか覚えたことで、仕事の幅も深さも広げる機会に恵まれてきました。ブログを読んでくださっている方にとって、少しでも機会を広げる一助になることができれば幸いに思います。
