テストエンジニアがTDDブートキャンプに参加してきました #TDDBC

はじめに

先日、TDDBCに参加してきました。

tddbc.connpass.com

このイベントで色々と学ぶことがあったので書きます。

目次

今回の題材

今回のお題は「自動販売機」でした。

プログラミングのお題: 自動販売機 (設計進化重視バージョン) · GitHub

ペアプロ時の工夫

TDDBCではTDDだけでなく、ペアプロも体験しました。 なお、今回は私(テストエンジニア)が常にナビゲータの立場、相方が常にドライバーの立場でペアプロを行いました。 そんな中、今回工夫した点をこのブログで共有します。

工夫その1:忠実に実装する

まずは、お題1を考えた時の工夫点です。

お題1. ボタンを押すとコーラが出る

ボタンを押すとコーラが出ます。

このお題に対し、コードは以下のように書きました。

public String buy() {
    return "コーラを購入しました";
}

しかし、これでは「ボタンを押すとコーラが出る」ではなく、「購入しようとするとコーラを購入できる」となり、お題の意図以上に業務全体を考えた実装になってしまっています。 なので、「ボタンを押すとコーラが出る」というお題に対して忠実に実装すべく、以下のように変更しました。*1

public String pushButton() {
    return "コーラ";
}

工夫その2:お題を分割する

お題1を終わらせた後、お題2を着手しました。

お題2. お金を払う

100円コインを投入してからボタンを押すとコーラが出ます。

100円コイン以外は投入できません。

このお題をそのまま行うのではなく、TODOの分割に着手しました。

TODOに落とし込むための会話ログ

以下は、TODOに落とし込むために行った会話です。


  • 自分「これって、どんなテストがありますかね?」
  • 相手「まず、100円コインを投入するとボタンが有効になるか(★1)、ですかね」*2
  • 自分「なるほど。100円コインを入れた場合の話ですね。他にはどんなテストがありますか?」
  • 相手「えっと、100円以外のコインを投入しても、ボタンが有効にならない場合ですかね。」
  • 自分「そうですね。ただ、『100円以外』とは具体的にはどんな値が考えられますか?」
  • 相手「例えば、10円コインですかね。」
  • 自分「ふむふむ。ちなみにこれらって、『ボタンが有効になる条件』をテストしていますね」*3

  • 自分「それでは、他にはどんなテストが考えられますか?」

  • 相手「ボタンを押した結果のテスト(★2)をしたいです」
  • 自分「ボタンを押した結果のテストって、具体的にはどんなことを考えてますか?」
  • 相手「ボタンが有効な場合に限り、ボタンを押すとコーラが出るようなテストですかね」
  • 自分「なるほど。それって、具体的なテストを考えると、どういう風になると考えてますか?」
  • 相手「100円コインを投入した後にボタンを押すとコーラが出るテストですかね」
  • 自分「ほうほう。そうですね。それ以外だとどうですか?」
  • 相手「ボタンが無効な場合、ボタンを押すと何も出ないことをテストしたいですね。」
  • 自分「それって、具体的にはどんなテストになりますか?」
  • 相手「10円コインを投入した後にボタンを押すと、何も出ない、とかですかね。」
  • 自分「なるほど。」

TODOを階層構造化する

ここまでを踏まえて、私は以下のように階層構造化して整理しました。

  • ボタンが有効になる条件をテストする

    • 100円コインを投入するとボタンが有効になる(★1)
    • 100円以外のコインを投入してもボタンが有効にならない
      • 10円コインを投入してもボタンが有効にならない
  • ボタンを押した結果のテスト(★2)

    • ボタンが有効な場合に限り、ボタンを押すとコーラが出る
      • 100円コインを投入した後にボタンを押すとコーラを出る
    • ボタンが無効な場合、ボタンを押すと何も出ない
      • 10円コインを投入した後にボタンを押すと何も出ない

階層構造化した文章のうち、青字は相方が思いついた部分、緑字は私との会話で加えていった部分です。

テスト設計の知識と紐付ける

今回行った会話は非常に興味深いです。

前半部分は(★1)のように、具体的な値を思いついて、そこからテストの条件を考えている、つまりボトムアップ型の考え方を行っています。

一方、後半部分は(★2)のように、どんなテストをすべきか考えて、そこから具体的な値を考えている、つまりトップダウン型の考え方を行っています。

実は、このボトムアップ型、トップダウン型という表現は、先日あったテスト設計コンテストU30クラスチュートリアルの資料及び発表でも話しています。

http://aster.or.jp/business/contest/doc/2019_U-30_V1.0.0%20.pdf#page=13

以下のツイートは、テスト設計コンテストU30クラスチュートリアルの発表聴講時のツイートですが、この発言は上記の会話のことを指しています。

工夫その3:Greenのままリファクタリングを行う

最後はお題3での工夫です。

お題3. ウーロン茶追加

押したボタンに応じてコーラかウーロン茶が出ます。

他の飲み物も追加してみましょう。

準備:お題2までのコード

お題2までで、こんなコードが出来上がっていました。(一部抜粋)

private boolean canBuy = false;
public String pushButton() {
    if (canBuy){
        return "コーラ";
    }
    return "";
}

一方、テストコードはこんな感じで書いていました。(一部抜粋)

@Test
public void 100円コインを投入した後にボタンを押すとコーラを出る() {
    VendingMachine vendingMachine = new VendingMachine()
    vendingMachine.insertCoin(100);
    String result = vendingMachine.pushButton();
    assertThat(result, is("コーラ"));
}

@Test
public void 10円コインを投入した後にボタンを押しても何も出ない() {
    VendingMachine vendingMachine = new VendingMachine()
    vendingMachine.insertCoin(10);
    String result = vendingMachine.pushButton();
    assertThat(result, is(""));
}

お題3の方針

お題3を考えると、以下のようなテストコードを考えたくなります。

private static final int COLA = 1;

@Test
public void 100円コインを投入した後にコーラのボタンを押すとコーラが出る() {
    VendingMachine vendingMachine = new VendingMachine()
    vendingMachine.insertCoin(100);
    String result = vendingMachine.pushButton(COLA);
    assertThat(result, is("コーラ"));
}

上記のテストコードを実現するには、お題2で"pushButton()"というメソッドだったのを、"pushButton(id)"というメソッドに変更することになります。

しかし、そのままメソッドの引数を変更すると、今度は今まで通っていた、"pushButton()"メソッドを用いたテストコードが通らなくなります。

新たなテストコードをGreenにするために、既存のテストコードを修正することになるため、新規テストコードのRed→Greenなのか、既存テストコードのRefactoringなのかが区別つかなくなります。*4

どうすれば良いでしょう…?

その時、教わった方法に納得しました。

既存コードをKeepしたまま実装する方法

手順1:別メソッドを作る

まず、別メソッド名で作ります。

private static final int COLA = 1;

@Test
public void 100円コインを投入した後にコーラのボタンを押すとコーラが出る() {
    VendingMachine vendingMachine = new VendingMachine()
    vendingMachine.insertCoin(100);
    String result = vendingMachine.pushButtonWithProductId(COLA);
    assertThat(result, is("コーラ"));
}
private boolean canBuy = false;
public String pushButton() {
    if (canBuy){
        return "コーラ";
    }
    return "";
}

public String pushButtonWithProductId(int id) {
    if (canBuy){
        return "コーラ";
    }
    return "";
}

上記のように、"pushButton()"とは別のメソッド"pushButtonWithProductId(id)"を作り、新規のテストコードは"pushButtonWithProductId(id)"を用います。

その際、"pushButtonWithProductId(id)"のメソッドの中身は、"pushButton()"のメソッドの中身をそのままコピペします。

これで、既存テストコードを変更することなく、Red→Greenにすることができました。

手順2:元々のメソッドを変更する

次に、"pushButton()"の中身を以下のように変えます。

private static final int COLA = 1;
private boolean canBuy = false;
public String pushButton() {
    return pushButtonWithProductId(COLA);
}

public String pushButtonWithProductId(int id) {
    if (canBuy){
        return "コーラ";
    }
    return "";
}

元々、メソッドの中身は"pushButton()"と"pushButtonWithProductId(id)"で全く同じでした。

なので、メソッドを呼び出しても同じ結果なはずです。*5

手順3:呼び出すメソッドを変更する

そして最後に、既存のテストコードで呼び出すメソッドを変更します。

すべてメソッドを"pushButtonWithProductId(id)"に変更したら、"pushButton()"が必要なくなるので、削除します。

private static final int COLA = 1;
@Test
public void 100円コインを投入した後にボタンを押すとコーラを出る() {
    VendingMachine vendingMachine = new VendingMachine()
    vendingMachine.insertCoin(100);
    String result = vendingMachine.pushButton(COLA);
    assertThat(result, is("コーラ"));
}

@Test
public void 10円コインを投入した後にボタンを押しても何も出ない() {
    VendingMachine vendingMachine = new VendingMachine()
    vendingMachine.insertCoin(10);
    String result = vendingMachine.pushButton(COLA);
    assertThat(result, is(""));
}

おわりに:ブートキャンプから学べたこと

今回は、テストコードもプロダクトコードも少ししか書いていませんでした。

しかし、ここで学んだことは、実務でも使える実践的な方法だったと思います。*6

それをブートキャンプの中で学べたのは非常に有意義でした。

*1:変更は、Greenの状態の時にRefactoringとして行いました。

*2:お題1で、業務全体ではなく実装に忠実になることを考えた結果、分割されたこのテストを思いつくのが素晴らしいですし、純粋にスゴイと思いました!

*3:本当は、ここで「コインを入れない場合」を思いついていますが、ここでは敢えて言いませんでした

*4:今回の例だと、同時に直せば良いと思うかもしれないですが、修正箇所が数十箇所あったらどうでしょうか?

*5:もちろん、このRefactoring中にもテストは常に回してGreenであることを確認します

*6:これがKataなのか…!

WACATE 2018 夏に参加しました #WACATE

はじめに

6月16,17日にWACATEへ行ってきました。

wacate.jp

遅くなりましたが、今回はそのWACATEであったことを書きます。

目次

ガイドライン作成

今回のWACATEは、新たな試みとして「チームのガイドライン決め」を行いました。

これは、2日間のチームで目指したい雰囲気と、それを達成するための行動を示そうというものです。

まずは1人ずつ、目指したい雰囲気を書くのですが、私は「納得感がある」と書きました。

これは自己紹介の際に、WACATE2回目参加の方が「前回のWACATEはぶっちゃけ何も覚えてない」という発言があったためです。

それを聞いた私は、

  • この人に、今回のWACATEは印象を持って終えてもらおう
  • そのためには、この人自身が腹落ちして進めるのが大事
  • だったら、目指したい雰囲気は「納得感がある」状態だよね
  • これだったら、他の(特に初回参加の)人にも有益だよね

と思い、「納得感がある」と書きました。

BPPセッション

BPPセッションは吉武さんによる2017年度JaSST振り返りでした。

www.slideshare.net

このセッションでは、何しろ吉武さんのインプットの多さに圧倒されました!

そして、このBPPセッションが、今までインプットしていた吉武さんにとってのアウトプットの場の1つなんだろうなと、ひしひしと感じました。

1日目のワーク

1日目は、ユースケース図、アクティビティ図、状態遷移図について学びました。

www.slideshare.net

speakerdeck.com

分かっているつもりになっていたけど、難しい!

特に、状態遷移図では、チームメンバーそれぞれと書かれた図が違っていて、すごい驚きました。

そして、違う部分を見つけて、その違いについて議論し、納得してチームとしての答えを出すのが楽しかったです。

ちなみに、この行動は、2日目のワークに大いに役立つこととなりました。

ガイドラインの見直し

1日目の最後に、チームで定めたガイドラインの見直しを行いました。

ガイドラインの見直し結果についても、チームで納得できるものになりました。

そして、この見直し時間の最中に、誰かがボソッと「これって守り神だ…」と言いました。

その瞬間、「ん?今なんて言った?もう一度教えて!」と私は食いついて確認を求めました。

そして、そのボソッと言った「守り紙」(神ではなく紙にした)を、「ガイドライン」という呼び名に変えて採用し、紙に貼りました。

おそらく、この言葉がチームとしての結束をさらに深める出来事だったと思います。

自分で写真を撮っていなかったので、同じ班だった、たまのびさん( id:tamanobi )のツイートを拝借

夜の分科会

分科会では初心者向けのグループに混じって参加し、今回のワークの悩みなどを聴く役割に徹しました。

その時に、「状態遷移図が分からなかった」という初参加者(Aさん)から、以下のことを感じました。

  • 何が分かっていないのか分からない
  • (初参加者である)自分はどうしても、経験者である皆の足を引っ張ってしまう
    • 結果、ワーク中に質問をできなくなる

なので、私は以下の2つのプロセスを踏みました。

「何が分かっていないのか分からない」を脱却する

まず、Aさんに対して、その思考プロセスを聴くことにしました。

その時は以下のような問いかけをしました。もしかしたら、少し意地悪に感じるぐらいにわざとらしく。

  • 今回の問題って、どんなことが書いてあったっけ?
  • 具体的に、どんな命令をしたら、次のアクションにできたんだっけ?
  • それらの考えを、おそらく無意識に頭の中で考えていたうえで、紙にはそれをまとめた内容を書いたんだね。
  • 今言っていた細かいことも、どんどん書いていいんだよ

ここでのポイントは、「私の方からは何も答えを言っていない」ということです。

あくまでも、質問を答える人(Aさん)が考えていたということを強調させました。

Aさんは、私の少々意地悪な質問に対してもまっすぐ答えてくれました。ありがたかったです。

「質問できない」という状況を脱却する

Aさんへの問いかけが終わった後に、その様子をずっと見ていた他の参加者に「このやり取りを見ていてどう思った?」と聞きました。

すると、色々な意見が出てきました。

「こういう風な思考を元に自分はやっていたんだ」と思い返してくれた人もいたようです。

そして、Aさんに以下のアドバイスをしました。

  • Aさんが質問することは、他の人に対してこんなにも良い影響を与えてくれていた。
  • だから、チームメンバーに質問することは決して無駄なことじゃない。お互いのためにもなると思う。

Aさんが、2日目には、もっと積極的にチームに加われていれば幸いです。(他チームだから様子は分からなかったけど)

2日目の朝イチセッション「受けてみようUMTP認定試験!」

2日目の朝は、今回から実行委員になった岡内ワニさんの発表でした。

www.slideshare.net

今回のテーマであるモデリングを、WACATE後にどのように活かしていくかについて説明してくれました。

モデリングに対して、冷静に見つめ返す良い機会になった気がします。

2日目のワーク

2日目のワークは、あるお題に対してグループで成果物を出すというものでした。

このワークでは、いくつか工夫して進めていきました。

工夫その1「意見を極力拾っていく」

今回は、チーム内で一番参加回数の多い自分が方針を決めるのではなく、みんなの意見を拾って、一番納得度が高い部分を抽出して選んでいく方法にしました。

なので、ワークで扱う図についても、みんなの話を聞いて決めていきました。

工夫その2「自信のない人!」

ワーク中は、以下のStepで進めていきました。

  • Step1. 個人ワーク
  • Step2. 全員で見せ合ってすり合わせ

その際に工夫として、すり合わせの最初に「じゃあ、自信の無い人!」という声かけをしていきました。

そうすることによって、「自分はここまで完璧なものを描けてないから、自分の内容は無視して進めて…」みたいな意見を出させないようにしました。

グループワークは、グループのメンバー全員が参加者です。そこに、参加回数とか経験年数は関係ありません。

みんなが参加し、みんなで意見を出し、みんなで納得するように心がけていきました。

工夫その3「違いを見つけることに集中する」

1日目で、「皆さんの意見は少しずつ違うものだ」ということに気付きました。

そこで、私は特に参加者皆さんの意見を聞き、意見に違いが無いか探すことに集中しました。

言葉で話していると違いは見えづらいです。

しかし今回のモデリングのように、図を使いながら説明していることで、より違いに気づくようになりました。

工夫その4「納得してない顔を見逃さない」

最初のガイドライン(守り紙)で書いたように、「納得感がある」ということを目指すにあたり、納得してない顔を見逃さないように心がけました。

もちろん、「納得している(と思ってた)」という人もいます。

しかしそういう人も、納得してない人を前に、あの手この手で説明するうちに、「あ、自分も実は納得してなかったんだ」と気付くことができます。

私の班の場合、納得してない表情を示すのが上手かったのが、たまのびさんでした。

成果物

上記のような取り組みで行った結果、私のチームの成果物は、すべてのチームの成果物で一番少ないものとなりました。

しかし、私のチームの発表者を含め、おそらくメンバー全員が「この部分は重要」「この部分は苦労した」と言った内容が殆どズレない状態になっていたと思います。

余談の感想

たまのびさんは、自身のブログでこんな余談を書いています。

このWACATE 2018夏で知った手法を会社に持ち帰って、活かそうとするのは良い心意気だと思いました。 だけど、僕がこのWACATEで理解したのは、「何が問題か」「どこが重要か」見極めることです。 勇み足にならないために、ゆっくりと問題と向き合って、そのとき適切な手法で解決しよう。

WACATE2日目の感想 - TAMALOG

この余談って、すごい大事なことだと思います。

私自身もワークをしていて実感できたのですが、「どこが重要か」を見極める、適切な手法を見極めることの大切さがあると思っています。

今回は、ユースケース図、アクティビティ図、状態遷移図の3つでしたが、それぞれが独立であるのではなく、1つの図のアウトプットが別の図のインプットの手がかりになったと実感できました。

招待講演「原因結果グラフとWACATEは僕に何を教えてくれたのか」

招待講演は加瀬さんによる原因結果グラフについての講演でした。

www.slideshare.net

加瀬さんは、一つ一つ具体例を用いて説明してくださったので、すごい分かりやすかったです!

また、秋山さんのお話しなど、多岐にわたってお話ししてくださいました。それらの話も非常に興味深かったです。

クロージング(ポジションペーパー賞の発表)

さて、このWACATEでは毎回、クロージング時にポジションペーパーに関する賞が発表されます。

ポジションペーパーとは

WACATEの参加者が、参加表明時に提出する紙のことです。

2日間、この紙を使って自己紹介などをします。

ガイドライン作成の章にあった、「前回のWACATEはぶっちゃけ何も覚えてない」という話も、ポジションペーパーに書いた内容を元に話していました。

ベストポジションペーパー

ポジションペーパーは自己紹介のためだけではありません。

同時に賞の対象にもなっています。

そして、その中のベストポジションペーパー賞に私の内容が選ばれました!

f:id:nihonbuson:20180626001253j:plain

ということで、今回「2017年度JaSST振り返り」を発表した吉武さんのように、次回のWACATEで発表する権利を頂きました!

私のポジションペーパー

私のポジションペーパーの内容を公開します。

f:id:nihonbuson:20180626081947p:plain

製品開発を見ていると、いがみ合い・戦いの末に出来上がっている製品が非常に多く感じています。

そうではなく、如何に皆が幸せな状態のまま製品開発に向かうことができるのか、常に考えながらやっていきたいと思って、今回のようなポジションペーパーを書きました。

おわりに

最近、勉強会や仕事をやっていると「テストって何だろう?」と思い返すことが多くなりました。

そのときに、JaSST Kansaiで見た以下のツイートをきっかけとして、にしさんの講演を見ました。

www.youtube.com

「テストとは納得してもらうことである」

良い言葉だなと思います。

今回のWACATEでは、この納得を実感できたワークになったように感じました。

余談:他にもたくさん、今回のWACATE記事があがってますよ!

今回はブログ記事にしている人が多いなー。

inside.pixiv.blog

tamanobi.hatenablog.com

tamanobi.hatenablog.com

tonono.hatenablog.com

tonono.hatenablog.com

yoshikiito.net

yoshikiito.net

teamomusoba.hatenablog.com

teamomusoba.hatenablog.com

panmania.hatenadiary.com

panmania.hatenadiary.com

qiita.com

tanakalivesinsendai.hatenablog.com

ameblo.jp

devtest.hatenablog.com

QA Meetup 2018 パネルディスカッション 参加レポート #QAMU2018

イベント概要

  • 先日、QAについてのMeetupがビズリーチで行われました。

  • 今回はその中の後半にあったパネルディスカッションについて載せます。

登壇者

パネリスト

  • 小林 依光(以下、小林)
    • KLab
  • 安納 達弥(以下、安納)
  • 柿崎 憲(以下、柿崎)
    • サイバード
  • 中野 直樹(以下、中野)
    • LIFULL
  • 江川 さおり(以下、江川)
    • ビズリーチ

モデレータ

  • 山本 健(以下、番長)

明日からのQAの方向性

  • 柿崎

    • 厳しいテーマですね
    • 僕の考え、会社の求めているのは自動化
    • 自動化をまったくやっていないわけではない
      • APIレベルならやっている
    • フロントエンドもテストのインフラがほしい
    • 腕に覚えがあれば
    • フルスタックがあれば
    • サイバードという視点から言えばフルスタックがほしいです
  • 中野

    • LIFULLの人材を募集してます
    • 基本的にはエンジニアリングや開発のことをわかってほしい
    • 各社自動化を取らざるを得ない流れ
    • それも踏まえ、プロダクトのステージを考え、メジャーなプロダクトとスタートアップのプロダクトがある
    • 新規事業で色々と立ち上がっている
    • ステージによって求められるものが違う
      • テスト戦略が求められる
      • テスト戦略をきちんと組み立てる
  • 小林

    • 高速DevOPS
    • 計画があるない、仕様があるないで異なる
    • 不確実性の中から確実性を見つける
    • 求心力を捉える
    • どうやって積極的に取得するか
  • 安納

    • 自分たちがやってる目的を考える
      • ユーザーさんに喜んでもらう
      • 正しく動くとか
    • つまんないゲームってやるんですか?
    • 求められるものが品質
    • その中の一部が自動化
    • 人の感情も担保していくのがアカツキとしての品質
      • 人の感情を動かせるようにする
  • 江川

    • テストアーキテクチャ
    • 手数が足りない
    • 自動化を推進したい
    • 自動化は当たり前になるはず
    • 自動化に興味があれば来てほしい

テストロールの評価(人事評価)

  • 番長

    • テストエンジニアの評価は難しいと思っている
    • どのように評価を行っているのか聞いていきたい
  • 小林

    • まだ品質管理チームを再始動しているので、明確な定義がない
    • メーカーの中にいたころはロールが無かった
    • そういう意識を持ってほしい
    • Web系に転職したら、テスターの方がヒエラルキーが低いのが驚いた
    • ある程度整備できたら、JSTQBで定義している資格のロールに従っているようになると思う
  • 安納

    • 3つある
      • 専門性
      • 自立性
        • 課題解決力
      • チーム力
    • QAだからという区別はしてない
    • 良いものをリリースする時にどれだけ貢献できたのか
    • その中のオリジナリティとしてスペシャリストがいたり
    • 能力とかやりたいことをやっていく
    • あまり固定せずに、売上とかに貢献できたのかを考える
    • そういうところをベースにして取り組んでいる
  • 番長

    • できれば、給料が上がるのか含めて教えてほしい
  • 中野

    • QAエンジニアもエンジニアだから評価は同じ
      • ベースは一緒
    • テクニカル面
    • 業績については、半期ごとの目標に貢献できたか
  • 江川

    • 利益を社員に還元することは良い
    • 1人しかいないので、評価も自分で作っている
    • レベル分けしている
      • テストオペレーター
      • テストリーダー
      • テストマネージャー
    • 最初はセントラルで
    • その後、各プロダクトへ
  • 柿崎

    • プロダクトにどのように与えるか
    • 自動化だけではない
    • 炎上を鎮火することが評価されがちだけど、未然に防ぐことも評価している
      • 外部環境の変化に対応することを重要にした
        • GoogleAppleのレギュレーションに敏感に反応した社員を評価したり

キャリアチェンジ・キャリアアップ

  • 安納

    • テーマが難しい
    • どうやって作るんだっけとか、作るまでの過程を考えて、その準備ができた人からQAの部署に極めるとか
    • 行けば良いんじゃないかな
  • 小林

    • キャリアチェンジはいくつかやり方がある
      • プログラムが掛ける人は品質管理に来ることができる
        • 仕組みを知ってるので、スクリプトや自動化を考えられる
    • テストやQAやってると、将来どうなるのか?
      • PMOになる人もいる
        • 全体を知っていることが多いので
      • プロセス的な話として、ルールを作る
        • ソフトウェアプロセスエンジニアリンググループ
      • AgileやDevOPSに対応して、Scrumマスターになったり
  • 江川

    • 一般的には、オペレータ、リーダー、マネージャへ
    • 大事なのは、何になりたいのかをしっかり考えること
    • ビズリーチの場合は、SETの人が良い
  • 中野

    • 開発からQAになりたい
    • 私もそれになった
    • 自動テストフレームワークをやってたら、うっかりQAになった
    • どうやったらなれるか
      • やりたいからやるって言えば良い
  • 番長

    • 踏ん切りがつかないときの体験入社はできない?
  • 中野

    • 契約形態をとって入社とかなら…
    • あとはワークショップとか

各社で採用している技術

  • 柿崎

    • サイバードでは、いろんなプロダクトが平行で動いているので、都度都度ベストな技術を使う
    • UnityやC#をフロントで使っている
      • 勉強会で学んだ
    • バックエンドはPHP
    • AWSを使ってもいる
    • 最近はボイスUIでGCPも使いたいと思っているが、AWSに寄せすぎていて揉めていたり
    • 技術採択は1ヶ月に1回偉い人が集まっている
  • 安納

    • 開発環境で良いんですかね?
    • イマイチ分かってない部分がある
    • ほぼAWSで動いている
    • データベースはオーロラ
    • サーバー側はRuby on Rails
    • フロントはUnityとか
    • 最近はAWSからGCPになったり
    • 私はAWSの価格交渉担当になっている
  • 江川

    • 事業部がたくさんあるのでチームによって違う
      • 基本的にはScala
      • 最近はElm推しの人が入社した
      • 自分たちでキメていける
    • Jenkinsが基本だが変えようとしている
  • 柿崎

    • 各チームでバラバラだと、プロダクトがポシャった時にスライドしづらいのでは?
  • 江川

    • 事業部ごとに違う会社のようになっている
    • プロセスも違う
  • 中野

    • 推しのポイントはない
    • 自分たちで決めてやっている
    • QAは昔Pythonだったが今はRubyになってる
      • 自動テストとか
    • あとは、レコメンドをAIでやってる
    • また、Home'sアプリは、かざして検索ができるようになった
  • 番長

    • 「かざして検索」のテストはどうやって?
  • 中野

    • ETしかやってないので…
  • 小林

    • サイバードさんやアカツキさんと似ていて、ゲームでユニークな技術はそこまでない
      • Unityを使ったり
    • 世の中にあるものの良いものを適宜使っている
    • 機械での自動テストでは、OpenCVで画像認識をしたりしている

テスト・品質管理の肝

  • 江川

    • 柿崎さんがコアバリューとおっしゃっていたのが本当にそうだと思う
    • ユーザーが何を使いたいのかを考えている
  • 安納

    • 我々の製品を使って長く遊んでもらう
    • ユーザーさんにどれだけコミットできるのか
    • 満足度を高めるためにどうすればよいのか
  • 中野

    • 新しい技術を開発が持ってくる中で、他人事と思わずにQA側もどうすればよいのか考えること
    • 多様性の中でどのように進化させるか考える
  • 小林

    • 日科技連では肝を108個紹介していて、読みきれなかった
    • メトリクスをいっぱい取りたいと思うかもしれないが、それを伝える品管が必要なのではないか
  • 柿崎

    • アンテナをめいいっぱい高く張ること
    • GoogleAppleは技術革新を猛スピードでやっている
    • どんどんプロダクトが死んでしまっている可能性が高い
    • この会場に来ている人は十分高いはず
    • 他の来てない人のアンテナも高くするようにしてあげてほしい。

感想

  • 「この部分ができる人が欲しい」というのが各社ハッキリとしていた印象だった
    • その中でも自動化は当然のように求められているなと感じた
  • テスト・品質管理の肝についてはもっと聞きたかった。

Web Service QA Meeting June-2018 第1部参加レポート #WebQA

はじめに

先日、以下の勉強会に参加してきました。

lifull.connpass.com

第1部では事前に決めていたお題を3つ、第2部では会場から募った質問に答える形式でした。

私は都合により、第1部しか参加できませんでした…。

※酒が入った状態で書いたので、途中、話した内容と違う可能性があります。その場合、指摘いただけると嬉しいです!

目次

お題1「0からQAチームを立ち上げるまで」

登壇者

モデレータ
  • 米山 允章(以下、米山)
パネリスト
  • 山本 健(以下、番長)

    • スライドの画像は韓国旅行のときにサングラスをかけた写真
    • 実際は怖くないです
  • 鶴岡 洋子(以下、鶴岡)

    • ビールが好きです
    • 緊張するんでビールを飲みながら話します

テーマを決めた経緯

  • 米山
    • JaSSTで質問を集めたときに、もっとも投票が多かった質問
    • ただし質問にたどり着かなかったため、今回行う

QAを立ち上げた経験は?

  • 番長

    • 最初のQAとして1人で入ることが多くて、出来上がったチームに入ったことがない
  • 鶴岡

    • 今いるユニファは0から立ち上げるところに関わった

立ち上げ当時の状況やロードマップはあるか

  • 鶴岡

    • 入社時の社員数は20名ぐらい、サーバーサイドのエンジニアが4名、CEOもプレイヤーでした。
    • プロセスの把握、改善点を見つけてカイゼンしていった
    • QAってどういうお仕事を説明した。
      • キャッチコピー「かゆいところに手が届くQA」と言ってた
    • チケットを書いてた
    • 定期リリースにしたい!と言ったりした
    • 要求分析していなかったので、想いを言ってた
    • 「QA」ってこんなもんすよと説明した
    • 社長がMTGしてたら、「話聞かせて」といったり
    • JIRAのステータスの管理をしたり
  • 番長

    • 会社の10人目、はじめてのQAスタッフとして入った
    • 海外赴任していたスタッフがQAのイメージを既に持っていた
    • 最初は既存のフローに入って、どんな価値観でやっているか把握した
    • どういうカイゼンをすればよいか考えた
    • 文化がない状態なので、何をしていくべきか考えてた
    • 立ち上げ時には要求されることがコロコロかわる
      • それに対応するようにしてた
    • ロードマップの話は難しいな
  • 鶴岡

    • ロードマップの話は特にしてなかった
  • 米山

    • 0から立ち上げるのは不安なのかなと思ってた
    • これを聞いてみんな安心するのではないか

立ち上げ時に意識するべきこと。最初の一人に求められるスキル、人間性、経験

  • 鶴岡

    • QAとは何をするべき人なのか色んな人に伝える
      • QAはエンジニア以外にもかなり多くの人とかかわる
    • QAの価値を伝える
  • 番長

    • QAに対する意識がバラバラ
      • 以前に良いQAとか関わっている人は良い
      • 悪いQAに関わった経験がある人は「何だよ」と思って接してくる
    • フレンドリーに接することが大事
    • 最初は良い印象を持っている人と仕事していくことで、「なんだ、QAがいるあのチームいいじゃん」と周りが気づき始める
  • 鶴岡

    • 困っている人を見つけて、どんどん助けていく
  • 番長

    • プレスリリースを書いたりもした
      • リリースされたものの要件を知ってるから書きやすい
      • 既に出ていたプレスリリースを真似して書いた
  • 米山

    • プロダクトがローンチしたあとに入った場合は?
    • ローンチしたあとに入ると辛いのでは?
  • 番長

    • 遅らせる=悪となってしまうので、スピードは大事
    • これぐらい時間がほしいです、という話を予めしておくようにした
  • 米山

    • 2人目のQAはどういうタイミングでどういう人を選ぶ?
  • 鶴岡

    • 自分一人で回らなくなったタイミングで
    • 自分と真逆の人を選んだ
  • 米山

    • 真逆の人だと働きづらいのでは?
  • 鶴岡

    • 全然そんなことない
    • 自動化とかやってくれて助かってます
  • 番長

    • スキルとかばらして集めたほうが良い
    • ただどんなスキルであれ、献身的な態度の人が良いと思う

立ち上げが好き?立ち上げたら次に行きたくなる?立ち上げ中毒?

  • 番長

    • その話は転職芸人で…(笑)
    • さんざん悲劇に襲われていて、仕方ない感じで入る
    • 短くても4年ぐらいはいる
    • 立ち上げ時は、文化や自分が良いと思った体制を組めるのが楽しい
  • 鶴岡

    • その分勉強をする必要がある
    • 自分の理想としているQAができる
    • 私の場合は、立ち上げちゃったら抜けづらくなった
      • 責任感が出てきた
    • 中毒というわけではない

100人規模の大きい組織でQAをゼロから立ち上げるときに意識すべきことは?

  • 番長

    • きっとお金は稼げているプロダクトなので、きっとQA役になっている人がいるはず
    • おそらくQA役となっているであろうディレクターさんに「これは私がやるので」と言ってみる
  • 鶴岡

    • それまでQAがいないということは、QAの価値を上の人が分かってない可能性がある
  • 番長

    • いろいろと社内事情がつらそう…

グローバルの立ち上げで意識したほうが良いことは?

  • 番長

    • 一回関わったが、お互いの国のやり方に触らないようにした
  • 米山

    • 弊社もそうです
  • 番長

    • QAは細かい単位で入らないといけないので、「グローバルで一つの基準を作りましょう」は厳しい

最後に、立ち上げに入ろうとしている人にアドバイス

  • 鶴岡

    • 公の場では言えないことも多いので飲みに行きましょう
  • 番長

    • 辛くなったときにリセットボタンを押して、リフレッシュできるようにしておきましょう

お題2「キャリアプランとビジョンについて」

登壇者

モデレータ
  • 米山 允章(以下、米山)
パネリスト
  • 山本 久仁朗(以下、くにお)

    • いろいろ転職しているが、嫌で転職しているわけではない
  • 柿崎 憲(以下、柿崎)

    • ここにいる3人は転職を多くしている
    • お酒が2本目に突入しているので、いろいろ楽しいことになるかと思う
  • 山本 健(以下、番長)

テーマを決めた経緯

  • 米山
    • JaSSTで質問を集めたときに、キャリアに関する質問が多かったため

QAエンジニアのキャリアパスはどういうものがあるか?

  • 米山

    • QAメンバー → QAリーダー → 品質保証マネージャ → その後は?
    • CQOがまだ浸透していない気がします
  • くにお

    • うちの会社ではCTOになれる人材を作ろうとしている
    • 同様に、QAとかQCとかのスペシャリストができる人を作った上で、トータル的にデキる人を作りたい
    • 自動化などのエンジニアリング寄りもできる人を作りたい
    • ISTQBでもいろいろなドメインがあるので、そういう方向もあると思っている
  • 番長

    • だんだん、位があがっていくと、日本を考えると難しい
    • 自動化は流行っているし、マネージャが一段落した印象
    • いろんなポジションをできるほうが幸せだと思う
  • 柿崎

    • 僕はすでにCQOみたいな位置で仕事している
    • Web系に来たんだったら、キャリアパスって関係ないでしょ
      • てめーでつくれよ
    • いろいろ考えてみたが、どんどんステップアップしていくときって、人に対する影響範囲が広がっていく
      • それが一つのキャリアパスの形
      • マネジメント寄り、ビジネス寄りの話
    • QAエンジニアと名乗る以上は、技術を語れるようになるべき
    • 人数の規模が自分のキャリアパスを構築している
    • テクニカルであれば、新しいテスト技術を作って変えていくという方法もある

今のキャリアを想像していましたか?今後のキャリアプランを教えてください

  • くにお

  • 番長

    • 今は47
    • もともと別の業界を目指していた
    • もともと美術系の大学で、画家になろうと思っていた
    • 面白いものに関わっていきたい
  • 柿崎

    • 今のキャリアは全然想像していなかった
    • 20代後半まではチンピラのような仕事をしていた
    • 初めて品質保証に関わったのはSCEのとき
    • ソフトウェアテスティングの技術を教えてくれた人がいた
      • すごい運が良かった
    • その後はWeb系のテスターに入ったり
    • mixiに入ったあとは良い出会いが多かった
      • 人に会いに行く姿勢を教えてくれた人がいる
      • 今日誘ってくれた人に会うこともできた
    • 出会いの中でできたと思っている
    • 計画的偶発性理論
      • 人のキャリアの8割は偶然起きたことの結果
    • キャリアと考えると10年先とか考えることが多いと思うが、今を考えるべき
    • 新しい機会があったら実現する
      • こういうテスターになると思っていれば、それに強いひとに会いに行けば良いのでは
      • 自分が気づけなかった自分に気付ける
    • 中小企業は後継者不足で潰れることが多い
      • 変な中小企業を買って再建したい

キャリアパスに正解はないと思うが、どんなふうにメンバーに見せたらいいか悩んでいる

  • くにお

    • 転職繰り返しているので気づいていると思うが「無理をしない」ことが大事
    • 楽しく思える現場で楽しくやるのが一番大事
    • 納得する場所で楽しくやっていれば、下の子も楽しんでやってくれるのでは
  • 番長

    • Webの世界は面白すぎて悩む必要がない
    • 美術だとお師匠さんが引退しないとやれる機会が少ないので…
  • 柿崎

    • エンジニアの場合はゴリゴリプログラミングをやることになる
      • プログラミングをやらないとぼんやりする
    • Webディレクターにも同じような悩みがある
    • テクニカルな解決方法を教えることでキャリアアップになる
    • 内発的動機ができれば、キャリアアップできる
    • 「お前が歩いたところがキャリアパスだ」となる
    • どういう風に見せればよいかというと、一緒に悩む
    • 真摯にテクニックを教える
    • あとは「俺の背中を見ろ」と
  • くにお

    • 来た人には教えるが、来ない人には教えない
      • ROIが悪いので
    • みんなを救う気はない
    • やる気のある人は救いたい
  • 柿崎

    • 自分のところだと運良くみんなやる気がある

エンジニアからマネジメント側に移った時、大変でしたか?

  • 米山

    • 準備しておいたほうが良かったこととかありますか?
  • 柿崎

    • エンジニアとマネジメントはまったく別のスキルセット
    • 「マネージャよろしく」って言った瞬間にみんな潰れる
    • テクニックと別の部分がある
      • ぶっちゃけ、顔も見たくないやつと1on1をしなくちゃいけない
      • 裏でなにか言ってるやつにやらせなくちゃいけない
    • 「モチベーションを上げるとかわかんねえよ」とか言ってる
  • 番長

    • マネジメントに移るときは、部下の評価ができる権限をちゃんと貰ってください
    • 褒めたのに評価が上がらないとかのズレが…
  • 柿崎

    • 今まで、なんかあったんですね…

キャリアに対して悩める志士へ一言

  • くにお

    • 過去のスライドにキャリア3部作を作ったので、それを見てください
  • 番長

    • いちいち悩んじゃいけません
  • 柿崎

    • いろんな人に興味を持って会いに行きましょう

お題3「テストの生産性ってどう見てるの?」

登壇者紹介

モデレータ
  • 小山 竜治(以下、コヤマン
    • 半年前にfreeeへ
    • 今までは組み込み系とかをやってた
    • イケメン(中野さん)とタメ
    • JSTQBの公認講師
    • テスト自動化研究会でAutomaterのスキル基準のリーダー
パネリスト
  • 柿崎 憲(以下、柿崎)

    • QAテストの力が会社のインパクトに影響するを証明したい
    • サイバードの業績が出ているので、見ていただきたい
    • V字回復している
    • 社長が変わったのもあるかもしれないが、私の力です
  • 菅原 史晴(以下、菅原)

    • 34歳
    • QAテスト歴11年
    • 内製サービスのQAをやってる
  • 中野 直樹(以下、中野)

    • ししゃもが好きです
    • この瞬間まで乾杯を我慢してた。かんぱーい!

テーマを決めた経緯

  • ヤマン
    • 今回の参加者のうち、今年のJaSST'18 TokyoのWebJaSSTのセッションに参加した人は、全体の1/3ぐらい
    • 今回のテーマの質問があったが、投票が少なかった
    • JaSST'18 Tokyo終了後、中野さんも良い質問だと気づいた
      • 気づくのが遅いけど
    • DevOpsでスピードを求められる中で、テストがイケてるか考えると、旧来のだと重すぎる
    • それでもテストをしているというのは、テストに価値があると思っているからやっているはず
    • 何かしらの工夫をしているはず
    • 価値の証明ができないので、プロセスに入れましょう→重くなる、面倒になる
    • Web系ならではの工夫をもって証明しているはずだ
    • 僕が聞きたいんで、この質問を選んだ。

中野さんの場合

  • ヤマン

    • まずは中野さんに聞きたい
    • 何らかのメトリクスや説明資料を使っているのでは?
  • 中野

    • 「イケメン」をいじってるよね(笑)
    • 基本的に計測しているのは、
      • 本番での障害件数
      • 自動テストがきちんと要件を満たした状態で動き続けているか
      • リリース件数
    • Web系はテストを丸受けすることがない
    • テストのプロジェクトはものすごいインパクトがある
    • 技術的な指導だったりする
  • ヤマン

  • 中野

    • とっている
  • ヤマン

    • 金額とか、工数に換算している?
  • 中野

    • 一時やっていたが、今は止めてる
    • ビジネスアウトカムをQAのしごとにしちゃうと、儲かるプロダクトに関わっていれば良いことになってしまう
    • 納品していて、QAのおかげでお金になったとハッキリ分かればよいが、正直遠い
    • 腹落ち感が低いので止めた
    • 自分が携わっているプロダクトの場合、1年周期で波があり、障害件数も波があるので、昨年対比で見ている

柿崎さんの場合

  • 柿崎

    • お金を見てます
    • テストにどれぐらいの工数がかかってとか、プロダクトの比率とかも見てる
    • 単体でだけでなく、プロダクトとしてのコンディションを見るためにお金を見ている
    • サイバードはゲーム会社なので、お金がどれぐらい使われていてというのは今までは見てなかった
    • 欠陥の検出率も重要
      • 社内と本番の比率とか
    • Unitテストのカバレッジも見てたり
    • ありとあらゆるメトリクスを見てる
    • あとからどうやって考えるか大切
      • リリース後の故障発生率を経営陣に示したり
    • 定性的な話で言えば、品質の危機(メンテまつり)とかあって、ポシャったゲームもあった
    • 必ずしも信頼度成長曲線が正解ではないが、それらしいものを見せることができる
    • 今もそれは継続している
    • どっちかというと絶対値ではなく継続してみている
  • ヤマン

    • 柿崎さんらしく真面目な回答ありがとう
    • 売上が上がったって「ゲームが面白いからじゃん」と言われそう
  • 柿崎

    • 純粋に僕がガバナンスを効かせたら、リリース後直メンテに入る状況が止まった
    • 新規リリースの場合、こういう世界が来ますよ、というのが信頼度成長曲線を使って説明できた
    • OKとかNGとかを説明できた
  • ヤマン

    • バグの重要度とかリスクカバレッジとか考えて、リスクの高いものを優先的に取り除くようにしていた?
  • 柿崎

    • メンテ入りバグの変化をとってた
      • 新規リリースしたあと、メンテの事態になるまでの時間
    • メトリクスはシンプルなものを継続的に取るのが大事
    • パーンと数値が跳ね上がるのを気づくのが大事

菅原さんの場合

  • 菅原

    • メルカリだと、3つのプロダクトがある(アメリカ、イギリス、日本)
    • 私は日本のメルカリのオートメーションQAチームに居る
    • 日頃、E2Eの自動テストや、システムテストのインフラ部分を担当している
    • 特に生産性を測ることは具体的には今の所何もしてない
    • 何かを測る時、計測の仕方、入力をするという行為自体が生産性を落としている
    • マネージャのための仕事が一番イヤだなと思っている
    • 日本のメルカリのオートメーションQAではクラッシュ率とかはやってない
    • それをやっているんだったら、自動化とか、そういう勉強をしている
  • ヤマン

    • 捉え方によっては「自分がやっていることが正義」のように聞こえる
    • 対外的にどうやって自動化を説明している?
  • 菅原

    • 考えたことがない
  • 柿崎

    • あのさー
    • メルカリさんはスクラムして、お客さんに価値のある取り組みをやっているはず
    • テストの生産性をテストだけで考えるのはおかしい
    • テスト単体だけでなく、例えばお客さんに刺さる機能を作り上げるのならば、できるだけ多くのことを挑戦しているはず
    • ベロシティをやっていないの?
  • 菅原

    • 今のところではやっていない
    • プロジェクト開発の生産性というか、より無駄なことをしないような取り組みはしている
    • 一般な開発だとプロデューサーとかいろいろな人がかかるが、アサインするということが無駄だなと思っている
  • 柿崎

    • そうじゃなくて、お客さんにどれだけの価値を提供しているか考えるべき
    • アサインは直接的ではない
    • それでチームのアウトプットを考えないと

お題3まとめ

  • ヤマン
    • 続きは第二部や懇親会ということで…
    • まとめると「腹落ち」と「シンプルな指標にすること」は大事だなと思った

感想

  • 立ち上げるにしても転職するにしても、自分なりのQAとしての動き方を持つことは大事だなと感じた
    • それも1つに固執するのではなく、その状況を見ながら。
  • さらにそれを哲学としてではなく、他の人にも説明できることも大事だなと思った。

理想の開発現場 ~ほんとにあのチームあるんだよ!~ 第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

はじめに

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

目次

初めての社外発表聴講『大企業だけど新規ビジネス開発をモブプログラミングでやってみた』 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

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

f:id:nihonbuson:20180429002442p:plain

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

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

wandbox.org

得た気付きや感想

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

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

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

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

tddrinking.connpass.com

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

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

cyber-dojo.org

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

f:id:nihonbuson:20180429002553p:plain

  • ちなみに、お酒も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

f:id:nihonbuson:20180501183249p:plain

f:id:nihonbuson:20180501183301p:plain

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

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

f:id:nihonbuson:20180501183541p:plain

そう、探索的テストの図です。*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は時間軸をまたぐため、暗黙知の共有、その場での同期だけで十分なのか…と検討の余地がありそう