第三者はそのトラブルを識別ために何を対象とするべきか

割と品質を求められるプロジェクトがシステム切り替えを終え、業務のサイクルが回り始めたある日、トラブルが起きたんですね。イメージ的には、業務データのトランザクションで「意図しない振る舞いをして特定の利用者が利用できない状態となった」と。

本番障害ですから、即、対応チームが編成され調査・復旧措置のアクティビティが実施されたわけですが、関心があるのはそのトラブルシュートではありません。

「第三者がトラブルの根っこになった真因が埋め込まれた一番最初の行程で識別することができるのだろうか」

です。本番障害ですから、普通の感覚なら原因分析をして原因が発生したプロセスの改善を再発防止策として策定し、実行するのが定石なわけです。

でも、このサイクルでは未来永劫「事後対処」しかできないということでもありますよね。いつもトラブルを起こして謝罪のレターを出して、再発防止策という名の効果が不確かな作業を追加する作業を繰り返す。

もちろん、一番良い再発防止策は、普段から書いているようにトラブルを生むような作業プロセスを作らないことです。だけれども、プロジェクトの特性上、「プロジェクトが変われば全てのリソースがなんらか変わるのでプロジェクトでの作業プロセスはプロジェクトマネージャの経験でリセットされてしまう」ことを避けられないのです。

これが正しいとしたら、進化はすれど変わらないプロセスとモニタリングをする第三者がウォークスルーするほかないのではないか、という仮説を立てたわけです。で、できるのかな。

トラブルの原因は（上位工程などの）前プロセスで仕込まれている
本番障害ですから設計・製造・テスト工程は全部前工程なのは当たり前ですね。総合テストだとしたら、結合テストより以前、となりますね。

どっちのケースにしても、トラブルが起きた工程ではなく、設計・製造・テスト工程で仕込まれていたとすると、そのトラブルの起因となった工程でトラブルの原因を識別したいのです。

第三者は何を検査できるか
インプット、アウトプット、作業プロセス。概念的はIPOですよね。ただ、その対象物の中身までを理解するまで知ることは第三者の立ち位置を確保するためには必要のないことです。だって、それではプロジェクトメンバと同じになってしまうから。

インプットでは何を検査できるか
インプットは、品目、品目ごとの品質の状態が知ることができます。レビュー記録が残されていれば。

作業プロセスでは何を検査できるか
作業プロセスは、作業プロセスの定義を知ることでインプットとアウトプットから検査することはできそう。でもアウトプットの仕様（品質）が決まっていることが必要。アウトプットの品質要求で作業プロセスは影響を受けるから。

アウトプットでは何を検査できるか
アウトプットは、次工程のインプットになるわけで、作業プロセスの一段上の工程レベルでの定義で要求する品質で特性が決定されてしまう。

結局アウトプットで要求される品質が確保できているかどうかを見る他なさそう。ただ、アウトプットは最終形態なんですよ。要件定義書、基本設計書…全部が中間生産物の取りまとめたものでしかない。

アウトプットももちろん、レビュー記録がないと健康状態が判別できないからそうしたメトリクスも必要。

中間生産物が一番やばい
契約で完成責任を負う成果物だけではシステムは動かないのは周知の事実だから、それ以外の中間生産物をどうするか、というところか。

これは工程ごとに直前で決めたり、工程中に追加することが多いのではないかと思うのです。つまり、作業プロセスを設計するときには必要と決めていなかったり、後付けで足したり。

作業プロセスを設計するときに考慮されているならアウトプットとしての前後のつながりも思慮されているハズ。後付けのときはそこまで配慮されないから作業プロセスとの整合性やアウトプット間の一貫性なんて何もないのではないか。

そうだとすると、インプット、作業プロセス、アウトプットのそれぞれの対象物やプロセスの必然性？とそれぞれのオブジェクトに求められる品質状態を客観的に見ることが必要なわけですが。

これでは対象物の特定までだ。ただ、これまでの契約で求められる成果物に限定していないところが新しいか。