再訪ありがとうございます!

なんどもご来訪くださりありがとうございます。わたしたちにお手伝いできることはありませんか?ぜひご意見やフィードバックをいただければ幸いです。

翻訳記事

この記事は、Johanna Rothman さんによる「A Simple Way to Measure Work Satisfaction and See Trends」の翻訳です。翻訳にあたり、Johannaさんに快諾いただきました。誤訳や誤字脱字がありましたら、ご指摘ください。

本記事は、#RSGT2022 の基調講演での質疑応答の際に、Johannaさんが紹介したものです。

はじめに

 Leadership Tip #8 にて幸福とは、仕事以外の機能であるため、測定する見込みは薄いと説明しました。そこで私たちは、満足度を測ることを提案しています。また、その方法を伝えていません。ここではいくつかのチームで満足度を計測した方法を紹介します。

Possible Team Satisfaction Scale

まず、上図のような5段階評価から始めています。チームが同じ場所で仕事をしている場合は、この図をツームの拠点の側にある紙に貼り付けています。一日の終わりには、全員が付箋を手に取り、自分が感じた満足感のところに付箋を貼ります。

チームがリモートワークしているときは、コラボレーション用のお絵かきボード(※訳注: MiroやMuralなどのボード)を使います。スプレッドシートは使いません。お絵かきボードを用いるのは、計測時に駆け引きをさせたくないからです。

実際の満足度の評価を見る

実際の評価はこのような感じです。これは一日分の満足度のデータになります。

Team 1 Satisfaction Scale

チーム1は、今日はかなり満足した様子です。「もやもや」("Meh")に付箋を貼った人が1人います。

アジャイルプロジェクトマネージャーのスーザンは、翌日の始業時に、その紙の写真を撮りました。1人だけ「もやもや」("Meh")だったので、スーザンは、付箋を全部剥がして、評価のメモリだけの白紙に戻しました。

チーム1には、以下の合意があるため、彼女は白紙に戻したのです。

  1. もし複数の人が「もやもや」("Meh")だったら、朝に全員が揃ったところで、カイゼンを行うこととする。そうでない場合は、レトロスペクティブを待って「もやもや」な問題に取り組むこととする
  2. もし「もやもや」("Meh")以下の人がいたならば、朝からカイゼンを行うこと

彼らの経験では、この方法は、「もやもや」("Meh" )した仕事をマネージするのに有効です(あなたのチームでは、別の合意が必要なのかもしれません)。

スーザンは、チームの満足度を示す日々の写真画像を、チームのデータ格納先(彼らはWikiを使っていました)に掲示しています。チームは、レトロスペクティブごとにチームの満足度データをレビューしています。チーム1は、毎週レトロスペクティブを行うリズムです。

チーム1は、リアルチームとしてのあり方を学ぶために、たくさんのカイゼンの日々を過ごしていました。

即時的な改善のためのカイゼン

チーム1のカイゼンは、次の質問から始まります。

  • 昨日、満足に至らなかった気持ちの原因をすべて洗い出してください

この質問は、メンバーの具体的な問題に焦点を当てるものなのです。昨日仕事を始めた最初からの問題をリストアップするように進めています。そう、コーヒーがないとか、ビデオツールが機能していなかったとか、そういうところから始まるかもしれません。

摩擦が多いために満足度が得られないことがあり得ます。ビルドシステムに時間がかかりすぎるとか、自動化したリグレッションテストが足りていないとかです。

同僚やマネージャーが仕事を増やしてしまうなんてこともあります。

あるいは、チームメンバーが望まない抜け道を、誰かがチームメンバーに頼んだりもします。

問題が浮き彫りになれば、それに対して何をすべきかを決めることができます。それはチームで解決できることでしょうか?そうであれば、いつから解決するかはチームが決めることができます。

これらの問題がチームの影響力の外にある場合は、ファシリテーターであるマネージャー(スクラムマスター、プロジェクトマネージャー、ピープルマネージャー)が問題を受け止めることができます。

それは、不満を持っている人がそれほど多くない「小さな」問題に対して有効です。では、チーム全体が不満を抱いている場合はどうでしょうか?チーム2にはその問題がありました。

不満な点を曝け出す

この組織は、アジャイルアプローチがもたらすものを求めていました。しかしながら、マネージャーはプロジェクトポートフォリオを管理することができていませんでした。つまり、プロジェクトがアウトカムを出すよりも、プロダクトオーナーが考えを変えることの方が多かったのです。

シニアマネージャーから電話があり、「チーム2がやる気をなくしているので、彼らのところに来て、修正してあげてほしい」と言われたました(私たちは、人を直すことはないということを話し合い、コンサルティング契約に合意しました)。

チームメンバーたちと個別に会い、そして、相対的な満足度を掲載して、見つけたことを議論してもいいかを尋ねて、彼らも同意してくれました。

Team 2 Satisfaction Scale

上図のようになりました。私たちは、その初日の図を出発点として、リーンコーヒーをはじめました。その後、レトロスペクティブを実施しました。

チームで解決できることもありましたが、マネージャーが問題を解決するまで、誰もそれにやりがいを感じませんでした。

私は、マネジメントにチームの不満のほとんどはそれらが原因であると説明しました。マネージャーは驚き、そして、不満を持ちました。

マネージャーと私は、モチベーションについて、それは内部にあることで、マネージャーが変えるべき選択肢であることを議論しました。

その時は、彼らは私の提案を選択しませんでしたが、チームは、満足度の図を作り続けました。

1ヶ月後、チームには不満を示すトレンドがみられました。そして、その問題を議論する方法を知っていたため、チームはその問題をマネジメントに提起することができたのです。

チーム2の組織は、アジャイル文化への変化にまだ苦労しています。しかしながら、彼らは今、データを持っているのです。

満足度のトレンドは有効

満足度のトレンドを実験してみたいのでしたら、以下のアイデアを検討してみてください。

  • 5段階の定性評価を用いる。
    私はこの尺度を好みますが、あなたは別のラベルを好むかもしれません。
  • 数値を用いたり、各段階を数字に置き換えることは避けるべき。
    段階を数字に置き換えて「おー、3.0以上なら大丈夫」と言ってしまうかもしれませんが、それは大丈夫ではないかもしれません。数値を平均化することは、すべてのトレンドを見ることとは異なるのです。
  • 匿名のデータから始める。
    トレンドをみるには、匿名のデータしか用いません。ある時点で各人が自分が経験したことを説明するのに十分な安心感を得る必要があるからです。それにより、他の人も自分と同じような問題を経験していることがわかるかもしれないからです。

これは一つの方法としてあなたのツールボックスに入れておいてください。他のプロジェクトベースの計測については、「Create Your Successful Agile Project」をみてみてください。また、モチベーションの低下を防ぐ方法については、「Practical Ways to Lead an Innovative Organization」をみてみてください。

本記事の翻訳者:

長沢智治

長沢 智治 - アジャイルストラテジスト

サーバントワークス株式会社 代表取締役。Helpfeel Inc. アドバイザリーボード。DASA アンバサダー/認定トレーナー。

PSPO II - Professional Scrum Product Owner II
PSPO I - Professional Scrum Product Owner I
PSM II - Professional Scrum Master II
PSM I - Professional Scrum Master I
PSD I - Professional Scrum Developer I
PAL-EBM - Professional Agile Leadership - Evidence-Based Management
PAL I - Professional Agile Leadership I
SPS- Scaled Professional Scrum
PSU I - Professional Scrum with User Experience
PSK I - Professional Scrum with Kanban I
PSF - Professional Scrum Facilitation Skills
PSPBM - Professional Scrum Product Backlog Management Skills
認定スクラムマスター
DASA Accredited DevOps Trainer
DASAアンバサダー

『More Effective Agile』、『Adaptive Code』、『今すぐ実践!カンバンによるアジャイルプロジェクトマネジメント』、『アジャイルソフトウェアエンジアリング』など監訳書多数。『Keynoteで魅せる「伝わる」プレゼンテーションテクニック』著者。

Regional Scrum Gathering Tokyo 2017, DevOpsDays Tokyo 2017, Developers Summit 2013 summer 基調講演。スクー講師。

プロフィール