弊社では四半期に1度、開発者全体でふりかえりを実施しています。従来は「KPT」でやっていましたが、「中長期のふりかえりには向いていないよね」という社内の声を受けて「YWT」を試してみました。

今日はその進め方や感想をお伝えします。なお私がウェブ上の情報を参考に実施したもので、何か正式なやり方に則っている保証はありませんのでご容赦を。

YWTの進行

KPTがKeep, Problem, Tryの頭文字から構成されているように、YWTも頭文字から成っています。それは、

• Y: やったこと
• W: わかったこと
• T: つぎにやること

の3つです。日本で考案された手法とのこと。

実際に今回作成したふりかえり内容から進行を説明すると、

模造紙などの紙を縦長に使い、

1. Y: やったこと(取り組んだ開発作業)を左端に挙げる
2. W: やったことから得られた成果や知見などをYの右側に挙げる(全てのYに対して挙げる必要はない)
3. T: やったこと/わかったことを受け、つぎにやることを挙げる

という流れで実施しました。

具体例を見ていくと、

• Y: (運用中のアプリケーションに)bugsnagを導入して使い始めた
• W: bugsnagなどのエラー管理を運用開始後に導入するのは大変、だけど「エラーはとにかくbugsnagに情報を集約させる」という対応は楽で良い、ということが分かった
• T: bugsnagにエラー情報が集約されるようになったので、発生頻度や重要度から仕分け・修正していこう

という流れが感じられます。

弊社でのアレンジ

弊社は複数のサービスを提供しており、それぞれ別のチームで開発しています。日常的にGitHubやQiita:Teamでチームを横断した情報共有をしていますが、サービスを横断した技術改善に取り組む「開発基盤チーム」のようなものは今のところありません。

なのでこのふりかえりの場で、チームを横断した知見の共有を実施しました。各チームでYWTを実施した後、1人を残して他チームのYWTを見学させ、その内容についてヒアリング¹。さらにそこで「もっと詳しく聞きたい」「自分のチームにも導入したい」と感じたものに「ドットシール」を貼っています。シールが多く貼られた内容については、社内勉強会などで開発チーム全体に共有したいと考えています²。

「まずは事実を挙げる」という進行がいい感じ

やって分かったことは、最初に「やったこと(Y)」という事実を挙げればよい、という進行がポイントだということ。このおかげで各メンバーの脳内変換やフィルタリングが発生しにくい。まずやったことを挙げた上で、そこから「わかったこと(W)」「つぎにやること(T)」の検討をチームで進めるというプロセスに意味がありそうです。

普段から「Qiita:Teamなどで情報共有しよう」としていますが、各自の脳内にある暗黙知を文章などの形式知にする作業はそれなりに労力が必要なもの。「各自の暗黙知でしかない状態から、如何に重要な情報をみつけるか」は、開発現場によくある課題だと思います。このYWTは、そんな課題に効果のあるやり方だと感じました。引き続き活用していきたいと考えています。

参考情報

以下の記事を参考にしました。感謝。

• 長いタイムスパンのためのふりかえりをしてみた - 冥冥乃志
• YWTという振り返り手法について | ナカシマガジン