レポート

自動化エンジニアのロールモデルを探せ!! 「システムテスト自動化カンファレンス2015」参加レポート

この記事を読むのに必要な時間:およそ 5 分

自動家は見た~自動化の現場の真実~/おいしが(旧.reviewrc)

昨年の.reviewrc改め,おいしがの自動化のパターンのセッションです。

まずはMicrosoft MVPである前川さんの前説から始まり,会場の参加者が自動家芸人?のみうみうさんを大声で呼び出しました。昨年のエモーショナルな熱いトークに魅せられ,ファンになった人も多いはずです。みうみうさんは自動化にこだわりを持つエンジニアがいなくなるとどうなるかということを,フィクションを織り交ぜながら説明しました。

前川さん

前川さん

みうみうさん

みうみうさん

おいしがはこのような状況も以下のような自動化のパターンとして整理しています。

画像

[ ]内はGitHubで管理されている関西発のテスト自動化のパターン

さらに開発者サイドからの意見のみならず,マネージャーに扮した水野さんからマネージャーサイドの意見が出ました。マネージャーの思考の流れを説明したあと,開発者は自動化の効果を数値で説明することで,マネージャーと価値を共有する必要があり,さらには『組織が儲かる』という視点からロジックを整理することが重要であると説きました。

開発者とマネージャーの意見がバランスよく織り交ぜられ,良く練られたセッションだと感じました。良いものを作りたいがゆえにコスト意識が薄くなることがある開発者にとってハッとすることが多かったのではないでしょうか?昨年のレポートでも書きましたが,みうみうさんのプレゼンはあまりに熱すぎて文字では半分も伝えることはできません。みうみうさんのプレゼンをライブでご覧になることをオススメします。

広告システム刷新よもやま話 - テストが当たり前となるまでにやったこと/森下 大介(ヤフー株式会社MSC開発本部マーケッターPF開発部)

Yahoo Japanの森下さんによる広告システムをイチから作り直したときの経験や知見を伝えるセッションです。

森下さん

森下さん

以前のYahoo Japanでは,コンパイルと型宣言がない言語で広告システムが構築されていました。中途で入った森下さんはきちんとデータを扱いたいと考えていましたが,ビジネス的なインパクトも大きいため,大きく変えることには踏み出せないでいました。その間にもシステムには機能が追加され,着実に技術負債が積み重なっていきます。そのような状況の中,ある大きなバグをきっかけに,部門長から「イチから全部変えなさい!」という指示が出ました。

森下さんたちは考え抜いた末に,これまでとは別の言語であるJavaを採用することを決めました。さらには自分たちのシステムにあった以下のようなテスティングフレームワークやDIという設計パターンの適用,さらにはインターフェースの定義言語を作ることなどさまざまな取り組みを行い,YahooJapanの広告システムを刷新していきました。

言語:Java
→コンパイルと型宣言があり,ある程度馴染みがある
テスティングフレームワーク:Spock(Groovyアプリケーションで動作する)
→Groovyは表形式でテストケースを記述することができる
IDE:IntelliJ
→Spockとの相性が良い
設計パターン: DI(Dependency Injection)
→依存性を少なくして,テストを実施しやすくする

いくら良い方向に行くと頭でわかっていても,別の言語,新しい技術に取り組んで成果を出すというは並々ならぬプレッシャーがあったはずです。森下さんは淡々と語っていましたが,その決断力と行動力は驚嘆に値します。

また森下さんはマネージャーの協力が大事と語っており,⁠ボトムアップだけではできないことはある。仲間がいれば個の範疇を超えた成果が必ず出る。」という言葉が印象的でした。テスタビリティやシステムテストの自動化を見据え,ソフトウェア設計をするというのは,これから新規開発するプログラマにとっても重要な技術の一つとなっていくと,ひしひしと感じたセッションになりました。

楽天の品質改善を加速する継続的システムテストパターン/荻野 恒太朗,菊川 真理子(楽天)

楽天の荻野さんと菊川さんによる継続的システムテストパターンのセッションです。

楽天の20サービスのシステムテスト自動化に関わることで見えてきた継続的システムテストに関する知見を整理すると,以下の図のようになります。荻野さんは菊川さんとの寸劇を交えながら実装をひとつずつ説明していきました。

画像

菊川さんの打ち合わせかアドリブかわからない寸劇が素晴らしいと,絶賛の声が上がりましたが,一方では寸劇に気を取られてしまい内容がイマイチ頭に入らなかったという声もちらほら聞こえてきました(笑

荻野さんと菊川さん

荻野さんと菊川さん

全てを紹介することはできないので,筆者の心に留まったエピソードをいくつか紹介します。

メトリクスの意義

結果が数値として目に見えることで,開発者のモチベーションが上がります。メトリクスの1つである『デプロイの頻度』はビジネス価値につながるものの1つであり,役員などの経営層に訴求できる指標となります。

生産性と自動テスト

N日でコインを100枚貯める場合は以下のどちらが良いでしょうか?

  1. 中身が見えない豚の貯金箱
  2. いくら溜まったか見えるATM貯金箱(アプリ)

継続的な自動テストは2のイメージであり,品質に問題がある場合はすぐに修正するなどの行動につながります。毎日品質についてフィードバックするツールの1つです。

DevOps

自動テストがない場合は運用側でバグが発生し,最終的にはエンドユーザーの価値の低下につながります。しかし,継続的システムテストがある場合は,開発側(Dev)でバグを抽出できるので,信頼性の高いソフトウェアを運用側(Ops)に届けることができます。

荻野さんは「毎日コミットされ,毎日テストされバグが見つかる。そういう世界を作っていきたい⁠⁠,⁠テストだけ詳しいエンジニアではなく,自動化にもリリースにも詳しいエンジニアを育てたい。」と熱い思いをセッションの端々で語ってくれました。

著者プロフィール

nemorine(ねもりん)

JaSST北海道実行委員/JaSST東北実行委員/TEF道 お肉担当/AgileJapan仙台サテライト実行委員/Certified ScrumMaster。

札幌の某半導体メーカに勤める開発エンジニア。北海道と仙台をこよなく愛す。開発も大好きだが,いいものを作るためには品質も大事だと気付き,ソフトウェアテストのイベントに参加するようになる。2012年から仙台ソフトウェアテスト勉強会を企画運営し,2013年5月に東北初となるJaSST東北を立ち上げた。2015年本拠地を札幌に移し、北日本のエンジニアとして頑張ることを誓う。

Twitter:@nemorine