PHONE APPLI Engineer blog

エンジニアブログ

開発者が意識すべき品質とは、なんだろうか?

こんにちは、サーバサイドエンジニアをやっている小林です。今回は、開発時に意識すべき品質について書いていきたいと思います。品質についてまとめてみようとしたきっかけは、下記のような業務経験からでした。

  • 新規開発・既存機能修正の機能設計を考える際に要件を満たす構成図・内部設計を書くが、レビュー時に毎回似たような指摘をもらう

  • ソースコードを書く際、仕様を満たす以外に何を考慮すべきなのか、漠然としている

今までは、こういった指摘・疑問は、業務を通して蓄えていこうという「経験」ベースで行っていたのですが、

  • 経験していないことは考慮できない(経験したことでも、「このように言われたから」くらいの理解度・・・)

  • 経験していないことを知識で補おうとしたが、何から学習すれば良いのかわからず、学ぶ前に挫折・・・

など、経験から次の学びへ活用できない状態でした。ただ、「これらはどこかに繋がっているはず」と思い、整理・調査をしました。

その結果、「品質」、特に「ソフトウェア品質の非機能要件での品質」について知れば、今までの経験を理解して、活用できる状態にできるのではないかと思い、記事にしてみました。

品質とは?

最初に品質とは何か調べてみました。すると、代表的な定義が2つ見つかりました。

  • 品質とは、要求を満たすことである(『クオリティ・マネジメント』フィリップ・B・クロスビー)

  • 品質とは、誰かにとっての価値(『ワインバーグのシステム思考法』G.M.ワインバーグ

要求 = 仕様書通りに動くかどうか、価値 = 利用者の満足度と置き換えると、「仕様書通りに動くのはもちろん、利用者が満足できるかどうか」が「品質」であるのかなと考えられます。

そのため、下記のようなレベル分けができます。

  • 仕様書通りに動く・利用者の満足度が高い(高品質)

  • 仕様書通りに動く・利用者の満足度が低い(仕様通りに動くが、満足できない(使いづらいなど))

  • 仕様書通りに動かない・利用者の満足度が低い(低品質)

非機能要件での品質とは

利用者が必ずシステムに組み込んでほしい機能を「機能要件」といい、「機能要件」以外の全般を「非機能要件」と呼びます。この2つは、「要件定義」の段階で考えるものです。

非機能要件では「サクサク動く」「使いやすい」など、利用者の満足度に直結する部分であるため、これらを満たすことが「非機能要件の品質」となります。

しかし、「機能要件」以外の全般を考える必要があるため、範囲がとても広いです。そのため、非機能要件の内容を整理・ジャンル分けをしたフレームワークのようなものが存在します。

ISO 25010:2011(JIS X 25010:2013)

ISO 25010:2011は、ソフトウェアの品質を評価する国際規格です。日本版はJIS X 25010:2013です。主に、非機能要件をまとめる際の観点出しや品質の評価を行うためのテストケース作成をするときに利用されており、8つの品質特性に分かれています。

ISO 25010:2011

8つの品質特性について

それぞれの特徴について、品質特性の意味、自分なりの解釈、に整理して見ていきます。 品質特性の意味は、JISX25010:2013 システム及びソフトウェア製品の品質要求及び評価(SQuaRE)-システム及びソフトウェア品質モデルを引用します。

機能適合性

明示された状況下で使用するとき,明示的ニーズ及び暗黙のニーズを満足させる機能を,製品又はシステムが提供する度合い

  • ヒアリング不足などで、利用者が想定したものとは異なる機能を作っていないかどうか。例えば、仕様書通りに動くが、利用者の満足には繋がらなかった、というケース。

性能効率性

明記された状態(条件)で使用する資源の量に関係する性能の度合い

  • 応答速度、メモリ・CPUなどの利用率を抑えた設計など、限られた資源(ハードウェア)を有効活用しているのかどうか。

互換性

同じハードウェア環境又はソフトウェア環境を共有する間,製品,システム又は構成要素が他の製品,システム又は構成要素の情報を交換することができる度合い,及び/又はその要求された機能を実行することができる度合い

  • サポートする動作環境はどのくらいあるのか。例えば、サポートしないブラウザはあるかどうか、といったもの。

使用性

明示された利用状況において,有効性,効率性及び満足性をもって明示された目標を達成するために,明示された利用者が製品又はシステムを利用することができる度合い

  • 利用者がその機能を利用した時に使いやすいかどうか。例えば、操作がしやすい画面になっているかどうか、といったもの。

信頼性

明示された時間帯で,明示された条件下に,システム,製品又は構成要素が明示された機能を実行する度合い

  • 障害が発生しにくく、発生した場合はすぐに復旧ができるようなシステムであるかどうか。

セキュリティ

人間又は他の製品若しくはシステムが,認められた権限の種類及び水準に応じたデータアクセスの度合いをもてるように,製品又はシステムが情報及びデータを保護する度合い

  • 不正アクセス・利用や侵入されないようにしているのかどうか。

  • 情報セキュリティ三大要素も含まれそう。

保守性

意図した保守者によって,製品又はシステムが修正することができる有効性及び効率性の度合い

  • システムを運用する人が管理しやすいように整備されているか。

  • バグが出た際に素早く特定・修正できる体制になっているのかどうか。

移植性

一つのハードウェア,ソフトウェア又は他の運用環境若しくは利用環境からその他の環境に,システム,製品又は構成要素を移すことができる有効性及び効率性の度合い

  • システム移行などを行う際、今あるシステムを適用させることができるのか。

  • 移行させる場合はどのくらい時間と労力が掛かるのか。

開発時に意識すべきこと

すべての品質特定を満たすことがもっとも良いですが、時間と労力などのコスト面の制限がある以上、不可能だと思われるため、 プロジェクトや会社のポリシーによって、優先度が変わってくると思われます。

そこで、個人的に考慮すべきだと思う非機能要件の品質特性を挙げていきたいと思います。

※ 想定は、SaaS環境

新規開発・既存機能修正の要件定義を行う際に、特に考慮すべき品質特性は?

  • 機能適合性

    • 利用者が求める機能を作るために必要なことは何か
  • 性能効率性

    • 利用人数はどのくらいを想定しているか
    • 応答・処理時間などの制限はあるか
  • 信頼性

    • システムが壊れないようにするために必要なことは何か
  • 使用性

  • 互換性

    • 利用者はどんな環境を使うのか
    • システムは動作するのか
  • セキュリティ

    • データに対して権限のないアクセスなど悪意ある攻撃から保護するために必要なことは何か

仕様決定後、ソースコードを記載する際に意識すべき品質特性は?

  • 保守性

    • バグが発生した際、特定・修正を素早く行えるようなソースコードになっているか
    • 会社のコード規則などに則っているか
    • 他箇所・機能に影響は出ていないか
  • 性能効率性

    • CPUやメモリをムダに消費してしまうソースコードは書いていないか
  • セキュリティ

    • SQLインジェクションなどの攻撃を受けてもデータが漏洩しないか

    • データに対して権限のないアクセスが試みられた場合、閲覧できないようになっているか

  • 互換性

    • 外部ライブラリによって、利用者の環境で動作しないなど問題は起きないか

「仕様決定後、ソースコードを記載する際に意識すべき品質特性は?」の部分がすごく具体的になってしまいました。

まとめ

今回は、開発者目線から「品質」をテーマにまとめてみました。個人的には、記事を書くということを通して、体系的に整理できたかなと思っています。

要件定義や設計を行う際、どうしても機能要件を集中的にまとめてしまい、非機能要件は知らん顔していた部分もあったので、これから気にしていこうと思います。

ではでは


PHONE APPLIについて

phoneappli.net
phoneappli.net