二日目です。保存したものが消えてしまったので思い出しつつ…。
イベントページ
スクフェス新潟 https://www.scrumfestniigata.org/
ブース
ナレッジワークさんのブースが印象に残りました。 写真を撮られている方がいたので、参考のために貼っておきます。
https://x.com/voicy_nonchan/status/2052947372867752247
新人QAエンジニアが発行した不具合のチケットなのですが、2バージョンありこれに対して先輩としてコメントするということをしました。 チケットの書き方などについて突っ込まれているような気がしましたが、個人的にはそれがユーザーでも起こっているかどうかが気にしてしまいます。 またシステムの不具合ではなく、OSやブラウザの不具合の場合はアップデートを待つしかないケースもあります。 私はユーザーへの影響を特に気にしており、周知などする立場なので、チケットの書き方よりも優先度の付き方そのものやチケットを取り巻く危機感、人の巻き込み方などが気になったので、その点をいくつかコメントしています。
また東京ガスさんや三菱電機さんなど、日本のインフラを支えるような大きな企業もブースを出していることに驚きました。 アジャイル・スクラムやスクラムフェス新潟特有の品質を考える文化などが広がっていくことで、様々で多様な参加者がいることを肌で感じました。
セッション
自動テストだけでリリース判断できるチームへ - 鍵はテストの量ではなくリリース判断基準の再設計にあった
- 概要: https://confengine.com/conferences/scrum-fest-niigata-2026/proposal/49867
スライド: https://speakerdeck.com/ewa/redesigning-release-criteria-for-lightweight-releases
回帰テストで時間がかかっていて、リリース回数が増やせない
- 月1回程度、緊急のものは早めに出す形でリリース
- スマートフォンアプリなので審査に時間がかかるという事情もありそう
- 回帰テストの手動実行が重く、毎回大変
- この見直しをしたかった
- 月1回程度、緊急のものは早めに出す形でリリース
- 自動テストをエンジニアの方で実装進める
- ただしQAにも納得してもらうように説明する
- 責任分離がうまくコミュニケーションされていると感じた
- 自動テストが軌道に乗り始め、手動でのテストは大幅減少
- ただしスマートフォン特有のカメラ・通知周りのテストは自動テストが困難なので人手で見る必要がある
- 既知のテストは自動テストで、新規のテストは手動テストで、という分担
- テスト範囲の合意
- すべてを検証する必要はなく、ビジネス上クリティカルである部分（ビジネス上合意する項目）については担保したい
- その結果、自動テストでの保証内容は合意する項目を包含する
- リスクベース判断を取り入れる
- リリース回数が約2倍、かつリリース判断を変更したことによる不具合は出なかった
- 不具合対応と機能リリースが同様の基準で判断できるようになったというメリットもある
- 自動テストの課題
- スマートフォン特有の問題としてOS側の仕様変更を受けやすいということがある
- マイナー・パッチバージョンの変更でも注意
- ライブラリをモックしているとテストで検出できない課題もある
- ユニットテストでの動作検証と、結合テストでの動作検証の内容を意識する
- 結合テストではライブラリを実際に組み込んでの挙動を確認するなど
- スマートフォン特有の問題としてOS側の仕様変更を受けやすいということがある
ここだけは不具合を起こしてはいけないという範囲を定めながら、エンジニアとQAが一体になりチームでの開発を進行していくイメージの持てるトークでした。 同じチームで働き続けられている・QAの方がドメイン知識豊富など、今回の改善に属人性のある部分もあるように感じましたが、自動テストをどう取り扱うべきなのかの合意を目線合わせてできているのは素晴らしいことだなと思いました。
またスマートフォンアプリ特有の問題はこれまでWebの開発ばかりに携わっている私にとっては新鮮でした（キャリアの最初の方にちょっとだけスマホアプリの経験がある程度で10年くらい前の知識しかない）。 自動化できるところ、そうでないところが存在するのはやや苦しい部分ではありますが、スマートフォンアプリ開発に携わるときは手動テストがどうしても発生するものであるという意識をしてみようと思います。
アクセシビリティは誰のもの？ 開発を丸投げしないPOの受け入れテスト実践論
- 概要: https://confengine.com/conferences/scrum-fest-niigata-2026/proposal/49117/po
Webアクセシビリティの話
- 弱視の人に対しての補助機能
- ダークパターンで混乱させないとか
- プロダクトによって目指すラインは異なる
- プロダクト規模や提供先による
- もともとの出発点は過去の資料で試験設計を行ったのかわからないので、開発が進められないというところにあった
- 過去のものを流用することが難しく、参考にしながら改めて再設計した
- 流用、ではなく参考にするという表現いいなと思いました
- アクセシビリティについて意識的に検討されていないことが顕在化
- 過去のものを流用することが難しく、参考にしながら改めて再設計した
- 画面サイズ変更、音声読み上げ（スクリーンリーダー）、キーボード操作
- キーボード操作で問題を見つける
- キーボード操作ができない（アクセシビリティが担保されていない）と誰が困るのかを考える
- 利用ユーザーが多ければ多いほどいろいろな立場のユーザーがいる
- マウス操作が困難なケースや、視力の問題などで画面そのものが認識できないケースもある
- これからの問い合わせの対応への意識、自社・プロダクトのブランディングにも影響する
- アクセシビリティのテストは手間がかかる
- ツールなどの検出でも10〜15%程度で人手がかかる作業
- それでも誰かがやらないといけない状況だった
- アクセシビリティに対して理解を高めておく
- 勉強会の実施などでチーム全体に浸透させる
アクセシビリティについてはスクリーンリーダーの対応などについていくつか聞いたことがあったものの、そのテストについては地道な対応が必要なことを知らなかったので学びがありました。
プロダクトが大きくなってくるといろいろなユーザーが増えて来るので、アクセシビリティに対しての意識が必要になります。 機能的に大きなインパクトになりづらいので理解を得づらいという部分もあったのかもしれないと思いながら聞いていたのですが、想定するユーザーへの想像力をよく働かせ、会社のブランディングにもつながるということは大きい影響があるものと言えそうなので、同じ目線で物事を考えられる人を増やすことが大事なのかなと思いました。
未経験を言い訳にしないーコミュニティに救われた事務局の業務改善
- 概要: https://confengine.com/conferences/scrum-fest-niigata-2026/proposal/49815
スライド: まだ公開されていなさそう
- 事前公開されていたNote: https://note.com/dattenesodane/n/n4336aac1af71
なんもわからん枠で本当になんもわからん状態で行ってみる
- エンジニアがよく知っているアジャイルとかいうアレを知っておこう
- こういう好奇心が様々な職業で発揮されると更に面白いことになりそうと思いながら、若干ワクワクが会った気がする
- アジャイルコミュニティが本当に暖かい
- 相互に理解しようという意識・姿勢の強さ
- 具体的・数値的(FACT)で話ができていないという気付き
- 気づけているのがすごいなぁと思いました
- 向き合い方の変化
- 助けてという強さ
- 付箋などをきれいに記録しているマメさ
- このときに何を考えていたのかというふりかえりが強くできてそうですごい
アジャイルコミュニティの暖かさを感じました。本当に困っている人に対して真摯といいますか…。 また困っていたことを自己分析して自分の言葉で表現する能力が高いなぁと思って、すごいと思いました。
困っているときはもう少し助けて〜というようにします。自分も頑張ろう。
コーチングで皆の内なる 「品質への関心」を 探しに行こう
- 概要: https://confengine.com/conferences/scrum-fest-niigata-2026/proposal/49064
スライド: https://www.docswell.com/s/55_ymzn/K4NY2Q-ScrumFestNiigata2026
コーチングはパートナーシップである
- 単にそれっぽい質問や傾聴をすることではない
- 上司から部下へのマウントっぽいインプットでもない
- 「答えを相手の中に探しに行く」
- やりたいから始める、モチベーションの源泉を理解する
- 自己のバイアスがかかっていることを自覚した上で切り離す
- 無理なときもあるが、バイアスを切り離した上で引き出し、行動につなげる
- 技術としての認める、聞く、質問、フィードバック
- 聞くは言葉の理解から始まる、アクティブリスニングも程々に
- 認めるは自分の中での判断・評価・解釈を最初に入れないということ（バイアスの話につながってそう）
- オウム返しでも良い
- 現実を受け止めること
- 質問は相手のための関与であり相手のための問である。マウントがにじみ出ないように注意
- どうあって欲しいかに気づいてもらう、意外と様々な可能性に自分で気づくことができる
- 自分の答えを手放すこと、答えは相手の中にあるという意識
- フィードバックは事実や感じたことを返す
- 自己との切り離しでその時必要なことを話す
- 解釈を加える場合は「私は」の主語で
コーチングはパートナーシップである、は心に刻んでおきたい言葉ですね。 エンジニア？ 文脈だと 1on1 の中でコーチングの話が出てくるのですが、エンジニア文脈の 1on1 はどうしても上下関係が発生していがちで、パートナーシップではないケースがあり、意識的にパートナーシップとなるような関係性になっていないと過去のことを振り返るとそう思います。
この分野は訓練が必要であり、経験量も大事なので意識しつつも実践しながら身につけていきたいなと思います。 （必要ならコーチングをコーチから習う、も考えたいですね）。
QAエンジニアはどうやってプロダクト議論の場に入れるのか？
- 概要: https://confengine.com/conferences/scrum-fest-niigata-2026/proposal/49814/qa
スライド: https://speakerdeck.com/moritamasami/qaenziniahadouyatute-purodakutoyi-lun-nochang-niru-rerunoka
PRD(Product Requirements Document): 製品要求定義書
- 本当はキックオフから参加したいけど、QAはなかなか呼んでもらえなかった
- QAはあとから参加するという文化醸成や判断が存在している可能性あり
- 皆さんの環境でもどうなのかを考えてみましょう
- キックオフに呼んでもらえると参加者にとって嬉しい人になれているかどうか
- プロセスの中で考慮が漏れていたものをありがたいと思ってもらえる仕組み
- 受け入れ条件をまとめて、手が回らかった部分を対応していて助かる
- 参加して価値を発揮できるという事実や信頼の積み上げが前工程に呼ばれるコツ
- テストの人からリスクを減らす人として認識される
- プロダクト会議に呼ばれてどういう体験にするか、から一緒に並走して考える
- PdM に近い仕事はこれまでとはちがう考え方や知識を使う必要あり
信頼をためていくことの大切さと共に、ただテストをする人ではなくリスクを減らす人という認識の変容が起こっているのは興味深いなと思いました。 ありがたいと思ってもらえる人になる、というのはこの例に限らず必要とされるキーパーソンになっていくために必要だと感じました。
地域課題を活性化に向けてアントレプレナーシップマインドでアジャイルに取り組んでいく
- 概要: https://confengine.com/conferences/scrum-fest-niigata-2026/proposal/49906
スライド: まだ公開されていなさそう
内容が多岐にわたっており、理解が追いつかず…
- 海外を転々としたり、新潟に引っ越してきたなどの経緯があった
- 新潟に引っ越すという判断は結構重大そう？だった
- イノベーションループを回す
- 地方自治体との協力
- 新潟での取り組みやつなげていく活動がたくさんあった
- 見本になるように行動しよう
熱いメッセージが多かったのですが、何しろ情報量が多く…。 私は新潟に初めて来たのですが、ITもホットで良い場所だと思いましたし、多くの取り込みを実感できました。
次回、新潟に来るときにはそのあたりも意識してみてみたいですね。
まとめ
スクフェス新潟は素敵なイベントで、また行きたいですね。 特にこれからAIによる開発がより一層進む中で、エンジニアとしてビジネスマンとして何ができるか？を再考するフェーズに来ていると思います。 その中の一つの可能性が品質に対してのコミットメントを発揮することであることは、今回のイベントの中で感じられました。
3年ぶりのスクフェスでしたが、多くの学びがあって参加して本当に良かったです。 今日の学びを活かして行くぞ！
