⚙️

品質とは何か

3 min read

対象者

一応バックエンドエンジニアを対象にしています。

品質とは何か

品質を、考えたことはありますか?
どこまでやれば、そしてどのようにすれば「高品質」と呼べるのか、答えられますか?

正直、今までの関わった現場、周りのエンジニアから得た情報を考えても品質というものをまともに評価している現場はほぼ存在しないのではと個人的には思っています。自分の中で「俺の最強の品質モデル」があればまだマシだと思っているのですが、ほとんどがヒューリスティックなアプローチでその場その場で「こうしたら品質高そう」と感覚的に高品質というものを、個人個人で考えて不明瞭のまま開発しているのだと思います。その判断基準をベースに開発されたものが、本当に「高品質である」と、人に自信を持って説明出来るのでしょうか。少なくとも自分には出来ません。では、何を持って「高品質である」と言えるのか。

それは、目的・ニーズによって変化します。

品質は目的・ニーズによって変わる

品質は「バグを起こさない」とか「拡張しやすい」等に限りません。確かにそれは品質に関係していることが殆どです。しかし、「目的にあった機能の追加」もサービスの品質に貢献します。「機能の追加」を例にすると分かりやすいのでそれを例えとして説明すると、書籍検索サービスがあり、「ユーザーに出来るだけ楽に欲しい書籍を手に入れることを可能にする」ということが我々の目的だとします。その場合は、「検索機能」を開発し提供することで「ニーズを満たず機能を追加した」ことになるので追加した分サービスとしての品質は上がります。しかし、ここで「超リアルタイムでニュースをトップに表示する機能」というあまり関係ない機能を入れた場合、ノイズになり逆にサービスとしての品質を下げることになります。こういうのも「品質」です。

これに関してはどちらかというとバックエンドエンジニアとしてのスコープからは外れるとは思います。では、バンクエンドエンジニアの「目的」は何かというと、「ユーザーが欲しいタイミングで、いつでも機能の利用が可能で、問題ないレスポンスの速さで使えること」になると思います。つまり、これを保証するように開発出来れば品質の高いシステムであるということができます。極論、確実に品質を担保できるような運用になって入ればテストコードもいりません(ただ、大体テストコードを入れなければ長期的に見て障害が多数発生するため入れたほうが信頼性高く、運用コスト安くなりますが)

しかし、冒頭で伝えた通り、毎回自分でなんとなくの品質を考えて開発をすると品質に抜けがあったり、品質に関する考えに個人差があったりするのでそれは問題です。では、どうしたら良いかというと、RASIS(ラシス)という信頼性を評価する概念を意識し開発すれば最低限の品質は担保できると考えています(本気で高品質なシステムを開発したいのであれば、日本工業規格JIS 25010:2013の「SQuaRE」というシステム及びソフトウェア品質モデルをベースに考えるべきだとは思いますが、ほとんどのWeb系開発でこれを適用させてしまうと些かコストがかかり過ぎてしまうので一旦気にしなくても良いです)

信頼性を評価する概念 ~ RASIS(ラシス)

Reliability: 信頼性
Availability: 可用性
Serviceability: 保守性
Integrity: 保全性
Security: 安全性

Reliability(信頼性)

故障せずに継続して稼働し続けられているか、ということです。信頼性をもし向上させたい場合は、指標として平均故障間隔(MTBF)を上げるように開発時に意識すれば良いと思います。可用性と似ていますが、こちらは障害の頻度が高くないかで評価している点で少し異なります。

Availability(可用性)

必要なタイミングでいつでも利用できる状態になっているか、ということです。稼働率を上げるように開発をすれば可用性が改善されます。信頼性とよく似ていますが「障害は頻繁に発生するが、すぐ復旧する」という場合には「信頼性は低く、しかしすぐ復旧するため稼働率は高いので可用性の高いシステム」ということになります。

Serviceability(保守性)

機能実装を行うとき、可読性高く、拡張性を意識し、責務を適切に分割し、ログは人間にとってわかりやすく、コメントは正確に必要最低限残しつつSOLID原則に従って等意識して皆さん開発されていると思います。これ、全て保守性を意識した開発になります。つまり、大体のバックエンドエンジニアは保守性に命を掛け過ぎています。

自分ですか、保守性大好きですが何か?(煽り)

(ちなみに、指標としては平均修復時間(MTTR)を用います。値が小さければ小さいほど復旧までに時間がかからないということで良い、ということになります)

Integrity(保全性)

バグがなくデータの完全性が保たれていることで保全性が確保されているということが出来ます。完全性とは「ある機能を使ってみたらバグが発生してデータが削除されてしまった」とか「データに不整合がある」などの問題がないことを指します。不整合が発生した時の対策として、バックアップを前もって取得しておきしっかり運用手順として問題が発生した際の復旧作業として組み込んでいれば保全性は確保できますが、現場では意外と無視されがちな印象です。

Security(安全性)

そのままの意味で、不正利用に対して保護されていることです。

品質は経済面との兼ね合い

品質は100%保証するべきかというと、実はそうでもないです。95%信頼性が担保されていればユーザー的には満足するという場合、ユーザーの満足は満たしているにも関わらずその5%を保証するために数千万円さらに開発にお金を掛ける必要があるということでは費用対効果がとても悪いです。エンジニアの皆さんであれば品質100%を保証することがいかに難しいことか理解しているかと思います。PMと相談しつつ、SLOを一つ一つ定義してそれに基づき開発していけば、金銭面を考慮しつつ、品質も問題ないレベルまでに持っていくことができると考えています。何より、定量的に品質評価が可能になります。出来れば、その上でDatadog等を使い、SLIが定義したSLOの範囲内に収まっているかを監視するようにすれば将来にわたり信頼性の高いシステムを安全に稼働させておき続けることができるのではないかと考えています(余談ですがDatadogはメトリクスとアラートが設定しやすくて最高です)

最後に

品質について語りました。今までふわっと品質を考えていた方はこの記事で「品質とは」について考えるキッカケになったのではないかと思っております。実際、個人的には「信頼性を考えるにRASISが考えやすい」という理由で今回紹介したのであって、他の品質評価の概念を用いても構いません。それこそ会社として「品質モデル」というものが既に定義されているのであれば、それを用いていただいて問題はありません。要は、開発をする際に「なんとなく」で品質を考えないで欲しい、ということです。

以上、個人的な意見ではありましたが、参考になれば幸いです。

関連

日本工業規格 | JIS 25010:2013 | システム及びソフトウェア製品の品質要求及び評価(SQuaRE)−システム及びソフトウェア品質モデルSystems and software engineering-Systems and software QualityRequirements and Evaluation (SQuaRE)-System and software quality models

Discussion

ログインするとコメントできます