ふりかえりによる情報共有がチームを強くする
アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き 角 征典 オーム社 2007-09 |
システム開発プロジェクトの現状をチェックする手段は
たくさんあります。
それは定期的な進捗ミーティングだったり、社内監査だったり、
その形式はさまざまです。
しかし、それら代表的な手段は特定の人(例えばリーダーやサブリーダー)だけが
参加してることが多いです。
実際に開発をしているメンバーとの意思疎通や情報共有がタイムラグなく
できていればそれでも問題ありませんが、大抵は漏れや遅れが存在します。
本書で述べられているレトロスペクティブ(ふりかえり)はそれらの
漏れや遅れをなくし、かつチームの結束力を高めてくれる手法です。
最近、この本から学んだことをもとに、今やっているプロジェクトに対して
実践してみました。その成果は最後に書きます。
本書の構成は、まずレトロスペクティブのサイクルについての
概要説明があり、その後それぞれのフェーズでのアクティビティ(ポイントみたいなもの)が
書かれています。
■レトロスペクティブのサイクル
レトロスペクティブは以下のサイクルで行われます
場を設定する⇒データを収集する⇒アイディアを出す⇒何をすべきかを決定する
⇒レトロスペクティブを終了する
【場を設定する】
チームの点検、改善を行うために、場を設定する。場を設けることで
これからやることにチームの意識を集中することができます。
今起こっていることを素直に発言できる環境づくりも含まれています。
一番のポイントは、当事者意識というか参加意識を持つ場を設けると
いうことでしょうか。
【データを収集する】
「データ」というとXX数とかYY率とか、そういうものだけを指しているのではありません。
本書では、
客観的な事実はデータの一部分に過ぎない。
データの半分以上は感情的なものである。
感情は、事実やチームについて重要なことをチームに教えてくれる。
と、感情もデータに含まれる、むしろそちらの方が重要だと書いてあります。
私も意思決定において、感情も重要なファクターの一つだと思います。
まぁ、それがいつも良い方向に働くとは限りませんが。。。
【アイディアを出す】
このフェーズでは、問題に対する改善案を検討します。
チーム全員でこの検討をおこなうことで、安易な策に飛びついて
失敗するリスクを軽減できるのだと思います。
【何をすべきかを決定する】
前フェーズででた、策の中からやるべきことを決定します。
せっかくアイディアを出し合っても、行動が伴わなければ、
意味がありません。優先順位や実行可能性をみんなで判断し、
やるべきことを決定します。
【レトロスペクティブを終了する】
具体的なアクションが決定したところで、レトロスペクティブは
終了します。決まったアクションなどを「見える化」して、進捗を
常に全員が把握できる状態にします。
以下、それぞれのフェーズでのアクティビティをいくつか紹介します。
■場を設定するアクティビティ
【チェックイン】
まずはメンバーに参加者意識を持ってもらう必要があります。
そのため、メンバー全員にレトロスペクティブのリーダーから簡単な
質問をします。
質問は、
このセッションに求めるものは?
という簡単なものでOKです。
【チームの約束】
議論が生産的なものになるためにのルールを決めます。
これがないと、議論の空中戦が行われたり、目的に合わない内容が
話しあわれてしまうことになります。
ブレストでいう「批判しない」というのと同じです。
■データを収集するアクティビティ
【タイムライン】
このイテレーション(Agile開発における一つの区切り)で、何が起こったのか
をタイムラインを用いて可視化します。
目的は全体像の把握です。イベントや問題がどの段階でおこり、
そのときに何が行われたかということが共有できます。
タイムラインはホワイトボード+付箋を使って行います。
【カラーコードドット】
これは感情データを収集するために行うアクティビティです。
タイムラインで挙げた内容に各メンバーの感情ポイントをシールなどを
使用してあらわします。
■アイディアを出すアクティビティ
アイディアを出すアクティビティは一般的な、ブレストやフィッシュボーン図などが
あります。
■何をすべきかを決定するアクティビティ
【ドットによる優先順位付け】
本書の中では「アイディアを出すアクティビティ」に分類されていましたが、
私はこのフェーズのものだと思います。
でてきたアイディア(アクション)の中からどれを実行するかを
決定するためのアクティビティです。
各メンバーにカラーコードドットを10個配り、
優先度1には4ドット
優先度2には3ドット
優先度3には2ドット
優先度4には1ドット
という凡例をもとに、優先順位付けをしてもらいます。
これを行うことで、メンバーの総意でアクションが決定されます。
【SMARTな目標】
アクションを実行するための計画を立てる際のアクティビティです。
SMARTとは、
Specific(明確な)、Measurable(計測可能な)、Attainable(達成可能な)、
Relevant(適切な)、Timely(タイムリーな)
という計画を立てる上での指針となるものです。
■実際にやってみて
最後に、私が実際にやってみた感想を書きます。
今携わっているプロジェクトは、イテレート開発はしていないので、
その区切りではできなかったのですが、サービスインを向かえ、プロジェクトが
終わりとなったため、その際に行いました。
【概要】
参加人数:5名
テーマ:円滑な設計からテストを行うためには
手法:KPT(Keep,Problem,Try)によるふりかえり
【成果】
時間を2時間設定したので、始めは時間が余るくらいだと思っていました。
しかし、実際にやってみると色々な意見がでて結局時間をオーバーしてしまいました。
この会議で出た内容は、現プロジェクトでの開発プロセスの問題点や
情報共有方法の問題点など改善活動として次につなげられるものでした。
■まとめ
システム開発はチームでやるものであり、特定の人だけが意思決定に参加するという
問題点を改善し、チーム力を挙げるためのポイントがまとめられた一冊でした。
■編集後記
次のプロジェクトでは、定期的に「ふりかえり」をやりたいです。
■トラックバックさせていただいたサイト
コメント