はじめに
この記事は、「とちぎテストの会議05」での企画セッションの1つ「理想の開発現場 ～ほんとにあのチームあるんだよ！～ 第1部『自画自讃』外から編」の参加レポートです。
「第2部『自画自賛』内から編」の参加レポートはコチラ。
私なりにメモしたものを載せていますが、雰囲気まではなかなか伝えづらいものになっています。
なので、どういう雰囲気か気になった人は、2年後の「とちぎテストの会議06」に参加してくださいね！
目次
- はじめに
- 目次
- 「あのチーム」のこと、どれくらい知ってるの？
- 「あのチーム」が発表内に登場したイベント
- パネルディスカッションのゴール
- パネリスト紹介
- 質問
- テーマ1「毎日すべてのテストをしてるって本当？」
- テーマ2「TDDやめちゃったけど、どうしてですか？」
- テーマ3「なにが違うの？あのチーム」
- テーマ4「みんなの問題でするということ」
- 感想
「あのチーム」のこと、どれくらい知ってるの？
- まったく知らない
- 10人位
- よく申し込んでくれた！
- イベントやSNSで聞いたことがある程度
- 多数
- 参加の中では知ってる方
- メンバーの人
- 4人だ
「あのチーム」が発表内に登場したイベント
- 「忍者式テスト」として2004年のJaSSTで初登場
- 2008年頃までは、抽象度が高い発表だった
- あのチームをもっと人類に近い言葉にしたい
パネルディスカッションのゴール
- 「あのチーム」がみなさんの頭のなかに思い浮かぶこと
パネリスト紹介
和田卓人さん（以下、和田さん）
- 大人気の人
- 画像検索がライオンばかり
自己紹介や現在の気持ち
- t_wada
- 最近の立ち位置はライオン
- AAが独り歩きしている
- 恫喝の道具になっている
- ナマハゲみたいな感じ
- 初対面なのに相手がビビっている
- 今日はプログラマ寄りの人代表
- 毎回何らかの形で「とてか」には登壇
- テーマすら聞いていないのにパネルに登壇させられている
- すごい困る
- 今回は温情でテーマを知らされた
- テーマが与えられたが、それはそれで困る
- テーマすら聞いていないのにパネルに登壇させられている
テスト駆動開発
- 一旦、絶版となりかけたが、出版社に必要性を訴えて再出版に至る
- 再出版時には付録Cを付けた
- TDDのこれまでと現在とこれから
- テストは品質を上げない
- たまに、この言葉で混乱を招いている
- これは関さんの言葉
秋山浩一（以下、秋山さん）
- HAYST法がチョットデキル人
- 大人気（おとなげ）なかった（過去形）
- 今回のパネルディスカッションについて考えるのをやめた
- おとなげないなぁ…
自己紹介や現在の気持ち
- おとなげないのは「2週間後の気持ちを、事前にスライドにして」と要求してきたみわさんの方
- テスト本を3冊書いた。計12000部売れた。
関将俊（以下、関さん）
- プロの無職
- おとなげない（現在進行形）
- 毎日サボりたいをツイートしている
- 画像つき
- だんだん、写真の撮り方がうまくなってきた
自己紹介や現在の気持ち
- 今は困ってます
- スライドを準備するとは知らなかった
質問
関さんの初心者ですが、なぜ漢字が違う時があるのか？
- 良い質問ですね
- OSSの時にはあっち（咳）を使っている
- サラリーマンの時はこっち（関）を使っている
なぜ第1回とてかに参加した？
和田さん
- とある場所でTDDについて議論があったから、それについて話す機会を持つために、関さんに連れてこられた。
- 基本的には毎回連れてこられてる
秋山さん
- 基本的には和田さんと同じ
とてかの良いところを聞かせてください
みわさん
- これは今回参加して、皆さんが感じてください
テーマ1「毎日すべてのテストをしてるって本当？」
- みわさん
- クックパッドのイベントで秋山さんが論文を書いてくれた
- 秋山さんはいつごろどこで聞きましたか？
- 秋山さん
- よく覚えてない
- 出会いは忍者式テスト
- 私の理解ではストーリーを作って実行するというもの
- 「翌日は改良しても無くしても良いから、テストを進化させて全部実行する」と聞いた
- 本当に、全部実行できるの？という疑問が湧いた
- 関さん
- 多少誤解がある
なぜ毎日すべてのテストをしたいか。
- 毎日システムを確かめたいため
- 実装も仕様も間違える
- 陳腐化もする
毎日すべてのテストはできるの？
- 毎日全部確かめたいけど時間がない
- 「本日のおすすめのプレイリスト」を作っている
- 毎日まばらにやっている
- 数日間やることで全部テストをやるようになっている
- テストの単位はストーリー
- 毎日やっている
- 最初は毎日すべてやっていた
- かっこいいアルゴリズムを作って、全体的に散らばりつつ、あるスパンで見るとすべてをやっているようにした
テストをできない場合もあるが、テストできなかった条件を解消できると、復旧後にカバーするようになっている
- 詳しくは関さんの発表資料に載っているグラフ参照
みわ
- 今の説明で分かりづらいところはあったか？
秋山さん
- いつ止めるのか？
- これでリリースできるの？
関さん
- これはある製品のあるVersionではなく、複数のVersionを含めてのグラフ
- あるVersionに対しては、納期で決まる
- この期間が来たら、そのVersionに対してのテストは終わっている
秋山さん
- かっこいいアルゴリズムには納期というパラメータがあるのか？
関さん
- 無い
- Versionは意識しない
- より新しいテストは優先的にやるようになっている
和田さん
- 優先のアルゴリズムを知りたい
関さん
質問「日々のテストとは別に、リリース向けにやるテストはあるのか？」
関さん
- やるが、基本的にバグは出ない
- セレモニー的なもの
- 結果として取れてる
みわさん
- 私はバグを出すつもりでテストしている
- セレモニーであってもバグを出す気持ちでやってる
テーマ2「TDDやめちゃったけど、どうしてですか？」
みわさん
- これは和田さんからの疑問です。
- 和田さん、質問の内容についての補足をお願いします。
和田さん
- ある時期にTDDを止めたと聞いている。
- これはTDDをすべて止めたのか、TDDの考えを別のやり方でやっているのか？
- また、どうやってテストしているのか？
テスト駆動開発への関わり
- 関さん
- 用意したスライドは、そういう回答じゃないかもしれない…
- 以前に自動じゃなくたってテストに駆動された開発はできると話した
- いわゆるTDDは最初の数年間だけ
- 第1回の「とてか」の頃には、既にやってなかった
- 結果的に自然消滅した
- 20世紀の頃は、テストコードといえば作ったものを動かす方法を書いてた
- 21世紀で、ゴールを先に書くという、かっこいいアイディアが出てきた
- ちょうどいい型を考えるときに使えそう
- TDDについては以下の認識を当時していた
- 一番上側から書けば良い？
- 部品のテストから書いたりしない？
自然消滅へ
- 関さん
- xUnitはオトクな感じがしなくなった
- やってもバグが見つからないから
- 型で担保されるところが多いから
- 明示的な別れではなかった
- 本物ですぐ試せるのに小さなプロジェクトをわざわざ作るのがもったいない
- xUnitはオトクな感じがしなくなった
やめてない
- 関さん
- テストすることに寄って開発を駆動してる感じは残っている
- ゴールから書くという考えはも持っている
- xxUnitという書き方は止めた
- テストドリブンはある
- テストすることに寄って開発を駆動してる感じは残っている
話を聞いた和田さんの感想と追加の疑問
和田さん
- 一番上側から書くのは、別に間違いではない
- むしろ「部品から書かないといけない」と思い込んでいる人こそ間違い
- ゴールから書くというのは最終的に近いところから書く
- 関さんがTDDをやり始めた頃は、まだ足回りが整ってなかっただけでは
- xUnitがある成果物とない成果物が存在する
- TDDでドリブンしている目的は、前向きになれるかどうか
- ミスをした時にすぐに分かる
- 不安を克服するためにやる
- 気付くまで長くなればなるほど保守的になる
- 短くなって一瞬で気付けるなら前向きになれる
- TDDを止めて、怖くないんですか？
- 一番上側から書くのは、別に間違いではない
関さん
- 元々、テストが大変だから直すのは嫌という人はいた
- そのときは、「僕が全部テストするから」と言ってた
- システムが十分に複雑になってくると、単体で分かる部分が少なくなってきた
- 元々、テストが大変だから直すのは嫌という人はいた
和田さん
- それならすべてオールグリーンでも不安になりますね
- ソースコードの質を上げるために、テストをしようと動くきっかけはあるのか？
関さん
- 僕が後ろに立てばやる
- 各自、まずいことは薄々感じながらやってる
- その人の良心の部分について、背中を押す感じ
和田さん
- わりとなまはげっぽい
- 作りすぎないとかについて、ちょうどよい塩梅にするためにはTDDがあると思うが、その塩梅はどうやっているのか？
関さん
- どのくらい自動化するかはそれによって違う
- 別に自動テストを禁止しているわけではない
- TDDはちょうどよさを見つけるものだというやり方は、私のチームでの考えとは違う
和田さん
- TDDでは、バグを見つけるためにテストを書いてるわけではない
- 特に2周目はcheckingのためにやってる
- CheckingとTestingは陣取り合戦の感覚で…（Timeup!）
テーマ3「なにが違うの？あのチーム」
- 米沢さん
- 流行りのプラクティスを取り入れてるんだけど、「何となくうまくいってない…」と感じたことはありませんか？
- 実は「あのチーム」でもやってることは同じ
中身は全く違う
米沢さん
- 作業場所は同じようにやってるけど、隣りにいるのにメールで連絡したり
- テストも沢山やる
- けど、大昔のもやる
- 2004年のバグが見つかったり
- けど、そのバグをみんな覚えてたりする
- けど、大昔のもやる
関さん
- ふりかえりという形のMTGはやってみたけどTDDと同じように自然消滅した
質問「いつもやってるというふりかえりで、「こうしたほうがいいよね」ということが出てくると思うが、 3人でやったほうが良いというものをどうやってチームに伝わるのか？」
米沢さん
- やったほうが良いよね、ではなくやる
- 次の瞬間には始めている
- やり方が人ごと伝播している感じ
関さん
- 「これやろうぜ」とかあんまり無いね
米沢さん
- 「やってみようよ」は続かない
関さん
- 元々、最初から全員を変えようとする気が無い気がする
- 行動する人がだんだん増えてくる感じ
質問「ログ的な残し方はどうしているのか？」
質問「途中でJoinした人は立ち上がりが大変なのでは？ペアワークで伝播されていくから苦労しないのか？」
関さん
- 大丈夫です
- 教えまくる
- その時はコストではない
- 徐々に立ち上がるのではなく、垂直で立ち上がる感じ
みわさん
- Joinした頃は、気にする所が全然違ったけど…(TimeUp!)
テーマ4「みんなの問題でするということ」
- 佐々木さん
- あのチームに入った時の初めの印象
- 個人の範囲が決まってない
- しばらくして分かったこと
- みんなの問題にしている
- その人だけが困るという状態にしない
- 設計のアイディア
- 一緒に試してみよう
- 実装のテクニック
- 今日はこれを手伝って！
- 仕様や計画の調整
- 仕様を考える人も別組織だが同じチーム
- 個人の担当範囲が決まってない
- 細分化しないほうが早い
- おおまかな計画
- 計画が変化していく
- 計画し過ぎたらもったいない
- みんなの問題にしている
- あのチームに入った時の初めの印象
みんなの問題にする雰囲気作り
秋山さん
- みんなの問題にするというのは、最初から？きっかけがあった？
米沢さん
- 来たときからこんな感じ
- 仕事としては険悪ではない
- 別に基本的に仲良くしているわけではない
- ただ、できないものを「できないじゃん」と責めることはない
秋山さん
- ムードメーカーはいる？
関さん
- ムードは出さない
- 助けられるのは分かっているが、助けない
米沢さん
- 何とかなりそうな形になってる
関さん
- 「協力する」ではなく、「これを出さなきゃ」となっている
和田さん
- チームの評価は？
関さん
- よく分からない。
- 自分達が評価し合うような関係になっていないのが良いことなのかもしれない
質問「『手伝って』という表現があったが、専任者はいないが各々やることが決まっているということか」
佐々木さん
- ぼんやりとは決まっているが、誰がどこをやっても良い
- 朝会のうちに調整する
- まずそうな場合は、本当に一緒にやる
米沢
- ダメなときはすぐにやる
佐々木さん
- うまくいってないことを隠さないことが大切
質問「Aさんが助けたら、Aさんの負荷はどうなるのか？」
関さん
- そもそも「Aさんの仕事」という形は存在しないのかもしれない
米沢さん
- ストーリーは1個2,3日で終る
佐々木さん
- 出したい期間を見て、だんだん決まっていく
- 計画を作るのは難しくて面白い
- 組み立ててストーリーにしていく
感想
- 「このプラクティスをやってみよう」ではなく、「こうやったのが良かったね」と、色々と試した結果論として出ている印象。
- 常に議論の対象が「人」ではなく、「製品」にフォーカスしている感じが至る所で出ていたパネルディスカッションでした。
