仕事の進め方の良し悪しを見える化して各自が行動を改善(#17)
この記事の初出は、Software Design 2023年8月号です。
はじめに
プログラミング開発をチームで行うためには、プログラミングのスキルだけでなく「仕事の進め方」も大事だと思います。
皆さんのチームで、仕事の進め方の問題により、手戻りが発生してしまったことはないでしょうか。
私は過去にそういう経験があります。
私が駆け出しのマネージャーだった頃、チームメンバーは若手が多く、以下のような問題がよく起きていました。
1つの不具合の修正に対して、丸一日かけて直したが、設計が適切でないため、最初からやり直しとなった。
レビュー指摘の修正時に、類似の問題が他にないか確認しなかったため、何度も差し戻しが発生した。
今回は、このような問題に対する改善事例の紹介です。
仕事の進め方の良し悪しを見える化
当時の私のチームでは、前述のような問題が起きるたびに「今後はこうして欲しい」と伝えても、なかなか改善されない傾向がありました。
そこで、別の改善方法を検討しました。
それが、各自の仕事の進め方の良し悪しを見える化することです。
それまで改善されなかった原因は「仕事の進め方の良し悪し」というものが具体的に何であり、各自が改善すべき点が何であるかが見えていないことにあると考えました。
従って、仕事の進め方の良し悪しを計測するチェックシートを作成し、その評価結果をメンバー全員で共有すれば、改善すべき点が何なのか見える化されると考えました。
その結果、各自が仕事における改善すべき点を認識し、自ら行動を変えてくれるようになりました。
その時に活用したチェックシートの作り方と運用方法を以降で紹介します。
問題を防止するチェック項目を作る
まず、チームでよく起きる仕事の進め方の問題を列挙します。
それらを同じ原因でグルーピングして、それを防止するチェック項目を作ります。
例えば、チームでよく起きる問題として、以下の4件がある場合を説明します。
新機能追加のプログラミングのタスクにて、仕様変更を何度かしているうちに、その新機能の目的を忘れてしまい、目的を達成できない(ユーザーが嬉しいと感じない)機能を作ってしまった。
テスト仕様書の作成時に、該当のテストケースでどんな不具合を検出すべきか考えずに作ったため、不具合を検出しきれないテスト仕様書になってしまった。
1つの不具合の修正に対して、丸一日かけて直したが、設計が適切でないため、最初からやり直しとなった。
外部仕様書を3日間かけて作成する際に、疑問点や判断に迷う点がいくつもあったが、一通り作り切るまで相談しなかったため、大きな手戻りになった。
これらの問題を起こさない仕事の進め方ができているかを評価するチェック項目を作ります。
この例の場合は、1. と 2. の問題は、タスクの目的を考えずに作業を進めてしまったことで起きた問題であるため、同じ原因のグループとみなして「自分のタスクの目的が何であり、その成果がどのように活用されるか理解して進めている」のようなチェック項目を作ります。
また、3. と 4. の問題は、手戻りのリスクがある場合に事前に相談せずに独断で進めてしまったことで起きた問題であるため、同じ原因のグループとみなして「大きな手戻りのリスクがあるタスクは、独断で進めず、事前に識者と進め方を相談している」のようなチェック項目を作ります。
なお、実際に起きた問題をベースにチェック項目を作るため、チェック項目の一覧は、一般的な仕事の進め方におけるMECE(漏れなく重複なく)で分類されるものにはなりません。
このチェックシートの目的は、そのチームでよく起きる問題を防止することが目的のため、MECEでなくても問題ないと考えています。
運用方法
当時の私のチームでは、マネージャーの私も含めたメンバー全員が毎月チェックシートで自己評価し、その結果を1つのファイルで確認できるようにしました。
評価結果の判断基準は、以下の通りです。
○：概ねできている（感覚的に90%以上できている）
△：意識はしているが時々できていない（感覚的に60%以上できている）
×：あまりできていない(感覚的に60%未満）
－：そのような機会がない
下図は記入例です。
評価結果は皆に見られるので、できていないのに○にする人はいませんでした。
むしろ、厳しめに自己評価している人が多くいました。
その点で、仕事の進め方の改善点がどこにあるのかが、目に見える形になるという点は、効果がありました。
そして、このチェックシートの運用における必須事項は、メンバーに評価してもらうたびに、マネージャーがフィードバックを行うことです。
例えば、「今月はA君とB君が目的意識の評価項目が○になって素晴らしいですね。実際、この項目での手戻りは最近無くなりましたね。」など、変化点に対してフィードバックのコメントを伝えます。
この手の活動は、フィードバックをしないとやる意味を感じなくなり形骸化するため、フィードバックはなにより重要です。
また、チェックシートの運用は、強制的に全メンバーにやらせるのでなく、皆でチームを改善する手段として納得してもらった上でやってもらうことが必要です。
その上で、日々の業務で仕事の進め方に対する改善を伝える際は、チェックシートにない項目の改善点を伝えても見える化されておらず効果が低いため、チェックシートの項目のみに絞ってそれと関連付けて伝えると効果的でした。
実施効果
「自分の仕事の進め方の改善点を認識」→「それを改善してチェックシートに反映」→「ポジティブフィードバックを受ける」というサイクルが繰り返されることにより、各自で行動を改善する傾向が見られました。
最初は、ほとんどの項目が×の評価だったメンバーも、少しずつ△や○が増えていきました。
半年～1年で×の自己評価は、ほとんどなくなりました。
また、チェックシートというのは、どうしても長くやっているとマンネリ化して形骸化しやすいため、効果が小さくなった時が辞め時です。
私のチームでは、×の評価項目がなくなるなど、一定の基準を満たしたメンバーは「卒業」という形で、チェックシートの運用を終了してもらいました。
チェックシートのダウンロード
私のチームで利用していたチェックシートはWeb上で公開していますので、もしよろしければダウンロードしてください。
ただし、そのチェック項目は「当時の私のチーム」でよく起きた問題です。
利用する際は、それを参考に「ご自分のチームでよく起きる問題」をもとにしたチェック項目に修正した上で活用してみてください。
それが仕事の進め方の改善の助力になると嬉しいです。
連載「ハピネスチームビルディング」の次回の記事はこちら↓
前回の記事はこちら↓
読んでいただき感謝です！何か参考になる事があれば、スキを押していただけると励みになります。毎月チームビルディングの記事を投稿してます。 Twitterもフォローしていただけると嬉しいです。 https://twitter.com/kojimadev