読者です 読者をやめる 読者になる 読者になる

Shoichi Matsuda's diary

このブログは移転しました。 https://shoma2da.net/ が新しいブログです。

意味のあるCheckをしよう

チーム

PDCAなんて言葉が出てきて久しいですが、みなさんのチームはうまく回っているでしょうか。

僕個人がいくつかのチームでスクラムやかんばん方式といった開発手法のうえでPDCAを回してきた中で、特にCであるCheck(振り返り)について思うところがあったのでまとめておきます。

(今回Checkの対象としているのは主にチームの状態や運営状況についてです。数値のCheckという観点ではないですのであしからず。)

よくある問題定義


Checkの中で必ずと言って良いほど出てくるのが以下のような問題点です。

  • 残業が多い(時間が取れない)
  • 作業が特定の人に集中している
  • 意思決定者に時間がない

こういった問題定義はほとんどの場合、事の本質に迫れていません。
少し詳しく説明していきます。

なぜ良くないのか


こうした問題定義の何が問題かというと、Actionにつなげられないことです。(あるいは見当違いなActionを行ってしまうことです。)

「残業が多い」というのを例に取って説明します。

「残業が多い」に対しての安易なActionの一つとして「定時になったら必ず帰る」という方法があります。(極端ですがw)

これをActionとして実践すると、今までは残業ありきで終わらせていたので当然ですが仕事が全く終わりません。
ひどい場合は退勤後のサービス残業につながるかもしれませんね。
これでは問題点を別の場所に移動させただけです。

多くの場合、真に迫るべきは「なぜ残業が必要になっているか」という点でしょう。
これはチームによってそれこそ様々です。
不要だと考えられる仕様が多く盛り込まれている、仕事に取り掛かる前の待ち時間が多い、会議が多いなどといったことなどが上がるでしょう。

ここで注意したいのはチーム内では対処しようもないことを問題として挙げてしまわないことです。
例えば開発チームにおける「人が足りない」というものですね。
Actionとしては「人事担当者に人を⚪︎⚪︎人採用するように伝える」などでしょうか。

運良く採用されれば良いですが、そうでなかった場合は「Actionなし」となってしまい改善への道が断たれます。
(もちろんチーム外の動きとしての採用活動の活発化はアリです。)

まとめます


Checkにおいてよくある問題定義は以下のようなことです。

  • 良くない状況をあげるだけになっていて、問題の特定ができていない(例:残業が多い)
  • 外部要因を問題としていて自分たちの範囲内の問題として落とし込めていない(例:人が足りない)

以上です。
それでは、良い改善を!