PDCA as a Game

このエントリは アジャイルCasual Advent Calendar 2014 の 8 日目のエントリです。

前回は shin_semiya さんの「時は80年代、仕様は変化することがわかった」 でした。
なぜアジャイル宣言が生まれたのかという、そもそも論の前提となるウォーターフォールモデルの欠陥を解説する、良エントリでした。
アジャイル宣言が解決したかったものをもう一度見直す、良いきっかけになったのでは無いでしょうか？

さて、 8 日目は PDCA サイクルのあるあると、対応策になり得る考えを導入してみたいと思います。

PDCA サイクルのよく見る光景

PDCA サイクル自体については 2 日目のエントリである a_suenami さんの「速く回す人」と「少なく回す人」 を参照していただくとして、PDCA サイクルはまわすもの、すなわち繰り返し実践するものだと言う点は、特に反論無く受け入れられていると思います。

しかし、PDサイクル...つまり、Check と Act の抜けたサイクルになってしまった経験は無いでしょうか？

著者は、PDCA サイクルを導入したは良いものの、Check や Act がおざなりになってしまうことを何度か経験しました。読者の皆様はいかがでしょうか？

なぜ Check がおざなりになってしまうのでしょうか？

1 つには既に行ったことの反省よりも、次にやるべきことの重要度が高そうに見えるというのがあります。また、特に問題が起きていないように感じられるのに、反省をするというのも面白くないというのも確かでしょう。Check の重要度については、頭では理解していても納得できないというのも１つの意見です。
PDCA サイクルの提唱者であるデミング自身も、後に Check の重要さをより強調すべく PDSA サイクルへと名称を変更しています。

PDCA as a Game

発想を逆転させれば、Check がしたくなるような仕組みがあれば、 PDCA サイクルの Check や Act が上手くまわるかもしれません。そのための手段として、 ゲーミフィケーション を導入してみるのはいかがでしょうか。

コスティキャンは、ゲームを「 充分な情報の下に行われた意思決定を持って、プレイヤーが与えられた資源を管理しつつ自ら参加し、立ちはだかる障害物を乗り越えて目標達成を目指す 」ものだとしました。
PDCA サイクルの 1 サイクルは、チーム一丸となって、ゴールを設定し、そこに向かって進んでいき、評価されるという一連の流れでもありますので、一種のゲームとみなせると思います。

うまくゲーム化することで、チームメンバーが楽しんで PDCA サイクルをまわせるようにしむけられるかもしれません。

サンプルゲーム: UX改善王への道

ひとつ、サンプルゲームを示してみます。

この、「UX改善王への道」は、ある Web サービスの運営チームとして、最も良い UX 改善案を提案したメンバーを決めるゲームです。
Web サービスのディレクターまたはプロダクトオーナーが、ゲームマスターになり、その他のメンバーはプレイヤーとなります。

Check をしないと報酬が得られなくすることで、 Check の活性化を促します。
また、 Check の指標を Planning 時に明確にすることで、PDCA サイクルの精度向上も狙えます。

Planning

プレイヤーは UX 改善案を１つ考えます。このとき、チームに提供されている各種 KPI のうち、どの指標を改善するかを同時に決めます。
ゲームマスターは、実装難易度やビジネス要件をもとに、「報酬ポイント」を設定します。

Do

UX 改善案を具体的な仕様に落とし、実装をし、サービスに適用します。

Check

Planning 時に設定した指標が改善されたか確認します。改善されていれば、ゲームマスターはその提案者に「報酬ポイント」を付与します。

見える化・ランキング・報酬・バッジ　

チームの壁などにポスターを張っておき、メンバーの「報酬ポイント」等を張り出します。また、一定ポイントや KPI の種類に応じてバッジを付与するのも良いでしょう。一定ポイントを超えることで、食事など報酬をだすのも工夫の１つです。

まとめ

PDCA サイクルで軽視されがちな Check 作業。この作業を、ゲームのゴール、すなわち楽しい作業にすることによって、 Check したくなるようする、そのための手法として、ゲーミフィケーションの導入を提案しつつ、１つのゲームをサンプルとして提示してみました。

ぜひ、仕事もゲームとして、楽しんでみてください。