仕事の質を講じる前に

そもそも「問題」と言うものについてあらかじめ知って、考えて、定義しておくべき要素が３つあると思っています。

業界や企業、あるいはチームや組織、プロジェクト特性などによって色々条件は異なるでしょうが「やらなきゃいけない」という１点においては、みな同じだと思います。

たとえばソフトウェア開発の現場では次のようになるでしょうか。

「問題」とはバグや失敗そのものを指す言葉ではない

バグや失敗は人間が実施する以上、必ず潜んでいます。

だからこそ人の行動に制限を設けず自由が過ぎると、それに比例してバグや失敗を作りこんでしまうわけです。裏を返せば、制限…つまり「ルールや手順、基準」などの"仕組み"を必要最低限（必要十分＋効率を妨げない最低規模）設けることが重要になってきます。

このことが当前であるからこそ、バグや失敗を発見するために、ソフトウェア開発の世界ではレビューやテストが仕組みとして設けられているのです。

ゆえに発見すべき工程と作業は、必ずそこに与えられています。

よって、それでもバグや失敗として検知され、認識されるものとは、現時点で定義されている仕組みのままでは

「発見すべき時に発見できず
　見逃してしまって次の工程（作業）に進んでしまう」

ようになっていることこそが問題であり、また問題はこの一点に絞られます。バグや失敗は問題ではありません。問題が解決されていないが故の結果であり、ただの事象です。仕組みが不十分で、発生すべくしてしたわけですから、バグや失敗そのものは「問題」とは言いません。

ゆえに、プロジェクトの"炎上トラブル"はバグや失敗そのものによって発生するのではなく、

仕組みを十分に構築せず（できず）、
その結果、計画を阻害する要因を見つけるべき時に見つけられず、
当初予定していた計画・想定・スケジュールが崩れて破たんした状況

のことを指すのです。一般的にはコストでも品質でもなく、スケジュールが破たんして初めて"炎上トラブル"と呼ばれるのはそのためです。トラブルは必ず起こるものではありませんが、その発生確率はこれから作業を行う前に

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

に強く依存・比例することを忘れないようにしましょう。

「問題」は解決しないまま進んではならない

さて、「問題」の定義を理解できたとおもいます。
ですが、それだけでは次に進むことはできません。

次に進むためには「後顧の憂いを断つ」…すなわち、問題そのものを解決しなければなりません。仮にバグや失敗をリカバリできたとしても、問題そのものが解決していなければ、すぐに同じような事象が再発します。

バグや失敗の発生時、それ以降の改修品質を保証するために最低限行うべき対処は

①対処する箇所および、対処によって影響を受ける箇所を特定／是正する。
②「できる限り早急に」「可能な限り具体的に」報告する。
③影響を受ける部分の課題も解決していることを証明する。
④発見すべき工程がどこにあったのかを、理由も添えて明確にする。
⑤発見すべき工程＝発見した工程の場合
　　└ チェック機構が正しく機能していれば、特に問題なし
　発見すべき工程＞発見した工程（フライング気味に発見した）
　　└ 特に問題なし（発見すべきタイミングでのチェック観点に追加する）
　発見すべき工程＜発見した工程（当該工程以前に抜け漏れがあった）
　　└ 過去に手戻って、抜け漏れた部分を再チェックしなおす。

の流れを実施します。この報告で嘘や虚偽は一切不要です。

仮に人に言えないような恥ずかしいプログラム実装をしていても、行動をしていたとしても、"正直"である方が何かと問題が派生しにくくするため、できるだけ正直な方がいいでしょう。

品質管理上、「何故バグや失敗が出たか？」などの動機的理由を求められることがありますし、実際分析のためにはおいおい必要となってくることではありますが、それは目の前で起こっている問題を解決した後でもかまいません。品質を維持しつつ最短で進めるためには、上記の流れ以外は蛇足となります。

それでも欲する人がいれば、それはただの自己満足に過ぎません。

「問題」の本質を見極めてから行動する

バグや失敗と言った事象そのものは、是正すればよいだけです。

しかしそれで「禍根が残っていない」「他に見直しの必要がない」と言い切れないケースが１つだけあります。それは

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

場合です。先ほどの例で言うならば『発見すべき工程＜発見した工程』のケースです。

やるべき時に、やるべきことがちゃんとできていると証明できているものについては見直しの必要性は一切存在しません。なぜならどんなバグや失敗であろうとも、レビューやテストは"そうあること"が前提で組み込まれた工程であり、その発見こそが目的となるからです。

先ほどの例で言えば『発見すべき工程＝発見した工程』の場合、もぐら叩きのように解決するだけで本来はなにも問題にはならないわけです。要は、計画通り、狙い通りに検知できているわけですから納品時にすべてが解決していればいいだけです。

先ほどの①～⑤の内容を管理情報として収集、整理、コントロールできていれば、プロジェクト運営において冗長コストによる大きな支障は絶対に発生しません（もちろん各担当でも整理はすべきですが）。

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

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

かどうかだけです。そのために重要なのは、常日頃からの各インプット⇔アウトプットのトレーサビリティの確保です。

これが成果物単位、ページ単位、行単位、項目単位、etc.…で保証できていれば、品質のほぼすべては保証・証明できます。

メンドクサイかもしれない。
今までそんなことしなくてもうまくいった事例はあるかもしれない。
（だがそれはこれからもうまくいく保証にはなりえない）

結局のところアリがいいか、キリギリスがいいか（最初に未来を見据えてほんの少しの苦労を受け入れるか、後になって後悔とともにふくれあがった膨大な苦労に押し潰されるか）それだけのことです。

しかし、この問題でもなんでもないケースであっても、わざわざ問題を生み出し、埋め込みたがるマネージャーやリーダーは多いものです。

何も問題がない『発見すべき工程＝発見した工程』の場合でも、思考停止をおこない、とにかく類似バグや失敗を総出で探させて、修正させ、スケージュールに負荷を与え、コストに打撃を加え、そして人的リソースに疲労を強いる…という愚を犯します。

仮に１件のバグを発見しても、『発見すべき工程＝発見した工程』の場合はチェックリストが同じレベルで書かれていれば、他のテストやチェックも必ず発見されることになります。

そのまま進めていても100%発見／改修できるのに、わざわざ潜在的な同類バグの見直し調査を実施すると、スケジュール的にもコスト的にも負担をかけ、よりトラブルへの道に近づくだけです。バグの件数としては「１件」でサマリされて対外的な心証は良くなるかもしれませんが、そんなどーでもいい目的以外には何の効果もなく、プロジェクト進行やプロダクト品質に対しては何の価値ももたらしません。

意味や意義の見いだせない類似見直しなど、ただの社会悪にしかならないのです。こういったことは、リーダーやマネージャー自身が

　「問題とはなにか？」
　「なにをすれば問題が解決するのか？」

と言ったことをあらかじめ定義できておらず迷走している…状態もさることながら、

　「どのような状況で各メンバーが作業を進めている状態が理想なのか？」

を具体的に言語化できない、あるいは言語化はできるとしても（キックオフなどで）公言していないために、仕組みの中に取り込まれていないことが原因ではないでしょうか。

最初に「目的」や「目標」として絶対的な指針にしておけば（そして、日頃からその姿勢を徹底していれば）、それを前提としたルールや基準、手順に自然と歩み寄っていくものです。

最後に

もしも医療や食品など、他のサービス業界ではどうなのでしょう。

やりたいか／やりたくないか（気分優先）
好きか／嫌いか（感情優先）

というのは個人のモチベーションに直結しますし、モチベーションは仕事のパフォーマンスや質に影響を与えるかも知れません（プロ意識が低ければ）。では、そんな気分や感情で行われた仕事に、消費者の目線で改めて立ってみた時、信頼がおけるのでしょうか？

あるいは

必要だと思うのか／必要だと思わないのか（根拠不明瞭）
前回はそれでいけたのか／いけなかったのか（根拠不十分）

といった主観／客観の目線で、客観的見解を持たず、客観的証明もできずに製品やサービスを提供され、対価を求められても、みなさんは客側の立場なら許せますか？

同じように、数百万、数千万という大金をかき集めてＩＴ投資するお客様に、そういう態度であなたは誠実な人間だと言えますか？

ＩＴも社会インフラに強く根差すものが多いため、時には人の命を、時には人の財産を大きく損なう可能性だって出ることは多々あります。そうでなくとも、人の人生に大きく左右するものが多いはずです。

ＩＴもサービス業の１つである以上、サービス産業における作業品質（プロセス品質）を保証するための取組みは、まずこうした観点／考え方をもって出発することから始まるべきなのではないでしょうか。