Scrum Fest Niigata 2024 現地参加してきました-発表チャレンジ編-

こんにちは、かとあず(@kato_az)です。弥生でQAエンジニアをしています。
5月10~11日に開催された、Scrum Fest Niigata 2024 に現地新潟で参加しました。

快晴の新潟の空とWhat’s NiiGATA モニュメント

前回、参加したセッションでの学びを書きました。 tech-blog.yayoi-kk.co.jp 今回は、発表にチャレンジについてです。

プロポーザル書いてみた!

書いてみないことには始まらない

私がスクラムフェスの存在を知ったのは、1年前2023年のScrum Fest Osaka 2023です。
弥生でスクラムマスターをやっている たろけん がプロポーザルを書くと発言したのが、一番はじめです。
この話をきいたとき、実は「スクラムフェス」も「プロポーザル」も何かわからないまま「がんばって」と言っていました。
その後、プロポーザルが「三河トラック」で採択されて発表をするということで、応援を兼ねて参加をしてみることにしました。

Scrum Fest Osaka 2023 たろけん 発表資料
speakerdeck.com
Scrum Fest Osaka 2023 たろけん 発表Youtubeアーカイブ
スクラムを通じてアジャイル開発の良さに気づいたPMのはなし ~だが、情熱はある~ - YouTube

Scrum Fest Osaka 2023では同時並行でたくさんの発表がありました。
地名のトラック名が何を意味しているのかすら解っていない状態で参加していましたが、みんな楽しそうだし、私もこの仲間になっていきたいなと感じました。

Scrum Fest Osaka 2023から半年ほどが過ぎ、私は2023年の年末にJaSST'23Tokai 2ndでLTをしました。
LT前に告知ブログ書きました。⇒ JaSST'23 2nd TokaiでLT登壇します - 弥生開発者ブログ
LTを聞いていただいた方からスクラムフェスでも話してみたらどうかというお話しをいただき、自分でもチャレンジできるかもしれないと、2024年2月に開催されたWomen in Agileにプロポーザルを出してみました。
これが私のはじめてのプロポーザル作成でした。

Women in Agileの次の週に2024年にQAに関するイベントに現地参加しました。
イベントの場でScrum Fest Niigata 2024はQAに関する内容が多いイベントだからQAエンジニアにプロポーザルを書いてほしいと思っているというお話しを伺いました。
そこで、Scrum Fest Niigata 2024に向けてプロポーザルを書いてみることにしました。

スクラムフェスを知ってから1年の間に、私は2回プロポーザルを出しました。

書いても始まらなかった

はじめてプロポーザルを書いたのは、2024年2月に開催されたWomen in Agile。
「書き始めたらきっとどうにかなるだろう」と思ってプロポーザル投稿画面を開いたのですが、「どの項目に何を書くの?というかどうすればいいの?」という状態になってしまいました。完全なる事前調査不足。
過去のプロポーザルをいくつか見ましたが、「決まり」のようなものはないように見えてしまいます。
話せる内容についての経験がこれから増えることはないので、テーマはある程度決まっています。ひとまず、項目を埋めてみましょう。
なんだか物足りないような、いいたいことが言えていないような気がしますが、下書きで熟成させても発酵してよい味を出すようにも思えないので、そのまま確定をしました。

2回目は、2024年5月に開催されたScrum Fest Niigata 2024に向けての作成です。
初回の経験でプロポーザルが自力で書けないことはなんとなく気づいています。
それでも書いてみないことには指摘をもらうこともできません。さっそく「QAエンジニアがスクラムマスターを兼任したこと」をテーマに書き始めてみました。
やっぱり「どの項目に何を書くの?」から抜け出せません。

レビューしていただいた

Women in Agileのプロポーザルは「書きっぱなし」のまま投稿して終わってしまいましたが、もう一歩どうにかしたい気持ちになってきました。
何の前触れもなく たろけん に「プロポーザル書いてみた」とリンクを送ってみたところ「こんな話を入れたらよさそう」というアドバイスをもらったり、Women in Agileを通して知り合った人と一緒に構成を練り直したりしました。
自分ひとりでは、項目を埋めることだけで終わってしまいましたが、レビューをしてもらうことで少しずつ書き方に対する理解が進んできました。
「無名の人が何も書いていないとどんな発表になるのかわからないから採択のしようがない。出し惜しみせず全部書く。」というのは非常に納得感のあるアドバイスでした。
「ネタバレになったり、当日プロポーザルをなぞっただけの発表だと面白みがないのでは?」と思ったりしましたが、それはプロポーザルをしっかり書けるようになってからの段階です。
あせらず一つずつステップを登っていくことにします。

結果的に、Women in Agileに続きScrum Fest Niigata 2024でもプロポーザルは採択に至りませんでした。
「例えば、常夏の国でダウンコートは売れない。どんなに質のよいプロポーザルだったとしても、採択されるかどうかはその時次第。だから採択に至らなくても落ち込む必要はない。」と言ってもらいましたが、常夏の国でも極寒の国でも、"ボロ雑巾"は売れ残ります。
私のプロポーザルは、今回のテーマに合わなかったのではなく、他の人に伝えるべき経験ができていなかったり、伝えたいことがうまく書けなかったりしています。

採択された発表について、プロポーザルの内容と発表や発表資料を見比べてみました。
どれも聞く前に内容の方向性がわかりますが、事前の情報をなぞっただけの発表というわけでもありません。プロポーザルで詳しく聞いてみたいと思うことが発表で具体化されていて、聞いてよかったと感じる発表でした。

チャンスが巡ってきた!

ありがたい、初心者枠

Scrum Fest Niigata 2024でもプロポーザルは採択に至らなかったので、現地参加者として思いっきり楽しもうと思っていたところ、「Scrum Fest Niigata 2024のWomen in Agileセッションでお話ししませんか?」と声をかけていただきました。
発表は10分。
20分や45分の1セッションは発表経験がないのでどうやって話を組み立てたらよいか難しく感じていましたが、10分であればチャレンジが出来そうです。
私はスクラムチームのQAでの経験で仕事の取組みが変わってきたことを話すことにしました。
tech-blog.yayoi-kk.co.jp 張り切ってプロポーザル風にまとめてレビューをしていただきました。
「10分の発表にしてはボリュームが多い」「言いたいことが散らばっていてつながりがない」といったレビュー指摘をうけ、大幅に修正をしながら準備を進めました。
悪いところだけではなく、「こういうことが言いたい?とするとこの辺を膨らませるとよさそう」と言ったアドバイスも大変役に立ちました。
私はLTをする中で「発表資料を作るときに最初からパワーポイント等の資料作成ツールを開かない。まずは準備をする。」というのを経験から学んでいます。
今回、発表の準備をするにあたり「プロポーザルを書くからと言って最初からプロポーザル投稿画面を開くのではない。まずは準備をする。」ということを学びました。

いざ発表

弥生が主催するもくテクでは、現地で発表経験がありますが、これはいわばホーム。
知っているメンバーが多く参加されていて、温かい雰囲気を作ってくれている場での発表です。
質疑で詰まっても他のメンバーがフォローしてくれることもたくさんあります。
今回、Scrum Fest Niigata 2024の発表は、知らない場所で初めてお会いする人が多い場所での発表です。
Scrum Festは初参加の人にもやさしくて、決してアウェイな雰囲気というわけではないですが、「この人は何者なんだろう?」と思われているような気になります。
準備した内容を超えることはできませんが、準備した分はしっかりできたと思います。
Scrum Fest Niigata 2024 発表資料
speakerdeck.com
Scrum Fest Niigata 2024 発表Youtubeアーカイブ
Women in Agile 「New Voices」 : 新たな声、新たな視点 - スピーカー未経験の女性たちが語るアジャイル - YouTube

現地で発表して気づいたのは、まったく緊張しなかったということです。
活舌がよくないとか、笑顔がないとか、ふりかえることはありますが、それは緊張のせいではなく、普段からのことです。毎日のふるまいが発表にも出るのだなと気づいたので普段の生活から気をつけていかなければいけないなと思っています。

今後

初心者枠は何度も使えるチャンスではないですし、いろんな人に初登壇を経験してほしいと思っています。
私は、これから納得できるプロポーザルを書けるように、そしていつか採択していただけるように、日々の業務を通していろんなチャレンジをしていきます。


弥生では、一緒に働く仲間を募集しています。 herp.careers

Quesに参加しました!―チームでのイベント参加がもたらす相互理解―

はじめに

こんにちは、エンジニアのウエタケです。 先日開催されたQAエンジニア向けイベント『Ques』に参加しました。

ques.connpass.com

イベントの後日、チームのQAエンジニアと話してみたら想像以上に収穫があったので
その学びを共有したいと思います!

参加のきっかけ

同じチームのQAエンジニアから"弥生のオフィスでこんなイベントやるよ"と教えてもらったのが参加のきっかけでした。

自身は開発エンジニアなので、QA専門イベントだと内容ついていけるかな?とも思いましたが、今回自社のオフィスが会場とのことで "オフライン開催の雰囲気を見てみよう"という軽い気持ちで参加することにしました。

後日話すことになった経緯

イベントの中でQAエンジニアの役割や現状について話がありました。
イベントの内容を聞いて"こういうことかな?"という一定の理解はしたものの、私自身はQAエンジニアの経験がなく、もう少し具体的に理解を深めたいと思いました。

同じチームのQAエンジニアもイベントに参加していたので、"具体的にイメージできなかったことがあるので話したい"とお願いしたところ、快く受けてくれました。

チームのQAエンジニアと話したこと

作業範囲が広く大変?

イベントの中で、

「QAの役割=テスト」ではない。要件検討や開発チームの作業、CS部門の作業にも入り込んでいくことで、品質を管理する方法もある。

といった話がありました。

自身のチームのQAエンジニアはテスト以外の役割も担っており、作業範囲が広いため結構負荷が高くて大変なのでは?という点が気になりました。

QAエンジニアの回答:

  • 作業範囲が広いことで大変なのは事実。ただ、メリットも大きい
  • 要件検討の最初から参加しているほうが要件や仕様の理解が進むので、テスト設計もしやすい。早い段階から品質を作り込める
  • テストの段階で要件の検討不足が見つかり、テスト設計もやり直して..となると、結果として作業負荷が上がってしまう

品質を管理するためには大事だと思いつつ、"作業負荷が高く大変そう"と思っていたため、
QAエンジニアとしての業務自体もやりやすくなる、という点は意外でした。

プロダクトだけではなく人も見るってどういうこと?

QAエンジニアは、プロダクトだけではなく人も見ることが大事。

という話がありました。 "出来上がったプロダクトだけでなくプロセスも見る"という理解はしたものの、具体的にはどういうポイントを見ているのか気になりました。

QAエンジニアの回答:

  • チームの状況をみることで、例えば「ここは急いで作っていたな」とか「途中で要件が変わったな」という"品質の穴"になりそうな箇所が分かりやすくなる
  • 日々の会話などから、どこを注意してテストしたらよいか、といった観点が拾えることもある
  • 開発チームと作業場所が同じかどうか、というのも意外と大事

日々の作業や会話の中からテスト設計に活きる情報がある、という点が新たな発見でした。QAエンジニアが開発チームと別の作業場所になるケースもありますが、それだけでも情報を拾いづらいとのことでした。

自身は開発エンジニアなので、基本的には開発チームのメンバと別の作業場所になることはありません。そのため、役割の違いがあることでそういった苦労がある、という点は想像できていませんでした。

スクラム開発とウォーターフォール開発の違いってある?

私の所属チームはスクラム開発を行っています。QAエンジニアの業務に関して、スクラム開発とウォーターフォール開発の違いが気になりました。
"短い期間でテスト設計、テスト実施を回さなくてはいけない"という点が一番の違いではないかと考えていたのですが、聞いてみるとそれだけではないとのことでした。

QAエンジニアの回答:

  • スプリント単位で機能が出来上がってくるので、傾向分析する材料が少ない
  • ウォーターフォール開発の場合は出来上がる機能の単位が大きいため欠陥の偏在を分析しやすいが、スプリント開発では出来上がる機能が小さいため品質分析のやり方が変わる

ここは自分の発想になかった観点だったので、なるほどと思いました。
だからプロダクトだけでなく人やプロセスを見るのがより大事なんだ、という点がつながり、とても腹落ちしました。

イベント参加&話してわかったこと

自身以外の役割を理解することの大事さ

イベントで話を聞いた時点では、"QAエンジニアの役割はテストにとどまらない"点は理解したものの、
とはいえ、実際は"テスト以外にも入り込んでもらうのは大変そうだし、色々巻き込むのはどうなのかな?"と考えていました。

ただ、後日チームのQAエンジニアと話をしたことで、"同じ情報を共有することでQAエンジニア側にもメリットがある"ことを知りました。
このように、チームの周りのメンバがQAエンジニアに対する理解がないと、私が感じたような遠慮だったり、QAエンジニアの業務範囲ではないと勝手に判断し、必要な情報を一方的に遮断してしまう可能性があると思いました。

チーム内でお互いの役割に対する理解がないことでこういったデメリットも起こりうると知り、互いの役割と業務を理解することの大切さを感じました。

チームでイベント参加オススメ

今回チームのQAエンジニアと話をしたことで、イベントで聞いた内容をより掘り下げることができました。

複数人で同じイベントに参加することでお互いの解釈を確認できますし、今回のように自分以外の役割のイベントに参加して「双方の役割としてどう思った?」という意見交換してみるとチームメンバの相互理解にも繋がると感じました。

いきなり「お互いの役割を理解しよう!」と言っても題材無しに話すのは難しいので、同じイベントにチームで参加して会話してみることで、チームの相互理解を深めてみてはいかがでしょうか!


弥生では、一緒に働く仲間を募集しています。 herp.careers

開発エンジニアが予備知識0でQAイベントに参加してみた

こんにちは。「弥生会計」開発チームでエンジニアをやらせてもらっているOです。弥生に新卒で入社して4年目になります。

先日、弥生で開催されたQAエンジニア向けオフラインイベント『Ques』に予備知識0で参加しました。

ques.connpass.com

この記事は「ソフトウェア開発エンジニア目線でこんな共通点や学びがあった」という内容のQues参加レポートです。 QAエンジニアの方もそうでない方もお気軽にお読みいただければ幸いです。

Quesのここが面白かった

今回のイベントは参加者から事前募集したQA関連のおたよりに対して、2名の登壇者がディスカッションしていく形で進んでいきました。 お話を聞く中で(これわかるな~)とか(自分も気を付けたいな~)など思ったことをピックアップしていきます。

1.『QAとテストは何が違う?』

QAとは求められる品質を保証することである。 品質が十分かを見るのにわかりやすいのが「テスト」であり、QAの中にテストが含まれる。 その他品質の管理に関連すること、お客さまからの評価をフィードバックして開発そのものの質を上げること、組織をよくすることなどもQAの仕事である。

「品質保証」という言葉はよく耳にしていたが、テスト関連の業務を除いてどんな仕事が該当するかは全然知らなかった。 開発の質の向上や組織の改善など含むならかなり幅広い。私も製品の品質向上を目指してチーム内であれこれ試してみているが、そういったことも品質保証、QAのひとつであるとは知らなかった。

tech-blog.yayoi-kk.co.jp

弥生の開発本部では、組織を改善するために自由に活動できる時間がエンジニアひとりひとりに割り当てられている。 「QAエンジニアだけが品質のことを考える。他のメンバーは従う」でなく、QAエンジニアを含めた全員が品質に意識を向け、様々な活動に取り組めているのは良いスタイルなんじゃないかなと思った。

2.『QAとしてのスキルをどうやって身につければいい?』

QAエンジニア自体が少ないためそもそも身近に先輩や上司がいない人が多いそう。そんな中でどのようにスキルを身につけたらよいか?というテーマ。

自分が教わる立場なら、上司の行動や発言をただ受けとめるだけでなく、常に「自分だったらどうする?」とシミュレーションする。

新人だったころに教わったことを思い出した。上司がなぜそのように指示するかを考えながら仕事への取り組むことで取り組み方や成長速度が変わってくるそう。

アジャイルでも求められるQAのスキルセットは変わらない。 アジャイルでもウォーターフォールでも、品質を上げるのがQAの仕事である。ただアジャイル開発ではスピード感を大事にするので、フットワーク軽く作業し、こまめにアウトプットすべき

「どうしたらアジャイル開発を上手に進められるか」という話は最近よく聞く。QA界でもアジャイルに対する関心は高い様子で面白かった。

私のチームではウォーターフォールで開発しているが、方向性の確認や進捗報告という意味で成果物をこまめに共有することは同様に大事だと思っている。

3.『不具合を有効活用するには?』

QAの業務のひとつに不具合分析がある。そこで分析した結果をどう活用したらよいだろうか?というテーマ。

そのバグを直す必要があるか?優先度はどのくらい?その認識は周りとすり合わせられている?

こちらは「見つけたバグが優先度低しと判断されてアーカイブされてしまうことがあるがどうしたらよいか」に対するコメント。

私の立場でも自分のやりたいことが独りよがりな「こだわり」になってしまっていないかは常に気を付ける必要があると思った。周りとの認識すり合わせ大事。

要望は根拠とともに伝える。提案の際にはいろんな人を巻き込む。却下されてもチャンスが巡ってきたら再度提案する。

要望を採用してもらうためには伝え方や提案者の信用(?)が大事というお話。一度採用されなかったとしてもあきらめないことが重要、という点が強調されていた。

本当に必要なことならまたチャンスが巡ってくる。そこで採用してもらうために改めて声を上げる。その積み重ねが信用となり、「この人の言うことはちゃんと聞かなきゃ」と思ってもらえるようになる。

これは自身の意見を伝えるうえで大切なことなので、すべての社会人が心得ておいたほうが良い。

4.『QAとして気を付けるべきこと』

謙虚たれ。一緒に仕事をしやすい関係性を築くことが良いものを作ることに繋がる。

バグを「指摘する」立場はどうしても上から目線っぽくなりがちだけどそれではいけないよ、とのこと。

最近私も他のメンバーの成果物のレビューを担当するようになり、指摘の難しさに気づいた。伝え方、言葉の柔らかさも注意すべきだが、一番気を付けたいのは指摘するという立場に溺れないことである。決して「自分が正しい」と思いこむことなく、相手がなぜそのようにしたか考えながら対等な気持ちでこれからも取り組んでいきたい。

参加の感想

今回のQuesはコロナ禍真っ最中に入社した私にとって初のオフラインイベントでした。 これまでイベント会場に足を運ぶ勇気が出ませんでしたが、このたび自社で開催するというお知らせが舞い込んできたので「QAのことは良く知らないけど困っても誰かにこっそり聞けそう!」という他力本願な気持ちで参加を決めました。

結果、畑違いかと思っていたジャンルのお話もたいへん勉強になりましたし、他社のさまざまな立場の方と交流することもできてとても新鮮でした。お声掛けくださった方、イベントを運営してくださったみなさまに感謝します。ありがとうございました!

ブログの宣伝

弥生の新卒エンジニアはこんな感じで働いているよ~という記事を書きました。良かったら読んでみてください。 note.yayoi-kk.co.jp


弥生では、一緒に働く仲間を募集しています。 herp.careers

元QAエンジニアが、PMの立場でQAエンジニアのイベントに参加してみた

こんにちは、弥生のシダです。 私は弥生でsubPM*1として活動しています。 また、私は2023年9月まではQAエンジニアとして働いていました。

先日、弥生で開催されたQuesというイベントに参加しました。 そこで新たな気づきを得ましたので、この場にてお伝えしたいと思います。

Quesについては以下の記事を参照ください。 (なお、現地で初めて知ったのですが、こちらは”キューズ”と読むのが正解のようです。直前まで"クエス"と口語していたため、開始2秒で恥ずかしくなりました。)

tech-blog.yayoi-kk.co.jp

YOUは何しにQuesへ?

前述の記事にもあるとおり、弥生内でQuesが開催されることとなりました。 開催が決まったときには私はQA業務から距離を置いていたため、参加の予定は無かったのですが、当日の会場設営や写真撮影などの手伝いを行うこととなり、その流れで話を聞くこととしました。

QAエンジニアとPMの作業内容には少なからず親和性があることは知っていたため、今のPM業務をより良くするヒントがあるのでは、と思ったことも一因です。

予想以上に賑わっていてワクワク

今回ピックアップする話

今回第22回のQuesではいくつかのセクションがあり、いずれも興味を惹かれる内容でした。 特に、私は前職で第三者検証会社に所属していたため、「事業会社のQAに求められるものと、第三者検証会社から安定的に供給できるQAエンジニアのGAPを埋めるにはどうすればいいか」という話題については、とてつもない"わかりみ"を感じました。

その話をしだすといくらでも語れる気がしますが、今回の目的はそこではありません。(というよりも、ただの昔話になってしまう)
そこで今回は「チームで求められるQAの役割」という話題にフォーカスして話したいと思います。

「チームで求められるQAの役割」の内容

※一部、私の意訳も含まれます

テストについて

QAの業務には、勿論テストは含まれる。 ただ、目の前の物だけ見てもいいテストは出来ない。具体的にいうと、完成した設計書やシステムを見るだけでは、表面的なテストにしかならない。それを解消し、QAとしての価値を高めるためには2つ案がある

開発プロセスを観察する

開発の様子を観察することは、効果的なテストをするうえで非常に大切である。観察を通じて以下のような問題点が明らかになる。

  • 仕様決定に四苦八苦した点
  • レビューで何度も差し戻しがあった点
  • コミュニケーションが不十分なまま進んだ点

これらの問題点を見つけ出すことで、QAはプロセスの改善に切り込むことができる。また、これらの観察結果をテスト観点に取り入れることで、より良い品質を実現することが可能となる。

利用者側の目線を持つ

QA本人が仕様やプロセスに明るくない場合、あるいは開発内部に親しみが無い場合は、ユーザー側の立場なるという点が効果的である。多くの開発メンバーは、実際に利用される背景を十分に理解していないことが多いため、ユーザー目線での意見は開発メンバーにとっても貴重なものとなる。このユーザー目線のフィードバックを開発側に還元することで、品質の向上が期待できる。ユーザーの視点を取り入れることで、より使いやすく、実際のニーズに合った製品やサービスを提供できるようになる。


いずれも、とても共感できる内容でした。私自身、QAエンジニアとして出来ていたことも出来ていなかったこともあると思います。
ただ、これだけだと単なるレポートになってしまうので、もう一歩踏み込んで考えたいと思います。

PMとして何ができるか

QAエンジニアの理想の動き方は分かりました。
では、PMとしてはこの内容を踏まえ、どういったことが出来るでしょうか?

1. QAエンジニアが開発プロセスを観察できる環境の構築

開発プロセス全体を透明化し、QAエンジニアが開発の進捗や変更点を常に把握できるような環境構築が必要だと考えます。 日次のMTGで生の声を聴いてもらうことも必要ですし、タスク管理ツールなどを最新化してQAエンジニアが開発の進捗状況をリアルタイムで確認できるようにする、というのも効果的だと考えます。

2. 要求元とのMTGへのQAエンジニアの参加

要求定義や仕様策定の初期段階からQAエンジニアにも参加してもらうことで、品質要件を早期に把握し、後のプロセスでの問題を未然に防ぐことが期待できると考えます。 また、QAエンジニアが要求を正確に理解するための質問や確認ができる場としても活用できます。 QAエンジニアが要求元とのMTGに参加することで、ビジネスニーズや実際の利用背景を深く理解し、それに基づいたテストケースの設計や品質保証が可能になると考えます。

3. 開発エンジニアとQAエンジニアの対等な関係構築

上記1、2のような施策も、QAエンジニアの声が開発エンジニアに届かないと意味がありません。そのため、開発エンジニアとQAエンジニアのパワーバランスを適切に保つのが大事だと考えます。(前職でのQAエンジニアとしての経験論ですが、開発エンジニアと距離を感じることが度々ありました。)
それぞれの役割と責任を明確にし、お互いに尊重する環境を作り出すことで積極的な意見交換に繋がり、結果的に品質の向上が期待できると考えます。


貴重な学びをありがとう

まとめ

改めて考えると、QAエンジニアが最大限に力を発揮できるよう、PMとしても出来ることはあると思います。 現在の私のチームには上記のような課題は無いものの、今後チームや環境が変わることはあるはずなので、後学のために覚えておきたいと思います。

今回の参加を通して、QAエンジニアとしての視点も持ち続けるべきだなと改めて感じました。 また、機会があれば次は開発エンジニア向けのイベントにも参加してみたいとも感じました。私自身もまだまだ成長が必要だなと思える、大変良い機会でした。
開催のために動いてくれた皆様に、この場を借りてお礼申し上げます。


弥生では、一緒に働いてくれる仲間を募集しています。 herp.careers

*1:subPM…サブプロジェクトマネージャーの略

Scrum Fest Niigata 2024 現地参加してきました-参加したセッション編-

こんにちは、かとあず(@kato_az)です。弥生でQAエンジニアをしています。
5月10~11日に開催された、Scrum Fest Niigata 2024 に現地新潟で参加しました。

新潟駅前で撮影

昨年2023年には仙台と札幌で勉強会の現地参加をしています。
おなじみになりつつある、地方名サムネイル画像が撮影できてよかったです。
▼仙台遠征ブログ▼
tech-blog.yayoi-kk.co.jp ▼札幌遠征ブログ▼
tech-blog.yayoi-kk.co.jp

Day1(5月10日)

開始前

フェスの前に知り合っていた人と待ち合わせ、新潟駅前でパフェを食べました。

おいしかったキウイパフェ。到着タイミングの都合でイチゴパフェは一緒に撮影できず。
近況報告や参加予定のセッションの話をしつつ、いざ会場へ。

受付

"パフェ友"たちに会場まで連れて行ってもらいました。
「スクラムフェス新潟に参加したことある」という情報を聞いていたので、自分で道を調べることを放棄しました、すみません。ありがとうございます。
いざ受付して会場へ……と思ったら入場パスである、QRコードが見つからない!!どうしよう。このままだと入口で半泣きでZoom視聴することになってしまいます。
「受付完了のメールは?」「ログインできる?」と手取り足取りサポートしてもらっているところに、受付担当者が救世主として登場。
QRコードを探すことを諦め、顔パスならぬ名前パスで通過させてもらいました。ありがとうございます。
私が今後スクラムフェスへ現地参加する人へ伝えたいことは、「受付ができるアプリをインストールしておくこと」、「事前にパフェ食べながらQRコードの表示を確認すること」。この2点です。

入口でかわいい発表者Tシャツをいただき、スポンサーブースを見ながら会場へ。

ここからは参加したセッションを紹介します。

「いかにしてオンラインで知り合いを増やすか」

speakerdeck.com 「接点、つくっていこう!」と決意しました。
Day1終了後、Discordのスクラムフェス新潟2024参加者のみ閲覧できる自己紹介チャンネルに自己紹介を書きこみました。そして、2日目が終わるまで、全員の自己紹介に「わいわい」リアクションをし続けました。

私が書いた自己紹介。「わいわい」してくれたみなさんありがとうございます。
「リアクションを押すだけ」なんて誰にでもできるかもしれません。それでも、今までDiscordを眺めていただけの私にとってはちょっとしたチャレンジです。
私は2日間やり遂げました。アウトカムはまだ出ていません。それでも謎の満足感でいっぱいです。

キーノート「The Boundaries of Testing / テストの境界」

「勇気をもって組織内のあらゆる境界を超えることの重要さ」を知るキーノートでした。
私は、境界を超えるのに必要なことは知識や経験だと思い込んでおり、テスターの心理的側面について向き合ってきませんでした。
「越境」するためには境界がどこにあるのか、どの程度の厚い境界の壁なのか、現状を知らなくてはいけません。

部分的には理解できたものの、私はキーノート、招待講演、基調講演を噛みしめて理解できて次に活かせそうという体験がまだできていません。
知識・経験の不足や、話を聞きながら具体化と抽象化をし続ける能力の不足を痛感しました。

ダニエルさんは、3年連続でスクラムフェス新潟のキーノートをされています。2022年、2023年と併せた三部作を視聴して理解していきたいと思います。

まずは自分の境界を越えていくところから。日々チャレンジしていきます。

Networking Party

たくさんの人とお話しさせてもらいました。お話ししてくださったみなさん、ありがとうございます。

おいしかった、100年梅ジュース
ずうずうしく「リキュール買えますか?」と聞いてみたところ、「お店で飲めますよ」とのことでした。いつか行こう、わたご酒店

Day2(5月11日)

「グイグイ系QAエンジニアでやっていくよ!」

speakerdeck.com

とにかく「すごい」の一言。リナさんみたいな人と一緒に働きたいし、リナさんがチームにいたら信頼されたいと思う発表でした。

自分とは対極だと思っていた、「グイグイ系」。
チームがスクラム開発をするのにスクラムマスターがいないという状況になったときに「スクラムマスターやっちゃいます」と言ったのは、私史上最大に「グイグイ系」の瞬間だったなと発表を聴きながら考えていました。
メリットもデメリットも共感しました。一時的に属人化しても自分の稼働があがっても、プロジェクトを前に進めて、お客さまに価値あるプロダクトを届けたいんです。
チームの誰もが時間の制約がない状態で「時間でカバー」できるわけではありません。だからといってグイグイいけないのはもったいないなと思っています。
グイグイ系になりたいけれど、障壁のある人のサポートをする仕事をしていきたいです。

「教えて!スクラムコーチ!品質とスピードを両立させるにはどうすりゃいいの?」

speakerdeck.com

品質とスピードは完全なるトレードオフではないと思っています。
それでも、機能追加を急ぐあまり品質をチェックしきれないままリリースしてしまったり、そもそも何をどうやって計測すべきなのかがわからないままプロジェクトを進めてしまっている現状を打開したいと考えて参加をしました。
このセッションは、私が今直面している悩み事を解決するヒントがたくさんありました。

リリースの基準や品質の基準があいまいなままプロジェクトを進めてしまっていたので、「スプリントをすり抜けた障害を対応するのにかかったストーリーポイント」「サービス停止に陥った時間」など、今記録を残せていない値をまとめることで、分析の第一歩から進めていきます。

最近「PBIの分割」を意識的に取り組んでいますが、ユーザーストーリーの分割方法の種類については考えていませんでした。
今は「あれもこれも」とPBIに書き込まれているものを分割しているところです。さらにPBIを分割して確実に完了できるようなサイズにしていけるように、PBIを分割する方法を学んでいきます。

また、スクラムチームとしてチームで開発を進めたいと思いながらも、並行していくつかのタスクを進めてしまっています。個人のスピードやチームのスピードをどうしていくのか、チームとしての在り方を考えていきます。

チームのアウトカムのために、自分の引き出しを増やす必要があります。インプット情報が不足していることを痛感しました。セッションでたくさんの書籍が紹介されましたので、チームが今まで以上に価値を提供できるように、書籍でインプットしていきます。

「バリュープロポジションキャンバスを使って、しごとの「もやもや」を「ほっと」にするワークショップ」

ワークショップのため、公開資料はありません。
現地にきているのだから、ひとつはワークショップに参加しようと考えていました。
私は、プロダクトのコードを書いていない自分がプロジェクトに必要な存在なのだろうか、どう行動することがプロジェクトへ価値提供につながるのかを、日々なんとなく考えていいました。「バリュープロポジションキャンバス」は初耳だけれども、自分の役割を考えなおすきっかけになるのではないかと考えて参加を決めました。
「8人限定」「事前申込制」ということで、スクラムフェスが始まる前から申し込み場所を探していました。会場についたときに参加申し込みをするボードを見つけ、迷わず名前を書き込みました。

ワークでは、私は"顧客"にビジネスチームのメンバーを想定し、彼らへの価値提供を言語化していきました。
解決したい課題をとして個人ワークで言語化しワークショップのメンバーに共有し、深堀りをしていく中で、課題が別のところにある可能性に気づいたり、相手のことをよく知らないことがわかったり、といった発見がありました。
課題がずれていると提供しているつもりの価値が役立たないばかりか、邪魔になることもあります。
2時間弱のワークショップでは、導入部分しかやってみることはできませんでしたが、新しい言葉を知ることができました。
ワークショップを通して、チームのことを考える新しい切り口を知りました。開発を進めているスクラムチームと、ビジネスチームがそれぞれに価値を高めあえるようなチーム作りを考えるきっかけができました。

「QA経験のないエンジニアリングマネージャーがQAのカジュアル面談に出て苦労していること・気づいたこと」

speakerdeck.com 会場の状態がわからない人には伝わらない表現にはなりますが、会場のガラスの外側からパソコンの充電をしながら視聴しました。
私は、QAのカジュアル面談を担当することがあります。
ログラスさんの組織体制が弥生の体制と似ていて、私自身はQAエンジニアではあるものの、採用を進めようとしているチームのことを解像度高く把握しきれていないなと痛感しました。
もちろん、残業時間やリモートワークの話など、おそらく弥生の誰が話しても同じような内容になることについてはきちんと話せます。しかし、今カジュアル面談で向かい合っている"あなた"に弥生のチームがフィットするのかどうかや、なぜ私が話をしに来たのかを明確に伝えられていません。
弥生の中のことをもっとよく知るために各チームの課題を聞き、外から見た弥生のことを知り、弥生以外の会社のことを知ることが、弥生の魅力を伝えるために必要な活動だと感じました。

「Women in Agile 「New Voices」 : 新たな声、新たな視点 - スピーカー未経験の女性たちが語るアジャイル」

私が10分の発表したセッションです。
発表に至るまでのことを含め、別の記事で書いていきます。

まとめ

すべてのセッションで学びがたくさんありました。
よりよいチーム開発ができるように、自分のこと、チームのこと、毎日少しずつ変えていきます。
そのチャレンジをスクラムフェス新潟にもっていきます。
また、複数トラック同時並行だったので参加できなかったセッションもたくさんあります。アーカイブ動画や公開資料で、全部の発表セッションを見ていきます。

おまけ

QAエンジニアになる前、私は新潟県の妙高高原赤倉温泉に住み込みでスキーインストラクターのアルバイトをしていました。
当時は千葉県に住んでいましたが、一年の1/4くらいは新潟県にいました。
そんな思い出のある新潟県でQAエンジニアとしてスクラムフェスに参加できたことは、私にとってすごく感慨深いことでした。

お寿司を食べたり、自称「島ガール」になったり、おにぎり食べ比べセットを見つけたり

現地参加は、ギャザリングの場で、とても刺激的です。
また、機会をつくって遠征に行きます。次は、あなたの街へ。




弥生では一緒に働く仲間を募集しています。

herp.careers

第二回 Yayoi (Engineer) Beer Bash 開催レポート!

はじめまして!

こんにちは&はじめまして!弥生株式会社の髙瀬と言います! 日々弥生Nextの基盤系プロダクトのスクラムチームでスクラムマスターとしてチームと共に最高のプロダクトを作る為に邁進しております! 最近カロリーコントロールを始めていてダイエットしようとしています。

今回は第一回のBeer Bashに引き続き、第二回を開催しましたので、そのレポートをしたいと思います!

え?ダイエットしてるはずなのにビール飲んでいいの? 大丈夫です。始めたのはこのBeer Bash後ですから( ̄∇ ̄;)ハッハッハ

Yayoi (Engineer) Beer Bashとは?

詳しくは以前宮崎さんが書かれている記事がとても丁寧に説明いただいているので、是非そちらをご覧ください!

tech-blog.yayoi-kk.co.jp

普段チームでプロダクトを黙々と開発していると、どうしても他のチームメンバーとのコラボレーションが希薄になったりするのを解消したい、だとか、今後よりオープンな文化を作っていきたいという気持ち(これは私個人かもしれない)があり、(イベントを通して)情報発信をすることの大事さを実感してもらい、ハードルを下げていきたい、というところから開催しています。

第一回では私もLT登壇させていただきました。好きな漫画のシーンを熱弁し、半分引き気味、半分楽しんでいただけたような、そんなゆるーいイベントです。(仕事にも結び付けず、ただただ個人の趣味の話をし続けるという…)

Beer Bash当日の様子!

ビールを待つ人々

  • 集まった人数:25人くらい
  • LT発表数:5名

LTの内容はちょっと私のうろ覚えですが以下のような内容でした!(スライド管理していないところが緩さを物語っている…!)

  1. ポケモンのお話
  2. ヘッドフォンのお話
  3. コード認知負荷のお話
  4. うどんのお話
  5. AWS S3ストレージ金額のお話

もうね、種族値やら努力値やらの話から始まり、ヘッドフォンのマニアックな話から、急にコード認知負荷という真面目な話が入ったと思ったら今度は個人的なうどんが上手いお店の紹介が始まり、最後はS3ストレージの金額の話で着地するという、LTは第一回に引き続きカオスで面白かったですね。ゲストにも登壇していただき、普段コミュニケーションを取ることのない部署の方のお話もしていただいりしました。

私ファシリテートさせていただきましたが、こういうむちゃくちゃふり幅のあるイベントの司会って経験ないので、これはこれで楽しかったですね! LT終わった後も、最近入社された方と初めまして!の自己紹介をしたり、プロダクトの話もしたりと、もう少し話をしていたい気持ちもありつつ第二回も無事終了しました。

LTを見守る運営

ポケモンを熱く語る登壇者

LTを真面目に聞くエンジニア

第二回のふりかえり

運営メンバーから出たふりかえりは以下のような内容でした。

  • 普段全く接点のないゲストからの話は良かったからゲストはいた方が良い
  • LT相変わらず趣味全開でカオスだけど面白いからいい
  • みんな座ってLT見る会みたいになってるけどもっとコミュニケーション促進のために何か変えた方が良い?
  • ゲーム要素があっても良いのかもしれない
  • 時間通りにいかない…(LTが趣味全開なので本人が盛り上がる)
  • 参加者が固定しつつあるかもしれない

イベント自体は準備もそこそこでゆるいんですけど、イベントをどういう良いものにしようか、どうしたら参加者に楽しんでもらえそうか、どうしたら今参加していないメンバーも参加してもらえるようになりそうか、など運営メンバーで考えるのも楽しかったりします。良いですよね、ふりかえりって。

第三回も企画していますので、乞うご期待!

弥生では一緒にはたらく仲間を募集しています

herp.careers

写真でふりかえる第22回Ques

こんにちは、「カト」あらため、「かとあず」です。
社外活動と業務ブログに接点が出てくると考えず、それぞれで別の名前を名乗っていたのですが、ややこしくなってきたので「かとあず」に統一することにしました。

5月17日(金)弥生株式会社の本社がある秋葉原でQuesを開催しました。
開催前の告知ブログはこちらです。
tech-blog.yayoi-kk.co.jp

このブログでは、写真で第22回Quesをふりかえっていきます。
イベントに参加できる社員に「映える写真を撮って共有してほしい」とお伝えしました。
「了解!」と一眼レフカメラを構える広報チームと、「"映え"ってどういうこと?」とスマホを構えて四苦八苦している開発チームの対比がちょっとおもしろかったです。
みなさん無茶ぶりに応えていただきありがとうございます。

御礼

弥生株式会社の本社には執務室にイベントができるスペースがあるものの、大規模に社外の人にお越しいただいたイベントの開催経験がありませんでした。
勢いで会場提供に名乗りをあげてしまって、Quesスタッフのみなさまには非常に多くのご迷惑をおかけし、本当に申し訳ありません。
準備が整っていない中、最後まで笑顔で対応していただき、本当にありがとうございます。

また、会場にいらっしゃったみなさまへWi-Fiの提供ができなかったり、フロアのアナウンスが適切にできなかったり、ご迷惑をおかけしました。
そんな中でも「きれいなオフィスですね」と言っていただけたり、もくにゃんを愛でていただいたり、たのしい時間を過ごせました。本当にありがとうございます。

イベント開催前

「大規模イベントの入り口と言えば、デジタルサイネージでしょ。」ということで、受付周りにサイネージを設置しました。
設置中のドタバタした様子は、映えと対極のおもしろ状態だったので、撮影はしませんでした。
仮置きできてうれしくて、デザイン作成者に早速共有した写真がこちら。

設置直後のデジタルサイネージ
サイネージ周りのコードや背景が整っていないのは、ご愛敬。

弥生社員が映え写真に苦戦している間に「Quesの中の人」がサイネージと司会の田原さんという素敵なツーショットを撮っていました。

スカイツリーを撮影するならブラインド開けたのに、と思うも後の祭り。気が回らなくて本当にすみません。
この投稿をみて「遠近法という手があるのか」と思い、スマホ撮影隊に共有。"映え"写真が撮れそうな気がしてきました。

開場前リハーサルの様子をばっちり撮影。

リハーサル中
Quesのスタッフのみなさんが、スクリーンやモニターのチェックをしていたので、ちゃっかり「もくにゃん」のスライドを出しておきました。

かわいいQuesロゴの描かれたノベルティと弥生ロゴの組み合わせを、あちこちで撮影。

こちらは、「Quesの中の人」が撮影した、登壇のお二方とポスター。

会場と協賛に「弥生株式会社」がばっちり入っています。ありがとうございます。

イベント中

オープニング中

イベントがはじまりました。大盛況。

オープニング
弥生が現在のレイアウトのオフィスになってから、こんなに人が集まったことがあったでしょうか。
前の方は机ありの椅子、途中からはカラフルな椅子です。

パネルディスカッション中

緑あふれるオフィス。

観葉植物越しのイベント
オフィスがジャングルの中にあるわけではないです。

学んだばかりの遠近法を使って、参加しているみなさんをぼかした撮影にも成功。

ノベルティ越しのイベント
ノベルティが、とにかくかわいい。

会社紹介

弥生社員である私の登場です。
遠巻きに見ていた弥生社員が、少しずつ近づいてきてちょっと怖かったです。

弥生がどんな会社だとか、発表者がピンク髪ではないとか和装をしたとか、わりとどうでもよいのです。(と、会社のブログで言いきってよいのかは、わかりません。)
何よりも見て覚えてほしいのはこちらのスライドです。

もくにゃん!
もくにゃんを愛で始めてしまったあなたには、こちらのブログを。 tech-blog.yayoi-kk.co.jp tech-blog.yayoi-kk.co.jp

弥生Tシャツ作成裏話もどうぞ。

note.yayoi-kk.co.jp

絶好のもくにゃん撮影タイムです。私の後ろにひかえていた司会の田原さんの左手の位置が気になります。

もくにゃん紹介中
私、発表中はひとりで立っていたと思っているのですが、実は後ろから田原さんに支えられていたのでしょうか?陰からのご支援ありがとうございます。

オンラインの参加の人にはおそらく見えていなかったであろう和装の全身写真は見つかりませんでした。
おそらく写真撮影メンバー全員の"映え"基準から外れたのでしょう。
自撮りはしていません。

『「もくにゃん」と「好きな勘定科目」の2語をX(旧Twitter)でつぶやいてもらえる発表にする』と宣言していました。私の今回の目標は達成です。つぶやいてくださったみなさん、ありがとうございます。

発表資料は、構想を考えるところからはじめて30分くらいで完成しました。「推しである、もくにゃんと弥生を紹介する」ということだけを考えて作りました。
FinTech領域QAのみなさん、今度「私の推し勘定科目LT大会」しませんか?

懇親会

おいしいお食事とたくさんの飲み物を準備していただきました。

イベントスペースから懇親会スペースへの移動は、見えない壁があったのか最初はみなさん躊躇されていたようですが、乾杯のタイミングからは、わいわいと盛り上がりました。
40分の懇親会ということで話足りない人もいたかと思います。この物足りなさが次回のイベントにつながるのだと思っています。
お話しできた方、次回もよろしくお願いします。残念ながらお話しできなかった方、次回こそお話ししましょう。

オンライン参加されていた人たちは有志でオンラインアフタートークをしていたようで、その動き方もすてきだなと感じました。

おまけ

Ques第21回(前回)と第22回(今回)に現地参加した証。

Quesノベルティ


弥生では一緒に働く仲間を募集しています。 herp.careers