目のつけどころが“ソフト”でしょ 第4回　開発プロセス考4 　　　　　　　　――ソフトウェアの品質は変化する 伊藤 昌夫（いとう・まさお） (株)ニルソフトウェア ソフトウェア・コンサルタント 「たしかなものがあるとすれば，それは変化である．今日計画している対象も，明日になれば違った形になっている」（Crosby, P.，PHILIP CROSBY’S REFLECTIONS ON QUALITY，McGraw-Hill，1995）． ●ソフトウェアの品質を解剖すると… 　ソフトウェアの品質をプロセスの視点で考えると，少し違った面が見えてきます．品質というのは，ソフトウェアにとってむずかしい課題の一つです．「仕様どおりにできていればよい」，というほど話は簡単ではありません．だいたい，ソフトウェア開発では仕様がきちんと書かれることが少ない！ ソフトウェア開発にたずさわる人たちは，やはりいい加減，とお思いでしょうか．否定はしませんが，より本質的な問題があることを今回は指摘したいと思います． 　品質の問題を考えるときは，最初に品質特性というものを考えます．これは，「ソフトウェアの品質はこういう視点から考えなさい」という指針です．ここまでは，一般の品質に関する議論と同じです．ソフトウェアの場合，品質特性には以下のものがあります注1． 機能性：要求された機能を備えているか 信頼性：どのくらい信頼できるか 使用性：どのくらい使いやすいかか 効率性：どのくらい効率がよいか 保守性：どのくらい保守しやすいか 移植性：どのくらい他の環境に移植しやすいか 　たとえば，使用性というのはわかりにくい日本語ですが，かみ砕いて言うと「使い勝手」です．さらに，この使用性は，理解性（わかりやすさ）や習得性（覚えやすさ），運用性（利用しやすさ）といった2次的な特性から構成されています． 　さて，ここまでくるといろいろな疑問がわいてくると思います．理解性と習得性の間にはどのような関係があるのか．効率性と使用性の間に関係はあるのか（スピードの遅いシステムは，たいてい使い勝手が悪い）．適切な測定法はどうやって選択するのか． 　しかし，ここでは遠大な議論を展開することなく，もう少し気軽に考えてみます．ソフトウェアの品質を仕様ですべて規定するのであれば，上記に示した特性についての記述が必要です．では，使い勝手はどう表現すればよいのでしょうか？ あるいは，拡張しながら使い続けられるソフトウェアにおける保守性の規定は？ ●品質は人間とソフトウェアの関係で規定される 　上記の問題には，多くの未解決の部分があります．したがって，「品質の規定が仕様書にすべて書かれていれば，その項目を検査することで品質を測定できる」と言われても，問題は解決しません．品質に関連する記述を仕様書にどう表現すればよいのか，という点は依然不明だからです．ここにソフトウェアのむずかしさがあります．では，このむずかしさの原因はどこにあるのでしょう． 　賢明な読者の方ならそれは，「人間が介在することによる必然だ」とすぐに答えられるでしょう．多くのソフトウェアは，人間を含むシステムになっています注2． 　だとすると，品質というのは決して固定したものではなくなります．使用性に端的に現れるように，品質というのはユーザにとっての満足です．もし，人間が変化すれば，人間とプログラムの関係である品質も影響を受けます注3． 　例を挙げましょう．いままで，紙の帳票によって事務処理を行っていたとします．その処理を，ソフトウェアを使用することで，可能な限り自動化を図ったとします．もちろん，紙の帳票は存在しません．となると，そこで働く人のプロセス（業務の手順）が変化します．このとき，このプロセスの変化による影響を正確に予測することは不可能です（WWW のシステムを開発した人は，世界がここまで変わるとどうして予測できただろう…）．つまり，ソフトウェアができた後の人間とソフトウェアの関わりを，ソフトウェアがない時点で記述することはできないのです．品質を厳密に仕様化することは，この点でも不可能ということになります． 　さて，救いのない結論になってしまいましたが，ソフトウェアにおける品質とは人間とソフトウェアの関係によって規定され，その関係は時間とともに変化するものだ，ということを覚えておいていただいて，機会があればこの問題に対処するために，どのような手段が試みられてきたかを紹介したいと思います． 注1　ISO/IEC9126「ソフトウェア製品の評価」．JISでは，和訳したものをX0129 として規格化している． 注2　シミュレーションの世界では，Man-in-the-Loopと呼ばれる．システムがなんらかの出力を行い，それに対して人間が別の入力を行う．たしかに，コンパイラのようにMan-in-the-Loopとは呼べないものもあるが，ソフトウェアの多くは対話型システムである．もちろん，ハードウェアにおいても人間系が問題になる場合はある．たとえば，自動車．乗り心地はどう評価すればよいのか． 注3　最初に挙げたZD運動で有名なクロスビーの言葉は，改善活動を行う人に対する警告．ソフトウェアではつねに人間が介在するので，この言葉は真である． >>> コラムに対する感想はこちらへ (本コラムはDesign Wave Magazine2000年6月号に掲載されました)

◆筆者プロフィール◆ 伊藤昌夫（いとう・まさお）．自動車会社，航空機関連会社のソフトウェア・エンジニアを経て，ニルソフトウェアを設立．ソフトウェア・プロセスおよび開発環境が専門で，そのためのコンサルテーションおよびツールの提供を行っている．設計における人間の認知活動に興味を持っている．

Copyright(C) 2000 CQ Publishing Co., Ltd. All Rights Reserved.