ロッシェル・カップさんによる「サーバントリーダーシップ」参加レポート #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人ではなく、チームとしてのワークをしたときには、どのようにチームとして協同し、進めていくか課題が見えた気がします。

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

はじめに

  • 先日、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

はじめに

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

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'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

テスト文化について (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

  • ここにコミットされているSQLGoogleの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つは区別するために勝手に命名しました。

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

はじめに

  • この記事はJaSST'18 Tokyo(ソフトウェアテストシンポジウム)のパネルセッションを書いたものです。

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

自己紹介

  • バックグラウンドが違い、コンテキストが違うことがある
  • そこで自己紹介時に、どれくらいの頻度でDeployしているのか、どれくらいの頻度でリリースしているのかを踏まえて話してほしい。

荻野 恒太郎(以下、荻野)

  • 楽天
  • テスト自動化とDevOpsのマネージャをしている。
  • デプロイは毎日数十回実施
  • 1週間に数回リリースしている

天野 祐介(以下、天野)

  • サイボウズ
  • kintoneの開発チームに所属
    • エンジニアが10数名、QAなどを含めると30名ぐらいのチーム
  • 2015年にチームリーダーになった
  • 今はスクラムマスター中心
  • 最近、WaterFallからAgile開発に変更していっている
  • 今は1イテレーション2週間で行っている
  • Deployの回数は1日数回から十数回実施
  • 2週間に1回リリースしている

山口 鉄平(以下、山口)

  • ヤフー
  • 全社横断の支援部門のマネージャ兼プレイヤー
    • 実際にプロダクトを持っているわけではない
  • 特定のサービスの話ではないが、多いところだと一日数十回のDeploy、2週間や1ヶ月に1回のDeployをしているところもある
  • テストの自動化はどんどん薦めている
  • Deployやリリースの自動化もどんどん進めている
  • セキュリティのテスト(というかライセンス周り)の自動化を進めている。

松尾 和昭(以下、松尾)

  • クックパッド
  • 海外事業部に所属
    • 半年前に異動
    • 開発拠点はUK
    • リモートで東京で働いている
    • 日本人は60名中10名ほど
  • モバイルの自動化やワークフロー構築をしている
  • OSSのコミッタとして活動している
  • 書籍のレビューもしている
  • 色々なサービスを分割して、それぞれで活動している
    • 1サービス6,7名ほど
  • GithubでMergeをAcceptすると、Deployを開発者が伝えればすぐにDeployできる
    • Deploy回数は30回/日ほど
  • モバイルアプリはAppStoreの審査が必要なので、1週間〜1ヶ月に1回は定期的にリリースしている

John Micco(以下、Micco)

  • Google
  • 26名のエンジニアが所属しているインフラでマネージャしている
  • 中核製品Gmail, SearchなどのCIを担当
  • 33000エンジニアをサポートしている
  • Deployやリリースなどは行っていない
  • 15年間はCIに特化している
    • この15年間、同じテストの課題に直面し続けている
  • リリースの頻度は2万/日
    • そのすべてが本番にPushされるわけでない
      • 本番にPushされるのは全体の5%
  • チームによって違う
    • 1日に1リリースしたり、1ヶ月に1回リリースしたり
    • 各チームによってリリース頻度は違う。中央管理はしてない

Micco氏が紹介したGoogleのやり方について

荻野

  • 自己紹介を聞いて、随分GAPを感じた人も多いのでは
  • どういう風な現場になっているかについてディスカッションをします
  • これから自動化を考えてる人も多いと思うので、その人達の参考になれば。
  • 例えば、基調講演の話で、200万件のすべてのテストケースが終わらないとリリースできないと思っていたのでは?
  • 会場にアンケート
    • もしも100%の自動化が終わっている場合、デグレッションテストの研究を使ってみたい(もしくは買ってみたい)人はどれくらいいるか?
  • 登壇者の皆さんは、このGoogleのツールもしくはやり方を利用したいか?

天野

  • サイボウズではSeleniumを使ったテストをしている。Pushをしてmasterに入ると、Seleniumで1700件のテストを20分程度で実行する。
  • Flakyと思われる原因で落ちることがある
    • Flakyかどうか勘で調査している
  • Flaky効果的に探し出せるならば使ってみたい

山口

  • 現在はそこまでのボリューム感がない
  • 優先順位はチームごとによって違う
  • 紹介されていた方法論を使えれば良いが、開発者、チームの感覚を確認した上で使う
  • 「良いから使う」とはならない

松尾

  • 簡単にはすべてを実行できないというときに、必要なぶんだけ実行するためには入れたい
  • Googleの方法を使うことで、自分のコミットがどれだけ影響があるのか見え、責任を持たせる効果も出るのではと思う。

荻野

  • Miccoさんに質問。
  • 実際にはバグを見逃している可能性があるのでは?
  • 全てのテストを実行しないというのはどういう思想をもとに行っているのか?

Micco

  • 確かに全てのテストを実行しないでリリースするのはリスクがある
  • ただ、思想としては否応なしにこのような取り組みになった
    • コンピュータリソースが大きくなり、莫大なコストがかかってしまった

荻野

  • 機械学習で行うといっているが、人間がテスト選択の妥当性を確認しているのか?
  • 将来はAIが完全に担うと思うか

Micco

  • 人間が介在するのはほぼ不可能
    • 1億5千万のテストケースを1日に実行するので
  • 機械学習による見逃しの欠陥を見ながら、それも機械学習に入れたいと思っている

荻野

  • AIのテストをどのようにしているかについては、後でまた聞きたいと思う。

テストの「価値の定義と計測」

  • 自動テストでは、バグを見つけるという価値以外に、コストや時間の短縮に価値を見出していると思う。
  • テストを行った時の価値について聞きたい
    • 例えば、開発・QAの生産性など
  • また、実際にどのように計測しているか

松尾

  • 自動テストはリグレッションの防止の為というのは組織で共通認識になっている
  • 製品を壊さないようにするために自動テストがある
  • CIでどれだけGreenになっているかは計測している
  • カバレッジを計測しているかはチームによる
  • マニュアルテスト(ユーザビリティテスト)はデザイナーを含めてチームでやっている
  • 我々はサービス会社なので、市場に出してよいのか見ている
  • 計測結果は逐次共有している
  • リリース前にそれによって継続して開発していくかの判断はあまりしていない
  • テストについては、カバレッジがあるからこのチームは良いとかいう話はしていない

荻野

松尾

  • Webの場合、テストでAll Greenになるのは時間がかかっても20分におさえている部署がある
    • はやいときだと10分いかなかったり

荻野

  • もっと早いという方?会場に…いませんね
  • これを実現するためにテスト自動化が貢献しているのではないか
  • 続いて、サイボウズさんの場合はどうか?

天野

  • QA部門があり、開発組織と別れてはいる
  • 欠陥検出率は計測している
  • 遷移を確認して、効率的に検出できたか確認していた
  • 自動化しきれない部分をマニュアルで行っている
  • 価値の計測はうまく行ってはいない

荻野

  • Googleではどのようにテストの価値やQAの価値を行っているか

Micco

  • Googleでは完全に自動化されているので、開発者にはコミット前でも後でもすぐにFBできている
  • テストが成功に終わっているのは1つの証でもある
  • ただ、コミットからリリースまで20分というクックパッドさんの例は世界で最速なのでは

テストプロセスとアジャイルについて

荻野

  • 楽天では、DevOpsの研修をしていて、迅速にFBをしていく図を伝えている
  • ドキュメントの管理だったり、リスクベースドテストなどの方法もある
  • サイボウズさんの例(ウォーターフォールからアジャイルの変化)が面白いと思ったが、簡単に説明してほしい

天野

  • 以前は3ヶ月のウォーターフォールだったが、2週間スプリント×6スプリントに変えた
  • スプリントを導入した最初の頃は、6スプリント目をKAIZENスプリントとした
  • 現在では、3週目のスプリントでの残存不具合がほぼ0になったので、KAIZENの工数も一定になった
  • 6スプリントでリリースしていたが、スプリント2回分で1回のリリースになった
  • 1年ぐらいかけて少しずつプロセスを変えていった
    • 初期はバーンダウンチャートがバーンアップしてしまったり…
    • それでも風土のおかげもあって、スクラムを止めようとはならなかった
  • スクラムを導入しようとしたのは私の提案がきっかけ
  • 結果として、不具合報告数が70%減となった

荻野

  • 1年でサイボウズさんのような成果を上げられるのは珍しいのでは?

山口

  • 成果との因果関係が分からないので、一概にアジャイルのおかげとは言えない
  • アジャイル導入前後の結果を見ると、すごいと思うと同時に、導入前はどうなの?と思った
  • ただ、上がったことは良いのでは?
  • スクラム以外のおかげもあったりすると思う
  • ただ、ここまでになったのは、より上手く作りたいと思った結果なのではないか。

荻野

  • GTAC2014でYOUTUBEのテスト自動化に衝撃を受けた

Micco

  • タイミングが一致していた。
    • 全社的に自動化に舵を切った2006年にYOUTUBEを買収した
  • Google全体で文化が根付いた一番の要素は、コードレビュー時にテストコードもコミットするようにしたこと
    • こういう変更というのは、インクリメンタルに一段階ずつ行っていった。
      • この領域はまずすべて自動化する、から会社全体に広がっていくとなっていった

荻野

  • 2006年からテスト自動化の取り組みを開始したと行っていたが、いつごろに100%になったのか

Micco

  • 私が2011年に入社した時には、手動テストはほとんど残っていなかったと思う
    • 全てのプロジェクトに関わっているわけではないので何ともいえないが

荻野

Micco

  • 色んな出来事が重なった結果
    • 政府の規制によってコードレビューが義務付けされた
      • この発言について、後日、Micco本人に確認して、別記事にしました。

nihonbuson.hatenadiary.jp

  • 開発者の振る舞いも変えたかった
  • 現在はコードレビューを存分に活用している
    • アナライズをしたり
    • 自動的にフィードバックしたりレビュアーでフィードバックしたり…
  • 私にとって日本に来て喜びだったのは、テスト自動化は良いものだと思っているが、日本では経営者への説得が大変だと分かったということ
    • アメリカの大手の企業は自動化はされているうえでどう改善するかの話になっているから
    • 自動化を経営幹部に薦めるためのスライドは用意していなかった
  • 自動化をすることで得られるメリットは、バグを見つける時間が短くなることなどがある
    • これだけでは日本のCEOを説得するには材料が足りない
  • 文化が変わるだけの大きな変化になるはず
    • 例えば、QAチームから各開発チームに派遣したら良いのでは?
      • 私の組織ではQAが独立部門にあるわけではない
      • SETIが各開発チームにいる
      • QAと開発者はより密に関わる必要がなる
  • 上層部に自動化を売り込むためには、価値を語れる必要がある。
  • エンジニアの生産性向上を伝えられると良いが、なかなか難しい
  • 具体的に、これだけの金額を節約できる、生産性がこれぐらい上がるという話は難しい
  • コード1行あたり…といったような公式に落とし込むことはできない
  • 今回のカンファレンスでも、そういった主張ができるように研究を薦めて、具体的な数値を示せるようにしていきたい

荻野

  • このような価値を数字で示せるようにしたい
  • ちなみに私は4年前のJaSSTで発表したのでその例を示す。
    • 継続的にテストを行っていると、自動化前後のバグの修正完了日数が短くなったという成果が出た
  • Googleではテストの組織をなくしたほうが良いと言っていたが、ヤフーさんの例を聞きたい。
    • テスト組織をなくしたと聞いているが。

山口

  • QAという職責を持っている人は現在いない
  • リリース速度を早めるために、ゲーティングとしてのQAの価値がないと判断したから
  • リリース権限とともに、チームにテストの責務を持たせるように変えた。
  • テストをする人をなくしたわけではない。
    • 行為としてのテストは残っている
  • チームの中でどうにかするようにしている

荻野

  • QAチームを無くすことに対して混乱は起きたか?

山口

  • 混乱は特に起きていない
  • 開発者が自分が作ったものをテストしないということは無いと思う。
  • なのでやることは変わっていない
  • 重箱の隅をつつくのはやらなくなったと思うが、ビジネスとしてダメージが大きい時に、次の時に何とかする
  • リリース速度を早めたメリットの方が大きかった。

Flakyテスト、保守性など、自動テストの品質特性の課題をソフトウェアエンジニアリングで解決している事例について

荻野

  • テスト自動化するしないで変わることについて
  • テストエンジニアが自動化しているのではなく、エンジニアが自動化をしていると思う。
  • また、自動化でよく出てくるのはメンテナンスの話
  • ソフトウェアエンジニアリングとして解決すべき課題は多いはず
  • 不安定なテストどのように解決していくか

松尾

  • Androidアプリを対象としたテストでは、統一性が無かった
    • 外部での通信もしたり
    • 描画でのテストだったり
    • モックやスタブを利用して、できるだけ最小のテストをしたり
  • Flakyなのは色々な依存関係を持っているところに発生していた
  • 色々な取り組みをしてきた。
    • どのくらいの時間をかけて実行するのかなどをまずは決めた
    • 実際のコードを書き換えて提供した
    • テストサイズやテストのピラミッドを使った説明をした
      • 狭い責任範囲にして高速で回すとか、時間をかけるテストはダメ、とか
  • WEBの場合、色々なサービスが入っていた
    • MSAの風潮に従って、単体の責務に分割するようになっていた
    • 本来の責務だと20分かかるテストは無くて、10分や5分でできるように崩していった
  • あとは、サービス間をどのように保証するかを取り組んでいっている
    • 依存性のあるものを別のテストに置き換えたり
    • 例えば、Facebookログインなら、スタブとかモックとかに置き換えていく
      • ただ、それは内部で依存を持っていないと、外部のログインの仕様が変わったとき、壊れてしまうので注意が必要

山口

  • SETIにあたるような部門が色々頑張ってくれている
    • テストに限った話ではないが、開発環境やDeployなどのツールを開発している
    • CI、CDやその並列化を進めている
  • モバイルアプリについては、Flakyなものがあるのは事実なので、E2E用の環境に順次投入していって、開発部隊とは切り離すようにしている

Micco

  • これはチュートリアルでも紹介したが、責任を明確に分担する必要がある
  • 失敗したテストがFlakyであるという情報も伝えるべき
    • 例えば、テストはサブミットされる前からFlakyである話なので、開発者の責任ではない、とか
  • テストそのものが失敗であったこととインフラが失敗したことを別問題と扱って情報提供するようにしている
  • 重要なのは、適切な人に適切な責任を持たせる
    • そのためにインフラ側にも働きかける

荻野

  • 今の話は痛かった
  • 現在、インフラの問題でFlakyになっていることが多いので…

Micco

  • メジャーな方法は、インフラそのものの不具合をシステムが認識出るようにする。
  • インフラ側の問題だったらリトライを行う
  • 例えばSeleniumで上手くいかなかった場合、Failにするが、インフラ側の問題の場合、Failにはしない

荻野

  • テストの方でもExeptionをしっかり入れることは重要だということですね。

最後に一言

Micco

  • 私はテストの自動化を強く支持しているが、エヴァンジェリストとして困っていることがあれば、是非お手伝いさせてください。
  • 一緒に皆さんのCEOに説得させたいと思う
  • 皆さんにお会いして、皆さんの会社について知れたことを感謝しています

松尾

  • テストの自動化は色々やりたいと思っていると思うが、Deploy回数を増やすのはまずは必要
  • リグレッションという一つの中でも自動化は必要
  • 1人に責任過多にさせると厳しくなる
    • 責務を分割して、テストとか意識しなくても確認できる世界になれば良いと思う
  • 色々話をして楽しかったです。

山口

  • 2人共コメントがかっこいい。ずるい。
  • ヤフーの状態が良いと思っているかもしれないが、それは違うと思う。
    • 何をすると良くなるんだっけ?と考えた結果
      • ゲーティングをなくしたり
      • パイプラインを変えたり
  • 届けるにあたって何をすれば良いのか考えるのがネクストアクション
    • その結果の1つがテストの自動化
  • 弊社の場合はこのようになったが、これがベストではない
  • 何かやらないと変わっていかない
  • 少しでも楽しんで頂けてれば幸いです。

天野

  • 自分はアジャイルを初めてスクラムを投入したが、それは早くユーザーに価値を届けたいと思った結果
  • エンジニアの立場で投入したが、テストをどうにかしたいと考えていた
  • こういう試みが大事だと改めて思った

荻野

  • 私個人はすごい楽しめた
  • ヤフーのように前から自動化していく話とか、サイボウズさんの最近の取り組みとか
  • Googleの取り組みとして、100%の自動化からさらにSKIPしたりとか
  • クックパッドさんがリードタイムが世界一というのも良かったと思う

感想

  • 奇抜なことをやっているのではなく、正攻法を実直に行っていると感じた
  • 「これをやればOK」ではなく、問題は何か、次に何を行えば解決できるのかを常に考えていくことが大切だと感じた

  • 山口さんの以下の想い、すごく伝わりました!

関連記事

  • この記事の中にも随所に出てくる、John Miccoの基調講演やFlakyの話については、別記事にまとめました。そちらもどうぞ。

nihonbuson.hatenadiary.jp