この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
こんにちわ。従業員体験( EX ) の向上がミッションのエンジニアリング統括室に所属しているてぃーびーです。
木こりのジレンマの話を聞いたことがあるでしょうか？
木を切り続けて刃こぼれした斧を使って効率が落ちたまま作業を続けている木こり。しかし、斧を研いだほうがいいのではと質問すると「忙しいから斧を研ぐ時間はない」と答える。結果として効率はよくならない。そんな逸話です。
仕事における改善業務も同様です。何かしら問題を抱えている。それによって時間が不足している。そんな状態が継続されるのは、改善する時間を確保し、問題を解決していないことによります。
私達のチームは人事領域の仕事をしていますが、関係者が全員ソフトウェア出身です。そういった背景もあり、システム開発領域でよく耳にする「ポストモーテム」や「レトロスペクティブ」による継続改善を実施しています。そこで、人事領域でのふりかえりからの改善事例としてまとめます。
ポストモーテムとは？
ポストモーテムは、取り組みが終わったあとにうまくいった部分とうまくいかなかった部分を把握し、うまくいかなかった部分を改善していくためのプロセスです。
ポストモーテムはプロジェクト単位で実施されるものと、何かしらのインシデントに対して実施されるものがあります。
ポストモーテム実施例
私達の会社では、2022年10月より OKR を全社導入しています。
OKR の情報は Notion のデータベースで保存しています。
運用を開始してみたところ、データベースのプロパティを一般利用者が誤って変更してしまうケースが度々発生してしました。
あるとき、誤ってプロパティの削除が発生した際にポストモーテムを実施しました。
関係者がデータベースを直接操作できてしまうことで問題が発生しているため、この問題を根本的に解決する方法を決めました。
検証の結果、一般利用者はリンクドビューという機能経由でデータを操作し、管理者のみがデータベースを直接操作するという方法でプロパティに対する誤操作を防げることがわかりました。結果として、この構成に変更することで根本対応をしました。
※より理想的には権限設定が強化されて根本的に間違えようがないようになるのが嬉しいので、 Notion の機能強化に期待です
レトロスペクティブとは？
レトロスペクティブはいわゆるふりかえりです。
立ち止まり、日々の取り組むのいい部分、改善が必要な部分などをふりかえり、改善につなげます。
レトロスペクティブ実施例
レトロスペクティブには様々なふりかえり手法や、運用形態があります。
私達のチームが現在利用しているのは
- 運用形態 - スクラムにおけるスプリントレトロスペクティブ
- ふりかえり手法 - KPT
です。
チームでスクラムを運用しているため、1週間1スプリントで、スプリントの最終日にスプリントレトロスペクティブを実施しています。実施方法は KPT です。
- Keep - 継続したい良い取り組み
- Problem - 問題点
- Try - 新たに取り組むこと、改善したいこと
実施する際は、オンラインホワイトボードでの付箋ワークで
- 数分で Keep を出す
- Keep のカテゴライズ
- Keep の内容についてやりとり
- 数分で Problem を出す
- Problem のカテゴライズ
- Problem の内容についてやりとり
- Keep から Try として1件取り組む対象を検討
- Problem から Try として1件取り組む対象を検討
- Try をタスク管理ツールに登録
という流れです。
なお、1週間の間の出来事を忘れてしまわないように、各自発生ベースで Keep, Problem を日々記載するようにしています。
その上で、レトロスペクティブ当日に不足があれば書き足す形です。
Try は、数を多くして改善に着手しきれないよりは、少数でも確実に日々改善していくために Keep / Problem から各1件に絞っています。2021年11月にスクラムを導入してから、毎週平均2件の改善を実施していることになります。
改善の中には単発のものもあれば、日々の業務の進め方に関わる永続的なものがあります。特に永続的なものは、一度改善するとそれ以降ずっと改善効果が継続するため、取り組みの価値が非常に大きくなります。
まとめ
時間に追われて問題点を解決しないまま進み続けるよりは、元から改善を業務に組み込み、常に改善し続ける状態を作るのが理想です。逆に忙しさは改善をしない状態によって維持される、と考えることもできます。
日々の業務に改善を組み込み、組織の仕組みとして業務の進め方が改善されつづける状態が理想です。
事業部単位、部門単位、グループ単位、プロジェクト単位、チーム単位、タスクフォース単位。それぞれの単位に課題があるのに改善されないまま残っているとき、各単位での定期的なふりかえりからからの改善が回っていないということになりそうです。まずは、定期的なふりかえりを導入してみると良いと思います。
特に、プロジェクト単位のふりかえりは実施しているケースが多そうに思いますが、事業部単位・部門単位・複数チームや部門をまたぐ連携が必要な業務に対するふりかえりは意外と見逃しがちです。一度、どの主体で、どのくらいの頻度でふりかえりが必要か、自分が関わっている業務について検討してみましょう。
5
