はじめに
こんにちは、新卒3年目エンジニアの@rs_tukkiです。先日開発オフィスが移転となり、美味しい昼食を探し求める日々が続いています。
さて、昨年このブログの中でこんな記事を書きました。
振り返りの手法のひとつ「KPT法」について説明した記事ですが、今回はその第二弾として「YWT法」について話してみたいと思います。
復習-KPT法とは
まずはKPT法について再確認しておきましょう。
KPT法とは、「振り返りの手法」として用いられている枠組みのひとつです。主にはアジャイル開発を採用したプロジェクトで実施することが多いですが、それ以外の現場でもやっていることを改善してよりよい方向を目指すために役立ちます。
今までの取り組みで感じたことを、
- K : Keep(継続すべきこと)
- P : Problem(問題だと思うこと)
の二つに分類して挙げてもらい、その中から次回の取り組みで実践することを
- T : Try(改善していくこと)
としてまとめます。
次回の振り返りではTryの内容がまたKeepやProblemに分類され、更なる改善を目指していくこととなります。
YWT法
KPT法について復習したところで、YWT法について説明します。
YWT法はKPT法と同じく、振り返りの手法として用いられている枠組みのひとつで、KPT法とは異なり
- Y : やったこと
- W : わかったこと
- T : 次にやること
という三つのステップに分割されます。
日本発祥のフレームワークで、日本能率協会コンサルティングで提唱されたのが始まりだそうです。
Y :やったこと
まず初めに、Y : やったこととして、今までの取り組みの中で文字通り「取り組んだこと」を書き出します。 開発プロジェクトであれば新機能を実装した、特定クラスのリファクタリングをした、テストコードを作成した、などなど。ルーチンワークと化しているものはYWTに乗せてもあまり効果がありませんので、上記のように単発の作業を挙げるといいと思います。
W:わかったこと
Y : やったことを洗い出したあとは、それを踏まえてW : わかったこととして、やったことの中から何を学んだか、どんなことに気づいたかを書き出します。
例えば、特定クラスのリファクタリングをしたところ、そのクラスの可読性が上がったとします。では、他のクラスでもリファクタリングを実施すれば同じように可読性は向上するでしょうか？
あるいは、新機能実装の過程で潜在的なバグがいくつか埋め込まれてしまったとします。バグはどうして生み出されてしまったのでしょうか？それを回避するためにはどうすればいいでしょうか？
このように、一つの事実から原因を深掘りしていくことで、今回やったことを次の機会にも生かせるように学びとして記録していくことがW=分かったことの一番大事な部分です。
T:次にやること
最後にT : 次にやることです。
Wで洗い出した内容を次回に向けてどう生かすかをまとめます。
「リファクタリングが他のクラスでも行えそう、その結果コード全体の可読性がよくなりそう」ということが分かったので、次から積極的にリファクタリングに取り組む、
「実装の際にレビュー担当者が1人だけだとバグを見逃す可能性がある」ということが分かったので、複雑な機能に対しては二次レビュー担当者を配置する、といったことが挙げられるかと思います。
そして、ここで挙げた「次にやること」は、KPT法と同じくそのまま次の振り返りで「やったこと」として記録することができます。
どちらも同じですが、振り返りは一度で終わらず「継続すること」が最も大事だと言えます。
YWT法のメリット
振り返りを実施する時は、実際にそれまでの活動で何があったかを思い出し、上手くいったこと、いかなかったことを振り分けながら考えていくことが重要です。
それをしないまま曖昧な記憶のもとに振り返りを行うと、KPT法で言うところのP(Problem)にのみどうしても目がいってしまい、K(Keep)が疎かになってしまいがちです。
YWT法では、まさにその「思い出し」から始めるフレームワークであり、問題点と並んでよかった点も意識せず洗い出すことができます。
そのためKeepに目が行きやすい、という点がYWT法の利点の一つです。
KPT法とどっちがいいの？
KPT法とYWT法で明確にどっちがいい、という結論はありません。
強いて言えば、YWT法はやったことを通して学んだことを次に生かす、というコンセプトなので、学習を目的としたプロジェクトで採用しやすいのでないかと思います。
しかし、振り返りに慣れていない人にとっては「わかったこと」を漠然と考えるより、問題点や継続すべき点を洗い出す、というイメージが湧きやすいKPT法が楽なケースもあります。
また、そもそも手法もこの二つに限りませんので、チームの状況によって柔軟に変えてみる方がいいでしょう。
おわりに
今回は、チームの振り返りの手法として、KPT法に次ぐ「YWT法」を紹介しました。
上記の通り、どの方法がいいかはチームの状況によっても変わると思いますので、これらに限らず実際にやってみてしっくりきた方法をとってみるのがいいかと思います。
ぜひ、皆さんのチームでも試してみてください。
参考
ブレスト初心者向けアイデアのまとめツールとして使えるフレームワークをご紹介
KPTとYWTの違いは？～KPTがうまくいかない理由と、YWTの特性を考える - Qiita
YWT分析 - ラーニング・ラボ
https://www.kikakulabo.com/tpl-ywt/
エンジニア中途採用サイト
ラクスでは、エンジニア・デザイナーの中途採用を積極的に行っております！
ご興味ありましたら是非ご確認をお願いします。
https://career-recruit.rakus.co.jp/career_engineer/カジュアル面談お申込みフォーム
どの職種に応募すれば良いかわからないという方は、カジュアル面談も随時行っております。
以下フォームよりお申込みください。
rakus.hubspotpagebuilder.comラクスDevelopers登録フォーム
https://career-recruit.rakus.co.jp/career_engineer/form_rakusdev/イベント情報
会社の雰囲気を知りたい方は、毎週開催しているイベントにご参加ください！
◆TECH PLAY
techplay.jp
◆connpass
rakus.connpass.com
