NPO法人ソフトウェアテスト技術振興協会 イベント報告-JaSST'16 Niigata

オープニングセッション

オープニングセッションは実行委員長の三浦氏がおこなった。JaSST Niigataでは「What（なにをすべきか）」に沿ったテーマと「How（どのようにするか）」に沿ったテーマを毎年交互に実施している。今年は上手なテストを実現する具体的方法をお伝えする年まわりで、継続的インテグレーションをテーマにしたとのことである。品質のためにどのように「継続的インテグレーションをおこなうか、手段や経験について様々な切り口で聴けるだろうと語った。

基調講演
「チームが一つになるための継続的インテグレーション」
長沢 智治 （アトラシアン）

基調講演は、長沢 智治氏による継続的インテグレーションを用いることでチームを一つにする話であった。継続的インテグレーションとは、ソフトウェア開発においてビルドやテストを頻繁に繰り返しおこなうことにより、問題を早期発見し、開発の効率化や納期の短縮化を図る手法である。ここでのチームとはマネージャーや開発者やテスト担当者だけでなく、お客さまも含めている。

長沢氏は、これまでに複数の企業を経験してきているが、紹介するツールは各社で違っても話す内容については根本的に変わっていないと説明した。

継続的インテグレーションで一番大事なことは「リリースに備える」ということである。継続的インテグレーションには、以下の側面がある。

• バッグログ単位での継続的インテグレーション（新機能・バグ修正）
• デプロイ単位（お客さまからのフィードバック単位）

お客さまに「活用できるソフトウェア」を届けることが価値となるため、リリースは開発担当者やマネージャーやお客さま全員が関係する大事なイベントとなるとのことだ。

チーム内でコンセンサスをとりやすくするための工夫について説明があった。
具体的には、パイプラインを可視化した継続的インテグレーションをおこなうとのことである。
手順は以下のとおりである。

1. 1つ要件が発生するたびに、プログラムコードのバージョンをわける
2. 構成管理上のブランチをわけ、プログラムコードを修正し、ビルドしテストを行う
3. テスト完了後、構成管理上のブランチをメインストリームに統合する
4. 1～3について、1つの画面上で確認できるようにする

パイプラインを可視化することで、各バージョンにより実装している内容や未実装の要件が明確になる。実装の状態を知るためにコードを読む必要はないため、マネージャーやテスト担当者、お客さまでもリリースまでの進捗状況がわかる。

講演の最後に「継続的インテグレーションを導入するにあたり、効果はどのように出すのでしょうか？」という質問があった。それに対し、長沢氏は「プラスの効果を期待するよりも、機会損失を考えるように話している。」と回答した。現場では新しい技術導入の際にはまず、費用対効果の説明を要求されるという声をよく聞くが、そもそも施策について効果への評価方法が定義できていない現場が多い。

そこで、

• 見えない現状を見るために継続的インテグレーションを使う
• とりあえずやってみることによって、現状を把握する
• ルーチンワークなのかどうかがはっきりすると、機会損失を含めて費用対効果が見えるようになる

といった説明をすることで「とりあえずやってみる」に繋げているとのことである。

（筆者感想）

長沢氏の講演を聴講したのは初めてだったが、終始にこやかに話す姿がとても印象的だった。大事なポイントは何度もキーワードとして出しており、参加者が聴き洩らさないように配慮していると感じた。本講演ではミニワークやパイプライン処理についてのデモンストレーションがあり理解しやすかった。

筆者は開発部門でテストを担当している。「継続的インテグレーションは開発者のためだけのものではない。チームとして必要なものである」という助言は今後仕事をする上で大切な言葉だと思った。

入門チュートリアル
「Jenkinsではじめる継続的インテグレーション」
今井 勝信 （日本ユニシス）

入門チュートリアルは今井 勝信氏によるJenkinsについての講義であった。今井氏は、入門チュートリアルなので、高度な話はせず具体的な内容を説明すると話した。また、説明の内容が各々の会社のどの部分にあてはまるかを考えながらチュートリアルを聴いて欲しいと話した。

Jenkinsは継続的インテグレーション支援ツールの代表である。継続的インテグレーションを使用しない場合、ビルドやテストコードを実行するためには、人が実行ボタンをクリックする必要がある。人がしていた「きっかけ」をJenkinsが自動でやってくれる。

今井氏は継続的インテグレーションをおこなうことで最も効果が高いと感じるものとして、定量化はしづらいが「開発者の健康」ではないかと説明した。「開発者の健康」とは、ビルドやテスト実行などを自動でやることにより、開発者は開発だけに注力することができるということである。継続的インテグレーションをおこなう最大の効果はバグが減少することや、品質があがるということではないとのことだ。

継続的インテグレーションを実施していない方にとってはビルドを自動化するだけでも意味がある。しかし、ビルドでなくても自動化できるところがあれば自動化してみて欲しい。色々試してみると、やりすぎているところや良くないところが見えてくるので、バランスが取れるようになってくると説明した。

（筆者感想）

筆者の会社にもJenkinsを一部導入しており少しだけ内容を知っていたが、テスト技術者にとってもわかりやすい内容であった。

今回は、4月にリリースされたJenkins 2.0のデモンストレーションを見せてもらった。パイプラインの可視化など、さらに使いやすくなるようでとても楽しみになった。

今井氏の話で最も心に残ったのは「継続的インテグレーションで最も効果を感じるものは、バグが減ったとか品質があがったということではない。開発者の健康である」という言葉であった。以前、弊社の開発者が「テストコードや継続的インテグレーションを導入したことで、安心して開発できるようになった。安心して仕様変更にも対応できるし開発を続けられる」と話していた。このセッションを聴講してその話とつながった。

事例発表1
「パッケージ製品開発におけるJenkins導入事例」
須藤 和寿 （リアンビション）

事例発表は2つあった。1つ目の発表は須藤 和寿氏によるJenkins導入事例であった。

須藤氏の部署ではパッケージ開発をおこなっている。パッケージ開発の次バージョンを作成するタイミングでJenkinsを導入した経験について説明した。

以前の開発では、以下のような問題が発生していた。

• 手動ビルドをおこなっていたため、人によるミスが発生しやすく時間がかかっていた
• テストを手動でおこなっていたため、コード修正の度に非常に手間がかかっていた
• 同じようなバグが多かった
• ロック方式のソース管理システムを使っていたため、開発が非効率で手戻りも発生していた

開発方法の見直しを検討したところ、継続的インテグレーションをするとよいのではないかという結論になり、Jenkinsを導入することにした。導入の際に今までのやり方からの変化を嫌う反対意見もあったが、導入してみせることによりメリットが分かりやすくなったとのことだ。

上記問題に対する最初のアクションとして、テスト駆動開発を取り入れた。そのためJenkinsの導入時にすでにテストコードはあったので、技術的な敷居は低かった。ただし、Windowsでの導入が必須であったため、設定について欲しい情報を探すのに苦労した。導入し得られたこととして、以下をあげていた。

• ビルド時間やリリース作業の時間が短縮できるようになった
• コミット直後にテストを実行することができるため、バグを早期発見できるようになった
• テストに割く時間が増えたり、他の作業に時間を使えるようになったりした

（筆者感想）

現場の生々しい導入事例であったため、リアリティのある話が聴けた。「新しい環境（継続的インテグレーション）への抵抗があったが、理由を示して納得してもらった」という話は実践してみようという企業や組織にとって心強い言葉になると思った。

また、須藤氏は「テストコードを書かないでテストすることにはもう戻れない」と最後に話しており、この言葉にすべての意味が集約されているのだろうなと思った。

事例発表2
「私が経験してきたソフトウェアビルドとマルチスレッドプログラミング」
柴田 芳樹

2つ目の事例発表は柴田 芳樹氏によるものであった。柴田氏は約30年に渡り、ワークステーションの開発やプリンターの開発をおこなってきた。本セッションでは、ビルドの方法についての移り変わりやマルチスレッドプログラミングの難しさについて紹介した。

柴田氏は大学生の頃や就職した始めの頃はフロッピーを使用してビルドをおこなっていたとのことである。他にも、紙に書かれた指示を読み込んでコピーやFaxをバッチジョブ的におこなえる製品の機能についての話や、ビッグバンビルドについて説明した。ビッグバンビルドが失敗したときに「毎日ビルドしてやる！」と思って夜間ビルドに挑戦したとのことだ。

マルチスレッドプログラミングは、設計やコードのレビューをおこなうのが難しく、マルチコアやマルチスレッドプログラミングについてきちんと経験や知識がある人がレビューする必要があった。逐次的プログラムと比較した場合、直感に反する動作をすることがあるため、経験の浅い人には理解が難しい。

長時間ランニングテストをおこなうことも、マルチスレッドプログラミングにおいては重要な要件となる。このことを含めて以下の様な点を工夫した。

• 開発者のPCを使用し、平日夜間や週末に長時間ランニングテストを繰り返すようにした
• マルチスレッドプログラムの実行時にランダムな負荷を掛ける
• CPUやHDDやメモリ容量を変更するなど様々な負荷をかけて動作させるようにした
• 障害調査の担当者が決まった人に集中しないように、ハングしたPCの開発者を調査担当とした
• 障害はその場で記録分析するように徹底した
• テストでの失敗を担当者だけにメールするのではなく、マネージャーにも送るようにした

柴田氏は、最後に継続的インテグレーションは強みではなくなったという話をした。継続的インテグレーションをやっていれば技術力が高いわけではない。今の時代では継続的インテグレーションをやっていないことが弱みである。継続的インテグレーションで機械に任せられるところは任せて、技術者は創造的な活動に注力することが大事だと締めくくっていた。

（筆者感想）

柴田氏は『プログラマー"まだまだ"現役続行』の著者であり、今回初めて聴講できることを楽しみにしていた。現役プログラマーとして活躍している話や立ち振る舞いを聴講できて感激した。

講演の最後に質疑応答の時間があったのだが、「若手エンジニアに向けて一言ください」という参加者からのリクエストに対し、｢ソフトウェア開発を楽しんでください。楽しめないものに対しては勉強できません。｣と回答した。多くの技術者に受け取って欲しい名言だと思った。

他の講演者も食い入るように柴田氏の講演を聴講しており、多くの技術者の憧れの方なのだと感じた。

おわりに

「継続的インテグレーション」というテーマを聞いたときに筆者には少しだけ不安があった。筆者の会社にはすでに継続的インテグレーションを一部導入している上に、導入や運用は開発者がおこなうため、継続的インテグレーションの設置や運用をしたことはなかったからだ。そのため、話についていけるかどうか不安であったし、会社にとっての新しい知見が得られるかがわからなかった。

しかし丸一日、さまざまな視点からの講演を聴講して、開発者だけでなくチームとして絆をより深めるために継続的インテグレーションは必要であることを知った。講演者によって、視点や切り口は違ったのだが、「とりあえずやってみる」「コンセンサスをとる」「楽しむ」といったメッセージは一貫しているように思った。

本会終了後も参加者同士が話す場が設けられており、たくさんの参加者や登壇者と話す機会をいただいた。今年3月に行なわれたテスト設計コンテストでは、初めて新潟のチームが優勝したとのことで、優勝チームの方とも話すことができた。地域のJaSSTでは参加者全員と話せるという距離感の近さが良いと思う。どこに住んでいても悩みやモチベーション、楽しさは一緒なのだなと感じた。