[開催レポート 詳細版2]  一般発表

一般発表 セッションA1  テスト(1)
セッションA3  テスト(2)
セッションA4  分析
セッションB1  妥当性確認、記述手法
セッションB2  レビュー
セッションB4  マネジメント、プロセス改善
セッションC1  プロダクト解析、非機能要求

一般発表

いずれの会場も沢山の方が聴講され、活発な質疑応答、意見交換がされました!!
セッションA1  テスト(1)

A1-1
要因組み合わせによる大量のテスト項目実施における
障害の早期検出および工数削減の取り組み

百足 勇人 氏 富士通株式会社

テストを効果的に実行する上で、相反関係にある「テスト網羅性の最大化」と「テスト時間効率化」の2つを両立することは、SEにとって永遠の課題と言えるでしょう。会場には、テスト技術に興味を持つ多くの聴講者が詰めかけました。

今回の発表は、それまで自社で実施してきた方法を改善したものです。
ランダムにテスト項目を多数発生させ、テストの自動実行および検証することは従前より実践していました。今回はこれに加えて、検出した障害と類似性などを分析して、障害検出効率の高いテスト項目を優先実施し、一方で既知となった障害を機械的に識別することで、検証時間の短縮と精度を高めています。

実務を通して改善していることから、技術的に大分こなれている印象を受けました。聴講者は、適用によるメリットを実感した方が多かったのではないかと思います。会場からは、適用対象の言語に関する質問やテストの優先順位付けの考え方など、実践的な質問が出されていました。

まだまだチャレンジすべき課題があるとのことでしたが、完成度を高めた姿を是非また発表して欲しいものです。

A1-2
Session Based Test Managementによる探索的テストの実践

熊川 一平 氏 株式会社NTTデータ

方法の違いこそあれ、探索的テストを実践しているプロジェクトは多いことと思います。発表は、実例よりテストのやり方を具体的に示し、さらにテストに参加した関係者の評価を考察するものでした。大変実践的な内容に、会場からの質問が集中し、聴講者の関心の高さを感じました。以下に質疑応答の一部をご紹介します。

(1)探索テストの工数が計画値への上乗せとなるのでは?

→障害を早期発見できることで、後工程で手戻りによる工数の増大が避けられることを考えると、計画を圧迫した認識はありません。効果を高めるため、要員には判断力のある人を充てる工夫が必要だと思います。

(2)効果について何か数値で示せるものはないか?

→見つかった障害数、仕様変更の抑制数があります。

(3)Sessionを阻害する要素はあったか?

→テスト環境の構築、用意したテストデータなどです。

A1-3
チームで継続的に探索的テストの効果を出す工夫

中岫 信 氏 東京エレクトロン株式会社

この発表は、継続的なプロジェクトへの適用を通して、探索的テストの質を改善した事例です。自らの探索的テストがアドホックになっているという気付きをスタートに、進め方の問題点を分析し、対策による効果を定量的に測定しながら、メンバーが話し合って改善を進めていく様子が分かり易く整理されていました。
会場から次の様な質問が出されました。

(1)プロジェクト毎に行われるキックオフと振り返りの実施タイミングは?

→キックオフはプロジェクト開始の30分前、振り返りは出荷後の落ち着いた頃合いで、しかし間が空き過ぎないよう注意しています。

(2)工数の増加要因となっていないか?

→工数の分析はしていません。ただ、やり方を議論しながら進めることで、モチベーションを持って楽しく取り組めた実感があります。

(3)テスト時間を決めているのか?

→テスタがテスト時間を決めています。特に時間制限はしていません。

組織的に振り返りを継続していく事は大変な事ですが、継続により探索的テストの質がさらに成熟していくものと期待されます。改善された姿について、また発表をお聞きしたいものです。
レポート:上田 俊昭 氏
セッションA3  テスト(2)

A3-1
クオリティゲートの通過判断として品質特性を利用した受入テストの導入と効果

伊藤 潤平 氏 ウイングアーク1st株式会社

「クオリティゲート」。企業によっては「工程判定」「出荷判定」などと呼んでいるところがあるかもしれません。工程毎での品質の見極めは、決して簡単なことではありません。同様の悩みを持つ聴講者にとって、興味深い発表となりました。
特徴的には、ステージ毎に開始前の受入れテストを実施することにより、工程開始判断(Entrance Criteria)するというもので、問題を先取りすることでステージの遅延を防ぎます。テストレベルの単位はシステムテストをβ1、β2、β3、RCの各ステージに分割し、確認すべきと定めた品質副特性を各ステージに配置する形で、計画的に全ての品質副特性を確認します。聴講者からは、次のような質問がありました。

(1) 終了基準はあるか?(ステージ毎に)

→「バグが全て解決し、テストケースが完了していること」です。

(2)テストの実施者は誰か?(テスト設計~実行)

→ QAが担当します。

(3)派生問題(開発遅延との調整など)と計画の調整を行うのは誰か?

→ QEが担当します。

A3-2
テスト詳細設計プロセスの手順定義によるテストケース抜けの防止

水野 昇幸 氏 Test Engineer's Forum 北海道(コミュニティ)

上流設計での情報不足、設計不足などにより、本来必要なテスト項目が抜け落ちてしまい、トラブルに発展するプロジェクトを時々耳にします。テスト項目の抜け漏れを解決する方法の一つとして、この事例は良い参考になったのではないでしょうか。
今回「テスト詳細プロセスの手順定義」としてご紹介いただいた方法、テンプレートはどこでもそのままでも活用できるものでした。発表者の自信に満ちた分かり易いプレゼンテーションからも、技術的な安定感が感じられました。

会場からは次のような質問がありました。

(1)向いている適用分野はあるか?

→組込み系で実績があります。(その他分野でも活用できると思われます)

(2)気付いていない情報の掘り起こし方はどのようにしている?

→パラメタを整理すると見えないものが見え易くなります。さらに疑問点を追及し、範囲を絞り込んでいくと良いと考えています。

A3-3
業務フローのテスト設計における状態遷移の抽出による業務シナリオ補完手法

井ノ口 伸人 氏 株式会社NTTデータ

テストをテーマとする当会場では、最後のセッションまで多くの聴講者が詰め掛けました。
この発表は、設計作業で起因したテスト漏れに着眼したものでした。その特徴とは、業務フロー図に記載されない代替シナリオ/例外シナリオについて、状態遷移図を整理する過程で仕様漏れを掘り起こしていくというものです。状態遷移図を中心に疑問点を炙り出していく進め方は、直ぐにでも始められる実践的な手法に感じられました。

会場からは、進め方や注意点についての質問が寄せられました。

(1)仕様に疑問が生じ、仕様変更の必要性を発見した時はどうしているか?

→リファインするかしないかは、程度次第、タイミング次第です。顧客承認が必要な場合も出てくるので。

(2)設計者とテスト者は別々の人が担当するのか?

→その通りです。

(3)状態遷移図を中心とした場合、図をたくさん作ることになると推察するが弊害はなかったか?

→図の作成を現場(複数メンバー)に依頼した際、作図の重複が発生してしまい、改善が必要という問題意識を持っています。
レポート:上田 俊昭 氏
セッションA4  分析

A4-1
ソフトウェア品質技術が品質特性に与える効果の見える化と活用の一考察

小島 嘉津江 氏 富士通株式会社

この発表は、「多面化するソフトウェア品質要求をどのように実現できるか」という課題の解として、国際尺度を活用し、関係性モデル「品質ボックス」を開発したというものです。実際に自社の21製品にて運用しており、一部を事例紹介したものでした。品質技術と品質特性の関連付けにSQuBOKガイドを、国際尺度にはISO/IEC2500シリーズを活用しています。

「RISEベンチマーク」においては、検証対象とした製品が重要視している品質特性について、21製品に対する相対位置を示すことで見える化を実現しています。その相対関係を見ることにより、製品が重要視している品質特性について、目標との乖離を確認し、製品へのフィードバックに役立てるというものでした。

会場からは、この方法での実績について質問がありました。実績においても、発表にあったとおり自社の21製品内での評価に役立てているとのこと。「品質ボックス」はSQuBOK V3で掲載を目指すとのことなので、掲載となりますよう期待いたします。

A4-2
ソフトウェア欠陥の共起性を利用した欠陥推定手法の提案
~ 共起欠陥推定アプローチによる潜在欠陥の捕捉 ~

澁谷 将行 氏 株式会社トーセーシステムズ

この発表は、欠陥の混入原因をもとに潜在していると思われる共起欠陥を効果的に推定する方法についての提案です。ある欠陥に付随する欠陥を高い確率で予想し得るのであれば、水平展開により、効率よく欠陥を除去することができるにちがいない。このような課題意識を共有する聴講者には、興味深いセッションだったと思います。

実証実験では、欠陥モデルに従い欠陥予測DBを作成しています。データには、過去の開発プロジェクトの欠陥データを使用しています。結果として「欠陥の共起性から潜在欠陥の推定が可能」「COPアプローチは普遍的な共起欠陥の見つけ方となりうる」と結論付けています。

会場からは、「共起欠陥として特定する欠陥の妥当性根拠が、単に欠陥同士が共起している多さになっているのではないか(障害の性格などが考慮されていないのではないか)。」との指摘があり議論となりました。会場と発表者の間で活発な意見交換が展開され、ソフトウェア品質シンポジウムの良い一例を示すものとなりました。

A4-3
ヒューマンエラーによる失敗・事故の分析手法の提案

海老澤 竜 氏 株式会社日立製作所

プロジェクトは、個性豊かな不特定多数のメンバーにより運営されている点で、ヒューマンエラーのコントロールはなかなか難しいテーマです。本発表は Medical SAFERをもとに、3つの課題を解決して得られた「SE事故分析手法」を提案しています。この分析手法による、より効果を得るための運用方法の紹介があり、実際に分析に関わった9名のSEへのヒアリング結果から、現段階での評価と今後について展望しています。発表は分かり易く、ヒューマンエラーを無くしていきたい意欲を感じました。
会場からは、「人の原因を追究するということは人を責めることに繋がり、分析が迷走して本当の根本原因に辿り着かないのではないか」との質問が出されました。他の聴講者から、「責めないルール造りが必要」「ファシリテートで対応すれば良い」などの意見が出され、議論が深まったセッションとなりました。プロジェクトメンバーの信頼関係を重視するPMの中には、なぜなぜ分析に懐疑的な意見もあります。積極派と慎重派の立場のせめぎあいを見た気がしました。
レポート:上田 俊昭 氏
セッションB1  妥当性確認、記述手法

B1-1
安全性解析手法STAMP/STPAにおけるプロセスモデル抽出方法の提案

福島 裕子 氏 日本ユニシス株式会社

STAMP/SPTAは、安全でないコントロールアクション:UCA(アンコントロールアクション)から、事故につながるという考え方で安全性を考えます。分析のステップは、①事故、安全、UCAを決め、②UCAの識別をし、③UCAの原因特定をします。

例として、列車運転中にドア開ける。これは、「運転手が」「走行中に」「ドアを開ける」とモデル化できます。さらに「走行中に」を分解して、①電車状態:走行、停止②電車位置:駅、駅以外とできます。
プロセスモデルの組合せは、電車状態 x 電車位置 x ドア状態とできます。それぞれを階層化、詳細化していき、網羅性を高められます。更に幅を広げる改良案として、6W3H(Who,When,Whom,What,How,How many,How much)でとらえる方法を考案しました。

分析・解析はスキルの要求される作業であり、形式的に実施する手法は初級者のOJTなどで使えると思われます。新しい知見が得られました。

B1-2
D-Case 適用ガイドライン策定によるシステム妥当性確保の取り組み

森 素子 氏 三菱電機株式会社

3回目のD-CASE発表とのことでした。
D-CASEは、システムのディペンダビリティの説明責任と合意のためのツールです。
D-CASEを使う例は、顧客ニーズの深堀、リスク洗い出し、暗黙知などです。そこで、ガイドライン作成をしました。工夫点は、D-CASE使ったPDCAの回し方を示した事と、パターンを作成し書きやすくした事です。
更に作成ワークショップも行いました。ワークショップにより理解が深まり、新しい機能も抽出できました。4チームで実施しましたが、実業務でその後使われたのは1チームでした。活用されない原因は、メンテナンスが大変である、やらなくても価値創出は困らない、すぐ適用できず忘れる、などです。今後は、抽出タスクを通常業務にのせる、メンテナンスせずリスク導出ツールと割り切るなどです。
以前の発表を聞き、D-CASEを使ってみたという聴講者との討論が見られました。発表を聞き実践した人がいるんだと思いました。ソフトウェア品質シンポジウムが情報収集の場として有効に機能していると感じました。

B1-3
さまざまな視点に合わせた仕様書の作成・維持の支援手法

酒井 雄太 氏

仕様書の課題として、記述があいまい、関係者で関心が異なる、不整合などがあります。解決策として、厳密な1個の仕様書から関係者毎の仕様書の自動生成を検討し検証した結果、一定の効果と感触が得られました。

仕様書はVDM(Vienna Development Method)で記載しました。画面遷移図の生成、実行ログよりシーケンス図を自動生成できました。

質問では、VDMで仕様書を書くなら、初めからシーケンス図を描いた方が早い。現状の要求される開発スピードに対応できるのか?等の懸念が示されました。この様に発表者も気づいていない観点が得られ、よい交流ができていました。
レポート:岩佐 賢 氏
セッションB2  レビュー

B2-1
レビュー記録のテキスト分析結果による多角的な品質管理方法の提案

佐藤 孝司 氏 日本電気株式会社

発表者の開発プロジェクトでは、上流工程の品質担保のためレビュー工数の基準値を定め、これを達成する事による評価は完遂しています。つまり、従来レビュー実施工数の評価により、出荷時の品質評価を実施してきたのですが、このプロセスの成熟により、レビュー工数での評価は現況以上の改善に意味を持たない状況となりました。そこで更なる高次元の評価軸として、レビュー実施内容の評価に踏み込み、その手段として、レビュー記録と品質の相関関係について研究した結果が報告されました。

従来のレビュー結果、品質においては、レビュー密度と摘出バグ密度の相関評価、及び追加変更機能単位の前後工程の品質の経過評価が主流でした。更に踏み込んだメトリクスを検討した結果、レビュープロセス自体の運用に着目し、レビュー記録文書の中の「言葉」に着目しました。レビュー記録で使う言葉の中で、「述語」は汎用的な表現が多く用いられるという点です。例えば「漏れ・不足・抜け」等の言葉は「漏れ」の指摘であり、「修正・訂正・改修」は「間違い」の指摘です。この言葉の表現をメトリクスとして、過去のレビュー結果を評価する事により、レビュープロセスが正常に機能したかどうかを評価できる仕組みが提案されました。例えば、意外なメトリクスとして「指摘文が長い」という特性があります。この場合は、要点を読み取る事が把握しづらくなるため、レビュープロセスとしてはよろしくないわけです。

この手法と従来手法との併用により、レビュー品質の評価精度が高まるものと期待されます。文書の分析については、非常に煩雑な作業が必要となります。今後、AI技術等の高度な分析の仕組みが使えるようになれば、更なる効果が見込める評価が可能となると期待される興味ある報告でした。

B2-2
レビュー会議の可視化により目的の曖昧さを明確にする手法の提案

西澤 賢一 氏 GEヘルスケア・ジャパン株式会社

レビュー会議の結果の分析手法、分析結果による評価については多くの議論がある所ですが、本稿においては、その議論の背景となるレビュー会議の内容について言及されたものであります。つまり、レビュー会議に関する様々な議論の根源に関わる研究であり、その観点として、効率的で有効な議論がされているかを分析し、改善手法を考察、検証した結果について報告がありました。

現状把握のため、過去のレビュー会議における課題事項を収集した結果が示されました。何れも心当たりのある事象です。
  • 本来議論すべき内容から反れている
  • 欠陥の修正内容にまで議論してしまうので時間がかかる
  • 軽微な欠陥しか摘出されない
  • 同種の欠陥摘出にまで議論してしまうので時間がかかってしまう
これら課題に対し共通する原因は、レビュー会議の目的が曖昧で、かつ、会議参加者に共有されていない事に起因していると想定されました。

これら状況を把握し、改善を実施する仕組みとして「TMBRI法」が考案されました。TMBR法とはレビューの目的の共有を実施し、会議での発言の時間・発言者の測定と可視化、更に会議参加者全員が参加して、レビュー運用結果を分析し、改善につなげる仕組みです。ポイントは、発言内容について各々の時間を計測し、発言者と発言内容全てを分類し、それら結果について参加者全員で分析する事で、各人が自らの対応状況を振り返る事で改善につなげる仕組みです。通常、これら取り組みについては、第三者の分析結果を当事者に提示し改善を迫られるわけですが、自らが分析に加わり、やらされ感を排除したところが本報告の肝であると感じました。

さて、この効果の検証ですが、レビュー会議の目的の事前明示と実施内容を見える化した事で、実務者自らが、改善点について認識を深めるという成果が認められています。課題事項として、導入容易性について、見える化の為のデータ収集集計分析に時間がかかる事が提起されました。これについては、今後の自動化等の対策が必要でしょう。

本取り組みについては、考察した手法が実務者自らに振り返りを問う事で、サイクルを回せば回すほどその成果が得られ、組織能力の向上につながることが期待されます。この考え方はレビューイベントのみならず、他の業務への適用による改善にも想像が膨らみました。

B2-3
レビュー重視と品質・生産性の関係分析-品質と生産性の向上は両立するか-

丸山 志保 氏 日本電気株式会社

品質と生産性の両立は、定性的に語られる事は多いのですが、この裏付けとして、実際の開発実績を用いた分析結果と、この結果にもとづいた品質と生産性の両立により、双方の改善が可能であるとの報告がありました。着目点はレビューにおける品質状況と最終的な生産性についてです。

当該社では、設計からコーディング工程で作りこまれるバグと単体試験以降で取り出すバグの関係を「品質会計」と名付け、バグをお金の出し入れに例えたわかりやすい仕組みを定義し運用しています。定量的な目標値として、開発全体での摘出件数の8割を上工程レビューで摘出する事を目標値としているそうです。なお、開発案件の特性のバラツキを考慮して、「汎用ソフトウェア系」と「特定顧客向けソフトウェア系」に分けて評価されていました。

本来の品質評価は、出荷後に顧客からのバグ指摘(摘出)について評価すべきであります。これについては、過去の分析結果から出荷後バグ基準値に対して、達成/未達成のカテゴリ分けをしています。つまり、そもそも本来達成すべき出荷後の品質を達成したプロジェクトでないと、開発期間中の品質生産性の評価には意味が無いからです。

この過去分析の傾向について、定量的な証明をするために、500件を超える開発案件について、出荷後の品質とその開発にかかった工数との相関の評価が報告されました。その結果、上工程バグ摘出が多いほど生産性が高く、且つ出荷後品質が高い事が示されました。つまり、品質と生産性の両立が証明されたわけです。

こういった分析においては、各プロジェクトの案件内容、開発体制、開発期間環境等の外部要因によるバラツキ、特異値を、如何に排除して求めるべき分析を実施するかが重要なのですが、この実現に向け、そもそも高品質とは開発内の評価ではなく、出荷後の運用品質である事。開発する案件のカテゴリに依存した品質のバラツキの考慮を、基本に据えた上で分析を実施した事により、結果の信頼性が高められたと考えられます。この成果を基に、品質・生産性の改善に向けた取り組みの加速に大きく寄与できる報告と期待されました。
レポート:田村 善嗣 氏
セッションB4  マネジメント、プロセス改善

B4-1
大規模で短期間のソフトウェア開発における品質進捗へのアプローチ ~ Quality Mind and Skill Scoring System ~

羽田 達哉 氏 株式会社日立製作所

過去の実績の分析結果より、チェックリストを適切に運用し、品質情報の共有が良い製品を生み出すことが分かりました。QM3S(Quality Mind and Skill Scoring System)という手法を実施しました。

チェックリストの項目毎に、担当者とリーダーのチェック項目数を記載し、比較し、重み係数をかけ総合点数を求めます。スコアより高リスクを品質分析し、改善しました。

実施結果は、QM3Sをやったオフショア先が、バグをたくさん見つけて、受け入れバグが少ない結果でした。チェックリスト観点の質問がたくさんあり、品質マインドの醸成にも効果がありました。

オフシュア先の品質向上は、どこでも悩んでいる事象です。チェックリスト項目をチェック数に変えるだけで、これだけ効果があるのは驚きでした。

B4-2
第三者検証活動からの開発プロジェクトマネジメントに対する改善提案

内藤 拓 氏 富士通クオリティ・ラボ株式会社

富士通の開発プロジェクト審査をしています。開発計画書を受領し、全数審査を実施し、横展開すべき内容や事例、品質人材の育成など実施しました。審査結果の傾向は、プロセス不備は減少していますが、マネジメント不備は、年度により増減あります。マネジメント不備は、65%が検証の領域で、計画文書が未格納/未作成なのに工程完了していたり、レビュー指摘分類がばらばらなど、開発計画書に決めた運用ができていません。

振り返り、障害分析は、79製品中で56製品ができています。優秀な事例を横展開し、新たにリスクの抽出・管理方法を検討したいと思います。

品質保証を専門に実施している部門で、プロジェクト審査を上記以外でも様々な観点から実施していました。

B4-3
WHYに重点を置いた人材育成:やりがいのあるプロセスへ

片山 泰司 氏 オムロン ソーシアルソリューションズ株式会社

「プロセスに対する納得不足」→「プロセス不遵守の増加」→「市場不具合の増加」の負のサイクルを改善するため、プロセスの目的・必要性の理解に重点をおいた教育を実施した取り組み事例です。
トレーニングでは、
  • はじめから品質のよいものをつくりだすプロセスづくりの基本の考え方が生まれたことを理解してもらう
  • プロセスによる嬉しいこと、不遵守によるリスク、成熟度レベル向上の嬉しさをたとえばなしでわかりやすく伝える
など紹介がありました。

また、トレーニングにおいて「聞いてよかった」というお得感を感じてもらえるよう、現場のノウハウやお役立ち情報を紹介するようしたところ、ベテランさんから「以外に知らない情報があってよかった」との感想をいただけたそうです。

アンケートの調査の結果、過去のトレーニングと比較すると、すべての項目で評価がアップし、また、コメントの記入率は35%から80%にアップし、この結果から、目的や意義を伝える事で教育効果が上がった事が確認できたそうです。

目的を明確にする事は、色々な場面で言われていますが、この様な実例を示してもらうと、より納得でき、重要性も実感できました。
レポート:岩佐 賢 氏
セッションC1  プロダクト解析、非機能要求

C1-1
統合テストにおいて影響範囲に対するテスト漏れを防止する
「影響波及パス分析法」の提案

柏原 一雄 氏 株式会社デンソークリエイト

派生開発では、変更した部分以外への影響の有無の確認が永遠の課題です。この課題に対し、影響範囲の特定、試験網羅性の工夫は元より、そもそもの原因である影響範囲を小さくする設計に踏み込んだ成果について、報告されました。

注目すべきは、「影響波及パス解析法」を考案し、この手法を用いる事で得た影響範囲の把握と試験の網羅性確認のみに留まらず、「影響範囲を小さくする設計」へフィードバックできる事です。これにより、従来経験者頼りであった影響範囲に対する試験項目抽出がシステマティックにできることを実開発において証明した事、及び、「影響波及パス数」は見積もりや品質データ分析での活用も期待され、今後も興味が持てる報告と思われます。特に影響波及パス分析法については皆様興味を持たれ、今後も議論が発展しそうでした。

C1-2
ソースコードメトリクスと品質リスクとの関係分析と
それに基づくリスクヘッジ手法に向けて

山田 弘隆 氏 富士通株式会社

近年の開発では、他者の開発した既存のソフトウェアを有効に活用する事で、多様なサービスを短期で開発する事が一般的です。実際の開発現場では、この流用したソフトウェアが想定通りの動作をせず、この手直しが重大なリスクとなる事も多く経験します。この対処として「流用部分の品質を事前に評価をする取り組みをしてきたが、その結果が開発現場に定着しない」という課題を抱えていました。対策として開発現場に対し流用部の品質評価結果を定量的に示す事で、浸透・定着を狙った取り組みについて報告がありました。

流用部を評価する仕組みは自動化したのですが、その結果のリスクの評価、問題の対処方法、対処の効果が見えないという開発現場からの課題が提起されました。通常、この時点で取り組みをあきらめてしまう事を多く経験しますが、本報告の重要な論点はここからでした。以下の対策を実施する事で開発現場への理解が得られたとの事です。「ソースコードメトリクスと品質リスクの相関を事実で示す」、「具体的な改善案を示す」、「対処結果としての成果を示す」。 第三者的な組織での施策が開発現場に浸透しない事はよく経験します。ここであきらめずに開発現場と一体となり、真のゴールである品質改善、納期厳守まで結びつけた成果は非常に興味がもたれました。会場からは、評価のための閾値の決め方、実際の評価における仕様上の問題と機能上の問題の切り分け、他のメトリクスを調べたのか等々の具体的質問が多くあり関心の高さが感じられました。

C1-3
派生開発での時間効率性劣化を変更要求から検出する方法

中村 奈津子 氏 日本電子株式会社

派生開発の終盤において、問題が顕在化する事例として時間効率性(性能)劣化があります。派生開発においての時間効率性の変動については、要件として明示される事が少なく、所謂「非機能要件」と分類されます。このため、顧客が実際に操作する段階になり不具合との指摘を受ける事が多くあります。この課題が潜在化してしまう要因を分析し、設計段階までに気付きを得る事で、それ以降の手戻りによる開発コストの増加・納期遅延の防止について、過去事例の問題を分析した結果から、対策について検討検証した結果が報告されました。

時間効率性劣化が潜在化する要因について、過去事例から以下が挙げられました。「変化する認識が無い」「認識はあるが変化を劣化とは考えていない」「顧客に劣化を説明できていない」。これら要因について、過去事例を調査する事で、設計者に気付きを与えるべく変化を確認する観点表を作成し、変化するであろう想定値を見積り記載する仕組みが提起されました。更に、この見積り値に対応して試験工程における実績値を記載する事で、想定値との差分を評価可能な仕組みが示されました。これらの取り組みの評価として、過去事例について検証した所、7件中約半数の事例で精度の高い結果が得られたとの報告がありました。課題として、想定値の設定時において非線形の増加が予想される場合には、想定が難しい事です。

今回は、過去事例からの効果の想定の報告でしたが、今後の実開発での効果に期待が持たれる報告でした。
レポート:田村 善嗣 氏(NTTコムウェア株式会社)