はじめに
最近チーム開発で「失敗したことを振り返りしましょう」とよく言われてます。
といっても、何故か出てこない。なんとなく自分も言いにくい。
その傾向を見ると、過去に失敗した本人は「自分の失敗」と思っているため、
責められると勘違いして、かえって言いづらいのでは？と思います。
(不思議なことに他人のであれば結構出てくるんですよね)
とある本の中に書いてあった失敗の戦略という項目を見てみました。
「本人の失敗」として責めないやり方が書いてありました(とおもってます)
チームで開発するということ
会社やその組織の文化によって違いがあるので、「これ」といった明確的な答えはないですが
今までの経験で一番やりやすかったチームはいかなる失敗も寛容に受け止め、それをどう生かすかどうかを考え
られる信頼関係なのかなと思ってます。
そしてこの本に「失敗の戦略」というものを参考に備忘録として書いておきます。
信頼関係があれば本人の失敗に対して「こいつのせいで失敗した」なんてレッテル貼りをしないからね。
失敗の戦略というもの
かなり難しいことが書かれているが自分なりに内容を解釈すると、失敗したひとや報告した人に報酬を与えてる(いかなる失敗も責めず・攻撃せず寛容に受け止めようと自分は解釈)ということ。
また、二度と同じ失敗を起こさないよう(本人が失敗しないよう意識する。ということではない)原因を追求し対処するということだということです。
| ヘッダーラベル | (1)失敗に気づく | (2)失敗を分析する | (3)失敗を進展させる |
|---|---|---|---|
| 避けることのできる失敗から学ぶための戦略 | どうすべきかわからないときに、安心してマネージャーや同期に相談できるようにする。問題に気づいたらインセンティブを与える。学習を練習という価値を持つ「誤報」（問題が起きた可能性があったが結果的に異常なしとわかった場合に）インセンティブを与える | プロセスの改善のために伝統的な手法を使ったり磨いたりあする。 | ちょっとした試みを即してプロセスの実効性を確かめる技術や顧客の好みが変わっていく場合は特に力を入れる |
| 複雑な失敗から学ぶための戦略 | ミスや問題を安心して報告できるようにする。脆弱性を発見できるシステムにインセンティブを与える。大小に関わらず失敗を早く報告したらインセンティブを与える。 | 職能の枠を超えたチームを収集し何が起きたかのさまざまな観点から確認をする | 危険を未然に防ぐ仕組みをプロセスを導入するため、本来の仕事を離れて試みを行い、失敗の新たなパターンを認識する。 |
| 知的な失敗から学ぶための戦略 | 安心して試みを行えるようにする。成功しないことに早く気づいたことに対してインセンティブを与える。失敗に終わったプロジェクトを早く報告することに対してインセンティブを与える。 | 科学的方法を使って、データを体系的に分析をする。傾向やパターンをさっと評価し中身がない意見を述べないようにする。さまざまな意見を取り入れる。 | さまざま手法を使って、より頻繁に試みを行う。テスト（試験的な実施）にあたっては、成功の証明としてではなく失敗がどのように生まれるかを認識する試みを行う。 |
まとめ
振り返りと言ってもただ実施しただければ意味なく、事前の「信頼関係の積み重ね」がとても重要。それあった上での振り返りが重要だと改めて理解。お互い人間だし。振り返りは重要だかその前の「信頼関係」はもっと重要だということですね。