問題の真の原因は何？
課題の前の問題掘り下げ
課題を明確にする前に、問題の本質を明確にしないと、解決策を間違えてしまうことがあります。
次の設計ミスについての話は、よくある話です。自分もした、された若い経験ですが、これをもとに話を進めていきます。
設計ミス
ソフトウェアやハードウェアの設計にミス（不具合）が発生した場合に、プロジェクトマネージャー（以下、マネージャー）が以下のように問題の結果に視点を当てて質問や指摘をすると、問題解決が遠のいてしまいます。
設計の方法やプロセスを確認せずに、不具合の内容（問題）だけを聞く
レビューやセルフチェック、クロスチェックの実施状況を確認せずにその実施の有無を質問する
要求仕様書と設計仕様書や設計条件がクリアになっているかを確認せずに、その仕様書の有無、条件を守ったかいなかを質問する
担当者がこのような質問を受けると、「○○をしていませんでした」と答えるしかありません。
さらにマネージャーから「なぜ○○をしなかったのか」と質問が飛んでくると、しなかったことへのなぜなぜ分析に陥ってしまいます。レビュー会議を開催する余裕がなかったから、設計仕様書を作成する時間がなかったから。スケジュールにレビュー日が書いてなかったから、レビューで指摘されたことを修正する工数を見積もっていなかったから。。
プロセス（インプットとアウトプット、その間の作成、加工の方法、手順）が確立していない状態で、納期が迫って毎日遅くまで残業して設計している状況では、レビューや確認時間がとれず、このようにしか答えようがありません。
これは、多くの場合、プロセスを重視しない組織で発生している問題です。設計仕様書を書く時間、レビューする時間、レビュー指摘事項を修正する時間。これらは、スケジュール表に掲載されているでしょうか。
マネージャーは、上のように質問するのではなく、プロセスの有無、プロセスの入力と出力、付随する方法の遵守を確認する必要があります。もちろん、設計前にこれらのことを担当者に教育し、そして担当者にその作業をさせるべきです。
プロセスのない組織
もし、結果だけを見て、その結果がもたされた原因を明確にしないのはまずいです。原因をエンジニア個人のせいにしてしまいます。上のような質問しかできない上司が多い企業はプロセスを軽視していると思います。
筆者が以前働いていたベンチャー企業はプロセスがありませんでした。入力とその設計方法も明確にせず、納期を守るため休日返上でハードウエア基板の設計していました。そのため、実装後に動作せず、不具合だらけでした。
かつて勤務していた大企業はISO 9000を取得していましたが、プロセスを重視していませんでした。ISO内部監査前に資料の有無を確認、資料がない場合は後付けで作成するだけで、形式的なエビデンス作りをしていました（これは１度、２度ではなく、習慣になっていました）。マネージャーはプロセスではなく、作業終了後に行われるレビューがあること、そのレビュー記録の日付、アクションがないことのみを確認していました。レビュー議事録すら残っていない。今考えると大問題ですね。
レビューはやればよいのではありません。多くの人はレビューの目的を勘違いしています。レビューは検証であり、仕様または要求に対して成果物が作成されているかを確認することです。そしてその検証でみつけた誤りを修正する、またはさせるのが目的です。
プロセスの重要さ
不具合（問題といってもいいかもしれません）の発生を未然に防止するには、組織全体でプロセスを重視する必要があります。
マネージャーは、問題解決のためにはまず問題の本質を把握し、問題に対して適切な質問をする必要があることを理解する必要があります。プロセスの確認です。たとえば、入力が明確になっている（記載されている）か、方法と手順が明確か。出力が明確かです。設計書の有無ではありません。
マネージャーは、プロセスを理解し、レビューやチェック体制を整備し、それを実行される必要があります。
設計者は、レビュー議事録など、エビデンスを残す習慣を身につける必要があります。そして、アクションとなったことを必ず実施します。マネージャーは、アクションが実施されたことをエビデンスを見て必ず確認します。
タートル図
プロセスを見える化するには、ISO 9001またはIATA 16949規格のタートル図を描くとよいです。タートルズは以下の6つの要素で構成されています。例を示します。
インプット：プロセスに入るもの。
アウトプット：プロセスから出るもの。
人：プロセスを実行する人。
装置：プロセスで使用される装置。
方法：プロセスを実行する方法。
評価：プロセスの結果を測定する方法。
タートル図は、これらの要素を亀の甲羅のように6つの角に配置して表します。
おわりに
問題の本質を掘り下げるためには、適切なプロセスを構築する必要があります。そのプロセスから真の問題を明らかにすることが可能になります。これは設計に限らず、多くの物作りで同じことが言えます。
この記事が気に入ったらサポートをしてみませんか？