5/19 ~ 20でスクラムフェス新潟参加してきました。
初めてのスクラムフェス、初めての新潟で緊張していましたが、学びが多く実りのあるイベントでした！コミュニティの皆様も温かく迎えてくださり、緊張していたのが嘘のようです。
本記事では、参加した中でも、特に印象に残ったセッションと、参加してみての感想を共有します。
スクラムフェス新潟とは
アジャイルコミュニティの祭典です。
アジャイルやテストのエキスパートと繋がりを持ちましょう。この祭典は初心者からエキスパートまで様々な参加者が集い、学び、楽しむことができます。
参加者同士でアジャイルやテストのプラクティスについての知識やパッションをシェアするだけでなく、ここで出会ったエキスパートに困りごとを相談することもできます。
特に以下のようなテーマに興味を持ちます。Test Engineering、Test Automation、Modern Test Management、Agile Transformation、Mental Health、Agile Leadership、ML&AI
とある通り、スクラムフェス新潟は、特にアジャイル開発やテストがメインテーマのアジャイルコミュニティの祭典です。
参加の背景
僕がスクラムフェスに参加した背景は以下のとおりです。
- Software Engineer in Test（以下、SET）として働いているが、業務で開発プロセスの改善を行うこととなった
- 関わるチームはアジャイル開発を実践している
- アジャイル×テストにおける体系的な知識だけでなく、現場での実体験を元とした知見を得ることで、自社により効果的な還元ができるのではないかと考えていた
印象に残ったセッション
Daniel Maslyn - Reaching the “Big Picture” In Testing and Quality / テストと品質における「全体像（ビッグピクチャー）」への到達
■感想
ダニエル・マスリンは、情熱的でクリエイティブなソフトウェアテストの専門家であり、実践的な運用テストの役割からテスト管理職に至るまで、20年以上の経験を持っています。様々なテスト手法、テクニック、テストパラダイムに精通しています。CATSアジャイルテスターの認定を受けており、その他のテスト技法や手法の認定、さまざまなマネジメント認定を受けていますが、型にはまらず、常識を覆すような挑戦をし続けています。
という方の、キーノート。
テストと品質における全体像と詳細のバランスが大事、だから全体像（=ビッグピクチャー）を描こう、というお話でした。
詳細だけ見ていると例えば、
- 修正して、検証して、パスすれば終了
だけになってしまいますが、全体像を見ると、
- そもそもこれは修正する必要のあるものか
と判断できるようになります（講演ではダブルループ学習の図とともに紹介されてました）。
テストコードにおいてもこのビッグピクチャーは大事になり、なぜテストコードを書くのか、という前提に立ち返ることが重要です。
- テストコードを書く（行動） → カバレッジが上がる（結果）
を繰り返すだけだと、意味のないテストコードや後でプロダクションコードがリファクタリングしづらいテストコードを書いてしまうことになってしまいがちです。
- テストコードを書く（行動） → カバレッジが上がる（結果） → そもそもなぜテストコードを書いているのかチェックする（前提/メンタルモデル）
という流れにすることで、このテストコードは不要だから消せるよね？みたいな議論にも繋げることができます（前提として、テストコードも負債のため、プロダクションコード同様にメンテナンスが必要）。
その他にも、ビッグピクチャーを描く大切さ、をたくさんの例と共に、視聴者に語りかけてくれました。Learning Outcomeの
テストと品質における「全体像（ビッグピクチャー）に到達する」ことの利点と意味を、状況に合わせて十分に理解することができる。
が満たされた素晴らしい講演だと個人的に思っています。
また、本講演は英語で行われましたが、会場に集まった参加者も英語で質問・やり取りしていたので、英語を聞く・話すことができるようになりたい！と思い、スクラムフェスに初参加した身としては、刺激になりました。Zoomで同時通訳されていたため、僕は会場にいながらもZoomで話を聞いていたため、英語ができなくても有意義な時間になりました。
JUnitで学ぶTest smells撃退法
https://confengine.com/conferences/scrum-fest-niigata-2023/proposal/18389/junittest-smells
■感想
テストコードの不吉な匂いを解消する話です。
SETとして負債にならないテストコードを書いていくために、学んでおく価値はあると考え、聴きました。
普段JUnitは使っていないですが、Test Smellsの概要から、何がTest Smellsなのか、そしてそれはどうしていけないのか、がまとまった素晴らしい講演でした。
一般に、Test Smellsは
「単体テストコードにおける悪い実装方法（テストケースの構成、実装、相互作用の仕方など）と定義され、テストソースコードに潜在する設計上の問題」
ref: https://testsmells.org/
のことを指します。
Test Smellsの数が多いコードは、コードの変更容易性が低く欠陥率が高いです。
厄介なことは、開発者自身がTest Smellsに問題があると回答しますが、なぜTest Smellsでそれの何が問題なのか、理由を言うことが難しいのです。本講演はその橋渡しをしてくれました。
Test Smellsが埋め込まれる背景はいくつかあり
- 自動生成ツール
- 会社で作ったとしてもプロダクションコードの変更に追従できなかったり
- 個人の思い込み
- 自分（テストコード書いた人）はわかるから良い、など
- アーキテクチャ上の都合
- 循環参照など
- etc…
など、さまざまです。
本講演で上げていたTest Smellsの一つとして、for 文を使ったテストコードを挙げていました。for文では途中で失敗するケースが存在すると、それ以降のケースが実行されません。ということは、失敗したケース以降は成功するのか失敗するのかわからず、失敗したケースを直したとしても今度は別のケースが失敗して直す、といういわゆる「いたちごっこ」になりかねません。これはfor文ではなくparameterized testを行うことで改善できます。
何がTest Smellsで、それがなぜTest Smellsなのか、そしてそれをどう解決するのか、をまとめて発表してくださったため、とても満足度の高い講演でした。
Test Smellsについて、詳細に知ることができるサイトを見つけたので、他に知りたい方はこちらを参照してみてください。
また、発表者のaki.mさんのブログには、発表するにあたって利用した記事が載っているので、Test Smellsをもっと知りたい、という方は、参照してみると良さそうです。
いきいきした受託開発をするためにアジャイルチームができること
https://confengine.com/conferences/scrum-fest-niigata-2023/proposal/18352
■感想
受託開発はつらそう、というイメージが僕にはあったのですが、「いきいきした受託開発」というワードに惹かれ、視聴しました。
本講演は、自社開発も受託開発も関係なく、いかに自分ごととして開発するのか、という開発する上で根本に持っておいた方が良い考え方、を事例とともに紹介してくれました。
なぜ受託開発を行うエンジニアはイキイキしないのか、を考えたとき
- Project単位なため、チームが長続きしにくい
- 私契約する人、あなたつくる人、という意識で開発してしまいがち
- 私考える人、あなたつくる人、という意識で開発してしまいがち
という3つを本講演では挙げています。
契約まではプロジェクトマネージャーのみで行なってしまうと、その時点ですでに、エンジニアにとっては不都合な制約が生まれてしまいます。
また、プロダクトオーナーが全て考えてくれる！という意識でも、うまくいかないことが多いです。前提として、プロダクトオーナーも答えを知らない中、探り探り進めていっています。ただし、仕事は進めなければいけないので、わからないけどとりあえず決めることも少なくありません。その状況で、「私考える人、あなたつくる人」では手戻りも当然出てきてしまい、結果的にエンジニア自身の開発工数は減っていきます。
さらに、上に挙げた3つは、連動します。これはスライドを見た方がわかりやすいため、以下にリンクを載せておきます。
https://speakerdeck.com/takaking22/what-agile-teams-can-do-for-lively-contract-development?slide=59
そんな問題を、どう解決してきたのか、を本講演では話してくださりました。
自社開発も受託開発も、似たような構造で、基本的にどちらにも適用できることばかりでした。
全ての開発者必見です。
PO,SMに送るテスト自動化の8原則に5箇条を添えて
https://confengine.com/conferences/scrum-fest-niigata-2023/proposal/18376/posm85
■感想
前提として、テスト自動化の8原則、はエンジニアが理解しやすい言葉でまとめられています。
一方、テスト自動化に関して、プロダクトオーナーやスクラムマスターも知っておくことは、良いチームを作る上で、必須です。
本講演では、プロダクトオーナーやスクラムマスターにも伝わりやすい言葉で、テスト自動化の8原則を再定義をしつつ、原則に添える5箇条の紹介をしてくださりました。
5箇条の中でも 「価値の下がったテストは捨てたり、頻度を下げることも検討しよう」 はパインさんの声のトーンが一つ上がったように感じたので、強調したい部分のように感じました。実際、SET目線では、これはかなり重要な視点です。
また、この講演中にブロッコリーさん（@nihonbuson）がシェアしてくださった以下のスライドも、そうそう！ととても共感したので、もしよろしければ見てみてください。
相互理解を目指す対話主体のコミュニケーションで心の負担を軽減し持続可能な組織変革を
https://confengine.com/conferences/scrum-fest-niigata-2023/proposal/18270
■感想
外からチームを支援していると、必ず対話が発生します。
そして、意見は異なるので、一定ファイティングポーズをとってしまうこともないとは言い切れません。
心の負担で押しつぶされないために、そして品質を良くする、という目指しているゴールに向かうために、コミュニケーションを学ぶことは大事だと感じたので、視聴しました。
何より印象に残ったのは、とても感情を込めて、話していた点です。スピーカーのえわさんは、アジャイル開発を推進していく中でスクラムを導入していく中で、過去悪かった振る舞いや思考回路と実践してよかったこと、を話してくださりました。
本当にチームを良くしたい
という思いを実現していく過程は、1つ壁を越えたらまた壁が現れて、の連続です。意見の違うステークホルダーと対話を繰り返す必要があります。そのため、自然と組織の改革は長期戦になります。また、精神を病んでしまうことも、0ではありません。それでも少しずつ少しずつ、改善を行なっていくえわさんの活動は、発表を通してとても素晴らしいなと感じました。
また、その活動の中で、コミュニティ（スクラムフェス）を活用していたと聞き、今業務で開発プロセスを行なっていく身としては、改めてコミュニティに参加する意義を感じました。
Whole-Team Approach (WhTA) for babies
■感想
「チーム全員で品質の責任を取る」
などと言われると難しそうな感じがしますが、
本セッションをなんとなく聴くだけで
そのイメージを感覚的につかめます
「チーム全員で品質の責任を取る」ってマインドを周囲に伝える言語が欲しいと思い、このセッションを聴きました。
Whole-Team Approachでは、開発チームのすべてのメンバーがプロジェクト全体に責任を持ち、共同で成功に向けて取り組むことが重視されます（ここでいう開発チームは、プロダクトオーナー、スクラムマスター、開発者、QAなどで形成されている前提です）。
そのWhole-Team Approachという概念を、誰にでも伝わりやすく、絵本にして、発表していました。
絵本では、4つのアンチパターンを紹介しています。
- 烏合の衆
- 各々のスキルが習熟していない時にできるチームのパターン
- 個人商店
- 開発とQA、1人の影響力が強く、チームが協力できていない状態のパターン
- 孤島
- 協力しあっていたチームが時間が経つにつれ、協力し合わなくなってしまうパターン
- パーフェクト超人
- 1人が開発もQAもこなしてしまう、その人がいなくなったらチームが崩壊するパターン
その絵本を通して、
- 協力と相互のサポート
- 継続的な改善
が重要だと感じました。
- QAだけが品質のことを考える
- 開発者だけが開発のことを考える
- プロダクトオーナーだけが要件定義のことを考える
- スクラムマスターだけがスクラムチームの改善のことを考える
といったように、個々のメンバーや専門性に依存するのではなく、チーム全体の力を最大限に活かすため、互いの得意領域を生かしながら協力して、品質を良くしたり、開発したり、要件定義したり、スクラムチームの改善をしたり、することが Whole-Team Approachの目指す姿なのかなと思いました。
この絵本はとても傑作なので、ぜひ見てほしいです。
参加してみての感想
面白いセッションが多数あっただけでなく、その場で出会った方々と会話でき、知見を得たり、オフラインの良さを実感できました。
実際、すぐに活かせる知恵も得ることができました。
一つ挙げるとすると、僕自身がテストコードを書く文化の醸成をしていく中で、良いテストコードを伝えるのに苦労しています。Test Smellsのなぜ悪いのか、を言語化できたのは、今後の文化醸成を続けていく中で、大きな武器を得た感覚です。
また、テーマがアジャイル・テストと定められていたので、境遇の近い方々が多かった印象があります。仲間を見つけられて良かったですし、明日からまた頑張ろう、という気持ちにもなりました。
（そして、新潟の日本酒はとても美味しかったです）
運営してくださった方々、発表者の皆様、ありがとうございました！