BT

Ready for InfoQ 3.0? Try the new design and let us know what you think!

アジャイルのレトロスペクティブはなぜ難しいのか?

| 作者: Ben Linders フォローする 29 人のフォロワー , 翻訳者 吉田 英人 フォローする 0 人のフォロワー 投稿日 2013年7月16日. 推定読書時間: 6 分 |

原文(投稿日:2013/07/11)へのリンク

レトロスペクティブ(ふりかえり)は,チームの作業方法を見直して修正することによって,自らの作業を改善するものだ。より多くの価値をユーザに提供する手段として,アジャイルの重要な手法のひとつに数えられることも多い。しかし時には,レトロスペクティブを行うのが難しく思われることもある。変更すべき対象がチームメンバのコントロール範囲外にあると感じられたり,改善の余地がないように思われたり,適切なアクションの定義が難しく感じたられりすると,アクションの定義よりも先に不満が口をつき始める。そうなるとレトロスペクティブがつまらない,単なる時間の浪費だと感じられてしまうのだ。このような問題に対処して,より有意義なレトロスペクティブを行う方法を見つけるには,どうすればよいのだろう?

Keith McMillan氏のブログ記事 agile concept of the week: retrospective には,レトロスペクティブとは何か,どのように実行するのか,うまくいかない場合はどうすればよいのか,といったことが概説されている。最初はレトロスペクティブを行う理由についての説明だ。

マニフェストの背景には,"チームは定期的に,より効果的になるにはどうすればよいかを時間を掛けて検討し,その結果に従って自らの行動を修正する" という原則が含まれています。これを行うための,もっとも一般的な方法がレトロスペクティブなのです。

そして氏は,レトロスペクティブを実践するチームに見られる,いくつかの問題点について言及する。

  • (...) 自分たちのコントロール範囲外にある,組織的な要件と思われることへの挑戦に消極的である
  • (...) 自分たちの行動を最適だと感じ,それ以上変更する必要はないと考える
  • 試してみたいことをなかなか見つけられない場合がある
  • レトロスペクティブが他のチームの行動への不満や,過去の出来事への不満にすり替わってしまうことがある

氏のブログでは,それぞれの問題に対する解決策として,上層部の支援を獲得する,チーム間で競い合う,アクションのカテゴリを追加する,注意深くチームを運営する,という方法を提案している。

Olga Kouzina氏はretrospectives, part 2: In a sentimental moodというブログ記事で,チームがレトロスペクティブを始めるときに困難を感じる理由について説明している。氏が指摘するのは,"レトロスペクティブを行うにはチームが十分成熟していなければならない" という点だ。

チームがレトロスペクティブを熱望するとき陥りやすい,よくある落とし穴のひとつは,レトロスペクティブの実施それ自体を目的化することです。アジャイルであるならば,レトロスペクティブを行わなければならない,それは周知の事実です。ただしそれは,ガイドラインに従って行うような単純なものではなく,チームの内部から生ずる必要性によるものなのです。チームに必要なのは,この問題解決に対する強い意思を育むこと,それにも増して重要なのは,その責任を受け入れることです。

チームが十分に成熟しているかを判断するために,氏はいくつかの指標を紹介している。

  • 非難をしない文化
  • コミュニケーション
  • 責任を追及しない

さらに氏は,なぜ人々がレトロスペクティブへの参加を望まないのか,より深い理由を見つけるために,その根本原因を解析した。

ほとんどの場合,疑問の連鎖(chain of whys)はまったく同じ問題を明らかにして終わります。レトロスペクティブは意味のあるアクティビティではない,という問題です。場合によっては,チームリーダやCEOが,アジャイル本に従って実行する儀式に過ぎません。彼らは実際には,すべての問題を認識していますし,その解決策もいくつか心の中にすでに持っているのです。ですから,このようなケースでのレトロスペクティブは,むしろチームの雰囲気を確かめて,リーダの判断がチームの期待に添うものか確認することを目的とした,意見確認のためのミーティングなのです。

ブログの結論として氏は,レトロスペクティブ改善のためにいくつかのアドバイスを行っている。

大規模な組織では,レトロスペクティブの実行を任された人たちが,組織の文化を変えるための手立てを持たない場合がほとんどです。もし誰かがある特定の位置,例えばレトロスペクティブの実施対象として白羽の矢が立てられたタスクに閉じ込められていたとしたら - その人はこの儀式を妨害して,自分たちの責任の及ぶ範囲内で対処するための方法を探すことでしょう。ロールプレイ,モデレータの入れ換え,固定時間の割り当て,道化役 - こういったアドバイスは,まさにそのようなオーディエンスのためにあるのです。

how to improve your sprint retrospective meeting?と題するブログ記事を書いたRini van Solingen氏は,チームがレトロスペクティブ実行の際に感じる困難について,次のように述べている。

スクラムが機能する上で,レトロスペクティブは非常に重要なものです。しかし多くのチームが,実用的,精力的,集中的なレトロスペクティブの運用に苦労しています。効果的な運用ができないため,レトロスペクティブを諦めるチームさえあります。これはスクラムにとって,まったくのマイナスです。レトロスペクティブがなければ,継続的な改善サイクルが断ち切られてしまうからです。ですが,効果的なレトロスペクティブを快適に実行するのは容易なことではありません。

レトロスペクティブに関して氏が目にする誤りは,次のようなものだ。

  • レトロスペクティブが退屈でつまらないルーチンワークになる
  • 実行不可能な改善が多過ぎる
  • 次のスプリントでは変更不可能なことに意識を集中する

氏は,レトロスペクティブ改善のための5つのヒントを提供する - 形式による変化,カイゼン,目標設定,マネージメントの参画,そして,テーブルをなくすことだ。

Craig Strong氏は,自身のブログ記事 top gear agile retrospectiveの冒頭で,組織がレトロスペクティブを適用することの難しさについて説明している。

(...) デリバリへの圧力や炎上しているプロジェクトがある場合,レトロスペクティブは事務的なものに思われたり,しばしば無視されたりします。そしてそれこそが,継続的な改善にとって,本当の意味で重要な問題なのです。

氏が望んでいたのは,チームが実施をエンジョイできて,なおかつ問題の根本原因に到達するような,対話的なレトロスペクティブによって,チームとともに行う改善を支援することだ。そのために氏は,"クールウォール(cool wall)" というレトロスペクティブ手法の導入を決定すると同時に,Top Gearをテーマとして採用した。チームメンバから車に乗った自分たちの写真を提供された氏は,部屋をTop Gearからの写真でセットアップした上で,retrospective prime directiveを読み上げ,レトロスペクティブの場を設定するためのチェックイン用の質問をチームに求めた。さらに氏は,チームメンバに対して,他のメンバのスキルを "クールではない" ”クール" "スーパークール" そして "マイナス" というカラムを使って投票するように指示した。一方チームでは,5whyのテクニックによる根本原因の解析を使用して,問題の原因を洞察した。それからDiana Larsen氏の"円とスープ"ゲームを使用して,自らのコントロール範囲内にあるアクションを見い出した。

このレトロスペクティブの最後として氏は,有効だった情報と無効な情報を区別するために,チームに対してフィードバックを求めた。氏の結論は以下のようなものだ。

全体を通してこのセッションは,チームにとってやりがいと価値のあるものでした。面白く,エネルギーレベルも高く,そして何よりも,チームとして,具体的なアクションを備えた改善方法を見出すことができたのです。

レトロスペクティブを行うときに,読者であるあなたはどのような問題を経験して,どのように対処しているのだろうか?

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション
BT