SQIPシンポジウム2019に行ってきた
はじめに
久しぶりの更新。
先日、上長のススメでソフトウェア品質シンポジウム(SQIPシンポジウム)を聴講してきた。
QAエンジニアとして働き初めて7年経ったが、
これまで社外のシンポジウムやセミナーに参加したことがなかった私。
(住んでいるのが地方なので、なかなか都内のセミナーに参加できなかったというのもありますが。。。)
せっかく頂いた機会なので、聴講して学んだこと、感じたことについて残しておく。
(完全に自分用備忘録なので、若干まとまりのない文章になります。ご容赦ください)
SQIPシンポジウムとは?
リンク先はこちら。
www.juse.jp
ソフトウェア開発における品質保証活動(テスト、品質分析、レビュー etc)をテーマとした発表・聴講を通じて自分が取り組んでいる品質保証活動活動の展開・共有する場。
聴講者の層としては、ソフトウェアハウス、メーカーに務めるQA部門、テストテストエンジニアの人が多かった。
アカデミックな内容もあったので、企業や大学の研究者の方々もそれなりに。
登壇された方のバックグラウンドは総合電機メーカー、ソフトウェアハウス、PCメーカー、自動車メーカー、SIer、大学教員などなど。
本会議は9/12(木)と9/13(金)に開催。場所は東洋大学白山キャンパス。
聴講したもの
プログラム自体は2日間でしたが、仕事の都合で初日(9/12)だけしか聴講できず。。。
今回は初参加ということもあり、色々な方のお話が聞きたかったので、全カテゴリまんべんなく聴講できるようにチョイスした。
実際に聴講したセッションの中でいくつか気づきがあったので、備忘録として下記にまとめておく。
【特別講演】建設業界のデジタルトランスフォーメーションについて
登壇者は国内最大の重機メーカ「コマツ」の執行委員の方。
重機機械にIoTを導入して作業の自動化・効率化を図る「スマートコンストラクション」の取り組みについてのお話。
講話の中で最も印象的だったのは下記。
「メーカーはシステムの品質や処理性能をよくアピールするが、建設業界の現場側からすればそれはどうでもいい。建設業界の現場が一番重視していることはそのシステムを使ってどのような利益・恩恵を受けるかということ。顧客に説明するときは、自分の主張がメーカ目線になっていないかを十分注意する必要がある」
これは建設業界だけにとどまらず、SEと顧客の間でも言える話ではないかと。
私自身も、顧客にシステムの提案や説明をするときに、「そんなのは求めていない」と言われてしまったという話をよく聞く。
QAとして気にかけなければいけないのは、テストケース作ったりバグ報告したりするときはメーカ目線ではなくユーザ目線でやることかな。。。
よく色んな人から「顧客目線で検査しろ」とか「顧客目線で説明しろ」と言われるが、その本質はここにあるのかもしれない。
ODCを用いた品質分析作業の標準化のお話
登壇者はエプソンアヴァシスの方。
どこのQAもテスト管理ツール、もしくはバグ管理ツールをもとに品質分析を実施しているが、品質分析のアプローチは体系化・標準化された手法がないため、分析者の力量に左右されてしまうという問題がある。
これを業務の中で標準化することで、だれでも分析ができるようにしようというお話。
ODCというのは、下記7つの属性を組み合わせて分析し、そこから掘り下げを行うアプローチ。
Attributes | 属性 | 概要 |
---|---|---|
Defect Removal Activities | 検出工程 | 欠陥を摘出した工程 |
Trigger | トリガー | 欠陥を発見する観点 |
Impact | インパクト(品質特性) | お客様に与える影響 |
Target | 修正対象 | 修正対象の成果物 |
Defect Type | 欠陥タイプ | 修正した欠陥の種類 |
Qualifier | 起因 | 欠陥埋め込みの種類 |
Age | 混入時期 | いつ作り込まれたか |
Source | 発生元 | 成果物の出頃 |
面白かったのは、分析の目的に合わせた属性の組み合わせパターンを提示していた点。
例えばテスト工程の場合:
- テストの成熟度を確認したいときは・・・トリガー+検出工程の軸で分析を行う。
- テストの強化観点を確認したいときは・・・トリガー+欠陥タイプの軸で分析を行う。
- テストの完成度を確認したいときは・・・トリガーとテスト項目有無の軸で分析を行う。
確かにこれならケースバイケースでやることが決まるので、分析の属人化が減らせそう。
すぐに実戦で試せそうなので、早速実際に動いているPJで試してみようと思います。
視線情報解析を用いたUX評価のためのユーザビリティテスト
登壇者は富士通の方。
ユーザビリティテスト中のオペレータの目線を計測し、その視線情報を元にシステムの使いやすさ(UX評価)を向上させようというもの。着眼点がとても面白い。
ユーザがテスト中に見たものがデータとして残るため、テスト後のインタビューで収集できなかった情報が得られるのは良いなと思いました。
ただ、視線情報を確実にとるには、事前のキャリブレーションが必要とのこと。
顧客(ユーザ)試験に適用すれば、生の運用目線のデータが得られるかなと思ったけど、キャリブレーションの時間とストレスがネックかな。。。
【ランチセッション】レビューツールの紹介
ランチセッションとは、簡単に言うとお昼ご飯を食べながら発表を聴けるセッションのこと。
なかなか面白いシステムだなと思いました。
SQIPシンポジウムでは事前申込さえすれば追加料金なしで参加できるようです。
私が参加した9/12(木)はデンソークリエイトかSCSKのうち1社の発表を選択する形式でした。
事前にアブストを読んで比較したところ、Lightning Reviewというレビューツールが面白そうだったので
前者を選択させていただきました。
www.lightning-review.com
このツールの特徴を簡潔にまとめると下記の通り。
- レビュー成果物としてWord, Excel, Powerpoint, PDFファイルのインポートが可能。
- ファイルインポート機能が優秀。ドキュメントファイルに設定されている見出し構造を自動解析し、そのまま取り込める。
- ドキュメントのキャプチャ取得ができる。直接書き込んだり矢印や丸をつけることができるため、担当者に指摘箇所を正確に伝えることができる。
- 担当者はツール経由で修正内容をレビュアーに伝達できるため。別途説明用の資料を作成する手間が省ける。
- レビューの指摘内容は「未修正」「修正済」「確認済」の3種類に色分けして表示できるため、指摘内容の一元管理・刈り取りがもれなく行える。
ざっと振り返ってみるとなかなか良さそう。気になるライセンス料もそれほど高くない。
自分が所属している部署でもレビューツールを取り入れ始めようとしているようなので、
今度紹介してみようと思います。
セッションで配布されたお弁当も美味しかった←
まとめ
その他、参加してみて感じたこと。
- 品質分析の標準化の話はパターンが体系化されていてシンプルだった。早速自部署で実践してみる。
- Lightning Reviewなかなか良い。自部署に紹介して、導入予定のツールと比較させてみようと思います。
- アジャイル開発のセッションはどこも満員で驚いた。「何度もSprintを回すアジャイル開発を導入したPJに対し、QAはどのようにして品質の見極めを行うか」がQA共通の関心事になっているように感じた。ウォーターフォール型しか経験してこなかった自分にとっては新鮮だったが、他の聴講者にとっては当たり前の内容だったように感じられた。(自分の考え方が古いのか、実は置いていかれている・・・?)
- 自部署のQA業務のなかでは思いつかなかったアイデアやシステムを知ることができたのは良かった。Lightning Reviewやエプソンアヴァシスの品質分析手法については、自社のセミナーだけでは知り得ない情報だった。「井の中の蛙」にならないためにも、積極的に社外に出て情報収集することも大事だということを学んだ。
- 一方で、アイデアは斬新だが、「まだ計画段階で実用化はまだ」という発表も何件か見受けられた。どの企業も「ソフトウェア品質」で抱える問題点をなんとか解決するために数多の提案出しているようだが、実開発PJに適用するのはなかなか難しいようだ。これに関してはどの企業のQAも頭を悩ませているんだな感じた。
まとまりの無いまとめになってしまいましたが
今後の指針を与えられた気がします。
何かしら成果出して、今度は自分が登壇できるよう精進しよう。