ODC分析についてのよもやま話〜ソフトウェア不具合についてのあれやこれや・・・〜第8回「ODC分析の事例研究」(3) 〜さらに非機能要件について考える〜

プロジェクト状況：

2つのコンポーネントAとBから構成された製品について、出荷後お客様から報告された不具合についてインパクト属性分析を行うと、図表1のようになりました。

注）ここで用いているインパクト属性は、この組織でお客様満足度の品質指標として定義しているもので分析しています。

コンポーネントAとBのお客様満足度合いの違いは何でしょうか？

ODC分析での見方と評価：

コンポーネントAとコンポーネントBは非常に異なる分析プロファイルであることが一目で分かります。それぞれを見てみましょう。

コンポーネントA：
お客様は機能性（Capability）に不十分さを感じていることを示しています（青色の部分）。

コンポーネントB：
お客様は機能性（Capability）の不十分さに加えて、黄色の信頼性（Reliability）とオレンジ色の使い勝手（Usability）に不満を感じていることを示しています。

このことから、次の指摘が挙げられます。

指摘：お客様満足度向上には、非機能要件の満足度が重要である

機能の充実で製品の優劣が決まると設計者は思いがちですが、インパクト分析の結果からお客様はそれ以上に「使いやすさ」や「安定性」を求めていることが分かります。

この指摘に対し、示唆される対応策を説明します。

示唆される対応策：機能性の検証と非機能要件の再検証

コンポーネントAとBそれぞれに必要な対応策は以下の通りです。　　　

コンポーネントA：
機能性の検証が不足していることを示唆しています。この場合、機能仕様のみならず機能性に対する要求仕様そのものを見直す必要があります。要求の過不足、誤解、あるいは要求意図の理解不足などが考えられます。

コンポーネントB：
非機能要件の特に信頼性と使用性の検証が不足していることを示唆しています。
おそらく要求にない暗黙知あるいは定量化されていない要求の不明確さなどから、それらに対するシステムテストの考慮が十分にされなかったと考えられます。
再度、非機能要件の設計・検証カバレージを見直し設計修正して、即お客様への解決策の提示および次期開発への設計フィードバックをすべきです。

プロジェクト状況：

基本設計と詳細設計での設計レビューにおける指摘事項を、インパクト属性で分析すると、図表2のようになりました。

何かおかしくないでしょうか？

一目で突出した属性があることが分かります。
ODC分析において分類すると突出した属性がある場合は、何かおかしいと感じ、何かを訴えていると捉えるべきです。

ODC分析での見方と評価：

基本設計および詳細設計のレビューでのレビュー観点に偏りが見られます。
両レビューともCapability（機能性）についての指摘が突出している一方、他のインパクト属性の比率が低く、Performance（性能・効率性）についてはまったく指摘が無いです。
この場合、基本設計および詳細設計でのレビューは、機能性ばかりにレビューが集中している可能性があります。
つまり、設計レビューにおいてお客様視点でのレビューに偏りがあると考えられます。

このことから、次の指摘が挙げられます。

指摘： 設計レビューにおいて、非機能要件に対する特定観点への偏りがある

この指摘に対し、示唆される対応策を説明します。

示唆される対応策：

設計レビューでは、要求仕様に有る無しに関わらず、お客様視点に立って非機能要件をも検証すべきです。

特にお客様の暗黙の要求になりがちなPerformance（性能・効率性）やUsability（使用性）について過去の不具合を見直すなり、要求元に期待を確認するなりして、レビューすべきだと考えます。

以上、インパクト属性分析の事例について解説しました。
ここからインパクト属性分析に関連して非機能要件について、もう少し掘り下げてみようと思います。

インパクト属性の定義はこの連載の第3回で解説しましたが、当時のIBM社の全社共通の品質指標を採用したものと説明しました。つまりインパクト属性は、みなさんの会社、組織で定めた品質指標を採用して分析することも可能ということです。

参考までに第3回でのインパクト属性の定義説明を図表3として再掲します。

インパクト属性の存在理由は長年ソフトウェアの品質研究から見出されたソフトウェア設計において開発企業・組織の設計対象が有するべき非機能品質の特性群であり、検証要件の代用属性と位置付けられるものだからです。

これらは一般的に設計要件の中で非機能要件とか非機能要求あるいは非機能品質と呼ばれるものですが、対をなす機能要件（要求）に比して非機能要件は、目的や具体性、あるいは対価性、投資対効果からややもすると等閑にされやすい要件ではないかと以前から危惧しています。

確かに、金融システムとか公共システムなど一度障害が起こるとその影響の大きさ、被害・損害の甚大さから「信頼性」「性能」「可用性」「保守性」などに具体的に数値的・定量的に品質要求されるのが常ではあります。想定する負荷状況でのレスポンスタイム、スループット時間や24時間×365日稼働、保守計画のためのMTBF（Mean Time Between Failures：平均故障間隔）値等々の実現が求められます。

他方、そこまで要求されない多くのシステム要求の場合、具体的な機能要求は重要視されますが、非機能要求についてはあまり計測可能な具体化・定量化・数値化がされていないことが多いのではないかと経験的に認識しています。

例えば、2000年代初頭に携帯電話（スマートフォンでなく）が本来通話目的の機器でありながらカメラ機能、インターネット接続機能およびメール機能、はてはお財布携帯と称した決済機能まで携帯電話の運営会社（キャリア）から要求され、携帯電話メーカー各社はその膨大な要求事項の実装に大変な思いをされていた時期がありました。当時、私の部門から多数のコンサル要員が国内の大手携帯電話メーカー数社に開発技術支援として参加しました。

なぜ携帯電話メーカー各社のプロジェクトが難儀しているのかを私自身も探る過程で気付いたことがあります。それは、ある時NDAをもとに某社開発部長が見せてくれたキャリアからの要求仕様書の記述にありました。

８cmバインダー何冊にもわたって、機能要求がずらずらと未整理ながら克明に書かれていて眩暈をしそうになりました。その中で目に留まったのは機能要求におまけのように簡単に漠然とした非機能要求が幾つも書かれていたからです。一例として、くだんの開発部長が示してくれたのが「キー操作は、滑らかな押し心地であること」という一文でした。これには二人で苦笑してしまいました。

この要求を書いたキャリアの担当者は、大真面目にユーザビリティー要求のつもりで書いたのでしょうが、「滑らかな押し心地」という表現では、どう設計をし検証したら良いのか実装する携帯電話メーカー側は答えに窮します。
ちなみに当時の携帯電話の操作はまだタッチパネル方式ではなく、物理的なキーボタンを押すものでした。

「押し心地」とは人間の感覚に関わる事柄なので、使う人それぞれで感じ方に違いがあります。グッと「押した」という実感を好む人もいれば、ちょっと触っただけでも反応してくれるのを好む人もいるでしょう。「滑らかな押し心地」とは一体何人の人がどういう感覚なら満足していると判断できるのか？一般解などそもそも存在するのか？究極はこの要求を書いたキャリアの担当者が満足すれば良いのか？と思ってしまいます。

ここで、非機能要求、特にユーザビリティーについて私の経験から私見を述べます。

システム評価において、ユーザビリティーは誰でも、それこそ初心者でも言いやすい領域のようで、「これは使いづらい」とか「反応が悪い」「見え難い」果ては「色使いが嫌い」とか日常使われる表現による評価に終始しまいがちです。このため、解を追求するには工学的表現でないことが多いようです。この感覚に関わる課題を工学の世界に持って行ったのが人間工学 (Human Factors)です。

私が人間工学グループの人たちと深く関わったのはパソコン開発初期、80年代前半でした。コンピューターをコンシューマー製品に仕立てるには、あらゆる使用環境、ユーザーの要望や使い方を研究しなければと人間工学のグループと共同で評価・検証方法を検討していました。プロトタイプを試作して、研究所近辺の事務員、主婦、学生、老人など可能な限り幅広く想定ユーザーを設定してユーザビリティーテストを繰り返していました。その成果はある程度設計に反映されていきました。しかしながら程なく人間工学の人たちと袂を分かったのは、結局コンシューマー機器の世界では、「習うより、慣れろ」的というか、ユーザーの方々の習熟スピードや慣れは思いのほか早いということを学習し、あれこれ考えた過度な親切設計より簡単に操作のやり直しが効き、ストレートで直感的な反応を持った作りが求められていると考えるようになりました。

そんなことよりもっと重要な発見は、ユーザーは時として思いがけない使い方をする場合があると言うことでした。そして、作り手側からすると想定外の使い方への対策を備えていることが製品として受け入れられやすく、完成度という点でも大事であると気づきました。当時の市場不具合報告からユーザーの「とんでもない使い方」を部門内で大いに学び、早速システムテスト項目に盛り込みました。

例えば身近なところで、

①   稼働中にいきなり電源コードを引き抜く。（電源瞬断時のディスクとデータの保全性）
②   キーボードの上に物を落とす。（複数キー同時高速押下時のキーボードバッファーの対応）
③   コーヒーをキーボードにこぼす。（処理継続性、防塵性）
④   印刷中に用紙をつまらせる、用紙を無理に引き抜く。（プリンタードライバーの復旧性）
⑤   稼働中に机の上から落とす。（筐体やディスクの耐久性と復旧性）

などなど、今で言う意地悪テストの走りですが、ソフトウェアのテストなのにずいぶん荒っぽいテストをしていました。

いずれも当時のパソコン設計でなかなか手の回っていない弱いところ、エラーリカバリー機能、キーボードバッファーへの耐負荷、プリンタードライバーのリトライ機能などを検証する理にかなったテストとして確立しました。

しかもこれらのテストケースで、期待に違わず当時のパソコンは面白いように想定外の挙動をしたのです。
そこからの反省の積み重ねなのか、近年のパソコンは多少のことではへこたれない堅牢な設計になっていると感じています。

当初は高機能、親切設計が製品の優位性を決めると信じられていたパソコンも、次第に世の中で当たり前な製品となり、さらに形を変えて進化したタブレット端末、スマートフォンなどが浸透した今の時代にあって、特に生まれた時からそれらが存在する世代のユーザーの対応力、適用力、価値判断は、もはやベテラン設計者など想いもよらない高みに来ているのかもしれません。

余談になりますが、先日、某アパレルショップのレジで対応してくれた女性の店員さんが、タブレットの決済端末を操作している指先を見て驚きました。3cmはあろうかと思うネイルをしたまま滑らかに操作しているのです。思わず「その爪でよく操作できますね」と問うたところ、「はい、すぐ慣れました」と言う返答に、ユーザーの感覚や適用力に隔世の感を覚えました。

同時に思ったことが、よもや「長いネイルでも滑らかな押し心地とはいかに？」などと研究所内で技術者たちが議論したとも思えませんが、そもそも今の時代、端からそんなことは無用な心配事なのでしょうか？

では、非機能品質についての思考はこのまま止まっていて良いのでしょうか？

近年、製品機能のコモディティー化、価格競争、そしてユーザーの知識量から、製品やシステム開発力のどこに競争力を見出せば良いのかと考えた時、やはり「ユーザーに受け入れられる」製品を作るという基本に立ち戻って考えるべきではないかと思います。

そこで昨今、設計品質の評価で重要視されているのが、「利用時品質」という観点です。

設計者の思いと要求元（ユーザー）の期待とにギャップがあると、不満や不具合と見なされ、顧客満足度の低下を招くことが分かっています。そのギャップを埋めてユーザーに受け入れられる製品を作るには、設計者の視野を360°広げ、設計に利用時品質を取り込むべきと考えます。

これまで、ODC分析のコンセプトを軸にソフトウェア不具合について考えてきたこの連載も、次回第9回で一区切りをつけようと考えています。

そこで次回では、これまで不具合ありきでODC分析による開発の「やり方」の改善を導き出すことを解説してきましたが、そもそも「なぜソフトウェア不具合が起こるのか？」と言う問いに対して、以下のテーマを取り上げようと思います。

• 要求元と設計者との間になぜギャップが生じるのか？
• そのギャップを低減するための利用時品質（ISO25000シリーズ）の咀嚼
• つまりは、要求と設計のひも付けに尽きる

こういったテーマを通して、私がODC分析研究から関連・派生して得た品質に関する知見を逆にODC分析に還元していくという試みを、本連載のまとめとして紹介したいと思います。

それでは次回最終回をお楽しみに。

参考文献：

*1) Orthogonal Defect Classification – A concept for In-process Measurement
Ram Chillarege, Inderpal S. Bhandari, Michael J. Halliday, etc., IBM Thomas J. Watson Research Center
IEEE Transactions on Software Engineering Vol .18, No. 11, Nov. 1992ⒸIEEE

｢ソフトウェア不具合改善⼿法ODC分析」 〜 ⼯程の「質」を可視化する 〜
⽇科技連ODC分析研究会編 杉崎眞弘・佐々⽊⽅規
株式会社⽇科技連出版社 (ISBN978-4-8171-9713-9)