スクラムにおける開発チームのモチベーションの上げ方とは？ All rights reserved.
© Copyright 2020PMノート.
振り返り 自由に振り返りをして頂いて構いませんが、私は以下の振り返りテーマを提示しました。例としてお使いください。 闇のゲーム時と何が変わったか？ 開発メンバーとしてやるべきことが出来たか？ プロダクトオーナーとしてやるべきことが 今回は、「ポジティブなPDCAを回す振り返り」について記事を書きたいと思います。なぜ、僕がこのテーマで記事を書くか？それは、僕がプロジェクトマネジメントのプロであり、プロジェクトマネジメントにおいてもPDCAのCにあたる振り返りをポジティブに行うことが、自分たちの成長やプロジェクトの成功確率UP、企業・組織の発展を考える上で超大事だと思っているからです！※少し前置きが長いので振り返り術をすぐに見たい方は、目次から「ポジティブなPDCAを回す振り返りフレームワーク」へ飛んでください。目次僕は、IT関連の事業会社で働いており、数々のITプロジェクトを担当してきました。プロジェクトは「独自性があり」「有期的な」取り組みと定義されるので、プロジェクトには必ず終わりが存在しますが、プロジェクト単位で見た時に、一切問題が発生せず全て完璧なプロジェクト進行だったと言えるようなプロジェクトなんて存在しないのではないでしょうか？その一つ一つのプロジェクトの中で発生した問題の原因を特定することや失敗からの気付き、教訓などを抽出し、プロジェクト関係者をはじめ、組織に還元されること、つまりPDCAのCである振り返りを行うことが超大事なんです！いくつかの問題や失敗はありつつも、１つのプロジェクトが終わったのであれば、後ろを振り返るのではなく、前だけを向いて次のプロジェクトに取り組めばいいんじゃないの？と思った、そこのあなた。「ずっと同じ問題や失敗を繰り返すことになりますよ。」問題や失敗を発生した事象を表面的にしか捉えられておらず、「つらかった」「大変だった」と感情的には記憶に残ったとしても、何が原因だったのか、今後何に気をつけて改善するのかは全く分かっていないのではないですか？企業や組織の視点で見ても、企業や組織が長期に渡って事業活動を継続する上で、個人や個別のプロジェクトの中での気付きや教訓がプロジェクト関係者のみにとどまらず、企業や組織に還元されることが望ましいのは言うまでもないと思いますので、その点から見てもPDCAのCである振り返りを行い、プロジェクト関係者をはじめ、組織に還元しましょう。面白いのは、同じ事象を経験したとしても僕と同僚のBさんでは感じ方やそこから気付く内容や学ぶ内容は異なるので、それらを共有し合うことで理解を深めたり、視野を広げることができます。問題の原因や失敗からの気付き、教訓と表現していた為、ネガティブな事象のみをイメージされるかと思いますが、PDCAのCである振り返りの対象は、ポジティブな事象にも目を向けるべきです。ポジティブな振り返りを行わないと、今回のプロジェクトで想定していたよりもたまたま上手くいった好事例がありませんでしたか？その好事例がなぜ上手くいったのかの要因を把握しないと次に同じことが起きるのは運任せ、再現性を高めることはできなくなってしまいます。つまり、成長の機会をみすみす放棄することになってしまいます。プロジェクトの反省会という名前でネガティブな事象のみを対象とする振り返り会を開催している事例をみることもありますが、そもそも精神的に苦痛じゃないですか？PDCAサイクルを回し続ける為には高いモチベーションを維持することも大切である為、上手くいったことやポジティブな事例こそ積極的に取り上げて、次も上手くいくように、更に上手くいくようにポジティブな振り返りを行うことが大事です。問題や失敗の責任を問う場でも、謝罪をする場でもありません！次に同じ問題や失敗を繰り返さない為の改善策や気付き、教訓を得る場であり、上手くいったことの再現性を高め、ポジティブなPDCAサイクルを回す為の原動力とする為の場にしていきましょう！前置きが長くなりましたが、ポジティブにPDCAを回す振り返りフレームワークをご紹介したいと思います。KPT（ケプト）という振り返りフレームワークをご存知でしょうか？を定期的に洗い出して振り返ることで改善サイクルを回します。このフレームワークを用いることで、Keep（良いこと。これからも継続すること。）を挙げることを意識的に行うことができます。つい、振り返り会と聞くと問題や失敗というネガティブな事象を思い出し、その反省点のみに終始してしまいがちな人もいますが、自信を持ってポジティブな良いことをあげることができるのではないでしょうか？とは言っても、実際にKPTでの振り返りを行ってみると、こんなことに出くわすかもしれません。そんな時は、意識的にポジティブなKeepに寄ったファシリテーションを行ったり、1人で振り返りを行うのではなく2人以上で行うようにして振り返りのプロセス自体を共有し知識習得・気付きを得る機会と楽しみながら振り返りを行うと良いと思います。チームで始めた、各人の仕事の進め方や業務プロセスに対するKPTでの振り返りワークショップについてまとめた記事もぜひご覧ください。振り返りのフレームワークとして最近よく耳にするようになったYWT（やったこと、わかったこと、つぎやること）をご紹介します。KPTを試したけど、という方にオススメです！YWTは、を順に洗い出し、振り返りを行います。YWTの振り返りは事実ベースの「Y：やったこと」が基点となって、「W：わかったこと」を抽出し、「T：つぎにやること」を決めていく為、ポジティブな振り返りになりやすい特徴があります。問題解決型の振り返りを行いたい場面では、少し物足りないと感じてしまう可能性があるので、その時はKPTがオススメです。最後に、FDL（Fun/Done/Learn）を簡単にご紹介します。まだあまり知っている方は少ないかもしれません。名前の通り、「Fun（楽しい）」や「Learn（学び）」にフォーカスした振り返り方法であり、最もポジティブな振り返り手法だと思います。スクラム開発チームにおけるスプリントの振り返りを対象に生まれた振り返り手法とのことであり、チームでの振り返りを対象としています。次回のプロジェクトや取り組みに対する各個人のTryを明確にし、行動に起こせる状態にするまでを含めてファシリテーションしてもても良いかもしれません。ポジティブなPDCAを回す振り返りフレームワーク3種として、をご紹介させていただきましたが、どれが良くてどれが悪いということはありません。振り返りの対象や参加メンバーの人員構成、性質によって、どの振り返り方法がマッチするかは異なると思います。下記に振り返りシートのダウンロードが可能なので、個人での振り返りやチームでの振り返りにぜひご活用ください！以下からそれぞれPDFファイルでダウンロード可能です。今回は、以上です。ポジティブな振り返りでPDCAを回し、未来をその手に掴んでください！ご質問やご意見などは、twitterでマツバラヤスユキ（PMノートのオーナーです。 もしよろしければこの記事をシェアお願いします！こんにちは、2015年にPMP（Project Management Professional）を取得したことをきっかけに「僕の知識や経験が誰かの役に立つといいなぁ」という想いでPMノートを運営し始めました。Webディレクターとしてキャリアをスタートし、プロジェクトマネージャー（PjM）やプロダクトマネージャー（PdM）、プロダクトマネジメントチームのリーダーとして働いてきた経験をもとに情報をお届けします。 PdMへのリアルタイムのインタビューでしか感じ取れない「話し手の熱量」やその場限りの「オフレコの話や裏話に詰まったリアル」があります。 シリコンバレーに在住13年以上、米系スタートアップで働く現役Product Managerが具体的事例をもとに、世界の先端で使われるKPIの考え方と使い方を詳しく解説 本ゲームはトランプを使ってスクラム開発、及びチーム開発の改善サイクルを体験できるゲームとなっております。エンジニアでない方でも学びになるところはあるかと存じますので、是非とも皆さん開催していただきたいです。本ゲームは、安井力様が御考案されていた『改めて、快諾してくださった安井様、西村様、有難うございます。本ゲームはチーム開発/チームビルディングにおける上記三点の重要性を体験し、という問いと気づきを参加者に与えることを目的としています。本ゲームは二部構成となっております。基本ルールは最終的にプロダクトオーナーが持っている手札がプロダクトとなります。私は先述した通り、本ゲームは上記二部構成でゲームを進めていきます。闇のゲームを始める前に、以下のルールを提示します。このルールから読み取れるように、闇のゲームは「コミュニケーションロス」状態のチームがいかにストレスフルなものであるか、またそのようなチームの状態がプロダクトにどのような影響を与えるのか、所謂「やりづらいチーム」を体験してもらうタームとなっております。どこまでルールを改変させるか等は難しいポイントですが、敢えてここでは主催者から説明しないでも良いでしょう。その辺りは数回開催した結果と合わせて所感の方に詳しく記載いたします。このタームは闇のゲームで感じていた"やりづらさ"を実際に改善し、その効果を実感してもらう狙いがあります。以上でゲームの解説は終わりです。ここからは数回実施した所感をまとめておきます。私は、このゲームをお昼休みのアクティビティとして開催しました。6~7人の希望者を募って開催したのですが、参加者の方々が全社チャットで「面白いゲームがある」と宣伝してくれたおかげで今では会社のほぼ半数以上の方がこのゲームに参加して下さいました。実際にこのゲームを体験された方から「このゲームは開発者だけでなく、チームを組む全ての職種が学べるゲームだね」という感想を頂戴しました。開催を重ねていくごとに、営業やディレクター、バックオフィスの方々まで様々な職種の方が参加してくださるようになりました。皆さん「勉強になった」とおっしゃってくださり、まさしく全職種の人が楽しめるゲームとなっていることに私自身後から気づきました。この段階では、プロダクトオーナー(以下PO)役をやられた方が特に苦しそうでした。開発メンバーはPOが何を作っているのか分からず、とりあえず指定されたカードに近いカードを出してしまいます。POは開発メンバーが出したカードから1枚しか手札に加えられない為、当初狙っていたロイヤルストレートフラッシュが1スプリントで到達不可能になることもありました。勘のいいメンバーがいると「大きい数字が集まればいいのかな？」「ポーカーかな？」と2~3スプリント目で出すべきカードに目星をつけ始めます。しかしその頃にはPOは既に狙いを変えていて、ストレートやフラッシュ、フルハウスあたりに移行しようとしていたりします。この構図は「何故これを作っているのか」「何をすべきなのか」ミッションの浸透していない、何もかも不透明な開発現場に似ています。残念ながら、このような現場はよくあります。開発だけでなく、様々な業種の人がこのような経験をしていることかと思います。コミュニケーション/目的の明示を封じることによって、かなりリアルな「やりづらいチーム」を作り出せたと感じました。光のゲームでは、参加者の特色がよく出ます。主催者として注意すべきポイントは、カード/人/スプリントは会社の資産の比喩としているので、開発メンバーは最低一枚のカードを引いて、最低一枚のカードを出す、という開発サイクルは守らせなければなりません。私の場合、引くカードの枚数、出すカードの枚数は変更を許容しました。開発リソースに対する投資を増やすということもまた手段の一つであるとの考えからです。この辺りは主催者側のジャッジによりますが、実際の事業/経営としてこのゲームを捉えると判断がしやすくなるかと思います。そのチームは光のゲームにおいて、開発メンバーが最初に引くカードの枚数を5枚にし、毎スプリント3枚ずつカードを引くようにしました。当然トランプには限りがありますので、3か4スプリント目に山札が尽きてしまいました。これは実際の経営で言えば資金ショートということになります。しかしそのチームのPOは"後1スプリントでロイヤルストレートフラッシュができるのだから、借金をしてもう1スプリント回せば良い"と言いました。1スプリントを一ヶ月として、人を一ヶ月雇うのに100万円、チームメンバーが6人なので600万、あと600万あれば3億の利益を生むプロダクトが作れる、と瞬時に計算したそうです。私はチーム開発についてのゲームを作ったつもりでしたが、チームによっては経営判断のゲームとなったわけです。そのPOは経営陣の一人でしたので、やはり視点が違うものだなあとこちらも非常に勉強になりました。長くなってしまいましたが、是非とも本ゲームをお試しいただいて、感想や改善点等を頂戴できると嬉しいです。そして、そもそもこのゲームの元である安井様の『以上、誤字脱字等御座いましたらご指摘宜しくお願い致します。