はじめに

2024年6月までは座席指定システムの領域を担当していましたが、2024年7月から体制変更に伴い古巣のチケット領域にアサインされました。

今回の記事では、業務を進める上で課題に感じたこと、課題解決に向けた取り組みなどを紹介させていただきます。また、活動を通じてモチベーション向上、自分自身の成長するキッカケを掴めた話ができたらと思います。

課題

出戻りだったため、ある程度のドメイン知識は持っていたので立ち上がりは問題なくいけましたが、離れていた間に追加された機能や変更点を、ドキュメントや過去のチケットを調査しながら整理しました。

キャッチアップを進めながら、実際のタスクに着手したときに課題と感じたことがありました。

新メンバーとのコミュニケーション

以前所属していたときのメンバーよりも新しくジョインしたメンバーの方が多かったため、質問など相談事項を誰に話したらよいか、円滑に業務を進めるために一定のコミュニケーションが必要だと感じました。これはどの組織・チームに所属しても出てくることかもしれません。

テスト環境の整備

実際のテストを進めるにあたり、どの拠点のチケットを利用したらよいか確認をしたり、目星を付けて探してみたりすることが必要でした。そのため、確認内容としては「チケットを購入できること」のとき、対象のチケットが分かっていれば数分で終わるものが探したり、存在しなければ新たに作成したりで手間がかかることも多かったです。

テスト設計フォーマットが統一されていない

私が所属していたときのもの（一部改良版）、業務委託でジョインしていたメンバーが用意したもの、新たにジョインしたメンバーが用意したものなど複数のフォーマットが存在している状態で何を使ったらよいのか判断に困りました。設計フォーマットが異なることで、設計自体のクオリティに差が出てしまう、レビュアーの負担が増える課題が見えてきました。

課題解決に向けたアクション

新メンバーとのコミュニケーション：心理的安全性の確保で信頼を構築

心理的安全性がとても重要になってくることは理解していたので、定例MTGなどオンラインで繋がりがあるタイミングを活かし、自己開示も含めたコミュニケーションを意識しました。業務上のやり取りは基本的にslackがベース（一部JIRAチケットやConfluenceでも）となりますが、仕様の擦り合わせや、アウトプットの内容に関しては文字だけのやり取りだけではなく、必要に応じてオンラインで会話することで認識齟齬がなく、手戻りが発生しないように進めました。他チームや新しい組織にジョインする際にも共通する課題だと思いますが、心理的安全性を重視したコミュニケーションの取り組みは、多くの職場で役立つポイントです。

テスト環境の整備：命名規則導入で効率化を実現

担当するメンバーによって扱う拠点・チケットが異なっていることを解消するため、QAチームで統一した拠点・チケットを作成しました。作成にあたり、必要なパターンの洗い出し、命名規則を設けてタイトルを見るだけでどんな設定なのか一目で分かるように意識しました。 QA業務では、テストケースやテストデータの特定が迅速に行えることが効率化の鍵です。このため、誰が見ても一目で内容が分かる命名規則が重要です。

全30種のチケットが存在しており、以下のような形式で【】の中にチケットタイプ（チケットの種類） / 着券タイプ（着券方法）の順で記載し、その後は本番環境に近いタイトルとしています。

【通常券-もぎり】xxxパーク前売りチケット（入園券）
【セット券-もぎり】xxxパーク前売りチケット（入園券＋アトラクション券）
【日時指定（時間帯単数）-もぎり】xxxパーク前売りチケット（入園券）
【日時指定（時間帯複数）-もぎり】xxxパーク前売りチケット（入園券）
【年パス-もぎり】xxxパーク年間パスポート（入園券）

テスト設計フォーマットの統一：クオリティとレビュアー負荷のバランス向上

フォーマットが統一させていないことにより、設計自体のクオリティに差が出てしまっていたため、まずQAリード主導で「機能QAテスト設計方針」が策定され、意識レベルからの統一がされました。

機能テストの流れ例として、

対象機能を分析する：マインドマップなどで、機能と影響のある因子・水準を洗い出す
TestSuiteを起こす：マインドマップの分割単位など
スプシなどで表を使って因子・水準を組み合わせる：禁則処理やテスト技法による組み合わせ
テストケース化：実施結果や進捗管理するためのフォーマットに揃える
レビュー

設計者と実施者が異なることも多く、フォーマットが異なることによって実施時の読解に時間を要することもあり、また、レビュアーの負荷を下げることも目的としたかったため、レビュアー（QAリード）が設計時に使っているフォーマットをベースに統一しました。流れ例が網羅されているフォーマットであったこともあり、「機能QAテスト設計方針」を参考にしながら設計を進められると思ったからです。

QA内部では課題をクリアさせ運用してみたところ、エンジニアレビュー時に内容が分かりにくい、理解するのに時間が要するときがあるなどフィードバックもいただいたので、ブラッシュアップをしていく予定です。

成長の実感

この記事で紹介した施策を実施する前に、私は上長との1on1を行っていました。そして、上長が話してくれた「現状維持ではダメで、事業成長に合わせて自分自身も成長していかなければいけない」という言葉がとても心に響いたのです。このマインドを心がけて仕事に取り組もうと思っていました。課題と感じていること、トライしようと思っていることを相談したとき、適切なアドバイスをもらったり、いいと思う！と後押しをしてもらったりして成功体験を積んでいくことができました。