システムの品質が悪いと言われないようにする方法を考える

はじめに

お疲れ様です。むぎです。

システム開発をやっていると、「品質が悪い」と言われることがよくあります。

むしろ、どんなに頑張っても「品質が良い」なんて言ってくれる人なんて微々たるものです。

（そもそも今まで作ったものが全部、品質が悪いせいかもしれませんけどね💦）

よくあるのが、

「本番障害でました」→「はい、品質悪い」

というパターン

ぼくはこれに納得がいかなくて、非常にもやもやしてました。

そもそも品質ってなんだっけ？

品質の定義は様々ですが、ISOの定義では、「本来、備わっている特性の集まりが、要求事項を満たす程度」と書かれてるそうです。

wiki引用https://ja.m.wikipedia.org/wiki/%E5%93%81%E8%B3%AA

システム開発における要求事項とは、要件定義を指すことになるんでしょうね。

だから、本番障害が出たことによって、ユーザの要件を満たしてなかったと判断された場合は、やはり品質が悪いとなってしまうのは、仕方ないですね。

支障が出る出ないも、結局は決め

ユーザに全く支障がでないようにする。サービスを途切れないように提供し続ける。

こういうのも結局は要求事項の中の一つでしかなくて、要件と、お金と、期限の落とし所を決めるものでしかないんですよね。

だから、
・全くサービスを停止してはならない。
という要求も存在すれば、

・一部の原因でサービスが停止することは致し方なし
という要求もあるわけです。

どこまで達成するかは、その時のプロジェクトによるというわけですね。

なので、支障が出たとしても、一概に「品質は悪い」とは言えないはずなんです。

それでも、本番障害はマイナス評価になる

ユーザーからしてみれば、サービスの利用にストレスを与えられれば、評価を下げたくなりますね。

それは至極当然。

ただ、よくあるのが、上司やPM、元請けからの「品質悪い」という評価。

どこまで達成すべきかというサービスレベルを、要件定義に記載してあっても、障害数によってプロジェクト全体を評価してしまうだけでなく、場合によってはエンジニアや協力会社を評価してしまうので、タチが悪い。

本当は、今回の予算や納期には収まらないとした範囲での障害であったかどうか。があるべきなんだろうな、と思います。

いつもマイナス評価になるのは、たぶんこの「収まらないとした範囲」が定義できてない（共通認識になっていない）のだと思います。

品質が悪いと言われない方法とは

じゃあ、品質が悪いと言われないようにするには、どうしたらいいのか？