バグは絶対悪なのか？〜情シス目線のプロジェクトマネージメントTips#16

世の中にプロジェクトマネジメントに関するコンテンツは非常にたくさんあるのですが、よく見てみるとどうしてもSIer目線のものが多いように思えます。SIer目線の場合だと、どうしても利害が一致しないせいか事業会社というか情報システム部門目線から見るとピンとこないものも多く、ちょっと腹落ちしないことが多くあります。
というわけで無いなら作ろうということで「情シス目線のプロジェクトマネジメント」なるものを書いてみようかと思い不定期だとは思いますがシリーズ的に書いていこうと思います。

今回のテーマは常に忌み嫌われる「バグ」のお話です。よく「バグゼロ」が目標にされますが、ビジネスに当てはめてみたら本当に絶対悪なのか？そのへんを書いてみようと思います。

情シスにとってバグゼロは正しい？

システム開発をしていると開発チームに向けて「バグゼロ」という目標が掲げられている事がよくあります。
そうでなくてもウォーターフォール開発のそれぞれのフェーズでバグがゼロであることを確認してから次に進むというゲート的なルールがあったりもします。

確かにバグはないに越したことはありません。ましてや受託開発をされている場合は納入する製品にバグがあっては会社の信用に関わりますし、後の改修費用は確実に利益を食いつぶしていきます。少なくともSIerの観点ではバグは絶対悪なのは間違いがないと思います。

しかしながら、これを自社内のシステムの場合はどうでしょうか？

バグをゼロにするために、ほかをどこまで犠牲にできるか？

バグをゼロにするためにはコストや時間がかかります。自社内システム・・・・情シスの観点で考えるとバグゼロは多くのものとバーターとなります。開発コストだったり、関係者の拘束期間だったり、開発期間や、リリースの時期だったり、タイミングだったり様々なものとバーターとなるわけです。

バグはいやだけどゼロを目指して良いのかは？？なのです。

バグ解決とリリースどっちを優先するか？

よく出くわすのはこういった場面です、

テストや移行準備も終了し、さぁリリースとなったときに偶然バグが発見された。

個なったときはリリースを延期してバグを解決するのか、バグありでリリースするのか？？という選択に迫られます。

この場合どうするかというと、たいていの場合は見つかったバグの影響がどこまであるのか？その発生時期がいつなのか？

・・・・このへんが判断基準になっていくと思います。

例えばリリース直後から大量に使用されるメインのエントリー画面だったならリリースを延期してでもバグを解決すべきであるし、バグがたまにしか使わないマスタメンテ画面だったり、発生するのが、たまにしか出会わない特定のパターンだけであった場合はリリースを優先して、ユーザーには注意喚起を促しながら、あとから見つかったバグを治すことになるでしょう。

つまりは価値基準はあくまでもビジネスの影響＝バグによって失われるビジネス価値となるのです。

それが小さいならバグよりもリリースが優先されるのです。

ビジネス価値の中でのバグの価値

システムの開発でいちばん大切なのはビジネスの価値を生み出すかどうかです。このへんはSIerとは明確に価値が違います。低コストで短納期で全くバグが無かったとしても、作られたシステムがビジネス的に価値を全く生み出さなかったとしたら、全く意味はないのです。

作る側の責任として・・・と思うかもしれないですが、残念ながらシステムは芸術品ではありません、史上に出される製品と同じように作る側の満足よりもビジネス的利益が優先されるべきなのはゆるぎません。

だからバグをなくすための活動も本来であるならばそのビジネス価値と比較しながら加減するのが正しいアプローチになるはずです。

バグがあったらすぐにサービスや製品の提供に大きな影響が出て、顧客が離反してしまうとであればまさにバグゼロを目指すべきであろうし、バックヤードの仕事が一時的に止まるだけであれば、それ相応程度の品質活動でいいわけなのです。

ビジネスの価値がそれほどない部分の品質・・・・そんなところに時間を使うくらいなら、もっと価値を生み出す機能を追加したり、さっさとリロースして速く価値を生み出す方がよっぽど良いのです。

その割り切りこそがマネジメントなわけです。闇雲にゼロを目指して隅々まで徹底的に対策を現場に求めるのはマネジメントとは呼べません。

これはプロジェクトマネジメントであってもそうあるべきだと思います。

バクゼロの功罪

バグゼロは現場の意識として目指すのはいいと思います。いつものメンバーで限られた時間とコストの中で目指すのはとっても良いことだと思います。

しかしマネジメントの階層でこれをやることは数々のマイナスを生み出すことを意識すべきだと思います。

バグゼロが究極の目標であるならば、コストも納期も青天井になってしまいます。そのうえ失敗の可能性のある「新しいもの」にはチャレンジしないほうが良いという思考に陥ってしまいます。新しいものにチャレンジしない組織風土で成功した企業は無いはずです。そのままではズルズルと交代してしまうのは確実です。

何かを極端に求めたら、何かを失うわけです。

ビジネスの視点でバランスを取ることが大事だと思います。

変わってきている価値の基準

そのへんが一番紫尾っそうな外部へのサービスや製品で考えてみます。

最近のソフトウケア製品、特にクラウドで提供されるものには実際にバグが存在します。でもその製品が供給停止や販売の停止になったりすることはめったにありません。しかもなかなか改修されないものまであります。まだまだ日本の企業の方が「作るものの責任」みたいな意識が強いようでこのあたりは海外のベンダーはよりシビアに割り切っているように思います。

たまに「海外ベンダーの品質に対する姿勢はけしからん」なんて言っている人を見かけますが、バグが放置されててもその製品は史上に採用され続けているわけです。そのバグの解消がビジネス価値が低いから後回しになっているだけなのです。

もちろん製品が自動車の自動運転技術を支える部分であるならば、当然バグゼロは絶対的なものです。当然自動運転においてバグが発生して交通事故が発生すれば社会的な信用の失墜は計り知れないものであるだろうし、ビジネスとして失うものも多いからです。

・・・・最近はそれよりも市場の開拓のほうが勝ちがあると感じている海外の企業や政府が多いようですが・・・・

システム開発もビジネス活動

まとめてみます。

社内システムの開発もあくまでビジネス活動のひとつでしかありません。それは顧客に価値を提供して自社のサービスや製品を買ってもらうことであり、持続的にそこから収益を上げるためにやっていることの一環なのです。

だからどんなことでも思考停止に陥らず、ちゃんとビシネス価値への影響を考えながらバランスをとれるようにマネジメントしていくことが大事なのです。「バグゼロ」も思考停止にならずにちゃんと判断していくことが大事だと思います。