Women in Agile Tokyo 2024に参加しました②-学び持ち帰ってやってみたこと編-

こんにちは、弥生でQAエンジニア兼スクラムマスターをしている、カトです。
2024年2月6日Women in Agile Japan 開催のWomen in Agile Tokyo 2024にオンサイト参加してきました。
www.wiajapan.org

「Women in Agile Tokyo 2024に参加」で1記事にしようと思ったのですが、いろいろと書きたいことが出てきたので、記事を分けることにしました。
tech-blog.yayoi-kk.co.jp 「Womenについて考えてみた編」を書いて1か月ほど経ちました。今回は、「学び持ち帰ってやってみたこと編」です。

会場

会場に到着して最初にびっくりしたのは、椅子の配置でした。
講演を聞くので全員が壇上を見るように椅子が配置されているのかと思ったら、サークル型で配置されていました。

画像は、Women in Agile Tokyo 2024 Opening, Keynote & OST - YouTubeより。
あまりにびっくりしたのと、すでに座っている人がいらっしゃったので写真はなし。

壇上を見るように並べると、参加している人の様子が見えにくかったり、真ん中付近の席になると出入りで周りの人に配慮しなければいけなかったりするのですが、サークル型に置かれた配置は、好きなところに座りやすく、どの席に座っても周りの人の様子が見やすく感じました。
「周りの人がどんなリアクションをするのだろう？」と後方、隅っこに座りがちな私にとって、新鮮な配置でした。

Keynote

1.5時間ほどの講演の中で、3つのミニワーク（参加者が考える時間）がありました。これから動画を見たり話しを聞く人にネタバレにならないように書きます。

お父さんとお子さんがお出かけ中に事故にあったシチュエーション
靴ひもを結ぶ
バスケットボールのパスをカウントする

3つともはじめて聞いたり見たりする内容でしたが、私は1つ目と3つ目はどちらも解答にたどりつきました。
完全に失敗に終わり、悔やまれたのが2つ目の靴ひもを結ぶワークです。
ワーク以外の箇所でも、社内研修で聞いたことのある用語を改めて聞くことができたり、自分の普段の活動についてふりかえることがたくさんありました。

開発レベル

2つ目のワーク、「靴ひもを結ぶ」ワークについてです。

弥生では、SLⅡ（セルフリーダーシップ）をもとに、会話をしています。
www.blanchardjapan.jp

「"開発レベル"は人につくものではなく、タスクにつくもの」と常々意識して業務をしています。「タスク-1については"D1"だから"S1"でサポートする、一方で別のタスク-2については、"D4"だから"S4"でサポートする」というような会話がなされています。
自分自身も「今対応しているタスクは"D1"だから"S1"でサポートしてほしい」とサポートをしてもらう相手に伝えることがあります。

普段"開発レベル"意識して業務をしているにもかかわらず、靴ひもを結ぶミニワークでは、相手の"開発レベル"の確認をせず、おそらく"D4"であるにもかかわらず、最初から"S1"でサポートをし始めてしまっていました。
知っていても利用すべき場面で活用できていないことを実感しました。
業務中は意識して対応できていると思い込んでいても、使いこなせていない場面があるのかもしれないとも感じました。

はじめて会った相手に対しても最初から適切なサポートができるようになれればよいですが、まずはオープンクエスチョンとクローズドクエスチョンを使い分けながら、相手とコミュニケーションをとりながら、適切なサポートができるようにしていくことを意識し続けます。

みんなのバイアス

3つ目のワーク、「バスケットボールのパスをカウントする」ワークについてです。

私は、パスの回数を2回ほど少なくカウントしてしまっていましたが、動画を見ているときに本題となる事柄には気づいていました。
「この場所はエレベーターホールだろうか？体育館やグラウンドではなく、なぜこんな場所でバスケットボールのパスをするのだろう？」と思いながら動画を見始めたことがきっかけでした。
パスをしっかり数えなければならないとは思いながらも、場所についてや参加している人の様子が気になっていました。

動画を見ているときに本題となる事柄に気づくことができたのは偶然ではありますが、実務でもこのような場面に遭遇することがあったことに気がつきました。

普段、エンジニアのミーティングにQAエンジニアの私が参加する場面において、正直、エンジニアが話している内容について詳細まで理解できていないこともあります。
それでも「わからないので教えて」と聞いてみることが、エンジニアが検討している事項で漏れているかもしれないことや前提が崩れているかもしれないことを洗い出すきっかけにつながることがあります。
この発言を"QA観点"と言われることがあります。しかし私自身は「誰でも気づけそうなことを、偶然私が最初に発言してみただけ」と思っており、他のチームに参画した場合でも再現性があるのかないのかわからないままになっていました。
今参画しているチームでは"QA観点"を発動できるけれど別のチームにいったらそれができないのではないか、これはQAエンジニアや私のスキルではないのではないかといった漠然とした疑問や不安を持っていました。

今回、「バスケットボールのパスをカウントする」動画を見て、エンジニアのミーティングにおいて、ルールを把握してしっかりと正しくカウントする役割がエンジニアなのだとしたら、ボールの行方を追いながらも他のことを気にできるのがエンジニア以外の役割であり"QA観点"に近いことなのではないかと感じました。
「エンジニアのミーティングにQA・UXなど別のロールの人を呼ぶと、エンジニアには説明しなくてもよい前提を説明しなくてはいけなくなる」「QA・UXがエンジニアのミーティングに参加してもらっても時間を使ってしまうだけ」と考えて閉じたミーティングになってしまうことはよくあることだと思います。
すべてのミーティングに参加することは現実的ではないですが、「関係者ではないかもしれないから」「ミーティングの邪魔になってしまうかもしれないから」と遠慮してミーティングに参加しなかったり疑問を発しないことは、チームにとってよくないことにつながります。
私はみんなの論点になっている中心部以外のことを気にできるQAエンジニアにならなければいけないし、QAエンジニアのミーティングも広くたくさんのロールの人に見てもらって意見を取り入れていきたいと強く感じ、今まで以上にミーティングへの参加して発言することを心掛けています。

読み手に考えてもらう手順書

ワークではなく、Keynote後半でのお子さまのテニスのコーチングの話題についてです。

お子さまのテニスのコーチが、「質問をしてくれる。ずっと考えさせるようなことをやっていく。ものすごい1時間が濃い。」とお話しされていました。
一方で、「子どもでも平気で2、3時間の練習をしているのはなんでなんだろう？と考えた時、自分で考えていないからこそ時間を長くしないと定着しない」というお話しがありました。

実務ではどういう場面で当てはまるだろうと考えた時、私は自分たちのプロジェクトで作成している操作マニュアルがこの状態になっているかもしれないと思いました。

私が担当しているサービスは、数多くのサービスと連携しており、時に複雑な設定をしなければ動作させることができません。
根本的な問題の解決として複雑な設定をしなくても使えるような仕組みづくりを考える必要はありますが、現在の挙動も知らなければなりません。
複雑な設定に対応できるようにという思いで、手順書を作成していました。
手順書を作成した結果、特定のメンバー以外でも設定ができるようになったというメリットはありました。しかし、「なんだかわからないけれど手順どおりにやったら設定が完了した」といった状態になったり、イレギュラーなことが起こった時にどの部分を確認すればよいのかがわからなくなったりしています。

この問題に対処するため「何のために実施するのかをメインで記載し、細かい手順は記載しない」という方針で手順書を作り変えました。
作成時に決めた方針は以下です。

テスト環境独自の設定については対外資料にはないので記載する
どのような機能を持っているのかについては記載する
画面に則って進めればよいことは手順を記載しない

レビュー指摘の「記載を削りすぎてしまっていて、他の資料を見ないと操作を進められない」を反映したり、細かく書きすぎている点を調整したりと、まだ試行錯誤中です。
それでも「なぜこの情報を記載しているの？」といった質問からコミュニケーションをとって理解を進められたり、「今、自分が何の目的で設定をしているのか考えながら進められている」といったフィードバックを受けたりといった、「読み手に考えてもらう手順書」に一歩ずつ近づいているという実感を持っています。

オンボーディングの資料として使えるように、さらに更新をしていく予定です。

OST

QAエンジニア

私はQAエンジニアとしてスクラムチームでどのように立ち回ればよいのか、チームはQAエンジニアに何を望んでいるのかということを聞いてみたいと思って、「プロダクトオーナー、スクラムマスター、開発者以外のロールでスクラムで活躍するには？」というテーマだしをしてみました。

つたない進行の中、参加してくださったみなさんに感謝しています。
スクラム開発チームに参加しているQAエンジニアにも、QAエンジニア以外からみたQAエンジニアのことを聞く機会になりました。
そして、「スクラムマスター的な働きをしている」QAエンジニアと出会いました。どんどんミーティングに参加させてもらって、いろんなチームの情報を取りに行く姿勢は取り入れていきたいと思いました。
自チームのミーティングやペアプロモブプロの場に顔を出すことや、Slackのテキストコミュニケーションで自分がメンションに入っていなくても気になることについて確認してコメントしていくことはできています。しかし、まだ他のチームにお邪魔するのは心理的ハードルが高くて実践できていません。
少しずつでも姿勢を変えていかなければ、「思っている」で終わってしまいます。「参加しても情報得られないかもしれないよ」という反応があっても、関連するチームのミーティングに参加してみることから始めていきます。
QAエンジニアがふらりとミーティングに顔を出したときに「どうしたの？障害でも出た？」と一瞬ピリっとする空気になるところから、徐々にでも「覗きにくることが普通」の状態に近づけていければと考えています。

まとめ

「Women」とタイトルにつく会で、Womenや多様性について考えることはもちろん、コーチングや自分の業務についてふりかえり、考えるきっかけにもなる会でした。
業務について視点を変えてみる日をつくることが、日々の業務の改善ポイントを見つけることにつながりました。
実践してすぐに結果が出ることばかりではないけれど、今回の学びを持ち帰って業務に活かし、さらなるサービス品質の向上とチームの発展に努めます。