議題

現場にコンサルタントやプロジェクトマネージャーとして入っているのですが、開発ベンダーの多くが、同じような問題を繰り返し起こしています。

なぜ、同じ問題が再発してしまうのでしょうか？

原因

多くの場合、問題が再発する最大の理由は、「原因を正しく見ていない」ためです。

障害報告として上がってきた内容を見てみてください。

原因の項目に、

「何が、いつ、どのように起きて、その結果、何が発生した」

と記載されているケースが非常に多くあります。

しかし、これは原因ではありません。

単に「起きた事象」を詳しく書いているだけです。

この内容を原因として扱ってしまうと、対策も「今回起きたことを二度と起こさないための修正」にとどまります。

その結果、大元の仕組みや体制は改善されず、同じ種類の問題が形を変えて何度も繰り返される、ということが起きます。

対策

まずは単純に、

「原因には、『誰が、何をしなかったために起きたのか』を書いてください」

と伝えます。

しかし、残念ながら、これを正しく書けるベンダー担当者は多くありません。

なぜでしょうか。

その背景には、「自分たちの責任を認めたくない」「責任を負いたくない」という心理が働くからです。

その意識が強ければ強いほど、原因を曖昧にした表現になり、正しい報告ができなくなります。

そして、原因が曖昧なままである限り、本質的な改善も進みません。

恒久対応

まず、日本語として「事象」と「原因」を正しく区別できているかを確認します。

そのうえで、起きた問題について正直に言語化し、自らの責任範囲として受け止め、改善につなげることを伝えます。

これが、実は最も早い改善方法です。

サービスに真摯に向き合っている開発ベンダーは、不具合を起こした際にも、それを自分たちの責任範囲として受け止めます。

そして、

「チーム内のどの役割の人が、何を、どのタイミングで、どのように行えば未然に防げたのか」

まで落とし込み、再発を防ぐ体制を作ります。

一方で、こうした改善は簡単には進みません。

だからこそ、そこに我々コンサルタントやプロジェクトマネージャーの活躍の場があるのだと思います。

AIの総括

問題が再発する組織では、「何が起きたか」は詳しく説明できても、「なぜ起きたのか」を正しく説明できていないケースが少なくありません。

事象の説明と原因の特定は、似ているようでまったく別のものです。

本当の原因とは、単に発生経緯を書くことではなく、

「どの役割で、どの確認・判断・行動が不足していたのか」

まで掘り下げて初めて見えてきます。

ここが曖昧なままだと、対策も表面的になります。

今回の不具合だけを修正しても、根本の仕組みや責任分担が変わっていなければ、別の形で同じ問題が再発します。

重要なのは、誰かを責めることではありません。

責任の所在を明確にし、次回から同じことを起こさないための役割と仕組みに変えることです。

また、原因を書けない理由は、技術力不足だけではありません。

「自分たちの責任だと認めたくない」という心理が、原因分析を曖昧にすることもあります。

だからこそ、障害報告で最も重要なのは、きれいな説明ではなく、正直さです。

事象を書くのではなく、原因を書く。
原因を書くのではなく、改善できる原因を書く。

そこまで導くことが、コンサルタントやプロジェクトマネージャーの価値の一つだと考えます。

所感

AIに綺麗にまとめていただきましたが、初稿はもう少し棘のある内容でした。

こうした問題は、責任を負いたくないという心理が強いほど起きやすいように感じます。

逆に、自分たちの仕事にプライドを持って対応している開発ベンダーは、原因を曖昧にせず、最初から自らの責任範囲として整理できます。

これはある意味当然のことなのですが、一方で、実際にそれを自然にできるベンダーは決して多くありません。

だからこそ、問題が起きたときに「何が起きたか」ではなく、「なぜ起きたか」を正直に見られるかどうかが、そのベンダーの本当の実力や姿勢を表すのだと思います。

ベンダーにお悩みがございましたら、ご相談だけでもお受け付けすることはできますので、お気軽にお問い合わせください。