モブプログラミングを色々な場所で体験してきた #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自体で残り続ける問題というよりも、慣れで解消できるような問題だと思っています

アメリカでは政府がコードレビューを義務付けている #JaSST

JaSST 勉強会 技術

はじめに

先日、以下の記事を書きました。

nihonbuson.hatenadiary.jp

その中で、以下のようなリアクションが大きかったです。

JaSST'18 Tokyoクロージングパネル「アジャイル・自動化時代のテストの現場のリアル」 #JaSST - ブロッコリーのブログ

"政府の規制によってコードレビューが義務付けされた" コレ自分もそう聞こえたんだけどマジかとビックリした ソースどっかにないすかねぇ #jasst

2018/03/09 12:18
b.hatena.ne.jp

そこで、カンファレンスの翌々日に、まだ日本にいたJohn Micco氏に急遽会いにいき、質問をぶつけてみました。*1

自分「政府の規制によってコードレビューを義務付けているのは本当か？」

Micco「そうさ。"sarbanes-oxley"によるものだよ。」

sarbanes-oxleyとは何か

いわゆるSOX法のことです。

www.legalarchiver.org

上場企業会計改革および投資家保護法 - Wikipedia

日本でも、日本版SOX法が存在しています。

参考： https://home.kpmg.com/jp/ja/home/insights/2013/10/jsox2.html

しかし、日本版SOX法は経営層に対しての決まりはあっても、従業員に対しての決まりが無いようです。

コードレビューが義務付けられるようになった経緯

当時、コードレビューもしていなかった頃、こんな事件が起きました。

  • ある取引では、端数の金額を切り捨てる決まりがあった。
  • その切り捨てられた端数を自分の口座に入れるプログラマが現れた。
  • 1回の端数は見逃しやすいような少額だが、積み重なって多額のお金を得てしまった。

これを二度と起こさないために、レビューを設けて、2人以上が必ず変更に関わることを義務付けたようです。

義務化されたコードレビューの内容

  • 個人的な利益に繋がる可能性のある、お金に関わる問題を発端としているため、それ以外のプログラムは義務から外れているようです。
    • 例えば、車のプログラムに関しては、今のところ、この義務の対象外のようです。
  • コードレビューの細かい指針というものは存在せず、「2人以上が関わる」ということのみが義務化されています。
    • 組織的に行わない限りは、別の人がコードを見ることによって防げると考えられるためです。

詳細は…

今回の内容としては、SOX法の第9章「WHITE-COLLAR CRIME PENALTY ENHANCEMENTS」が該当すると思われます。

しかし、具体的に「複数人のレビューを義務付けている」というような記述が見当たりませんでした…。

これについて詳しく分かる方、補足をお願いします！

*1:主にこのために往復1時間かけて会いに行ったら、Micco本人から「クレイジーだ！」と言われました。

GoogleのJohn Micco氏によるFlakyなテストとその判別方法の解説 #JaSST

JaSST 勉強会 技術

はじめに

と書い（てしまっ）たので、JaSST'18 Tokyoに参加した私なりのFlakyの解釈を書きます。

JaSST'18 Tokyoについては以下のページを参照してください。

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

お知らせ

この記事の内容を4/11に発表しました！

nihonbuson.hatenadiary.jp

発表スライドはこちら

speakerdeck.com

目次

Micco氏のお話

  • John Micco氏（以下、Micco）の話は、以下の3回聞きました。
    • ICST基調講演(2017年)
    • JaSST'18 Tokyo基調講演(★今回)
    • JaSST'18 Tokyoチュートリアル(★今回)
  • それぞれのタイミングで、特にFlakyの話の理解度が変わっていったので、Flakyを中心にMiccoのお話をお伝えします。

いいだろー！*1と言いつつも、t_wadaさんのように後悔した人にも伝われば幸いです。

ICSTでの話

  • Miccoは昨年行われたICST2017でもGoogleの自動テストについて講演されています。
  • その時の説明は、以下の記事を参照してください。

nihonbuson.hatenadiary.jp

基調講演「Advances in Continuous Integration Testing at Google」

  • 上記のICSTから追加・変更した内容を中心に記載します。

講演資料

Advances in Continuous Integration Testing at Google – Google Research

テスト文化について (3ページ付近)

  • テスト文化を大切にしている
    • テストのテクニックはトイレに貼ってある
    • Google Testing blogで発信している
    • GTACでも発信している
  • テストが書けることを期待している
    • 新規採用の際はテストが書けないとダメ
    • Googleの新入社員に対してテストの仕方を教える
  • SETIエンジニアを各開発チームに配置している
  • モデルテストなどは実験をしている
  • 大体はエンジニアが書いた自動テストが回っている
  • 自動化テストを促進する文化がある
    • 10年の文化がある
  • コードビューがある
  • 450万のテストは開発者が行っている

回帰テスト (4ページ付近)

  • 1つのbranchで何十億ものコードがある
  • それを3万人の開発者がテストをする
  • どの回帰テストをするのかの選択が大切
    • これを選択する仕方が大事
  • 現在は2秒に1回テストが動いていく
  • 全ての変更リスト(CL)は2年間保管している。
  • これだけのデータがあれば、パターンが見えてくる
  • 明日のチュートリアルではラボを見ていく

Milestone Scheduling (8ページ付近)

  • 一定期間のマイルストーンで区切る
  • ここまでの変更の累積からテスト対象を決める
  • スケジューリングして実行する
  • NGになった場合、原因探し（犯人探し）を行う
  • NGだったものがNGになるものよりも、OKからNGになる（状態の遷移が起こる）テストの方が興味がある
    • 99.8%は状態の遷移が起きない
    • 0.2%のテストのみをスケジューリングしたい
      • コンピュータリソースを改善するため
    • ほとんどの問題はこの0.2%に集約される
  • 依存性ベースでやっているのは上手く行かない*2
    • すべてが依存しているものがあるから

RTS Affected Target Counts Frequency (13ページ付近)

  • 頻度のグラフを示した
  • コード変更の半分は、400万のテストケースの中の38のテストケースに影響する
    • すべてのテストを流し続ける必要はない
  • 何らかの方法でスケジューリングを減らさないといけない

Project Status and Groupings (16ページ付近)

  • リポジトリは1つだけだが、プロジェクト別にグループ分けをしている
  • GmailにもSearchにも一連のテストが紐付けられている
    • Searchで失敗していても、Gmailのリリースはできるようになっている
  • すべてのテストを見落としていない限り、Greenの結果にはならない
  • オーバースケジューリングを減らすには、Greenに近い確信レベルが必要
  • 実行していない自動テストは、決定的でない代わりに、確率論を用いる（スライド17ページ）
  • チームとしてはリスクを持ってリリースする

Safe Results (33ページ付近)

  • Skipしても、その前後でテスト結果が変化していないならばSkipして問題なかったと判断している
  • Unsafeな場合、どのコミットが原因なのか探さないといけない
  • 最終的にはマイルストーンを排除していきたい
  • 90%以上はテストをしなくても、きちんと動くものをコミットしている
  • 遷移が分かっているものはSkipする
  • Skipする割合とテスト結果の変化は直線的ではないことがわかった

Flaky (35ページ付近)

  • あてにならないテストのこと。
  • Flakinessは同じコードで成功と失敗の両方を観測されるテストのことをいいます。*3
  • 全体の16%はFlakyである
  • Flakyテストを再実行すると、リソースの2%〜16％を費やすことになる。

分析結果

  • 変更が多いファイルはFlakyが起きやすい
  • 開発者は1人よりも2人のほうが良い
  • 言語によってはFlakyが起こりやすい
  • C++ < Java < Go でFlakyが起きづらい
  • データセットにクエリをかけて、論文の結果を検証・再現するのは明日のチュートリアルで実施予定
  • リソースを待っていたり、WebDriverのテスト、スリープが入るテスト、マルチスレッドのテストはFlakyが起きやすい
  • テストの合否を記録して、時間によるテスト結果の遷移が多いのはFlakyなテストと言える
  • 816件のFlakyなテストがあった
  • 詳しくは明日のチュートリアルで！

質疑応答

その場でツイートしていたので、詳しくは以下のまとめを見てください。

togetter.com

その中から3つだけピックアップ

色々な質問の中で、手動で行っている話はこの3つだけであり、他は徹底的に自動化しているという印象を受けた。

基調講演の感想

  • ICSTの頃に比べ、どのようにすれば少ないリソースで効率的に不具合を見つけられるテストを行えるか考えられていた。

    • ICSTでは、依存関係から判断する話はあったが、テストをSkipする話をそこまで伝えていなかったので…。
    • 以下の文章ぐらい？
      • 例えば、テストが成功ばかりしている場合、そのテストは必要ないのかもしれない （ICSTの聴講レポートより）
        • ICST当時は、「不具合を見つけられないテスト」と解釈していたが、今となっては「本来Skipすべきだったテスト」という意味で必要ないと言っていたのかも。

  • Flakyなテストというのが「過去のテスト結果とも照らし合わせて判断するもの」という意味で使われている（とこの時点では感じた）のは、去年のICSTでの話と異なっている点だと感じました。

    • 「FailedになるとFlakyになるか確認する」という文章が、「テストをリトライした結果を見てFlakyか判断する」「（過去のテスト結果ではなく）リトライした今のテスト結果を見て判断する」という風に捉えていたので…。
    • ICSTとJaSST基調講演で定義が異なるという疑問は、この後に記載しているチュートリアルを受講したことで、払拭されていくわけですが…。

チュートリアル「How to identify test flakiness in your test result data」

  • チュートリアルの内容をどこまで載せてよいのか悩みましたが、Miccoと連絡を取り、ブログに載せても良いという許諾を頂きました。
    • Thank you, Micco!

概要

  • Googleでのデータを用いて、どのようにFlakyであるか判別するのかを体験しました。
  • 体験時に利用したSQLは以下のGithubページにあります。

github.com

  • ここにコミットされているSQLをGoogleのBigQueryを用いて実行しました。

  • チュートリアル中のツイートは以下にまとめました。

togetter.com

対象データ

  • Fullデータは以下の通り
    • 143万件のテストケース
    • 5億件のテスト結果
  • 「数が多いので、もっと数を絞ってシンプルなデータを用意した。」by Micco*4
    • 1万件のテストケース
    • 340万件のテスト結果

テスト結果の種類

  • 以下のようにテスト結果を分類している。
    • PASSED…テスト成功
    • FAILED_TO_BUILD…ビルド失敗
    • FAILED…テスト失敗
    • INTERNAL_ERROR…テスト開始の準備が整わなかった
      • 例えば、ブラウザが立ち上がらなかったなど
      • インフラチームが責任を持っている部分
    • PENDING…実行開始しようとしたけどできなかった
    • ABORTED_BY_TOOL…開始したけど制限の15分を超過したので強制終了した *5
    • FLAKY…テストが失敗し、そのテストをリトライしたら成功したもの
      • ここでのFLAKYは、この後に話しているFlakyと別の使い方をしているように思えるので注意！
  • テスト結果を細かく分けることで、以下の点をハッキリさせている。
    • 成功・失敗だけでなく、どんな失敗なのか
    • 失敗の原因はどのチームが責任を持つべきなのか

テスト結果のEdgeを元に、Flakyなテスト（候補）を特定する

  • テスト結果をさらに以下の4種類に分ける。*6
    • Keep Succeed…前回も今回も成功しているテスト
    • Keep Failed…前回も今回も失敗しているテスト
    • Positive Edge…前回は失敗し、今回は成功したテスト
    • Negative Edge…前回は成功し、今回は失敗したテスト

f:id:nihonbuson:20180310105503p:plain

  • 基調講演でも話したように、我々が興味を持っているのは遷移が発生している(Edgeの)部分である。
  • Edgeの中の84%はFlakinessである。
  • これらはすべてのテストの16%に集中している。
  • より多くの遷移に発生しているのはFlakyである。
    • これらはSQLを引っ張り出すことができる
      • 同じテストケースの前回結果と今回結果が変わったどうかでカウントをとる
    • 一番多いテストケースで、1ヶ月に884回も遷移が発生した。
  • 300万ケース中7590ケースで1ヶ月に4回以上の遷移が発生した。
    • これ以下のテストケースはFlakyではない、つまり純粋なテスト失敗の可能性が高い
  • PASS/FAILを記録するだけでもFlakyの判断をすることができる

テスト結果のパターンを元に、Flakyではないテストを特定する

  • Flakyなテストケースはランダム性がある。
  • Flakyではないテストケースはパターンが存在する。
  • 下記の図の場合、「t4とt6」や「t2,t3,t5,t7」は同じパターンで成功や失敗を遷移している。
    • このような組はFlakyではないと考えられる。

f:id:nihonbuson:20180310105623p:plain

  • 過去1ヶ月間のテスト結果のデータを解析すると、以下のことが分かった
    • 最大5000ケースが同じパターンだった
      • これらはFlakyではない
      • これらが同じタイミングで成功・失敗が遷移するとなると、ライブラリ起因の失敗などの可能性が高い
    • 同じパターンのテストケース数が2つ以下のものが、Flakyの疑いのケースだった。

おまけ：テスト失敗の分類をする

  • Flakyかどうかを判別することで、純粋な失敗のテストケースについて分類をすることができた。
  • どんな拡張子がテストの失敗を起こすのか
  • 誰がテストの失敗を起こしやすいのか
    • ただし、これは匿名化している。
      • これを人事情報を結びつけないようにするため。
      • これらは開発者にFBするのではなく、解析したものを機械学習に投入するために使っている
  • Flakyはテストコードとプロダクトコードのどちらを指すのか？
    • どちらに原因があるかを区別していない
    • よく聞かれる質問です。

チュートリアルの感想

  • Flakyを色々な使い方で言っていることが分かった。
    • 1つのテストケースを（コードの変更もせずに）リトライするとテスト結果が変わる場合
    • 前回のテスト結果と今回のテスト結果が違う場合
      • 特に、他のテストケースとテスト成功・失敗のパターンが異なる場合
  • Flakyの判別は特殊な操作をしているのではなく、単純なクエリで推定できることが分かった
    • ただし、Googleは推定するためのデータ数がとてつもなく多いのでできる部分もあるけど
      • 自動テストをどんどん増やす方向になっていくと良いメリットの1つともいえる

おわりに

という、Micco尽くしのJaSST'18 Tokyoでしたが、おかげでFlakyとその判別方法について少しだけ近づけた気がします。

  • 去年のICSTでは、「1つのテスト結果の中で、リトライするとテストが成功したり失敗したりするもの」がFlakyだと思っていました。
  • 今回のJaSSTの基調講演では、「前回のテストと今回のテストの結果が違うもの」がFlakyだと思いました。
    • あれ？Micco、定義が変わってない？と思いました。

  • 今回のJaSSTのチュートリアルで、「1つのテスト結果でも複数回のテスト結果でも結果が変わるもの」をFlakyだと理解できました！

  • 大満足なJaSSTとなりました！

関連記事

  • Miccoも参加したパネルディスカッションについても記事にしました。こちらもどうぞ。

nihonbuson.hatenadiary.jp

*1:t_wadaさんに対してこんな風に言える数少ない機会

*2:ここは私の理解が曖昧です。依存性ベースというのがどういうことを指しているのか…

*3:ここでの「同じコード」というのは、おそらく「同じテストコード（プロダクトコードに変更はあった）」ともとれるし「両方とも同じ」ともとれる。ここが（私個人の）混乱の原因と分かったのは、チュートリアルを受講した後だが…。

*4:いや、これでも十分多いっす…

*5: @yuki_shiro_823 さんと @kz_suzuki さんにご指摘いただきました。ありがとうございました！

*6:実際に説明で述べているのはPositive EdgeとNegative Edgeだけで、それ以外の2つは区別するために勝手に命名しました。