ソフトウェア品質とサービス品質

連休前の某氏とのmtgの中で大変有意義なディスカッションができました。

テーマは「ソフトウェア品質とサービス品質」。

一般的に我々は、なんらかの「モデル」を用いてある時点のソフトウェアの品質を測定(=メトリクス)し品質要求とのギャップを見つけようと試みます。
そして得られた分析結果を次期改修計画などに役立てたいと考えます。

ここで用いるモデルにはいくつかのものがみられますが、それらの基本部分はほぼ共通して以下の様な枠組みで品質を捉えます。

品質側面
品質特性
品質視点
品質関係者

なぜ似通ったものになるのかというと、フレームワークの多くは「ISO/IEC 25000 SQuaREシリーズ」などを下敷きにして作られているからです。

ただし、一段踏み込んで具体的に「メトリクスツール」となるとグッと守備範囲が狭まり、開発時を想定したもの、つまり開発者にとっての品質側面・品質視点・品質特性をスコープとした測定ツールになります。
ソフトウェアライフサイクル全般にわたって広範に品質を測定/評価できるツールはまだ殆ど見つけることが出来ないと言っていいでしょう。

そこで、現在我々のワークグループでは、「ソフトウェア品質をより包括的/多面的に測定/観測/評価したい」とのゴールを設け、利害関係者として「利用者」「開発者」「提供者」の三者を設定し品質のボトルネックの可視化にトライしています。

ここで目下の検討課題となっているのが、「開発者」によって作りこまれた品質(=設計意図の通りきちんと動作をするのか)は「利用者」の要求を満たし且つ「提供者」がソフトウェアに期待する貢献(≒収益性)に寄与できているのかというテーマです。
つまりいかにして、三者のインセンティブ・バランスを評価するのかということ。
そのためには、「サービス品質」と「ソフトウェア品質」の相関を読み解くアプローチが必要になってくるだろうということ。

ちょうどそんなトピックについて議論していたタイミングで良い提案/お声かけをいただいた、そんな今回のmtgだったわけです。
考えも整理することができましたし、プロジェクトの大きなターニングポイントになるような予感がしています。

本来ソフトウェアとは、ある提供価値を体現した一つの実装に過ぎません。サービスの中心的な柱をなすものであってもその全てではない。
言い換えると、ほぼ全てのソフトウェアは何らかのサービスの一環/一部として内包されているもの(たとえそれがサービスの大きなウェイトを占めていたとしても)であるはずです。

サービスの要求品質とソフトウェア要件、そしてソフトウェアの利用を通したサービスへの満足度。
この価値連鎖の中で何がサービスの品質を毀損し提供者利用者間の齟齬を生む要因となっているのか。そしてそれはどこに起因するのか。

まだまだ道半ばでここで詳細まで触れることはできないのですが、引き続き進捗/成果については可能な限りシェアしてきます。
どうぞご期待下さい。