品質の重要性を知る者にとっては

当前で、最低限で、自己防衛するためでもある
作業品質を保証するための取組み

と言うものがあると思います。
言葉にしなくても、なんとなく自分の仕事の質を一定に保っている人は、常にどこかしら気を配っているものです。「何も問題が起きないように」＆「何か問題が起きても自身に過失が起きないように」スマートに取り組んでいるものです。

問題とは、不良そのものや欠陥を指すのではない

不良や欠陥、およびそれらを生み出す「失敗」は、人間が実施する以上必ず潜んでいます。そのことが当前であるからこそ、それを発見するために、レビューやチェック、テスト、監査、審査と言ったプロセスが用意されているのです。

もし存在しない仕事があれば、それはおそらく"性善説"に則って仕事をしているのだと思います。ですが、大抵の仕事は、後々迷惑をかけないために、必ずと言っていいほど何かしらのチェック機構がはたらいているはずです。

ですから、発見すべき"タイミング"と"作業"は、まず間違いなく与えられていると考えてください。もし、その機会すらない様であれば、ウォーターフォルであっても、アジャイルであっても、おそらくそのプロジェクトは不良や欠陥が混入することを根絶することはできないでしょう。

しかし、それは"不良"や"欠陥"の話です。
問題とは似て非なるものです。

"問題"とは

発見すべき時に発見できず、
見逃してしまって次の作業に進んでしまう仕組み

この一点に絞られます。

まぁ本来の意味とは異なりますが、ソフトウェア開発に特化していえば、そうであると考えてください。しかしこれは、製品や技術的な品質ではなく、いわゆる『マネジメント品質』の問題です。

いつ発見するように作業するか？
どうやって発見するべきか？

など、計画時点でのアクティビティの定義や、方法・手法の明確化をあいまいにしたことが原因です。それ以外の技術的な不良や欠陥は、本来発生することこそが想定内・許容内のものであり、それらはこの時点では予期していた範囲、計画的な不良であり、欠陥であるため、"問題"とは言えません。

このことからもわかるように、プロジェクトのトラブルは"不良"や"欠陥"によって発生するのではなく、そうした不良や欠陥を見つけるべき時に見つけられるように作業の進め方が確立されておらず、当初予定していた計画・想定・スケジュールが崩れて、破たんするために発生するものを言います。

一般的には、コストでも品質でもなく、リスケ(再計画)すら間に合わないほどにスケジュールが破たんして初めて"トラブルプロジェクト"と呼ばれます。トラブルは、これから作業を行う前に、その作業に対し、

　「準備が過不足なく行われている(条件が揃っている)かどうか？」

に依存、影響します。当然、準備とは「計画」のことを指し、計画とは「リスクが一切顕在化しない状態まで「準備」され、予定調和の中で進められる段取りができていることを言います（まぁ、なかなかそこまでいかないので、残存リスクをどうコントロールするかが、マネージャーの腕の見せ所となるわけですが）。

問題が発生した際、対処・対策は必要

不良や欠陥は、クリティカルパスに影響の出ない範囲で優先度付けのし直しができますが、問題はその場で解決しないと次に進めません。進めても、よりひどい状況になるだけです。

問題…すなわち「不良を起こした真因」を解決しないと言うことは、再発可能性を摘み取らないと言うことです。これを属人的に「気を付けるように」と言ったところで、具体的に何をどう気を付ければいいかわかりませんし、気を付けたところで人間のすることですから完璧を期待できるわけでもありません。

"問題"は、いついかなる時でも、その場で解決し、再発する芽を摘み取るのが最善なのです。

不良や欠陥の発生時、それ以降の活動において改修品質を保証するために最低限行う対処は、原則として

・対処する箇所に影響を受ける部分を「できる限り早急に」
　　「可能な限り正確に」報告する。
・影響を受ける部分の課題も解決していることを証明する。
・発見すべきポイントがどこにあったのかを、理由も添えて明確にする。

の３点です。

ここで嘘や虚偽は不要です。

仮に人に言えないような恥ずかしい実装／成果物をしていても、正直で且つ詳細である方が後続の問題へと派生しにくくなるため、できるだけ正直な方がいいでしょう。

恥と思って抵抗したい気持ちが湧き出るかもしれませんが、ここで後続業務の再発防止に一役買うことで、大きな貢献となります（誰もそう評価してくれないかもしれませんが）。

不良や欠陥は発生すればするほど手戻りコストが増加します。

仮に、発生した不良の修正と簡単な動作確認に20分かかるとします。しかしそれだけで終わらず、類似の不良が混入していないか、他機能のチェックもするとしましょう。１機能確認するのに10分要するとして、10機能あれば100分必要になります。報告や納得してもらうための説明などにも時間を要するとなれば、１不良発見するたびに２～2.5時間消費することになります。もし、１件発覚時に正確に伝達し、再発防止ができれば、最大2.5時間の手戻りコストで済みます。しかし、上手くいかずに５件、10件と似たような問題が発生すれば、たった１種類の不良で数万から数十万のコストを無駄使いしてしまうことになります。

速やかな報告、正確な情報伝達、および再発防止への取り組みはそれだけで、年間数千万から億単位の利益価値を有します。

最短で解決し、最大の効果を得るためには、嘘偽りなく、虚飾のない事実情報以外は蛇足です。それでも冗長的な手続きを欲する人がいれば、それはただの自己満足に過ぎないのではないかと思います。

前提・全体をまず知る

不良や欠陥は、解決・解消だけすればよいものです。
もぐら叩きのように解決するだけで本来は問題ありません。

ただし、その対応で「問題が無い」「他の見直しの必要がない」と言い切れないケースが１つだけあります。それは

やるべき時に、やるべきことを、やらなかった

場合です。言い換えれば「当該工程以前に発見しておくべき不良、欠陥なのに、なぜか後工程で発見してしまった」と言うケースです。

これは、言い換えれば当該工程以前のどこかのチェック品質に穴があったと言うことです。そのチェック自体の信用が問われているわけです。ですから、その信用に疑いが生じた以上、もう一度それが「大丈夫」であることを再チェックしなければならなくなります。

これが、一般的にいう「類似見直し」です。

当該工程または当該工程以降で発見されるべき不良や欠陥が、発見されることについては、チェック機構が正しく機能していて、漏らさずに不良や欠陥を検知できている、と言うことなので、その証明ができているものについては、見直しの必要性は一切存在しません。

仮に１件の不良を発見しても、他のチェックリストも同じレベルで書かれていれば、そのままチェックを進めていけば必ずほかの類似不良も発見されます。

そのまま進めていても100%発見・改修できるにも関わらず、見直し調査を実施すると、スケジュール的にもコスト的にも負担をかけ、よりトラブルプロジェクトへの道に近づくだけとなってしまいます。

意味や意義の見いだせない類似見直しなど、ただの"自己満足"、ただの"社会悪"にしかなりません。

結果、上記の1～3さえ、リーダーないしマネージャーが情報として整理できていれば、プロジェクト運営において、冗長コストによる大きな支障は絶対に発生しません（もちろん、リーダーやマネージャー任せにしないで、自身の担当分の整理は各メンバーでもすべきではありますが）。

結局、検討すべきポイントはシンプルで、

　「やるべき時(工程)に、やるべきこと(作業、成果物)を、やる」

かどうかに帰結します。その実現のために重要なことは、常日頃からの各成果物間のリレーションの整理や、成果物自身のトレーサビリティの確保です。これが行単位、項目単位、説明単位で保証できていれば、成果物品質の大半は保証・証明できます。

地味でメンドクサイかもしれません。モチベーションが上がらないことだってあるでしょう。今までそんなことしなくてもうまくいった事例はあるかもしれません。

しかし、それが仕組みではなく、属人的であったならば、未来も発生しないまたはこれからもうまくいく保証には決してなりえません。結局のところ、アリになりたいか、キリギリスのままでいたいか、それだけのことなのだと思っています。