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