第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%ですけれど

モリカトロン 新宿テストLab プレオープンイベントでゲームAIの講演を聞いてきました

ゲームAIを専業とするモリカトロン株式会社様がこの度、AIを応用したテスト（いわゆる第三者検証）を請け負う『モリカトロン新宿テストLab』を立ち上げるということで、ご縁があり12/7のプレオープンイベントにご招待いただきました。

モリカトロンの森川幸人氏と、スクウェア・エニックスの三宅陽一郎氏による、ゲームAIに関する講演内容を中心に書かせていただきます。

morikatron.com

モリカトロン株式会社は、『がんばれ森川君2号』『ジャンピング・フラッシュ*1』などで知られる森川幸人氏を中心に昨年立ち上げられた、"日本初のゲーム専用AIの会社"で、モノビットエンジン株式会社を含む「モノビット・モリカトロン ホールディングス株式会社」の傘下*2の会社です。

「ゲームAI」と「第三者検証」、簡単には結びつかない言葉かも知れません。ですが、まずゲームの制作に関わるAIの適用範囲がとても広く（後述の森川氏・三宅氏の講演参照）、その中にテスト自動化への利用があります。ここ2〜3年、CEDECなどでいくつも事例が発表されています。

モリカトロン様も、独自の自動化ツール開発を行ない、ただし、それをツールとして売るのではなく*3、手動テストのエキスパートと組み合わせて効率を上げた形で提供できる「第三者検証」という形を選択されたようです。

自動テストは、どうしてもリグレッションテストのウェイトが大きくなり、新規のバグ発見には余り効果が出ないものです。単純な、機械でもできる種類のテストは自動化し、人間はより高度な探索的テストなどに注力するのがセオリーであり、そこまでパッケージングしたサービスが「モリカトロン新宿テストLab」ということでしょう。

前置きが長くなりましたが、以下、イベントの講演内容のメモです。

開催挨拶

モリカトロン代表取締役の本城氏ご挨拶。上と重複する部分もあり割愛しますが（すいません…）、「あらゆるゲーム制作に役立つAI」のひとつとして、品質管理に活かす事業を、というのがはじまりだったそうです。

続いて、同取締役の成沢氏より。元スクウェア・エニックスでプロデューサーをしていた際、現場では様々なツールが開発され、ゲーム制作に利用されていることを見てきており、プロデューサー目線で見ても役立ちそう、他にも転用できそう、と思っていたので、今回のようなツールやサービスを広げて行きたい、とのこと。

20分でわかった気になる ゲームAI講座

モリカトロンAI研究所所長 森川幸人氏の講演。ゲームAIは門外漢なので、間違ってメモしていたらごめんなさい。

• 第三次AIブーム（deep learningあたり）以降、AI関連の話が多く来るようになったので会社にしたのがモリカトロン
• 『がんばれ森川君2号』は第二次AIブーム。このときは学者の中でのブームだったが、第三次はGoogleなども参入してカスタマーに広がっており本物ではないか
• AIの外科手術医。ゲーム制作の後工程になって「AIで面白くできないか」などの依頼が来て、キャラクタの行動判断などをAIに載せ替えたり
• AIモデルにはいろいろなモデルがある。deep learningだけでない。ふさわしいものを選別する必要がある
• ニューラルネットワーク：脳の仕組みを数理モデルにしてみたもの
  • パーセプトロンは第一次AIブーム
  • モリカトロンの由来は森川＋パーセプトロン
  • 脳のサイズアップ → 知能が増える、という仕組みは生物と同じ
• 正しいAI、楽しいAI
  • 正しい：医療、金融、囲碁、自動運転 → これらは、ほぼほぼAIに置き換わるはず
  • 面白い：ゲーム、小説 → 「面白い」の本質がわからないので難しい
• 中のAI、外のAI
  • 中のAI：キャラの行動判断、経路探索など。それなりに進んでいる。ゲームごとに特徴的
  • 外のAI：メタAI、イベントの進行、QA、デバッグ。これから必要となってくる。どのゲームでも共通的に使える、発展できる
• 中のAIの例
  • キャラのパラメタ、ショップの売り物
  • カードデッキの最適化：組み合わせが増え、人間がやる限界に来ている
  • キャラの行動判断：人間の発想に限界があるのでAIに期待できる
  • ユーザにあわせた会話を自動生成：ユーザごとにカスタマイズされた会話、歌とか
  • 経路を設計する
  • 世界やステージの自動生成。世界観を指定すれば、AIが生成してくれる
  • キャラクターを自動生成。属性を入れたらAIが自動生成。萌キャラ生成サイト（中国）
  • 仮想アイドルを自動生成
• 外のAIの例
  • ユーザに合わせた「接待」をする。ユーザに合わせた難易度調整。敵の数や強さとか。メタAIと呼ばれるが、森川さんとしては「ディレクターAI」と呼びたい
  • 品質管理、バグ摘出
• 正しい・楽しい × 中・外 のマトリクス
  • 正しい側の、中・外の中間に「データ解析AI」がある。まずここから新宿テストLabでは扱う
• 現在、まずは汎用的なツール化をしているところ
• AIが得意なこと
  • 画像認識。見分ける。人間でも意外と難しい例：文鳥とイチゴ、フクロウとりんご、チワワとマフィン、トイプードルと唐揚げなど
  • レンブラントの偽物をつくる
  • コピーライティング
  • キーワードから文を自動生成してくれる
  • ウェザーロイドAiri（まだ動きは人間モーキャプ）
  • フェイク・オバマ
  • AIアナウンサー（中国）
• 苦手なこと
  • 大阪弁のような、同意味の言葉、一般常識がないと読み取れない
  • 全部ひらがなの文。「せいじかのおしょくじけん」「うみにいるかのたいぐん」は一般的な知識の下地がないと間違える
  • 雑談が難しい
• その他の事例
  • Grand Theft AutoをAI自動運転のシミュレータに使う。ゲーム → AI → 現実世界。GTAにあるまじき安全運転
  • 先読み。二人の人物が写ってる写真から、その後、ハグするか握手するか殴り合うとかを予測
• 手書き数字の類推。1文字を元に、同じ特徴の1〜10を作り出す

見覚えのある事例もあったのですが、全部のリンクを探しきれておらず、このまま公開します。追々時間があったら追加していくかも知れません。

デジタルゲームの調整・デバッグ・品質管理における人工知能技術の応用

続いて、株式会社スクウェア・エニックス 三宅陽一郎氏の講演。こちらも事例のリンクを探しきれておらず。

デジタルゲームの調整・デバッグ・品質管理 における人工知能技術の応用 from Youichiro Miyake

www.slideshare.net

• ゲームの中のAI
  • メタAI
  • キャラクターAI
  • ナビゲーションAI
  • ここ15年くらい研究され、使われている
• ゲームの外のAI
  • 開発工程を助ける
  • バランス調整
  • 可視化
  • シミュレーション
  • データマイニング
• 時系列では、ナビゲーションAI、キャラAI、メタAI（2007ごろ)、外のAI（2015ごろ）の順にできてきた
• 中のAIは、ゲーム機内で動かすものという制限、ゲーム固有のものである等、あまりノウハウが外に出せない
• 外のAIは共通化、社外での研究開発もできるので、最近盛り上がってる
• QA、品質保証。テスターをAIに置き換える動き。ソシャゲの複雑化、オープンワールドのテストなどは、人間がやる限界を超えている
• 中：人力。Scripted AI。人力＋AI技術
• 外：今はまだ、ほぼ人力だが、これにAIを入れていく
  • 出ている事例では20-30%をAIに置き換え。セガさんのオートリプレイで40%くらい置き換えて一億円くらいの効果
  • 50%くらい置き換えられるようになるのでは
  • ゲームの中に手を入れるのでなく、ゲームの外（ユーザ視点・操作）からのI/Oだけでテストするようになる。自動プレイング
• ニューラルネット、機械学習、強化学習
  • ニューラルネットワーク：どの敵から攻撃するか、学習させる
  • 強化学習：行動の結果を取って学習
  • 遺伝的アルゴリズム：集団をかしこくする。『GA Racer』『アストロノーカ*4』
  • NEAT: ニューラルネットワーク＋遺伝的アルゴリズム
    • DeNAさんの『FINAL FANTASY Record Keeper』の例 → 強化学習を利用した自律型GameAIの取り組み ~高速自動プレイによるステージ設計支援~ #denatechcon
    • ゲームのデバッグに向いてる
  • 機械学習：ユーザのログから学習する。『FORZA motorsport』
• 『Assassin's Creed Origins』
  • オープンワールドのマップ検証。オブジェクト500万個の位置関係を検証するAI、placement metrics。夜間に検証して翌朝レポートしてくれる
  • なんとなく安心して出荷できる
  • 負荷テスト、telemetry、負荷が高いところをヒートマップにしてレポート
• 『Thief』
  • ベテランプログラマがつらさを知っていたので、AI testを作った。コードレベルでなく、ゲームのコンテキストレベルのテスト
  • UE4のBlue Prinntで状況を作って、テストを書く。キャラクタAIの行動が正しいかをテストできる
    • Playerが障害物の陰に隠れたとき、回り込んで発見できる、みたいなテスト
• 『Horizon Zero Dawn』
  • 人力でビジュアライゼーションのテスト
  • テスターさんの行動ログと見つけたバグの集約、ヒートマップ、クリックすると動画再生
  • 統計情報を可視化してくれるAI
  • 夜は自動テストAIがオープンワールドを探索
• 『Battlefield』
  • AI向けの荒い解像度の画像を入力にして、AIが行動判断、ゲームコントローラーに出力
  • 強化学習
  • たぶんこの話 → AIエージェントに「バトルフィールド 1」のプレイを教えるには？
• 離脱率
• マッチングが正しく行われているか。選択アルゴリズムの補正。勝率を50%に近づける
• 『Halo 4』
  • 実際にプレイヤーが死ぬ場所のヒートマップを作る。テレメトリでレベルデザイナの意図通りの難易度になっているかを検証できる
• まとめ
  • 中のAI：コンテンツ。作品を作っている（作品の一部である）。自律的、より動的なコンテンツ
  • 外のAI：サイエンス。動的なコンテンツを外から抑え込む
    • ゲーム向けは、先行研究が少ない、アカデミックな知識を援用する場合が多い、個別課題が多い、統一的に解決するには研究期間が必要、共通フレームワークがない
    • 共同研究しやすい、直接競合しにくい

三宅氏はちょうど"SIGGRAPH ASIA"でも講演されており、こちらに記事が出ているので参考になるはずです。

www.gamebusiness.jp

モリカトロンではこれをやります！

最後に、モリカトロン 桑野氏より、新宿テストLabのサービスについてのお話。

• JSTQBのテスト手法を用いた、ゲームデバッグ＆テスティング
• バグを出すことに特化した、エキスパートによる専門チームの設立
• エキスパートチームによるインディーズ支援
• QAエンジニアを配置、開発初期から自動化を見据えたご提案
• モリカトロン独自の自動化ツールの開発
• テスト工程に必要な各種ツール開発

所感

AIや機械学習をテスト自動化に活かす試みは多方面で進んでいますが、元々難しいと聞いていたゲーム分野での現状をまとめて聞くと、これまでなんとなく他人事のように思えていた事例が、とても現実的なものに感じられました。

研究開発費だけでなく、エンジンを内製していないととても真似できない話が多いのは確かなのですが、自動リプレイ＋ビジュアライゼーションだけでも実現できれば、十分価値のある情報が出せそうだということなどです。 少し、数年前のモバイルアプリのUIテスト自動化と状況が似ているかも知れません。

まだまだ、完全自動化という段階ではないとは思うのですが、冒頭に書いたようにうまく機械と人間とで役割分担することでうまくまわる箇所は多いのではないかと思います。 その点、このモリカトロン新宿テストLabの取り組みは現時点での最適解かも知れず、半年、一年後にまたお話を伺いたいです。

*1:先日発売された「プレイステーション・クラシック」に入っているそうです！

*2:持株会社化および組織変更はつい先日ですが、元々モノビット系列で立ち上がった会社と伺っています

*3:具体的に聞いてはいませんので、売ってくれるのかも知れません

*4:森川さんが開発

Android Test Night #5 Androidテスト全書の回 に行ってきました #android_test_night

11月に一般販売が始まった『Androidテスト全書』の著者さん達によるトーク回ということで、年甲斐もなく「ブログ・Qiita枠」で申し込んで参加してきました。

testnight.connpass.com

『Androidテスト全書』は、技術書クラウドファンディングのPEAKSで企画・制作されたAndroidアプリのテスト自動化を中心とした書籍で、11月初旬より製本版の一般販売が開始され、15日で限定セール分が完売してしまったという人気の書籍です。 セールは終わっていますが、製本版・電子版とも下記ページから購入できます。

Androidテスト全書

• 著者： 白山 文彦,外山 純生,平田 敏之,菊池 紘,堀江 亮介,
• 製本版,電子版
• PEAKSで購入する

本書はざっと通読しており、特に以下の観点でおすすめできる書籍です。

• 自動テストの書き方にとどまらず、なぜテストを書くべきなのかといった、「手段」から一歩引いたところから丁寧に書かれている
• JUnit、Mockitoといった基本的なテスティングフレームワークによる基本的なテストの書きかただけでなく、非同期、RxJavaなどに対するテストの書きかたも押さえられている
• UIテストに関して、Espresso、Appiumそれぞれにページが割かれ、差別化されている
• CI/CDの導入も丁寧にかかれており、Firebase Test Labにも言及されている
• JUnit 5への移行、Local Unit TestとInstrumentation Testの統合（Jetpackへの統合）など、少し先にこうなっていくという事項にも言及されている

トークセッション

本会は、SFにいる白山さん（冒頭にビデオレターで登場）以外の著者の方々と、編集の日高さんによるトークで進行されました。

著者のおすすめポイント

• 堀江さん：ツールの使い方とかでなく、CI/CDとは、というところから書いた
• 菊池さん：公式にはまだJUnit 4なのに、JUnit 5を動かせるのが楽しい。個人的にそうゆうのが好きなので紹介した。Parameterized Testは便利で使える。この分量が大きくなってしまって章立てを変えた
• 平田さん：Appiumまわりは、本書のために会社でUIテストやりたい人を募って実際に導入した成果を書いている。さらっと書いてるところも実際は大変だったりした
• 外山さん：UIテスト導入まわりでは、『システムテスト自動化 標準ガイド』（通称「ギア本」）から、最低限押さえておいてほしい点のピックアップもしている。Espressoに関しては、ドキュメントからだけではわからないところもソースを読んだり試したりした結果を書いてある

システムテスト自動化 標準ガイド CodeZine BOOKS

苦労したところ

• 菊池さん：本が出たあと、Gradle JUnit Pluginの変更がどんどん入ってつらい。ただ、本書の記載内容が使えなくなったわけでなく、便利なアノテーションとかが追加された等。執筆期間にGoogle I/O 2018を挟んだので不安だったが、大きな変更はなく安心した
• 堀江さん：仕事との兼ね合い、子育てもあるので時間がつらかった
• 平田さん：執筆中にAppiumのバージョンアップ（1.8 -> 1.9）、uiautomator2 driverのBetaが取れたのはよかった
• 外山さん：Kotlinを使うかどうか悩んだ。執筆当初はコンパイルが通らないところがあり、Javaで書いた。電書版直前くらいに試したらKotlinもコンパイルが通るようになっていた
• 日高さん：読むターゲットの選定。初心者なのかバリバリやってる方か。テストのことをちゃんと伝えたい、わかりやすく書きたい。改訂版の予定はまだないが、売上がよかったらぜひやりたい

PEAKSについて

• PEAKSで書いた書籍を技術書典で売るときにTシャツを作ってもらえた
• 表紙はなぜこうなったのか？
  • 永野さん@PEAKS：わからない
• 永野さん@PEAKS：本書は、他の本に比べてクロスレビューが活発だった

自分以外のセクションでおすすめ

• 外山さん：非同期テスト細かく書いてある、CI/CDとかあまり詳しくなかったので勉強になった
• 平田さん：自身がiOS寄りなので、4・5章が特に、視点が違って面白かった
• 菊池さん：2年くらい前、AppiumでAndroid 4系をテストしようとして辛かったのが、今はよくなってること。Circle CIのManual Approvalsで手動でワークフローのトリガを設定できること
• 堀江さん：1章、テストをなぜ書くのかなど
• 日高さん：企画段階では250ページ、完成400ページ。これでも削ったところもある。技術の変化が早いので古臭くならないようにした。例えばインストール手順のようなWebで得られるところは割愛している。深夜2時に原稿があがって、その時間から相互レビューがはじまるくらい皆書いていた。編集者は、毎回、頭をリフレッシュして読み直すのが仕事

日高さんの編集について

• 堀江さん：編集前160ページのセクションが60ページくらいに減った
• 菊池さん：そこまで減らなかったけど、ごっそり入れ替えとかの指示があると、そこからの辻褄合わせとか大変だった。趣味で小説書いたりしてたので、細かい言い回し等には気を使うほうなるので、その辺りの指摘はそのままにしたところも
• 平田さん：社内でUIテストを導入しつつ書いたので混乱した部分もあったが、羊さんがヒカリエまで来て話したりした。指摘箇所に理由をつけてくれるので納得感がある
• 外山さん：著者脱稿して80%くらいの完成度と思っていたら、その後が大変だった。でも読みやすくはなってた。抽象的でなく具体的に書くべき、みたいな指摘とか

普段どこに気をつけてテストしているか

• 平田さん：QAがやってることを自動にできないかと相談されるが、マニュアルテストをそのまま自動化することは運用まで考えるとROIが良くないので、そこから話す
  • UIテストの安定性。CIに乗せると落ちたり
  • どこまで自動化するか
• 外山さん：課金などのシステムが出すDialog、テストはできるけどGoogle都合で変わるので大変だけど、大事なので押さえたいところ
• 堀江さん：CI/CDで、自動と手動をひとつのフローに乗せるべきか。Circle CIでは手動テストの完了をトリガにワークフローを進めてリリースりたりできるので活用している
  • ZOZOにもSWET(SoftWare Engineer in Test)のような組織はあってUIテストは書いてるけど、CI/CDに統合はされていない
  • 手動テストの人がちゃんと探索的テストに注力できるようなフローにする
• 菊池さん：エンジニア自体が少ないので、UIテストには工数をかけられていない。コストとのバランス

テストを書いたコストがペイしたと思った経験

• 平田さん：自動テストでバグを見つけるのはよくない*1。テストがある安心感と、正しく動いていることが確認できることが良い。安心してリリースできるのが大事。テストが落ちるのは環境的な問題が多い

現場で実現するために大事なこと、チームプレー

• 外山さん：自動テストは銀の弾丸ではないので、Unit/UIテストの仕切りが大事。QAが「全部自動化してほしい」と言ってくることもあるが、認識合わせが大変
  • 日高さん：そのときのキーワードは工数？
  • 外山さん：工数だけではなく、Unitでやるべきだけど構造上できないのでUIでやったり、事情を汲んでいる
• 堀江さん：CI/CDがないところに途中から導入したとき。困っていないか聞いて回って、SDKバージョンを上げるのを躊躇するみたいな話を聞く。テストをたくさん書くより、効果的なところから導入していくようにしている

ライブラリ等のバージョンを上げていくか

• 菊池さん：ライブラリ全般、無理にバージョンを上げる必要はないと思っている
• 外山さん：テスト系ライブラリはわりとカジュアルに上げる

会場からの質問

QAがテストを書くのか

• 外山さん：そうしたいが、まだできていない。Excelにシナリオを書けばテスト実行できるくらいにしたいけど、それを作るとコストが見合わないのでできていない
• 堀江さん：会社に受け入れテストを自動化している部隊がいたが、最近まで知らなかったし、経緯もよくわからない。今後連携していく

テストを書くタイミングについて

テストファーストだと仕様変更で書き直しになる。完成してから書くべきなのか？

• 変わらないところを中心に書くのがいいのでは。永続化まわりとか
• UIのほうはあとまわしにして、Unit Testはテストファーストで書く

GUIでテストを作れるツールについて

• 日本に限らず、増えてきてはいる。どのように使うかによっては使えると思うので、徐々に使えるとは思っている。精度次第？
• Firebase Test LabのRobo testは、だんだんかしこくなってる。単純なアクティビティ遷移でクラッシュみたいなのは検出してくれる

テストピラミッドの各層でしかできない検証について

• Unit Testから入って、CIを導入してから、UIテストにかかればいいのでは。CIは入れるべき

プロダクションのライブラリやSDKバージョンを上げることについて

ライブラリやSDKのバージョンを上げるという話があったが、そのときに問題を検出できるように考慮したテストの書き方はありますか？

• 特にその目的で考慮していることはない
• Firebase SDKを上げたときにビルド失敗はあった。レポートを社内に展開したりはした
• ライブラリのバージョンは、上げてもすぐ元が消えるとかある

テストコードの保守性・可読性

本質的でない部分が多くなったり、そもそも何をテストしたかったのかわからなかったりする。工夫はあるか

• チームが日本人メインであれば、テストメソッドの名前を日本語にすることは有効
  • Instrumentation testのほうは日本語使えない
• 前設定のコードが多くなるのであれば、Mockitoとかのライブラリを使って簡潔に書けるようにする
• テストコードの中を、Setup, Exercise, Verify, Teardownにちゃんと分けて、メソッド抽出したりもする。仕様変更などでSetupがごっそり変わることもあるが、分けられていれば対応も容易になる

註：このあたりの用語は、『xUnit Test Patterns』から。テストダブル（Mock等）のパターンも参考になります。

xUnit Test Patterns: Refactoring Test Code (Addison-Wesley Signature Series (Fowler))

テストのリファクタリングに使う時間はトータル何%？

• 共通化をするくらいで、そう多くはない

(AACの)Repositoryのテストについて

Mockを使うUnit Testでは仕様変更の対応が不安。Repositoryまで統合したテストもするべきか

• OkHttpのMockWebServerを使った統合テストは有効
• Swaggerとか使ってモックサーバを立てる

既存プロジェクトに対してテストをどう書くか

• データ層から進めていく
• セオリーだと、Integration Testなど外側からテストを書いて保護していくが、これは大変。一部アーキテクチャを組み替えながら進められるのであれば、それがいいと思う

所感

会場で質問をされた方の中に「本書を読んでテストを書き始めた」という方もいました。それだけの力のある本が、いい時期に*2書かれたのではないかと思います。

今回のトークセッションでは、著者および編集者の皆さんの熱量（本書に対するものと、テストに対するものの両方）を感じ取ることができ、また共著の大変さを思い出し、改めてじっくり再読しなければ、という気持ちになりました。

本書が広く読まれて（売れて）、改版や、また他分野のテストに関する書籍の出版につながるといいな、と思います。そして、テストを書いてCI/CDすることが当然という世の中が早く来てほしい。

ともかく、著者・編集者、ほか関係者の皆さん、お疲れさまでした。ありがとうございました。

*1:自動テストはリグレッションテストが中心になるので、新規のバグ発見はほとんど期待できないということを踏まえて

*2:ツール・フレームワークの成熟度合いや、Jetpackまわりなど、個人的にそう感じています

Gotanda.unity #8 in ワンダープラネット株式会社 @渋谷 に行ってきました #gotandaunity

五反田で開催されないと定評のある『Gotanda.unity #8 in ワンダープラネット株式会社 @渋谷』に行ってきたので雑なメモと、拾えただけのスライドを貼っておきます。

gotanda-unity.connpass.com

LT #1 シンプルStateMachine

@k-wth さん

docs.google.com

• ステートマシン"1号"、シンプルなうちはよかったが、Stateの入れ子など複雑化し、バグの温床に
• シンプルな"2号"を作った

LT #2 シェーダー芸・入門から1ヶ月の道のり

@nimu026 さん

docs.google.com

• 8月のJAPANLAND花火大会＠VRChatに触発されてシェーダ芸を
• Shurikenでなく、GPUパーティクル？　シェーダ芸？
• Compute ShaderはVRChatに持ち込めない
• phiさんのシェーダ芸
• Vertex Shaderでもなく、Fragment Shaderでもなく、Geometry Shader
• Geometry Shaderで動かしてFragment Shaderで塗る
• ひたすら写経したり改変したり

LT #3 NCMBでオートログインとセーブデータのバックアップ

@azumagoro さん

docs.google.com

• 個人開発ゲーム。v1はローカル保存、v2からNCMB
• JsonUtilityでシリアライズ。EasySaveではList<>を保存できない
• masterから取得できるデータはkeyだけ持っておく（節約）
• NCMBの課金体系が変更されて痛い

LT #4 ObservableパターンからはじめるUniRx

@torisoup さん

niconare.nicovideo.jp

• Observerパターン
• ObserverとSubject、印象が逆なので注意。Subject側が管理してる。Observerは監視・管理はしていない

LT #5 PUN2触ってみた

@otyugen59 さん

speakerdeck.com

• Photon Unity Networking
• PUN2が8/25リリース
• PhotonRx（とりすーぷさん作）
• コールバックが変更されているのが一番影響大きい

PUN は 開発者の Tobias はパンと発音してたけど、日本ではピーユーエヌって読む人が多い気がする

— やまさん(S.Yama) (@syyama_net) 2018年9月26日

LT #6 ここが楽しい/しんどいLive2D CubismSDK for Unity

@traitam さん

docs.google.com

• v2.1とv3.0で互換性がない
• "うちの子・推しを動かせる"のが一番楽しいところ
• ドキュメント、情報発信者が少ない（Editorの話はあるけど）
• 畑を耕さないと

LT #7 Tilemapのアップデートについて

@RyotaMurohoshi さん

speakerdeck.com

早速ブログ記事も

mrstar-logs.hatenablog.com

• 2018.2から、Hexagonal Tile
  • Point top/Flat topがある
  • コンポーネントは同じもので、propertyで切り替えられる
• Isometric Tile
  • クォータービュー
  • まだベータ
  • オクルージョンできる。高さがある

こういうのやりたくないですか！#gotandaunity pic.twitter.com/1H6NBl5qH8

— むろほし (@RyotaMurohoshi) 2018年9月26日

• Let's 人柱！

LT #8 スコープファンクションでコードの見通しを改善する

@yashims85 さん

speakerdeck.com

• 関数に切り出すほどでもないもの*1
• Kotlinの文脈で出てくる
• 引数にselfを渡して、Lambdaの中でプロパティをセットするなどして、selfを返す
  • Also(that => {that.x=0;... return that} とか
• 一時変数が減ってコードの見通しが良くなる
• Null安全

LT #9 4画面出力とレシート印刷で作る体験型デジタルサイネージ

@ksk1030 さん

speakerdeck.com

• マルチディスプレイ
  • ディスプレイごとの設定、リフレッシュレート、アス比
  • UnityのindexとOS上の番号が一以しない。ケーブル挿す順で変わる？
• レシートプリンタ
• Windowsタッチパネルのエッジスワイプを抑止したい→物理的に抑止した

LT #10 Scene操作系のエディター拡張Util2セット

@takumi_hanzawa さん

Scene操作系のエディター拡張Util2セット from Takumi Hanzawa

www.slideshare.net

• マルチシーンエディティングで、アクティブを切り替えるのを2クリック→1クリックに
• シーンの読み込み履歴。ヒストリーウィンドウで1クリックでロード

所感

LT10本、Unityの扱う領域の広さをあらわすように、幅広く、話の被りもなく、とても面白い回でした。

聞いた話が役に立つ日が来るのか？と言われると、まず無い、と言い切れるトークが多かったのですが、それはそれ。役に立つ話を聞くばかりが勉強会ではないと思っているので、このノリは引っ張ってほしいところです。

なかでも、マイノリティな技術の孤立無援っぽい話は共感するところもあり、それでも「畑を耕さないと」「Let's 人柱！」といった前向きな言葉がよかった。

また次回は2ヶ月後ということで、何かネタがあればまた登壇も検討しようかという気持ちになったと同時に、前々回のフォローアップ記事をまだ書いてないことを思い出したり…

関連資料

Unityゲーム プログラミング・バイブル

*1:個人的には「関数に切り出すほどでもないもの」は関数に切り出すほうが好きです。テスト書きやすいし

フォトグラメトリでバ美肉(1.5) Qlone

フォトグラメトリツールの紹介・比較をしていくつもりはないのですが、例外としてひとつだけ。iOSおよびAndroidで動作するQloneというアプリについて。

www.qlone.pro

対象は小さい物体に限りますが、ガイドに従ってスキャニングし、クラウド上で3Dモデル生成までやってくれるアプリです。アプリ自体は無料で使えますが、生成された3Dモデルをobjなどの形式にエクスポートするのに課金が必要です。

フォトグラメトリについてや注意事項などについては、前回の記事を参照してください。

スキャニング

撮影には、専用のマットの印刷が必要です。これはアプリから直接AirPrintか、pdfファイルを取得して自分で印刷します。被写体をマット上に置いて撮影するのですが、A4サイズのマットで高さ10cmくらいのフィギュアが限度です。

A3サイズで今回の被写体（高さ17cm）がなんとか収まりましたが、それでも上部のえんぺらあたりがキレイにスキャンできませんでした。

また、被写体の向きを変えて（フィギュアを倒して）もう一度スキャンすることが推奨されていますが、A3マットの場合スキャン中に数回（恐らくメモリ不足で）アプリが落ちたので、今回は1回だけスキャンしています。

これで、148,343頂点、581,760ポリゴン、テクスチャは2048x2048が1枚です。

エクスポート

エクスポートは、スキャンしたモデル単位にアンロック権を購入する形式で、1モデル¥120から無制限¥2,400まで。obj, stlのほか、iOS 12から使えるUSDZ形式*1にも対応しています。

なお、アンロックはモデル単位ですが、アプリ内でモデルの複製を行なうと権利もコピーされます。

また、Sketchfabへのエクスポートも可能です。アンロックしていないとダウンロードできない設定、アンロックしているとダウンロード可能設定でアップロード・公開されるので注意。 SketchfabのProアカウントでは試していないので、privateにできるかは未検証です。

エクスポートしたモデルをBlenderで見るとこんな感じ。テクスチャは余りキレイではないものの（これは撮影環境の問題も大きい）、メッシュはそれなりに取れています（うまく辻褄を合わせている、が正しい気もしますが）。

胴（頭足類なので）の上のほう、えんぺら周辺のメッシュが荒いのは、恐らくA3サイズマットでの限界なのだと思います。

リサイズツール

Qloneにはある程度の加工ができるツールも実装されています。例えば、編集 - RESIZE - Simplifyでポリゴン数の削減もできます。

削減前1（148k頂点、582kポリゴン）

削減後1（62k頂点、174kポリゴン）

かなりメッシュの大きさにばらつきがありますが、自動でやってくれます。3DF Zephyrのリトポロジー機能と違って触手の先などのエッジはキープされるようです。

削減前2（148k頂点、582kポリゴンのはずですが表示がおかしい）

削減後2（34k頂点、100kポリゴンくらいのはずですが表示がおかしい）

その他のツール

テクスチャのペイント、スカルプティング機能もありますが、やはりスマートフォンでの操作には限界があると思いますので、素直にPCのツールでやるほうがいいでしょう。

ほかに、ボクセル化の機能もあります。

所感

意外とメッシュは取れていて驚きました。モデル単位の課金というのも使いやすいですね。PCでのリトポロジーやレタッチ前提で、メッシュのアタリが取れるクオリティでいいといった条件では十分実用的ではないでしょうか。

ただ、大きめの被写体にはそれなりのサイズのマットを印刷して用意する必要があることと、大きくなるほどアプリが落ちやすい*2のが難点です。

参考

いかレスラー

*1:SafariでリンクするだけでAR表示もできるアレ

*2:スキャンを試したのは数週間前なので、すでに改善されているかも知れませんが