#37 「失敗を報告しにくい組織」を回避したい
QAエンジニアをやっていると「多くの失敗」に遭遇します。
一つの不具合に着目してみても、例えば
・「仕様の理解不足」
・「テストの観点漏れ」
・「コードが複雑怪奇」
など。他にもあるでしょうが、いろんな「失敗」を発見します。
そして、その失敗を「そのままスルーさせないこと」は製品の品質向上に繋がるわけだと思うわけです。
今回はそんな「失敗」と「組織」の関係性について考えてみたいと思います。
失敗を許容できる組織づくり
「失敗をしてはいけない」という考え方は「行動を鈍らせたり」「発言を抑制」します。これは品質を保つにおいて「余計なことをしない」ことには繋がるかもしれませんが「改善」には繋がらないのです。
基本的に製品というものは作ったその瞬間から「劣化」していくものであり、何もしなければ「徐々に壊れていく製品を指をくわえて見ているだけ」になってしまうので、私としては「失敗してでも行動する」ことが大切であり、そういった組織を作ることも重要だと思うわけです。
PACE
私が今着目しているのが「PACE」というコミュニケーションのヒントとなるフレームワークです。（元は航空業界で取り入れられNASAなどでもクルー同士の訓練に取り入れられていたとのこと）
Probe（確認・探求)
Alert（注意喚起）
Challenge（挑戦）
Emergency（緊急事態）
例えば、この「PACE」をベースとしてコミュニケーションをすれば、部下➡︎上司への進言がしやすくなります。（と思っています）例えば
@上司
【Probe（確認・探求）】
～～～についてご存じでしょうか？
上記のようなメッセージのルールを作ることで、Probeであれば「分からなかったことが何なのか」が理解できるため、「ナレッジ整備」の参考にできるかもしれません。
Challengeであれば「挑戦的な話なんだな」と理解できるので、それを汲んだ上でレビューできます。
Emergencyであれば「緊急だ。すぐ対応しよう」と分かるし、Alertであれば、それを後から拾って振り返ったり、改めて周知することもできます。
振り返りの上で、どの項目が多かったのか。どの項目に時間がかかっているのかが分かれば、改善できる部分を見つけられるかもしれません。日常的に使えなくても、発言する時のヒントとして使っても良いかもしれません。
組織と失敗
「失敗をすることが悪」なのではなく「失敗を放置し見逃すのが悪」なんですよね。なので、「放置し見逃していないか」という観点で組織を運用するのが個人的にはベターだと思っています。
人間は「知っている問題・起こしてしまった問題を隠蔽しようとしてしまう生き物」なので、その特性を知ったうえで「どう自己開示できるか」「どう失敗を大っぴらにできるか」を考えると良い組織の運営ができるのではないでしょうか。という妄想をしてみました。
参考文献
👆PACEのお話はここから参考にしました
よろしれけばサポートよろしくお願いします！クリエイターとしての活動に活用させていただきます！