0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

【新卒研修】教えてくれそうで教えてくれないソフトウェア産業の常識(品質編)

Last updated at Posted at 2020-03-31

こんにちは、 @illypon です。
そんなテストで大丈夫か?

さて、教えてくれそうで教えてくれないソフトウェア産業の常識。
今回はモノづくりをする以上は避けては通れないソフトウェアの品質についてです。

品質が意味するものは人や状況によって異なるものであって、品質はこれという決まりはない

プロジェクトで最初にやることのひとつは、そのプロジェクトでいう品質とは何なのかを決めることです。
品質と一口に言ってもその概念にはいろいろあり、それらはソフトウェア品質特性として定義されています。

知って便利な品質特性

品質特性を使うと、自分たちが品質として呼びたかったものなんなのかが、網羅的にリストアップできます。
副特性は品質特性をさらに細分化したものですが、参考程度に見るだけでも大丈夫です。

ISO/IEC 9126 ソフトウェアの品質特性モデル

品質特性と実際の指標との紐づけ

品質特性ごとに実際のプロジェクトの活動で気を付けることをリストアップして明確にします。
プロジェクトを繰り返していくと、だいたいいつも同じようなことに気を付ければいいのだとわかるでしょう。
このときなるべく定性的、もしくは定量的に観測可能な指標を設置することを心がけてください。

品質特性にも限界はある

品質特性も万能ではありません。
品質特性は狭義の品質についてしかカバーできておらず、広義の品質の概念が抜けています。

会社である以上、広義の品質を意識する必要がある

私たちは信頼している人の口コミを強く信用する傾向にあります。
また、会社ではどうしても限られた予算の中で調達しなくてはならないこともありますし、
どうしてその製品・サービスを買うのかを上手に説明しなくてはならないシーンが多くあります。
その時にいわゆる品質として感じているものは狭義の品質ではなく、
もっと実感を持ちやすく身近なもの、広義の品質であるはずです。

たとえば以下のようなものです。

  • 口コミ、レビューの評価
  • シェアの高さ
  • 会社の信用
  • 保守体制の安心感(24時間365日のサポート、継続的にアップデートの提供があるなど)
  • 販路の広さ(手にいれやすい)
  • ライセンス形態の柔軟さ(小額からスタートできる)
  • 発売日の早さ(=使える時間が長い、オトク)
  • 純粋な価格の低さ(やたら安い必要はないが、予算規模に収まらないと検討対象にもならない)
  • 製品名・サービス名から受ける印象(生理的に受け入れられない)
  • (矛盾のように見えるが)狭義の品質は期待できないがとにかく安い、というのもひとつの広義の品質のよさとなりうる

製品・サービスにいったい何を求められているのか、常に考え続ける必要があるでしょう。

システムはすべてオーダーメイドなので、プロジェクト間で品質や生産性を定量的に比較できない

ソフトウェア産業の特性として、まったく同じものを二度作ることはないし、まったく同じメンバーで異なるプロジェクトを進めることもないため、プロジェクト間で品質や生産性を定量的に比較することに意味はありません。数字が独り歩きしないようにくれぐれも気を付けることです。

もちろんほかのプロジェクトから学ぶべき点は多くありますので、
よい取り組みや大きな失敗などは参考にしていきましょう。

品質はコストより重要ではない 品質第一主義の会社は必ずつぶれる

これは田口博士という人の有名な言葉ですが、会社で働く人にはしっかりと認識していてもらいたいです。
会社にとって一番大事なのはコストです。コストをコントロールしなければ会社はつぶれます。
一方で、品質が期待と乖離しすぎると顧客からの信用を失い、その場合も会社はつぶれます。

期待を裏切らない程度の品質を実現しつつ、コストをコントロールして利益を出す。
これが会社の基本です。

バグはすべて直さなくてはいけないわけではない

報告されたバグを片っ端からすべて直そうとすれば、おそらくあなたは物事の優先順位を見失って多くの時間を失い、あなたの任されたプロジェクトの作業は停滞するに違いありません。
大事なのは、このプロジェクトはどのような性質を持ったプロジェクトなのか、
そしてどのようなバグであれば直さなくてはならないのかを明確にしておくことです。
自分で判断できないならば、ベテランの人に作業の優先順位をつけてもらいましょう。

一方、バグを放置しすぎると、プロジェクトが進むにつれて直したいけど直せないという事態になることも多いです。
「このサービスでこんな不具合が起きたら大変なことになる」という想像をいつもするようにして、
残したくないようなバグははじめから作らないようにすることが大切です。

品質保証とは一定の品質を約束することにすぎない

品質保証という字面だけ見ると、とても品質のいいもののように勘違いをしがちです。
実際には製品・サービスごとに決めた何らかの品質を満たしていることを約束しているにすぎません。

身近な電化製品の例でいうと、保証書に保証期間1年と書かれていることがありますが、
あれは1年間は故障しないことを約束しているだけで、1年を1秒でも過ぎた瞬間に故障することを否定しないという意味です。

必要以上の品質を追求してもコストにしかなりません。
どういう品質のものを作りたいのかというのは、何を作りたいのかと同義です。

要求された品質を満たしていなければ、納期には間に合っていない

「品質を下げて納期に間に合わせる」ダメな現場にありがちな話ですが、
ちゃんと炊けてないお米をお客さんに食べさせるような行為です。
それを間に合ったとは言いません。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?