ミスを責めない組織 〜悪いのはおおむねシステムである〜
このエントリはiCARE Advent Calendar 2022の投稿です。
こんにちは。iCAREのデータアナリスト、若松です。
──「データアナリスト」として入社したものの、あまりアナライズしていないな……と思う今日この頃です。私がiCAREにJoinしてから３ヶ月ほど経ちますが、人がやる必要のない集計を自動化するべく粛々とPythonでコーディングしたり、DWHのプロトタイプみたいな小規模なDBを構築したり──。
分析をしているというより「分析に集中できる環境をつくる」仕事をしています。まぁ、データ分析チームもまだ立ち上げ段階なので、こういう仕事が多くなるのは当然だし、コードたくさん書けるからこれはこれでいいか、と納得しながら仕事しています。
さて。
今回は「ミスを責めない組織」というタイトルでひとつnoteをしたためてみます。
ミスを責めない組織
直らないバグ、終わらないテスト
あるソフトウェア開発プロジェクトに参画していたときのことです。
このプロジェクトでは、発注元の企業が要件を決めてベンダーにソフトウェア開発を委託していました。一般的な「外注」です。
私は発注元企業に所属しており、担当は納品されたソフトウェアの受入テストでした。ベンダーが開発したソフトウェアに、要件通りに機能が実装されていることや、それらの機能・性能が仕様を満たすこと──要するにバグがないこと──を確認するのが、私の役割です。
ここまででお察しの方もいるでしょう。
納品されたソフトウェアは非常にバグが多く、また基本機能でさえもまともに動作しない──という有様でした。
当初の私は、淡々と機能をテストし、見つかったバグの詳細を報告するスタイルで仕事をしていました。しばらくすると、バグが多いためテストを進められず手持ち無沙汰になったため、テストの条件を増やしバグの挙動を詳細に取得して、ベンダーに報告するようになりました。
ベンダーの担当者は私の情報を元にソフトウェアを修正して再度納品してくれましたが、残念ながらすぐに別のバグが見つかったり、あるいは修正したはずのバグが解消されていないこともありました。私はその度、テストの条件を明示して担当者へ報告を行います。
その担当者とは対面で打ち合わせをしたり、一緒にテストやデバッグもしましたが、真面目で誠実な人柄でした。自分が楽をするためにテストの一部を(合理的な理由なく)削除したり、修正が完了していないソフトを「直しました」と言って送りつけるような、不誠実なエンジニアではありませんでした。
にもかかわらず、ソフトウェアの品質が一向に上がらない。
──このプロジェクトにおいて、成果物のソフトウェアの品質が低かった原因は、ベンダー側で利用していたテスト環境が不適切だったことでした。開発対象のソフトウェアはいささか特殊なもので、テスト環境の構築には押さえるべきポイントがいくつかありました。しかし、それらのポイントを外していたために、本来検出できるはずのバグが検出できないままテストの工程が終了してしまった──。
テスト環境が不適切であるために、テスト環境に”だまされて”、バグが修正できたと信じ込まされてしまう。
そうして、納品先で見つかったバグは、正味数百個。それをほぼ一人の担当者で修正しなければならない──という過酷な状況にあった彼は、残念ながら、精神的な健康を損ない、休職を経て退職に至りました。
先ほど述べた通り、彼の人柄は誠実で真面目でした。こちらの要望やアドバイスも素直に受け入れてくれて、(成果物の質はともかく)一緒に仕事をしていて不快感はありませんでした。
ごくごく一部の例外を除けば、「人は怠惰ゆえにミスをするのではない」ということは、みなさんの経験に照らしても納得できることではないかと思います。さらにいえば、慎重に注意深く作業を行なってもミスは生じる。
真面目で誠実で勤勉な人が、丁寧に慎重に作業をしてもミスを犯してしまう。ならば、どうすればミスを防げるのでしょうか。
チェックリストをつくる
答えのひとつは「チェックリストをつくる」ことです。
どちらかといえば嫌われがちなチェックリストですが、本来は適切に設計・運用すれば、我々が仕事でミスをするのを防いでくれる、有用なツールです。
この「適切な設計・運用」については、書籍『あなたはなぜチェックリストを使わないのか？』(著:アトゥール・ガワンデ/訳:吉田竜/発行:株式会社晋遊舎)が詳しいです。年末年始にぜひ読んでほしい一冊です。
同著に記されている「良いチェックリストの条件」をいくつか抜粋しておきます。
・良いチェックリストは「いつチェックを行うか」、つまり一時停止点(ポーズポイント)がはっきり決められている
・良いチェックリストは「行動のち確認」か「読むのち行動」かがはっきり決められている。
・チェックリストは長すぎてはいけない。項目の数は五個から九個にしておくとよい。
同著にはこのほかにもさまざまなノウハウが記載されていますが、全体として「どうやってミスを防ぐか」「どうやって仕事の質を上げるか」の観点にフォーカスして書かれています。過去のトラウマを抉られることなく読み進められるので、個人的にはおすすめです。(書籍に登場する実例と同業種であれば耳が痛いかもしれませんが……)
「責められるべきはシステムである」
チェックリストをつくることはミスを防ぐ上で有用で、読者のみなさんにもぜひ実践してほしいことです。しかし、本記事の題名は「チェックリストのすすめ」ではなく「ミスを責めない組織」としました。
人はミスをします。怠惰や不誠実の結果ではなく、懸命さと誠実さ、丁寧さを以ってなお、人はミスをします。少なくとも仕事の一担当者レベルでは「サイコロを二個振って１のゾロ目が出たら、ミスイベント発生」のような、ほとんど偶発的な事故のように起こるものです。
ですから、ミスが起きたこと、ミスを起こしたことを責めたところで、物事は良くならない。
それよりは、ミスを防ぐ仕組み、ミスが起きた後に迅速に対処してマイナスの影響を最小限に止める仕組みをどうやって構築するべきか？に心を砕くべきです。
そういう意味では、ミスが起きたときに責められるべきは「ミスを防ぐことができない仕組み」、業務を回すためのシステムそのものです。ここにはチェックリストやマニュアルの類だけではなく、マネジメントも含まれます。
（毎月60時間残業せざるを得ない状態が半年も続けば普通ミスするでしょう？リソース調整や業務負荷軽減について暗黙でもルールはありますか？という話)
──私は冒頭部分で「『分析に集中できる環境をつくる』仕事をしている」と書きましたが、これがまさに”仕組みづくり”です。iCAREはベンチャーの例にもれず仕組みが未整備の領域が多いため、データ分析業務に関してもマニュアルや業務フロー、雛形類の整備やノウハウの言語化を行なっている真っ最中です。(これを読んだ求職者が入社する頃には落ち着いてるはず……多分……)
ミスを責めない組織づくり
とはいえ、仕組みをただ整備するだけでは「ミスを責めない組織」を作ることはできない、とも思っています。
「人は怠惰ゆえにミスをするのではない。仕事が複雑だからミスをする。」
「それゆえに、人の能力ではなく組織の仕組みを強化することでミスを防ぐべきである。」
こういった考えが組織のなかに(すなわち自分自身のなかに)深く浸透させる必要があるでしょう。そうでなければ、ミスをしたことに罪悪感を覚えて心が傷つく社員は減らないし、誰かを悪者にして吊し上げて解決した気分になる人々も存在しつづけるでしょう。
私自身は、仕組みをつくりながらこの考えを伝えている(evangelize)つもりですが、一方で自分も「誰かを悪者にして解決した気分になる」癖が抜けてはいないので、日々心を鍛えているところです。
──偉そうに語れるほどの人間でもないのですが、「ミスの責任はどこにあるのか」と捉え直すことで心が軽くなる人もいるはずだと思い、筆をとった次第です。今年の罪悪感は今年のうちにそそいでおきましょう。
最後に、書籍『あなたはなぜチェックリストを使わないのか？』のリンクを再掲しておきます。繰り返しですが、良い本なので年末年始のインプットにおすすめです。ぜひに。
iCAREでは一緒に働く方を募集しています。
カジュアル面談からでも歓迎です。是非下記リンクよりエントリーください！
https://herp.careers/v1/icare
会社紹介スライド
https://speakerdeck.com/icarerecruit1/icare-book-2021-dot-11