理想の開発現場 ~ほんとにあのチームあるんだよ!~ 第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でやり取りして、実践してみた。
  • その時は「調べるのをやめて聞こう」と言うようにしている。
質問「これを使っているが、まだこれでうまくいくのがよく分からない。」
  • 聞き手の問題かもしれない。
  • もしくは、溜めないで大きくならないうちに上手く言うと良いのかもしれない。
  • 絶えず聞かれる、絶えず答えるから自然とそういう風になる。

感想

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