みなさんこんにちは。伊藤 宏幸（@hageyahhoo）と申します。アジャイルコーチおよび自動化コーチとして、プロダクト開発チームによるテスト自動化やCIなどの自発的な実現を指導・支援しています。また、Scrum Alliance公認の認定スクラムプロフェッショナル（CSP）でもあります。
去る2016年7月6日に、台湾で開催されました「DevOps Summit 2016」というカンファレンスに、キーノートスピーカーとしてオファーを受けて登壇してきました。
海外のカンファレンスに登壇するということ自体、非常に刺激的な経験です。その上、オファーを受けてのキーノートスピーチでしたので、光栄な気持ちと同時に身の引き締まる責任感も経験することができました。
今回は、そのような貴重な経験の中でも、特に次の3点についてお伝えしたいと思います。
- キーノートスピーチのオファーを受けた経緯
- カンファレンスに参加してみて私なりに肌で学んだ、台湾のDevOps事情
- キーノートスピーチでお話した、Yahoo! JAPANでのDevOpsの取り組み
目次
1.キーノートスピーチのオファーを受けた経緯
- 海外とのつながり方について
2.DevOps Summit 2016と、台湾のDevOps事情
- 1）DevOps Summitとは
- 2）カンファレンスの内容
- 3）個人的な所感
3.Yahoo! JAPANでのDevOpsの取り組み -キーノートスピーチの内容解説-
- 1）テスト自動化
- 2）CI
- 3）一連の施策の自己評価
- 4）質疑応答
4.キーノートだけではなかったDevOps Summit
- 1）DevOpsに関するインタビュー
- 2）締めのパネルディスカッション
- 3）海外カンファレンスでのイレギュラー対応の心構え
5.結論
1.キーノートスピーチのオファーを受けた経緯
そもそものきっかけは、私がSlideShareで公開していた英語のプレゼン資料を、DevOps Summitの主催者である「iThome」の担当者が読んでくれたことでした。
2015年4月にAgile Japan 2015に登壇した際、私は下記の資料を作成・発表しました。
しかし、日本人にだけ資料を公開するのは何かもったいない、海外の人たちにもできれば読んでもらいたいと思い、英語版も併せて作成・公開していました。
それがたまたまiThomeの担当者の目に留まったそうで、メールで直接オファーをいただきました。
海外とのつながり方について
もしあなたが、海外とのコネクションを確立したいと考えているならば、プレゼン資料なりプログラムなり、積極的に英語で情報を公開しておきましょう。きちんと拾ってくれる人がいます。
2.DevOps Summit 2016と、台湾のDevOps事情
1）DevOps Summitとは
DevOps Summitとは、台湾で2015年から年1回開催されている、DevOpsに関する国際的なカンファレンスです。
- 今年はGoogle・百度・Red Hatといったプレーヤーが登壇
- 昨年はGoogle・Chefが登壇
- 今年は7/5（火）と7/6（水）の2日間の開催
- セッション数は19（同時並行トラック数は最大2）
- 参加者は350名前後
- 香港・アメリカからも参加者あり
主催が「iThome」という新聞社であるところが、ちょっと面白いです。
また、台湾での開催なので、中国語の話せない私のキーノート（英語）以外のセッションは、全て中国語で行われていました。
2）カンファレンスの内容
2日間、中国語が分からないなりにセッションに参加してみての、私なりに理解したカンファレンスの内容です。
- Kubernetes by Google
- 現時点の設定内容を、グラフィカルに把握できる。
- コマンドを発行すると、即サーバーを増設・変更・削除でき、トポロジも自動的に再設定される。
- KitchenCI ＆ Docker ＆ serverspec as Acceptance Test
- 立ち見が出るほどの満席でした。
- 基本的には、Test Kitchenの使い方の説明でした。
- Dockerによるプロセス改善事例
- Dockerで動作環境を構築次第、ステークホルダーへのデモ環境やQAへのテスト環境として渡していく。そのため、これまでのような開発環境・ステージング環境を用意しなくても事が足りるようになった。
- これを実現するために、QA・PM・営業もGitを使うことを必須にした。
3）個人的な所感
- Dockerはもはや当たり前に。
- 発表者のほとんどが、デモで使用していました。
- ChatOpsやKubernetesなど、簡単に「オペレーション」を実施できるものがトレンドになりつつある。
- Kubernetesのように、設定を常時グラフィカルに表示しておくツールは便利かも。
- serverspecなどを活用した、IaC（Infrastructure as Code）のテストの需要の高まり・一般化を感じる。
- DevOpsとAgileとを分けて考える議論が多かった。
- 個人的には、DevOpsは自動化などの技術基盤を活用したAgileだと理解しているので、違和感がありました。
- アイコンは、プレゼンの共通言語として使用できる。
- 中国語だらけの資料でも、内容をある程度追うことができました。
- 台湾のカンファレンスの実況は、TwitterよりもGitterというツールを使う方が主流らしい。
発表されている内容のレベルは、日本のカンファレンスのものと同等でした。ことDevOpsに関しては、日本と台湾に特別な差はないという認識です。
3.Yahoo! JAPANでのDevOpsの取り組み -キーノートスピーチの内容解説-
こちらが、今回のキーノートスピーチのプレゼン資料です。
今回のキーノートスピーチ、スライドを数ページ見ていただけると感じられるかもしれませんが、そもそもDevOpsのカンファレンスなのに、テスト自動化とCIの話ばかりをしています。
なぜか？
現場での業務を通じて実際に得た知見をまとめたからという側面もありますが、真の狙いは、DevOpsの今の流れに、あえて「テスト自動化とCIを先にやれ！」という波紋をぶち込むことを意図したためです。
- テスト自動化とCIだけでも、十分変えられることがあることを伝えたかった。
- テスト自動化とCIもやらずに、いきなりデプロイツールだけでDevOpsを語ろうとする人々にクギを刺したかった。
- テスト自動化とCIも面白いことを伝えたかった。
また、2013年頃から持論としている「自動化技術を基盤にしてプロセスを改善する」という考え方に基づき、テスト自動化・CIを使った組織改革をDevOpsの文脈で説明することも企図しました。
英語だけだと分かりづらい点もあるかと思いますので、以下、各章の概要を解説します。
1）テスト自動化
- 今回特に対象としたのは、ユニットテスト（単体テスト）でした。
- 状況に応じて、TDDも採用しました。
- サンプルのテストスクリプトを提供し、ペアプロを行いながら教えていくスタイルを採用しました。
- プロダクトを壊すようなテストを狙って作成することで、メンバーに対して以下の効果を狙いました。
- ユニットテストに興味を持ってもらう
- ユニットテストの効果に気づいてもらう
- そもそもバグを事前に発見して解決してしまう
- Cyber Dojoというツールを活用しました。
- クラウドサービスなので、ブラウザーさえあれば使うことができます。また環境設定が不要です。
- 多くの言語とそれに対応するxUnitフレームワークをサポートしています。
- PHPやJavaはもちろん、GoやFortranもあったりします。
- TDDの多くの課題があらかじめ用意されているため、飽きがきません。
- 同一の課題を複数名で別々に解くことが可能です。
- ダッシュボード機能で、全体進捗の把握が可能です。
2）CI
- 設定ファイル系の障害が多発していたため、これを迅速に解決することが主目的でした。
- テスト自動化と組み合わせることで、環境系も含めた障害検知の容易化を企図しました。
- 特にPHPは、インタプリタでコンパイル不要なので、不要なパッケージの散乱や必要なパッケージの漏れといった問題が起こりがちだという課題認識がありました。
- 教育支援としては、支援先メンバーとのペアセッティングなど、テスト自動化と似た施策を多く採用しました。
- 「全社でCIを実施しよう！」というCTOの号令・理解があったため、われわれのbottom-upの活動と、CTOの号令によるtop-downの動きとが合わさり、迅速な施策の遂行が可能となりました。
3）一連の施策の自己評価・分析
- 3カ月と短期間の施策でしたが、少ないテストでも多くの障害を検知することができました。
- 追加したユニットテスト数は27ファイル、障害検知数は37。
- プロダクトを壊すようなテストを狙って作成したことと、CIがそれを迅速に検知してくれたことが、一連の成果へとつながりました。
- テストをしやすくするための、プロダクトおよびテストのアーキテクチャの見直しは逐次必要です。
- 今回のケースでは、staticなモックという課題を、Phakeで解決しました。
- コンサルやコーチとして振る舞う人は、全てを自分でやってはダメです。プロダクトチームが自力で考え成長する余地を与えなければ、本当の意味でのプロダクト改革・組織改革は生まれません。
- テスト自動化とCIという技術基盤が、プロダクトチームの業務効率化・成長・協業を促進します。（Technology-Driven Development）
4）質疑応答
発表後に、3名の方から質問をいただきました。その内容と回答は、以下の通りです。
- Q）期間の割に追加したユニットテストが少ないが、なぜそんなに障害を検知できたのか？
- A）プロダクトを壊すようなテストを狙って作成したため。壊せるものはもろい。また、CIとの連携で障害を迅速に検知できるようにしたことが大きい。
- Q）良いテストを書くコツは何か？
- A）プロダクトを壊してみよう！
- Q）DevOpsの理想的なプロセスはあるか？
- A）そんなものはない。Trial ＆ errorで発見的・経験主義的に行動して、自分のやり方を見つけよう。そして来年のDevOps Summitでそれを発表しよう！
4.キーノートだけではなかったDevOps Summit
当初はキーノートスピーチだけだと伺っていたのですが、せっかくの機会だということで、2つの追加イベントを依頼されてこなしてきました。こういうチャンスはなかなかないので、個人的にはうれしい経験でした。
1）DevOpsに関するインタビュー
iThomeは新聞社ということで、インタビューを受けました。
私が受けた質問は次の2つ。私がアジャイル・スクラムの専門家だということで、特にそれらとDevOpsとを絡めた回答が欲しいとのことでした。
- Q) アジャイルにDevOpsは必要か？
- A) 必要。アジャイルを実現するための技術基盤こそがDevOpsだと認識している。
- Q) DevOpsをやるために、アジャイルは必要か？
- A) 必要。DevOpsは継続的な改善。それを実現するためには、経験主義的なアプローチであるアジャイルが適している。
2）締めのパネルディスカッション
内容は、参加者からの質問に各自が思うことを回答するというものでした。
ちなみに私への質問と回答は、以下の通りです。
- Q) DevOpsを効率的に進めるためには、どうすれば良いか？
- A) まずは自分たちのプロセスを計測してみよう。時間が掛かっているところがあれば、そこが改善の出発点だ。
- Q) テスト自動化を効率的に進めるためには、どうすれば良いか？
- A) プロダクトをテストで壊そう。壊せるということは、効率的にテストをできる証左でもある。
- Q) DevをOpsにするには、何が必要か？
- A) DevにOpsの仕事をやらせよう！ 私もそれで仮想化やChefなどを覚えた。
3）海外カンファレンスでのイレギュラー対応の心構え
今回イレギュラーな対応をこなしたことで、以下の必要性を強く意識させられました。
- 行って即オファーが来るという恐怖に打ち勝つ強い心
- 急に依頼をされても笑顔で受託する勇気
- トラブルはエンジニアの本懐だとして解決する心意気
- やりきる力
案外なんとかなるものです。
5.結論
私にとって、今回のキーノートスピーチの経験は、まさにプロレスでした。
- 発表者として、主催者と聴衆が求めるもの（情報）を提供すると同時に、自分の強みを的確にアピールして、自身のメッセージを広く聴衆に訴えていく。
- 一方でキーノートスピーカーとして、カンファレンス自体を体現する内容を発信して、カンファレンス自体を引き締める役割をも受け持つ。
- 逆にいうと、カンファレンスを自分自身の色に染められるチャンスでもあると言える。一体何をそこに残すべきかを考えて行動すべき。
もともとはメール1本から始まった話だったので、キーノートスピーチだからという緊張感は、当初は感じていませんでした。
しかし一方で、いざ300名を超えるカンファレンスの参加者たちやスタッフの皆さんを目の当たりにした時、「このカンファレンスをしっかり成功させねば」という使命感に駆られたことは事実です。
「キーノートスピーチだからすごい」とよく声をかけていただきますが、普通の登壇とキーノートスピーチとの違いは、実はこの点に集約されているのではないかと思っています。
- そのカンファレンスを自分の色に染め上げる覚悟はあるか？
- カンファレンスを通じて聴衆にどうしても伝えたいものを持っているか？
- それらを実現できるか？
きちんと海外に情報発信し、そのための覚悟と地力をつけ続ければ、皆さんにも平等にこのようなチャンスはあります。
そのようなチャレンジをしてみませんか？きっと新しい自分と世界を見つけることができるでしょう。
参考資料
こちらの記事のご感想を聞かせください。
- 学びがある
- わかりやすい
- 新しい視点
ご感想ありがとうございました
