原因の分析と、マネジメントの塩梅について【PM困りごとシリーズ】

ベンダから「◯◯という不具合が発生しています。」等の報告は、特に試験工程でよく聞かれる言葉だと思います。
事業側のPMとしては、「了解」で終わりではなく、バグの真因は何なのか？追求する姿勢が時に必要です。
※品質が安定している案件であれば、逐一追求するのはコスパが悪く、ベンダ側の負荷もかかるのでオススメしません。…が、炎上していたりバグが頻発している時こそ、こういった姿勢が事業側にも求められます。

リリース後のバグも含め、単に報告を聞いて終わりではなく、バグの原因を分析するようしましょう。

バグの分析とは？

順を追って紐解いていくことが肝要です。個人的にはフォームの離脱ポイントを分析するのに少し似ていると思います。

①どの工程で発生したバグだったか
試験工程で発覚したバグだったとして、「これまでの工程の"どこか"で"何か"がうまくいっていないので、バグが発生した」と考えるべきです。例えば
・開発工程で、ジュニアレベルの開発者が担当していた箇所だった
・設計工程で書き漏らしていた
・要件定義工程で記載されていなかった仕様である
なと、どの工程でヌケモレがあったのか、まず振り返りましょ

②なぜその工程でバグが混入したか？
開発者のレベルの問題なのか、設計工程で本来書くべき処理を書き漏らしていたのか、要件定義でどの観点がもれていたのか、いま一歩踏み込んで分析をしましょう。トヨタ式のようになぜを繰り返すことが大事です。
真因を特定することは、そのバグを根本から治療することはもちろん、他の潜在バグを洗い出すことにもつながります。

③真因に基づいた潜在バグの洗い出しについて
真因を特定したら、バグを修正するだけでなく、「真因により他にもバグが起きているのではないか？」という視点を必ず持ちましょう。
この眼を持つことで、バグに後追いで対処する回数を減らし、インシデント発生を未然に防ぐ可能性が高まります。

例えば、
・特定の開発者の品質に問題があるのであれば、他にその開発者が担当した箇所について、同様のバグが起きていると仮定し、ソースコードレビューをしたり早めに試験を実施する
・設計書の記載漏れであれば、類似処理で同じように記載漏れはないか？あるのであれば、潜在バグとなっていないか？
・要件定義漏れであれば、同じ理由で他に漏れている箇所はないか
など、「同じ真因で、他にも発生しうる潜在バグはないか」についてベンダと対話をしましょう。そうすることで、前掛かりにバグに対処することができ、品質向上につながります。

また、今後に向けた具体的な予防策も重要です。開発者のレベルによる問題であれば、その開発者のソースコードは、ベテランのメンバーがレビューするなど、さらなるバグを産まないための取り組みも、バグが頻発している時ほどベンダからヒアリングをすべきです。

事業側のPMの立場からすると、要件定義を除きバグへの対処はベンダに最終委ねられます。…が、リリース後バグが出た場合、検収した事業側のPMの責任になります。どんなにベンダを憎んでも、その事実は変わりません。品質が不安定な案件ほど、おせっかいやうっとおしいと思われても、運命共同体としてベンダに細かくヒアリングすることが重要だと私は思います。

本当にうっとおしいと言われないように

「うっとおしいと思われても」と先ほど言いましたが、実際マイクロマネジメントを求めると、ベンダ側のPM・ディレクタには負荷がかかり、「そんな細かく報告するのは無理です」という反発を食らう事態になりかねません。もし炎上している時にそういった話になると、余計にお互い疲弊してしまいます。。

そうならないよう、事前に「報告のアウトプットや報告頻度」などをベンダに伝えておくことが肝要ですう。
「週◯回の進捗報告を求めます。報告にはこういう要素を入れてください。バグの発生時には、△△△やXXXについて必ず報告してください」といった内容のすり合わせを、早いタイミングでベンダと握っておくことが重要です。
何なら、RFPに上記のようなマネジメント系のアウトプットイメージがあってよいと思います。ベンダ側もどういったレベルのマネジメント・ディレクションが求められているのか判断がつくので、双方有益な情報となるでしょう。いずれにせよ、炎上する前に、双方余裕があるうちに、マネジメント系のアウトプットについてすり合わせておきましょう。

最後に

以上、バグ分析と、マネジメント系アウトプットの事前すり合わせの重要性についてお話させていただきました。ここらへんは、実は事業側PMの腕の見せどころだったります。文中にも少し触れましたが、案件の特性に応じて、報告内容は調整するべきだからです。
案件の抱えるリスクが大きいほど、マイクロマネジメントが必要になりますが、品質が安定している案件の場合過剰なコミュニケーションは無駄なコストです。例えば、ベンダに知見のないシステムを1からインフラ～フロントエンドまで開発する場合、リスクが高いのでマイクロマネジメントを求めるべきですが、安定稼働している既存システムの改修の場合、ベンダも経験値をそれなりにたくわえているので、マイクロマネジメントは避けるべきです。判断がつかない場合、上司やいっそベンダに相談することも1つです。

この塩梅は難しい局面もあると思いますが、まさにテーラリングの一貫と言えるでしょう。