ソフトウェアの品質とは何か?組織的に品質を担保できる体制作りについて
ハコベルで品質保証のマネージャーをしている小林です。
今回は元々の自分の専門領域であるソフトウェアの品質について記載しようと思います。
対象読者
- ソフトウェアの品質に関心を持つ開発者やテスターの方
- ソフトウェアの品質に関する基礎知識や規格を学びたい方
- ハコベルのサービスや開発体制に興味のある方
そもそもソフトウェアってなに?
ソフトウェアでググると、以下のように定義されているようです。
コンピュータを動作させる命令の集まりであるコンピュータプログラムを組み合わせ、何らかの機能や目的を果たすようまとめたもの。
この文章だと具体性がないので結局どんなものなのかがイメージしづらいですが、要するにみなさんのPCやスマートフォンなどで動いているWindows、macOS、Android、iOSや、その中で動作しているChromeやEdge、ExcelやWord、LINEやゲームなどといったアプリケーション全般のことを指します。
もちろん、弊社が展開しているハコベル運送手配や配車管理、配車計画などもソフトウェアとして分類します。
ソフトウェアの品質とは?
ソフトウェア品質といえど、通常の品質保証とあまり大きな違いはありません。
品質そのものは国際規格(ISO9000)で定義されています。
対象に本来備わっている特性の集まりが,要求事項を満たす程度
(JIS Q 9000:2015)
これだけだと何を言っているのかよくわからないので、Wikipediaから引用してきた文章を載せます。
製品・サービス・組織・システムといったモノゴト(対象)は、それ自身に内在し永久不変の性質を様々もつ。例えばあるリンゴは固有の大きさ・糖度などを特性として有している。これらの集まりが明示的・暗黙的・義務的なニーズ・期待を満たす程度を品質という。
定義から明らかなように、品質は特性の強弱ではない。品質は特性と要求の一致度である。例えば甘いリンゴ、すなわち高い糖度特性をもつリンゴがあるとする。このとき「このリンゴは糖度特性が高いので品質が良い」とはならない。リンゴが甘味処への卸売を予定していれば「高い糖度特性は甘味処のニーズと一致するので、このリンゴは品質が良い」となるし、リンゴが観賞用であれば「糖度特性は見た目に影響せずサイズ特性も平凡で観賞にマッチしないので、このリンゴは品質が低い」となる。
後半のパートに記載のある、 「品質は特性と要求の一致度である」という部分はかなり重要でソフトウェアの品質においてもまったく同様です。
弊社のプロダクトを例に挙げると、
- SaaSとしての側面
- 車番表が確認できる、外部APIが利用できるなど
- マッチングプラットフォームとしての側面
- 案件が確認できる、配車依頼ができる、請求支払ができるなど
各々の顧客に対しての要求を1つのシステムの中で担保しなければなりません。
さらに、上記の機能的な要求以外にも、セキュリティに問題がないか、保守性が高いかといったような顧客が知り得ない部分も考慮する必要があります。
なぜ必要なのか?
品質が低下すると後述のような大きなリスクがあります。
これらの問題を起こさないようにするために事前に打てる手は必ず打っておかなければいけません。
そのために私のようなソフトウェアの品質に特化した職やポジションが存在します。
社会的な信用の低下
障害やトラブルが頻発すると、顧客からのイメージは悪くなってしまい、徐々に誰も利用しなくなっていきます。
悪評が広まれば、当然ながら既存顧客が減るだけではなく、新規開拓すら困難になります。
こうなってしまった場合は、どれだけ宣伝や人材にお金をかけても元のブランド価値を取り戻すことは非常に難しく、会社としての存続すら危ぶまれるような状態になります。
膨大な時間やコストをかけないと、負の連鎖から脱却できなくなってしまうのです。
時間とお金の損失
システムに障害や事故が発生することで対応に多くの人が巻き込まれます。
ビジネス的な側面だと、顧客へ謝罪に行ったり、障害が発生している旨を周知したり、お問合せに対応したり。
開発的な側面だと、修正に工数がかかったり、開発計画が狂ってしまったり、原因によってはシステムの保守ができなくなってしまうような場合もあります。
本来発生しないところに時間やお金がかかってしまうので、上述の社会的な信用の低下と相まって、より一層会社としてピンチを迎えてしまいます。
会社としてソフトウェア品質体制をどうすべきか?
私が現状注力しているタスクとしては、事業規模、開発規模の拡大を見込んで組織的に仕組みで品質をカバーできる体制づくりとなります。
ハコベルの事業はラクスル社の一事業部としてスタートした8年前頃から比べるとかなり規模が大きくなってきました。
これから先もより成長していくと思います。
ソフトウェアの品質体制についても、当初はPdMが本業の合間に担当していたところから、私が参画し、今ではQAエンジニアが5名在籍しています。
前述のようなリスクの回避、また、システム導入のボトルネックとならないように盤石な品質管理体制を固めていこうと思っています。
今までは個人の技量でなんとかしてきたという背景がありますが、今後を見据えた場合に個人規模でカバーできる範囲は限られてきます。
前述のようなリスクの回避、また、システム導入のボトルネックとならないように盤石な品質管理体制を固めていこうと思っています。
まとめ
ソフトウェアの品質とは、ソフトウェアが持つ特性と顧客の要求との一致度であり、品質が低下すると社会的な信用の低下や時間とお金の損失などのリスクが発生します。
そのため、ソフトウェアの品質に関する規格やガイドラインなどを参考にしながら、組織的に仕組みで品質をカバーできる体制を構築することが今後の事業展開においては重要です。
ハコベルでは、事業や開発の拡大に伴い、品質管理体制を強化しています。
一方で、現状は取り扱う領域がソフトウェア品質という不確定な部分が多いため、まだまだ定量化がうまくできておらず、客観的な指標となるようなものがあまりありません。
もし知見をお持ちの方や、ハコベルのソフトウェアの品質について興味がある方は、ぜひカジュアル面談でお話しましょう!
「物流の次を発明する」をミッションに物流のシェアリングプラットフォームを運営する、ハコベル株式会社 開発チームのテックブログです! 【エンジニア積極採用中】t.hacobell.com/blog/career
Discussion