プログラム不具の発生により、お客様の業務に支障を来たしたという経験はおありではないでしょうか。
こうした場面に遭遇した管理者の皆さん、担当者の皆さんはどのような行動をされたでしょうか。少し思い出してみてください。
（管理者の場合）
□ 本番でのトラブル調査メールが来て、調査中に業務に大きな影響があることが発覚したが、原因と対策が明確になってから連絡したが、お客の機嫌が非常に悪かった。
□ 不具合が発生したとき、そのプログラムの担当者をつい叱責してしまった
□ トラブルの原因がわかり、経緯・原因・応急対策・恒久対策などのまとめたトラブル文書を書くのに時間がかかってしまった。
□ トラブル報告にすぐ来るように言われたが、他の仕事があり、日程調整の結果報告に行ける日が遅くなってしまった。
□ 顧客に報告する恒久対策として「ダブルチェックによるトラブル防止」を謳ったが、「これって本当に対策」と思う
□ 顧客に報告した際に、不具合を生んだ開発者のプログラムを全件点検するように言われた（そんな工数はないのに・・・）
□ 顧客に報告した際に、「他にはないのか」と詰問され、言葉につまってしまった（または、勢いで「ありません」と言ってしまった）
□ 顧客に報告した際に、「もう二度とこのようなことはないように」ときつく言われ、つい「わかりました（無理だよと思いつつ）」

（担当者の場合）
□ 自分が担当したプログラムの不具合ゆえに責任は感じるが、どうしたら良かったのか思いつかない。
□ できれば人の作ったプログラムの改修はしたくないと思ったことがある。
□ 改修仕様を決める際に、上司や設計者に聞いた際にこの仕様でいいと了解をもらったはずなのに、「それは違う」と言われたが納得いかなかったことがある。
□ 改修仕様を決める際に、上司や設計者に聞いた際にこの仕様でいいと了解をもらったはずなのに、「それは違う」と言われ、自分の勘違いだった思ったことがある。
□ 自己責任を感じて落ち込んでいるところに、（イライラが顔に出ている）上司の叱責で、仕事が嫌になった（また、会社に行きたくなくなった）ことがある。
□ トラブル原因について上司から詰問されるのも嫌だが、トラブル対策を立てるのに、自分を除いて検討され、嫌な気分になったことがある。

こんな思いになることを防ぐための「品質の作り込み策」について考えてみました。

我々の仕事は人がやる仕事で、まったく同じプログラムを２回作ることはまずありません。多くの製造業のように繰り返し生産の仕事ではありません。基本的には製造業でいうところの個別受注方式（１個づくりの仕事）です。
作業手順書やチェックシートなどを作っても、「お蔭で品質が向上した」と感じた人は少ないのではないでしょうか。ナレッジ蓄積と称して課題やその対策などをシステムに蓄積する方法を実施している場合もあるが、検索して役になったと感じたことはあるでしょうか。
検索して役に立った経験はGoogle先生やWikipedia先生でしょうか。

製造業では「品質は工程で作り込め」といいます。できたものを検査で弾くのは品質保証の考え方です。
我々が実施するテストは品質保証の考え方に基づくもので「品質を作り込む」作業ではありません。「品質の作り込み」に相当するものは何でしょうか。皆さん、考えてみてください。

品質の作り込み作業として位置付けられるものは次のものではないかと考えます。
① 作業者の開発スキルを把握し、そのスキルに沿った作業指示
② 開発者がエビデンスなしに実施している「いわゆるデバッグ」
③ 開発中に実施するコードレビュー

しかし、この３つの作業のやり方事態に問題があるため品質が作り込めていないと考えます。
課題①：開発で必要なスキルが管理されていない（のではないか）。また、管理されていてもプロジェクトマネージャに知られていない。そもそも開発で必要なスキルには何があるかが把握できていない可能性すらあります。製造業では、仕事に就くためには、必ず機能トレーニングを実施し合格したものしか作業に就かせません。
課題②：デバックで使用するデータを開発者自ら準備する場合が多いのではないか。データ準備は設計者が行うことで開発者の勘違い防止になります。
課題③：コードレビューを実施しているものの、レビューアのレビュー能力が事前に評価されていないのではないか。結果、レビューアにより発見できたり、できなかったりしているのではないか。

緊急提言
その①：コンサルタント・設計者・開発者およびレビューアのスキル審査基準を（とりあえず簡易に）作成し、とにかく格付けをすることが必要だと考えます。また、スキルアップのための教育制度も整備しないとならないのではないでしょうか。
その②：テストデータはとにかく設計者が準備しよう。それば無理でもテスト計画書だけは作成しよう。
その③：３点レビューの薦め（担当者以外の３つの目でのレビュー）
・その機能の設計者の視点
・コードレビュー的な視点
・その機能を含む業務全般の視点

Follow me!