【前編】DX時代のIT品質とは？　-価値に目を向ける-

昨今のニュース等でITシステム障害が話題になることが多くなりました。ITシステムの「品質」というと、不具合（バグ）の有無を連想することが多いのではないでしょうか。IT企業の品質管理担当の仕事も同様で、「出荷前に不具合を残さない」ことに専念している様に思えます。

しかし、「品質」とはそもそもそういうことなのでしょうか。DX（デジタル変革）を目指す中でのITシステムの力によって、達成したいことが実現できるかどうかが、本来の品質のはずです。ITシステムの品質を考えることを通して、DXで何を実現したいのかを考え直すきっかけにもなるのではと思います。

ITシステムの「品質」にいだくイメージ

近年、検査結果の改ざんなどの品質不正が数多く報道されています。検査不正はもはや日本の「お家芸だ」とすら書かれました。また、金融・通信・運輸など社会的に重要なITシステムで障害が発生して市民生活にも影響が出ることも、残念ながら珍しくなくなりました。

このような障害によるITシステム停止についても、事前のテストはどうなっていたのかと必ず指摘されます。これらのニュースは「品質がおろそかになっていないか？」という印象を持たれる事案です。

品質とは、製品やサービスの利用に支障が出てしまうかもしれない不都合な“何か”で、事前の検査で潰しておくものなのでしょうか。それだと、どうしてもマイナス面を埋めるものという印象になります。

ちょっとITから離れて、品質とはどういう文脈で使うか考えてみます。
たとえば、リゾートで宿泊するホテルや旅館での「サービス品質」はどんなことを想像しますか？また、たとえば、本やパンフレットなどの印刷物の装丁を依頼する場合のクオリティ（品質）はどうでしょうか？快適さや上品さ、目を引くデザインや格好良さなど、そんなプラスイメージを想像しませんか？

品質にはどのような観点がある？

ITのプロフェッショナル達も、サービス停止のトラブルなどの原因となる「バグ」だけを品質だと決めつけているわけではないんです。
製品・サービスの品質要求を洗い出して確実に設計・実装・評価するための指針を規定した国際規格「SQuaRE」（スクエア）というものがあります（[1]p.6:SQuaREとは，[3]）。
国際規格というととても“お堅い”イメージだと思います。たしかにそのとおりで、カジュアルに読めるものでないのはたしかですね。このSQuaREに、品質にはどういう観点があるのかが整理されています。

1つは「製品品質」で、その製品の機能が完全・正確・適切かどうか（機能適合性）という観点に加えて、効率性・互換性・信頼性・セキュリティなどの観点が並びます。この製品品質が、従来の、昨今の報道で問題になる「品質」の目線だろうと思います。ただし、この製品品質は大きな分類のひとつにすぎません。

製品品質の他に、「利用品質」（ざっくり説明すると、ITシステムが稼働・運用してちゃんと役に立っているか）と、「データ品質」（仕組みだけじゃなくて投入するデータがちゃんとしてるか）という観点が示されています。各観点は更に細分化されていて、全体としてはかなり小難しく感じてしまうのが難点ですけれど。

SQuaREの品質特性

さて、国際規格でも「品質観点は多岐にわたる」とされているのに、IT企業での「品質管理」の中心的な話題は、その中の「製品品質」（機能が完全・正確・適切かどうかや、信頼性、セキュリティなど）に偏っている様に見えます。その理由は、元となる製品仕様が事前に詳細まで決まっていて（決まっていれば）、仕様とのズレを計りやすいことにあるのでしょう。かたや、利用品質やデータ品質は「計りにくい」という課題（従来からの積年の課題）があります。

「品質」は「価値」

「品質」はある辞書では「品物の性質」と書かれていますが、その他に「そのもの(品)に期待すること」や、「その品物の性質が要求を満たす程度」という説明の仕方があります([4]，[1]p.5:品質とは）。

ちゃんと使えることやトラブルを起こさないという面もたしかに品質の一面であるのですけれど、明らかにそれだけじゃあない。本当に大事なのはもっと違うところにありそうです。

製品やサービスがちゃんと動いて使えることは、たしかに品質（期待すること）が最低限達成するべきことかもしれませんが、最低限であって全部じゃありません。
「期待していたのとは動きがちょっと違うんだよな」というのが、品質問題かどうかはケースバイケースでしょう。もしかしたら仕様とは違ってもその方が使いやすくなっていてプラスの品質になっている場合すらあるかもしれません。

品質、すなわち期待することには、最初に考えたとおりにできているかの他にももっと大事なことがたくさんあります。先に紹介したSQuaREはそのことを教えてくれています（ちょっと小難しいですけど）。

そもそも、何のためにそのITシステムやサービスを作ろうと／買おうと／使おうと思ったのかが「期待すること」のはずです。つまり、ITシステム／サービスが与えてくれる「価値」が品質のはずです。隠れている虫たちは、その価値を下げてしまう「かもしれない」点においてのみ品質に影響します。（「かもしれない」のであって確実かどうかはケースバイケースです）。

DX時代のITシステム品質の見方・考え方

ようやく「DX」と品質の関係にたどり着きました。でも、ここまで読んでいただければ、何を言いたいのかは薄々おわかりいただけるのではないかと思います。

DX（デジタル変革）によって何を達成したいのかを写し出したものが、DXにとっての品質です。「DX（活動全体）の品質」は、経営を含む事業活動全体が期待したように進んでいるかということになって、ちょっと話が大きくなります。この大きな視点では、「DX推進指標」が示す評価項目や、他組織の取り組みが参考になるでしょう（[5]，[6]）。

DX（デジタル変革）を実現するためのITシステムに目を向けたときの品質はどうでしょう。そのITシステムに期待することは、DX（デジタル変革）を実現することです。DX推進指標の後半はIT システムの構築に関する指標群が示されています。これらがこのITシステムの品質観点に相当します。DX推進指標の性格上、一般論的になっているのは否めませんが、見落としている観点がないかどうかのチェックには有効だろうと思います。

個別具体的なケースでの品質観点は、各組織・各ケースで「どうなりたいか」の達成目標や期待が異なるでしょうから、この方法で測るべしという万能ツールはありません。この点が、DX時代のITシステム品質にとっての最大の悩みどころです。「品質は大事」なので何もしないわけにはいかず、従来型・定番の品質管理（バグを洗い出す活動）が幅を利かせる結果になっている様な気がします。

品質のキモは価値だと書きました。
DX（デジタル変革）の期待を背負ってITシステムの見直しや新規構築に関わることになったとき、ITシステムがどういう価値を生み出して欲しいのかが、はっきりしているでしょうか。「なんでもいいからDXだと言えそうな何かをやってくれ」という雑なケースも多いと聞きます。そんなケースは論外ですけれど、まともなDXプロジェクトでも大なり小なり曖昧な目標感でスタートしているのではないでしょうか。

ITシステムは、最終的には非常に細かくて厳密な制約をもつプログラムコードやIT基盤（ハードウェアやネットワークなど）で実装されますから、「なんとなくこんな感じ」のままでは完成しません。
プロジェクトの進行に合わせて、何を作ろうとしているか？どの程度まで動けばOKか？の詳細化した目標設定を随時見直しながら進めることになるはずです。

ソフトウェア開発の視点では、このアプローチはアジャイル開発そのものであり、アジャイル開発での品質目標の設定の仕方が参考になるはずです。ただし、アジャイル開発での品質活動についても、現時点では「この方法論を行えばOK」という決定版の解答はまだ無さそうです（[1]p.22:アジャイル開発の品質測定）。

また、これもDXに限ったことではないのですが、ITシステムとはソフトウェア（プログラム）だけでできているわけでは無くて、稼働させるIT基盤環境も重要な品質要素です。
さらに、稼働が始まってからが勝負どころなので（だからこそ「本番運用」と呼びます）、運用手法や運用体制なども品質要素になります。そして「DevOps」という言葉があるように開発と運用の連携も求められます。

それら全体を俯瞰して考えないと、DX時代のITシステム品質は「期待していること」に応えられません。ソフトウェアとインフラ、開発と運用、発注側と請負側の様に分業された担当部分だけ見ていると、部分的な品質・手っ取り早く計りやすい品質しか見え無くなってしまいます。

繰り返しになりますが、品質とは達成される価値を計るものです。
もしあなたがITエンジニアとしてDX（デジタル変革）の役割を担うことになったら、期待される価値・達成目標を反映した品質目標を設定してください。品質管理の部署がある場合には、もしかしたら従来型の品質基準と戦うことになるかもしれません。その従来型の品質基準がムダだとは言いません。けれど、DXに期待される成果にまっすぐ向かっていくためには、それに適した品質目標の設定が必要です。

【後編】DX時代のIT品質-リーヌスの法則と品質の守備範囲-

参考情報