DZoneの自動化テストのガイドブックを読んでみた
海外の知人からの紹介で、『DZone's 2019 Guide to Automated Testing: Facilitating Continuous Delivery』というガイドブックを読んでみました。
2019年版とちょっと古めではありますが、
- 2021年の現時点でも、実務で参考になる／役立つ点が多かったこと
- 日本国内で、同ガイドブックのまとめ記事を見つけられなかったこと
- 自分用にメモを残しておきたかったこと
から、個人的に気になった点やポイントをまとめてみました。
What Is This Guide?
- IT系情報サイトのDZoneが2019年に発行した、ソフトウェア業界における「自動化テスト」（Automated Testing）*1に関するガイドブックです。
- DZoneの読者約500名に対するアンケートに基づく分析、および同調査に協力したソフトウェアベンダー各社の自動化テストに関する寄稿文で構成されています。
- 同ガイドブックは、DZoneへメールアドレスを登録することで、無料で入手できます。
背景：なぜいま「自動化テスト」か？
- 昨今のソフトウェアプロダクト・サービス（以下「プロダクト」と表記）は、サブスクリプションベースのSaaS（Software as a Service）であることが増え、常時機能追加や変更が行われるようになってきています。
- 常時機能追加や変更を行えるようにするためには、自動化テスト・CD（Continuous Delivery/Deployment）・DevOpsが必須・前提となります。
- 手動テストは、この開発・リリーススタイルでは、どうしてもボトルネックとなりがちです。
Executive Summary & Key Research Findings
読者のアンケート結果から、自動化テストに関する以下の傾向がみて取れます。
- 「Shift Left」の拡大
- SDLC（Software Development Life Cycle）において、自動化テストの開始時期が早期化しつつあります。
- 開発フェーズから開始：54%（2018年）→66%（2019年）
- ステージング／QA／テストフェーズから開始：31%（2018年）→22%（2019年）
- 加えて、専任のQAを持たない会社・組織が増加しつつあります。（2018年：7%→2019年：44%）
- テストに関する責務を、開発者が持つ傾向が拡大しつつあるとも言えます。
- SDLC（Software Development Life Cycle）において、自動化テストの開始時期が早期化しつつあります。
- どのテストを自動／手動で行うか？
- 自動
- 統合テスト（Integration Tests）
- コンポーネントテスト（Component Tests）
- 性能テスト（Performance Tests）
- ユーザストーリーテスト（Story-level Tests）
- 手動
- ユーザ受け入れテスト（User Acceptance Tests）
- 使用性テスト（Usability Tests）
- ユーザストーリーテスト（Story-level Tests）
- Deploy後のテスト（Post-deployment Tests）
- 自動
- 自動化テストの優先度の向上
- 過去の調査結果では、会社・組織における自動化テストの優先度が低くされがちという課題がみられました。
- 一方で今回の調査結果では、自動化テストを優先しない会社・組織が減少しつつあります。（2018年：33%→2019年：28%）
- TDD
- 2018年の調査では、TDDを会社・組織内の全てのプロダクトの開発に適用するという回答者が多かったです。
- 一方で2019年の調査では、TDDを全てのプロダクトの開発に適用する回答者は減り、選択して一部のものに適用する回答者が増えています。
- TDDとDevOps専任組織との相関関係
- 会社・組織内にDevOps専任組織がある場合の方が、ない場合よりもTDDの採用率が高いです。
- DevOps専任組織の有無と、自動化テストを阻む要素との関係
- DevOps専任組織がない場合：自動化テストの作成自体が大きな障壁になっています
- Test execution and Orchestration
- Test report and analysis
- Maintaining a stable and up-to-date test lab
- Test automation creation
- DevOps専任組織がある場合：いかに自動化テストを（会社・組織全体に）広め、実施結果レポートを分析するかに視点が移っています
- Maintaining a stable and up-to-date test lab
- Test automation creation
- Test execution and Orchestration
- Test report and analysis
- DevOps専任組織がない場合：自動化テストの作成自体が大きな障壁になっています
How to Test What Matters
テストカバレッジ（Test Coverage）に潜む品質面の課題を指摘し、その上で我々は如何にして品質の高いプロダクトを実装すべきか？についてまとめられた文章です。
- 課題
- 解決方針
- 以下のようにプロダクト自体の実装を工夫することで、品質を高めることができます。加えて、ムダなテストスクリプトも減らすことができます。
The Four Keys to Achieving Parallelization in Automated Testing
自動化テスト、特にSelenium WebDriverのUI E2Eテストスクリプトを並列実行できるようにするためのポイントについてまとめられた文章です。
- 課題
- テストスクリプトが増えすぎると、テストの実行時間が延びてフィードバックを迅速に得られなくなる「Slow Test問題」が発生しがちです。
- この問題を放置し続けると、自動化テストが敬遠されるようになり、最悪の場合自動化テストそのものが実施されなくなり破棄されることがあり得ます。
- 解決方針
- テストスクリプトを並列実行できるようにすることで、実行時間を短縮します。
- Atomic
- ユースケースシナリオに準拠した全ての画面遷移および全画面項目を検証するE2Eテストスクリプトではなく、そのうちの単一の画面遷移と項目だけを検証するテストスクリプトを作り実施することです。
- E2Eテストの例
- 1ケースで、以下の全てを検証する
- ログインページへ遷移する
- ユーザ名の入力欄が表示されていること
- パスワードの入力欄が表示されていること
- ログアウトのリンクが表示されていること
- 商品をショッピングカートへ追加できること
- 1ケースで、以下の全てを検証する
- Atomicなテストの例
- ログインページへ遷移し、ユーザ名の入力欄が表示されていること
- ログインページへ遷移し、パスワードの入力欄が表示されていること
- 同じ検証内容で、Atomicなテスト180ケースとE2Eテスト18ケースとを用意して実行時間を比較したところ、前者が後者よりも8倍速かったとのことです。
- Autonomous
- テストスクリプト間に実行順序の依存関係を作らないようにし、単独で実行できるようにするということです。
- 実行順序に依存関係がある例（上から順番に実施が必要）
- 商品の注文を確定させる
- 上記の注文を取り消す
- Autonomousな例（順番に関係なく実施可能）
- 商品の注文を確定させる
- （上記とは関係なく）商品の注文を取り消す
- 実行順序に依存関係がある例（上から順番に実施が必要）
- テストスクリプト間に実行順序の依存関係を作らないようにし、単独で実行できるようにするということです。
- テストデータの冪等性
- テストデータは、テストスクリプト実行前に読み込み、実行後に破棄するようにする、ということです。
- 上述のautonomousなテストの前提にもなります。
- Selenium WebDriverのテストスクリプトでは、Javaのstaticキーワードを使用した変数・メソッドの使用を避ける
- Atomic
- テストスクリプトを並列実行できるようにすることで、実行時間を短縮します。
Executive Insights on the State of Automated Testing
ガイドブックの締め括りとしての、自動化テストの今後の課題です。
- 自動化テストのスピードと品質を高める必要がある
- 自動化テストの標準・ベストプラクティスが不足しているため、これを充実させる必要がある
- 自動化テストを、CI/CDパイプラインおよびDevOpsと統合することで、その効果をさらに高める必要がある
- 自動化テストの焦点が、UIテストからAPIテストへシフトしつつある
- 自動化テストを担う人材が不足している
個人的メモ
- 自動化テストに関するメトリクス
- 総テスト量
- 単位時間あたりの実施テスト数
- テストの実行時間
- テスト全体
- 1テストあたり
- 手動テストの実施時間と自動化テストの実施時間との比率
- ガイドブック内の「バズワード」
*1:テストに関する用語の翻訳は、『ソフトウェアテスト標準用語集（日本語版）』（Version 2.3.J02、JSTQB技術委員会訳）を参考にしています。
怒りを感じた時にできる「ちょっとした」工夫
「最近怒りっぽくなったな〜（アカン）」という自省に基づくポエムです。
事例
皆さん、このような経験はありますか？*1
- 上司から、隣のチームへ書類を提出するよう頼まれた
- 実際に書類を提出してみると、隣のチームから「この書類はなんですか？」と言われた
このような場合、私は即座に「なんですかとは何だ」「何で事情を把握していないんだよ」「バカにしているのか」と考え、怒りを感じがちです。*2
ポイント
上記の事例は、自分の前提と違うことが起きたことが、怒りのきっかけです。
- 上司は、隣のチームへ、私から書類が提出されること教えているはずだ／べきだ
- 隣のチームは、書類が提出されることを知っているはずだ／べきだ
- 隣のチームは、書類が提出されたら受け取るはずだ／べきだ
「〜いるはずだ／べきだ」という言葉が多いですね。
しかし、ちょっと冷静に考え直してみると、上司から隣のチームに話がそもそも届いていない可能性もあり得るんですよね。その場合、隣のチームにとってみては、「書類を出されたけれども何これ？」と反応するのが自然なんですよね。
この種の怒りと付き合う工夫
自分の前提と違うことが起きたら、自分の頭の中にある「〜いるはずだ／べきだ」を探し、それを疑ってみましょう。
- 自分の前提は、勝手な思い込みであることが往々にしてある*3
- 相手も、そもそも困っている可能性がある
- お互いに、共通の問題に直面している可能性がある
その上で、一つ一つお互いの前提を確認し合い、ズレを見つけた上で、一緒に解決策を見つけるようにすると、自分にとっても相手にとってもwin-winになれます。
また、「重要な前提をお互いに共有されていないのでは？」という仮説を立てられると、相手への敵意が減り、問題解決へ意識を向けやすいです。
さいごに
正直、常にこのように振る舞い続けることは、今の私にはまだ難しいところが多いです。
一方で、国籍・バックボーンが異なる人たちとのやりとりの増加、会社・組織のスケールアップ、物事の複雑度の向上など、連絡の行き違いや前提のズレは、昨今どうしても増えがちです。
なので、自分の前提と違う場面に遭遇したら、自分の前提を一旦「脇に置いて」*4、お互いの前提のズレを見つけることに注力すると、怒りよりも知的好奇心を高められ、結果課題を解決しやすくなります。
参考資料
ＮＶＣ 人と人との関係にいのちを吹き込む法 新版 (日本経済新聞出版)
- 作者:マーシャル・Ｂ・ローゼンバーグ,安納献
- 発売日: 2018/04/20
- メディア: Kindle版
- 作者:加藤 一二三
- 発売日: 2019/10/03
- メディア: 単行本
カンファレンスのプロポーザルの書き方！2021
今朝起きてスマホをみたら、しいばさんからこんな通知が届いていました。
たしかに @hageyahhoo さんのプロポーザルはいつも伝わってくる。すごいよなぁ。
— Mitsuyuki Shiiba (@bufferings) 2021年3月13日
Scrum Fest Osaka のプロポーザルを世界最速で眺める https://t.co/yDPIQDRahR
教えていただいた「Shinagawa Agile Talks」で、47:30くらいから、確かに私のセッションプロポーザルの書き方を、参考例の一つとして紹介していただいていました。
「お手本になるプロポーザル」として紹介していただいた例は、こちらになります。
https://confengine.com/conferences/regional-scrum-gathering-tokyo-2021/proposal/14621/tips-of-product-management-for-internal-tools
ちょうど良い機会＋需要も多少ありそうですので、私が意識・工夫しているカンファレンスのプロポーザルの書き方のtipsを、以下に簡単にまとめてみました。
1. アウトラインが中心
アウトラインは、プロポーザルを書く際に一番重視している箇所です。
なぜならば、自分を知らない人たちに対して、自分が提供したいトーク・ワークショップのイメージを、最も「いきいきと」伝えられる箇所だからです。
具体的には、以下のような工夫をしています。
- セッションの全体構成を、ツリーで表現する
- ミーティングの前に、参加者にアジェンダを共有することと同じです。
- どのようなトピックを、どのような論理構成で伝えるつもりなのかを明示できるため、プロポーザルの内容をよりクリアにできます。
- プロポーザルが通った際は、これをベースに資料を作れば良いため、時間を節約でき、より良い内容にブラッシュアップし続ける余裕を生み出せます。
- 各トピックの、おおよその時間見積もりを明記する
- 上記のツリー情報を、さらにイメージしやすいものとして伝えやすくなります。
- カンファレンスの運営側に対しても、タイムスケジュールやスタッフの方の仕事量などを把握しやすくするメリットを提供できます。
- プロポーザルが通った際は、資料のページ割り当て量の参考にできます。
- アイデアの伝え方も明記する
- どのタイミングで
- 例：1章の最初に
- どのように伝えるつもりか
- 例：xxxという質問を参加者に出し、アイデアを出してもらう（3分）
- その結果セッションをどうしたいか
- 例：参加者が、xxxという課題をより「自分ごと」として理解しやすくなる
- 例：参加者が、xxxという課題をより「自分ごと」として理解しやすくなる
- どのタイミングで
アウトラインは、そのプロポーザルがReady状態であることを明確に伝えられる箇所です。まずはここを最優先で書きましょう。
2. 「一目」におさめる
関連する情報を、画面をスクロールせずに一目で把握できるよう、常に文量とレイアウトを工夫しています。
Confengneを例にすると、以下の情報を、ブラウザのデフォルトのフォント設定で「ちょうど」１画面内におさまるように記述します。
- タイトル ＋ 概要
- アウトライン
- Learning Outcome ＋ Target Audience ＋ Prerequisites for Attendees
- Links
画面スクロールは、文章を読む際のストレスになり、内容把握の妨げになり得ます。そのため、読者に画面スクロールを強いないことは、プロポーザルの可読性の向上につながります。
3. 「3」を保つ
アイデアや箇条書きなどは、極力3つにするようにします。
これは、とあるコンサルタントの方から教えていただいた、提案の選択肢の数が与える心理的効果を考慮しています。具体的には、
- 2つ：少なすぎて、十分考えていないのでは？という不安感を与えてしまう
- 4つ以上：多すぎて、情報を整理できていないのでは？という不安感を与えてしまう
- 3つ：必要十分に考えて整理されているという安心感を与えられる
このような方法でも、読者に心理的安心感を提供し、プロポーザルへの関心・共感を高められます。
さいごに
上記内容は、些細なことに思われるかも知れませんが、大きな差を生む小さな工夫です。
実は、私の過去のプロポーザルも、内容自体は皆さんとあまり差がありません。それでも私のプロポーザルが採択されたことが多めだったのは、このような「見せ方の工夫」を他者よりも意識して実践していることにあると認識しています。
これ以外にも工夫していることはまだまだありますが、いずれも他者のプロポーザル・資料・発表内容を観察し続け、自身が実験を繰り返して検証して身につけていったものです。
ヒントは、あちこちに転がっています。皆さんもそれらに目を配らせ、自身のプロポーザルのスタイルを確立してみてはいかがでしょうか。
テキストベースでの自身の仕事・時間の管理術
先日、会社の同僚たちとの雑談で、「お互いに日々の業務で工夫している仕事・時間の管理術を紹介し合ったら面白そう」という話になりました。そこで、私がここ7-8年実施している工夫を、以下に簡潔にまとめてみました。一つでも読者の方のプラスになるアイデアがあれば幸いです。
1. SetUp: 一日の業務を始める時
毎朝、以下のルーティンを実施しています。
1) その日の仕事をリストアップする
認識・把握している範囲で良いのでリストアップします。会議など時間が決まっているものは、実施時間も明記します。
2021/03/06 ・部の定例MTG（15:00 - 16:00） ・A機能のPull Requestのレビュー ・B報告書の提出
2) 仕事を実施する順に上から並べ替える
併せて、実施時間が決まっている仕事には、🔴などの一目で分かる印をつけます。
2021/03/06 ・A機能のPull Requestのレビュー ・B報告書の提出 ・🔴部の定例MTG（15:00 - 16:00）
2. Process: 業務中
1) 実施する仕事に印をつける
自分が分かる印で良いので、これから実施する仕事に印をつけます。以下では⭐️を使っています。
2021/03/06 ・⭐️A機能のPull Requestのレビュー ・B報告書の提出 ・🔴部の定例MTG（15:00 - 16:00）
2) 完了した仕事に印をつける
仕事が完了したら、自分が分かる印をつけます。以下では🟢を使っています。
2021/03/06 ・🟢A機能のPull Requestのレビュー ・B報告書の提出 ・🔴部の定例MTG（15:00 - 16:00）
3) 突発的な仕事が来た場合
システムトラブルなど、当初予定していなかった仕事の実施が必要になった場合は、実施順序を考慮した上で仕事のリストに追加します。また、その日に終えられない仕事が出てきた場合は、次の日のタスクに移動します。
2021/03/07 ・B報告書の提出 2021/03/06 ・🟢A機能のPull Requestのレビュー ・⭐️Cシステムのエラーの原因調査 ・🔴部の定例MTG（15:00 - 16:00）
4) 気付き・発見の明記
後日上長や他チームに共有した方が良い情報などが見つかった場合は、その情報をリストに追記します。
2021/03/07 ・B報告書の提出 2021/03/06 ・🟢A機能のPull Requestのレビュー ・🟢Cシステムのエラーの原因調査 ・💡既存のアラート機能では把握できないもの -> Dチームに改善を依頼する ・🔴部の定例MTG（15:00 - 16:00）
3. TearDown: 一日の業務を終える時
最終的に、以下のようになるはずです。
2021/03/06 ・🟢A機能のPull Requestのレビュー ・🟢B報告書の提出 ・🟢部の定例MTG（15:00 - 16:00）
印を全て削除して、一日の業務を終えたサインとします。
2021/03/06 ・A機能のPull Requestのレビュー ・B報告書の提出 ・部の定例MTG（15:00 - 16:00）
4. 一週間・一ヶ月の業務を終える時
終了した仕事のリスト一週間は、そのまま週報にできます。
同じ理屈で、一ヶ月分のリストは、そのまま月報に活用できます。
一連の工夫の動機
- この工夫を始めた当時、とても一日ではこなせない量の業務依頼・メール・会議依頼が毎日届くようになった時期で、何らかの取り組みが急務でした。
- メール・カレンダー・JIRAなど複数の情報ソースが存在していて、かつそれらの行き来が遅くて苦痛だったため、手軽に一箇所で情報を扱える仕組みが個人的に好ましかったです。
- ちょうど当時、Atlassian社のConfluenceの操作方法を業務上急ぎ覚える必要があり、勉強の一環で少しずつ試してみたところ、徐々に上記の仕組みを確立していきました。
個人的に感じているメリット
- JIRA・Trello・付箋などのタスクボードと比較しても、実施が手軽です。
- 仕事に対する心の余裕を生み出せます。
- 現状把握が容易になります。
- 頭の中にだけ情報がある時と比較して、忘れるのでは？という不安感を解消できます。
- 頭の中にだけ情報がある時と比較して、思い出すためのエネルギーを減らせます。
- スケジュールの調整がしやすくなります。
- 仕事が大量に来たとしても、調整箇所を特定しやすくなるため、考える余裕を持てます。
- 会議など、実施時間が決まっている仕事の見落としを減らせます。
- 作業の実施順序や優先順位を考える訓練にもなります。
工夫の背景にあるアイデア
- 仕事のリストを書き出して、終わったものに印をつけるアイデアは、Getting Things Done (GTD)と、Kent BeckのTDDの本からヒントを得ています。
Test Driven Development: By Example (Addison-Wesley Signature Series (Beck))
- 作者:Beck, Kent
- 発売日: 2002/11/08
- メディア: ペーパーバック
- 一日単位での仕事のリストアップと優先順位付けのアイデアは、スクラムのプロダクトバックログおよびスプリントバックログを、個人の作業に応用してみたものです。「個人バックログ」と雑に呼称しても良いかもです。
- 一日の終了時にリストから印を消すアイデアは、スクラムのバーンダウンチャートをヒントに、毎日達成感を感じられるようにしようというのが狙いです。
- テキストベースを続けていることは、レポート作成の効率化も意識しています。また、社外カンファレンスなどでの登壇資料作りのメモとしても活用しています。
おわりに
上記の工夫は、あくまで私が自身の知識・経験の範囲内で、実験を繰り返して有効だと考えて続けているものです。
もっと他に良い方法は、まだまだたくさんあると思います。
もしより良いアイデアをお持ちの方がいらっしゃいましたら、教えていただけるとありがたいです。
自分自身の答え合わせとふりかえりの場だったRSGT2021
2021年の1月6日（水）から8日（金）まで、Regional Scrum Gathering Tokyo 2021（RSGT2021）に参加させていただいていました。
イベントそのものに関するレポートは既に多くの方が書かれているので、私はイチ登壇者としての視点からの個人的体験をまとめてみます。
※他の方のレポートは、こちらから見つけられます。
1. 登壇による「現場での経験」の答え合わせ
学術や理論を整理して話すことに（私よりも）長けた方々が既にたくさんいらっしゃるので、私は「現場での経験」、特にソフトウェア開発の実務での実験・失敗・発見の生々しい話、実践知にフォーカスしてお話させていただくように心がけています。
特に今回は、「SET」（テスト自動化やDevOpsなど、特に技術的アプローチからアジャイルを推進するロール）として社内ツール群を提案・開発・運用し続けた経験をもとに、社内ツール視点でのプロダクトマネジメントについてお話させていただきました。
開発者主体だとどのような行動・失敗をしがちなのかという情報とその克服案を、アジャイルコーチ・アジャイルを実践中の方・アジャイル初心者の方いずれにも提示して、私自身および参加者の双方に考える場を提供しようというのが、私のねらいでした。
その点では、「SETという役割・チーム自体が私たちのプロダクトとも言える」という視点を得られたことが、私的には大きなプラスでした。
2. 「共に苦しんで共感を育むこと」の裏付け
私は昨年のRSGT2020の発表で、「共感・思いやり」に「compassion」という英単語を当て、
- この「compassion」の語源がラテン語の「compatio」であること
- 「compatio」の意味が「共に苦しむ」であること
- 同僚や支援先チームと一緒に問題解決に取り組んで「共に苦しむ」ことで「共感」を育くみ、課題解決を加速させる
という話をさせていただきました。
これと近しい考え方が、クロージングキーノートの野中郁次郎さんの発表にも出てきて、自分自身の気付きと発表内容に裏付けを得られたことが非常に嬉しかったです。
ちなみに、「共感」に「empathy」の英単語を当てていたら、上記の考えには気付きにくかったです。怪我の功名でした。
3. フラクタルな組織「だった」（いろいろな意味で）
私自身、アジャイルコーチになって「多くの観察から自分自身を成長させられてきた」経験とその喜びから、これを他の人や組織にも広げたいと思い振る舞い続けてきました。
また、私自身が数年前に体調を崩したことから、私がいなくても自律的に考え成長し続けられるチームづくりを心がけていました。私がリーダを務めるSETチームは、それを志向し続けています。
加えて、そのような個人・チームは、上位の組織（あるいは会社）を「乗り越えて」価値を提供し続けられる強みがあるとも考えていました。
これらを「フラクタル」という考え方である程度整理できること、一方で適切な言語化を私自身ができていなかったことで周囲に伝え切れていなかったな〜という反省を得られたことが、今回のカンファレンスでの１番の個人的収穫かもしれません。
というわけで、早速こちらをいま読んでいます。
4. 私だからできる「貢献」を
- より「アピールしやすい」プロポーザルの書き方の工夫・アイデアを、数度にわたってDiscordでお話しさせていただきました。今回のカンファレンスで「話をしてみたい！」と思われた方の背中を押せれば嬉しいです。
- 私なりのプレゼン資料の書き方の工夫・アイデアを、数度にわたってDiscordでお話しさせていただきました。長沢さんとは別の視点から、アジャイルコミュニティに9年ほどいる私自身の「秘伝のタレ」を「伝授」しましたです。
- 参加者の多くに、特にスマホアプリのテスト自動化に悩まれている方が多かったので、「お互いにコミュニティ活動を通じて知見を共有し合おう」と提案させていただきました。ちょうど同僚が同じ目的で「てすらぼ」というコミュニティを運営していたので、こちらを紹介させていただきました。続きはここで議論しましょ〜
さいごに
ちょうどコロナ禍の拡大で判断が難しい状況で、このような素晴らしい機会を提供してくださったスタッフの皆さま、参加者の皆さま、応援してくれた同僚のみなさんに感謝です。
また、Among Usを一緒にプレイしてくださった方にも感謝です。（またやりましょ〜！）
中国のカンファレンスで自社プロダクトを英語で発信してきた
2020/12/20（日）に、中国の「TOP 100 Summit 2020」というカンファレンスで、私たちのチームの新プロダクト「Testable Infra」についてお話させていただきました。
こちらが、カンファレンスの情報になります。
同カンファレンスは、プロダクトマネジメント・テスト・DevOps・SREなど、ソフトウェア開発の幅広い領域の事例を100個集め、それらを4日間かけて発表し合うという、なかなか大規模でガチ幻想をかき立てられるものです。
私のセッションの情報はこちらです。
（バナーは上と同じに見えますが、きちんと個別ページにジャンプします）
こちらが、私の発表資料になります。
今回は、登壇の経緯と、登壇に際して工夫した点を、今後海外で英語でプレゼンしたい！という日本の方むけに説明させていただきます。
加えて、今回発表させていただいた「Testable Infra」のポイントを、アジャイル・テスト自動化・Kubernetesのいずれかに興味ある方むけに説明させていただきます。
1. 登壇の経緯
過去に同カンファレンスに登壇したことのある、台湾の同僚からの紹介がきっかけでした。カンファレンス主催者から彼のもとに「スピーカー候補いませんか？」という打診があり、ちょうど登壇予定だったアメリカのAgile2020がキャンセルになって力を持て余していた私に白羽の矢が立ちました。
※ちなみにAgile2020についての詳細はコチラです
今回は、以下の要因が組み合わさって、登壇の機会を得ることができました。
- 私自身、社内外・国内外での登壇経験があること
- カンファレンスでの登壇経験のある、外国籍の同僚が身近にいたこと
- 登壇に関心がある者同士として、「類友」の関係を築けていたこと
2. 登壇に際して工夫した点
今回は、特に以下の3点を工夫しました。
1) 英語のプレゼン動画での反復練習
特にカンファレンスでのプレゼンならではの英語の言い回しのレベルを高めようと、Youtubeなどにあがっているプレゼン動画を何度も観て、そこで気がついた点を反復練習して、自身の発表に取り入れました。加えて、今回の発表はKubernetesの比率が高かったため、KubeCon（Kubernetesのグローバルカンファレンス）の動画を特に観ました。
2) 関連トピックの会話に慣れる
プレゼンだけではなく、関連トピックのカジュアルな会話や語彙にも慣れようと、特にこちらのPodcastを頻繁に聴いていました。
3) 社内で素振り
本番前に、社内の所属部署で「事例紹介」と称して、発表練習をさせてもらいました。素振りなので失敗しても安心ですし、発表経験自体も積めるので、メリットが非常に大きいです。
また、機会をくれた同僚に対して、お礼と準備万端であることの両方を伝える意図も兼ねました。
3. 「Testable Infra」のポイント
ここでは、発表させていただいた「Testable Infra」のポイントを、3つ紹介させていただきます。
1) テストのし辛さを生み出す3つの要素
これまで長年、様々な会社・プロダクトで、「テストがし辛くてバグを見逃して障害を起こしてしまった」事例と向き合ってきました。それらを整理・分析すると、大体次の3つのいずれか／どれもが原因であることが多いです。
- テスト環境：環境自体がない、準備が面倒、環境ごとの差分が大きすぎてテストを信頼できなくなる
- テストデータ：他の人と共有するとテストを壊す／壊される恐れが高い
- 外部システム：準備しづらい、環境ごとの接続設定の変更が面倒
2) 「Immutable Infrastructure」をCloud-nativeに実現
様々な試行錯誤を繰り返した結果、「Immutable Infrastructure」の考え方を、Docker・Kubernetes・Istioなどを組み合わせることで、上記の問題を解決できるのでは？との考えに至り、「Testable Infra」を構築してみました。
具体的には、Pull Requestが作成されたら、それをテストするために必要なDockerコンテナを作成し、それらをテスト用に作成したKubernetesのnamespace上にdeployし、そこに対してE2E Testを実行する仕組みをまず構築しました。
3) 構築・運用の際の工夫
新規の試みだったことから、以下の手法を組み合わせることで、構築・運用をより「効果的」にしました。
- 開発初期からDevOpsの仕組みを構築し、必要な時に最新の動作するソフトウェアを見せられるようにした
- 「Product Discovery」や「Design Sprint」を活用して、仮説設定・検証を繰り返した
- 失敗を学習機会として積極活用し、プロダクト・プロセスの改善につなげた
※「Testable Infra」の概要については、こちらもご覧ください。
さいごに
日本での登壇も工夫する点や面白いことは多いですが、海外で母国語以外で登壇するとなると、その国の文化や言語ならではの言い回しなどにも工夫の余地が出て面白いです。
また、昨今はコロナの影響もあって、「Zoomなどのビデオ会議システムで時差さえ埋められれば国籍を超えて登壇しやすい」という状況でもあります。
コロナには最新の注意を払っていく必要がありますが、一方で新たに生まれた機会は、積極的に利用しても良いと思います。
