ソフトウェアの品質を学びまくる

ソフトウェアの品質、ソフトウェアテストなどについて学んだことを記録するブログです。

JSTQB-TTAシラバスのお勉強 ─ 第2章「構造ベースドテスト」(1)

資格 テスト設計・技法

　TTAシラバスの第2章「構造ベースドテスト」は非常に謎めいた構成で、2.2から2.6までがコードカバレッジの話なのに、2.7が突然「APIテスト」なのです。なんだかとてもバランスが悪い印象なのですが、とにかく進むしかありません。
　あと「based」の訳が当初「ベース」と「ベースド」で不統一だったことから現在は「ベースド」に統一されていますが、さすがに「漢字熟語＋ベースド」にはギャグ感があります・・・。

2　構造ベースドテスト

　構造ベースドテストは、シラバスに

テスト設計のベースとして、コード、データ、アーキテクチャ、およびシステムフローを使用する。

とあるように、プログラムの中身からテストを作っていく方法です。
　第2章で説明されるコードカバレッジについては、以前の記事で自分なりの整理をしました。詳しくはそちらを参照！ということで、個々で気になる点だけ補足していきたいと思います。

www.kzsuzuki.com

2.2　条件テスト

　対応するコードカバレッジは、条件網羅です。「判定」と「条件」がなんとなく似ているので混乱しがちなのですが、「条件」(condition)は不可分な命題です。∧や∨を含みません。「判定」(decision)は、条件やその組み合わせを評価した結果のブーリアンです。

　条件網羅はあまり実用的な意味のない概念だと思います。
　たとえば条件100個からなる、こんな判定を考えてみましょう。

(条件1 ∧ 条件2 ∧ ... ∧ 条件99) ∨ 条件100

　考えられる組み合わせは2100個ありますが、この場合に条件網羅を100%にするには、

条件1～99 = True、条件100 = False 条件1～99 = False、条件100 = Ture

の2つでOKです。一方、この2つのテストケースでは判定がともにFalseになるので、Trueの場合を実行できず、判定網羅は50%になってしまいます。

2.3　判定条件テスト

　対応するコードカバレッジは、判定網羅です。
　制限/注意事項としては「テストケースの増加」に言及していますが、条件網羅が保証されない点も重要でしょう。
　シラバスの表を少し書き換えて以下のようにしても判定網羅は満たされますが、条件網羅は満たされていない（条件AがFalseの場合がカバーされていない）ですね。

#ABA and B
1TrueTrueTrue
2TrueFalseFalse

2.4　改良条件判定カバレッジテスト

　対応するコードカバレッジは、改良条件判定カバレッジ（MC/DC）です。そのままですね。

定義が難解

　それにしても、シラバスの以下の文章は理解が難しいです。

N個の一意な不可分条件を想定した場合、MC／DCは通常、N+1個のテストケースで実現できる。MC／DCは判定条件カバレッジを達成するが、次の要件も満たす必要がある。
  1. 不可分条件Xが真になると判定結果が変わる1つ以上のテスト
  2. 不可分条件Xが偽になると判定結果が変わる1つ以上のテスト
  3. 各不可分条件に、上記の要件1と要件2を満たすテストが存在する。

　かみ砕いていうと、「その条件の真偽値が変わることで判定全体の真偽値が変わる」場合、そのテストケースはやっておけということ。裏を返すと、「その条件の真偽値が変わっても判定全体の真偽値が変わらない」のであれば、そのテストケースはやらなくていい（判定網羅を満たす範囲であれば）。

　TechMatrix社のページには以下のようにあります。こちらの1.は判定網羅、2.は条件網羅なので、シラバスの3つの項目が、3.の1文にまとめられていることになります。

DO-178Bに従うと、完全な(100%の)MC/DCカバレッジを得るには、次の3つの条件を満たす必要があります。
  1. 各「判断文」が、少なくとも1回すべての可能な結果を得ている。
  2. 1つの「判断文」中の各条件が、少なくとも1回すべての可能な結果を得ている。
  3. 1つの「判断文」中の個々の条件が、単独で全体の「判断文」の結果を左右する。

www.techmatrix.co.jp

具体例

　シラバスに示された、MC/DC=100%の例で確認してみましょう。

#ABC(A ∨ B) ∧ C
1TrueFalseTrueTrue
2FalseTrueTrueTrue
3FalseFalseTrueFalse
4TrueFalseFalseFalse
  • 条件A・B・Cが、TrueとFalseの両方の値をとるテストケースがある（条件網羅）
  • 判定結果 (A or B) and C が、TrueとFalseの両方の値をとるテストケースがある（判定網羅）
  • テスト1はAがTrueで判定がTrue。テスト3ではAだけをFalseに変えて、判定がFalseになっている。
  • テスト2はBがTrueで判定がTrue。テスト3ではBだけをFalseに変えて、判定がFalseになっている。
  • テスト1はCがTrueで判定がTrue。テスト4ではCだけをFalseに変えて、判定がFalseになっている。

　確かに、満たされているようです。

どうやって導出するのだ？

　さて、ではどのようにMC/DCを満たすテストケースを導出するのか。シラバスには書かれていません。「MC/DCは通常、N+1個のテストケースで実現できる」の根拠もわかりません。
　ネットを調べてみても（論文は調べていません！）、「これはMC/DC100%のテストケース群ですよ」といきなり「答え」が出ているものばかり。TechMatrix社のツールではMC/DCのカバレッジ分析ができるとのことなので、論理的に導出できるのではないかと思うのですが・・。。

　唯一希望を持てるのは、キャッツ株式会社のWebサイトで読める「ZIPC WATCHERS Vol.13」の記事「組込みソフトウェア開発課題への挑戦～網羅度～」（PDF）です。ここに以下の記述があります。

MC/DCテストケースを最小化する方法、MC/DCランダムテストに確率値誤差逆伝播法（バックプロパゲーション）を用いる方法については、別稿で述べる。→リンク先：松本

　でも「リンク先：松本」が見つからない・・・。
　と言いますか、ん？ バックプロパゲーション？ ディープラーニングでちらっと勉強したあれ？ 気になりすぎるのですが、とりあえず発見できませんでした。

導出方法を勝手に考えてみる

　ここからはあまり根拠のない話なので、冷やかし程度で読んでください。

　先の記述の、「ランダム」「最小化する」という言葉を見るに、MC/DCの場合は論理的に導ける唯一解があるわけではなく、何らかのランダム性を入れて、そこから最小な群を見つけていくアプローチなのでは、と想像しています。

　では自分なりにその方法を考えてみましょう。

　まずOR文。「または」なので、2つ以上の条件がTrueの場合、どれが独立にFalseに変わっても、OR文全体の結果は変わりません。
　次にAND文。「かつ」なので同様に、2つ以上の条件がFalseの場合、どれが独立にTrueに変わっても、AND文全体の結果は変わりません。
　よって、テストケース削減の方針として、以下2つを挙げることができるでしょう。

  • 方針1: OR内で複数条件がTrueになっているテストケースは省略する
  • 方針2: AND内で複数条件がFalseになっているテストケースは省略する

　では、シラバスの例である (A or B) and C について考えてみましょう。真理値表は以下の通りです。

#ABC(A ∨ B) (A ∨ B) ∧ C
1TrueTrueTrueTrueTrue
2TrueTrueFalseTrueFalse
3TrueFalseTrueTrueTrue
4TrueFalseFalseTrueFalse
5FalseTrueTrueTrueTrue
6FalseTrueFalseTrueFalse
7FalseFalseTrueFalseFalse
8FalseFalseFalseFalseFalse

　方針1から、AとBが両方Trueになっているテスト1と2を落とします。次に方針2から、(A ∨ B)とCが両方Falseになるテスト8を落とします。
　残るのはテスト3・4・5・6・7です。

　テスト3とテスト7は、条件Aを反転することで結果が反転しています。
　テスト4とテスト3は、条件Cを反転することで結果が反転しています。
　テスト5とテスト7は、条件Bを反転することで結果が反転しています。
　テスト5とテスト6は、条件Cを反転することで結果が反転しています。 　

　条件Aの反転と条件Bの反転のために、テスト3・5・7は必須。あとは条件Cのために3・4を選ぶか、5・6を選ぶか。
　シラバスでは前者の3・4・5・7のパターンになっていますが、3・5・6・7でもMC/DCを満たしているといえるのではないでしょうか。なお、判定条件網羅はともに満たしています。

■シラバスの解

#ABC(A ∨ B) ∧ C
3TrueFalseTrueTrue
4TrueFalseFalseFalse
5FalseTrueTrueTrue
7FalseFalseTrueFalse

■別の解

#ABC(A ∨ B) ∧ C
3TrueFalseTrueTrue
5FalseTrueTrueTrue
6FalseTrueFalseFalse
7FalseFalseTrueFalse

　自力の導出方法として、この程度が限界でした。何かスマートなやり方あるんだろなあ。
　長くなってきたので、第2章の残りは別途。

#JaSST '18 TokyoのMicco氏のチュートリアルを復習し、少しデータで遊んでみる

テスト実行 テスト管理 イベント

　GoogleのテストマネージャーであるJohn Micco氏の、Flakyなテストについてのチュートリアルの内容は、こちらに書き尽くされています。なので、あらためてその復習記事を書くことはないのだけれど、SQLの勉強も兼ねて、要点を絞って振り返っておきます。

nihonbuson.hatenadiary.jp togetter.com　

　Micco氏のお話の要点は、以下の2つだとわたしは考えています。

  1. 自動テストが膨大になると、効率よい順番で実行したり、適切に間引いたりすることが重要である。
  2. シンプルな記録であっても、積み重ねればさまざまな洞察を導くことができる。

　この記事では、上述の2つを踏まえてチュートリアルを振り返るとともに、せっかく権限をもらったGoogleさんのログで、少し遊んでみたいと思います。

膨大な自動テストの効率を上げるには

　Micco氏の資料*1によると、Googleで継続的に実行されている420万件あり、1日あたりテスト実行が150万回とのこと。
　一方、バグが見つかるのはわずか1.23%のテストだけ。膨大なリソースを使うことから、テストを効率的に実行することが求められます。

　テスト結果を分析する中で、Micco氏はテストの結果の遷移（transision）に注目。過去にpassしていたテストがある時点でfailに変わるネガティブな遷移は、テストがflaky（あてにならないもの）であることが原因の1つであることがわかりました。flakyなテストについて、スライドでは以下のように述べられています。

  • flakyなテストとは、同じコードであるにも関わらず、passになったりfailになったりするテストのこと。
  • 420万件のテストのうち、16%が何らかのflakinessをもっている。
  • flakyなテストの結果の確認に、開発者の時間が浪費される。そのため開発者は無視しがちだが、その判断が誤っていることもある。
  • flakyなテストの(再)実行のために、2～16%の計算リソースを使っている。
  • flakyなテストは、進捗を阻害したりリリースを遅らせたりする。

　この無駄を減らすことが、自動テスト実行の効率改善の大きな助けになるというのがモチベーションです。　

Flakyなテストを見つけるには

　チュートリアルで教えてもらったのは、どのようなデータをどう使って分析しているか、ということです。

どんなデータを使う？

　実はこの目的に必要なデータベースは、次のシンプルな2つのテーブルです。targetsはテストケース、resultsはテストケースの実行結果と、ざっくり捉えてよさそう。

■targets

idINTEGERREQUIRED テストのID
targetSTRINGREQUIRED テストケース（のディレクトリパス。これでテストが一意に決まっているようだ）
flagsSTRINGREQUIRED テスト環境などの情報をフラグ化したものの組み合わせ

■results

target_idINTEGERREQUIRED テストのID
changelistINTEGERREQUIRED プログラム変更リストのID
resultSTRINGREQUIRED 実行結果
timestampTIMESTAMPREQUIRED タイムスタンプ

　resultsテーブルの「result」に入るのはテストの結果で、以下のようなものがあります。一部内容を聞いていないものもあります。

  • AFFECTED_TARGET
  • PASSED: 成功
  • SKIPPED
  • FAILED_TO_BUILD: コンパイルできずチェックイン不可
  • FAILED: 失敗
  • INTERNAL_ERROR: テストを開始する前提が満たされなかった。テストインフラの問題
  • PENDING: 実行開始できなかった
  • FLAKY: 一度のテストの中で、初めは失敗したが、リトライで最終的には成功したもの
  • ABORTED_BY_TOOL: 実行時間の閾値15分オーバーによる実行停止
  • FORGE_FAILURE
  • BUILD_TIMEOUT
  • PROHIBITED
  • BLACKLISTED

　このように結果を細かく分けることで、テストの問題なのか、インフラの問題なのかを切り分けやすくし、開発者とテストインフラチームがお互い時間を浪費しないように工夫しています。

　わたしのチームでもテスト失敗の要因は区別していて、自動テストインフラのどこに改善ポイントがあるのかがわかるようには、一応しています。
　プロダクトのバグ起因、自動テストケース起因、テスト環境起因、人の凡ミス、前のテストの影響が残ってしまった、などなど。
　Googleとの大きな違いは、この分類を、ほぼ人がやっているということで・・・スケールしないですね。

結局flakyって？

　チュートリアルの中では、flakyを2つの意味で使っているように感じました。
　1つ目はテスト結果の種類としてのもので、「1回のテスト実行の中で、最初は失敗したが、リトライで成功している」ことを指しています。2つ目はテスト結果の変化の種類としてのもので、「ある時に成功したが、次の実行の際には失敗した」ことを指しています。
　でもこの2つって本質的には同じで、結果の変化が1回のテストの中で起こったか、2回のテストの中で起こったかの違いだけなんですね。

　よって現時点では単純に、「同じコードで同じ結果を期待しているのに、結果が変わってしまう」ものだと捉えています。

遷移するテストを見つける

　チュートリアル最初は、resultsのレコード件数は？みたいなシンプル過ぎる練習クエリを投げていたのですが、遷移するテストを特定するクエリから、以下のようにややこしくなってきます。（MiccoさんのGitHubから引用しています）。

　以下読み解いてみますが、解釈が間違っていたり言葉遣いがおかしければご指摘ください。
　まず、WITH句で、サブクエリ「result_values」を生成しています。resultsテーブルを並び替えたもので、こんな感じ。*2

Rowrowtarget_idchangelistresult
2602601100515424AFFECTED_TARGET
2612611100518994AFFECTED_TARGET
2622621100519320AFFECTED_TARGET
2632631100520152AFFECTED_TARGET
2642641100522728PASSED
26512100005012AFFECTED_TARGET
26622100020333AFFECTED_TARGET

　PARTITION BYによって、target_idごとにレコードを区分し、changelistでソートしたうえでrow列でナンバリングしています。
　「区分」されているため、target_idが変わるとナンバリングが1から再スタートするというところがポイントです。264行目まで増加していたrowが、265で1に戻るのはそういうわけです。

　WITHが終わった後のSELECTでは、上で作ったテーブル result_valuesを、自分自身と結合します。結合の条件は、①target_idが一致している ②rowが1個ずれている。
　target_idとrowを指定すればレコードは一意に決まりますね。上のテーブルだと、たとえばRow260をRow261と、Row261をRow262と、1行ずらしで順に結合していくことになります。イメージ的には、以下。

changelistresultchangelistresult
100515424AFFECTED_TARGET100518994AFFECTED_TARGET
100518994AFFECTED_TARGET100519320AFFECTED_TARGET
100519320AFFECTED_TARGET100520152AFFECTED_TARGET
100520152AFFECTED_TARGET100522728PASSED

　WHERE句で、resultが一致していないものを抽出すると、1番下の行だけが残ります。これって、「あるテストと次のテストで結果が違う」、つまり遷移を表していますね。さらにこれをtarget_idでグルーピングして、遷移が4回以上起きているものを残す。とこういうことをしていたんですね。
　まあややこしかったけれど、遷移がよく起きるテストケースを特定することができました。

Rowtarget_idtransition_count
184818481
229299458
370376429
471932425
592007416

遷移の歴史を見抜く

　さて次の問題は、「flakyに見えるけれど実はflakyじゃなかった」遷移をどのように見抜くか、ですね。

　1つの仮説として、それぞれのテストのflakyさ≒遷移のパターンは、独立しているはずです*3 。逆に、複数のテストが同じような遷移の履歴を示すのであれば、それはテスト以外のものに由来する問題である可能性が高い。Micco氏はそのよ１うな現象の原因として、サブシステムやライブラリの問題を挙げていました。
　テスト自体がflakyなわけではないことが明確になれば、テストインフラ側の問題として引き取ることで、開発者の調査の工数を減らせそうです。

　まず事前準備として、先ほどのクエリを少し変えて、以下のようなテーブル「target_transitions」を作っておきます。遷移が起こった際のchangelistとtarget_idの組み合わせ表です。

Rowchangelisttarget_id
110000000117341
210000000128661
3100000001183752
4100000001228506
5100000001259831

　このテーブルに対し、以下のクエリを投げる。

　ざっくりいうと、target_idでグルーピングしたうえで、そこに紐づくchangelistをarray_agg関数で配列にしている。結果がこれです。

Rowtarget_idchangelists
1424100437692
100437728
100446646
100452444
1434100031939
100036158

　上の表でいうと、(424, [100437692, 100437728, 100446646, 100452444]) みたいになっているってことですね。つまり、「テストケース、遷移歴」のテーブルになっているってことですよ。
　この遷移歴が一致するテストケースが多ければ、その遷移・flakyさは、テスト自体と違うところに起因する(可能性が高い）といえるわけですね。
　この結果から、遷移する22,760のうち、1,610が遷移歴を共有していることがわかりました。これらはFlakyではないと判断できそうです。

Google先生のデータで遊ぶ

　さて、シンプルなデータですが、いろいろできそうな気もしますよね？
　少しだけ遊んでみました。

遷移回数を正規化する

　上で出た「flaky_tests」テーブルですが、内容は「target_id」（テストケース）と、「transision_count」（遷移回数）です。でもこれだと、実行回数が多いテストと少ないテストを公平に比較できないのでは？と考えるのが自然ですよね。
　実行回数はすぐ得られるので、遷移回数/実行回数 で正規化してみましょう。
　クエリはこんな感じか・・・？

Rowtarget_idexecution_counttransition_countflake_ratio
14956292068.97%
27764441636.36%
38881892224.72%
4545421419.05%
56792891617.98%
6434132518614.04%
76456132517212.98%
86031125414811.80%
98769102411210.94%
102468154414809.59%
11407389808.99%
12593745408.89%
1369021691408.28%
147811307118005.86%
1549018484004.72%
161529262912204.64%
17709189404.49%
187367280610103.60%

　さっき1位だった434は6位に、2位だった7811は14位に、3位だった6456は7位に。ランキングはそれほど変わらないかな？

Googlerの人たちのホワイトさを調べる

　テストと結果のテーブル以外に、「TensorFlowCommits」というコミット履歴のデータがありました。どんな言語でよくfailするのかを、修正対象となったファイルの拡張子から判断したりしています。
　チュートリアルで、「誰がよくfailを引き起こしているのか」という分析もあったのでですが、「いや、むしろ何時ごろの修正がfailを引き起こすのか、の方が面白いのでは！？」と。ただ残念ながら、コミット履歴のテーブルの一部が匿名化されており、またテスト結果のテーブルと結合できるキーもないため・・・、一気にスケールダウンし、「googlerは何時にコミットしているのか」を見てみましょう。クエリはたぶんこんな感じ・・・。

　この結果をグラフにすると、こう。いきなりExcelですけれど。

workingHour

　7時ごろに急に立ち上がりはじめ、昼前にピークを迎え、昼休憩をとった後16時ごろにもう一度ピークを見せて、17時ごろから急減。
　ただ、意外に、夜中働いていらっしゃる・・・。人間以外のコミットがあったりする、のでしょうか？*4

まとめ

　基調講演やチュートリアルで学んだことは、膨大なテストの効率的な実行が必要だけれど、ヒントはシンプルなデータの中からも得られる、ということでした。
　何億件というデータはGoogleならではですが、使っている情報も、ロジックも、とてもシンプルと言えるのではないでしょうか。
　自動テストはログの蓄積と相性がいいので、自分なりのメトリクスを考えるのは楽しそうですし、効果も見込めそうなので、仕事の中で何か見つけてみたいと思っています。
　Miccoさん、ありがとうございました！ 謝謝！

*1:The State of Continuous Integration Testing @Google (pdf)

*2:実際は「AFFECTED_TARGET」は除外されている。

*3:実際のところ、20回同じタイミングで遷移するような組み合わせは、わずか2つしかなかったそう。

*4:@nihonbuson さんに、「多拠点開発だからなのでは？」とのご指摘いただきました。なるほどー。

JSTQB-TTAシラバスのお勉強 ─ 第1章「リスクベースドテスト」

テスト分析 資格

JSTQB-TTAシラバスのお勉強 ─ 第1章「リスクベースドテスト」　ISTQBのAdvancedレベル「テクニカルテストアナリスト」のシラバス日本語訳が出ました。いつ試験が行われるかは微妙なところですが、シラバスの紹介をしてみます。

テクニカルテストアナリストとは何なのか

　実は、ISTQBで定義されているロールの体系を見ても、定義を見つけることはできませんでした。この絵でいう「CORE」で、Advanced Level (AL)はFoundation (FL)の上位に位置付けられており、以下の3つから成っています。

  • Test Manager (テストマネジャー、TM)
  • Test Analyst (テストアナリスト、TA)
  • Technical Test Analyst (テクニカルテストアナリスト、TTA)

　テストマネジャーは一番わかりやすいでしょう。テストの計画・進行・管理・分析を行うロールですね。
　テストアナリストにもマネジメントの知識は要求されますが、どちらかといえばテストマネジャーに対して情報をインプットするという側面が強い。いわゆるテスト技法を駆使したテスト設計であったり、テストツールの導入であったりが仕事の中心と見なされています。

　テクニカルテストアナリストは、（ぱっとシラバスを読んだ限りでは）よりホワイトボックス的な色合いの強いロールのようです。シラバスでは、コードカバレッジや、静的/動的解析が章立てされています。また品質特性については、機能性やユーザビリティなど「ユーザが直接意識する」部分をTAが見るのに対し、TTAはどちらかといえばユーザがあまり意識しない、保守性やセキュリティなどに責任を持つことになっています。第4章の「品質特性」でも明らかになりますが、TTAは開発者側が意識すべき内容が多くなっています。

2018/3/21追記

　確かに、TTAについては、こちらの「概要」にきちんと説明がありました！ 足元がおるすになってますよ。
　TTAの「ビジネス成果」から引用してみましょう。

Advanced Levelテクニカルテストアナリストは次のビジネス成果を達成できる。
TTA1: ソフトウェアシステムの性能、セキュリティ、信頼性、移植性、保守性に関連付けされる代表的なリスクを認識し、分類する。
TTA2: 性能、セキュリティ、信頼性、移植性、保守性のそれぞれのリスクを軽減するためのテストの計画、設計および実行を具体化したテスト計画を策定する。
TTA3: 適切な構造テスト設計技法を選択し適用する。コードカバレッジおよび設計カバレッジに基づいて、テストが適切なコンフィデンスレベル（確信度合い）を提供することを確保する。
TTA4: コードおよびアーキテクチャ内の代表的な間違いに関する知識を、開発者およびソフトウェアアーキテクトとのテクニカルレビューに参加することで効果的に適用する。
TTA5: コードおよびソフトウェアアーキテクチャ内のリスクを認識しテスト計画要素を作成して、動的解析を通してこれらのリスクを軽減する。
TTA6: 静的解析を適用することで、コードのセキュリティ、保守性および試験性への改善を提案する。
TTA7: 特定の種類のテスト自動化を導入することから想定されるコストおよびメリットを概説する。
TTA8: テクニカルなテストタスクを自動化するために適切なツールを選択する。
TTA9: テスト自動化の適用における技術的な概念や課題を理解する。

　9つ中4つに「コード」という言葉が出てくること、またTAに比べて自動化がより詳細になっていることがポイントかと思います。
　上に書いた通り、より実装に近いところにフォーカスされている印象です。

1. リスクベースドテストにおける、テクニカルテストアナリストのタスク

　それでは、今回は第1章を見ていきましょう。まず、リスクベースドテストとは何だったでしょうか。
　用語集での定義は以下の通りです。

リスクベースドテスト（risk-based testing）
プロジェクトの初期段階からプロダクトリスクのレベルを低減させ、ステークホルダにその状態を通知するテストの方法。プロダクトリスクの識別の他、テストプロセスをガイドする際のリスクレベルの活用もこれに含まれる。

TMでも出てくる言葉なので、軽くこちらのエントリも覗いていただければ。

www.kzsuzuki.com

　識別・評価（アセスメント）・軽減というタスクについてはTMと同じですが、TTAは「技術的なリスクについて」の知識の提供が期待されています。
　ALの3つのロールでいうと、ざっくり分けてTMがプロジェクトリスク、TAとTTAがプロダクトリスクの深堀りをすると考えるとわかりやすいでしょう。

　例として挙げられているリスク例は以下です。

  • 性能リスク（例：高負荷状態では応答時間を達成できない）
  • セキュリティリスク（例：セキュリティ攻撃による機密データの漏えい）
  • 信頼性リスク（例：アプリケーションがサービスレベルアグリーメントで規定された可用性を満たせない）

　リスクの識別や評価については、特に目新しいことは書かれていません。専門家へのインタビューや有識者レビューを通じてリスクを洗い出そうとか、発生確率と影響度を評価しようといった一般論です。

Rex Blackさんの説明

　さて、これはプロジェクト管理でなくテストの話なので、テストを通じてこれらのリスクを低減する必要があります。そのリスクに応じてテストの優先度を決めるのが、リスクベースドテストです。

　リスクベースドテストの提唱者であるRex Black氏の資料、Risk-Based Testing - What It Is and How You Can Benefit（pdf）を見てみましょう。
　この資料では、リスクベースドテストの長所が以下のように述べられています。

  • リスクの高い順番にテストを行うことで、深刻な欠陥から順に見つけていける可能性を最大にできる。
  • テストの工数をリスクに基づいて割り当てることで、リリースまでに残った品質リスクをもっとも効率的に最小化できる。
  • テストの結果をリスクに基づいて測ることで、テスト実行期間中にどれだけのレベルの品質リスクが残っているかを組織が把握し、適切なリリース判定を行うことができる。
  • スケジュール上必要であれば、リスクの低い順からテストを割愛することで、品質リスクの増加を最低限に抑えながら、テスト実行期間を短くすることができる。

　このスライドを見ると、品質リスク項目とその品質特性を並べて、それぞれについて発生確率と影響度を記入しています。リスクベースドテストを紹介している他のサイトでは、縦軸に機能モジュールを並べているものもあります。機能×品質特性で、それぞれどんな品質リスクがあるかのマップを作るとわかりやすいでしょう。

たとえば

　例として、「外部I/Fの変更と機能追加の影響で、性能が劣化するリスクがある」ケースを考えてみましょう。
　まず発生確率について、プロジェクト開始当時は「非常に高い」だったとしても、初期段階でのプロトタイプ評価により思ったほど性能影響がないことがわかれば、「中程度」に変更されます。
　影響について、プロジェクト内部で定めた性能目標値を達成していなかったとしても、ユーザはまったく気にしないかもしれません。あるいはシステム全体の前提を満たせなくなり、リリース自体が不可能になるかもしれません。
　「性能が劣化する」と一言で言っても、その度合いによって確率も影響も異なるので、ものによっては別のリスクとして扱うのがよいでしょう。

　リスクの高いものから順に、対応するテストケースを消化していくことになりますが、そのテストケースも有限なので、リスクがゼロになることはありません。許容される工数と時間内で、受け入れられる程度にまでリスクを低減できたかを判断することになります。

機械学習の分野でも注目される、メタモルフィックテスティングとは何か。

とは何か テスト設計・技法 機械学習

　先日のJEITAのイベントで、メタモルフィックテスティング（Metamorphic Testing、MT）というものを知り、「誰かMetamorphic Testingの勉強会やりませんか？」とブログに書いたところ、ソフトウェアテスト・ヒストリアンの辰巳さんが資料をたくさん紹介してくださいました。ちなみに、一緒に勉強してくれる人は誰もいませんでした。

www.kzsuzuki.com

　ICSE MET'2017のサイトにも、MTについてのスライドがたくさん掲載されていたので、学んだところを紹介してみたいと思います。
　日本語の論文も無償で見られるものがいくつかあるのですが、どちらかといえばMTについての知識は前提として、それを機械学習にも応用してみたという内容なので、基本を学ぶには敷居が高そうです（論文だから当たり前か・・・）。

メタモルフィックテスティングの概要

　まず、Chris Murphy氏の『Applications of Metamorphic Testing』(ppt)が一番わかりやすいです。スライド終盤のサマリには、以下のようにあります。

  • MTは、既存のテストケースから新しいテストケースを生成する手法である。
  • テストオラクルのないアプリケーションにおいて、バグ検出の役に立つことがある。
  • ソフトウェアのメタモルフィックプロパティ(metamorphic property)に強く依存する。

    • 　一つずつ、見ていきましょう。

    なぜテストケースを増やす必要があるのか。

    　「新しいテストケースを生成する」理由は何でしょう。
    　境界値分析や組み合わせテストといったテスト技法は、テスト空間を論理的に絞り込み、効率的にテストケースを減らすための技術でした。なぜあえて、テストケースを増やすのか。
    　このスライドでは「だって、テストケースは多ければ多いほどいいだろう？」とあります。手動テスト中心のテスターが聞くと吐血しそうな意見ですね。

    　たとえばこちらのICSTの論文『Metamorphic Model-based Testing of Autonomous Systems』(pdf)では、ドローンの飛行や障害物回避のシミュレーションプログラムにMTを応用した例が載っています。ドローンの出発地点と到着地点、その経路にある障害物には無数のパターンがあるので、ある特徴的なテストケースをいくつか通すだけでなく、そこから大量のテストケースを派生させて、プログラムの妥当性を検証することが有効なのですね。

    テストオラクルってなんだっけ？

    　テストオラクル（Test Oracle）などという用語を使うのは、I/JSTQBで学んだ界隈の人だけだと思っていましたが、MTの文脈では当然のように使われている言葉です。
    　ISTQB用語集に追加された日本語検索機能をさっそく使ってみましょう！ 使い方は、湯本さんのnoteから！

    note.mu

    テストオラクル（test oracle）
    テスト対象のソフトウェアの実行結果と比較する期待結果のソース。オラクルは、実在する（ベンチマーク用の）システム、他のソフトウェア、ユーザマニュアル、個人の専門知識の場合があるが、コードであってはならない。

    　テストオラクルがないというのはつまり、「どういう出力なら正しいのか」がよくわからない状況ということですね。

    メタモルフィックプロパティとは？

    　「メタモルフィックプロパティ」（Metamorphic Properties）とは一言でいうと、対象とするソフトウェアが備えている「性質」のことです*1。MTでは、この性質から多くのテストケースを導出することを目的としています。

    　それってプログラムの仕様そのもの、あるいはそれを変換した高位レベルテストケースのことでは、とも思いませんか？ 一般的なテスト技法でテストケースの絞り込みを行わなければ、テストケースはいくらでも追加できそうなものです。
    　たとえば、「12歳以上は料金1,000円」という仕様からは、入力である年齢を12歳、13歳、14歳、・・・とし、出力が「1,000円」となることを確認するテストケースがどんどん作れます。

    　ですが、メタモルフィックプロパティはもっと別のものです。
    　わたしは、「プログラムの仕様として定義するまでもない、自明な性質」と解釈しています。

    メタモルフィックプロパティの具体例

    数値リストから最小値を求めるプログラム

    　抽象的な話になってきたので、先の資料から具体例を引用します。
    　整数のリストの中から最小値を得る関数 findMinを、以下のように書くとします（バグがあります）。

    　「2、1、4、3」というリストを入力にすると、期待値（つまり最小値）は「1」になる、というテストケースは、以下のように表現することができます。

    { {2, 1, 4, 3}, 1}

    　さて、このプログラムが持つべきメタモルフィックプロパティには、どういうものが考えられるでしょうか。
    　それはたとえば、「リスト内の数字を並び替えても、出力値（最小値）は同じになる」という性質です。このような性質は、おそらく外部仕様として明示されない、「自明な」性質ということができるでしょう。

    　この性質に従ってテストケースを生成すると、

    { {4, 2, 3, 1}, 1}

    というテストケースが通らないことがわかり、バグを検出することができます。

    形式的な表現をしてみると

    　少し形式的に表現してみましょう。
    　プログラムfに対する元のテストケースを {x, f(x)} と表現します。

    　元のテストケースの入力値を関数tに通すと、新しい入力値はt(x)、プログラムfからの出力値はf(t(x))となります。
    　一方、元のテストケースの出力値を関数gに通すと、新しい出力値はg(f(x)) となります。
    　プログラムfのメタモルフィックプロパティとは、すべての入力値xに対して、f(t(x))=g(f(x))を満たすような関数ペア(t, g)のこと。文字列だと全然わからないですね・・・。

    　先のfindMinの例では、関数tは「リスト要素の並び替え」に相当します。出力値の方は変わらないことを期待しているので、関数gは恒等関数になるでしょう。入力に「リスト要素の並び替え」という操作を行っても、出力値は変わらないというのが、findMinのメタモルフィックプロパティです。

    一般的にはどんなプロパティがある？

    　一般的に、どんなメタモルフィックプロパティがあるのでしょうか。P.22からその例が書かれています。
    　元のテストケースが「要素a～fの総計がsになる」というものだったとして、

  • Permute: 並び替えを行っても総計はsと変わらない
  • Add: 各要素に定数を足すと、総計は s+定数*6 になる
  • Multiply: 各要素に定数を乗じると、総計は s*定数 になる

    • といったものがメタモルフィックプロパティとなります。これはだいぶ単純というか・・・数学以外には適用できそうにない、退屈な性質ですよね・・・。
    　もう少し違うタイプとして、以下のようなものが紹介されています。

  • Noise-based: 出力に提供を与えないであろう入力（の変化）
  • Semantically Equivalent: 意味的に「同じ」入力。
  • Heuristic: 元に「近い」入力。
  • Statistical: 統計的に同じ性質を示す入力。

    • 数値計算分野以外での応用

    　メタモルフィックプロパティが上で紹介したようなものばかりだと、MTは数値計算関連のプログラムにしか応用できないのではと思いますが、Zhi Quan Zhouさんの講演『Metamorphic Testing: Beyond Testing Numerical Computations』(pdf)によると、数値計算関連分野での適用は全体の4%でしかないそうです*2。

    　この講演で紹介された適用例は、プログラム難読化ツール*3。
    　難読化ツールのメタモルフィックプロパティには、たとえば以下のようなものがあります。

  • 同じソースコードを入力するといつでも、動作的に等価なプログラムが出力される。
  • 一つのソースコードに対し繰り返し難読化を何度かけても、動作的に等価なプログラムが出力される。

    • 　こういったプロパティを利用して、一般的なテストでは必ずしも検出できないバグが、MTであれば検出できるという例を示しています。

    　また、オンライン検索での例も紹介されています。一口にオンライン検索といっても、GoogleのようなWebサイトの検索、ホテルや飛行機の空き状況、商品、用語、地図など無数にありますが、これらに共通して言えそうなメタモルフィックプロパティがあります。

    　まず一般的な（general）メタモルフィックプロパティとして、以下が考えられます。

    「AがBに包含されている」という関係が成立しているなら、
  • Aの結果はBの結果の部分集合になる
  • Aの結果の数は、Bの結果の数以下になる

    • 　この2つ目のプロパティから導出できる具体的な（concrete）プロパティは、たとえば店舗検索において、

    検索する地域を絞ることで、ヒットする結果は絞る前より少なくなる

    というものが考えられます。このメタモルフィックプロパティを利用してテストケースを生成し、妥当性を確認することができます。

    まとめ

    　引用した資料に明確に書かれているわけではないのですが、生成されるテストケースが常に「期待値付き」であることが非常に重要だと思います。いくら大量にテストケースを生成したとしても、それが期待値なしであればあまり役に立ちませんし、自動化もできません。

    　テスト技法といえば、テストケースを合理的に選択することと思いがちでしたが、「とにかくたくさんのテストパターンが欲しい」「でもテストオラクルがない・・・」という状況において、有効だが数が少ないテストケースから、期待値付きのテストケースを大量に派生させる技術として、メタモルフィックテスティングが有望な技術だということがわかりました。

    *1:他の資料では、「メタモルフィック関係」（Metamorphic Relations、MR）という用語も出てきますが、どうやら同じものを指しているようです。

    *2:Chris Murphyさんの資料では、実際の応用分野として、生物情報学、機械学習、ネットワークシミュレーション、コンピュータグラフィックスなどがあるとのこと

    *3:クラッカーなどに重要なシステムの内部情報を与えることを防ぐためのプログラム。obfuscator。

    「ソフトウェアエンジニアリング技術ワークショップ2017 ～人工知能ブームの中でのソフトウェアエンジニアリング～」に参加

    イベント 機械学習

    　2017年12月15日(金)に、JEITA（一般社団法人 電子情報技術産業協会）の「ソフトウェアエンジニアリング技術ワークショップ2017」に参加してきました。プログラムなどはこちらをご覧ください。
    　テーマは「人工知能ブームの中でのソフトウェアエンジニアリング」。とても勉強になった催しでしたので、許される（であろう）範囲でシェアしたいと思います。

    　なお、わたしはディープラーニング初学レベル以下です（堂々）。講演者の方のご発言の趣旨を正しく理解できず、間違った要約をしてしまっているかもしれません。申し訳ありませんが、その際はご指摘いただければ修正・削除いたします。

    基調講演: 機械学習工学に向けて

    　株式会社Preferred Networksの丸山宏さんの基調講演では、機械学習の概要や潮流について、幅広くお話しいただきました。どちらかといえば、機械学習のすばらしさよりも、限界や注意点に重点を置かれているように感じました。

    ディープラーニングが合うもの合わないもの

    　演繹的な「モデルベース開発」と、帰納的な「モデルフリー開発」、という言葉がありました。
    　銀行のトランザクションにように、人間が定義したルールに従って動くシステムは前者。複雑すぎてルールが書き下せないようなものに後者を適用とするというお話です。 後者の開発においては、十分な精度が出るかはやってみないとわからないため、Expectation Controlと、アジャイル的なアプローチ・PoCが必須との注意点もありました。

    　品質の判断として、これまでは「レビュー工数」のようなプロセス指標で測定していたところを、ディープラーニングのシステムにおいてはプロダクト自体の性能（判定精度）で示せるのが大きな違い、とのお話がありました。ただ個人的には、「正確に判定できる」というのは品質特性の1つでしかないので、それだけとって「品質を定量的に示せる」とするのは物足りないと感じます。

    機械学習に基づくソフトウェアの難しさ

    　技術的な難しさとして、要求定義と品質保証について言及がありました。
    　要求定義の難しさは、いわゆる「フレーム問題」と呼ばれるもので、ハイコンテキスト前提の人間の指示を、ソフトウェアがパーフェクトに忖度することはできないという点です。
    　品質保証の難しさは、ディープラーニングにおける「何かを変えるとすべてが変わってしまう」（Changing Anything Changes Everything）性質に由来するものです。この性質のもとでは、ユニットテストを定義することさえ困難であるということです。また、adversarial exampleのような新しいタイプの脆弱性が生まれていることも、保証の難しさにつながります。

    　またビジネス面の難しさとして、「100%のものはできない」ということに対する社会的な受容が必要ということです。同様の話は、SQiP2016における、デンソーの早川浩史氏のご講演「つながるクルマのセーフティ&セキュリティ」でもあったと記憶しています。そもそも現在のソフトウェアだって完璧なものではないことは明らかなのですが、「ディープラーニング/自動運転車は判定を間違うこともある」ことを社会が受け入れ（あるいは麻痺し）なくてはなりません。

    統計を勉強しよう

    　ソフトウェアエンジニアに必要な知識として統計、特に事前確率などベイズ統計の基本的な知識を挙げていました。
    　質疑応答では、ソフト屋は統計を知らないといった論調があったように思いますが、割とみなさん統計好きですよね？ 僕はそうでもありませんが・・・特に自由ｄ・・・うっ頭が・・・。

    所感

    　機械学習のニュースやトレンドをきちんと追っている人には当たり前のお話だったのかもしれませんが、特徴や注意点などの概要をお聞きすることができて有益でした。また、今後テストがますます難しくなっていくことがよくわかりました。
    　こんな話もありましたね・・・これも、Changing Anything Changes Everythingの一種だと思います。

    itpro.nikkeibp.co.jp

    AIによるソースコードレビューの変革

    　富士通アプリケーションズ株式会社の森崎雅稔さんによる、「AIでソースコードの良しあしを判定する」お話です。Twitterでも話題になりましたね。ニュース記事はコチラ。

    itpro.nikkeibp.co.jp

    何をやっているのか

    　記事を読んだだけでは、従来のソースコード解析との違いがよくわからなかったのですが、かなり別ものでした。この技術ではコードの文法や意味を理解させるのではなく、コードを画像のパターンとして認識させて、良い/悪いの判定を行っているのだそうです。
    　ここでの判定は「バグの有無」ではなく、保守性や可読性といった内部品質の良しあしです。ただ経験則的に、内部品質が悪いコードを書く人は、バグを作り込むことも多いという相関があり、悪い判定はそうズレないとのことでした。

    　なお、単純に画像化するだけでなく、レビューエキスパートの観点が反映される工夫をしています。
    　たとえば、いわゆる「複雑度」といえばネストの深さなどで計算されますが、そういう制御構造以外にもレビュアが「複雑でレビューしづらい」と感じるコードの特徴があるので、そういう特徴がうまく画像パターンに現れるようにしているということです。
    　ディープラーニングといえば、学習用の加工だけして後は機械に学習させるというイメージを持っていたので、これは意外でした。

    運用面での工夫・苦労

    　今回紹介された技術は、少なくとも現時点では既存のコード解析ツールを代替するものではなく、互いに補完するものとしています。既存のツールに加え、今回のツールをSEの日常に自然に組み込んでいくことが大事だとのお話がありました。また、既存のツールのように「ダメな点をひたすら指摘する」のではなく、良い部分は良いと見える化することが、ユーザのモチベーションにもつながると。

    　その他、「いいコード」「悪いコード」の収集と、それらのスコアリング（もちろんレビュアによる手動！）に苦労されたとのこと。これは想像に難くないですね・・・。

    所感

    　どんどん大量のデータが集まってくるセンサーデータと違って、人間の手による成果物をディープラーニングの入力にするのは厳しそうだと思います。特に教師あり。こんな話もありました・・・。

    itpro.nikkeibp.co.jp

    ソフトウェアの不具合検知・修正への機械学習の応用について

    　産業技術総合研究所の森彰さんのお話です。
    　「AIによるソースコードレビューの変革」とこちらが、「AI for SE」のカテゴリです。

    AIで何ができるのか

    　Fault Detection、Fault Localization、Fault Repairの、3つの分野での応用を紹介されています。検知、同定、修復、ですね。
    　重点が置かれていたのは、修復です。
    　方法の1つとしては、バグを含んだソースコードの一部を変換し、そのコードでテストを実行するというもの。テストをパスすればスコアが得られるゲームとして、変換を繰り返し行っていくうちに、ものによっては修復ができてしまうそうです。この場合の「修復」は、「既存のテストをすべてパスする」という意味でしかなく、単にテストが弱かったということもあるのですが、それを踏まえても3～4%は「本当に」直るとのこと。

    　これも十分、力業という印象を受けたのですが、さらに力づく感があるのが、Vertical Code Transplantingという技術。ある特定の機能を実現するためのコードは、似たものがきっと世界中のどこかのリポジトリにあるだろうということで、それを探してもってきて、それを自分のコードに反映してしまうのだそうです。この「似たもの」というのは、文法構造の類似ではなく、やろうとしていることが似ていなければならないのですが、この「意味的コードクローン」の判定がそれなりにできてしまうので、荒唐無稽な話でもないようなのです。
    　自動的にコードが修復されていく世界が未来過ぎたのですが、「GenProg」で検索すると関連資料がたくさんあり、驚きました。

    質問したこと

    　今回のお話で気になったのは、ユニットテストが完備されていて、かつ短時間で完了できるということが前提になっている点です。
    　たとえばIoTの世界だと、多数の機器が接続された、バリエーション多彩な環境で動作して初めて発現するバグがより深刻だと考えられます。そのようなバグを見つけるにはシステムテストレベルのテストが必要で、その実行はおそらくユニットテストのような時間オーダーでは終わらないのでは・・・という点が疑問で、質問させていただきました。

    　そのようなケースは、修復よりまず検知と同定が課題であり、AIによるログのパターン解析が使えるだろうとのご回答をいただきました。
    　また上述のような背景から、今後はプロダクトコードよりもテストコードを正確に書くことが重要になってくるとのご意見もいただきました。

    所感

    　このような話を弊社の大先輩エンジニアとしたところ、「テストコードを完璧に書くというアプローチと、要件を形式的に書くというアプローチの本質的な違いは何なのか、意見を聞きたい」と言われました。

    　テストコードをプロダクトコードに対する要件と捉えると、本質的な違いはないようも思います。
    　少し考えて、「前者のアプローチは、適切なテストコードが追加されるごとに、自動的に品質が良くなる（蓋然性が高い）点が違うのでは」といった趣旨の回答をしましたが、それは後者でも変わらないですね。つまり、不足していた仕様を追加すれば、そこから導出されるソフトウェアの品質は上がっているはずなので。

    　もう1点、形式的に記述された仕様から導出するプログラムが仕様を完全に満たすのに対して、テストコードから修復されるプログラムはあくまで「いろんな可能性の中で一番よくテストコードをパスしそうなもの」であるにすぎず、すべてのテストコードをパスすることを保証しない（もっとも多くパスすることも保証しない）という点が違うのかなーと思いました。
    　みなさんはどう思われますか？（全然所感じゃない）

    Neural Network ConsoleによるDeep Learning研究開発の効率化

    　ソニーの小林由幸さんによる、ソニー謹製のディープラーニング研究開発ツールのお話で、ここから2つが「SE for AI」のカテゴリー。 　プログラマ向けの関数プログラムである「ライブラリ」と、商用開発に対応したツールである「コンソール」があり、セッションは主に後者のデモでした。
    　自社ツールの紹介ではありますが、お金のにおいを感じさせない、開発者の情熱に溢れたプレゼンテーションでした。

    　製品紹介は、YouTube上でも見ることができます。
    　こちらもディープラーニング学習者ならとっくに知っているものなのでしょうが、わたしは初見でして。
    　GUI上で各種レイヤをグリグリ並べて、整形済みデータを流し込むと、すぐに学習が始まって精度も測定される。一番よい精度を出せそうなネットワーク構成の探索も自動でやってくれる。コストに効いてくる計算量もわかる。そしてそのGUIも、SONYらしく美しい。


    Neural Network Console：ツールで体験する、新しいディープラーニング

    所感

    　AffineやCNNなどは、プログラミングにおけるif文と同じで、一度理解すればそれで済む。理解したら、コンソールのようなツールでいろいろ試してほしい。というお話がありました。
    　わたしは『ゼロから作るDeep Learning』でゼロから学びきれず落伍しましたが、再度立ち上がって一通り基礎を習得し、そのあと堂々とこの手のツールを使えるようになりたいです。

    ゼロから作るDeep Learning ―Pythonで学ぶディープラーニングの理論と実装

    ゼロから作るDeep Learning ―Pythonで学ぶディープラーニングの理論と実装

    機械学習における品質保証のチャレンジ

    　国立情報学研究所の石川冬樹さんによるセッションです。
    　機械学習に基づくソフトウェアにおける困難と、その打開策についてお話いただきました。

    何が難しいのか

    　欠陥に気づくことができるのか、直せるのか。何をもって完成とし、どのようにユーザに説明するのか。
    　テスト工程以降のあらゆる工程に困難さが発生することになります。それを解決する方法として、いくつかの手段を紹介いただきました。

    • Metamorphic Testing: 入力をこう変えると出力はこう変わるはず、という関係を活用して多数のテストケースを生成する。たとえばアイテムのランキングの機能があったとして、アイテム群から1つのアイテムを抜いても、残ったアイテムのランキングの上下関係は変わらないはず、という関係を確認するためのテストは、たくさん考えることができる。
    • Search-based Testing: メタヒューリスティックを用いて、スコアを最大にするようにテストスイートやテストケースを生成し、カバレッジを高く、テストケース数を少なくする技法です。
      ・・・これではまったくわかりませんが、辰巳敬三さんによる記事がこちら(pdf)にあります。

    　またホワイトボックステストにおいて、コードをカバーするだけではダメで、ニューロンのカバレッジを上げる必要があるとのお話がありました。とはいえこれは人手でできるものではないので、やはり機械による大量入力を回すしかない。また、GAN（Generative Adversarial Network）による意地悪なデータでソフトを試すというアプローチも実用になりそうとのことでした。

    blogs.nvidia.co.jp

    所感

    　テスト技法といえば、「無限ともいえるテスト空間をいかに効率よく、合理的に狭めるか」、ざっくりいうと「テストケースをどう減らすか」に焦点を当てたものを捉えていました。
    　が、「テストケースをどう増やすか」という真逆の目的をもった技法があることを学びました。短時間で完了するテストケースと期待値をできるだけ多く、自動的に生成し、それを全部流してプロダクトの妥当性を検証するというアプローチなんですね。
    　誰かMetamorphic Testingの勉強会やりませんか？ 理解できる自信はないのですが。

    総合討論

    　5人の講演者の方と会場からの質問による、パネルディスカッションです。
    　いろいろなトピックがあったのですが、特に印象に残ったのは「ディープラーニングに基づくソフトウェアが出した答えをどう説明するか」についてでした。単に「学習の結果、こうなりました」では、答えを言われた方は納得できないでしょう。

    　富士通の森崎さんは、たとえば「コードが良くない」と判定された理由をできるだけ伝えるようにしているとの答えでした。やはり判定を誤ることもあるので、既存のメトリクスも使って総合的に判断しているとのこと。

    　一方、ソニーの小林さんのご意見は逆で、「理解してもらう必要はない」とのこと。なぜなら、人が理由を知りたがるのは、その理由に基づいて人が対処しなくてはならないから。将来的にはその対処を機械が行うようになるので、人の介入は不要、説明も不要になるという見解です。
    　森さんのお話にあった欠陥修正にしても、自動で修復されていくのであれば「コードのどこの部分が悪かったのか」を人が知る必要はなくなるのかもしれません。
    　ただそうはいってもその見解に誰もが納得するわけではないので、人の意識を変革していく必要があり、それは我々の仕事だ、というご意見でした。

    　石川さんのご意見は、「説明できない、ルール化できないからこそディープラーニングを使っているのだから、説明を必須とすると普及しない」というものでした。ただし、社会学的・心理学的に「説明」が必要なのであれば、ディープラーニングでそれっぽい説明を自動生成すればいい、との極論（？）も出ました。

    おわりに

    　パネル含め、すべてのセッションが有意義で面白く、ディスカッションも活発で、参加できたのは本当にラッキーでした。
    　JEITAさんのイベントは初めてだったのですが、今後もウォッチしていきたいと思います。ありがとうございました！