HOW TO GO

〜昨日の今日とは一味二味違うBlog〜

「CI and Testing Unconference in Tokyo」に参加しました。#cituncon

2013.4.20 CI and Testing Unconference in Tokyo に参加してきました。
http://citcon-jp.doorkeeper.jp/events/3473

CI(Continuous Integration)やソフトウェアテストに関するアンカンファレンスです。
「アンカンファレンス」ってなんじゃ?って感じだったんですが、まあみんなで議論しようぜー、という会でした。

f:id:sugiim:20130420224631j:plain

アンカンファレンスとは…?

まず集まった時に各セッションの議題/テーマ(?)をみんなで決めます。参加者から議論したいこと、発表したいことなどを募り、そのテーマの議論に参加したい人、発表を聞いてみたい人を募ります。
ある程度みんなが興味あるテーマをセッションとして決めます。
大事なのはみんなで決めること。参加者がテーマを挙げ、参加者でそのテーマについて議論するイベントです。
今回は20名程度だったので2セッションにわかれて進めることになりました。

ということで参加したセッションのメモなど。

#1 カバレッジは100%を目指すべき?

テストコードのカバレッジをどこまでやるの?っていう話です。
カバレッジと言ってもC0〜C2とありますので、まずはそのおさらいを有識者から解説。
通常「カバレッジ」というとC0(ステートメントカバレッジ)のことを言う場合が多いですよね。
カバレッジの測定ツールなんかはほぼこれ)
でもテストってC0だけじゃ不十分に決まっていて…。なんて話はこのテーマとは違うので割愛。

  • 100%にすることは難しいよね。コストとの兼ね合い重要
  • アーキテクチャのレイヤによって目指す数値は異なる
  • コードを引き継いだ時にテストコードがあると嬉しい。カバレッジが高いとさらに嬉しい。テストコードがないと困るし、ダメなエンジニアって思ってしまう。
  • 誰のためのテストコードか
  • 100%にすることは難しいが100%を目指す心意気は大事

現実として100%は難しい。だけど100%に近づける努力をすることは重要でしょう、というのが心に響きました。エンジニアとしてどれほど誠実に仕事をしているか、ということでしょうか。

#2 TDDのテストと品質保証のテストって違うよね…?

このテーマは個人的にもとても興味があり、いい議論ができました。

  • テストコードを書くという取り組みは品質管理チームに説明が難しい。なんか噛み合ない。
  • テスト計画や目指す品質のイメージがステークホルダーで違っている。だから噛み合ない。
  • TDD(テストコード)は内部品質をあげる仕組みであり、品質保証の一部ではあるが位置づけは若干異なるのでは。
  • 品質管理チームなどは「一緒のチーム」として活動すべき。開発側とムダな対立となるのは意味がない。

という感じで、品質に関する捉え方がプロジェクト全体で統一できていないとうまくいかないよね、という話が出ました。そりゃそうだ。だけど大事なこと。

#3 CIの導入の事例発表

渋谷界隈のServicerから事例の発表です。

  • Java/JUnitでのサービスの開発
  • Github使う。PullRequestをレビュー依頼として使うのは便利
  • Jenkinsを途中から導入

リリースが頻繁にあるプロダクトだとやっぱCIは必須。

#4 テストの工数はどれくらい?

テストに掛ける工数はプロジェクト全体に対してどのくらい?っていう疑問から始まったセッションです。

全体の40%程度ってのが妥当。これはウチの会社でも大体こんな感じ。
でも標準って考えは危険でプロジェクトによってコンテキストは変わってくる。それぞれのプロジェクトでちゃんと考えることは大事。似たようなプロジェクトとか隣のプロジェクトとかと比較するのも大事。計測はできるならやろう。

で、話が途中から変わり「みんなテストファーストってできてる?」という話に。
できてる人は2〜3名(笑)
みんなテストコード書くけど正しいTDDにはなっていないようです。

でもTDDを試みることはメリットが多くあって、例えばテストパターンをコード書く前に考えるので効率的だったりする。
それって設計の一部だったりして、結局コードを書くことって設計/コーディング/テストを行ったり来たりすることなんだよね、ってことですよね。
モノを作るってそういうことのはずです。

#5 Fabric, vagrant, chef-soloを使った構成管理

ツールの名前を聞いたことあるくらいで参加したセッションです。
話についていくだけで精一杯。詳細は割愛。
本番とステージング、開発環境はなるべく同じOS(環境)にしたほうがいい…。
って僕は当たり前って思ったんですが、色んな都合でそうなっていないことも多いのでその差異を構成管理としてどう吸収するのかってのは課題でしょう。難しいみたいです。

#6 ダッシュボードの話

「スーツの人」に報告するためにイケてるダッシュボードってなんだ?
という発表でした。
http://www.slideshare.net/ar_maniacs/ss-19250545

普段はダッシュボードって面白いなーと思いながらもそれほど関心を持たなかったのですが、可視化という点でもうちょっと注目されてもいい分野だなと思いました。

  • インフラの状況(ネットワーク、リソースなど)
  • 開発の途中(品質、進捗)
  • サービス後(アクセス数、SEO

それぞれのステージで見たいものは異なりますので使うツールもそれによって違いますよね。
なかなかぴったりくるツールはないようです。

#7 TDD Boot Camp について

TDD Boot Campなる研修(勉強会?)を開催している方がいらっしゃいました。
お題に対してテストコードを書いていく、さらに仕様変更にどのように対応するかを学ぶことができるようです。

これはいい!と思いました。是非若手向けにやってみたいですね。
SIerである我々はテストコードを書く習慣があまり無いように思います。若手にはテストコードを書くことが当たり前の環境で育ってほしいです。

感想とか

ソフトウェアテストについてこれだけ議論できる場所ってなかなか無いと思います。
参加者の皆さんのレベルの高さに驚きでした。精進せねば…。
このイベントは是非次回もやってほしい!

あと「スーツの人」って表現はツボでした(笑)
一般的に開発者はスーツの人(お客様、営業、マネージャーとか総称)があまり好きじゃないですが、テスト技術者はさらに嫌い!って感じ共感しました(笑)

以下写真です。

渋谷のVOYAGE GROUPさんで開催されたのですが、会社/会議室のデザインにびっくりしました。

受付です。なんじゃこれ…。
f:id:sugiim:20130420234239j:plain
バーが会社内にある…。
f:id:sugiim:20130420234810j:plain

会議室にはクレド。これはいい。
f:id:sugiim:20130420234457j:plain
f:id:sugiim:20130420234416j:plain
f:id:sugiim:20130420234450j:plain

和室の会議室!
f:id:sugiim:20130420234520j:plain

振り返り
f:id:sugiim:20130420234543j:plain
f:id:sugiim:20130420234549j:plain
f:id:sugiim:20130420234557j:plain