GitKraken Ambassadorになりました

マスコットキャラクターがたいへんかわいいと評判のGitクライアント"GitKraken"のアンバサダーになりました！

今後、当ブログでGitKrakenの（かわいいだけじゃない）機能紹介などを行なっていくとともに、近い内に都内でmeetupなどを開催できればと画策しています。

※以下、当初の原稿が「たいへんかわいい」で埋め尽くされてしまっていたため、大幅にリライトしたものでお送りします。

GitKrakenとは

GitKrakenは、Axosoft社が開発・提供しているGitクライアントです。オープンソースプロジェクトでの利用など、商用でなければ基本機能は無料で使用できます。 またGitクライアントだけでなく、Glo Boardsというカンバン機能も備えています。

とりあえず触ってみたい、という方は、ぜひ下のリンクからサインアップして試してみてください。

www.gitkraken.com

Nintendo Switchがもらえたりもらえなかったりするようです。なにより、meetupを開催するときに送ってもらえるノベルティが豪華になりますので、ぜひこのリンクをご利用ください。

GitKraken Pro

GitKraken Freeでも、その美しいGUIは使用できますし、そもそも他に無料のGitクライアントはいくつもあります。しかし、個人的にGitKrakenをおすすめする最大の*1ポイントは、$4.08/moのProプラン以上で使用できる"Merge conflict editor"です。

Merge conflict editorについては、次の動画の1分20秒あたりから見ると*2その便利さがわかっていただけるのではないでしょうか。

youtu.be

またProでは、個人のGitHub.comのアカウントと、会社で使っているGitHub Enterpriseアカウント、もしくはGitLabやBitbucketなどのアカウントを切り替えて使いたい方のための"Multiple profiles"機能も使うことができます。

なお、GitHubにおける複数アカウント利用は利用規約違反では、という話（全社的に会社用GitHubアカウントを廃止した件 - ZOZO Technologies TECH BLOG）ですのでご注意ください。

GitKraken Proは有料プランですが、7日間のトライアルがあります。ぜひ一度お試しください。

Glo Boards

いわゆるカンバンです。GitHub Projectsなどより高機能で、カレンダー・ビューなどもあります。 こちらも、オープンソースプロジェクトでの利用など、商用開発でなければ基本機能は無料で使用できます。

下はバージョン5における新機能紹介動画ですが、Glo Boardsがどのようなものかわかりやすいはず。

youtu.be

こんな方におすすめ

初心者から上級者まで！ と言いたいところなのですが、初心者しかも日本人には英語の壁があるのも確かです。 しかし、先々、複雑な操作をするようになる頃にはCLIに行き着きますし、GUIは慣れるものです。 どうせ使うならキレイなGUIを使いたいという方、ぜひGitKrakenを使ってみてください。

GitおよびGitHub自体に慣れていないという方には、まずはこちらの書籍をおすすめします。

わかばちゃんと学ぶ Git使い方入門〈GitHub、Bitbucket、SourceTree〉

また、マージ、リベース、それに伴うコンフリクトの解消がとても強力なクライアントですので、多数のブランチが並列していたり、個々のブランチの寿命が長かったりというつらみの深いプロジェクトに携わっている方は、ぜひぜひGitKraken Proのフリートライアルを試していただきたいです。

まあそもそも、そんなプロジェクト（以下略

免責事項

私はGitKraken Ambassadorであり、GitKraken開発元のAxosoft社の従業員ではありません。

I am a GitKraken Ambassador, not a paid employee of GitKraken by Axosoft.

*1:これは「たいへんかわいい」を差し置いて、最大です。次点で「アイコンがたいへんかわいい」「スプラッシュ画面のアニメーションがたいへんかわいい」などと続きます

*2:埋め込みだと再生開始指定が効かないみたいなので

定職につきました

いわゆる転職エントリです。 長らくフリーランス開発者としてやってきましたが、4月から株式会社ディー・エヌ・エー（以下DeNA）のSWETグループ所属となりました。

副業可・裁量労働でもありますので、自分の会社も副業として細々と存続します。その副業の関係でここ2ヶ月はアルバイト扱いで仕事していたのですが、とても仕事しやすい環境です。

フリーランスから会社員という変化、開発者からテスト系というロールの変化を同時に決めたわけで、そのあたり少し書き残しておきます。

DeNA

お誘いを受けたときの最初の印象は「『電エース*1』みたいな名前の会社だ」というくらいで*2、正直なところ会社員というものが選択肢として考えられていなかった状態でした。

が、なにせ過去に会社員だった記憶は20年前のメーカー系だったわけで、時間をもらって考えるに並の案件よりよほど自由もあるし*3、DeNAであれば色々な領域の技術を扱えるのでは、というあたりに惹かれた感じです。

とは言え、ろくに転職活動などしてこなかったので広く他社と比較したりということもせず（できず）、ネガティブな要因に背中を押されたところもあります*4。

SWET

GoogleなどでいうSET (Software Engineer in Test)、MicrosoftでいうSDET (Software Development Engineer In Test)にあたり、狭義には開発チームのテスト自動化を支援したり、CI/CDなどのインフラを整えたり、というロールです。

自分のコミュニティ活動、著書もまさにこのあたりの領域なので、チョットデキルと言えるところ。

しかし、先日のJaSST'19 TokyoでのYahoo! JAPAN山口さんの話のように、開発チームが自力でテストを書けるようになれば不要になるはずのロールであり、現にGoogleではインフラ色の濃いSETI (Software Engineer, Tools & Infrastructure)に名称も変わり、MicrosoftのSDETはなくなっているそうです。

ソースはこのあたり。

• ベリサーブ ナビゲーション（VERISERVENAVIGATION） | ベリサーブ 2018年11月号のYahoo! JAPAN山口さんの寄稿「アジャイルなソフトウェア開発におけるテスティングの実際」
• 【翻訳】「アジャイルテスト」、わたしたちの定義 - ソフトウェアの品質を学びまくる2.0
• Google Testing Blog: From QA to Engineering Productivity
• Evolving Test Practices at Microsoft - Azure DevOps | Microsoft Docs

この点は最初の面談でまず聞いたところでなのですが、DeNAでは狭義のSETのロールだけでなく、形式手法や機械学習との連携などR&D的な活動も進めているという話であったり*5、AI for Testingとかゲームとかのテスト技術を個人で追うことに限界を感じていたところもあったので、もう片手間でなくこちらに舵を切ってしまおうか、と決断したのです。

フリーランスについて

フリーランスという働き方については、勧めもしないし止めもしないです。20年前と今とは違うし、どちらが良いとも悪いとも言えないです。DeNAの居心地は今のところとても良い*6ですが、まだ2ヶ月なのでいつ手のひらを返すかわかりませんし。

個人的には、本業で開発、コミュニティ活動でテスト自動化と活動を分けた挙げ句、本業側でろくなポートフォリオを残せていないというバカなことをやってきたわけで、後進には反面教師以外の何も残せないのは申し訳ないです。

最後に参考までに、会社が副業可であっても年金事務所の手続きとかめんどくさくて、日本社会がまだまだなんだなという感想。なにせ絶賛手続き途中なので落ち着いたらエントリ書くかも知れません。 あと雇用保険が7年で失効するとか。

参考資料

テストから見えてくる グーグルのソフトウェア開発

実践アジャイルテスト テスターとアジャイルチームのための実践ガイド (IT Architects' Archiveソフトウェア開発の実践)

バカ映画一直線!: 河崎実監督のすばらしき世界

電エースBOX 河崎実監督作品 [DVD]

電エースQuiz - 河崎実監督と特撮映画の世界

• HUB Systems, Inc.
• エンターテインメント
• ¥600
• 

*1:平成元年、バンダイのビデオマガジン『電影帝国』内の1コーナーとしてはじまった特撮作品のシリーズで、30年続いている河崎実監督のライフワーク。気持ちが良くなると変身するヒーロー、電エースの活躍が描かれている。近年はクラウドファンディングで出資者を出演させるという商法が展開されている

*2:実は数年前DeNAセミナールームで登壇したときネタに使ったのですが、盛大に滑りました

*3:フリーだとなかなか案件から抜けられないこともあり、逆にDeNAでは社内での異動がしやすい制度が整っていたりします

*4:最近フリーランスが流行りっぽいけど余り良い案件流れてないとか、35歳定年説については諸説ありますが個人的には内部品質の低いコードの読み書きはつらくなってきたとか、営業めんどくさくなってきたとか

*5:日付は前後しますが https://speakerdeck.com/orgachem/story-of-a-swet-engineer

*6:ぬるいわけではないです。みんな頭良くてついていくだけでも大変

Unity 2018のUnity Test Runner

ようやく重い腰を上げて手元のUnity 2017.4プロジェクトを2018.3に移行したので*1、何番煎じかわからないけどテスト(Unit tests)まわりについてまとめ。

Test Runnerウィンドウ

2017ではメニューのWindow直下にあった"Test Runner"ですが、Window > General > Test Runnerに移動されました。

Edit mode Tests

2017.4までは、EditModeで実行するテストコードはAssets/**/Editor/**/下にあればよかったのですが、2018では条件が増えています。

例えばAssets/Xxx/Editor/のようなフォルダ階層でXxx下にAssembly Definition（以下asmdef）ファイルを置いてしまうと、Editorまで同じアセンブリに含まれてしまいます。

Xxx/Editor下にEdit mode Testsがある場合はXxx/Editor直下にもうひとつadmdefファイルを作り*2、"Test Assemblies"と"Editor"の2つのチェックボックスをonにする必要があります。

なお、Edit modeでは[UnityTest]属性をつけたテストはEditorApplication.updateコールバックループで実行されるという点は2017も2018も同様です。

Play mode Tests

2017ではPlay modeでテストを実行するには”Enable playmode tests”をクリックしてから再起動する手順が必要でしたが、2018では不要になっています。

代わりに、テストコードは任意のフォルダ下に置き、そこにadmdefファイルを作り、"Test Assemblies"チェックボックスをonにする必要があります。

なお、Play modeでは[UnityTest]属性をつけたテストはコルーチンで実行されるという点は2017も2018も同様です。

Enable playmode tests for all assemblies

もし、Play modeのテストコードを容易に移動できない、asmdefによってアセンブリを分けることが困難といった場合、Test Runnerウィンドウ右上のハンバーガーメニューから"Enable playmode tests for all assemblies"をクリックして有効にすることで、Unity 2017のようにモードを切り替えてPlay mode Testsを実行することができるようです（未確認）。

ただし、このままではビルドに追加のアセンブリが含まれるため、プロジェクトのサイズとビルド時間が長くなってしまいますので、ビルドを行なうときにはDisableに戻すべきです。

アセンブリの依存関係

Assembly Definitionファイル（以下asmdef）はUnity 2017.3から導入された機能で、アセンブリを小分けすることでプロジェクトのビルド時間を節約する効果があります。

Unity 2018からはテストコードは専用のアセンブリ（"Test Assemblies"チェックボックスをonにしたもの）に属する必要が生じたため、テストコードのasmdefからSUT（system under test: テスト対象）ほか使用しているasmdefを参照する旨を"Assembly Definition References"に設定する必要があります。

下図はSUTである"SUTClient"と、"UniRx"に依存している例です。

Internalの扱い

C#では、Internalアクセス修飾子をつけたclass/methodは同一アセンブリ内からのみ参照できます。Unity 2018でテストコードが別アセンブリになったことによって、そのままではInternalなclass/methodのテストを書くことができません*3。

これに対し、参照される側（SUT）の中に以下のコードを書くことで、指定したアセンブリに対してInternalなclass/methodを公開することができます。

using System.Runtime.CompilerServices;

[assembly: InternalsVisibleTo("Assembly-CSharp-Editor")]
[assembly: InternalsVisibleTo("SampleTestsAssembly")]

""の中には、公開するアセンブリ（この文脈上はテストコードのアセンブリ）名を書きます。"Assembly-CSharp-Editor"はUnityエディタです。

なお、このコードはアセンブリ内のどのファイルに書いても良いようなのですが、過去の経緯から"AssemblyInfo.cs"というファイルに書くことが多い？ ようです。

おまけのTips

Time.timeScaleでPlay mode testの実行速度上げられるの知らなかった
Testing Test-Driven Development with the Unity Test Runner – Unity Blog https://t.co/Yt4LQ4ihL6

— Koji Hasegawa (@nowsprinting) 2019年2月20日

*1:2017.4から2018.3に上げたので、差分は2018.1か2か3のどこで入ったものかまでは確認していません

*2:右クリック > Create > Assembly Definition

*3:Unity 2017以前でも、Edit modeのテストコードはAssembly-CSharp-Editorというアセンブリに入るため、Internalなclass/methodのテストはそのままテストできませんでした

JaSST'19 Tokyo 聴講メモ（主にAI x Testing関係） #JaSST19Tokyo #JaSST

ほぼ毎年恒例、JaSSTソフトウェアテストシンポジウム-JaSST'19 Tokyoに行ってきました。今年はAI x Testing（AI for TestingとTesting AI）の話多め。

以下、聴講したセッションのメモ。

AI-Driven Testing: A New Era of Test Automation

Ultimate SoftwareのTariq King氏による基調講演。

• Automationとは、独立してできること。テスト実行を自動化しても確認がマニュアルでは当の自動化ではない。AIで完全な自動化を目指す
• AIST(AI for software testing)は以下を含む分野と定義
  • AI driven testing
  • testing AI systems
  • self-testing systems
• コミュニティが必要なので作った -> AI for Software Testing Association
• 今日はAI driven testingにフォーカス
• testingに使う
  • input:d -> program(function) -> output:f(d)
  • f(d)は受け入れ可能か？
  • 機械学習のモデルも似ている
  • domain:dx -> program -> range:OK(d1),OK(d2),,,
• 機能を追加するとcomplexityは増えていく
  • coverageも上げるけど追いつかない -> カバレジギャップ
  • 解決したい
• AI driven testing: a new era of test automation
  • test.aiのJason Arbonと一緒にやっている
    • test.ai
  • explore 画像で画面とかを学習
  • model
  • interact
  • プロトタイプを公開している
    • GitHub - UltimateSoftware/AGENT: AI Generation and Exploration in Test
    • GitHub - UltimateSoftware/AGENT-X: Chrome extension to supplement the AGENT (AI Generation and Exploration in Test) system.
• 『不思議の国のアリス』を解析して再生成する試み
  • AI driven test generation
  • abstract testの記述言語を作った
    • if "first name"が出てきたら
    • when 空有白を入れてsubmit
    • then エラーが出る
  • トレーニングデータ不要
• 限界はある。次に何をするのかわかってない。信頼できるか？
• self testingし続けないといけない。リアルタイムで

Q&A

AIによるテスト結果を信用できるのか

• いくつか取り組みがある
  • ブラックボックスでない、説明可能なAI
  • AIそのものをテストできるようにする
• それでも100%納得されないかもしれないが、それでも今よりまし。マニュアルでもバグはある。100%でない
• 100%でなくても、数値化・定量化できるのは利点
• ミッションクリティカルなところには適用できないかも。人間の支援として使うとか。それでも、なにもしないより、AIを使うほうがはるかにいいはず

large volume output

• "Pterodactyl"というプロダクトに最初に取り組んだ
• ダッシュボード、複数の問題を集約したりできる

usability testingはできるのか

• 事例さえあれば。このボタンがわかりにくい、このデザインは見づらい、みたいな事例を学習させることで可能
• applitools.comでVisual Testingをやっている
  • AI Powered Visual UI Testing & Monitoring

Agentにやってはいけない動作を指定できる？　より探索的にすることはできる？

• ふたつのゴールを同時に達成するのは難しい
• なにもないと、すべてのリンクを見つけてクリクしてしまうので、スコープを制限する機能はある
• アクションを制限することもできる。コンフィグレーションを作る必要はある
• スコーピングする機能は必須

仕様とか検証内容をどう教える（定義する）のか

• ソフトウエアが予想どおりの動きをするかの予想。ドメインナレッジ。人間の脳の中にある
• システムに、ある特定の分野のドメイン知識を入れる必要がある。専門家がトレーニングする
• まだ時間がかかるが、構築する必要がある
• amazonとかgooogle mapから「これ正しい？」という質問が来る。これはトレーニングに使われている

学習モデルは汎用的？

• まだ教育ツールの段階。これにトレーニングしてテストに使う。まだ汎用的ではない
• App Storeのアプリでトレーニングしている人はいる（test.aiのこと？）
• 汎用的なものは目指したいが、モバイルとデスクトップはまた違う

UIのテストのみ？

• input/outputがあればできる

将来像について。汎用化は全体なのか、ドメインごとに特化したのを組み合わせるほうか

• model driven engineeringをやってきた。結果、general solutionでは問題は解けない
• トレーニングは（そのドメインの）コミュニティでやらなければならない

self healingなどいつごろ実用化されそうか

• いつ？というのは、コミュニティ次第

テストの未来、品質の未来　～自動化はテスター撲滅の夢を見るか？～

speakerdeck.com

各社でテスト自動化に取り組んでいる方々によるパネル。まず体制とロールについて。

• 山口さん＠Yahoo!
  • Devのチームで品質も見る。QAというロールもプロセスも存在しない
  • 支援の横断的チームはある
• 大園さん＠LINE福岡
  • 横断的チーム：テスト自動化、SET、QAがある（わかれている）
• 木住野さん＠LIFULL
  • 横断的チーム：SET, QA
  • SET（QAから分離）：リリース前E2E自動テストと、依頼があれば自動化支援
• 根本さん＠メルカリ
  • SET -> Automation&QAグループ(AQA)
  • 各プロジェクトにQAが入っている
  • 横断的チーム：AQA, iOS Dev, Frontend Dev, Backend Dev
• 松尾さん＠今回はクックパッドの話ベース
  • 各プロジェクトにQAが入っている
  • 横断的チーム：モバイル基盤グループ(QIT)

アンケート結果について

• テスト自動化への期待と結果
  • 素早いフィードバックが期待も結果も多い
  • コスト削減は期待にはあるけど結果にはない
• テスト自動化の課題と対策
  • フレーキー
  • 不安定なテストを書くのは後回し、価値の出るところから優先
• 自動化チームがいない、立ち上げが難しい、人がいない
  • Yahoo!の規模（Devが3,000人）になると、Devがみんなテストできるようにならないといけない
• なにを対象とするか、どのテストを自動化するか、準備や計画ができていない
• 手動テストを自動化しようとしてしまう
• テスターがスクリプト書けない
• 自動化チームがマネジメント層やテスター他の関係者から十分なサポートを得られない

自動化はテスター撲滅の夢を見るか

• 自動化チームは必要か
  • 必要：技術のキャッチアップとか手がまわらないので必要
  • 不要：開発チームがやるのが適切なはず
• QAは必要か
  • サービスによる：Webだと手厚くQAするより、手早くfix&releaseするほうがいい。組み込みとかだとQAは必要
• テスターは必要か
  • 不要 → 部分的に置き換わる
  • 仕事内容が変わる：多様化

Agile, DevOpsがあたりまえの時代に求められる人材とは

• プログラマが出せない価値を出せる人（山口さん）
• 誰もやっていないことに果敢にチャレンジする人（大園さん）
• 技術スキルを持ち、継続的な改善を推進する人（木住野さん）
• 越境する人（根本さん）
• 学びを続けられる人（松尾さん）

まとめ

• テスターの仕事は自動化によっておきかわるか
• すくなくとも、"置き換わらない"は0%

Q&A

未来への投資と目の前の仕事とのバランスについて

• 会社が挑戦していい風潮だった（大園さん）

所感

• 個人的にもYahoo!さんの体制が理想だと思っているので、大手の話だからで終わらせず、そこを目指していくべきだと思う
• 自動化チームは必要かのところ等、自動化チームのロールが曖昧なところがあった気がする*1ので、ややはっきりしない点はあった

他のブログ記事

nihonbuson.hatenadiary.jp

AI-based static analysis for clean code

Gammaの紹介

www.mygamma.io

• ルールベースのstatic analysisは役に立つが、限界もある
• コミットログを学習してレコメンドするエンジン
• すばやくフィードバック
• サジェストはIDEプラグインを提供（今はEclipseのみ？）
• 学習モデルはインクリメンタルに更新可能
• 学習モデルは3段階
  • Project
  • Organization
  • Community: オープンソースから学習
• オープンソースリポジトリでの利用なら無料で使える

AIプロダクトに対する品質保証の基本的考え方

スライド(pdf): http://qa4ai.jp/QA4AI.JaSST-Tokyo.20190327.pdf

• 機械学習を使用したシステム
  • CACE性(change anything, change everything)
  • 非線形で同値分析できない
  • 石川先生のスライド参照
    • IoT/AI時代のテスティング・検証技術の最前線
• QA4AIコンソーシアム
  • http://qa4ai.jp
  • ガイドラインを出す
    • 5つの軸とバランス
    • SQuBOK v3と同期させる（重複投資はなるべき避ける）
    • まずは、スマートスピーカー、産業用プロセス、自動運転、生成系の4ドメイン
• 5つの軸
  • Data Integrity
  • Model Robustness
  • System Quality
  • Process Agility
  • Customer Expectation: 良くも悪くも、顧客の期待
    • 合理的説明・原因・責任を求めるような客。悪い意味で期待値が高いということ
    • 期待値コントロール：低く保ちたい
  • バランス
    • レーダーチャートは5軸でもいいし、Customer Expectationを除いた4軸でもいい
    • 数値化は任意なので感覚的なものになる？
• プロセス
• テスト
  • ニューロンカバレジという試みもある
  • メタモルフィックテスティング：今のところ名前がついてる有効なテスト方法はこれだけ？
  • GANでエラーを探す：GANをQA側で組まなければならない
• 品質の保証とはなにか、をもう一度考え直す必要がある

Q&A

Process Agilityがあったが、なぜアジリティなのか

• 不確実性に対処するためにサイクルをまわす
• 機械学習は、規則性があるかすらわからないので
• Process Qualityでなく、あえてAgility

説明可能性

• 間違えたら、なぜ間違ったのか。狼とシベリアンハスキーを見分けるモデルで、実は背景の雪を見て判断していた話
• 全部説明する必要はないけど、ドメインによっては（銀行のローン審査とか）は、理由が説明されなければならない

System Quality

• AIの寄与度を抑えられているか、という項目はなぜ？
• 不確実性は持っているので、それを抑えられているか、という話
• 守るべきものは、仕様書に書かれる

確率的なので、外れたものを人間が即異常値と判断していいのか。学習途中では許容できたりしないか？

• メモできておらず

ルールベースと機械学習の比率は、ドメインによって違う？　議論はされている？

• それはネクストステップ。今はまだコンソーシアムとしてはやってない
• 個人的には、そもそもルールベースでは解決できないことをやってるものもある。自動運転とか。なので、都合よくルールベースというわけにはいかないと思う（石川先生）
• かならずしも同じものを実現するとは限らない
• 例外、制約、セーフティネットはルールベースになっていきそう

ゲームのテスト：三銃士モデルを適応してみた！ -Next Generation 次世代の挑戦-

三銃士モデル

• 世界観、コンテキスト、実装。中心にユーザ感情
• テスト観点を構造化する。マインドマップ
• 観点の中に「環境」がある。機種とかOSバージョンとかはここ
• ジャンルによっても異なる
• 単一観点から入って複合に進む

ゲーム業界の○○テスト！？＠KLabさん

• ISO-29119-10 Games Testing（2019/4執筆完了予定？）
• そもそも、ゲームのテストタイプにはなにがあるのか、研究会で考えてみた話

三銃士モデルを現場適用してみた＠アカツキさん

• フリーデバッグ（探索的テストみたいなもの。各社で定義は違う）
• 前倒して実施するようにした。リリース延期とかになるので
• バグ摘出できるのはベテラン。人数を増やしても無駄だった
  • そもそも、テスト手順があいまい、組み合わせ条件が甘いなどが問題
  • マインドマップで整理してテスト項目にフィードバックすることで事前摘出できるように

UX／マイクロサービスアーキテクチャー時代の自動テスト戦略

• テストピラミッドのIntegration Tests以下をフロントエンドとバックエンドに分ける話
• ファクトベースで振り返り
• 品質はチームで守る意識が芽生えた
  • テスト設計、実装、レビューまでやることで意識が芽生える
  • 自分たちでテストレベルやテスト密度・手法について考えるようになった
• APIテストは、要件定義からテストチームが入っていた

所感

• そもそもE2Eテストでないならフロントとバックを分けてテストしているものだと思うので、主張はよくわからなかった
• 振り返り、開発チームがテストを書き、品質に関する意識が上がったという話はとてもよかった

人工知能は何ができて何ができないのか

はこだて未来大学の松原先生による招待講演。

• AIに明確な定義はない（そもそも"知能"が定義できてない。知能を定義することが目標？）
• 個人的には鉄腕アトムを作りたい
• ヒューリスティック。いいかげんなIT。アルゴリズムで100%うまくいくようになった分野はAIから"卒業"するので、AIはあいまいな状態が続く
• AIは今、3回めのブーム
• 将棋・囲碁も40年前は絶対無理と言われていた
• エキスパートシステム
  • スコアはそこそこ出たけど、ときどきとんでもない間違いをする
  • ナレッジを持っている人の、無意識・暗黙知は反映できない
• 創造性はコンピュータにも持てる。将棋、機械学習
  • 学習データのマネだけでない新手を指した
• プロの寄付から学習→教師を超える→AI同士で対局して強化学習→強くなったけど、ブラックボックスで人間は理解できない。解説できない
• 俳句。生成できるけど、良し悪しを選んだりできない。まだ評価できない
  • 将棋などのゲームは評価基準が明確で、その点はやりやすい
• 100m競争で機械にまけても悔しくない。体力で負けることは経験がある（動物にも負けてる）。でも将棋で負けると悔しい
• AIの社会実装の試みの例
  • 公共交通を持続可能にしたい
  • リアルタイム乗り合いサービスを提供。SAVS(smart access vehicle service)と呼んでいる
  • 技術の中心はエージェントシステム
• 18-19世紀、肉体労働が機械に置き換わっていった。ラッダイト運動
• 21世紀、ネオ・ラッダイト
  • 一部の頭脳労働（とみなされていた仕事）にすでに影響が出ている
• 人間とAIのこれから
  • 人間とAIで役割を分担する
  • 人間＋人工知能として賢くなっていく（人間の概念が拡張されていく）
  • 賢くなったAIを人間が受け入れるにはある程度の「とき」が必要と思われる -AIもテストしてもらえる時代になった、という感想

所感

• "一部の頭脳労働（とみなされていた仕事）"という表現が好き。AI以前にITで減らせるはずの仕事はあったので
• "AIに明確な定義はない"ということなので、キズナアイちゃん親分も間違いなくAI

キズナアイ 1st写真集 AI

人工知能の未来 ～その未来をどうテストし、どうテストに活用するのか～

ヒューリスティックを前提とすると、品質は？ 品質とはどう定義するのか

• 正解率の話なら、正解率でいい。正解のラインが決まっているのなら
• 正解がなにかがわからない分野にAIが使われているし、その評価が難しい。点数をつける基準をつけたり、人の感性でチェックする

システムの一部にAI

• AIは、作ってみるまで価値はわからない。前例がないと特に。データに規則性がちゃんとあるのか、それを特徴点として取り出せるかわからないので
• 文化が違う、試行錯誤、研究に近い開発

AIをAIでテストするとき、指針がほしいのでは。くれって言われない？ > Tariq

• オフラインでのバリデーションでは十分ではなくなるかも
• トレーニングによってその環境に適応していくことがある
• 基準を設けることはできるが、変化が起き続けるので本番環境でモニタリングし続け、評価し続ける必要があるのでは
  • 推論するだけでない
• 未解決である。エンジニアリングの手法を再検討する必要がある。古いやり方はできないと理解する
• AI, ML,それぞれの手法の違いを明確に理解する
• cross validation
• AI, MLをまず明確に理解するのが第一歩

本番環境でモニタリングするという話はある？

• 公式には聞かないけど、各所でやりはじめてはいるはず。結果が出てからでないと公式に言わないので

学習過程、explainable

• 規則性を学ぶ、言語化できないルールを見つける
• 狼とシベリアンハスキーの雪背景の話。なぜその判断をしたかがわかるか → explainability（説明可能性）
  • 本当に必要か？ なくてもいいのでは？
  • 天気予報、天気図が出てるけど、あれ出ないと納得しない？ 本当に見てる？
• 将棋の解説者、説明する相手（弱い相手）にわかるように説明する。自分の思考ではなく相手に向けて再構成している
  • 抽象化がいい説明なのかどうか
  • 説明とはなにか、わかった気にさせること？
• 相手によって説明のしかたは変える。人間はAIの思考は理解できていない。複雑なので＋その分野の知識がない。→たとえ説明してもらても理解できない
• 機械に対して期待が高すぎる。人間でも適当なことを言う（うまくいくんじゃない？等）が、AIにその答えはゆるされない？
• 説明しなくてはならないシステムをどう作るのか。必要なら作らないと。いらないなら作らなくていい
• 科学でなく哲学の話
• 人間には思い込み、概念がある
• データの網羅性が少ない問題にはexplainableのアプローチは有効なのでは？
  • 自動運転で、雪の日、霧の日、とかをあらかじめリストアップする必要があるという話になってしまう。でもそれは大変。社会的な話
  • 必要になってからデータ追加・再学習できる体制を作るほうがいいアプローチなのでは
• Mutation testingなど、既存のテストソリューションがAIのテストに応用できるものもあるのでは？
• 人間のように、環境の変化にすばやく適応できるマシンを作るほうを目指したい

過学習

• 防ぐことはできてないけど、知識として持てるようになったので気をつけられるようにはなった
• 過学習では精度が上がったように見えてしまうので、テストのやり方を考える必要がある

データの話。品質保証の範疇？

• データ（セット）の情報、バージョン管理などはこれから整えていく必要がありそう
• proverance、それは確かに誰々が描いたものとか、ワインの出処や経路を保証する
• データを自動収集しはじめる、差別用語を覚えてしまうとか。信用できないソースに対して検査するノウハウ・手法も確立すべき
• セキュリティも問題。攻撃される

Q&A

エコシステムは作れないのか。QAがブリーディングする？

• QAはブリーディングする役割にわまらないと、テストとか評価とかの役割ではいらなくなりそう。ダメ出しするだけの人はいらない
• サイクルはいる。クオリティを一番に考えてる人に与えるべき役割は、プロジェクトの進行に対してガイダンスを示してくれる人
• 顧客のニーズを満たせているかが重要
• テクノロジーを恐れる人、仕事を奪われることを恐れる人がいる。でも、やり方が改善されるだけである。Uber, Cell Phoneとか

データ*2を共有できる？

• ナレッジは共有すべきだが、データの共有は気をつけるべき。セキュリティや、データにバイアスがかかるという問題があるので、簡単にはできない
• ツールを作っていく。セキュリティなどの問題を解決するツール
• 訓練データは資産なので、オープンにしにくい
• モデル盗難: AIの動きを外から見て、似たモデルを作ってしまう手法。これに対し、透かしを入れられないかという動きもある

テストデータの数

• 同値クラスの概念がないので絞れない
• モデルに着目してテストしていかなければならない

*1:スクリプトを書く人であったり、支援する人であったり。SETのロールも各社で違っていたりするので仕方ないのですが

*2:明確に言われなかったが、学習データの話であり、学習済みモデルの話ではなさそう。モデルの話も出てきたので少し曖昧？

第1回AI4SEセミナーに行ってきました #AI4SE

昨年の12/14に開催された第1回AI4SEセミナーの聴講メモを下書きのまま放置してしまっていたので、今更ながら。

ai4se.connpass.com

TOC:

AIによるテスト・デバッグ技術 イントロ＆チュートリアル

AIによるテスト・デバッグ技術 イントロ＆チュートリアル from Fuyuki Ishikawa

www.slideshare.net

• AI4SEで扱うのは広義の「AI」
• 自動でなにかすごいことをしてくれる楽しい技術・進んだ技術を
• 機械学習工学やAI工学は、SE4ML、SE4AI
• AI4SEといえば、リポジトリマイニング(MSR: Software Repository Mining)
  • ここ10年
• 今回はSearch based SE/Testing/etc..
  • これもこの10年くらい
  • Facebookのあれ
  • Optimization based Falsification
• データでなく論理ベースも？
  • Concolic testing
  • 静的解析
  • 例: www.rise4fun.com/
• 進化計算：最適化の一手法
  • 進化的計算
  • メタヒューリスティックをいう区分もある
• 強化学習
• サーチベースドテスティング
  • 進化計算でテストケース、テストスイートを生成する
  • 自動運転車で、衝突させるようなケースを作る
  • 評価：カバレジ、テスト数、とか
  • 2018年のJava Unit Testing Competition
    • カバレジ、ミューテーションスコア（人工バグの摘出数）、テストケース数で評価
  • FacebookのSapienz
    • 指標：カバレジ、テスト長、検出バグ数
    • バグ修正も連携(SapFix)
    • 多目的最適化を使っているので、複数のテストスイートのパレートフロントが生成される
    • 意味がありそうなイベント列、リバースエンジニアリングで得た文字列
• 自動修正
  • プログラムいろいろいじってみて、テストが全部通ったら「修正（案）」
  • テストスイートがしっかりしていることが当然の条件
  • 人の頭の「暗黙の期待」だと無理
  • 例：ミューテーションベース。">"を">="に修正して、テストが落ちるかを評価
  • 自然に近いバグの入れかた
• 反例探索 (Falsification)
  • モデル検査

バグ自動修正ツールって本当に使えるの？ ～自動デバッグ技術の現状と課題～

バグ自動修正ツールって本当に使えるの？ ～自動デバッグ技術の現状と課題～ from Susumu Tokumoto

www.slideshare.net

• 2003年：7兆円
• 2013年：34兆円
• 開発者は時間の50%をバグの局所化と修正に費やしている、というデータ
  • バグのfixまで：平均6ヶ月
• 局所化
• パッチ生成
  • 変更タイプ1：ステートメントレベル
    • 代表的なツール：GenProg, RSRepair
    • 探索範囲が広いため、探索方法に工夫が必要。遺伝的あるごとか
  • 変更タイプ2：テンプレートベース（最新はこちらが主流）
    • Prophet, PAR
    • 探索範囲は狭いが、テンプレート依存
    • テスト成功でも、正しいパッチとは限らない。誤ったパッチ（テスト漏れ）
• 現在はレベル2（単純バグ自動修正）。3以上は直せない（複雑バグ、高度バグ、完全自動修正）
• 課題
  • 小規模バグのみ修正可能
  • テスト実行が長いと、パッチ探索の時間がすごくかかる
  • 修正品質がテスト品質に大きく依存
• SapFix by Facebook
  • 今わかっている範囲（詳細は非公表）
  • revert, template, 単純な変更を網羅的に試す
  • 特別なことはやっていないが、
    • 割り切りがいい。revert優先
    • 修正は実行時エラーに絞っている
• 富士通
  • ELIXIR: AIを活用したバグ自動修正ツール
  • MLで過去の修正履歴から見つける
  • 開発者による修正は1h、ELIXIRは5min
• バグ自動修正readyか？ チェックリスト == テストコードの品質が重要
  • 1.自動テストがある
  • 2.自動テストのカバレジに基準がある（xx%以上
  • 3.単体と結合両方で自動化している
  • 4.CIしてる
  • 5.実行時間が規模に対して十分に短い
  • 6.バグが発生したときに再現テストコードを書く文化がある
  • 7.ミューテーションテストでテスト品質を確認している
• 開発スタイルが変わる。CIで検出した単純バグはBotになおしてもらう
• オープンソースではkGenProgが日本語で開発されている

github.com

Q&A

テスト十分性の基準は？

• 理想はミューテーションまで。現実的なところは、カバレジか。

Facebookは実行時エラーのみに絞っている件、ほかは、テストケースがfailしたものも拾おうとしている

• テストカバレジが必要なのはコスト的ネック、適用が難しい
• その点も、SapFixの優位点

自動（運転）車システムのためのAI的自動テスト生成

自動（運転）車システムのためのAI的自動テスト生成 from Fuyuki Ishikawa

www.slideshare.net

• サーチベースド
  • 入力：歩行者配置、道路の構造、信号変化たいみんぐ、ほかの車の動きなど
  • 出力；安全性、快適性、法令遵守など（単項目ではない）
• 最終的には人が見る。悪いケースにアタリをつける、絞り込む
• 局所最適問題：あら捜し意識が強いと、やや悪い状況を探して、もっと悪い状況を見逃す
• モンテカルロツリーサーチ、バンディット問題
• AIシステムのテストへの応用
  • 機械学習モデルのテスト

深層強化学習による制御系の検証の試み

• 制御系が「おかしな振る舞い」をする入力を強化学習を使って自動生成した
• 強化学習を使わない手法に比べて、効率的に探索できる（だいたいの場合
• まだ実用化には程遠い（と思う
• 強化学習のコツ
  • 入出力は正規化して小さい値にする。0-1とかがいい
• 成功率の表、アルゴリズムの略称-次のアクションまでの間隔（1sec, 5sec, 10sec
  • 緑はDQN, 赤は既存手法

LT

LTはメモ取れておらず、公開されているスライドのみ貼ります

強化学習による制御システムの自動反例生成

speakerdeck.com

Generate and Validate Program Repair - 学術から産業へ持ち出してみて

第1回AI4SEセミナー from y-maezawa

www.slideshare.net

所感

バグ自動修正をしてくれるSapFixが話題になりましたが、その現実感とか、適用する前提条件が十分な自動テストというあたりを聞けてとてもよかったです。

テストカバレジは指標にとどめて100%を目指さなくていい、とずっと思っており公言もしていましたが、自動修正を見据えるとそうも言えなくなりそうです。また、ミューテーションテスト等、テスト自体の品質を上げる技法も注目度が上がっていきそう。

まだ実用レベルでないことは認識しつつ、いつか来そうではあるので早めに準備はしておきたい。

月刊『秘伝』誌のVR特集レビュー

昨日発売の月刊『秘伝』2019年4月号では巻頭特集「E-武道」ということで*1、その中のVRまわりについて。

武術系ブログ*2とどちらに書こうか迷ったのですが、こちらに。

月刊 秘伝 2019年 04月号

VRの記事は大きく2つ。

稲見先生の記事

武術・武道誌でVRを紹介ということで、期待半分・不安半分という感じでしたが、まず東大の稲見先生の、"Virtual"とは「本質」「実質」「エッセンス」といった意味であり、古流剣術の型稽古はとてもVRに近いものだ、という話から始まり、一安心。

「けん玉できた！VR」における、スローモーションで練習することで習得しやすくなった話などを挙げ、初心者のハードルを低くしたりできるのでは、という話とか、

www.youtube.com

能で「腰が据わっていない」状態をモーションキャプチャで可視化したら実は師匠が一番動いていた（つまり物理的な腰の動きと"据わり"がイコールでなかった）という話、逆に、紙漉きの名人の筋肉活動を記録して素人がトレースするようにしたら上達が早かったという話が面白い。

VR PARK TOKYO体験

武術家の方がVR PARK TOKYOでVR体験した記事。体験部分はよくある話として、"Circle of Saviors"のようなアクティビティは（普段稽古できない）集団戦の体験になってよい、という感想。

ただ、すべての稽古がVRでまかなえるものではなく身体感覚なども必要という話もあって、持ち上げすぎもせず落としもせず、地に足のついた良い記事だと思いました。

所感

私、"Circle of Saviors"は未プレイなのですが、記事によると移動はできないようで、これが良い感想につながっているかも。コントローラのパッド移動ができると、とたんにゲーム感がでるというか、ありえないヒット＆アウェイができてしまうので。

できれば、ルームスケールで（自分の足で）移動できるボクシング系のコンテンツを体験してもらっての感想も欲しかったところ。

あと、もしまた『秘伝』さんでVR特集があるのなら、ぜひ格闘最強VTuber眠居ふわりちゃん師匠のインタビューを取ってほしい。

www.youtube.com

*1:前号の予告ではVRだったのですが、ボリューム足りなかったんだと察し

*2:https://nowsprinting-ma.hatenablog.com/

デブサミ2019のCI/CDとかゲームQAとかの話 #devsumi

Developers Summit 2019、今年は2日目だけ行ってきました。テストとか自動化まわりのセッションの、気になったところだけ のメモ。

全量、また、その他のセッションの資料はこちらのページに追々貼られるはず。

codezine.jp

【15-E-2】CI/CDを使い倒して数段上のソフトウェア開発をしよう！

speakerdeck.com

デブサミ2019【15-E-2】CI/CDを使い倒して数段上のソフトウェア開発をしよう！ #devsumiE - Togetter

CircleCIの金洋国さん。「なぜCI/CDへの関心がこれほど高まっているのか？」という問いかけから、CI/CDのWhat/Why/Why not/Beyndについて。

• Why CI?
  • 実行し忘れ
  • 昔書いたテストが壊れて動かない
    • 「使われていない自動化は壊れていく」（出典：サイボウズを支えるCircleCI）
  • テスト結果が環境依存
• Why not CI?
  • CI導入の障害
    • テストがない
      • テストがなくても、構文チェック、カバレジ*1、サイクロマティック複雑度、ドキュメント自動生成など、自動で継続的に実行できる（効果のある）タスクはある
      • 可視化する。バッジ、ダッシュボード、メールやチャットでの通知
      • マージブロック有効化
      • 少しずつテストを追加していく
    • メンテナンスがつらい → Jenkinsおじさん問題 → クラウド型がおすすめ
• Beyond CI
  • リリースまで自動化 → CD
• What CD?
  • CDのDは、Deliveryなのか、Deploymentなのか
    • Delivery: 常にリリース可能な状態を維持する。リリースには人間の意思が介在する
    • Deployment: 自動でリリースまで実行される
    • 広義のCD: ビジネス価値を継続的にデリバリーしていくこと。書籍『継続的デリバリー』はこの意味で使っている
  • DeployとReleaseの違い
    • Deploy: 本番環境に配置する
    • Release: 配置したコードがトラフィックをさばく
• Why CD?
  • No CD, No feedback loop
• Why not CD?
  • アーキテクチャの問題
    • 疎結合にする、モダン化などの努力
  • 組織の問題
    • 明確な答えは無い
    • 『エンジニアリング組織論への招待』参照
  • ダメなら、早めにあきらめる
  • 開発の初期に早めにCI/CDを入れる。「最初からクライマックスだぜ！」
• Beyond CD
  • カナリーリリース、ブルーグリーンデプロイ
  • リリース間違ってもリトライできる → 心理的安全性
  • CI/CD Makes programming fun!
  • さらなる自動化に向かう？　CI/CD自体の設定、モニタリング、デプロイ環境構築など
  • さらに「最初からクライマックス」に

参考

継続的デリバリー 信頼できるソフトウェアリリースのためのビルド・テスト・デプロイメントの自動化

エンジニアリング組織論への招待 ~不確実性に向き合う思考と組織のリファクタリング

仮面ライダー電王 Blu-ray BOX 1

【15-C-4】ゲームQAを支える技術～前処理・後処理は大変だが役に立つ～

※スライドは追って公開されるそうです

デブサミ2019【15-C-4】ゲームQAを支える技術～前処理・後処理は大変だが役に立つ～ #devsumiC - Togetter

太田さんのセッション。AI技術を使ったゲームQAの話。

• ゲームQAと狩野モデル
  • 当たり前品質
  • 一次元品質はゲームではあまりない
  • 魅力品質
• ゲーム内AI、ゲーム外AI（開発、運用支援、データ検証、性的コード解析、テスト）
• AI for QA
  • 当たり前品質
    • データ検証
      • コリジョンチェック、ソシャゲのキャラの性能評価など
    • ガチャの確率
      • 法規制もあり、受け入れテストとして実機で検証する必要がある
• ガチャ確率確認ツール
  • OCR(Google Vision API), C++
  • 機械学習ではない
    • Google Vision APIのOCRは学習できない
    • ビルドパイプラインに組み込めない（3rdからバイナリとキャプチャ画像だけもらえる）
  • 標準的OCRだと難しい
    • フォントを作りこんでいる
    • キャラ名、アイテム名が一般的でない単語
    • レイアウトや背景
  • 偽陽性が多い、偽陰性はほとんどない
  • OpenCVで前処理をがんばる
  • 標準的フローに則る。検出できなかったりしてもオペレータがリカバリできるような流れ
  • OCR 本来は95%くらいが損益分岐点
    • ツール的に、90%くらい出れば手動の1/3〜1/4くらいの時間でできる
    • 70%を下回るなら、全手動のほうが早い
  • 行間を空けるとかの前処理で改善
• 排出率確認ツール
  • まわして出てきた画像
  • Airtestでキャプチャを取る作業は事前にやっておく
    • 10連ガチャでも、個々のカードに切り出しておく
    • 同キャラマージ表示（x3とか）とかがあると難易度が上がる
  • 外部委託なので、機械学習は難しい
  • 学習なしでできるか？ → 特徴量比較のみでやってみる → 分類数が多くなると無理
    • 誤分類はNG、過分類はある程度は許容できる
    • 1000overの微妙に違う「石」の画像
      • やっていると人間も学習するので見分けられるようになった
      • dot by dotの判定ならいける？ → ポストエフェクトがあるので無理
  • k-meansベースの方式で改善
    • お手本分類の重心を取る
    • 一部手動と割り切る
    • レア度の高いものは標本が少なくて過分類になりがち
    • 手作業が1/10に。分類作業を含めても1/10なのでかなり効率化できた

参考

前処理大全[データ分析のためのSQL/R/Python実践テクニック]

【15-B-5】Site Reliability Engineering at Google

デブサミ2019【15-B-5】Site Reliability Engineering at Google #devsumiB - Togetter

Googleの中井さんによるSREの話。

• Googleは当初から運用もSoftware Engineerで構成。目的はサービスを安定して提供し続けること
• 50%ルール。50%は開発にあてて、運用業務は残りで行なう
• SREのバーンアウト防止
• 50%ルールをおびやかすシステムに対しては、開発チームに運用作業の返却、もしくは運用要員の提供を要求する権利がある
• 安定稼働を組み込むための技術支援もSREチームの業務に含まれる
• SREの運用範囲は全システム/アプリでない。インフラ、ミドルウェア、重要度の高いアプリだけ見てる。
• 上記の範囲でも、すごく安定しているアプリケーションは見ない
• SREチームの究極のゴールは、自分たちが運用するシステムをなくすこと
• SLO (service level objective): 「安定」の共通認識
  • Webリクエストに対し、n%のsuccess、m%は200ms以内にレスポンス、x%は1000ms以内、等
  • モニタリングする
  • エラーバジェット = 1.0 - SLO
    • 期間内(3moとか）のエラーの許容量
    • バジェットがなくなる可能性が生じたら抜本的な対策を講じる
      • 開発を巻き込んでやる。新規機能のリリースは止める
• デザインレビューの提供
  • 設計段階でSREチームを交えてデザインレビュー
  • 運用まわりの設計が共通化・標準化できるので、SREチームとしても運用しやすいシステムになりwin-win
• Toil（労力のかかる作業）の削減
  • バーンアウト防止
    • Software Developerにつまらない作業をさせない → 50%ルール
  • 運用作業・障害対応の自動化を促進
• 障害対応のプロセス
  • 問題解決が最優先、他人に頼ることを本人のスキル不足とは認識しないことを徹底
• ポストモーテム
  • 重大問題の解決後に実施
  • Google Docsでみんなで一斉に、要因、反省、改善策を書き出す
  • 個人を避難する内容は絶対に書かない。個人のミスを誘発するシステムを設計したSREチームの責任という認識
  • 社内の全エンジニアに内容を公開
    • 障害対応により得られた知見を共有
    • 障害対応の実地訓練にも活用（再現シナリオとして使う）
• SREトレーニングコースがCourseraにある
  • ポストモーテムの書き方とかもある

たぶんこれ

www.coursera.org

所感

運用は運用専門の部隊（だいたい外部委託）がいて、という状況からSREできる人だけ入れれば解決するわけではなさそう。（QA部門における）テスト自動化と似たような話が繰り返されそう。

参考

SRE サイトリライアビリティエンジニアリング ―Googleの信頼性を支えるエンジニアリングチーム

The Site Reliability Workbook: Practical Ways to Implement SRE

【15-B-7】無意味なアラートからの脱却 ～ Datadogを使ってモダンなモニタリングを始めよう ～

デブサミ2019【15-B-7】無意味なアラートからの脱却 ～ Datadogを使ってモダンなモニタリングを始めよう ～ #devsumiB - Togetter

Datadogの池山さん（実は珍しい名字だそう）。アジア圏の最初の社員。

• 犬のロゴかわいい
• でも社員はネコ派が多い
• "Cattle, not pets"
  • ペットのようにひとつひとつ細かく見て分析するのではなく、家畜のように群れとして管理できる
• 14 days free trialがある

www.datadoghq.com

日本語ドキュメントも完備

docs.datadoghq.com

参考

入門 監視 ―モダンなモニタリングのためのデザインパターン

おまけ

今日読んだ（というか書かれた）個人スポンサーはいいぞという話。来年は検討しようかな…

blog.evangelism.jp

*1:テストがなければ0%ですけれど