HOME > 活動報告 > イベント報告 > JaSST'17 Tokyo

イベント報告
 ソフトウェアテストシンポジウム 2017 東京

2017年2月3日(金)~4日(土) 於 日本大学理工学部 駿河台校舎1号館

ソフトウェアテストシンポジウム 2017 東京

冬の青空の下、JaSST'17 Tokyoは開幕した。会場は昨年に引き続き、日本大学理工学部の駿河台校舎だ。

JaSST Tokyoは例年2日間に渡って開催される。1日目の基調講演と2日目の招待講演以外は、いくつかのセッションが並行して進行するため、いずれかのテーマを選択する必要がある。会場の案内パネルの前で、どのセッションに参加すべきか迷う人の姿も見られた。

以下、筆者が参加したセッションについてレポートする。

A0) オープニングセッション

オープニングセッションおよび基調講演が行われる会場が満員となったため、サテライト会場での聴講となった。

オープニングの挨拶は、JaSST'17 Tokyo共同実行委員長の片山氏が実施した。今年は開催が金・土曜日となり、時期も昨年より1か月早い2月開催となったことを挙げ、アンケートを通じて要望を募り、今後も多くの人が参加しやすい日程を設定していきたいと述べた。

A1) 基調講演
「ICT応用S&S製品の品質不良のリスクとSQuaREシリーズ国際標準 - その歴史と概要」
東 基衞(早稲田大学名誉教授)

ICTを応用したソフトウェアは、年々多様化、巨大化の傾向にある。その中には必ず誤りがある。ただし、誤りが無ければよいというわけでもない。ソフトウェアテストにおいて考えるべきは、そもそもどのような品質が求められるか、ということだ。

東氏は車を例に、「ユーザのやりたいことと安全性が両立しないこともある」と述べた。車のように、人の命や財産に関わる製品をクリティカルな製品という。それらの製品開発・評価では、リスク管理が重要だという。

クリティカルと呼ばれる性質には、様々な種類がある。前述の人命や財産のほか、環境、国益、企業の利益などだ。クリティカルの多様性に応じて、品質も、セキュリティや信頼性、正確性、機能性など、多岐にわたる。ユーザビリティが重要な製品もあれば、それよりも他の品質が重要な製品もある。

東氏が提唱するSQuaREシリーズでは、ソフトウェアの全てのユーザがそれぞれ求める品質を考慮している。ここで言う全てのユーザとは、そのソフトウェアの影響を、直接的、あるいは間接的に受ける全てのユーザ、という意味である。品質の影響を受けるのは、ソフトウェアを直接扱うユーザだけではない。間接的な利用者や、想定とは異なる目的で利用する人もいるのだ。SQuaREは、そのようなステークホルダーが求める品質要求についても標準化し、システム&ソフトウェアの品質向上を支援している。

SQuaREシリーズは元々、多様な国際標準を継承して発展した標準である。今後も、そのような標準を適用しながら、新しく生まれるソフトウェア技術に対応して、改善活動を継続させていくことが重要であると東氏は述べた。

F3) テストのキャリア
「[ジャストーーーク!]転職芸人が語るテスト/QA 技術者としてのキャリアパス」
大西 建児(ガイオ・テクノロジー)
柿崎 憲(サイバード)
山本 くにお(mediba)
山本 健(ミクシィ)
湯本 剛(ASTER)
吉澤 智美(日本電気)
安達 賢二(HBA)
福田 里奈(Fusic)
司会進行:
KENさん(ASTER)
越中谷 郁美(ジャパニアス)

本セッションでは、QA技術者として転職しながらキャリアを積んできたエンジニアの方々(本セッションでは転職芸人と称していた)が、様々な質問に対し経験談を語り合った。なお、セッション中に何度も念押しされていたが、このセッションは転職を勧めるものではなく、あくまでQA技術者のキャリアにおける、幅広い選択肢を提示する、という趣旨となっている。

転職芸人として紹介されたのは、大西建児氏、柿崎憲氏、山本くにお氏、山本健氏、湯本剛氏、吉澤智美氏という、様々なキャリアパターンを持つメンバーであった。セッションでは、あらかじめ6名に対しアンケートを行い、その回答を取り上げて、ゲストの安達氏、福田氏を交えながらトークした。本レポートでは、数ある質問の中から一部を紹介する。

まず、「転職をする理由は?」という質問に対し、湯本氏は「テストの仕事を価値あるものにしたいから」と答えた。テストの仕事は誰にでもできるものではないし、テストがあることでプロジェクトを成功に導きたい。けれども、職場環境によっては、やりたいことを止められる場合がある。だから、自分のやりたいことが実現できる職場を求めて転職するのだと言った。

次に、「転職して驚いたことは?」という質問で、山本健氏は「テストチームの立ち上げをお願いされ転職したが、周りがテストに関して何の知識も無く、理解者がいなかったこと」と答えた。その環境でも、1年半ほどで周囲にテストの重要性を認めてもらえたとのことだ。その回答に山本くにお氏は同調し、「会社によってテストの浸透レベルはまちまち。広める苦労はあるが、テストの面白さを広めることで自走する」と話した。

「なぜ同じQAに転職するのか?」という質問には、大西氏が「定め」と答えた。これまでやってきたことを活かす方が有利だし、テストのコミュニティに参加すると、知り合いに「テストを一緒にしよう」と誘われる。過去には要求分析を行ったこともあったが、その時は失敗し、テストに戻ったという。

一般の方から募った質問も取り上げられた。大学生の方からの質問で、「学生の就活はあまり楽しいイメージは無い。なぜ転職活動を楽しくできるのか?」というものがあった。それに対し柿崎氏は、「転職活動には必ず、行きたい会社の課題を解決したい気持ちがあるから」と答えた。面接担当者と、会社の課題について話をすること自体が楽しい。ただの面接ではなく、ディスカッション感覚だと言った。

最後に、「転職に関わらず、QA技術者として意識することは?」という質問が出た。吉澤氏は、「好奇心、向上心、人脈」と回答した。知らないことを知るのを楽しむこと、自分を育てる気持ち、それから、職場でやりたいことをやらせてもらえるような上司に恵まれることも重要だと語った。

D6) TPI NEXT
「対談 TPI NEXT導入の実際」
湯本 剛(ASTER)
米山 允章(メルカリ)
司会進行:
島根 義和(JaSST Tokyo実行委員会)
藤原 洋平(JaSST Tokyo実行委員会)

昨年のJaSST'16 Tokyoで、株式会社メルカリの米山允章氏は、湯本剛氏が講師を務めた「TPI NEXT」に関するチュートリアルを受講し、実際の現場に導入した。それを知った湯本氏がぜひその話を聞きたいとオファーし、本セッションでの対談が実現した。湯本氏や会場の聴講者から、実際のTPI NEXT導入に関する質問を募り、米山氏が実体験を語る形式で進められた。

TPI NEXTとは、テストプロセス改善モデルのひとつである。TPI NEXTではまず、16のキーエリアにて、自己評価を行う。未達のキーエリアに対する改善提案が定義されており、自己評価に基づいて自己改善を行うことが特徴である。

昨年のチュートリアルで、一部ではあったがTPI NEXTの自己評価を実際に行ったことが、TPI NEXT導入のきっかけとなった。その際に米山氏は、自分の組織が半分程度しかYESにならないことに気付いた。組織のプロセスがあまり良くないのでは、という感覚は元々あったが、TPI NEXTを用いて客観的に足りない部分を知ることで、テストプロセス改善を行うことを決心したという。

当時メルカリでは全社でひとつのQAチームがあった。チーム全体で目標を立てる機会があり、米山さんはそこでTPI NEXTの導入を提案した。当初は「よし、やろう」という積極的な声はあまり聞けず、最初の1か月は1人で進めていたが、興味を持った数名が、徐々に協力してくれるようになっていった。

活動内容として、米山氏は自分の組織に必要なキーエリアをピックアップし、欠陥管理とテスト設計に関する改善を中心に進めたという。また、同じようにTPI NEXTを導入しようとしていた他社のQA担当者と合同勉強会を行い、チェックリストを比較することで、自組織の強み、弱みを確認しながら進めていった。

TPI NEXTで難しいと言われるポイントのひとつに、テストの専門性に関する自己評価がある。技術者によって技術のレベルはまちまちで、どのレベルに合わせるべきなのか迷う部分が出てくる。米山氏の場合は、全ての項目を低いレベルに合わせて改善活動を行おうとするとキリがないため、最低限必要だと思われる改善点については低いレベルに合わせて要改善項目とし、現状必要でない改善点については改善項目から省いているという。湯本氏は、基本的には低いレベルに合わせる方が望ましいとしながら、レベルの高い人、低い人両方からヒアリングを行うべきだと言った。そもそも全員の認識を合わせるのは難しく、中には自己評価が実際より低い人もいるので、それぞれの評価の理由を聞いて、最終的な改善レベルを決定する、とのことだった。

A7) 招待講演
「品質保証活動の本質」
奈良 隆正(NARAコンサルティング代表)

QAの定義は、JISハンドブックやISO8042品質等、様々な標準に記載がある。どの定義も「体系的活動」と記載されており、特定の部門の「作業」ではない、ということに注目したい。品質保証は、品質管理部門だけの仕事ではないということである。

1970年代のソフトウェア品質保証は、黎明期と言える。ハードウェアは必ず出荷前に検査を行うにも関わらず、なぜソフトウェアは行わないのか、という疑問から、不良品を出荷しないための、完成品に対するソフトウェア検査を行うようになった。そこからソフトウェアの素性を明らかにする仕様書が生まれ、レビューとは異なる仕様書のチェック(ドキュメント検査)が始まった。

1980年代は隆盛期だった。ソフトウェアの開発量が爆発的に増え、完成品の検査から開発フェーズの品質管理重視へと移行した。この時代に、V字モデルに基づくソフトウェア品質管理の体系化と普及が始まった。

現在の品質保証に関する技法は、ほとんどが80年代に確立された。70年代は新卒が多く、教える世代が不足していたため、自分で勉強するしかなかった。そのような自主勉強を行っていた世代が、80年代に入り、後輩に教えるようになった。

1990年代前半から、ISO9000の台頭により、ソフトウェア開発はプロダクトよりもプロセス重視の開発となっていった。ところが、現場がプロセスを理解できず、ISOの認証取得のために形骸化してしまう、という事象が発生した。つまり、プロセスは現場の開発者ではなく、専門家が作るものになってしまったのだ。

1990年代半ばから後半にかけて、ソフトウェアの品質をどんなに上げても、ミドルウェアのバグにより頭打ちになるという壁にもぶつかるようになった。これにより、品質の新しい管理法が必要になり、PMBOKなどの導入が盛んに行われた。

2000年代には日本経済は回復し、日本のソフトウェア品質管理が再評価された。CMMIなどのプロセス改善手法が現れ、テストを工学にしようという取り組みが始まった。V字モデルの拡張や、ソフトウェアの品質測定のためのメトリクスも生まれた。

そして今日に至るまで、その測定方法が使われ続けていることに、奈良氏は疑問も感じているという。今の現場のQA技術者たちは、何のために今の手法を用いているのかを学び、考え、ブラッシュアップしていくことが求められているということだった。

まとめ

JaSSTへの参加は今回が初めてだった。複数のセッションが同時に進行するため、いずれかを選んで聴講することになるが、どのテーマも興味深く、体が2つも3つも欲しいと思ったのは久しぶりだ。どのセッションも、新しい気付き、そして学びのある内容であった。

なかでも印象に残ったのは、テストのキャリアを考えるセッション「ジャストーーーク」で吉澤氏が言った「壁を越えるのはマイナスにはならない」という言葉だ。筆者は、新しい何かをするのに躊躇してしまうという課題を持っていたが、「新しいことに挑戦して、失敗したとしてもマイナスではない。何かに挑戦する機会があるなら、恐れずやってみればいい」という言葉に背中を押され、新しいことへ取り組むことに、とても前向きになれた。

私はQA技術者としてのキャリアをスタートさせたばかりだが、この2日間で学んだことに対し理解を深め、それを自分や組織の課題に合わせた形で適用することで、改善につなげていけると確信した。

また、次回JaSSTに参加するときは、QA仲間を誘って行こうと思う。ぜひとも別々のセッションを聴講し、お互いに情報を共有し合って、知識の幅を広げていきたい。

記:中島 千尋

[ページトップへ]