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

ロッシェル・カップさんによる「サーバントリーダーシップ」参加レポート #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なテストについて発表しました!

きっかけ

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

話す内容

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

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

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

発表する勉強会の情報

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

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

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

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

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

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

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

発表しました!

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

speakerdeck.com

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

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

JaSST'18 Tokyo チュートリアル「計画立案とふりかえりでリスクを捉えよう!~SaPIDTOC:未来予想型チーム運営WS(テスト編)~」 #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人ではなく、チームとしてのワークをしたときには、どのようにチームとして協同し、進めていくか課題が見えた気がします。