開催レポート 詳細版1
基調講演、特別講演、一般発表

基調講演

IoT 時代の品質・生産性向上とは;“共創”に基づく-顧客価値創造

圓川 隆夫 氏
職業能力開発総合大学校長、東京工業大学名誉教授
特別講演

「物流の改革」を実現 宅急便の進化を支える最重要システム・IT 戦略

田中 従雅 氏
ヤマトホールディングス株式会社 執行役員 IT 戦略担当、ヤマト運輸株式会社 常務執行役員
一般発表

セッションA1 「レビュー」

セッションA2 「テスト」

セッションA3 「プロセス改善」

セッションA4 「アジャイル開発」

セッションA5 「自動化」

セッションB1 「品質保証」

セッションB3 「メトリクス・データ分析」

セッションB4 「人材育成」

オープニング


大杉副委員長(左)
シンポジウム委員のみなさん(下)
ソフトウェア品質シンポジウム2018委員会・私たちが、企画・運営いたしました

基調講演

IoT 時代の品質・生産性向上とは;“共創”に基づく-顧客価値創造

圓川 隆夫 氏
職業能力開発総合大学校長、東京工業大学名誉教授

講演者・圓川氏

満員御礼!
今年も多くの方にご参加いただきました
  1. 共創とは、顧客に価値を感じさせる“ありがたいこと”を考え抜くプロセス
    講演冒頭でこのように述べられた圓川先生。近年よく目にするようになった“共創”という言葉ですが、基調講演ではこれからの時代における“コトづくり”発想による“共創”の重要性についてわかりやすくお話しいただきました。
  2. 今起こりつつある革命と日本の現状
    世界の大きな変化の中でAIなどの技術力はどんどん高まっており、日本においても空港の入国審査への顔認証システム導入など驚くようなことが起きています。一方、国際競争力という点では日本は低迷している現状があります。しかし、圓川先生は「日本も主役の座からはまだ遠くはなく、今こそ競争力を上げていくことを考えなければいけない。いまの時代の状況は立て直すのにいいチャンスである」と述べられ、今こそ新技術を活用するためのマネジメント技術が必要なのではないか、と提言をされました。
  3. 「実用的価値(モノ)」から「情緒的価値(コト)」へ
    「品質には、裏の品質力(適合品質、設計品質)と表の品質力(顧客価値、顧客ニーズ)がある。日本は裏の品質力は依然強いはずであり、表の品質力をどう強くしていくか、顧客価値をどう創造していくかが鍵になる。」と前置きし、日本において表の品質力を強くしていくうえでの8つの課題を挙げられていました。多機能疲労、品質差の見える化の失敗、など、どれも自分が現場でリアルに実感してきた課題ばかりで納得感がありました。
  4. 顧客価値をどのように創造し実現していくか
    顧客価値の代用特性としてのCS(顧客満足)についても解説をしていただき、CS生成モデルや各国においての結果の違いなどはとても興味深いものでした。同じスマホでもiPhoneのCSが高いのはなぜか?という問題提起や、幸福追求欲求(こうありたいと思う姿に接近したい)を介したCSへの影響の解説があり、共創を引き起こすメカニズムが非常にわかりやすかったです。また、顧客価値実現のための戦略のひとつとして“コトづくり発想”を挙げられていましたが、手法は様々であれ、感性を働かせて考え抜くこと、固定概念にとらわれない発想力が求められるのだと感じました。
  5. 共創マネジメントに向けて
    「アメリカから理論だけを持ってきて日本でうまくいくかというと決してそうではない。」という言葉が印象的でした。日本文化の特徴である“今(現在主義)=ここ(共同体集団主義)”の強み、弱みをふまえたうえで、これらをベースとして良い方向へ変えていく“技能を科学する”が必要なのではないかという提言は『過去の成功にも失敗にもとらわれず、時代の変化をキャッチして考え抜こう!自身の強みを活かして高みを目指そう!』というメッセージであると感じました。
  6. おわりに
    見えていない世界に対する感受性を上げ、いかに共創力を発揮していけるか。まだまだ失敗する事例も多く、失敗を恐れてしまう私たち日本人にとっては少し勇気がいることだと思います。しかし、ここを一歩乗り越えることは、さらなる品質向上に不可欠であると認識しました。圓川先生、素晴らしいご講演をありがとうございました。
レポート:平岡 百合子 氏

特別講演

「物流の改革」を実現 宅急便の進化を支える最重要システム・IT 戦略

田中 従雅 氏
ヤマトホールディングス株式会社 執行役員 IT 戦略担当、ヤマト運輸株式会社 常務執行役員

講演者・田中氏
ヤマトホールディングスのシステムは、「NEKOシステム」という名称で開発されており、現在8次NEKOシステムまで進化しています。このシステムは3次から大きく変わり、セールスドライバーがPortable POSSでデータ入力するようになりました。その後、4次でICカード採用、5次で端末を用途により分け、6次ではお客様に荷物のトレースデータを見てもらうためにPOSSの情報をネットワークに上げ、7次では電子マネーを使用できるようにしていきました。最新の8次では伝票情報をためて、足りない部分はヤマト運輸が補完することで最適な配送ルートを決められるようになりました。今後のシステムにおいて、宅配データを蓄積することにより、お客様が在宅している時間に荷物を配達するということも検討しましたが、現状、個人情報保護の問題もあり、データの蓄積は行っていないとのことでした。

2013年から車から取れるデータを分析して指導することで、安全・安心を追及し、現在開発中ですが、エンジン回転、ブレーキ回数、急ハンドルなどのデータから、さらに安全を追求すること、取得したデータをクラウドに上げて現在起きている事象に対して指導すること、ドライバーの異常時に必要なら車を止めることなど考えているそうです。

10年~15年後にはロボット配送になる時代が来るのではないかと考えていますが、ヤマト運輸はセールスドライバーのサービスが売りになっていますので、すべてをロボット配送にはせず、ロボット配送とセールスドライバーを2極化してトライされるそうです。

本講演を聴講し、ヤマト運輸は右肩上がりに業績を伸ばされていますが、それは、新しいことに挑戦し続けたこそ業績であると思いました。攻めのITはどこの企業も欲しがっています。先を見据えながら、何か新しいことにチャレンジしていくということを念頭に置き、仕事に励んでいこうと思いました。
レポート:鈴木 祐司 氏

一般発表


一般発表の会場の様子。質疑応答では、会場から多くの質問が寄せられました。
一般発表は10セッションで計23件の発表がありました。
ご発表くださいましたみなさま、ありがとうございました。

セッションA1「レビュー」

A1-1 作成者の認知バイアスに着目したレビュー手法の提案

湯川 健 氏(ソーバル株式会社)
誰でも持っている認知バイアスをレビューに生かそうというD2BOCs(Defect Detection from Background of Cognitive bias)法について、認知バイアスの説明からしていただき、とても理解しやすい発表でした。
D2BOCs法の適用により、従来法よりも難易度と重大度の高い問題点の適出が可能になったとのことで、手法は有効であり、手法を取り入れたレビューをすぐにでも取り入れて実施してみたいと思いました。

会場では、認知バイアスに関する以下の質問がありました。
Q1:認知バイアスから、欠陥の紐付けはどのように行いましたか。
A1:欠陥の分析をして、欠陥モデリングを参考にして行いました。

Q2:作成者がセルフチェックする場合の注意点はありますか。
A2:今後の課題となっています。メタ認知を使って、第3者的に自分を見ることで認知バイアスから逃れられるのではないかと考えています。

Q3:認知バイアスの影響を受けない成果物の作成方法はありますか。
A3:欠陥を埋め込まないのが良いことですが、第3者でないと気付けないこともあり、レビューは必要と考えています。

A1-2 運用の観点を取り入れたレビュー手法の促進と有効性評価

桑村 陽子 氏(日本電気株式会社)
「運用を考慮した設計不足」による障害が最も多いことへの対策で、運用の観点を取り入れたレビュー手法の体験教育についての有効性評価の発表でした。

会場では、以下の意見や質問がありました。
・個人の経験に基づいたレビュー(Ad Hoc Reading:AHR)以外のレビューであれば、レビュー教育の有効性は認められています。
Q1:レビューに観点を取り入れるPerspective-Based Reading(PBR)の効果はすばらしいと思います。ただし、PBRでのレビューで指摘が0件のチームがありますが、どうしてでしょうか。
A1:0件のチームについて、これから振り返り、傾向を分析したいと思います。

Q2:日本ではレビュー能力の高い人が存在しています。教育で見つかりましたか。
A2:チームでのレビュー結果を集計しましたので、個人の能力は確認しませんでした。難易度の高いバグを摘出した人は、問題とした機能の経験者でした。

A1-3 顧客の期待に応えるためのコンセプトベースドレビューの提案

小楠 聡美 氏(株式会社HBA)
自社の強みと顧客の要望を満たすためのコンセプトベースドレビューの提案でした。魅力的品質の作りこみには、有効な手法と感じます。札幌からいらした発表者は、地震の影響による手書きの資料を用いて熱い提案を行ってくれました。

会場からは、以下の参考情報や質問がありました。
・ハードウェアのQFD手法を参考にするとより良いものになると思います。

Q1:要求を作るところの提案と思います。超上流での対応は難しいでしょうか。
A1:お客様から要求を聞くとそこに凝り固まっています。これからは要求を作るときにやってみようと思っています。

Q2:SEの市場調査も限界があるので、営業含めて市場調査が必要と思いますか。
A2:お客様と一緒にコンセプトを考えることが良いと思っています。
レポート:小森 正美 氏(株式会社日立ソリューションズ・クリエイト)

セッションA2「テスト」

A2-1 テストケースの自動生成を見据えた基本設計フォーマット作成アプローチの提案

中川 穂 氏(株式会社インテック)
テスト仕様書の自動生成を見据えた、基本設計書のフォーマット作成のアプローチに関する発表でした。これは、上流工程に携わることが少ないテストエンジニアがより生産性の高いテストを”楽”に実施でき、”皆がハッピーになれる”基本設計の実現を目指そうというテーマで、テスト仕様書の自動生成に関心があるエンジニアには興味深い発表でした。

この提案における基本設計書のフォーマットは、抽象度や厳格さが手書きにより変化しないよう厳密性を担保する(縛る)部分と開発するシステム仕様の自由度を奪わないように自由な記述による表現、読みやすい表現または書きやすい表現を可能にする(縛らない)部分からなり、両者のバランスを取るというものでした。

実験では、被験者が記入した基本設計書から疑似コードに基づくアルゴリズムによってテストケースに変換し、その結果から基本設計書のフォーマットの有効性を確認します。続いてその確認結果に基づいてガイドラインの正しさの検証やテストに必要な事項・情報を基本設計書のフォーマットにフィードバックするという改善のサイクルを回しており、手間と苦労が伺えました。

今回の発表では、結果がわかりやすい業務システムの端末のUIを対象にしていました。質疑応答でも議論がありましたが、UI以外での対応の可否、テストの粒度やテストのカバー率の目標についても同様のアプローチで実現可能との事でした。基本設計書からテスト仕様書へ自動変換出来れば、属人性の排除やテスト設計の工数が削減でき、開発の効率化を行うことが出来ます。同様の課題を抱える技術者の関心は高く、質疑応答は時間一杯まで続きました。

基本設計書のフォーマットの更なる拡張、基本設計以外のフェーズで適用するためのアプローチおよび自動化ツールの実現について期待しています。

A2-2 短納期型開発プロジェクトのためのテスト手法
    「FaRSeT(Flexible and Rapid Software Test)」の適用と効果

上田 和樹 氏(日本ナレッジ株式会社)
「FaRSeT」を適用し、仕様変更や開発スケジュールの変動によるテスト工数の増加の抑制に成功した問題解決の事例発表でした。特に短納期型開発ではよくありがちな問題であり、とても興味深い内容でした。

「FaRSeT」は、仕様変更の度合いによりテスト設計および分析のアプローチを変えています。例えば、仕様変更の多い要素に対しては手順書を記述しない探索的テストを採用し、仕様変更の少ない要素に対しては探索的テストの実施前にマインドマップを活用した業務分析を行っています。開発スケジュールの変更に応じた最善なテストのために探索的テストマトリクスを活用しています。これは品質状況の把握など、利害関係者間で可視化による視覚的効果と情報の共有性が高いと感じました。

探索的テストマトリクスでは、仕様が変更された場合は、手順書を修正する場合と異なりマトリクスを修正するだけにとどめ、影響を少なくするよう工夫がされていました。また、マトリクスの交点に摘出したバグ数を記入することで不具合の多い品質要件を認識できるようになっています。テストの実施も、探索的テストマトリクスを見ながら、プログラムの実装状況、品質状況など優先順位の高い箇所から実施することで開発スケジュールが変更になった場合でも効率の良いテストが行えるよう考えられている事が理解出来ました。
また、マインドマップや探索的テストマトリクスの作成のために多くの時間がかかるのではないかと思いましたが、アドホックテストや、業務分析もテストチャートも用いない探索的テストに比較しても結果的に不具合検出に必要な工数が少なくなるメリットがあることを丁寧に説明頂き、効果的で実用的な手法であると実感しました。

質疑応答では、マインドマップの扱いについても質問がありました。マインドマップを顧客との調整に使用したり、不具合分析の中間成果物や納品物としている旨の回答が発表者からあり、短納期型開発における効率化のコツだと感じました。
レポート:大堀 忠嗣 氏

セッションA3「プロセス改善」

開発におけるプロセス改善にはキリがありません。また、プロジェクトや環境が変わると、それまでのプロセスでも上手くいかなくなったりもします。そんな中で何らかのヒントを得られないかと参加させていただきました。

A3-1 開発現場のプロセス改善~自工程完結によるアプローチ~

芳沢 圭一 氏(株式会社オージス総研)
今回の発表は、メンテナンスで長期間にわたり1つのシステムの開発、運用を実施した際に多々発生してしまうノウハウやスキルの属人化についてスポットを当て、その解決アプローチのご紹介でした。近年、ITコストの削減などから、要員的な余裕もなくなってきています。その際に発生しがちなのが属人化です。属人化はよく課題として挙げられますが、一方で究極の効率化という一面も持っています。そのため、後々の課題となるリスクがあると分かっていても、属人化に頼ってしまうことも多いのではないでしょうか。
 それに対し、よくある標準化・マニュアル化という対策に留まらず、「誰がやっても同じ品質」を実現するため、プロセスと成果に第三者が判定可能な基準を設けるという一歩踏み込んだものでした。また、併せて実際の現場の改善の流れや、メンバーのモチベーションを保つための工夫も紹介いただき、興味深く視聴させていただきました。

会場からは次のような質問が挙がりました。
Q:属人化の解消は抵抗があるのでは?
A:有識者がノウハウを出すのを嫌がる、他のメンバーが仕事の増加を嫌がるなどの抵抗が最初はあった。ただ「顧客の予算の削減により有識者を維持できない」などの共通の危機を示し、取り組むことで一丸となり解決できた。

A3-2 振り返りを力強く推進する「FOPA 振り返りプロセス Ver.2」の提案
   - 効率的で納得感の高い振り返り分析と、TRY実行支援活動の具体化 -

田中 桂三 氏(オムロン株式会社)
最初に発表者から以下の問いかけがありました。
・振り返りをやっているか?
・振り返りで取り決めたことは次の案件で実施できているか?

過去の全ての案件に対し自信を持ってYesと言える人は、少ないのではないでしょうか。人の入れ替わり、不十分な引継ぎ、時間の経過、次プロジェクトが忙しいなどの様々な要因から、資産ともいえる振り返り結果が失われしまうリスクは定常的に潜んでいます。それに対しKTP法やRedmineといった比較的一般的なツールを活用し、解決策を導いている点が興味深かかったです。

会場からは次のような質問が挙がりました。
Q1:TRYを次プロジェクトのメンバーにモチベーション高く取組んでもらうには?
A1:本当に必要と思わないと人はやらない。そのため、前プロジェクトのProblemにより前メンバーがどんな痛みを経験したのかを前メンバーが対面で伝える必要がある。

Q2:振り返り会が確実に実施されるようにするには?
A2:PMO側で全プロジェクトの完了時期を把握している。また、完了時期にメンバーにリマインドや、開催場所や参加依頼の発信などのお膳立てを行うことで確実な実施を実現している。
レポート:櫻井 淳人 氏(株式会社インテック)

セッションA4「アジャイル開発」

私がアジャイル開発を初めて知ったのは、エスクトリームプログラミング(XP)が登場した時でした。当時思ったのは、XPを導入したいが品証をいかにクリアするのかという点でした。ウォーターフォール全盛の時代には、XPの導入はかなりハードルが高いものでした。それから20年近く経ち、品質をテーマとした集まりで、アジャイル開発がテーマに挙げられていることは興味深く、実際の現場でアジャイル開発の品質にどのように取り組んでいるのか興味深く聞かせていただきました。
会場はほぼ満席で、品質の視点でもアジャイル開発は注目されているテーマなのだなと思いました。

A4-1 アジャイル開発における利用者価値が高いソフトウェアのリリーススピード向上に向けた取組み

酒井 響平 氏(富士通株式会社)
「お客様にとって価値あるソフトウェアを迅速かつ高品質で提供する」ことを目標に、富士通のプロダクト部門ではアジリティ重視開発プロセスによる開発に取り組んでいます。
この取り組み中で、迅速な提供が実現できないケースがあり、問題となっていました。ユーザエクスペリエンス(UX)の評価とその修正が、同一スプリント内で実施されないため、リリーススピードが期待したほど上がりませんでした。
同一スプリント内でUX評価とその修正を行うためには、開発チーム内でその評価を行う必要があります。
この問題にいかに取り組んだか、というのが今回の発表でした。取り組みは以下2つです。

取り組み1.スプリント計画時のシナリオ作成
取り組み2.UXメトリクスの導入

これは、機能開発前にUX目標値を明確にすることで開発者に裁量を持たせて開発をしてもらうことだと理解して発表を聞いていました。開発者のパフォーマンスを引き出すというアジャイル開発の良いところを引き出し、品質も向上させた好例と思いました。開発者の方も高いモチベーションを維持して開発に取り組めたのではと想像します。

参加者からは以下のような質問が出ていました。
Q1:開発時間が短くなってしまわないか?
Q2:パフォーマンスメトリックは測定する人によってバラつきがでないか?

A4-2 アジャイルプラクティスを導入した開発における品質メトリクスの提案

松田 元輝 氏(株式会社日立製作所)
「変化に強くしたい、効率を上げたい、早めにリスクを除去したい、価値/品質を上げたい」これを実現するために、開発プロジェクトの一部に、アジャイルプラクティスの導入を推進しています。しかし、いくつかのプロジェクトでは品質が安定せず、市場不具合が発生している状況です。
過去のプロジェクトを分析した結果、バグの摘出がリリース直前に偏っていることが分かりました。そこで、アジャイル開発のようなイテレーティブ開発でも適用可能な「前倒し率」の算出方法を考案し、その有用性を検証した取り組みを紹介していました。

前倒し率はプロジェクト終了時でないと測定できないが、開発中の前倒し率を開発者に見せることで、開発者が早めにE2Eテストする、難易度の高い機能を早めに開発する、倒しでテストする、という意識付けできるとのことでした。

参加者からは以下のような質問が出ていました。
Q1:前倒しを上手くできていないプロジェクトがあるのはなぜ?
Q2:バグの数をメトリクスの計算のベースに選んだ理由は?

アジャイル開発になったからといって、品証の本質が変わるものではないと思います。品質の本質をしっかり理解して、アジャイル開発に適用していくこのようなチャレンジによって、従来よりもエクストリームされた品証が生み出されていくことに期待しています。
レポート:宮澤 匡 氏(横河ソリューションサービス株式会社)

セッションA5「自動化」

A5-1 UIテストの所要時間を10分の1に短縮する取り組み
    ~ラズベリーパイのクラスターで並列実行~

折田 武己 氏(レバテック株式会社)
WebアプリケーションなどのUIを用いたソフトウェア製品では、用意したインターフェースを用いてアプリケーションを操作した時の動作を確認するテスト(以下UIテスト)を実施します。
近年では、そのUIテストを自動化するツールが整備されてきましたが、複雑な処理を伴うなどの理由により、テストに時間がかかるという問題があります。
その解決策として、テスト専用のPCを購入したり、クラウドサービスを利用したりする方法がありますが、それぞれ導入コストや運用コストが高額になるといった課題があります。
そこで、本発表では、ラズベリーパイというシンプルなコンピュータを活用してUIテストを並列で実行可能な環境を構築することで、UIテストの所要時間の短縮を安価に実現されています。
ラズベリーパイは安価という利点がある一方で、一般的なPCと比較して性能が低いという欠点がありますが、UIテストの実行時間は通信時間によるところが大きく、性能が低くても台数効果を十分に発揮することができることから、ラズベリーパイの特長を最大限に活かした試みと言えます。
計算能力の確保の手段としてクラウドサービスが一般的になりつつある現在において、敢えてローカル技術に着目した点は興味深く、性能やコストの面でクラウドサービスと具体的にどの程度違いがあるのかが気になる所です。

A5-2 ソフトウェアコードレビューのAI技術を応用した自動化の試み

西田 啓一 氏(テクマトリックス株式会社)
近年ソフトウェアの大規模化が進んでおり、数千数万ものモジュールによって構成されるソフトウェアも珍しくありません。
そのようなソフトウェアのレビューやテストを全てのモジュールについて万遍なく実施するのは時間やコストの観点から困難になりつつあり、品質を維持しつつ、レビューやテストを効率的に実施する手段が求められています。
そこで、本発表ではソフトウェアの構造指標(CKメトリクス)の値とバグ情報を特徴量とし、そのパターンからバグが含まれている可能性が高いモジュールを推定し、レビューやテストの優先順位付けに繋げる試みがなされています。
さらに、バグが含まれる可能性が高いと判断したモジュールについて、CKメトリクスを用いたFuzzy推論によって、開発者に改善案を提案する試みもなされています。
ソフトウェアの構造指標の値の大小によってソフトウェアの品質リスクを評価することは従来から行われてきましたが、明確な基準が無い指標が多く、その精度に課題がありました。本発表の機械学習モデルでは約9割の精度でバグを含むモジュールを特定できたとのことで、非常に高い精度を達成されている印象です。
また、ソースコードの改善については、改善案の提案だけでなくコードの自動修正まで可能になれば、リファクタリングの大幅な効率化が実現できると思われるため、今後の発展に期待したい所です。
レポート:川上 大輔 氏

セッションB1「品質保証」

B1-1 GSN 及びESD モデルを用いたソフトウェアFMEA の提案

梅田 浩貴 氏(国立研究開発法人宇宙航空研究開発機構)
宇宙航空研究開発機構(JAXA)では、システム限界や制約の抽出のためにFMEA(故障モードと影響解析)を行っていますが、ソフトウェアに対してFMEAを適用する際、分析行為におけるエキスパート依存性が高い、分析結果に対するレビューが困難、過去フィールドデータの活用が困難という課題が発生しています。
これらの課題に対して、分析フレームワークで特徴点を抽出後、GSN(Goal Structuring Notation)のビューで故障モードを発想し、ESD(Event Sequence Diagram)のビューで故障モードの有効性を確認することで故障モードの発想を高めることができました。

熟練者、非熟練者の双方において故障モードの発想支援ができ、開発の進捗に合わせて繰り返し適用することで効果が大きくなると思いました。

B1-2 マルチベンダー構成システムの信頼性向上を目的としたフェールセーフ設計に対する点検手法 ~HAZOP を活用した例外事象を含む応答のモデル化~

相澤 孝一 氏(富士通株式会社)
HAZOP(Hazard and Operability Studies)は、1960年代、英国ICI社が、自社開発の新規化学プロセスを対象として、潜在危険性をもれなく洗い出し、それらの影響・結果を評価し、必要な安全対策を講ずることを目的として開発されたプロセス危険性の特定手法です。

お客様に導入するシステムがマルチベンダー化になったため、想定外事象でのトラブル発生リスクが高まっています。しかし、ホワイトボックステストができないため、システム全体でトラブルへの備えが必要だと考えました。
製品故障が業務処理に返す応答をモデル化することとシーケンス化で妥当性の確認を検証することで、従来システムと同等な信頼性まで品質を向上させることができました。

マルチベンダー化により仕様が良くわからないシステムが入っていても、これまでのノウハウを生かして従来と同じような品質で点検できることは、多くの企業において品質向上に役立つと思います。事例を積み上げることで、設計者に対しても提案できるということなので、企業全体での品質向上にも有効だと思います。

B1-3 セーフティ&セキュリティ開発のための技術統合提案
   ~ STAMP/STPA とアシュアランスケースの統合~

中嶋 良秀 氏(株式会社ノーリツ)
IoT時代に求められる開発方法論はセーフティまたはセキュリティの一方だけを意識したものではなく、両方を意識したものであるべきです。機器連携サービスの一例として自動車の自動運転サービスを取り上げて事例作成を行い、改良点や問題点の洗い出しを行いました。
セーフティの手法であるSTAMP(Systems-Theoretic Accident Model and Processes)/STPA(STPA-Sec)にSTRIDE(Microsoft が提唱する脅威の分類手法)のヒントワードを拡張することでセーフティとセキュリティ両方に関する脅威を洗い出すことができました。

自動車の自動運転の事例ではセーフティとセキュリティ両方を意識することが必要ですが、IoTでインターネットに接続する機器が増えるとセキュリティがより重要になってくると思いました。

GSNが品質保証の2つのセッションに取り上げられていて、ホットな話題だと思いました。
レポート:鈴木 祐司 氏

セッションB3「メトリクス・データ分析」

B3-1 メンテナンスフェーズにおける欠陥周期性分析手法の提案

澁谷 将行 氏(株式会社トーセーシステムズ)
ソフトウェア製品は、開発にかかる期間(1~2年)よりも、保守にかかる期間(5~6年)が長いことが多く、ソフトウェアの全ライフサイクルコストの40%~80%は保守が占めていると言われています。
また、保守期間(以下、メンテナンスフェーズ)では、ツールの改修やデータ修正などの似たような作業が繰り返し実施され、欠陥の検知数が増減することが知られています。
本発表は、このメンテナンスフェーズにおける欠陥の検知数の周期性を分析することで、今後発生する欠陥の数を予測し、事前に適切な体制を整備したり、あるいは周期性を引き起こす原因を分析することで、欠陥数の平準化、すなわち修正作業の負荷の平準化に繋げる試みになります。
このような試みは、企業の基幹システムなど、比較的長期間運用され、かつシステムの改修が定常的に実施されるようなシステムで、特に有用なものになるのではないかと感じました。
また、発表では欠陥を全体数で取り扱っていましたが、欠陥を層別することで、より詳細な分析ができるのではないかといった意見や、特異スペクトル解析を用いた周期性の分析について、フーリエ変換を用いてはどうかといった意見が聴講者から出ており、今後に向けて様々な発展が期待されます。

B3-2 ソフトウェア開発プロジェクトにおける工数の構成分析―適切な管理工数とは―

齊藤 拓也 氏(日本電気株式会社)
ソフトウェア開発において、工数は関心が高い事項の一つであり、開発するソフトウェアの規模に応じて増加することが知られています。
一方、ソフト開発における工数は、一般的にソフトウェアの開発に直接関係する工数以外に、開発の管理工数や顧客対応工数といった間接的な工数が含まれます。
本発表では、ソフト開発における工数を開発工数、管理工数、顧客対応工数の3つに分離し、これらと開発規模の関係を分析することで、ソフトウェア開発における適切な管理工数がどの程度かを分析されています。
具体的には、まず出荷後のバグ基準を満たしているかどうかで良いプロジェクトと悪いプロジェクトを層別し、良いプロジェクトにおいて、管理工数とその他の工数や開発規模の関係を相関分析することで、相関の強い指標に対する管理工数の比率を導出し、これを適切な管理工数とされています。
300件近いプロジェクトを対象に統計手法を用いて分析されており、非常に信頼度の高い結果であることが伺えました。 一方、その対象には多業種のSI系ソフトウェア開発プロジェクトが含まれているということで、業種やソフトウェアの種類によって特徴に違いがあるかどうかが気になる所です。
また、聴講者からは開発工数や開発規模が正しく見積もれなければ適切な管理工数が導出できないのではないかという意見があり、これらを如何にして精度良く見積もるかが次の課題になると感じました。
レポート:川上 大輔 氏

セッションB4「人材育成」

B4-1 「利用時の品質」観点に基づくドキュメントレビューのための教育カリキュラムの提案

伊藤 浩子 氏(キヤノンIT ソリューションズ株式会社)
レビューの問題として、レビュー漏れが減らない、レビューアを育てるが難しいというのがあります。品質特性についても、そもそも品質特性がわかりにくい、観点の網羅性を広げるにはどのように使ったらよいかわからないという問題があります。
レビューの観点としてSQuaREの品質モデル(品質特性)を活用し、品質特性をわかりやすい言葉で解説した資料を作成し、利用時の品質に着目した演習を行いました。教育を受けた後、1回目の教育トライアルでは7割の人が意識できるようになった、観点が広がったとアンケートに答えました。

このセッションで品質特性の大切さがよくわかりました。作成された品質特性の資料もわかりやすく、公開していただければ、多くの企業で活用できると思います。

B4-2 テスティングロールに基づく人財マネジメントの取り組み

小林 元樹 氏(株式会社ディー・エヌ・エー)
サービスの急激な拡大・変化に伴い、QA業務を担う部門の人員も急速に増加しています。それら人員の多くはテストベンダーから派遣されたメンバーで構成されており、急速な人員増加に伴い、技術・マネジメント領域を問わず様々な問題が発生するようになりました。
本取り組みではマネジメント領域に焦点を当て、QAメンバーのスキルアンマッチやモチベーションに関する問題をメンバーのスキルレベルを定義したテスティングロールを使用することで解決しました。
テスティングロールをメンバーのアサインに使用するだけでなく、数値でメンバーの評価に使用することで、メンバーが自身のスキルレベルや目指すレベルを把握しやすくなりました。

担当する業務や所属するチームでロールの難易度が異なるなど問題点はまだありますが、メンバーのアサインミスをなくし、モチベーションの向上に十分な効果があると思いました。
レポート:鈴木 祐司 氏