シリー ズ ［続］ソフトウェアの「品質」を考える②

対談

ソフトウェアの難しさとどのように向き合えばいいのか（後編）

本紙３月号（№112pp.6-7）に掲載した対談の前編に引き続き，今号で後編を掲載します。

「ソフトウェアの多様性」をキーワードにした㈱日立情報制御ソリューションズの大島啓二氏とSQiP運営委員長の野中誠先生（東洋大学准教授）の対談は，ユーザー視点の品質のあり方についての話題となりました。

シリー ズ ［続］ソフトウェアの「品質」を考える②込みは妥当だったのかを評価するのは，テストの役割に含まれると思います。
これはハード，ソフトを包含したシステムにおいてたくさんのユーザー，ステークホルダーが存在する中で，どれだけ多様かつ必要な観点で見られるかということです。開発設計者，テスト担当者，皆で本来求められるシステムをどのように考えていくのか。
セクショナリズムを廃して，システムとそれがもたらす顧客価値に全員で向き合うことが大切だと思っています。

――システムを開発する場合に，開発側はユーザーの大島立場でどれだけ深く考えることができるのか。なかな

とても重要なことではないでしょうか。ここをしっかか難しい課題だと思いますが，いかがでしょうか？

りとやることによって大きな価値が生まれると考えてなどが精緻に定義されていることがありますね。評価

野中先生がおっしゃることは難しいけれど，㈱日立情報制御ソリューションズ

大島啓二氏＊

大島 私の経験からお話をさせていただきますが，いいと思います。

用データもしっかりと定められています。システム全

いつも最終ユーザーを意識できるような開発ができる――ソフトウェアの多様性の中で，特に難しいと言わ体としての評価はされていますが，ソフトだけを評価かといえば，そうなっていないケースも多くあります。

れている「ソフトウェアをどのように測るか」というしようとすると難しいですね。ソフトの品質評価では，

しかし，車を例にとれば，最終のユーザーはよくよくテーマがありますが。

例えばテストでの検出バグ数など比較的測りやすい指

考えれば私たち自身でもあるわけですから，どういう

野中難しいテーマですね。本来，お客様に価値を標が用いられていますが，大島さんがおっしゃるよう車が快適で，どういう車載システムがいいのかわかる

提供するという視点で見て，ソフトウェアの性能はどに，システムの特性に合わせた評価方法が適用されてうか，機能の妥当性はどうか，業務との整合性はどういるかと言えば，そうではないように思います。

はずです。医療の分野でも，私たち自身は「患者」と東洋大学准教授いう立場に立てるのです。目線を少し上げれば，たと野中誠先生

かなどの品質を評価する必要があります。しかし，そ大島の評価技術はこれと定まった方法はありませんね。というと，必ずしもそうではありません。品質を追求

お客様はただ品質が良ければ買ってくれるかえメーカーの開発サイドにいてもお客様に様々な視点客様の総意とは言えない場合もあり，立場が異なればでの提案ができるのではないかと思います。

違う要求を持っているのが普通です。様々な意見があ一方で，ユーザーの立場の私としては，残念ながら，しすぎてコストが高くなり，結果としてお客様にそっ野中同感です。そもそもユーザーはどのような利る中で，また，「ソフトウェア開発の仕事をいただい不満に感じてしまうシステムに触れることがしばしばぽを向かれてしまっては意味がありません。つまり，用意図を持っているのかなど，ユーザーの本質的要求ている」という状況で，開発側が信念を持って「仕様あります。ユーザーが不満に思うシステムがリリースお客様の価値向上に寄与しなければいけないのです。

を開発者が共有した上でソフトウェア開発を進めないをこのようにすべき」と主張するのはなかなか難しいされ，運用されているという現実があるわけです。こ

お客様価値というのが本質ですが，これは本当に測りと，ユーザーが満足するシステムはできません。ソフことかもしれません。の原因の一端は品質測定技術の未熟さと難しさにあるにくいものです。

トウェア開発業務を請け負う企業は，与えられた仕様――ソフトウェアのテストの話になりましたが，テスのでしょうが，まずは評価プロセスの充実を図ること

野中 お客様の要求をどのように品質要素として定義通りに動作するソフトウェアを実現することは当然とトでもいろいろな課題がありそうですね。

が必要です。そして，それが開発企業の強みになり，し，それぞれの達成レベルをどのように評価するのか。

して，ユーザーの本質的要求を満たすために，ソフト大島 テスト設計と開発設計のミッション（役割）とユーザーの満足につながり，開発側に適正な収益としその評価結果に基づいて開発プロセスや組織体制をど

ウェア技術に基づく価値を発注側に提案できる能力がをどのように考えればよいのか。一緒にすればよいのて正しく還元される仕組みが大事です。

う改善するのか。その活動のコストは妥当な範囲なの必要です。この能力がないと，ソフトウェア開発は単かというと，必ずしもそうではありません。

大島か。このような視点を常に持たねばなりません。

なるコスト競争の世界になってしまいます。

野中 テスト側でも，開発設計者と「ユーザーの要求一条件です。野中先生にはぜひこの分野でさらに深く

大島あるテスト技術者の方から，テスト設計の時に「仕をどのように考えて設計したのか」を議論することは取り組んでいただければと思っています。ソフトウェ

顧客価値全体を見た時に，エンドユーザーに出してい様には書いていないけれど，こういうことを実現した大切ではないでしょうか。そうすることで，どのようアの世界では共通的な性質と異なる性質が混在していくトータルな品質がちゃんと一定のレベルにあるかどう測るということは，「見る」（わかる）ための第そうですね。単に品質が良い，悪いではなく，いのですよね？」と仕様に言及した時に，開発者からなテスト設計が必要なのかが見えてくると思います。

るものです。最終的にはお客様ごとに違ってくるでかです。メーカー側が達成すべきと考えている品質と，「それはテストの仕事ではなく，設計の仕事。あなた大島

ユーザーの立場から見ると，開発設計者とテしょう。ソフトウェアの性質のある部分は測れるけれ受け入れるユーザーがよしとする品質の両方を踏まえが考えることではない」と言われた話を聞きました。

スト技術者の視点は違います。テストの役割は，ユーど，別の部分は測りにくいということがあるはずです。て，作り込む品質レベルを規定すべきだと思います。

発注側と開発側の壁や，開発側にいる様々な役割を担ザーの視点で必要なことやあってはほしくないことを受託のソフトとパッケージ製品では違います。受託開――ソフトウェアの開発において，達成しなければいう技術者の壁を越えて，お客様に提供する価値に注力

広く考えることだと思います。ものを作る開発設計か発でも，エンタープライズ系と社会インフラ系では異けない品質とは何か，ソフトウェアの多様性という視したいものです。

らすると，途中でコストや安全性などを考えて制約をなります。品質の重点をどこに置くかが違ってきます

点からとても有意義な議論ができました。今回の対談大島設けたり，妥協しなければならないこともあります。

から。ユーザーの使い勝手やシステムの信頼性や安全にご協力いただき誠にありがとうございました。

提案の妥当性を誰に確認するかという点です。お客様，

野中性などの視点も必要です。対象分野やユーザーによっ＊大島氏の所属は取材当時（2013年3月）のものです。

つまり発注側は，もちろん要求をすべて適確に提示でいかなければならなくなりますね。その時に，目的にてそれぞれ別に考えた方がよい場合があります。

きるわけではありません。担当者の要求が必ずしもお対する整合性を鑑みて，第三者的に見てその機能の絞野中

8

そうですね。しかし，難しいのは，その価値

日科技連ニュース No.114 2013年5月号

そうですね，制約のために機能を絞り込んでメカやエレキでは，出荷するための品質基準

SoftwareQuality

Profession

http://juse-sqip.jp

日科技連ニュース No.114 2013年5月号

9