サウスポーなエンジニアの独り言

サウスポーなエンジニアが日々感じた、気づいた、学んだことを徒然と書いています。

Agile 仕事のやり方 改善 旧館より

フリカエリ

投稿日:2012年2月28日 更新日:


[仕事]「可視化」と「見える化」で書いた勉強会で、「朝会」と「見える化」ともう1つ「フリカエリ」について考えることがありました。

今のチーム(約2年)では原則、(Scrumの)イテレーション毎にフリカエリを行い、そこではKPT(Keep/Problem/Try)のフレームワークを使っています。

やり方はほぼプロジェクトファシリテーション実践編 ふりかえりガイド(※リンク先はPDF)の通りです。
以下は、今のチームでやっている工夫や気づいたことです。

W(分かったこと)を書き出す

KPTに似たようなフレームワークで「YWT」というものがあります。
Y(やったこと)・W(わかったこと)・T(次にやること)というもので、弊社ではひょっとするとKPTよりこっちに慣れている方が多いような気も・・・。

Keep・Problemといった事象やアクションから「感じた」何かがあると思います。
それを「W(分かったこと)」として書き出します。
分かっこと自体がTryなどの直接のアクションになることは少なくても、それをさらに深く考えることで別のTryに結びつくこともあります。

日常的に書き出す仕組み

youRoomをコミュニケーションツールとして使っています。
そこにイテレーション開始時に”あらかじめ”フリカエリ用のスレッドを立てておきます。そして、日常の開発などで「あっ!これはPかも」「次はこんなこと(T)したいなぁ」と思えば、すぐに書き込むようにしています。

イテレーション終了時のフリカエリより先にPの内容によってはすぐに対応できます。
早く対応した分だけ、チームのパフォーマンスが上がります。
なかなかチーム全員が開発に集中しているとPへの対応は後回しになりがちですが、そこはスクラムマスターがうまく動くことである程度はカバーできると思います。

Problemの深掘り

これは最近やり始めたことです。

Pに対してTを書き出しますが、中には「本当にそれでPは解決する?もう少し深く話した方がいいのでは?」というものもあります。
例えばPの原因が実は根深かったり、TがPの対処療法にしかなっていない等です。

このような場合、(KPTが一通り終わった後)新しいホワイトボードにPを中心としたマインドマップを使って深掘りします。
こうすることで「隠れていた本当のP」や「(Pに対する)より効果的なT」が見えてくることもあります。
(時間の関係で)全てのPを深堀りすることはできないことも多いので、チームが「これでできるのかな?」と半信半疑な雰囲気になっているPを取捨選択する必要があります。

ProblemのTry以外にも、チャレンジしたいTryを書く

(Pとは関係なくても)「こんなことにチャレンジしたい!」という意味のTも書き出すようにしています。
そしてそれがPJの方向性と合うのであれば、実際にその手を上げたメンバーを中心にして、次のイテレーションなどでやるようにします。

(サインアップのように)「自分がやりたい!」と手を挙げることで、その質やコミット感が強くなるのが良い点です。
Pに対するTは(改善ではあるものの)、(内容によっては)「できていないこと」にフォーカスが当たりがちです。
ですので、前向きにやる…とのが難しいこともあります。

それとバランスを取るように「チャレンジしたいT」を使ってみると良いと思います。

同じProblemが上がっていないかを見る

同じチームで何度かフリカエリをやっていると「あれ、これって前も同じようなPが上がっていなかったっけ?」というシーンが出てくることもあります。
同じPが出ていると、ひどい場合には、チームの中に「どうせ変わらないし…」という負の感情やマンネリ感が出てしまい、あまり良い状態ではなくなります。

そこで毎回フリカエリのKPTを(写真などで)残しておき、次のフリカエリでそれを眺めて、同じようなPが上がってないか?を見るようにしています。
そのようなPがあるなら、その根本原因やTを工夫しないと、また同じ結果になってしまうのでチームで対応を考える…例えば、上に書いた「深堀り」の対象にするなど…必要があります。

気づき:暗黙知となったKは減っていく

同じチームでフリカエリを行なっていると(PやTはそれなりに出ているのですが)Kは少なくなっていきました。
チームの状態が悪くなったわけではなく、そのKがチームにとって当たり前になり「暗黙知」になったのです。
そして「あえて書き出すまでもない当たり前のこと」になり、Kとして出ることがなくなったわけです。
新しいメンバーが入って、そういう暗黙知を「K」として書き出すことで改めて、チームがその良さに気づくということがありました。

このように、いくつか工夫はしていますが、最初に上げた「プロジェクトファシリテーション実践編 ふりかえりガイド」に書かれているほぼその通りです。

大事なのは(リーダーなどを含めた)チーム全員が、そこに書かれている心持ちや姿勢を取ることができるか?ということです。
その点では、(日常の)朝会に比べると少し難しいかもしれませんが、フリカエリをきっかけにチームが大きく変わることもあるのでチャンレジする価値はあります。

※注意:この記事は旧サウスポーなエンジニアの独り言から移行し一部修正したエントリです。

Photo by Acarlos1000 on Visualhunt.com / CC BY

-Agile, 仕事のやり方, 改善, 旧館より

執筆者:


comment

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

関連記事

「従業員」満足度調査

本人が望む、望まないは別として「顧客満足度調査」等のようなアンケートに答えたことが1回はあると思います。 その兄弟で「従業員満足度調査」なるものがあります。 「自分の会社にどれほど満足しているか1~5 …

タスクマネジメントツール「Trello」

今のところ、個人で一番使っているタスクマネジメントツール「Trello」です。 Trelloとは? 「Fog Creek Software」が提供しているWebベースのタスクマネジメントツールです。 …

何かを変えたい(チェンジ)時の5つのコツ

先日「AgileTourOsaka2012 in Minoh」に参加してきました。 箕面という珍しい土地も楽しめましたし、スピーカー3人ともあまり関西ではお話されない方なので、お話が聴けて良かったです …

「レビュー」タスクの見積もり

1~3年目のような経験の浅い方が見積もる「レビュー」タスクの工数について思うことがあります。 レビューはある成果物…提案書や設計書、ソースコードなど…を個人/複数のメンバー…たいていはプロジェクトリー …

エンジニアの特徴って高い「知的好奇心」

以前「お医者さん」だって全部の病気を知らないでしょ?で書いた「(知らないアプリケーションについて)頑張ればそれなりに答えれる事もありますがそれをしない理由」(ややこしい言い方)を自分なりに書きます。 …

ギルドワークスの現場コーチ。
「正しいものを正しくつくる現場を増やす」ことを目指している現場コーチ。認定スクラムマスター(CSM)。
様々な規模のSIerでのシステム開発を経て今に至る。
DevLOVE関西を主催。