継続的E2Eテスト #Seleniumjp

スライド

www.slideshare.net

はじめに

  • 自動テストを継続的に行うのって難しいですよね?
  • 自動テストはキャズムを超えた
  • やり始めるのは簡単だが、継続していくというのは大変
  • 技術的な話というよりも、運用で気をつけてきた点を話す

継続のポイント

  • メンテナンスコストがかかる

メンテナンスコストがかかる

  • テストが動かなくなった
  • NGが多発する
    • テストの分析が走るはず
    • 分析そのものが時間がかかる
      • テストを諦めてしまう
    • SUT updateをする
      • これも時間がかかる
      • リリースサイクルが早いと、メンテナンスコストが追いつかない
    • テスト環境が変わる
      • これを意識しないと大変なことになる
      • 対応してSeleniumそのものバージョンを上げたりする
  • メンテナンスするものはたくさんある

メンテナンスを効率よくするために行っていること

  • 毎日動かす
    • リリースが毎月1回とかでも動かす
    • 動かしていないと大変
    • 変化に敏感になる
  • 不安定を排除する
    • 特にテスト環境
    • WindowsのOSを再起動する
      • 溜まっていくメモリを開放するため
  • 常に調査する
    • OSSのバグなどを敏感に知っておく
    • ナレッジ化して社内の人が知っておくようにする
  • 対応の速さ
    • テストが落ちた時に、次の実行までに解決するようにする
  • メンテナンスしやすい仕組みにする
    • OSSSeleniumでページファクトリーでメンテナンスしやすくするのもそう
    • Updateした時に動作確認をする場所が常にある

テストの価値が低下する と感じる要因

  • デグレが見つけられない
    • テスト設計・実装の見直しを積極的に行う
    • 実行頻度を開発プロセスと同期する
      • 開発者が意識していくと、「テストが○時に動くので、それまでにMRを通そう」となったりする
  • NGが多すぎる

    • 環境起因でのNG
    • メールの表題が毎回同じだと、鈍感になったりする
  • 自由にテスト実行ができない

    • テスト実行環境を複数用意する
    • 自分で直した時に確認できるようにする

テストが継続しない最大の要因 = 担当者がいなくなる

  • 「部署は残っているのですが、担当者がいなくなったので一から作り直しています」とかある
  • 自動テストは属人化する
  • 一つの案件に対して複数人をアサインするようにしている

Let's step into the OSS community #Seleniumjp

スライド

www.slideshare.net

クックパッドについて

  • 日本だけでなく世界でもサービスを提供している
  • Rubyを使っている

OSS活動について

  • 今はOSSに貢献している
  • 入社前は全然コミットしていなかった
    • 利用していただけ
  • 最近はどんどんOSSのコミットをしている
  • Appiumのコミットを盛んにしている

Appiumのコミュニティについて

  • 様々な人が存在している
  • コミッター
    • Rubyのコミッターの一人として松尾さんがいる
    • あくまでもコミュニティの一つのユーザー
  • 質問に回答している人もいる
    • Githubのissue
    • Appiumのdiscussionのサイト
    • Appiumに関するチャット
      • コミッター同士ではSlackで行っている

OSSの貢献について

  • 松尾さんの最初のPRはiOS8の不具合修正(2014 Oct 14)
  • タイポ、スペルミスなどのプルリクも貢献のカタチの一つ
    • 例えば、Elixerでは、コロンが抜けていたのでPRを送った経験もある
    • OSSをメンテしているのも人なので、間違いはある
  • 慣れていくと、もう少し大きな修正をしたりする
    • Google/earlGreyでは、大きな不具合修正をした
    • リリースノートに自分の名前が載った!
  • 質問に回答したりケアするのもOSSの貢献の一つ

  • OSSの貢献では英語が主体にはなる

    • このSeleniumコミュニティのように地域ごとにあるコミュニティもある
      • 英語が苦手なら、こういうコミュニティに入ってケアするのも貢献の一つ

E2E自動テストの長期運用に耐えるための5つの手法 #Seleniumjp

スライド

www.slideshare.net

モバゲーのプラットフォームについて

  • 数千万人の会員がいる
  • 3rdパーティーの開発のためのサービスを提供している

モバゲーのプラットフォームの経緯

  • ブラウザのゲームからスマホゲームに移行している
  • まだまだ沢山のユーザーがモバゲーのプラットフォーム上で遊んでいる
  • 課題として、高いアベイラビリティ後方互換性を少ないメンテナンスコストで行っている

規模感

  • 5年経過
  • 22個のテストスイートが分かれている
    • 機能毎に分かれている。
      • 会員登録とか
  • 700個のテストケース
    • 決済とかログインとかはしかkりテストしている
  • 60000個のAPIのテストケース
  • 開発者はサーバーサイドのリリースはQA無しでリリースできる

運用について

  • テストスイートがどういう経過を辿るか分かってきた
  • QAの一部として作り始める。
  • リグレッションテストとして回り続ける
  • 1年ぐらい経つとテストが壊れ始める
  • 自動テストが完全に壊れるテストスイートが出てくる
  • 出来る限りちゃんと動く期間を長くするようにする

どうすれば長期運用に耐えられるようになるのか

  • とにかくテストを流し続けましょう
  • 1日1回は最低限回すようにしている
    • 定期的に実行しているぐらい安定していないといけない
    • なかなか通らないテストは安定化しましょう
    • 開発環境が変わったなどをいち早く検知するため
      • 壊れた瞬間が一番直しやすい
  • どうしようも無いテストは諦める
  • 既存のリグレッションテストの100%グリーンを拘らない
  • 環境に依存するようなFlakyなテストとか
  • 直す工数が大きいが得られるメリットが小さいものとか

できるだけ早くテストをデバッグしたい

  • 出来る限りテストのデバッグが出来る人を増やす
    • 一番長く使われるテストは、開発のプログラミングテストと同じ言語にすることだった
  • テストのインフラはしっkり確保しよう
    • 1回回すのに1時間かかるものとかは無しで
    • 失敗したテストケースのみ流せるようにする
    • 失敗時のログを出す
  • Selenium Gridが活躍している

Debuggability

  • Zalenium
  • 実行のデバッグが見やすいようになっている

テストの実装とテスト対象システムの実装を疎結合にしたい(これからやりたいこと)

  • WebAPIはメンテしやすい
    • APIサーバーに依存しにくいから
  • Seleniumでテストを書こうとすると、テストコードの中で表現しないといけない
  • 取り組み
    • イトクローラを用いて、本番プロダクションのデータを持ってきて、それを正解データとする
      • 正解データはGithubに入れる
      • 別のブランチでプルリクする
        • GitHubが勝手に差分をしてくれる
    • 自然言語処理を使ってフォームを解析する
      • ICST2017で得たネタを使っている

re:反復開発

勉強会告知ページ

connpass.com

スライド

speakerdeck.com

自己紹介

  • @m_seki
  • XPプログラミングを16年ぐらいやっている

クックパッド

  • 2015年にイベントをやってた
  • 秋山さんが論文を書いてた
    • 開発チームの中にテストエンジニアを配し…テストの現場の理想型の一つと思う
    • 開発者もテストエンジニアも不具合を減らし、
    • このようなチームを@m_sekiさんが持っている

Agenda

  • 反復開発の基本
  • 上手くやることのヒント

本当はなにに困っていますか?

歴史

  • 2004年には会社の理解が無かった
  • 2008年
    • 川口さんが上手くやり始めた
  • 2016年のJaSST
    • 「Scrumは上手く行っているがプロジェクトは上手く行っていない」
    • →反復開発が上手く行っていないみたい

障害を想定したい

  • 今日の会場は「変わりたくない層」ではないと思うことにした

反復開発ができてないのでは?

  • まず、反復開発を説明するべきかもしれない
  • Scrumとか色々な名前の手順書が出てきたのに、それを使いこなせてない

プロジェクトが終わったとき

  • どんなことを感じますか?
    • こうすれば良かった…とか
  • もう一度やったらうまくいくような気がしませんか?

ウォーターモデル

  • 図だけ引用されることが多い。
  • 実は「戻りはnステップですよ」と書いてある
    • 工程は1ステップずつ進むけど戻りはnステップ
  • 同じ工程は何度も起こる
  • むしろ2度作りましょう
    • 1回やって分かったことを使って本番の開発をしましょう
      • 2度作ることで色々活かせることがある

期間を半分にしてみる

  • 期間と内容を半分にして、2回に分けて開発したら?
    • なんだかうまくいきそう!

工程別の不具合の調査結果

  • Royceの図はテストは1つ
  • この資料ではV時モデル風
  • 原因工程と発見工程の違い
    • 原因は上流工程が60%強
    • 下流工程で75%発見
      • 企画・仕様・設計の問題をその時に見つけるのは難しい
      • テストは問題を見つける能力が高い
  • 試して分かることは試す
  • 試さずに調べるのは高コスト
  • 中間成果物(ドキュメント)をあてにするのは危険
  • 試してみたほうが安いので、上流工程で頑張るのはコストがかかる

利用する

  • 工程と時期を分けて考えてみよう
  • システムテスト・運用テストをより早く
  • 結合された状態でのテストを早く、頻繁に行うために反復型の開発を行う

期間を半分にしてみる

  • 1/2、1/4、1/8としていって、どんどん小さくしてみる
  • V字を行うにあたって、どこまで短くできるか考えてみる
  • 時期ざっと並べて開発するのと同じ

やり方視点

  • V字モデルの全行程をやるのが1反復
  • 小さな動くシステムから始める
  • 強のシステムを次の反復で改造する
  • じわじわ開発するのとは違う
    • V字の下部分しかやってない
    • @t_wadaが言っていることを信じちゃうやつ
  • V字の一番底だけを繰り返すもの
  • うまくいってそうに見えるのがやっかい
  • 例えば、「ブランチで作業することで、結合時の問題を避けている」という状態になったり

システムを改造する単位

  • 確認ができ、数日で終わる仕様を作る
  • ストーリー毎に全行程を行う
    • 部品、フレームワークを先に揃えるのは✕
    • ストーリー単位に必要なものを用意するのが○
  • 住みながら増築していく感じ
  • アプリケーションとフレームワークが同時に進む

製品を反復毎に確かめる

  • 不具合を確認するだけではない
  • 製品を前にして様々なことを発見できる
    • 製品の意味とか
    • この製品はどういうものだったのかとか
  • 顧客の欲しいものは顧客もよくわからない
  • 実装の問題もよくわかってない
  • 最初から分かるはずがない

プロセス=チーム

  • 出来上がって製品によって、要求が変わったりチームが変わったりする
  • チームが変わったことでどんな効果があったかを製品を見ることによって分かる
  • 要求を変えたりチームを変えたりするには、製品を作る必要がある
  • 全部が成果!
    • 製品はもちろん成果だが、その作り方とか、その途中で分かってきた要求仕様とかも成果物になる
      • 2008年では膨大なテストスイートも成果物だった
      • 自動テストではなく、手動テストだった

製造業であれば…

  • おそらく自社製品
  • 3つの成果を活かしやすい
    • 良い仕様の開発は非常に難しい
      • 何が使いやすいのか
    • 製品寿命が長い
    • 開発期間が長い
      • チームが長生きする
  • 数ヶ月でAgileとかは難しいと思う

チームの変化

  • 反復毎に何かが変わる
  • メンバーのちょっとしたふるまいの変化とか
  • わざとらしい変化以外もあったりする

やろうとすると難しい

  • よく知られている話だけど実践するのが難しい
  • なので、m_sekiならではのヒント

反復開発ならではの問題

  • プロジェクトの初めから終わりまでに起こる問題が5日間の中で発生する
    • ごまかせない。目をそらす時間がない

壁?

  • 世界のエリートは大事にしないが、普通の人にはそこそこ役立つビジネス書

おすすめ→無理をしない

  • 無理そうなことは無理そう
  • 3つの例を示す
    • サブシステム間のペースの違い
    • 工程別のチーム
    • ストーリーの分割

ペースの違い

  • 大きなシステムでは全員同じペースではないかもしれない
  • ペースの違いから揉めがち
  • 実はペースを混ぜても大丈夫
    • 結合された状態で確認するという原則を守っていればね
  • まだ結合されてない部分はリスクとして持っておけば良い
    • あるチームだけ確認した内容は信じない
  • 反復が綺麗に揃うことはあまり重要でない
    • そんなところでは揉めない
  • 隣のチームのペースを無理に変えない
    • スムーズに行っている自分達が合わせる
  • となりのチームもサボっていないのでイライラしない
    • となりのチームは遅いのではなく、実はタイミングが合わないことへの不満が多い
    • 質問しても返事が来ないとか
      • 相手の都合を聞いてみよう
  • どこまでがチームなのか、チームの切れ目に意味があるのか?
  • となりのチームの人達も同じチーうの人達のように考えましょう
  • チームの境界を曖昧にするのが吉

工程別チーム

  • ロール別にチームを作ったり…
    • 開発者とテスターとか
  • なんとなく仲違い
  • 遠慮とか不信感が…
  • 担当する工程がうまくいっているかどうか製品で確認する
    • 自分達の工程だけ上手く行っている状況はあり得ない
  • 前後の工程のチームがうまくいくように気を使おう

開発に関わる活動

  • 以下の5つ全部!
    • 欲しいものを実現する
    • 仕様を具体的にする
    • 実装を考える
    • プログラムを書く・直す
    • テストする
  • 5日間の中に全ての工程がある
  • ソフトウェア開発の加圧動画そのままロールになった
  • こうなるのが自然
    • 5日間でやるとなると自分でやらざるを得ない
  • ほかのロールは?
  • やらないことが違う
    • テスターの場合、「プログラムを書く・直す」だけがない
  • テスターは劣化プログラマか?
    • テスターならではの価値がある
    • 開発者に比べ…
      • 領域が広い・深い
      • テスターの方がより長い時間製品を触れる
      • 製品全体を触れる
      • 手触りの一貫性をイメージしやすくなる

ストーリー

  • 要求の分割のテクニック
    • 練習しないと難しい
    • パターンは存在する
  • ルール
    • 結合したシステムで確かめられること
      • 部品だけのストーリーを作らない
    • 何かしらの価値が増えていること
  • 作戦
    • 起動、主処理、終了までの最も単純なフローを見つける
      • まずはこれを作る
      • 最初は起動と終了だけ作る
        • 設定ファイルは…とか面倒なものが多い
      • その後、徐々に増築し、単純なフローを完成させる
        • 起動の面倒なものが多いので、それが終われば主処理のコードに集中できる
        • なるべく早い時期に心配な処理が試せるように工夫する
        • 枝葉を気にせず幹(中心となるもの)を作る
    • 基本フローから徐々に枝葉を増やす
      • 幹無しで枝が生えないように、いきなりリンゴを作らない
  • 階層のあるチケットはオススメしない
    • 入れ子になりがち
    • なんとなくかっこいい!
      • しかし確かめられない…!
        • 進捗が分かっても確かめられない
    • 個人の進捗は確かめられるが、製品の出来は確かめられない
  • いつも結合テストを可能にする
    • 手に触って完成した様子が分かるようにする
    • 新しいものが載っていることを確かめたい
      • 個人の進捗はどうでも良い
      • 「進んでいる」と言う割には分からない
      • 「どうやって確かめるの?」と聞いてみると良い
        • 「実は確かめられないです」「ダメだね」となったりする
  • ボタン一つは価値があるの?
    • システムが壊れていないことは分かる
  • できるだけ早く喜ばれるものにしたくなる
  • 向かい合うことは大事!

質問

チケットの粒度について。チケット1つが価値を届けるものになっているのか?それともストーリー?

  • ユーザーが確かめられるものが一単位
  • チケットはストーリー、バグ、タスクの3種類。そのうち、ストーリー、バグは確かめられないことが書いてある。
    • タスクは確かめられないもの。ほとんど書いていない

イテレーションの最初は考えるものが多いと思うが、最初はユーザーに届ける価値が無いのでは?

  • ボタンを押して起動して、終了できること
  • 少なくともWindowが出てくること

受託開発をやる場合は、お客様が出した要件通りにやらないといけない。3ヶ月でとかだと難しいのでは?

  • 難しいと思う。
  • 3ヶ月経って作ったもの見せて「ああ、ダメだね」となったり。
  • 「早く気付くために期間を半分にしてみよう」と提案するとか

ストーリーと価値の話について。「ボタンを押して起動して動くものを提供する」というものは、ストーリーを繋げて話すと思うが、お客様としては繋がらないと意味ないじゃんと言われるのでは?

  • 「価値」というと難しくなるので、「変化が分かる」と言ったほうが良いかも
  • ユーザーのゴールは一番細い線ができること

今のやり方に組織が変わるきっかけはあったのか?

  • 全員がやっているわけではない
    • 最初にやっていたのは、V字のテスト部分のみをやっていた、それによって開発が変わったりする

じわじわ開発について。非機能の部分とかも反復の中でやっているのか?

  • 非機能の多くは分けていない。
  • パフォーマンスはもはや非機能ではない。パフォーマンスはほぼ毎日触る。
  • ただ、できないのもある気がする。
  • できないものは「できないなぁ」と思っているようにする。

エンタープライズアジャイル勉強会のきっかけは?反復開発できていないと気付いたのはどこで?

  • テストのイベントでテストエンジニアが開発と話をしていないことがわかった
    • 永田さんから「これが普通なんだよ」と言われた
  • プログラマの話は、プログラムの話はあってもプロダクトに興味を持たない

ストーリーを扱うのは1本だけか?

  • 最初は少なくしていたが、どんどん増える

徐々にテスト工程が増えてくるのでは?

  • やるべきテストスイートを集めてきて優先順位を付けるツールを作った

テスト工程を全なめするわけではない?

  • 全体をカバーしているが、全なめするわけではない

疎にしていると思うが、そのアルゴリズムはどういう風にしているか?

  • 最近触ったものは暫くしなくてよいとか
    • だいたい通っているものは下がっていく
    • rateを決めていて、rateが高いものは頻度を高くするとか

ストーリーの分割が難しい。「DBにアクセスしないといけない」とか、「インタフェースを切り替えたい」といったようなものは、どういうタイミングに行うべきか

  • 増築していくと辛いから整理したいときとかで。

その結果、何が良くなるのか?

  • 次の増築がやりやすくなる

リファクタリングしたい」という要望が出る場合は?ストーリーなどが書けないと思うが…。

  • それで何ができるの?
  • 言ってくる自体怪しいよね

増築するとぐしゃっとなるのでは?

  • 数日で終わる経験が多い。それだけ大ジャンプしてないのかも。
  • 限定的にするように話をすり替えているのかも

大企業だけど新規ビジネス開発をモブプログラミングでやってみた #xpjug

スライド

speakerdeck.com

カンファレンス

  • カンファレンスは発表者に直接聞けるのが売り

現地

  • 真ん中の写真は従業員ボード
    • 自分ができること、出来ないことを書いている
    • 付箋には、他者からのコメントが書いている
  • 右側の写真は技術について、TDDとかBDDとかカンバン、リファクタリングとか

Hunter社のモブプログラミング

  • 社内に6つぐらいモブが存在する
    • 川口さんが現地に行った時には8つぐらいになってた
  • 1つのモブに付き3〜5人
  • 隣のモブは全く別の技術領域
    • CDの話
    • UIの話
    • サーバーサイド
    • 製品の制御系
    • Android
  • 常にモブプログラミングをしている
    • この時間はモブプログラミング、というような働き方ではない

環境

  • 大きいモニタ2枚と、長机
  • 楽天では、ディスプレイ2枚とPC
  • エンジニアは1日中タイピングしていることが無くて、だいたい調べているはず

作業内容

  • 分担を決めてやると、他作業者の同期の時間がかかる
  • モブの場合、常に同期をしている状態
  • お客様のところへ行くと、人事の人がほしいと行っているものに、発注者と利用者が違うので、欲しいというものに違いがある
  • モブプログラミングでは作る量に限りがあるので。
  • 業務担当者から要望が出ない
    • 業務担当者はソフトウェア開発をしているわけではないので、時間がない
  • バグ=思いもよらない挙動なので、予想できない
  • コードの量に比例してバグの量が増える
    • 一番良いのは作らないこと
  • やり方を直すようにしている
  • 打ち合わせの後に、伝言ゲームを使ってクレームが来た
    • クレームがくるのは良い。伝言ゲームを辞めろ

10年ぐらい出てから気付いたこと

  • お客様は成果物の想像が出来ない
  • 引き継ぎは問題の強調解決しないとできない
    • 2週間や1ヶ月では、業務手順は引き継げるがスキルは引き継げない
    • 問題が出てきた時点で、どうやって解決するか話し合う必要がある
  • 人は忘れやすい生き物なので、備忘録は必要
    • 手順を書くだけでなく、どうしてその手順が必要なのか書く
  • 情報ラジエータとして壁に貼る
  • モブプログラミングはコード・情報・情報ラジエータ・ヒトが必要

取り組んでいること

  • 全員で客先に行く
  • 「来週は何がほしいですか?」と聞く

質問

  • 誰もいなくなっちゃう場合には怒らないのか?
  • モブプログラミングは評価と紐付いている。誰もいないところに参加するだけで、評価が上がる
  • リーダーはいるか?
  • それっぽいヒトはいたが、明確に決めているかどうかは分からない

【基調対談】ワークスタイル改革を実践者する二人が、働き方の本質を語る #xpjug

はじめに

  • その場で聞きながら書いたため、間違っている箇所があるかもしれません。
  • 指摘箇所があれば、コメント等でお願いします。*1

自己紹介

倉貫

  • XP祭りは10何年参加している
  • いつの間にかスタッフだといわれ、スタッフMTGに参加していたらいつの間にか会長になってた

  • 働き方という話

    • 社員の半分が全国で在宅勤務&コミュニケーションはチャット
  • 働き方改革と改めて言われても、昔からやっているので質問されても困る

青野

  • サイボウズで代表をしている
  • 元々プログラミング少年だった
  • MSXを購入し、大学はコンピュータ・サイエンスを学んでいた
  • 1年先輩の同研究室の畑慎也さんのプログラムを見てショックを受けた
  • 松下電工に入社したが、120人に対してPCが3台しか無かった。
  • macのパワーブックを自費で購入して、GW後に持ち込んだ
  • インターネットのブームに乗って、新卒3年で辞めてサイボウズを起業した
  • 16年ぐらいプログラミングはしていない
  • 「働き方」とか興味ない

  • 最初の頃のサイボウズは良い感じでブラックだった

  • 25%ぐらいの離職率があった
  • 社員に「ワガママ言って」と伝えたら、「残業したくない」とかいっぱい要望があった
  • 色々やったら5%ぐらいまで減った

  • 電通の事件があって働き方改革に注目された

  • 昔も死ぬ例があったが、今は厳しい。
  • 残業をさせないために、「帰れ」と言って、責任逃れをする
  • 最近、「働き方改革に関するお詫び」の広告を出した。
  • 働き方改革が曲解されてると感じている

倉貫

  • 昨日もコードを書いている
  • 学生時代からベンチャーで働いている
  • それまで家庭教師や寿司屋のバイトをしていた。
    • 自分の性格と合わなかった
  • よく考えたらプログラミングでバイトを募集しているな
    • プログラミングで遊んでいたらお金になる
    • こういう仕事いいな
    • 一生プログラマーでやりたい
  • 就活時は就職氷河期だった→大企業に行こう
  • 独立系SI&オブジェクト指向ができる会社
    • →オージス総研or東洋情報システム(TIS)だった
  • 99年はプロジェクトマネジメント全盛期だった
  • 2000年問題があったので、プログラマが必要だった
  • 入社直後、「これからTISはマネジメントの会社になります」という方針を聞いて「えっ!?」となった
    • 配属しようと思っていた部署も3月末で廃止に
  • 周りは「IT業界に入りたい≠プログラミングやりたい」だった
  • マネジメントが出世コースなので、マネジメントやります
  • 社内で合う人がいなかったので、社外に出たらXPJUGがあった
  • 参加したら、社内のマイノリティの人がいっぱいいた
  • 社外に出ると、物差しが増える。社内だと上司しか物差しがない
  • すごいと思う人がお酒を飲むと普通のおじさんだった
  • 発信しているうちに、社内でも面白いやつがいるとウワサになった
  • 「色々やってクビになろう」と思ってた。
  • 真面目な働き方が分からない

青野

  • 社内ベンチャー時代にお会いしたことがある
  • 独立後「納品のない開発」とか、おかしなこと言ってるなと思ってた。

「納品のない開発」について

倉貫

  • TISから独立した頃は、仕事は自社開発のものだけだった
  • せっかく独立したので、まずは会社のビジョンを考えよう
    • リーダーがどうこうではなく、乗組員の顔を見て決めればよい
      • 独立した5人が全員がプログラマだった
      • 一生プログラミングをできる会社に
  • 営業とかマーケティングが必要だった
    • 用もないのに人の家に行くのが辛い
      • 受託開発するしかない
      • ただし下請けはヤダ
  • 開発は繰り返しをすべきだなぁ
  • けど1回こっきりの納品がある
    • お客様も納品した後に言ってくるし
  • 儀式で納品しているだけなのでは?

  • 最初発表した時は「意味が分からん」「そんなのでうまくいくわけないでしょ」と言われた

  • 「無理でしょ」と言われると頑張りたいと思った
  • 理解してくれる顧客も出てきた

  • 例えば、電力自由化によって、電力会社が自由に作れる

  • 東京電力がメーカーになって、小売業者が作れるようになった。
  • そんな電力会社が顧客に
  • 1人で電力会社の基幹システムをRuby+AWSで作ることになった
  • SIerの場合、電力会社の基幹システム=数億となっていた
  • 電力会社も投資して…とか
  • 電力会社の仕様は頻繁に変わるので、ウォーターフォールでやっていると全滅してた

青野

  • PJの失敗するだけならまだしも、死人が出ているのはちょっとね
  • やらされ感が出てくる仕事があって、喜びを奪っていた

倉貫

  • お伺いを立てないといけない
  • WFの上流で決めた人は楽しくやってる
  • 夢語っているうちはそりゃ楽しいさ
  • 最後までケツ吹けば良いのに逃げていく

  • 社員でプログラムができる若者は使い勝手が良い

  • 上手く行ってないPJは本当に最初から上手く行ってないのか?調べてみた
    • 下流「3ヶ月前に決まった仕様だから直せない」
    • 下流「設計のコミット、フィックスが出来なくて、けど次の工程に流さないといけない」
  • 上流に行けば行くほど清らかな世界
  • 最上流「お客様も夢があって、うちの会社も協力して、毎日飲みに行ってた」

青野

  • 仕様をなかなか決めない
  • 大きいところは、お客様にも決断を求める
  • お客さんも参加意識が出る

  • 上流と下流が離れるほど責任感が薄くなる

倉貫

  • 1週間分だけお客様に決めてもらうようにしている
  • 1周間分がダメだでも、すぐに修正ができる

現場寄りの話について

青野

  • 開発のことを聞かれても知らない
  • ちょうど、目の前の席に社員の天野がいるので、話してもらう

天野

  • サイボウズkintone開発の天野です。
  • kintoneは1年前にスクラムを導入した
  • 前までは作って出荷していた
  • クラウドは3ヶ月で出荷
  • 高速WFになってて辛かった
  • 今は2週間のサイクル
  • 社長がスプリントレビューに参加
  • QAの部門が大きいが、試験を順次回しているようにしている
  • 3ヶ月の出荷サイクルが1ヶ月の出荷サイクルになった

青野

  • 今はホワイトボードだらけ
  • 総務部門も
  • 我が家でもホワイトボードがあったりする
    • 夏休みの最後にWF的にリリースしますからね
    • 見えるようにしたが、やらないことはやらない
    • けど、9月4日には宿題を終わってた

倉貫

クラウドを扱うようになって、社内も変わったのでは?

青野

  • 一番変わったのはDevOps
  • 前までは運用はお客様任せだった。
  • スキルもないし、やりたい人がいなかった
  • クラウドになったら、運用もやる必要が出来た
  • 作るところでも意識するようになった

倉貫

  • 開発から運用へというようなキャリアになる?

青野

  • 今はないが、運用の人も開発ができるようになっていかないといけない

倉貫

  • 創業時は開発と運用メンバが分かれているが、5人だけだと運用メンバが暇になる
    • →開発やるか
    • Rubyを勉強し始めた
  • 開発者は運用が開発をし始めると「俺らの存在って…」と思うようになった
  • クラウドになるとプログラミングの延長でサーバーが用意できるようになった
  • Rubyなどになると、メモリのことを気にしなくなったり、OSSで色々できるようになった
  • クラウドOSSによって、開発と運用のハードルが低くなった

青野

倉貫

  • メンテが別人だと、「ちょっと良いかな?」と思ってしまうが、自分自身が運用することになると「ヤダ」となる

納品なくして、オフィスをなくしたが、今度は何をなくそうと思うか

倉貫

  • 次は管理をなくそうとしている
  • 経営はするが、管理はしない
  • 管理されるのは嫌だし、管理するのは面倒
  • 部署がないので中間管理職がない
    • 「中間管理職」という言葉が悲劇の元
    • だって、中間で管理ですよ!?
  • 指示命令がない
  • 自分で考えて自分でやる
  • 有給も自分で申請&承認
    • だって、上司が有給却下することないじゃん
  • 会社のクレジットカードを全社員と共有した
  • 社長も含めて全社員の経費利用状況がオープン
    • 「良いもの食ってる」と見られちゃう
  • 個人評価も無くした
    • 評価が面倒
  • 「お前、何を分かるねん」と。
  • エンジニアは評価をされにくい
    • 良いコードはビジネス的にすぐに評価されない
    • メンテ時に初めて価値が分かる
    • その時は評価されにくい
  • 「コード量少ないんじゃない?」→「コピペしたろうか」となる
  • 給料も山分け
  • 売上目標も無し
  • 結果、社長の仕事が一気に減った
  • 社員との面談も無くなった
  • 今はストレスフリー

青野

  • 基本給は?

倉貫

  • グレードはある
  • 弟子・見習い・一人前の3段階しか無い
  • それぞれのグレードの中は一律
  • 勤続年数でおまけが付く(しかし上限付き)
  • 「いつかはすごい給料になるから、今は我慢して」は無理。
    • 経済も成長してないのに。
  • 「給料上がらないから、欲しい人は副業して。」と言ってる
  • お金は十分与えているので。
  • 給料格差はない。
    • 地方だからというのも無いので、地方に移住する。良い車に乗ったりしている
    • 昨年末、スノーボードやりたいから長野に移住した社員もいる
    • 2月頭に「何回スノーボードしたの?」と聞いたら、「40回行きました」
      • スノボ、仕事、スノボ、温泉、仕事

働き方改革

青野

  • 星野リゾートの社長の提言として「働き方改革ではなく」「休み方改革」にすれば良いのでは
  • 「この時期の雪は良いから、この日に休みたい」とかになるはず

青野

  • 自分で考えて、自分でやって、自分で責任を持つ
  • 自分でPDCAを回す

倉貫

  • 自分で考えなくちゃいけない中で、会社でサポートする?
  • そういうこというと、外を見て会社を辞めちゃうかも

青野

  • 「あなたのキャリアはどうしますか?」と考える機会を半年に1回設けている
  • 「他の部署に行きたい」となったら、本部長の異動会議に載せる
  • 「今もう少しここの部署でやった方が…」とかもあるが、そういう話の結果もフィードバックとして本人に伝えている

  • 本人からキャリアチェンジを言い出せない人もいるが、上司からの逆ドラフトもある。本人は断っても良い

  • 自立して欲しいが、引き出す、ファシリテートを組織で作り出せれば

  • 出ていくと、人件費が減るんですよ。(笑)

  • 出ていく人に対して悪いと思わないほうが良い

  • 去った後に成長してれば、良かったなと思う

倉貫

  • 洗脳ではなく、魅力があるから辞めないようにするのは、すごいが魅力を作り続けないといけない

青野

  • 大企業の退職金は20年を超えた後に伸びる

倉貫

  • 普通、目標を管理すると思う
  • サイボウズさんは評価の面接ではなく、キャリアの面接なのが良い
  • 目標の面接にすると、設定を低くするはず

    • 自信家だった自分は、高いハードルを達成しなかった自分は評価されない
  • 私たちはYWTを(やったこと、わかったこと、次にやること)を話す

  • 仕事の成果を話していても意味が無くて(評価しないから)、得意・苦手を見返す機会を作る

  • 学生時代までは3,4年に1回、進路相談の機会があったが、大人になったら進路相談をしなくなる

  • 半年に1回進路相談の機会を作ろう

  • YWTは若手とベテランで違う

    • 若手はキラキラしたことを言う
    • ベテランは「向いていないことが分かりました」と言ったりする
  • 普通の会社の面接では言えないこと
  • 「これ出来ません」と言ったからには、次やることを一生懸命やる
  • そうすると不適合な人が集まるが、何か尖っている人がいる方が会社として良い
  • 弱みを見せるのが大事

青野

  • 自分の向いていないことに気付くと、得意な人を尊敬する
  • 別の部署の大変さを知らないからギスギスする
  • 営業の副業でカレー屋さんやってる人もいた

倉貫

  • 奥さんがパン屋さんをやっているが、そんな奥さんが大好きだからリモート勤務すると言った社員がいる
  • 木・金はパン屋の仕込みという副業をしている

青野

  • パン屋の仕事きたら活躍しますよ
  • プロトコルがあるんで。

倉貫

  • そのパン屋が通信販売を始めた
  • ソニックガーデンの先着販売も告知があった
    • つまり、社内で商売を始めた

質問①

質問者

  • 「倉貫さんの話の中で、クラウドになったことで組織も変わる」とあった。
  • どうやってものが出来るか分かっている社長さんですが、「俺に分かるように説明してくれ」という経営者をどう思うか?
  • なぜかソフトウェアを分からない人が経営していることが多いと思うが…

青野

  • 日本が遅れている理由の一つがそこ
  • なぜなら、これらをコストとして見ているから、
  • そういう会社は沈んでいくしか無い

倉貫

  • 社員が不幸だと思う
  • だって、説明するのが面倒
  • 管理してないので、Githubを見れば良いとなっている
  • サイボウズさんもスプリントレビューに出てるのが良い

質問②

質問者

  • マネージャはどういう風にしていけば良いと思うか?

倉貫

  • 今後のキャリアとして、1人で複数のスキルセットを組み合わせて仕事をしていくようになるのではないか
  • 例えば、今の副社長は社内のバックオフィスを作りながら仕事している
  • kintoneを使っているので、JSを開発するだけで、運用はサイボウズさんに任せられる
  • 中小企業の社長さんから働き方改革を聞かれるが、「まずはムダなことをなくしましょうよ」と言っている
  • 他社はチューニングしないところが多い。
  • 今まではやり方が分かっていなかった総務の人が、やり方を伝えるだけで改善ができる

  • 昔は「社内SE」と言っていたが、「業務ハッカー」という言葉にすればかっこいいと思ってもらえる

  • マネジメントの組み合わせる内容の一つ

青野

  • 今までのマネージャがマネジメントと称していたのは相当効率化できる
  • マネージャがいらないわけでなく、マネージャはビジョンを作って共感してもらう
  • 倉貫さんはビジョンを発していて、メンバが共感している
  • 風土を作るのがマネージャの仕事
  • より次元の高いマネジメントにシフトしないと、これからの組織はまとめられない

質問③

質問者

  • マイクロマネジメントな仕事をしていて、マネージャが優秀で成果が出ているが、組織として見た時に歪な形になっている。
  • 下が育たない。自分の経験が正しいと思っているマネージャをこういう場に連れてくるためには?

青野

  • 働き方改革は2年前ぐらいまで人事の人が聞きに来たが、2年前ぐらいからは経営者が聞きに来た。
  • 今年は情シスの人が聞きに来る。
  • 徐々に波が広がってきている。
  • もしかしたらそのマネージャも気付くかもしれない。
  • 確実に前進している。

質問者

  • 殺し文句は?

青野

  • 人手不足がはっきりしてきた
  • 「このままだと採用できない、このままだと辞めていく」

質問④

質問者

  • 「マネージャをなくしたよ」と言うと「仕事がなくなってしまう」などの受動的になってしまいがちだと思う。
  • 社員の方々は、会社に入る前からその意識だった?それとも会社に入ってから意識が変わってきた?

倉貫

  • 中途採用は働き方に共感して入ってくれる
  • 応募から入社まで半年から1年かかる
  • その間に似た考え方か見る

  • 新卒は学生なので、働き方についてはわからない。

  • 0からなので、会社の責任として育てる
  • 「会社は潰れるかも」「自分で考えて成長する」「どこに言っても通用する力は提供する」
  • と伝えれば、会社が潰れても納得してもらえるなと。

青野

  • 会社が潰れても社員がいきいきとする状態になるのが良い。
  • 元々技術力が高い人が入ってくるわけではない
  • The・サラリーマンな社員がいる。
    • 「副業したら?」と言ったら、「辞めろと言っているんですか?」と言われた
    • 結局、その人も副業探しの旅に出たりした。
  • 機会を与えるようにしている

倉貫

  • 副業はお金が入ることよりも、自分が自信を持てることが大事。

まとめ

青野

  • すごく楽しい時間でした。
  • ITエンジニアはもっと評価されるべき
  • そして逆らうべき
  • もっと給料上げろと声をあげるべき
  • 声をあげることで社会が変わるはず。

倉貫

  • オファー頂いた時に、「XP祭りで青野さんで大丈夫ですか?」「ここに連れてきて良いのか?」と思っていたが、杞憂だった。
  • 小井戸さんには「遊んでいるのか働いているのかよくわからないね」と言われたが、それは正に私がやっていること
  • 働くこと自体が楽しいとなれば、本当に革命になる
  • 「働き方改革を提言できるのはエンジニアだからでしょ?」と言われる。
  • 確かにそういう側面がある。
  • だからXP祭りの会場は話しやすい。
  • 皆さん、やりやすいんです。
  • 昔は資本家が言って、労働者がいる
  • 今は逆転している。エンジニアの方が価値が高い
  • お金を持っている人よりもスキルを持っている人の方が価値が高い。

  • 好きな場所で働けるかどうかが大事。

*1:既に @Mura_Mi さんに多数ご指摘頂きました。本当にありがとうございました!

Selenium Committer Day 2017『Q&Aパネルディスカッション』聴講レポート #Seleniumjp

勉強会の告知ページ

seleniumjp.connpass.com

  • 今回の記事では、この勉強会の中のQ&Aパネルディスカッションの内容を記載します。
  • 同時通訳の人の言葉を基に書いているので、若干内容が不足している可能性があります。

進行方法

  • 質問に対してパネリストが応えていく形式
  • 質問は以下のサイトから投稿&投票が出来る

app.sli.do

  • 得票数が高い質問から行う

回答者

  • 3名ともSeleniumのコミッターです。
  • Jim Evans(以下、JIM)
  • Marcus Merrell(以下、Marcus)
  • Manoj Kumar(以下、Manoj)

SeleniumプロジェクトとAppiumプロジェクトは統合する予定はあるか?

JIM

  • Noです。
  • SeleniumプロジェクトはDesktopのアプリケーションの自動化。
  • Appiumプロジェクトは目的が違うので統合する予定はない」

Marcus

  • 自分の会社ではすべてのプロジェクトをモバイルも含めて統一したプロジェクトに入れたが上手くいかなかった。
  • 結局、デスクトップとAndroidiOSを分けて管理している。

A/Bテストの話にもあったように、今後テストの対象の質が変わってくるように思います。例えば確率的に振る舞うもののテストや、機械学習のように時系列で結果が変わってくるようなものなど。今後どうしたらこうしたテストを生産性高く行えるでしょうか?

Manoj

  • 面白い質問です。
  • A/B Testingで色々なこと、クレージーなこと、異なるDOCKERイメージでパフォーマンスで比較して…とか。
  • Marcusさんもアナリティクスの話で、どちらのユーザーフローが良いのかなどを行っているが(どうですか?)。

Marcus

JIMさんのセッションで、Selenium 4でオープンソースではなくなるところがある、といったことをお話しされたような気がするのですが、少し聞きもらしてしまいました。その部分について、あらためて説明してもらえないでしょうか。

JIM

  • Seleniumプロジェクトですが、これは常にOSSです。これは強い意向を持っている。
  • ただし、コンポーネントの中のブラウザが提供しているものについては話が別。
  • 例えばEdgeDriverとかはMicrosoftが開発しており、ソースコードをリリースする決定はなっていない」

JIMさんはアルバムをリリースしているとのことですが、どういう音楽のアルバムを出しましたか?

JIM

  • いくつか出しました。ロックです。今はもう活動していませんが。
  • 例えば、{複数のグループの名前、聞き漏らした…}などのアーティストと似たような音楽です。

Marcus

  • 全然理解できませんね。

JIM

  • じゃあ、リリースした音楽についてのリンクを送りますね。

ヘッドレスブラウザが登場した時はどう思いましたか?また、皆さんは使っていますか?

JIM

  • もしもお客様が『WEBアプリの自動化したい』、そして『ヘッドレスブラウザもテストしたい』と言ってきた場合、『なぜなんですか?』と聞きたい。
  • 『ヘッドレスブラウザだと速くなるんですか?』とも聞きたい。実は速くならないです。
  • もう一つ聞く質問として、『あなた(JIMさんが相手にしているお客様)は、ヘッドレスブラウザを使ってサイトを訪問したことがありますか?』と。おそらく『NO』と答えるでしょう。
  • なのでヘッドレスブラウザのテストをする必要がない。
  • ただし、ヘッドレスブラウザが出てきた当時は各ブラウザにオプションが無かった。それが、つい最近変わった。
  • 例えばGoogleChromeでヘッドレスモードが出来た。これはChromeの一部の機能であることを意味しているので、そうなると話が変わるかもしれない。Chromeのヘッドレスモードができたということなので。
  • 私は日々のTestingで使う時、全く同じコード、振る舞いになった場合、それは魅力的になっていくと思う。

Manoj

  • 私も同じ意見です。

Marcus

  • これはメンテナンスも大変。競争性もないかもしれない。

JIM

  • UI、ブラウザレベルの自動化の目的としては、実質的なセーフティ、あるいは予測するセーフティだと思っている。
  • ヘッドレスブラウザを使うとき、使いやすいか?

司会者

  • コレに対して反論がある方…。3人を前に反論しにくいですよね。

伊藤さん*1

  • 海外で使っている事例はご存知ですか?

Marcus

  • 私自身は知らない。
  • 外資系の仕事もしていてが、ヘッドレスブラウザを推奨している立場でもあるが、辞めたほうが良いと伝えている。

海外の会社では、1つのWebサイトに対して幾つくらい自動テストを作りますか?

Marcus

  • 一番成功した導入テストとしては、ユニークなIDが全てあった時。
  • ナビゲーションが成功しているか、ちゃんとレンダリングしているかの確認で約1200通りやっていた。
  • これが2009年の話。現在も同じソフトウェアでやっていたので、今でも使っていると思う。

Manoj

  • アプリケーションも機能テストも含めて1万ぐらい(?)*2
  • これが全体の20%にあたる。
  • テストピラミッドに対しても明確な答えとして出ている。

JIM

  • 大手のグローバルで行っている企業で働きましたが、ブラウザで適切に表示されているかどうかについては、どこかで線を引かないといけない。
  • ブラウザレンダリングのバグも存在するので。それについては私たちは制御できない。
  • 何を制御するのか。ファイルをダウンロードするのは制御できるもの。
  • それでは無い部分などはブラウザベンタが制御するものかもしれない。

Marcus

  • 例えばユニークなHTMLが表示される場合、ソフトウェアアーキテクトはhtmlをQA側にも提供して、シームレスにできるようにするとか。
  • QAというのは、自分達の立場、リクエストを主張してこなかった。投げかけられるのを待っていた。
  • QAがきちんとテストするということをQA側が主張すべき。

「独立したテストはどのように作っていたのか?」

Marcus

  • このセッションはあと何時間ぐらいできますか?

司会者

  • あと30分ぐらいですね。

Marcus

  • この質問に対して語るには時間が短すぎますね(笑)
  • 例えば私達はテンプレートとしてVelocityを使っている。これを用いて開発者が作成している。
  • 一方で、私たち(QA)はPage Objectを作成した。
  • コードをチェックインする前にPage Objectを作成する。
  • それを用いて自動化で何か壊したか確認する。
  • Simon Stewart*3は生成には否定的だった(?)*4

JIM

  • Page Objectという言葉に誤解がある。
  • システムが何を生成するかというと、ページラッパーを生成する。その上に適切なPage Objectを作成すると。
  • 開発者は簡単にこういったelementのロケーションを提供するならば、各人によって楽になる。
  • このようにしてテストが壊れにくくするようにする。

Marcus

  • ページのマップを生成するようにしている。
  • テストが壊れてしまうかをチェックする。
  • そうすれば、新しいマップを更新するだけになる。
  • 通常のテストだとチェックインした1日後ぐらいで行う。
  • 開発者が12ページのワークフローを作成していた時に、1日の終わりの前に自動化のコードを書き始めることができた。
  • このようにして壊れにくいようにしていた。

JIM

  • 私が作っていたものでは、壊れやすいロケーターを確認するような企業が無かった。
  • 私がそこをチェックし、説明し、教育していた。
  • コーディングの標準を守って欲しいが、そこを分析するまでは出来ていなかった。
  • あまり自分がやるべきではないことに時間をかけるべきではない。
  • Dave HaeffnerさんがSeleniumConfでデモしたツールがあるが、非常に素晴らしいソフトウェアで、静的分析をSeleniumで実施してくれる、Runtimeでレポートを出してくれる。
  • 静的分析の結果、このコードは良いものである、ロケーターがしっかりある、というようなツールを作っている。

Marcus

  • Locationという名前のツールである。

司会者

  • ここらへんの話は掘り下げて聞きたい人が多いと思うので、それは懇親会などで聞ければと思います。

docker seleniuminternet explorerイメージはありますか?

Manoj

  • あればいいですね

Marcus

  • 本当ですね

Manoj

  • もしもUNIXでできるならばIEでできるかもしれないですね

JIM

  • ここの課題は素晴らしい。
  • これが変わらない限り、WindowsベースやMACベースの話なのですが、コンテナがおそらく無いと思います。
  • テクノロジが追いつく必要がある

Manoj

イメージはすべてあるが、UNIXのコンテナベースなので。

Selenium IDESelenium Builderの今後の動向を知りたいです。ちょっとした作業の自動化に便利です。

JIM

  • これは(JIMさんの発表の中で)少し話したと思うが、Selenium IDEはテクノロジーとしては古い。
  • Selenium Builderはもっとモダンなものにしようとしていた。
  • しかし残念ながら、ボランティアの仕事なので、中心で開発している人達はプレイバックのツールに興味がない。
  • Selenium IDESelenium Builderはユースケースがあり便利なものだが、ライブラリを作る、テストコードを長期的にできることに意義がある。
  • ソフトウェアテスト業界に25年以上に努めているが、コードを再生し、的確、適切、そして維持できるものは無かった。
  • 例えば、これが壊れてしまったのでもう一度レコードするというのは、長期的に維持できないことを意味する。
  • 学ぶ段階で使う。
  • プロジェクトチームが認識していることとして、レコードツールが無くても使えるようになったと考えている。
  • それには気付いているが、優先順位は高くない。
  • とはいえ、これをどうやって前進させるかということは話している。去年のSelenium confの後に1日話し合った。
  • コードが生まれてきているわけではない。
  • ただし、現状のSelenium IDEのコードを見たが、このコードを現状のまま使い、さらに前進させることを見ているチームもいるが、まだ時期尚早。
  • 具体的なスケジュールを言うことは出来ない。いつか。まあ、クリスマスまでにはあるでしょうね(笑)*5
  • 期待に添える答えではなかったと思う。それを欲していることも知っている。ただしタイミングとしては妥当ではない。

Marcus

画面の「見た目」のテストについて、有効なソリューションや、今後どうなっていくかについて意見はありますでしょうか。今はDOMの計算済みスタイルや画面のスクリーンショットをスナップショットとして保存し、正解として使うアプローチがあると思います。

JIM

  • 長い間、ビジュアル系のテストをやってうまくいったこともあるが、比較がfuzzyであるべきところはfuzzyで、正確なところは正確であるべき。
  • 誰かが『1px変えた』とかに対して上手くいったこともある。
  • 適切なスクリーンショットを提供すると比較するオプションを提供しているツールがある。
  • Mongoテスト(?)というものもある。残念ながらそのプロジェクトが今は存在していないが。
  • また、スクリーンショットではSeleniumでは課題がある。
  • そもそも『スクリーンショットを撮る』という行為がブラウザによって解釈が異なるからだ。
  • あるブラウザでは現在の画面表示域のみを見せてくれる。別のブラウザではスクロールする部分も含めたフルページを見せてくれることもある。
  • しかしフルページに意味はないと思っている。現在はスクロールし続けられるページがあるので。
  • ちなみにW3Cではビジュアルポートという項目で定義している。どんどんW3Cに従ってしていると思う」

地獄に落ちろと思ったブラウザまたはそのバージョンは、今までにありましたか?

Marcus

  • 時間が無いのでちゃんと答えられないね。(笑)

司会者

  • それでは時間になってしまったので、このセッションはこれで終わりに…。

JIM

  • Firefox48とIE7だと、(締めのコメントを司会者が話している間に)3人の中で合意できました。(笑)

*1:日本Seleniumユーザーコミュニティ会長

*2:聞き間違えた可能性あり

*3:Selenium WebDriverの生みの親

*4:ここらへん、メモがきちんと取れていませんでした…

*5:SeleniumConf in 2013でSelenium3.0は「クリスマスまでにリリースする」と発表したが、何年のクリスマスまでにリリースするとは言っていないという笑い話を使ったジョーク(実際は2016年にリリースした)。今回のSelenium Committer Day2017でも頻繁にこのフレーズが登場した。