勤め先で ITプロジェクト終了時、KPTで振り返りを実施しています。
それなりにまとまった期間KPTを実施していると未消化のTryが溜まってくるので、あれこれ実施する方法を考えるのですが、それでもなかなか実施されません。
Tryが実施されない理由について考えてみました。
考えた結果を備忘録として残します。

前提

振り返りの実施状況が違うと、参考にならない可能性があるので、実施人数などの情報を記載します。

振り返りの実施方法について

  • 振り返り実施人数は10名程度
  • 振り返り頻度は（月1回月1回リリースがあるのでリリース後に実施）
  • 実施期間は1年6か月実施
  • 振り返りは、Google Meetで集まって結果をGoogleスプレッドシートに記録している。

考えたことの注意点

考えただけで、実際に実践していないこと、発生していないことも含みます。

自分の立場

チームのKPTの管理、振り返り後の改善活動の管理をしている立場です。

Try が実施されない理由

思い浮かんだTryが実施されない理由は以下の通りです。　

Try の主語が大きくなりすぎている。 / Tryの内容が行動まで落ちていない。

抽象的な大きな問題点があり、その解決がTryとして上がるケースです。
問題が大きすぎて何から手をつけて良いのか分からず一向に消化されません。 対策としては以下のようなものがあります。

  • 複数のTryに分割する

    実行可能な複数のTryに分割します。

  • 上位の管理者に問題をエスカレーション。

    チームでは解決できない問題として、 上位の管理者にエスカレーションして自チームのタスクとしては完了とするイメージです。 自チームでの解決を諦めて、上位管理者の判断に委ねます。

Try の実施に時間がかかりすぎる

実施にまとまった時間が必要で、かかるものもあります。 個人的な経験だと作業内容が明確だが実施に時間がかかるものは大きく以下の2つに分かれそうに思います。

  • 1から管理資料を作る等、大規模なドキュメントの作成、メンテナンス
  • ツールの開発

所属している組織にもよりますが、実施に2日以上要するものは、別途予算化、計画して実施する方が収まりが良さそうに思います。

Try の実施担当者の割り当てに偏りがある / 担当者・期限を設定していない

結局のところ同じことなので1つにまとめています。
1年程度、チームメンバー作業負荷増加を懸念して担当者として自分のみを設定していて一部の作業を手伝ってもらうスタンスでいましたが、自分の作業が立て込んでいる場合、改善作業が滞ってしまいました。この状態は以下のような問題点がありました。

  • 改善の主担当となることがないので、自然とTry項目を意識しなくなる。（忘れてしまう）
  • 1人の作業状況にTryの実施が左右されてしまう。

チームメンバーをTry実施の主担当としたことで、上記の問題点は解消されました。主担当の設定と合わせて期限設定もしてもらい少し実施にプレッシャーがかかる状況にしました。

ITプロジェクトの作業と、Tryの実施の作業が切り離されている

ITプロジェクトの作業とTryの実施作業が切り離されていると実施率が下がりそうです。
「切り離されている」とはどう言うことかというと、上手く説明ができなそうだったので、反対の「繋がりがある」の例を説明します。以下のような状況は「繋がりがある」と言えそうです。

  • 各開発工程別のチェックリストにKPTに関連する項目がある。
  • Tryの実施担当として次プロジェクトの担当作業が勘案されてアサインされている。
  • 次プロジェクト作業としてTryの項目が組み込まれる。（項目消化がプロジェクト成功に寄与すると判断されている）

Try を実施する作業時間の確保ができていない

主担当業務が忙しくて、Tryの実施時間が確保できていないケースです。
Tryの実施は強制ではないという状況の場合は、Tryの実施は重要だが緊急ではないタスク扱いになり中々実施されません。 時間を確保する方法としては以下が思いつきました。

  • あらかじめ、Tryの実施を想定したスケジュールを立てておく。 このようにスケジュールを立てた上でTryの実施してから主担当業務を実施する。

Try の棚卸しができていない

状況変化で過去のProblemがProblemではなくなったり、 未実施のTryも実施不要となるケース、派生した別作業の優先度が高くなるケースがあります。
少なくとも半年に1度は過去のKPTの問題の棚卸しを実施すべきと思います。

Tryの実施（改善活動）の位置付けが曖昧

KPTの実施、改善活動に関して社員の義務なのか、あくまで推奨される作業で実施が評価されるのか等の制度的な部分でどのように扱うかをはっきりさせておくべきと思います。
改善が義務なのであればTryの実施も義務化してしまっても良いはずですが、社員のモチベーションには影響しそうに思います。個人的には実施義務がない状態でも自然に消化されていくのが理想ですが、そのような状況を経験したことはありません。

改善の実施責任者側のタスク

Tryが実施されない理由を踏まえて、改善実施責任者側のタスクを考えてみました。 月次、週次、日次でのタスクがあり、実際に実行してみて、様子を観察しようかと思います。

月次

  • 新しく追加するTryの剪定
  • Tryの主語の調整
  • 進捗情報の集計

週次

  • 担当者を定めた改善項目に対しての期限切れのリマインド
  • 期限切れ改善項目について以下をヒアリング
    • なぜ、実施できなかったのか？
    • どうすれば実施できたか？
    • 何かサポートできることはないか？

日次

  • 自分自身が担当の改善項目の実施。
  • 担当者の改善実施のサポート。

チーム異動した

この記事の投稿の後に、チーム異動しました。
異動先でのふりかえりとの比較をふりかえりのやり方で後悔すること、答えがわからないこと | Monotalk にまとめたので、こちらも興味があればご確認ください。

参考

以上です。
他にも何か思いついたら追記していこうかと思います。

コメント

カテゴリー

最近の投稿