6年目エンジニアが1年間アウトプット駆動開発をしたら"圧倒的成長"した件について

本記事はトレタアドベントカレンダーの23日目の記事です。

始めに

皆さま、こんにちは！
念願のスプラトゥーンのサーモンランカンストを達成したハイカラスクエアのタコガール兼佐久間まゆちゃん・北条加蓮ちゃんのプロデューサーの@hiroki_tanakaです。
本記事では私が今年1年間実践してきたアウトプット駆動開発に関して振り返ります。
丁度1年前の自分がこんな記事を書いていたので、アンサーソング的な意味合いも込めて笑
tech.toreta.in

アウトプット駆動開発とは

私は2020年の目標に「インプットとアウトプットのスループットを良くする」を設定しました。
この目標を立てた理由はここ1~2年程全く外部へのアウトプットを怠っていた結果、エンジニアとしての成長曲線が止まってしまった感覚があり、その成長曲線を再度動かしたかったためです。
そこでアウトプットを自発的に増やすためにアウトプット駆動開発を導入してみました。
アウトプット駆動開発を一言で言うと、アウトプットする前提でインプットするというマインドセットです。

一般的なメリットとして、以下のようなことが挙げられます。

• アウトプットを意識することで、注意深くインプットするようになり体系的な理解に繋がる。
• アウトプットに対するフィードバックやコメントをもらうことで、より深く学ぶ事ができる。
• 数年後の自分が簡単に振り返ることができる。

そのため、私は具体的には業務・業務外問わず学んだことはすぐに何らかの形でアウトプットして発信していくこととしました。
アウトプットの形は様々でトレタテックブログやQiitaでの技術記事投稿から、社内勉強会での発表・社外勉強会のGotanda.rbでの発表という社内外での発表もありました。
他にもトリッキーなものだと読んだ本の書評をAmazonレビューを書いたり、資格取得をしたり、社外の友人と技術書典に合同誌を出品したりしました。

ただ、私はSNSを殆どやっていないのでそこからの発信は全くしていなかったです。
そのため、アウトプットの拡散力という意味では正直イマイチでしたが、バズることや有名になることが目的ではないのでそこはあまり気になりませんでした。
(今思い返すとSNSを効率的に活用した方がよりフィードバックは得られたかもです。)

実践したこと

そんな今年一年のアウトプット駆動開発の成果ですが、下記の通りです。

• トレタテックブログの記事投稿：4記事
• Qiitaの記事投稿：8記事
• Amazonへの書評レビュー：9レビュー
• 技術書典への出品：1冊
• 社内勉強会での発表：5回
• 社外勉強会での発表：3回
• 資格取得：1資格

改めて数字として数えてみると「よくやったなぁ…」というのが率直な感想です笑

これらのアウトプットは勿論、どこかの月にまとめて行ったという訳ではなく、1年間を通じて満遍なく行ってきました。
強いてあげれば、上半期はQiita・トレタテックブログ・Amazonへの書評レビューといった記事投稿がメインでしたが、下半期は社外勉強会での発表がメインでした。
おそらく、これは最初は記事投稿といったある種、一方通行なアウトプットで満足していたのですが、 徐々にアウトプットした際に見てくださった方からのフィードバックというインタラクティブなコミュニケーションが恋しくなったためです。

発表に関してはネタがなくてもまず「発表します」と手を挙げることを常に意識していました。
挙手してからネタを考える方式だったので、発表1~2週間前は毎回「ネタどうしよう…」と悩んでいました。
今振り返るとこの挙手してからネタ考えるというのは、アウトプット駆動開発に非常にマッチしていました。

実践して感じたこと

1. 学んだ技術の深い理解

記事や発表共に何かしらのネタが見つかると色々試行錯誤しながら、記事や資料を作っていきます。
外部へのアウトプットを意識すると「外部に発信するのだから、下手なこと言えない…」という気持ちにもなり、丁寧に調べるようになりました。
そうすると自然と今まで自分が知らなかったことや曖昧なままの何となくの理解だった部分もしっかり理解出来るようになりました。

例えば、私は下記の発表をするまでRailsの権限管理に関して断片的な知識しかなかったのですが、まとめていく中で体系だった知識が身につきました。

また、よく言われることですが、勉強会は発表者が一番勉強になるということを身に沁みて実感しました。
下手でも聞く側にいるよりも発信する側にいる方が断然良いです。

2. わかりやすく説明できる力の向上

記事でも発表でも自分の学んだこと・経験したことを読み手や聞き手にわかりやすく伝わるように論理立ててまとめる必要があります。
勿論、普段の業務の中でも例えば、Pull Requestの概要や仕様のまとめドキュメントなどわかりやすく伝えるといったことを心がけることはありますが、
あくまでも社内の人は前提や背景を知った上で読み取ってくれる部分も正直、小さくはないです。

しかし、外部の人は前提や背景を一切知りません。
その人たちにわかりやすく伝わるように私は以下のことに気をつけました。

• 「自分が知ってるのだから、相手は絶対知っている。」という思い込みを捨てる。
• 言葉だけで説明せずに、サンプルコードを適度に使用する。
• 記事で伝えたいことや発表で話したいことを最初に書くようにする。また、伝えたいことも最大3つまでに絞る。

このような工夫を行った下記の発表は「わかりやすかった」というフィードバックを頂けて、かなり嬉しかったです！

3. 高いモチベーションの維持

1人で粛々と勉強していてもモチベーションを維持するのはとても難しいです。
(勉強の最大の敵はモチベーションの維持だと思っています。)

しかし、外部にアウトプットすると記事の場合はLGTMやスターが・発表の場合は聴衆からのフィードバックが貰えるようになります。
これがモチベーション維持に役立ち、「自分の記事が誰かの役に立っているんだ！」や「発表後に活発な議論が起こったということは皆気になってたんだ！」と感じることが出来、かなり励みになりました！

また、アウトプットすると自分の理解が深まると同時に、自分の知らなかったことも見えてくるので次はこういうことを勉強しよう・やってみようと思い、それがまたモチベーションUPに一役買いました。

まとめと今後

総括するとアウトプット駆動開発を通じて、成長速度は2段階くらいギアが上がったように感じたので、やってみて本当に良かったです！ そのため、来年もアウトプット駆動開発は続けていきます！

今年は上期は記事投稿中心・下期は発表中心のアウトプット媒体のバランスが悪かったので、来年は記事投稿と発表をバランス良く両立させていきたいです。
そして、外部での発表は社外勉強会だけではなくより大きなカンファレンスなどでも登壇したいです。
勿論、勉強会での発表も続けていきたいです！

また、自分が発表するだけでなく、他のエンジニアが発表出来る場も提供出来るようになりたいです！
(このアドベントカレンダーもその1つです！)

終わりに

正直に言うとアウトプット駆動開発はやっぱり、かなりしんどくて「休日なんだから、ダラダラしたい…」といった誘惑や「こんな記事書いても誰も見てくれないでしょ…」といったネガティブ感情に囚われたことは数え切れません。
ただ、業務と同じで発表(・ものによっては記事投稿も)は発表日という明確な締切があり、かなり強制力が働くのでかえって良かったのかなと思います。
おかげで継続する事ができ、1年間のアウトプット駆動開発を通じて圧倒的成長することが出来たと胸を張って言えます！
これからもこの2つの言葉を胸に来年も邁進していきます。

インプットは必要、でも差別化要因にならない。
しかし、アウトプットすることで差別化になる。
~@yukihiro_matz~

自分と同じくらいの能力がある人間はいくらでもいる。
学び続ける姿勢を止めればかつての恐竜と同じ末路をたどることになる。
~『プログラマが知るべき97のこと』~

プログラマが知るべき97のこと

終わりの終わりに

トレタに少しでも興味を持っていただいた方がいれば、ぜひ遊びに来てくださいヾ(o･ω･)ノ
仲間も募集しています！

トレタにJOINして勉強になったRailsに関する3つを紹介

この記事はトレタ Advent Calendar 2020の22日目の記事です。

はじめまして。2020年3月からJOINしたサーバーサイドエンジニアをしている @shiroemons です。

Appleから AirPods Max が発表されて、SonyのWH-1000XM4を即購入して、ノイズキャンセリング機能と2台の機器に同時接続できるマルチポイント機能に感動している今日このごろです。 マイク性能に関しては、手持ちのAirPodsの方が良さそうなので、ビデオ会議の時は切り替えが必要なのが残念ポイントでした...

本日は、私がトレタにJOINして、勉強になったRailsに関する3つを紹介します。

config/routes.rb のファイル分割

1つ目は、巨大になりがちなルートファイル(config/routes.rb)を複数のファイルに分割するTipsです。

↓でconfig/routes.rbにdrawメソッドを追加することでルーティングの内容を別ファイルに分割できるようになります。

# config/routes.rb
class ActionDispatch::Routing::Mapper
  def draw(routes_name)
    instance_eval(File.read(Rails.root.join("config/routes/#{routes_name}.rb")))
  end
end

Rails.application.routes.draw do
  draw :admin
end

# config/routes/admin.rb
get :foo, to: 'foo#bar'

DHHのgistもあります。

こちらは、Rails 4.0がリリースする前に一度取り込まれた機能になりますが、revertされました。 ところが、最近リリースされたRails 6.1で、この機能が復活しました🎉

Rails 6.1からは、今回のTipsは不要になります。

# config/routes.rb
Rails.application.routes.draw do
  draw(:admin)
end

# config/routes/admin.rb
get :foo, to: 'foo#bar'

Rails Guidesもすでに用意されています。(日本語はまだかな)

guides.rubyonrails.org

ルートファイルを分割したい場合は、試してみてください！

APIドキュメントツール apipie-rails

ここ最近のRailsの役割は、APIで利用されることが増えてきました。 必要になってくるのは、エンドポイントは何で、どんなパラメーターが必要で、どんなエラーが発生するのかなどのドキュメントが大事になってきます。

そこで重宝されるのは、REST API向けのドキュメント生成ツールのapipie-railsです。

github.com

ここでは、設定方法などは省略します。設定方法などは、GemのREADMEをご参照ください。

コントローラーのメソッドの上部に、HTTPメソッドやエンドポイント、パラメーター、エラーなどの説明を記載することで簡単にAPIドキュメントが残すことができます。 学習コストが少なくすぐに利用することができます。

サンプルコード

class UsersController < ApplicationController
  before_action :set_user, only: [:show, :edit, :update, :destroy]

  api :GET, '/users', 'ユーザ一覧を返します'
  def index
    @users = User.all
  end

  api :GET, '/users/:id', '指定したIDのユーザー情報を返します'
  param :id, :number, require: true, desc: 'ユーザーID'
  error code: 404, desc: 'Not Found'
  example <<-EOS
  {
    "id": 1,
    "name": "hoge",
    "created_at": "2020-12-17T05:23:18.135Z",
    "updated_at": "2020-12-17T05:23:18.135Z",
  }
  EOS
  def show
    #...
  end
  
  #...

画面キャプチャ

サンプル画面

このような、ドキュメントが簡単に生成することができます。

apipie-railsは、Swagger形式(OpenAPI 2.0)のJSON出力が可能です。

rake apipie:static_swagger_json

GemのREADME にも記載があるので参照してみてください。

• Static Swagger (OpenAPI 2.0) files

APIドキュメントの管理は、苦労したことがあるので簡単に生成できるのでとても感動したので、紹介してみました。

コールバッククラス

Railsを運用していくとどうしてもコールバック処理が煩雑かつ、複雑になりがちです。 そんな時は、Railsガイドにも載っているコールバッククラスを利用します。

railsguides.jp

サフィックスにDispatcherを付けてコールバッククラスを利用しています。 主な用途としては、複数のモデルから共通の非同期処理を行う Worker の呼び出しに使用しています。

以下は、店舗の席情報に変更が行われた際、非同期処理で席在庫を再計算するサンプルコードです。

# app/callbacks/restaurant_table_stock_manager_dispatcher.rb
class RestaurantTableStockManagerDispatcher
  def after_commit(record)
    rebuild_stocks_async(record)
  end

  private

  def rebuild_stocks_async(record)
    # 非同期処理(Worker)呼び出し
  end
end

# app/models/restaurant_table.rb
class RestaurantTable < ActiveRecord::Base
  after_commit RestaurantTableStockManagerDispatcher.new, on: [:update]
end

このようにafter_commit等のコールバックに対応するメソッドをパブリックメソッドとして定義します。 引数にはコールバックを呼び出すキッカケになったオブジェクトが渡されます。

コールバッククラスは、コールバック処理すべてをコールバッククラスにするのではなく、 複数のモデルで同一の処理を行う場合や、複雑な処理を行っているものなどの機能単位に切り出せるものに留めておくのが良いかと思います。

コールバッククラス自体は、目新しいものではありませんがバリバリ活用していたので、紹介したかったところです。

おわりに

１つ１つは、目新しいものではないですが、実際に利用し活用していますよという発信の意味を込めて紹介してみました。

トレタに少しでも興味を持っていただいた方がいれば、ぜひ遊びに来てください！ 仲間を募集しています！

corp.toreta.in

超短期プロジェクトでのQAエンジニアの立ち回りを振り返ってみた

※この記事はトレタ Advent Calendar 2020 20日目の記事です。

こんにちは。QAエンジニアの坂田です。

今年はコロナ禍で大変な年でしたね。私はそんな中ボルダリングに嵌ってしまい、感染対策を心掛けつつジムに通う毎日です。

さて、弊社代表がオーナーを務める「豚組しゃぶ庵」というしゃぶしゃぶのお店が先日「豚組しゃぶ庵β」として期間限定リニューアルオープンしました。
※ リニューアルの経緯やコンセプトは以下のひとしさんのエントリーをご覧ください

note.com

こちらの予約サイト、お店の間取りを見て好きな個室を予約できるという飲食店では珍しい仕組みを採用しています（「席指定予約」と呼んでいます）。従来のトレタには無かった仕組みのため、裏側のシステムを含めほぼゼロからの新規開発でした。

reserve.ox-shabuan.jp

席指定予約の構想と実装方針が固まってきたのが10月半ば頃、その時点で引いたリリース日が12月7日という1ヵ月の超短期プロジェクトで、私がQAとしてメンバーに入ったのは11月10日でした。今まで経験した中でかなりの突貫プロジェクトでしたが、スケジュール通りに無事リリースを迎え、大きな問題なく稼働しておりホッとしています。

本記事では、このプロジェクトでやったことを振り返りつつQAとしての立ち回りのポイントをいくつか挙げてみたいと思います。スピード優先の開発での品質担保に興味のある方、少しでも参考になれば幸いです。

※ ちなみに、席指定予約のバックエンドの話をいっしーが 12/14のアドベントカレンダー で詳しく語ってくれています。是非あわせてご覧ください！

プロジェクト全体の振り返り

プロジェクト期間中の実装・QAの動き

上の「テスト」の欄に私の大まかな動きをまとめました。
（休日にも便宜上ラインが引かれていますが、当然ながらお休みです）

機能テストやマルチブラウザテストの実施期間よりも、仕様書作成やスモークテスト（デプロイ単位で行う簡易的な動作チェック）に掛けた期間の方が長くなっています。

これは後でも述べますが、デザイン案をベースとした実装方法にリスクが高く、視覚的には想定しづらい抜け漏れが大量に発生し得ると考えたためです。

抜け漏れをテストフェーズまで持ち越すとスケジュール破綻やリリース時品質の低下を招くため、とにかく早期に機能全体をチェックして未確定事項を挙げられるだけ挙げ、デザイナ・エンジニア間で都度あるべき挙動をすり合わせながら進むことを最優先しました。

ちなみに仕様書の手直しはリリース直前まで頻繁に行っており、仕様書に関わった時間の割合は上で引いたラインよりもかなり多いです。結局テストフェーズまで持ち越してしまったバグも幾つかありましたが、結果的にはかなりの数を予防・早期発見の方向に寄せることができました。
（マルチブラウザテストの開始タイミングが遅く、大きめのブラウザ依存のバグを終盤まで見逃してしまったことは反省点です）

さて、以降は時系列を追って詳しく振り返っていきたいと思います。

キャッチアップとテスト計画作成

ごあいさつ。

参加初日にまず取り掛かったのは状況確認です。「超短期で皆多忙」「途中参加」「原則リモート勤務」という制約もあって、必要な情報は全部自分から取りに行きました。esaのドキュメントやSlackの過去ログを漁れるだけ漁り、体制・役割分担・スケジュール感・各種ドキュメントの有無・タスクの進捗状況などを確認していきます。 （弊社では社内の情報共有にesaを使っています）

同時にテスト計画に取り掛かり、アウトプットベースでQA活動に関する認識合わせの土台を作ります。書き始めからメンバーへ共有し、初日のうちにフィードバックを貰いつつ大体のアウトラインを固めました。

テスト計画を書きながら状況確認を進める

テスト計画はシンプルに、事前にステークホルダーに最低限伝えておくべきことと、メンバーに事前承認を取っておくべき項目に絞って書きます。

テスト計画の項目抜粋。大体2〜3時間程度で書き終えられる分量。

状況確認や情報収集にあたりポイントだったのは、当たり前っぽい質問でも知らなければ躊躇なく聞いてしまうことです。
もちろん漁れる資料は漁っておくなどメンバーになるべく負荷を掛けないよう配慮が大事ですが、

• 各メンバーとのコミュニケーションの下地を作れる
• 既存メンバーの情報量に追いつき早くから一人前の働きができる
• 当たり前のようでいて実は認識が揃っていなかったこと、決まっていなかったこと、抜けていたことを発見できる

といった大きなメリットがあります。実際、本プロジェクトでもチーム体制・役割など当たり前の情報がまとまっておらず、キャッチアップのついでにプロジェクト概要を整理してドキュメント化したりもしました。

知らないことが沢山。とにかく教えを乞う。

情報収集を通して分かったプロジェクトの全体像はおおよそ以下の通りです。

• 開発の主力はデザイナ1名とエンジニア4名（フロント2、バックエンド2）の少数精鋭
  • PM/POはプロジェクト複数掛け持ちで多忙、エンジニアは一時的なヘルプの増員あり
• ざっくりした要件や開発方針はチーム内で共通理解が取れているが、要求仕様に関するまとまった文書は無い
• デザイナが要件をデザイン案（画面設計と画面遷移図）に落とし、それをベースに実装が始まっている
• 実装が全て完了してからのテスト期間はせいぜい5日間程度しか取れそうにない

ここでQAとしてリスクを感じたことは、テスト期間もそうですが何より一番はデザイン案と実装との間に情報のギャップが大きすぎることです。

デザイン案はユースケースの基本的な流れや画面の構成・機能を視覚的に分かりやすく把握できますが、実装に必要な情報を全て与えてくれるものではありません。
特に以下のような動的な挙動や非視覚的な処理の表現には不向きです。

• 各画面要素の詳細な挙動や状態変化
• 画面要素同士の相互作用
• 入力値の保持やクリア
• 時間経過が関係する挙動
• バリデーション処理
• エラー発生時の挙動
• バックエンドの仕様や制約に依存する処理

このまま進むと「エンジニアが気づいた都度よしなに対応する」という対処になりますが、抜け漏れや手戻りが多く非常にリスキーです。
そこで、品質担保のため、まずデザイン案と実装との間の情報ギャップを埋め、実装が進行する前に未確定事項を極力つぶすことを最優先に進めることにしました。

機能仕様書の作成

markdownで仕様を書いていく

3日目、技術的なキャッチアップと並行して、デザイン案をベースに機能仕様書を書き始めました。

QAエンジニアが仕様を書くのに違和感を覚える方がいらっしゃるかも知れませんが、QA自身にとってもメリットが大きく、取り掛かる意義があります。この辺りの意義は昨年のアドベントカレンダーに書きましたので宜しければご覧ください。

tech.toreta.in

仕様を書くことで、細部の未確定事項や矛盾に気づけます。デザイナやエンジニアが既にプロジェクトの細部にどっぷり浸かっているのに対し、フレッシュな第三者視点で全体を眺めて疑問点を洗い出せたことも良い点でした。

取り急ぎデザイン案から想定される挙動と、他に検討すべき項目を2日間で整理し、チームメンバーに共有しました。未確定箇所や要確認事項はとりあえず [TBD] とラベルを付けておきます。

また、仕様整理後すぐにデザイナ・エンジニアを交えて仕様書の読み合わせを行いました。視覚的に分かりやすいデザイン案と異なり、言語とロジックで記述された仕様はとっつきにくく誤解を招きやすいためです。読み合わせの場で [TBD] を解消できる可能性があるというメリットもあります。
（エンジニアは既にデザインベースでよしなに実装を進めていたため、単に共有しただけでは読んでもらえないだろう、という事情もありました）

読み合わせの結果、デザイナやエンジニアから沢山のフィードバックが得られました。デザイン・実装面での制約や解決のアイデア、データの実体や内部ロジックの詳細などです。
これらはテスト設計のインプットとしても有用であり共有価値もあるため、機能仕様そのものではありませんが仕様書に [補足] として追記していきました。

補足情報や要件変更に絡む情報も一緒にまとめていく

[TBD] はメンバーが持ち帰り検討したり、大きなものはPOに確認を取ったりして確定していきます。また、実装が進む過程で要件漏れや不具合・それに伴う要件変更が次々と発生するため、その都度仕様に反映してチームに共有し、必要があれば再度読み合わせを行いました。 （結果的に、リリースまでに30回以上のドキュメント更新を行いました）

スモークテストと機能テスト

テスト計画に記述した各テストタイプの位置づけ

仕様反映作業がひと段落したタイミングで、エンジニア側も一連の画面遷移や主要なコンポーネントの実装が完了し、UIでの確認が可能な状態になりました。そこで、後続の機能テストのためにテストパターンを作成しつつ、出来上がった実装部分のスモークテストを先行して実施することにしました。

スモークテストに必要なテスト用データは予め投入されていることを確認済みで、実行環境はstg,prod環境が未構築のタイミングだったためローカルマシンでビルドし実行する、という手段を取りました。

実装作業と並行してローカルでスモークテストを実施する際の制約として、どこが未実装でどこが実装済なのか区別がつきづらい、という点があります。実装の進捗状況はデイリーで大まかに把握はしていますが、部分部分にいつどこまで手が入るかは細かく把握できず、都度エンジニアに聞くのもコストになります。

そのため、スモークテストは

• 主要なユースケースに沿った正常系の機能確認（トップ画面から順に遷移してちゃんと予約完了まで到達するか）
• 実装上の要注意箇所に絞った動作確認（入力した条件に合致した空席情報が表示されるか）

といった観点に絞って実施しました。

また、事前にバックエンド担当のエンジニアと連携を取り、各データストア（Hasura, Closure, Firestore）上で空席データや予約完了データを直接参照できるように権限を貰っておきました。これによりデータの流れを含め確実にE2Eで追える状態になり、スモークテストだけでなく機能テストで詳細なロジック検証を行う際にも役立ちました。

次にテストパターンの作成および機能テストについてです。

テストパターンの大項目

概ね「ユースケース」「ロジック」「エラー処理」「各画面要素の挙動」を軸にテスト観点を洗い出しました。

「ユースケース」は画面の行き来や繰り返し実行、異なる操作の組み合わせや時間経過に注目してユーザの一連の操作を展開しています。
「ロジック」はある程度複雑な内部処理や判定条件が絡むもの、「エラー処理」は異常な入力のパターン、「各画面要素の挙動」は個別のコンポーネントごとの依存関係や状態変化のパターンに注目してケースを洗い出していきます。

この辺りの観点整理はテスト対象のシステムによって最適解が異なると思いますが、私は（特にWebアプリの場合は）上記のフレームワークをよく使っています。

テストパターンおよびテスト結果の記述には、やはりesaを用いました。スプレッドシートやSaaSのツールなど様々なテストケース管理手段がありますが、本プロジェクトではテストパターンの作成・管理コストを最小限に抑えたいことと長期的な運用の想定は不要な点から、使い慣れていてかつ他メンバーも参照しやすい点を重視しました。

機能テストは、テストパターンに対応したテストデータの投入とstg環境のデプロイが完了したタイミングで着手しました。

この時点では既にほとんどの実装が完了しており、スモークテストで検知した不具合も修正済みだったため、大きな不具合や手戻りに悩まされることなくテストを実施できました。エンジニアも余勢を駆ってユニットテスト追加を精力的に進めてくれ、システム全体をより強固にすることができました。

最終確認とリリース

macSafariでは input type="date" でカレンダーが表示されない...だと...！？

プロジェクトも終盤に入り（といっても4週目ですが）、大方の機能確認が完了したタイミングでマルチブラウザテストに入りました。
席指定予約システムはスマートフォンからの予約を主対象にしていますが、デスクトップブラウザ経由のアクセスも想定し、主要なサポート対象ブラウザでの動作確認を行いました。

ここで想定外に不具合が出たのが誤算で、上図のようにブラウザ標準のカレンダーが表示されないブラウザがあったり、個室の間取りの上に予約の◯×マークが正確に表示されずずれてしまうブラウザがある、等のバグを発見してしまいました。
これは機能テスト開始のタイミングでデスクトップブラウザも簡易的にチェックしておくべきだった...と、良い反省材料になりました。 （ブラウザ標準カレンダーの不具合は、近々のリリースで独自のカレンダーUIを実装することで解消見込みです！）

ともあれ、デザイナとエンジニアがすぐに代替案や修正方針を提示してくれたお陰でリリースには響かず、事なきを得ました。席指定予約のリリースは当初お店のオープンに合わせた12/7を予定していましたが、開発がスケジュール上の余裕を少し残して完了したため、12/3に内部リリースして本番動作確認を行い、12/4に外部向けの本番リリースを迎えることが出来ました！

まとめ

QAとして立ち回ったポイントを改めてまとめると、

• 早期に機能全体をチェックして未確定事項を特定し、デザイナ・エンジニア間で都度あるべき挙動をすり合わせながら進むこと
• プロジェクト参加直後は情報を漁れるだけ漁った上で、当たり前っぽい質問でも躊躇なく聞いてしまうこと
• 仕様をドキュメントに整理し、早期にデザイナ・エンジニアを交えて仕様書の読み合わせを行うこと
• なるべく実装と並行してスモークテストを実施し、主要なユースケースや実装上の要注意箇所に絞った確認を行っておくこと
• 環境依存のバグを侮るなかれ

という感じかなと思います。

それにしてもスケジュール通りリリースできて良かったです。
プロジェクトへの献身と惜しみないサポートをくれた優秀なチームメンバーに感謝しつつ、本記事を結びたいと思います。

おっと、、トレタでは新しい仲間も募集中です。興味を持った方は是非。

エンジニア採用 | 株式会社トレタ