はじめに
現在入社6年目で、5年ほど品質管理をやっています。
品質管理業務をやっている中で、当たり前の徹底ほど重要なものはないと痛感しました。
その具体例3点について共有します。
特に新人開発者の人に読んでもらえると嬉しいです。
1.アップデートの社内フローを遵守する
弊社では、最低週に1度のアップデートを実施しています。
その中で「何曜日の何時までに何々の段階まで確認を終わらせてください」というものがあります。
この期日を開発部全体で守ってもらうことが、品質向上に繋がります。
なぜ期日厳守が重要か？
例えば、金曜日の19時までに「検証込みで開発完了」が期日だとします。
このとき、確認や修正が間に合わず「金曜の19時10分に完了しました。アップフロー載せてください」と依頼が来ることがあります。
時々、「19時も19時10分も、その10分間で品質が大きく変わるわけがないのだから、開発速度優先でどんどん通すべきではないか」と思う人がいます。
しかし、これは大きな間違いです。
割れ窓理論
割れ窓理論とは
1枚の割られた窓ガラスをそのままにしていると、さらに割られる窓ガラスが増え、いずれ街全体が荒廃してしまうという、アメリカの犯罪学者ジョージ・ケリング博士が提唱した理論
です。
これは品質管理にも当てはまります。
「10分が許されるなら、30分」「30分が許されるなら1時間」...のように、伸び伸びになってしまいます。
その開発物の品質が仮に良かった場合でも、その期日意識では次回以降の開発物で開発計画・テスト計画などの段取りが上手く行かず、後工程でのしわ寄せが起きる可能性が高いです。
また例外が認められた場合、人は「次回もこの手法で許される」と無意識に思ってしまう生き物です。
「今回の開発計画・テスト計画の何がマズかったか」と反省して改善してもらうためにも、安易に例外的に認めるのは避けるべきです。
(もちろん、やむを得ない事情があり柔軟に対応した方が良い場合もあります。ここで重要なのは「ルールが形骸化しないようにすべき」ということです)
2.開発チケットに、実装内容・確認内容を詳細に記載する
そもそもの話、業務で開発したものや記載したチケットの所有権は、原則会社に帰属します。
「私物ではなく会社のもの」という意識で、「将来的に自分以外の人がソースコードやチケットを読んだとき、理解できるか」という観点で取り組んでください。
特にIT業界では、同じ業務を数年後・数十年後も同じ人がやり続けることはほぼあり得ません。
今やってることが数年後の後任者が見てわかるか、という"思いやり"で整備しましょう。
(緊急対応などで忙しければ後日対応でもよいですが、リマインダーなどを掛けて後でやるのを忘れないようにしましょう)
3.開発チケットを期日切れにしたままにしない
チケットは基本、期日切れにならないように管理してください。
期日切れのタスクがあると「やらなきゃいけないと分かっているが、今はできない」という状態になります。これが重なると期日切れのタスクに対する警戒レベルが麻痺し、重大なタスクの漏れがあったときに気づけなくなります。
ハインリッヒの法則で言及されているように、重大なやらかしは確率の問題なので、いつかくる「しまった」のリスクを減らしていきましょう。
「ハインリッヒの法則」とは、労働災害の分野でよく知られている、事故の発生についての経験則。 1件の重大事故の背後には、重大事故に至らなかった29件の軽微な事故が隠れており、さらにその背後には事故寸前だった300件の異常、いわゆるヒヤリハット（ヒヤリとしたりハッとしたりする危険な状態）が隠れているというもの。
たまに「自分の頭の中や別のシートで完璧に管理しており、現状タスク漏れは起きていない。全く困っていない」という人もいるかもしれません。
ただ2で述べたように、そのタスクを一生ずっとその人がやるはずがありません。諸事情で突然引継がれた場合、後任者は「どれが実際大丈夫な案件で、どれが期日切れしている案件なのか」が分からなくなり、問題が発生します。
終わりに
品質管理では「他者にどれだけ当たり前のことを当たり前にやってもらうか」というのも重要なファクターだと思います。
障害の中には、日頃から当たり前を徹底していれば防げた、というものが多くあります。
人数が多くなっても、これらの当たり前が当たり前に守られるようにしていきましょう。