振り返りは、学びと成長のエッセンス
こんにちは、まままです。
振り返りに関してのハナシです。
はじめに
振り返りと言うと、トラブルに対する振り返り、リリースに対する振り返り、フィールド障害に対する振り返り、バグに対する振り返りと、様々な振り返りがあり、何を振り返るかは、会社やプロジェクトによるかなと思ってます。
また、開発プロジェクトにしても、フィールド障害にしても振り返りは不可欠なプロセスです。進捗、課題、成功要因を評価し、将来のプロジェクトやプロセス改善に活かすことができます。この記事では、振り返りの重要性に焦点を当て、成功への鍵を探求しようと思います。
でも、いざ振り返りをしようと思っても(しても)、振り返り会をしただけで終わってしまったり、表面的な話しかしない振り返り会になっちゃったりと、将来に繋がる振り返り会ができていない場合もあるかと思います。
そこで、振り返りに対して、どう向き合うべきかとか、振り返りで大切なことをまとめてみようと思います。
前提
振り返りというと、対プロジェクト、対フィールド障害等、スコープにより内容が異なる部分があると思いますが、この記事では、振り返り全般に言えることと、共通することを記載しようと思います。
振り返りとは何か？
まずは、振り返りとは？というトコロを考えてみましょう。
・とあるイベントや作業に対して良かったこと、悪かったことを確認、共有する。
・悪かったことの部分を改善するための施策を立案する。
が大きな目的の2つになるかなと思います。
上記の2つが目的ではあるんですが、よくありがちな振り返り会として…
・議論会ではなく、批判会になってしまう
・参加者で何も喋らない(意見、質疑を出さない)人がいる
・振り返り会で話して満足して、それで終わりになってしまう(振り返り会で出た内容のその後の監視ができていない)
になってしまうのがあるあるかなと思っています(僕の経験上としても)。
振り返りのプロセスとしては、以下が一般的かなと思います。
事実、出来事、データの収集: 振り返り対象に関連する良かったこと、悪かったこと、発生したアクシデント、各種データ、メトリクスを収集して、実績や問題点を確認します。
分析と課題の見つけ出し: 上記の1の内容から、成功要因、課題、および改善の機会を特定します。何がうまくいったのか、何が問題だったのかを分析します。
課題解決のための施策立案: 問題を解決し、改善を行うため、再発を防止するための具体的な施策を立案します。
実施施策の監視とフィードバック: 振り返り会の場で終わらせるのではなく、監視ポイントの計画まで決定し、監視ポイントでは実施内容に対してフィードバックを実施します。
そのプロセスの中で、理想的な振り返り会としては、
・きちんと準備含めて時間を取り、足踏みをして、立ち返る、見直す場にする
・課題を見つける会になっている
・課題に対する施策と、その施策の監視計画を確立させる
・参加者全員の意見、発言を聞く場になっている
がポイントになってくるかなと思います。
振り返りの重要性
振り返りは、意外と重要です。振り返りをしないと、何も改善が入らないまま次に進んでします（苦しい状況から抜けられない）、課題を解消できずに、問題がある状態でプロセスが進む、といったような状況に陥ります。
なぜ振り返りが次の成功につながるのかをいくつかのポイントで整理します。
学びの機会: 振り返りは、過去の経験から学び、成長する機会を提供します。成功と失敗の両方から教訓を得ることで、次の活動に活かすことができます。
問題の早期発見: 振り返りによって、問題や課題を早期に発見し、対処する機会が増えます。これにより、問題がエスカレートする前に対処することができます。
チームの連携強化: 振り返りはチームのコラボレーションを強化します。チームメンバーはお互いの意見や視点を共有し、共通の目標に向けて協力できる機会の提供になります。
持続的な改善: 振り返りは持続的な改善のプロセスの一部となります。毎回の振り返りから得られるフィードバックを用いて、プロセスと成果を改善し、改善できる仕組みを維持します。
振り返りの注意点
パフォーマンス的な振り返り(振り返りをやったよ！っていうことだけを残す振り返り)ではなく、将来に繋がる振り返り(課題が見つかって、改善に繋がる)ためにも、振り返り会実施には以下の注意点があります。
・事前準備
振り返り内容を事前に共有して、参加者全員が振り返り内容に対して、内容の読み込みと自分の意見をまとめてから会議に望む必要があります。
(他の打ち合わせとかでも言えることではありますが、振り返り会では特に重要になってくるかと思います)
これができていないと、会の場で、沈黙が続いてしまったり、意見の深掘りや議論ができなくなりがちです(ファシリテーターとしてはとても困る!!)。
そのためにも、参加者全員でちゃんと工数取って対応が必要です。
・批判会にしない
特にフィールド障害の振り返りやバグに対する振り返りとかでありがちだと思いますが、
「当事者を責める」
「なんでコレやってないんだ？、なんでアレしてないんだ？攻撃をする」
「当事者の意見全否定」
は、絶対にやってはいけないです。
当事者の言い訳や反省を聞くというよりも、何が問題だったのか？何が課題なのか？課題を解決るすためにどうするか？を議論するのが振り返り会です。
・表面的な課題ではなく、根本的な課題を見つける
課題には、表面的な課題と根本的な課題があります。
表面的な課題: 確認が漏れた、パターンが漏れた
根本的な課題: めんどくさくてこの作業を省略した、、、パターンを考える時に参照したドキュメントに書いてなかった、、、みたいにどんどんなぜ？なぜ？した結果
その中でも根底にある課題を見つけることが重要になってきます。
根底にある課題(根本原因)に対しては、具体的な改善案や課題となっている事象を出すことができます。
逆に表面的な課題(直接原因)に対して議論しても、〇〇を気をつける、△△を意識すると言った気持ち的な努力目標が結論として出てきがちです。
振り返りのメリット
開発プロジェクト振り返り
開発プロジェクトの振り返りは、成功への鍵となります。プロジェクトの成果や過程を評価し、学び、改善点を特定することで、次回のプロジェクトにおける成功の確率を高めることができます。振り返りは学びの機会であり、問題の早期発見手段でもあり、チームの連携を強化向上させる道でもあります。
振り返りを成功させるためにはオープンなコミュニケーション、事実に基づいた分析、継続的な振り返りが重要です。これらの要素を組み合わせて、プロジェクトの振り返りを効果的なプロセスに変え、成功につなげましょう。
また、振り返りはプロジェクトの成績向上に貢献します。プロジェクトの各段階で振り返りを実施し、絶えず学び、成長し、改善する文化を築きましょう。振り返りは成功への鍵であり、進化し続けるプロジェクトの中核でもあるかなと思います。
バグや重大なフィールド障害振り返り
バグと重大なフィールド障害の振り返りは、ソフトウェア開発と運用において重要なプロセスです。品質向上、未然の危機回避、チーム学習、コスト削減など、多くの利点があります。
バグや重大なフィールド障害が発生した場合、バグや障害をただ解決するだけでなく、振り返りを通じて学び、改善する姿勢を持つことが重要かなと思います。
バグや重大なフィールド障害は避けられないかもしれませんが、振り返りを通じて、再発防止策を打ち、ソフトウェア品質を向上させることができます。
まとめ
振り返りは、開発プロジェクトやソフトウェアの品質向上に不可欠なプロセスです。また、振り返りは、過去の経験から学び、課題を特定し、未然の危機を回避する手段にもなります。
バグと重大なインシデントの振り返りも同様に重要です。品質向上、問題の再発防止、チーム学習、コスト削減など、多くの利点があります。
最終的に、振り返りは”失敗を成功に変える”の鍵であり、”成功体験を継続させる”鍵であり、プロジェクトやソフトウェアの品質向上に貢献します。
最後に、
振り返りの文化を醸成し、プロジェクトチームが共同で学び、成長し、改善する文化を育てましょう。
持続的な改善の一環として、振り返りを継続的に実施し、未来の成功に向けて努力しましょう。
振り返りは問題の解決だけでなく、学びと成長のプロセスに繋がることも忘れずに。
この記事が気に入ったらサポートをしてみませんか？