障害管理はこれで完璧（1/2）

ちょっと長すぎてへばってきたので、複数に分割したいと思います。

ソフトウェア開発においては「モノづくり」を実際にしている設計や実装の作業において品質を証明することはできません。品質を意識した設計や実装はできても、それ自体を証明することはそこではできません。

あくまで

　レビュー（設計工程のテスト）
　テスト

によって、作りこんだ作業や成果物の品質を検証し、保証します。裏を返せばレビューやテストをまともに実施していないプロジェクトというのは、何も品質を保証しないまま先に進もうとしているわけですね。

ですので「する／しない」で論じるならば「する」一択です。

「しない」という選択肢はありません。しないことには品質を保証することができないのですから。「しなくても大丈夫なんです」といくら声を大にしたところで何一つ証拠はありません。その人を信頼できたとしても、製品自体の品質を信用する根拠にはなりえないのです。

もし「しない」「できない」というプロジェクトであったり、プロジェクトマネージャーがいたらそのプロジェクトや人は一切信用しない方がいいのではないでしょうか。

基本的に、品質の保証は

　・レビューやテストの仕方（網羅性）
　・１件１件の指摘や不具合に対してしっかりと対策の手続きを行う

だけで品質を完璧にすることが可能です。

そんなレビューやテストですが、いくら「品質を保証するため」といえど具体的にどんな評価基準で、どんな内容の確認を、どんな手順で行うべきかで保証される品質というのは変わってきます。

その点については対象となる成果物次第でまったく変わってくるため一概にこうだということはできませんが、いずれ機会があったら説明していきたいと思います。

なかなか汎用的に説明できる情報というのは少ないのでnoteの場で説明しきれるかわかりませんが、個別気になったところから公開していこうと思います。

で。

今回は、そうしたレビューやテストの過程で、指摘や不具合を発見した時の対処方法、対策の進め方について説明していきます。少なくとも指摘や不具合一つひとつに対する「品質」の課題についてはこれが徹底されさえすれば不安や懸念はゼロにすることが可能となります。

しかも、今まで通りの一般的な障害対応に比べてコストは圧倒的に低下すると思います。なぜなら『無駄を徹底的に省く』から。ほんの少し管理の手続きを厳格化してエンジニアやマネージャー個々人の好き勝手にさせないだけで、圧倒的なパフォーマンスを出すことになるでしょう。

0.障害対策の前提条件

まず大前提をご説明しておきましょう。

このことを理解していなければまともな障害管理（=問題解決管理）は不可能です。これはソフトウェア開発に限った話ではなく「期待と異なる結果」となった場合の対策として幅広く行われていることです。

障害管理（=問題解決管理）には大きく４つの対策をもって初めて完了と呼べるものとなっています。ごく一部を実施しても完了とは呼べないということを知っておいてください。

①是正（=修正）
②影響範囲の見直し
③同質の類似問題の見直し
④再発防止

この４つです。多くのエンジニアは①または①＋②だけ実施すれば完了だと思い込んでいる人もいるかも知れません。通常業務においても多くの場合は同じでしょう。

①というのは目の前で起きている問題個所に対する修正です。

たとえるなら、ケガをして血が出ているなら、血が出ている個所を止血するような行為がこれにあたります。当たり前ですが、まずは問題個所をなんとかしなければなりませんよね。

②はその対処をすることによって派生する影響の確認です。

先の例で言えば血が出ているとして血さえ止まればどんな方法でもいいか？というとそんなことはありませんよね。たとえば頭から血が出ているとして、止血するのに頸動脈を完全に止めてしまえばいいかというとそんなことはありません（死にます）。ソフトウェアも同様です。修正するのは良いのですが、その修正によって他の個所に不具合が出ては困ります。修正することによる影響範囲を特定し、その修正で問題ないことを論理的に確認したうえで修正しなければなりません。

③は同じような問題が他に潜んでいないか確認することです。

これは「しなければならない」条件というものがあってなんでもかんでもやればいいというものではありませんが、「しなければならない」条件を満たした場合は必ず実施しなければなりません。その条件については後述しますが、そうしなければ同質の問題がそのまま放置されて次工程へ進んでしまったり、リリースされてしまったりするからです。

④はその名の通り、再発防止です。

これが一番おろそかにされていますね。だから同じような理由の問題原因が多発します。一番多く、一番問題となるのは「ケアレスミス」。多くの人は軽く考えがちですが、ケアレスミスというのは言い換えるなら

　「原因の特定が難しい軽微な不良」

という謎の問題です。ナメてかからないでください。結局、プロジェクト活動の仕組み自体に不備があるからこそ起きることが許容されているのですから、早々に対策が必要な問題なんです。

実施するのが人である以上、ミスは必ず発生するものですが、その多くは「仕組みが醸成しておらず、個々人の取り組みに依存しているから起きている」ものが殆どで、ルールや手順だったり、取り扱うドキュメントの様式がフリーすぎたりするためにミスが起きているにすぎません。しっかりと"ミスが起きにくい"環境を用意すれば間違いなくケアレスミスは減ります。

レビューで指摘を受けたり、テストで不具合が出たりすることをゼロにすることが難しいでしょう。

しかし、「難しい」ことと「減らさない」ことは同義ではありません。難しいからと減らす努力をしなくていい理由にすることはできないのです。ですからこの努力をしないで手戻りを発生させ、余計な費用をかけようというのはプロジェクトや部門、企業に対する背信行為と言っても過言ではありません。なによりそれらが見積りに含まれているのであれば顧客に対する裏切りと言っても差し支えがないでしょう。

仮にバグ１件の修正、影響範囲の特定、類似見直しにかかる工数を１人日だと仮定します。あるプロジェクトで100件発生すれば100人日（５人月）が非生産的な作業に取られます。１人月の原価を100万と仮定するならそれだけで500万の無駄遣いとなるわけですね。そしてそうなることを予測して、この500万分の予算も見積りに含まれていたりするわけです。

実際に100件のバグを発生させているなら顧客への裏切りともとれますし、仮にその予算を請求するにしても100件を50件にする努力ができれば純利益に還元できるはずなのにその努力を行わないのは、プロジェクトや部門、企業に対する背信というのも頷けるのではないでしょうか。

そう言った意味でも「再発防止」はmustな対策となります。

なにより、国際規格が定める多くのマネジメントシステムにおいて

　「是正」と「再発防止」

はワンセットで定義されていますからそれが国際的にも標準であるということがわかりますし、ＱＭＳなどを導入している企業であればそこに所属する従業者はその規格に準じて活動できていなければなりません。

問題解決にあたるにはこうした基礎的な理解が求められている点を踏まえたうえで対策するようにしましょう。