理想の開発現場 ～ほんとにあのチームあるんだよ！～ 第2部『自画自讃』内から編 参加レポート #toteka

勉強会 技術 とてか

はじめに

この記事は、「とちぎテストの会議05」での企画セッションの1つ「理想の開発現場 ～ほんとにあのチームあるんだよ！～ 第2部『自画自讃』内から編」の参加レポートです。

d.hatena.ne.jp

第1部の参加レポートはコチラ。

nihonbuson.hatenadiary.jp

私なりにメモしたものを載せていますが、雰囲気まではなかなか伝えづらいものになっています。

なので、どういう雰囲気か気になった人は、2年後の「とちぎテストの会議06」に参加してくださいね！

目次

反復開発で紹介する「あのチーム」

  • もうすぐイテレーションが719になる
  • 全ての工程を繰り返す開発システム
  • V字を繰り返すスタイル
  • 実装とデバッグを繰り返すのは1ターン相当であって反復開発ではない

V字の最小単位=ストーリー

  • いわゆるチケットの単位。
  • 最小かつ最大

反復って期間じゃないの？

  • そういう時期もあった
  • 十分複雑になるとチケット自体を反復と考えた
  • 部品とかをチケットにしない

テストスイート

  • Vが終わる毎に新しいテストが増えてくる
  • Vが終わる度にほどほどに全部やる
  • 2008年頃は、それぞれ全てが成果物と説明していた

ずっとテストしている

  • 時間割に従ってテスト実施する
  • テスト中に疑問が起きると開発者にすぐに質問する
  • 結果、ずっとテストする
  • テストで見つけた調査を優先する
  • 米沢さんは、朝会のあとの1時間テストする
  • みわさんは朝会以降、ずっとテストしてる
    • たまに集中しすぎちゃう
    • 「ちゃんと開発者に聞いてね」と注意している

反復開発は目的じゃない

  • 確かめると直すを交互に繰り返す
    • 直す時間が確保されているからテストする
    • 直される前提だからテストできる
    • 限られた時間でテストするために短期間でターンを終わらせる
    • 計画自身の確かめ方（テスト）も計画する
    • 「確かめて直す」がそこらじゅうにある

質問

Vが下まで来た時に、そもそもダメな時はあるか？途中で終わることはあるか？

  • どのタイミングでもあるが、やる前に却下されることが多い

リリースが1年かかったりすると思うが、リリースサイクルは？100個ぐらい要件ができてからリリースする？

  • 3ヶ月から6ヶ月
  • ストーリーは200個ぐらい

要件が降りてきてから仕様を考えて、というのも全体で考える？それとも要件をストーリーにしてから？

  • 一番外にいる人が気付いたところ
  • レイヤーでいえば上から下まで全部
  • ある工程の考える範囲は小さいかもしれない

ストーリーが並行して動いていることはある？

  • 20個ぐらいが並行で動いている

HWとの協業部分は？

  • なければ何ができるんだろう、届いたら何をするんだろう、とか考える
  • 出荷前には全部確かめる
  • 外側でもやる

時間割について。みわさんが集中して、就業時間を飛び出ているように見えたが、みわさんが一人だけ残業している？

  • 「それは困る」という話はしている
  • みわさん
    • 不思議だが、飛び出る部分（残業時間）はよく不具合が出るんですよ。
    • ただ、私一人だけ残業したことはない
    • みんなを巻き込んでいる

何人ぐらいでやっている？

  • 少なくはない
  • 朝会に出ているのは16人ぐらい

ストーリーを書く人はチーム内にいる？

  • 昔はスクラムで言うPOという外の人がいたが、今は中で書いている

ストーリー間のコンフリクトは起こらないのか？

  • 基本的に仕様追加は、過去の何かの仕様とコンフリクトするもの
  • 言われたらここおかしくなっちゃうよと分かる状態になっている
  • 何もかもわかるとは言えないが、相当な状態が分かる気がする
  • みんなが色んな視点で言い合える

それを言い合えるタイミングはあるか？

  • 朝会後は常に言ってると思う
  • みわさん
    • 実装の前に、テストを思い浮かぶので、その時点で言う
      • 昔は実装後に「やっぱりバグった」と言ってたけど、実装前の思い浮かんだ時点で言うように変えた

製品を作ってリリースするとき、おおまかなステップを切ることが多いと思うが、結果として後半に寄ってしまったりしないのか？

  • この頃までにこうなっていないとこの時点でヤバくなるだろうな、と想像できている

ズレてしまって後半に困ることはあるか？

  • 大まかにずれることはない
  • 佐々木さん
    • 「危なそう」というのは初めの頃に分かる

反省

  • 人類にはここまでの関さんの話がついてこれないかもしれない
  • これまではチームの様子を説明しただけ
  • 「ああいうチームがあるんだね」で終わっちゃう

仮説

  • 問題を解決していく最中におこる「小さな会話」が「よいチーム」をかたち作るのではないか？
    • チームの価値観そのもの

題材

  • 今日はこれらのフレーズを紹介する
    • うまくいったらどうなるの？
    • 早く見つかってよかったねー
    • 再現させたら、わかるの？
    • わかんない

テーマ1「うまくいったらどうなるの？」

  • 佐々木さんが発見したフレーズ
  • こんな良いことが起こる
    • ゴールが分かる
    • うまく迷える
  • 例）○月○日にリリースします
    • リリースしたらどうなるの？
  • 「○○テストをやります」と言った時にはよく使うフレーズ

質問・意見

質問「テストが通った！で終わりじゃないのか？」
  • 「この修正されたら、この部分が触れるようになるね」とか答えられる
質問「探索的テストにつながっている感じ？」
  • そうではない
  • 「何を試したかったんだっけ？」を思い返せるために言ったりする
意見
  • 英語とかでも、目的だけ書かれてもよくわからないことが多いので、うまくいったらどうなるかさえ伝われば、途中経過がよく分からなくても軌道修正ができると思う。
  • 「うまくいったらどうなるの」が暗黙的に分かっている人は、自分の変更が他の部分が壊れてないか気にしてくれる
  • 入ってきたばかりの人は気にしないので、似たような話をしてツッコミしたりする。
質問「このフレーズを見るたびに「うっ」となる。何が聞きたいの？と思っちゃう。どの時点を知りたいの？普段からこのフレーズが出るの？」
  • 最初のゴールは何なのか、どれくらい次のステップを知りたいために聞きたい
質問「このフレーズをそのまま使っている？こういう風に聞いたら良いのか？」
  • 根っこにあるのは心配している状況（という前提があるからそのまま使ってる）
  • その人の問題ではなく自分の心配として聞いているだけ

テーマ2「早く見つかってよかったねー」

  • こんな良いことが起きる
    • 異変にいち早く気付けるようになる
  • 状況
    • バグが見つかった時
      • わいわい嬉しそうに集まる
    • エアコミット（実はコミットしてなかった）
      • 次の日の朝会で「エアコミットしちゃいました」と言ってみたり
  • 気が楽になるフレーズ

質問・意見

質問「言いにくいことが無いように感じるが、そのへんはどうなのか？」
  • 入った初めの頃は、作業を見られるのが恥ずかしかった
質問「こういう言葉って割りといいづらい。バグを見つけた人が言っても「お前、何言ってるんだ」となるのでは？」
  • まずいものを出荷しないことが圧倒的に大事
質問「そういう雰囲気になれば良いが、なかなかなりづらいのでは？」
  • 関さん
    • 言い始めたら変わるかもしれない
  • 米沢さん
    • プログラマは嫌な感じかもしれないが、リリース前に見つかることは良いことかもしれない、と思うようになるかも
質問「この言葉を使うようになってから、報告が漏れていたことはあったか？」
  • みわさんが永遠とテストして法則を見つけようとして報告が遅くなったことがあった
  • あとは、「連休前に見つかったものを、連休後に言います」と言っていた人がいた
意見
  • 日常生活でも類似することがあるな、けど言いづらいなとも思う
質問「最終的に言うと思うが、途中で『なんで遅れたの？』と聞いてしまったりしないのか？」
  • 米沢さん
    • 考えたことがない。やった人を責めることはない
  • 佐々木さん
    • 確認ミスで、もう一回テストしたら見つかった時、『このままリリースするよりは良い』と自分に言い聞かせた
  • 佐々木さん
    • 前提として、誰もかれもミスをするということ

テーマ3「再現させたら、わかるの？」

  • 佐々木さんが紹介
  • 調査して再現できない時に対して言われるフレーズ
  • プログラマとしては、ログを仕込んで確認しようというときには、仮説をするはず。
  • 考える時点で問題の調査は進んでいる。
  • 諦めない意思の表明にもなる
  • 想像力を掻き立てるフレーズの一つ。

質問・意見

質問「デッドロックが起きたとき、デッドロックしたら対処するという回避策ではなく、根本解決まで行うのか？」
  • 場合による。
  • クラッシュしないような回避とかはする
質問「その時は議論する？」
  • 議論というか、厳しい目で見られる
  • みわさん
    • 「クラッシュしないです」と言われても疑う。
    • 諦めないで、クラッシュするところはテストすると思う。
  • 関さん
    • 諦めはどういうときにくる？
  • みわさん
    • 1日目触って上手くいっても、2日目や他のテスターに触ってもらうなどして、簡単にチケットをクローズしない。
質問「再現しない限り、修正の確信が得られないのでは？」
  • 色んな可能性を考慮、検討しているか聞きたいがために、このフレーズを言う。
  • 調査を進んでいると、何パターンか挙がってくるはず。
  • 再現しない限り終わらないのは確か。
質問「『もうちょっと調べるべき』と迫るためにこのフレーズを使っているのか？」
  • それもそうだが、どこまで調べられたか確認するため
  • みわさん
    • テスターの人は言いづらいのではないかと思っている
    • 言える状況というより、言い方が…。
    • 若干、高圧感があるのでは？

テーマ4「わかんない」

  • 良いことが起きる
    • 自分に異常があることを伝えます。
    • なぜ分からないのかみんなで考えるようになる。自分個人の問題ではなくなる。

質問・意見

意見
  • 自分のチームでも、「『わかんない』を言っていいんだ」となってからチームが変わった。
質問「分からないと言われた後に、『あー、分からないねー』で終わることはあるのか？」
  • その場では解決まで持っていかなくても、反省できることにはなる
質問「『分からない』と言えるようになる勇気の培い方はあるか？」
  • 基本的によく言うようにしている。
    • それによって「あ、関さんも分からないんだ」と周りが思ってくれてるかも。
  • みわさん
    • 初めは調べようとしちゃう。
    • 自分の知識が足りないせいだと思っちゃう。
    • 分かる状況を自分でしようとしちゃう。
    • けど、このチームは私の分からない状況を察知してくれるみたい。
    • 言えるようになるまで3ヶ月練習した。
    • 調べる時間も勿体無いと実感してきた。
質問「チームで仕事をするときには、まずはGoogleで調べなさい」という話と真っ向に対立する意見に見える。
  • 早く言った方がチーム全体で考えると早くなっている。
質問「Googleの15分ルールがあると思うが、深谷さんはどのくらい考えるか？」
  • 15分はない。2,3分考えたら聞いちゃう。
質問「『分からない』と言う判断基準が分からない。」
  • その検討もしない。
  • 調べて出てきたドキュメントで分かるかもしれないが、書いてあることは所詮形式知。
意見
  • この話を、以前に2人のTwitterでやり取りして、実践してみた。
  • その時は「調べるのをやめて聞こう」と言うようにしている。
質問「これを使っているが、まだこれでうまくいくのがよく分からない。」
  • 聞き手の問題かもしれない。
  • もしくは、溜めないで大きくならないうちに上手く言うと良いのかもしれない。
  • 絶えず聞かれる、絶えず答えるから自然とそういう風になる。

感想

  • 発生したことを、絶えず「チームの問題」「チームの出来事」としていることが垣間見えた
  • 「みんなで考える」というやり方はすごいモブワークと似てる
    • ただし、モブワークは同時に同じことをやっているのに対し、「あのチーム」は適度に分担しているにも関わらず、「みんなのこと」と出来ているのがすごいと思った。

理想の開発現場 ～ほんとにあのチームあるんだよ！～ 第1部『自画自讃』外から編 参加レポート #toteka

技術 勉強会 とてか

はじめに

この記事は、「とちぎテストの会議05」での企画セッションの1つ「理想の開発現場 ～ほんとにあのチームあるんだよ！～ 第1部『自画自讃』外から編」の参加レポートです。

d.hatena.ne.jp

「第2部『自画自賛』内から編」の参加レポートはコチラ。

nihonbuson.hatenadiary.jp

私なりにメモしたものを載せていますが、雰囲気まではなかなか伝えづらいものになっています。

なので、どういう雰囲気か気になった人は、2年後の「とちぎテストの会議06」に参加してくださいね！

目次

「あのチーム」のこと、どれくらい知ってるの？

  • まったく知らない
    • 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はオトクな感じがしなくなった
      • やってもバグが見つからないから
      • 型で担保されるところが多いから
    • 明示的な別れではなかった
    • 本物ですぐ試せるのに小さなプロジェクトをわざわざ作るのがもったいない

やめてない

  • 関さん
    • テストすることに寄って開発を駆動してる感じは残っている
      • ゴールから書くという考えはも持っている
      • 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日で終る

  • 佐々木さん

    • 出したい期間を見て、だんだん決まっていく
    • 計画を作るのは難しくて面白い
    • 組み立ててストーリーにしていく

感想

  • 「このプラクティスをやってみよう」ではなく、「こうやったのが良かったね」と、色々と試した結果論として出ている印象。
  • 常に議論の対象が「人」ではなく、「製品」にフォーカスしている感じが至る所で出ていたパネルディスカッションでした。

モブプログラミングを色々な場所で体験してきた #mobprograming

勉強会 技術 モブプログラミング xpjug TDD Developers Summit

はじめに

社外でモブプログラミングを色々と発表聴講＆体験したので、そこで感じたことなどを書いていきます。

目次

初めての社外発表聴講『大企業だけど新規ビジネス開発をモブプログラミングでやってみた』 in XP祭り2017

「以前からモブプログラミングというやり方があるよ」というのは聞いていました。 2017年9月にあった今回の発表は、モブプログラミング体験者の声を初めて聴く機会となりました。

聴講レポートは既に書いているので、コチラを見てください。

nihonbuson.hatenadiary.jp

得た気付きや感想

  • そういう風にやり始めた世界があるんだ…という感じ。
  • 正直、この時には実感が湧いていなかったんだと思う。まだ遠い存在。

初めての社外見学「実況パワフルモブプログラミング」 in Developers Summit 2018

2018年2月頃はモブプログラミングを社内でやっていることもあったのですが、社外で初めて生のモブプログラミングを見ました。

発表スライドはコチラ

speakerdeck.com

得た気付きや感想

  • 「やったー」の回数がとても多い。

    • 感覚としては3分に1回ぐらいあった。
    • これはそれだけ粒度を小さく区切って進めている証拠
    • 以前に、「テスト戦略を語る夕べ」という勉強会 *1 で、「リリース間隔が狭いことで得たいものは、リリースを早くしたいのではなく学習機会を増やしたい」という話があったが、それを正に実践している感じだった。

  • 自分も社外の人とモブプログラミングをしてみたい！

初めての社外体験「モブプログラミングワークショップ」 in Developers Summit 2018

「実況パワフルモブプログラミング」を聴講した後に、同じ会場の別部屋で体験会があったので参加してきました。

connpass.com

会場のセッティングは、イベントページにあった、この画像のような感じでした。

モブプログラミングの題材と結果

  • FizzBuzz問題を使用。
  • 参加者の方々がほとんど触れたことがが無い言語（python）を使用。
  • 時間交代制。確か7分。
  • FizzBuzz問題を解いただけでなく、途中でテストランナーの作成まで行った。
  • 実装結果は以下のページに残ってる。

wandbox.org

得た気付きや感想

  • 「実況パワフルモブプログラミング」でも書いたけど、本当に「やったー」の回数がとても多い。
    • 細かい粒度というのは大切。
    • 例えば、3の倍数のテストが書けただけで「やったー」と言ってたり。
  • 心理的安全性が高い雰囲気にしている。
    • 分からなければすぐに言える雰囲気。
    • 分からないところに対してすぐに教えてもらえる安心感。
    • みんなで分からないときはみんなで調べるという一体感。

  • ということで、社内の人も一緒に体験してほしい！

2回目の社外体験「テスト駆動飲み会 - Test Driven Drinking」 at ヴァル研究所

「お酒も飲みながらモブプログラミングを楽しめる」と書いてあったので、参加してみました。

tddrinking.connpass.com

モブプログラミングの題材と結果

  • 100doorsという問題を使用。
  • Javaを使用。
  • イベントタイトルからも分かる通り、TDDで進めていく。
  • 自由に交代する形。
    • ただし、ドライバーが「そろそろ代わってよー」と発言するという、多少のグダグダ感。*2
  • cyber-dojoを使用。

cyber-dojo.org

  • 実際に利用した結果は画像の通り。

  • ちなみに、お酒もTDD(Red→Green→refactoring)を意識したものに。

得た気付きや感想

  • テスト失敗続きになったときの対処(revertの判断)は勉強になった。
    • revertの判断も、モブでやっているからこそ、色々と相談しながら進められた。
  • 最初にTODOをきちんと整理しなかったのは反省点。*3

3回目の社外体験「モブプログラミング現場訪問」 at 楽天株式会社

Developers Summit 2018でyattomさん( id:yach )と話して、及部さん( id:TAKAKING22 )なら、モブプロの現場見学ができるという情報を仕入れました。

結果、 kidaniさん( id:kidani_a )とそのチームメンバーである後輩3人を誘って、5人で現場見学が実現しました。

今回の話は、kidaniさんが既に記事にしているので、そちらも参考にしてください。

kdnakt.hatenablog.com

モブプログラミングの題材と結果

  • 及部さんのチームが作っている製品が題材。
  • 時間交代制（7分、休憩1分）。
  • 1時間弱で、お客様に提案の形を示す程度のものができた。

得た気付きや感想

  • FizzBuzzとは違い、既にあるコードを使ってのモブプログラミングだったため、コードを理解するのに時間がかかった。
  • 今までの勉強会とは違い、社外勉強会に積極的に参加しているわけではない人と行ったため、「○○が分からない」と素直に発言するのをためらっている人がいた。
    • これはその人が悪いというわけでなく、「そういう人も存在するよ」という知見になった。
  • 心理的安全性やサーバントリーダーシップといった、チームビルディングの大切さを改めて感じた。

ちなみに、積極的になりきれていないチームでモブプログラミングを始める場合、今回のやり方は2つの部分で良かったです。

1. 時間交代制

時間交代制によって、コーディングに慣れていないメンバーにもドライバーとなってコードに触れてもらいました。

実際の現場では、時間交代制ではなく、ドライバーになりたい人が「代われ！」といって交代する方法をとっているようです。*4

また、途中でプロジェクトに参加した人がいた場合は、慣れてもらう意味でも、積極的にその人をドライバーにするとか。

2. 休憩時間の導入

休憩時間といっても、休むだけではなく、以下のような会話を行っていました。

  • 自分がこの7分間で何を行っていたのか。
  • 次のドライバーは何を行うべきなのか。
  • その他、この7分間の振り返り。

今回は、この休憩時間があったことで、なかなか慣れてない人から「コピペの仕方が分からない」という発言が出てきました。*5

休憩時間の導入は、発言を躊躇する人がいるうちは良い方法だと思いつつも、慣れてきたらそういう「分からない」発言もモブプログラミング中に話せると良いね、とのこと。

テストエンジニアとして、モブプログラミング体験から感じたこと

及部さんのスライドには、以下のような話があります。*6

  • 毎日 11:00～11:15にモブプランニングとして、今日やることを見定めて、1日中モブワークをしている。
  • モブワークは、コーディング以外にも、設計やレビューなどの工程を区切らず、常に同期している。

これらの話や図を見て、私は似たような図を思い出しました。それが次の図です。

そう、探索的テストの図です。*7

最初に計画を立て、それに基づいて学習・設計・実行を、短いサイクルで行うというところも似てます。

時間で区切る方法として「セッションベースドテスト」あったりするのも似ている気がします。ちなみに、セッションベースドテストについては、テスターちゃんの説明が分かりやすいかも。

testerchan.hatenadiary.com

通常の探索的テストは、学習・設計・実行を分担して行ったりします。

ただ、もしかしたらモブワークとの親和性が高いのかもしれません。

実際に、モブテストを行っている例もあります。

underscore42rina.hatenablog.com

上記の場合は、ドライバーをリナさんで固定にしています。

一方で、ドライバーを時間交代制にしたり、テストに慣れていない年次の浅い人をドライバーにする方法もありだと思います。

それによって、どこが上手くテストできないかが可視化できるかもしれません。

また、issueとして残すことが多いため、書記を置く方法というのは、モブテストならではかもしれないです。*8

まとめ

  • モブプログラミングの発表聴講、見学、3回の体験を行って、色々な違いを発見することができた。
    • そのほとんどは、チームとしての雰囲気や心理的安全性が大きく関わっていた
  • TDDの方針と同じで、とにかく粒度を小さくして、学習機会を増やすというのが本当に大切だと感じた。
  • テストの場合、探索的テストと親和性が高そうだと感じた。

*1:詳しくはこちらnihonbuson.hatenadiary.jp

*2:アルコールが入っているし、仕方ない

*3:アルコールが入っているし、仕方ない

*4:いわゆる「我が家」方式

*5:今回はvimを使っていた

*6: 次のスライドのP11とP35 speakerdeck.com

*7: 次のスライドのP27

www.slideshare.net

*8:issueは時間軸をまたぐため、暗黙知の共有、その場での同期だけで十分なのか…と検討の余地がありそう

ロッシェル・カップさんによる「サーバントリーダーシップ」参加レポート #servantleadership

勉強会 技術

はじめに

codechrysalis.connpass.com

  • 具体的な考え方やアクションの話が多くて、とても参考になる勉強会でした！

発表資料

www.slideshare.net

新技術の導入成功へ導く8つの文化的習慣

  • Be Lazy
    • 最小の努力で最大の価値を生み出す
  • リスクや間違いを快く受け入れる
  • 不確実性を受け入れる
  • サーバントリーダーシップ
  • セルフマネジメントチーム
  • 従業員への信頼
  • 個人の自信
  • 階層関係のパワーバランス

ロッシェル・カップさんが聴講者に伝えられること

  • 文化の違い
  • アメリカではどんな働き方や人事管理をしているか
  • 「ソフトスキル」やコミュニケーション方法
  • リーダーシップ

サーバントリーダーシップとは何か

  • 人々が最優先するニーズが満たされているということにフォーカスしてい るリーダー
  • チームが必要としているのをサポートできるリーダー

サーバントリーダーシップはなぜ日本で必要なのか

  • スクラム・Agileの実施に不可欠だから
  • 日本企業への良い解毒剤になるから
    • 縦社会
    • 命令中心
    • お偉い様への反応
    • パワハラ
    • 社畜化
      • 人を大切にしない
      • 監視の強化
        • ドローンで監視するなんて！
  • 良い効果をもたらすことが証明されている

サーバントリーダーシップのインパクト

ガンジーの言葉

  • 世界を変えたいなら自分から変われ

スクラムマスターもサーバントリーダーシップが必要

  • セルフマネジメントのチームにおけるメンバーに対してもサーバントリーダーシップが役立つ
  • 命令にはスキルがいらないが、説得するにはスキルが必要

グーグルで成功する人の特徴

  1. 良いコーチである
  2. コミュニケーション上手・聞き上手
  3. 他人を理解している
  4. 同僚に対して共感的
  5. クリティカル・シンキングと問題解決
  6. 複雑なアイデア同士を結びつける
  7. 科学や工学などの専門性を持っている

この順番が大切だが、日本企業は優先順位が完全に逆だった

さらに、1〜4のソフトスキルが、「コミュニケーション」という一言でしか出てこない。

サーバントリーダーの素質（『Scrum Mastery』より）

頭文字をとって「RETRAINED」と表現している。

  • Resourceful
    • 困難な中で問題を解決する
  • Enabling（日本企業が得意）
    • 他の人が結果を出せるようにサポートする
  • Tactful
    • 機転が利く
  • Respected
    • 尊敬されている
  • Alternative（日本企業が苦手）
    • 新しい文化を導入しようとする
  • Inspiring（日本企業が苦手）
    • 元気づける
  • Nurturing（日本企業が得意）
    • 人の育成
  • Empathic（日本企業が得意）
    • 共感的
  • Disruptive（日本企業が苦手）
    • 現状打破

サーバントリーダーが取るべき行動①（特に日本人が気をつける部分）

  • 上手に質問して、メンバーの考えを刺激する
  • フィードバックの力を活かす
    • 改善してほしい行動を指摘する
    • 良い行動を認める
    • 自分の行動に対してチームからフィードバックを得る
  • 会議のファシリテーションをする
    • 心理的安全性を育てる
    • 「変わった」発言に有難味を示す
    • 少ない発言数の人に発言を促す
    • 多い発言数の人は抑える
  • バカな質問を言えるような雰囲気作りを

サーバントリーダーが取るべき行動②

  • ビジョンを描く
  • チームメンバを個人として知る
    • 1:1の会話をする
      • 日本のリーダーはなかなかやらない
    • 歩き回りによる経営
  • 多様性の尊重（考え方の多様性）
    • 固定観念を避ける
    • 同調すべきというプレッシャーを避ける
  • ポジティブさを保つ（チアリーダーになる）

サーバントリーダーが出来ているかどうかのチェックリスト（毎日確認）

  • 相手に考えさせるような質問をしたか？
  • 改善する余地があるところを指摘したか？
  • 良い行動に対して感謝を示したか？
  • MTG時、皆がバランス良く発言したか？
    • 喋り過ぎる人がいなかったか？
    • 黙っている人がいなかったか？
  • MTG時の発言には、バリエーションや新しさを感じたか？
  • 励ましの言葉をかけたか？
  • 目標となるビジョンについて触れたか？

フィードバックを依頼する方法

  • 上司がどういう行動をとったか
    • フィードバックの依頼を忘れると、恐い（上司との壁？）と感じる可能性あり
  • 「役立てる上司になるには？」と聞いちゃおう

質疑応答

Q. サーバントリーダーシップのメンバーはどんなスキルを要求される？

  • メンバーの自主性が問われる
  • Agileを導入しようとしたが、指示待ちメンバーだったということはある
  • サーバントリーダーシップを行うのと同時に、メンバーが自信を持つのもセットで
    • 「私はこれだけ期待しているんだ」と伝える
    • 「あなたに考えてほしい」と伝える
      • 指示待ちからの脱却

Q. メンバーの自主性に任せて行った結果、メンバー間のコンフリクトがあった時にどのように対処するか？

Q. 命令とサーバントリーダーシップのビジョンの違いは何か？

  • 達成したいことを示すことが大事
  • 達成するための方法はメンバーに考えてもらう
アメリカの銃規制の話
  • アメリカではなかなか拳銃の規制ができない。
  • そんななか、銃殺事件があった高校の学生に注目している。
  • 学生だからお金などが何もないが、コミュニケーション能力があった。
    • インタビューでビジョンを示した
    • 感化するスピーチをしている
    • Twitterなどでコミュニケーションをしている
  • これは命令したわけではないが、スピーチなどによって市民に刺激した
    • ライフル協会との関係を切る企業が増えた
    • 拳銃規制推進を目指しているボランティア団体への寄付が激増した

Q. サーバントリーダーシップを発揮する組織構造は？

  • これはどの本にはあまり書かれていない点。
  • 今後研究する必要があるかも
  • ただし、これを理由にサーバントリーダーシップを採用をしない言い訳にしてほしくない

Q. 状況によってサーバントリーダーシップが適切でない時はあるか？

  • 軍隊や自然災害のときとかはコマンドコントロールが適切な時が多い
    • ただし、自然災害の時は命令ではなく、自分自身で動いたほうが良いときもある。

Q. 感化させるビジョンを作るスキルは？

  • 達成することで世の中がどのように良くなるかを描いて伝えること
    • セキュリティの組織のビジョン
      • 「数百万人を守って」→無味乾燥で分かりにくい
      • 「Yahoo.comのようにはならない！」→分かりやすい

Q. サーバントリーダーシップはチームの成果が上がると思うが、そのためにリーダーはどのようにメンバーを感化させれば良いか？

  • サーバントリーダーシップのチェックリストをメンバーに対しても使ったりすると良い
    • ただし、最後の項目「目標となるビジョンについて触れたか？」は除く
  • そのために、リーダーがチェック実行の模範になる

Q. サーバントリーダーシップはボトムアップの方法のように見える。一方で、上の人は命令しようとする。

  • 上からの命令はやるが、「方法についてはメンバーで考えさせてほしい」とバッファを貰う
  • 目標をどうするかメンバーが決めて、リーダーはそのことを上に伝える

Q. リーダーは上と下に挟まれて、ストレスが溜まってしまうのでは？

  • リーダーのストレスについては、自分の心のケアが重要

Q. 社員が元々、働くことに悲観的な人がいる。その中でサーバントリーダーシップを行うためにはどうすればよいか？

  • 日本のマネージャが部下を選べないのはかわいそうな点。
  • 日本ではもっと流動性のある社会になるべき
  • 日本ではモチベーションの低い人の割合が多い
  • 会社に対する信頼について、日本が世界で一番低いというデータもある
  • まずは部下を個人として知ること
    • 何を大切にしているか？
    • なぜこの会社を選んだのか？
    • 人生の目標は？
    • などなど…
  • もしかしたら潜在能力があるかもしれない
  • まずは、なぜモチベーションが低いのか聞いてみよう

Q. サーバントリーダーシップが無理そうな上の人の特徴を知りたい

  • 会社の中のインセンティブ構造が変わらないと難しい部分はある
    • ミスの懲罰性を無くすとか
    • 人事制度を変えるとか
  • それでも、どんな人でもサーバントリーダーシップは適応可能だと信じている
    • 過去にも、セミナーを行った結果、保守的だった運用部門のマネージャが変わった例もある
  • 何がカギになるかは分からない

Q. サーバントリーダーシップの発揮をどのように評価すれば良いか？

  • チームの成果をリーダーの評価とすれば良い

Q. 道半ばなチームの成果を評価した結果、「成果が出てないから、やっぱりサーバントリーダーシップを止めよう」となるのでは？

  • 「成果が出てない」には色々なパターンがあり、複雑で答えにくい。

感想

  • サーバントリーダーシップについては以前から知っていたが、今回の勉強会では、より具体的なアクションの話が多くて参考になった。
  • ロッシェル・カップさんは日本企業にも詳しいということもあり、日本企業での注意点についても多く話されていて「確かに」と頷くような場面が多かった。

#JaSST で話題になったFlakyなテストについて発表しました！

JaSST 勉強会 技術 発表

きっかけ

このツイートがきっかけで発表することになりました！*1

話す内容

以下の記事の内容を話します。

記事は頑張って書いたものの、頑張りすぎて長くなってしまい、特に伝えたい部分が伝わってない気がしたのでスライドにしました。

せっかくスライドにしたので、補足の説明も含めて、私が分かる部分を発表します！*2

発表する勉強会の情報

以下の勉強会で話します。

既に定員を超えていますが、以下のようなことに繋がるので、キャンセル待ちでも参加登録してくれると嬉しいです。

  • 過去の傾向から見ると、1/3～半分程度のキャンセルが発生するので繰り上がって参加できる

  • イベント申込者数によって、今後の再演も検討できる

ちなみに、発表者は私だけでなく、EgaSaさんとshimashima35さんも発表します。

お二人の発表内容は、私もすごい楽しみです！

それでは、4月11日に渋谷でお会いしましょう！

発表しました！

ということで、発表スライドを共有します。

speakerdeck.com

*1:ちなみに現在は40ページ

*2:ちなみにMicco氏にも発表の許可を快諾頂きました！

JaSST'18 Tokyo チュートリアル「計画立案とふりかえりでリスクを捉えよう！～SaPIDTOC：未来予想型チーム運営WS（テスト編）～」 #JaSST

JaSST 勉強会 技術

はじめに

  • この記事はJaSST'18 Tokyo（ソフトウェアテストシンポジウム）のチュートリアル「計画立案とふりかえりでリスクを捉えよう！～SaPIDTOC：未来予想型チーム運営WS（テスト編）～」で経験したことを書いたものです。
  • JaSST'18 Tokyoについてはこちらを見てください。

JaSSTソフトウェアテストシンポジウム-JaSST'18 Tokyo

  • 本記事ではチュートリアルの内容そのものではなく、ワークを行っていく中で苦労した点を書きます。
  • SaPIDについては、以前に私が学んだ内容を参考にしてください。
    • 今回は、以下の記事の内容を理解した上での記事の書き方になってしまう部分があります。ご了承ください。

nihonbuson.hatenadiary.jp

メンバー構成

  • このチュートリアルでは、3〜4人のチームでワークを行う形式になっていました。
  • 私のチームでは、SaPID経験者は私のみであり、他の3人はSaPIDもTOCも初めてということでした。
  • なので今回は、他の人の意見に対して質問をする役目を私がとりました。

苦労した点

  • チームとして進めていく中で苦労した点が2つありました。

苦労した点その1：意見をまとめてしまう

  • 意見をまとめてしまうことで、抽象度が高くなり、本当の問題を見えづらくしてしまう状態になりました。
  • 例えば、「準備内容が曖昧」という付箋を書いたとします。
  • それに対して、「どんな準備をすると思いますか？」と質問すると、以下の2つが出てきました。
    • これから作業する対象がどんなものか理解するために準備をしなくてはいけないはず
    • これから作業する内容が何か把握するために準備をしなくてはいけないはず
  • これらは「準備内容が曖昧」という内容よりも具体的です。
  • さらに、「人によって準備に対する認識が異なっている」という事実も見つけ出すことができました。

  • しかし、これらの話をしても、「けど、こういうことをまとめると『準備内容が曖昧』の1枚になるよね」と、その1枚にまとめようと考えてしまう人がいました。

  • 「まとめたい」という気持ちは分かります。他人に示す場合は、「準備内容が曖昧」の1枚だけにした方が、全体としてもスッキリします。

  • しかし、SaPIDの作業を共に行う場合には、問題認識をハッキリさせるためにも、これらの具体的な話は残したほうが良いように個人的には思っています。

苦労した点その2：疑問形に対するアプローチ

  • 今回は、とある題材に対して、「将来どんなことが起こりそうか？」を考えるワークでした。
  • そのため、「○○ってどうなんだろう？」「△△が危ないのでは？」という、疑問形が多く出てきました。
  • これらの疑問形は、「それを疑問に思った根拠」が存在するはずです。
  • 今回は、その根拠を引き出すための質問に苦労しました。
  • 「○○って別にそのままでも大丈夫なんじゃない？」「△△ってどうして危ないと思ったのですか？何か過去に似たような経験がありましたか？」と聞いても、「いや、だって○○はダメだと思う」「△△が危ないのは当然でしょ」というような答えが出てきてしまいました。
  • ここに関するアプローチはもう少しできたのではと思ってます…。

終わりに

  • 以前書いた記事では、SaPIDでどのように取り組むべきかという話を書きました。
  • しかし、自分1人ではなく、チームとしてのワークをしたときには、どのようにチームとして協同し、進めていくか課題が見えた気がします。

t_wadaさんと柴田芳樹さんの講演から、テスト駆動開発の良さを実感しました。 #JaSST

JaSST 勉強会 技術 TDD ペアプログラミング

はじめに

  • 先日、JaSST'18 Tokyoが開催されました。

JaSSTソフトウェアテストシンポジウム-JaSST'18 Tokyo

JaSST'18 Tokyo チュートリアル「コードを書きながら学ぶテスト駆動開発」

  • テスト駆動開発(TDD)の第一人者であるt_wadaさんが講師となってTDDを学びました。

当日のツイートまとめ

  • 以下のページです。*1

togetter.com

チュートリアルの構成

t_wadaさんによるライブコーディング付きのTDDの方法についての発表

  • もう、この一言に尽きる。こんなになめらかなライブコーディングは初めて見た。

  • 滑らかすぎて、必死についてきてツイートしたので、それは上記のまとめページを見てください。

  • 自分は初めてTDDを学んだのですが、何よりも「TODOの出し方」から「1回目のRed解消」までのやり方は非常に参考になりました。

  • 今回は全員がeclipseを利用するという制限で行っていましたが、それによって「ライブコーディングで示したいたのと同じことを、自分が使っているIDEでできるのか！」と共感できました。

  • 特に、以下の一連の流れは、「テストコードを書く」というよりも、「実装する（それがたまたまテストコードだった）」という感覚になりました。

    • fail()でとりあえず失敗するテストコードを書く
    • まだ作っていない変数や関数を記述して、コンパイルを失敗させる
    • 変数を宣言させてコンパイルを通る状態にしていく
    • 関数を宣言させて、プロダクトのクラスを作成することでコンパイルを通る状態にしていく
    • でっち上げでも良いからテストコードの通る値をreturnして、テストも成功するように変更する

  • また、JUnit5ならではのテクニックも参考になりました。

ペアプログラミングでのTDD体験

  • さて、t_wadaさんの発表を聞いただけでは、理解はできても実感はできません。

  • 今回のチュートリアルでは、2人1組になり、ペアプログラミングをしてTDD体験をしました。

  • この体験を通じて、色々とTDDでの苦労を体験できました。*2

    • TODOの分割で、優先度の高いものがどれになるか考えられない
      • FizzBuzzの例でいえば、「数を文字列に変換」とかを考える前に「3の倍数だったらFizzと変換」とかを考えちゃう
    • 取り掛かるテストコードが具体的にならず、試行錯誤で具体的にしていた
      • 何を入力値で、何が期待結果になるか分からぬまま、取り掛かろうとしていました
    • 細かい関数に分けて考えられない
      • 1つの塊のコードで考えるクセが付いているらしく、それを細かく区切るというところに頭が回らない
    • ナビゲートが大変
      • 経験年数から見て、今回は自分がナビゲート役でしたが、TDDは初めてだったので、上記の苦労した点の改善策を上手く相方に伝えられませんでした…。

  • ここらへんは、もっともっとTDDに慣れ、ペアプロに慣れることで改善していきたいと思います。

  • チュートリアルならではの内容で非常に勉強になりました！

JaSST'18 Tokyo招待講演「私が経験したソフトウェアテストの変遷」

  • 今回の招待講演は柴田芳樹さんによるお話でした。

当日のツイートまとめ

togetter.com

招待講演の構成

  • 大きく分けて、以下の3部構成でした。

    • TDD、CIの話
    • 柴田さんの経験談
    • ソフトウェア開発とQA

TDD、CIの話

  • 個人的には以下で紹介する「フィードバックループを短くする」の図が招待講演の中で一番響いた部分です。

  • QAテストなどは開発者へのフィードバックが長い。

f:id:nihonbuson:20180329092359p:plain

http://jasst.jp/symposium/jasst18tokyo/pdf/A7.pdf#page=9

  • 単体テストになると開発者へのフィードバックは短くなる。
  • しかし、実はこれが最短ではない。

f:id:nihonbuson:20180329092432p:plain

http://jasst.jp/symposium/jasst18tokyo/pdf/A7.pdf#page=10

f:id:nihonbuson:20180329092445p:plain

http://jasst.jp/symposium/jasst18tokyo/pdf/A7.pdf#page=11

  • t_wadaさんのチュートリアルのおかげで、「常に実装している感覚」が実体験と共に実感できました。

  • 手で行ったテストは資産ではない…「自動テスト実装までやると余計なコストがー」という人に聞かせてあげたい。

柴田さんの経験談

  • ブログに書き残すことができない話もしていたため、あまりメモを残せていません…。
  • ただ、Flakyなテストに悩んでいた話も聞けて、「ここでもFlakyが！」と一人で反応してました。

ソフトウェア開発とQA

  • 実装より前に設計するという、ソフトウェア開発において当たり前の話がなかなかできていない気がします。
  • そして、それを上司が理解していない場合、考えをひっくり返すのにパワーがいるという話は「確かにー」と思ってしまいました。

質問

  • この質問が印象的でした。
  • この質問では、「API設計」を前提とした質問でしたが、教育についてはどんな場合でも同じようにいえると思う。
  • 教育や研修については、どれだけ現場と近付いて協力的に行えるか、もっと考えるべきだなと思っている。
  • そういう意味でもペアプログラミングは教育的視点も含めて良い方法なのだろうなと感じました。

終わりに

  • 今回のJaSSTでは如何に開発とテストが協同して行われるかが（個人的に）テーマだった気がします。
  • 基調講演などでは自動テストがテーマでしたが、今回参加・紹介したテスト駆動開発もその一つだったと感じました。

関連記事

  • JaSST'18 Tokyoでは自動テストの話も盛んに行われていました。自動テストに関する記事はコチラです。

nihonbuson.hatenadiary.jp

nihonbuson.hatenadiary.jp

*1:自分以外、誰もツイートしてなくて、「あれ？これってツイート禁止のチュートリアルだっけ？」と不安になりました。

*2:これはTDD自体で残り続ける問題というよりも、慣れで解消できるような問題だと思っています