トヨタの片づけを読んでみた
はじめに
WACATE 2025夏に参加した際に、抽選に当選し頂いた「トヨタの片づけ」を読了しました。
本書では、片づけを単にキレイにすることではなくムダをなくし効率を上げるためのツールと捉え、トヨタ式の片づけの方法や片づけを習慣化する仕組みが紹介されています。
工場の現場での話が中心かと思いきや、オンライン上で働く（物理的にモノを持たない）IT業界の自分にも当てはまる話がいくつもありました。
「品質」というワードも所々に登場し、QAエンジニアとしても非常に興味深い内容でした。
日々「情報が散らかってるな」「この仕組み、無駄が多いな」と感じている人ほど刺さる一冊と思います。私自身、いくつかの失敗を思い出しながら読みました…
特に印象に残ったトピックをいくつかご紹介します。
印象に残ったトピック
モノを持つことは、コストになる
モノを捨てるときに障壁になるのが、人間の捨てたくない心理。「急に必要になるかも」「もったいない」という気持ちがモノを捨てることにブレーキをかける。
しかし、モノを持つにはコストがかかる。モノを保管するにはどれくらいのお金がかかるのか考える必要がある。コストというのはお金だけではなく、そのモノを探す時間や取りに行く時間もコストである。
コストがかかることを意識することで、「いるもの」なのか「いらないもの」を考えて行動できるようになる。
自分が業務上で保管しているドキュメントは全てオンライン上にあり、目の前に書類が積み上がってる訳ではないので、モノを保管するスペースとしてのコストはあまり意識していなかったです。
しかし、物を持ちすぎると探す時間がかかるというコストは、物理的にモノを持たない人にも通ずる話に思います。
ドキュメントを見つけたものの似たようなものがあってどっちを信じたらよいかわからない、今も参照していい情報なのか古い情報なのかわからない…などはあるあるだなと…。
片づけができてないと間違えるリスクもあると本書にありましたが、最近まさにこれ起因の作業ミスをやらかしました。複数箇所に同じ情報が管理されていて、自分が見ていた情報だけ内容が更新されておらず間違っていたため発生したミスです。
片づけができておらず重複して情報が管理されていて内容に食い違いが起きる…あるあるな気がします。
でもトラブルが起きた時に、情報の散らかりが直接的な原因に見えにくいなぁとも思います。「もっとしっかり確認しよう」とか、そういうふりかえりになりがちだなぁと。問題が起きた時に片づけができていたか？という視点を持つようにしていきたいです。
付随作業と主作業の話
いるものを整理できたら次はどこに置くか整頓する必要がある。
モノを置くときに考えるべきことが、付随作業をいかに減らせるか。
付随作業とは何か。パソコンで報告書を作るケースを例にすると、文字を打つ作業が主作業、資料を探したりプリントアウトするのが付随作業。
しかし、人は動いていれば仕事をしている感覚にとらわれてしまう。「やっている動きにムダはないか」「この動きは価値を生んでいるか」を問い直してみることが大事。
あ〜〜これもやりがちだ〜〜って思った部分。
テストケースの根拠を知りたくてテスト設計の資料を探すんだけどなかなか見つからないとか…“なんでこのケースがあるのか”を知りたいだけなのに、資料を探す方に時間がかかってしまうというムダ…
必要な時にすぐに取り出せるように関連する情報同士はたどれる状態にはしておきたいなと思いました。
線を１本、引きなさい
整理・整頓しようとしてもどこから始めたら良いかわからない場合、まずは線を１本引いてみる。
仮の基準を作れば、それを元にして正常・異常がわかる状態になる。そこから標準を作ることができる。
例えば、モノを置くスペースを示す線をまずは引いてみる。それでモノが溢れるようなら、もっと広いスペースが適切であることがわかる。
仮の基準を作って、現実の動きを見ながら修正をかけていくことで標準が決まっていく。何も基準のない状態が一番よくない。
完璧な基準を作ろうとするばかりに、動き始められないこともよくあるなと思います。
実際の業務だと、例えば、不具合の緊急度を作ろうとしても「ケースバイケースだから判断ができない」「作っても基準通りに分類できるのか？（使える指標になるのか）」みたいな話になって、なかなか踏み切れないこととかもありました。
でも、仮の基準すらないと何も始まらないので、完璧じゃなくていいからとにかく基準を用意してみようと思いました。
清掃は点検なり
整理・整頓ができたら、その状態を維持して行くための活動の一つに清掃があります。
清掃とは、キレイにそうじする。日常的に使うものを汚れないようにすることです。
トヨタには「清掃は点検なり」という言葉があります。清掃によって異常が見つかるのです。
例えば、デスクを整理していたら提出し忘れた書類や処理していない仕事が見つかることがあります。
清掃はいつもと違う状況に気がつき問題を見つけるチャンスだから、労力を惜しむべきではない。
また、そもそもそうじをしなくて済むしくみを考えることも、清掃のひとつなのです。
こ、これも刺さる…。
カンバンにどんどんタスクが積みあがって、ある日見直すとやり漏れていたタスクに気づいたこと、何度かあります……。
整理・整頓しても、維持できなければまた散らかる。“清掃”がなぜ必要かを改めて実感します。
でも、清掃って定着しないんですよね…。忙しさからつい後回しにしてしまったり、効果が見えにくかったり。
本書で「清掃時間を業務に組み込む」という話を見て思い出した取り組みがあります。
以前チームで週に１回１時間を確保して既存のテストケースを見直す会をやっていました。
この時間にやるぞと決めて習慣化していたことで長期にわたって続けることができたし、テストケースを見直す中で、仕様が変更されて不要になったテストケースに気づけたりもしました。
「清掃は点検なり」という言葉、まさにその通りでした。
実際の業務にどう活かせそうか
普段の業務で「片づけ」が必要なのはどんな対象でしょうか。
私の場合、仕様書やテスト設計のドキュメント、テストケース、タスク管理に使うカンバンなどが真っ先に思い浮かびます。
これらが散らかっていると、例えば誤った情報をもとに作業をしてしまったり、古い仕様に引きずられて無駄な作業が増えたりして、品質低下やミスにつながることを何度も経験しました。
QAの仕事は異常を発見し品質を保証すること。だからこそ、片づけで情報を整理することは、品質向上に直結すると強く感じています。
とはいえ、プロダクトの品質を良くするための片づけは一人ではできないと思っています。チームで片づけをしていくことが不可欠です。
本書にも、決めた片づけルールをいかに定着させ、維持していくかという点が詳しく書かれており、この辺りも仕事に活かせそうだと感じました。
おわりに
本書を通して、片づけ＝ただキレイにすることではなく「ミスやムダを減らす改善活動」であると改めて認識しました。
一見、当たり前のことばかりに見えますが、自分自身の仕事の中で「本当にできているか？」と振り返るとハッとさせられる内容ばかりでした。
当たり前のことを当たり前に継続することの難しさを改めて痛感しています。
QAという仕事に限らず、「成果が出づらい」「やたら忙しい」職場にこそ効くエッセンスが詰まっていると感じます。
WACATE2025夏に行ってきた！
めちゃくちゃブログ放置してた〜〜〜〜！久しぶり〜〜〜！
ずっと気になっていたWACATEに行ってきたのでその感想です
WACATEとは
テストに興味がある若手向けのワークショップです。
1泊2日の泊まりがけでワークショップに取り組んだり、参加者同士で交流を図ります。
年に２回行われ、夏はひとつのテーマを「狭く深く」集中的に取り組みます。今回のテーマはテストプロセスでした。
2025年夏の概要はこちら：https://wacate.jp/workshops/2025summer/
なぜ参加しようと思ったのか
参加の目的は主に２点あります。
１点目は、QAエンジニアとして自信を持てるようになりたかったからです。
私はQAエンジニア３年目ですが、テスト分析〜実行に関するスキルが足りてないと感じていました。JSTQBのFLは取得したものの活かしきれている気がしませんし、自己流の付け焼き刃テストになっている不安がありました。
ワークショップを通してテストプロセスを学び直すことで、テスト活動に自信を持てるようにしたいと考えました。
２点目は、社外の人と交流することで自分の立ち位置を見つめ直したかったからです。
ここ最近、業務の中でテスト活動をあまり行なっていないことから「自分のやっていることはQAの仕事なのか？」「品質にちゃんと貢献できているのか？」と思うことが多々あります。
社外の人とテストや品質保証について話す中で、自分がQAエンジニアとして何をしていきたいのか改めて考え直したいと思いました。
事前準備
事前準備として、ポジションペーパー作成と予習を行いました、
ポジションペーパー
WACATEに申し込む際ポジションペーパーが必要です。
自己紹介、参加の意気込み、議論したいことなどを書くそうです。テンプレートは用意されていますが、フォーマットは自由です。
実際に参加者のポジションペーパーを見ると、文章として書き連ねる人、箇条書きな人、画像を添えている方…色々でした！
どういうフォーマットにするか悩みましたが、あまり深く考え込みすぎなくても大丈夫だったなと思いました。私はこれまでのキャリアや前述した参加目的を記載しました。
ポジションペーパーは１度提出すると修正ができないので注意です。
予習
テストの話を複数人でするのに用語や概念は押さえておいたほうが良いかなと思ったので、JSTQB FLのシラバスを読み返しました。
実行委員からテスト技法について予習しておくように連絡があったので、ソフトウェアテスト技法練習帳 ~知識を経験に変える40問~ を何問か解き直しました。
当日レポート
1日目
オープニングセッション
諸々の説明を受けて、配られた名札の裏に持ち帰りたいことの記入をしました
名札はWACATE参加回数で色が違うようです
ちなみに今回の参加人数は60名だそうです。
ポジションペーパーセッション
事前に提出したポジションペーパーを使って班のメンバーに自己紹介をします。
普段の業務、参加の意気込み、持ち帰りたいことを話しました。皆さんの話を聞くなかで、自分と同じ悩みを抱えていたり、共感できるポイントがあったりして、緊張がほぐれました。
ポジションペーパーは冊子にまとめられて配布されます。WACATEのクロージング時にBPP賞（ベストポジションペーパー賞）という最も多くの人が良いと思ったポジションペーパーの人に贈られる賞があります。
今回は60人分！どの内容も興味深く読んでいて楽しかったです！
BPPセッション
前回のBPP受賞者によるセッションです。
QAという仕事の魅力について、ご自身の悩みも踏まえてお話ししてくださいました。
最近QAの仕事の楽しさってなんだろうと悩んでいた自分は「そうそう、こういう時が楽しんだよね！」と思い出せて前向きな気持ちになりました。
スライドの構成や話し方もうまく、そういった点でもとても勉強になりました。
テストプロセス
今回のワークショップのテーマであるテストプロセスについて講義形式で学びました。
テストプロセスについては、JSTQBのFLを勉強したときに学び各工程については理解した気になっていましたが、じゃあなんでテストプロセスを使うの？というのを意識できていなかったなと気がつけました
また、JSTQB以外のプロセス、Test.SSFやISO/IEC 29119-2、については知りませんでした。他のプロセスもJSTQBのプロセスと比較しながら学びたいです。
仕様書読み込み
これからのワークショップでお題にするアプリケーションの仕様書、テスト計画書、要件定義署を3色ボールペン法を使い、各人で読んでいきます。
久しぶりに仕様書を読むことをしましたが、ユーザーがやりたいことを考えながら作る物に考えを巡らせるのは楽しいな、自分はこれが好きなんだ、と実感しました。
ワークショップ（テスト分析、テスト設計）
ここから6名1班でのワークショップとなります。
初日はテスト分析〜テスト設計までを行いました。
まずはテスト分析です。
最初に「ユーザーのやりたいこと」「業務上ありそうなこと」を洗い出しました。
それをもとに必要だと思うテストを検討し、制約や要求を考慮（スコープ外の機能はテストの対象から外すなど）しました。
そして、洗い出されたテストすべきことに優先度をつけていきました。私たちの班ではユーザーが一番解決したい課題、クレームになりそうなところ（リスクが高いところ）を軸に優先度を決めていきました。
私は「何をテストするか」を考えるときに、思いつくがままに連想ゲームして列挙していて、自分の中で再現性のある考えの”型”のようなものがないということに気がつきました。
班のメンバーの方に「何をテストするか考える時にどう考えているか？」と質問したところ、さまざまなアドバイスをいただけました。悩みの相談しやすさはWACATEの大きな価値の一つだなと２日間を通して感じました。
次にテスト設計。
使えそうなテスト技法を考え、テスト技法を適用する対象を決めていきます。
その情報をもとに、どこまでテストをするかを決めました。例えば、同値分割を使うとこの辺りの値は代表値だけのテストで良さそうだよね、などの判断をしていきました。
このフェーズから私たちの班では、３ペアに分かれてそれぞれ別のテスト項目について設計を行いました。
限られた時間の中でワークを進めるという点では有効でしたが、他のペアが何をやっているかの把握があまりできていなかったのが個人的な反省です。結構、時間がタイトなので難しい…！
１日目のワークショップはここまでです。
分科会
夕食後には分科会が行われました。
分科会とは、オーナーが持ってきてくれたテストに関連するトピックの中から話したいトピックを選んで、トピックごとに自由に話す会です。OST（オープンスペーステクノロジー）みたいだな〜と思いました。
今回のテーマは４つでした。（正式なタイトル忘れてしまったのでニュアンスだけ…すみません）
- プロセス改善って必要？
- コミュニケーションについて
- 本日のふりかえり
- 勉強会はじめての人
私はコミュニケーションについてに参加しました。QAと開発エンジニアがうまくコミュニケーションを取るには？などの話がされました。
勉強会はじめての人では、オフラインの勉強会ハードル高いよね的な話や資格試験についてなど幅広くお話ししました。私はテスト分析や設計を実践的に学ぶにはどうしたら良いか？と相談させていただき、身近にあるアプリや物でテストを考えてみると良いというアドバイスをいただきました。勉強になる〜〜〜！
２日目
モーニングセッション
最近テストで使った値から、「なぜその値を選んだのか？」など思考を遡って、普段現場でやっているテストプロセスを理解しようというワークショップでした。
私はテスト分析の過程までしか遡れず、それは自分がテスト計画を意識してないからなのかな？不確実性の高いプロジェクトで急にテストフェーズに入ったからなのかな？などの発見があって面白かったです。
ワークショップ（テスト設計、テスト実装、テスト実行）
１日目のワークショップの続きです。
前日にどの技法を使うか、どこまでテストをするか決めたものをもとに、テスト技法を使ってデシジョンテーブルや状態遷移図などを作成していきました。
テスト技法は知識として持っていても、実戦で使える状態にするには繰り返し訓練が必要だと痛感しました。
次はテスト実装です。
テスト設計で作ったものをもとに、テスト手順や期待結果を記載していきます。
ワークショップでは紙に記載していったのですが、こんなに手書きで文字を書いたのは久しぶりです。
テストケースのテンプレートの用紙が配られた時に、班のメンバーと「うちの会社ではこういうフォーマットだよ」と話したのが各社で違いがあり印象的でした。
テストケースができたら、テスト実行です。
実際に動かせるアプリケーションが用意されていてびっくり！
テスト実行しながらテストケースに実行結果を記載し、不具合があったら不具合票に記載していきます。
最後にテスト完了です。
これまでやってきたことを踏まえ、リリースできるかできないかを判断します。
ほとんどのメンバーがリリースできると判断しましたが、リリースできない意見もあり「仕様から見直す必要がありそうな箇所がある」という理由にたしかに…！と思いました。
最終的には、ユーザーが一番解決したい課題は解決できるので、リリースしたほうが価値があるという判断を下しました。
ちなみに、パソコンを持ってきましたがワークショップではほとんど使わず、自分用のメモ取るときくらいしか使いませんでした。
発表
班ごとに以下を発表しました。
- テスト計画を考慮したテストの要否を考えたポイント、テストの優先度の理由
- テスト分析、設計、実装の一例
- リリースできる/できないの判断理由
- テストプロセス通りにやってみた気づき
班によってテストの内容が自分の班とは異なっていたりと興味深かったです。
特にテストプロセス通りにやってみた気づきとして「成果物が明らかになっているので作業しやすい」「休憩から戻ってきた後でも何をやっていたのかふりかえりやすい」という意見は非常に共感できました。
ワークショップを通して、以下の視点を今後、大切にしていきたいと思いました
- テストプロセスにおいて、前フェーズで使用したアウトプットを、後続フェーズでも活用する
- 前のフェーズのアウトプットが、次のフェーズでどう使われているかをきちんと追えるようにする
- 単にテストを作るのではなく、実際のユーザーの使い方や業務シーンを意識すること
ふりかえり
この２日間学んで、誰に何を伝えたいのかを各自書き出しました。
私は、「職場のチームメンバーに、テストプロセスにおけるアウトプットの大切さを伝える」としました。
班のメンバー以外の人と２人組になり、その内容を共有していきました。人に話すと自分が書いた内容がより頭に残って良いなと思いました。
招待講演
吉澤智美さんによる講演でした。
テストプロセスがどのように生まれたのかなどを中心にお話いただきました。
プロセスがうまく使えないと、今このプロセスでやってるからいいじゃんとなってしまい、変化への対応が遅れてしまう、といった内容は、現場でもありがちな気がしていて耳が痛かったです。
クロージング
ポジションペーパーの３つの賞の受賞者の発表がありました。
あと、景品として本が抽選でもらえるので当選者の発表もありました。
当選して「トヨタの片づけ」をいただきました！大切に読ませていただきます！
ふりかえりと学び
２日間とにかく楽しかったです！！
参加前は不安と緊張でいっぱいでしたが、飛び込んで本当によかったなと思いました。
- 悩みを相談しアドバイスもらえる場面が多かったこと
- 参加者同士でたくさんコミュニケーションができ刺激をもらえたこと
この２点が特に参加して良かったことです。
参加前に掲げていた目的が達成できたかふりかえってみると…
目的１：QAエンジニアとして自信を持てるようになりたい
全然自信持てなかった！！！笑
むしろ、わかった気になっていたけどできないことだらけで悔しいです！！！！
自分のできていないことが明らかになって危機感を持てたので、これを糧に自信をつけられるようできることをひとつずつ増やしていこうと思います。
目的２：社外の人と交流することで自分の立ち位置を見つめ直したい
これは達成できました。
交流の中で、「普段どんな業務をしているんですか？」という問いに詰まる自分に気づきました。
テスト活動らしい業務が少ないためイメージが付きにくいという部分はあるかもしれませんが、自分の業務の価値や目的を自分の言葉で説明できない状態だと痛感しました。伝えられない業務に、自分自身が意義を感じられるはずもないです。まずは「これは何のためにやっているのか」を明確にし、言語化することで、自分の業務の価値を取り戻していきたいです。
また、「テストっぽい活動が業務でできないからスキルが伸ばす機会がない」という考えも、今振り返るとただの言い訳だったと思います。スキルを磨く機会は、業務の中だけにあるわけではありません。身の回りのもの、たとえば使っているアプリやサービスや物を「どうテストするか？」という目で見る習慣をつけようと思いました。
参加を迷っている人へ
実はQAエンジニアになった3年前からWACATEの存在を知っていましたが、参加する勇気がありませんでした。
「（自分は年齢的にはそこまで若手ではないので）若い人ばかりだったらどうしよう」、「つよつよな人ばかりだったらどうしよう」という不安な気持ちがあったからです。
実際に参加してみると、幅広い年齢、バックグラウンドの方が参加していて、自分が不安に思っていたことなんて何一つ気にする必要なかったんだと思いました。
周りでも参加して良かった！という声をたくさん聞きました
迷っている方はぜひ参加してみてはいかがでしょうか？😊
最後に、実行委員の皆様、同じ班の皆様、関わってくださった皆様ありがとうございました！！！！
開発エンジニアからQAエンジニアになって3ヶ月の振り返り
2023年4月時点で、QAエンジニアにジョブチェンジして3ヶ月が経ちました。その際、会社のブログで「バックエンドエンジニアからQAエンジニアになって3ヶ月でやったこと」的なブログを書きました。
改めて振り返りをしたいのと、もう少し個人の思い的な部分も残しておきたく、個人ブログにも書こうと思います。
なぜQAエンジニアになったのか
開発エンジニアとして今の勤め先にジョインしたのですが、以下の課題を感じていました。
- 10年以上続いているサービスなのに仕様に関するドキュメントなどがあまり残っておらず、既存仕様の調査に多くの時間がかかりスムーズに開発できない
- QAエンジニアがおらずプロジェクトメンバーで集まり動作確認する会を開発完了後のテストとしており、「テストは十分だっただろうか」と不安を感じた
- 上記のことなどもありチームメンバーが伸び伸びと働けていない部分もあるように感じ、チームが安心して働ける環境を作りたいと思った
そんなモヤモヤを抱えている中、QAエンジニアに興味を持った出来事が二つありました。
ひとつめは、知人の開発エンジニアと話していた時に「QAエンジニアがチームにいた時は開発がしやすかった」という話が出たことです。私はこれがきっかけでQAエンジニアという仕事を知りました。
ふたつめは、開発エンジニアとして参加した社外勉強会にQAエンジニアの方が登壇していたことです。その方の話を聞き"Three Amigos"という考えを知り、自分はどういう立場でプロダクト作りに関わりたいのか改めて考え直そうと思いました。
これらの出来事を受けQAの仕事について調べていくうちに「QAの活動は、企画職/開発職などプロダクトに関わるメンバーがよりプロダクトに向きあいやすくなることに、繋がるかも」と感じました。
また、以下のような自分の価値観ともマッチするかもと思いました。
- 様々な人と話し合いながら物事をチームで進めたい
- 自分の業務に線引きをしすぎず、自分のできることはなんでもやっていきたい。そのため要件検討の段階からリリース前のテストまで幅広い開発工程に関わりたい。
このような経緯で「開発に関わるメンバーが安心して素早くユーザーに価値ある製品を届けるサポートがしたい」と思いQAエンジニアになりました。
QAエンジニアになって3ヶ月で取り組んだこと
弊社では主に２つのプロダクトがあり、開発エンジニアとして携わっていたプロダクトとは別プロダクトのチームにQAとしてジョインすることになりました。
私がQAエンジニアにジョブチェンジする少し前に、弊社に１人目のQAエンジニアがジョインしていたのでメンターとしてついてもらいました。
既存テストケースの実行
まずは既存テストケースを全て実行することから始めました。
テストケース実行を通して得られたこととしては、
- ざっくりと仕様を把握することができた。また、全体のボリュームが掴めた。
- テストケースをどのように作っているのかぼんやり把握することができた。
- 不具合時の報告方法(チケットの起票方法)など、チームのルールを把握できた。
- テストケース管理ツールに慣れることができた。(Qaseというツールを使っているのですが、シンプルで直感的に使えて良かったです)
などが挙げられます。 個人的にはテストケースの実行から始めることは、最初の一歩としてのハードルが低く業務のイメージもつきやすく非常に良かったです。
他社さんがどのようにQAのオンボーディングを進めているのかとても興味があります。
テストプロセスを一通り経験
次に開発案件を通して、テストプロセスを一通り経験しました。
特に難しく感じたのは、「仕様書のレビュー」と「テストケースの作成」です。
弊社では、要件定義段階からQAチームが参画し、プロジェクトオーナーが書いた仕様書をレビューします。 例えば、誤字脱字のチェック、既存仕様との矛盾のチェック、よりユーザーが使いやすくなるような提案などを行っています。 最初の頃は、開発エンジニアの時の習慣が抜けず「どうやったらシステムとして実現できるか？」と考えがちでした。しかし、それ以前に「その仕様で本当にユーザーの課題を解決できるか」という目線を持つことが必要だなと感じました。
レビュー観点を広げる方法として、モブ作業を行って他のメンバーの観点を盗み身につけるということをしました。 具体的には、仕様書をレビューするときにslackハドルなどで画面共有しながら、お互いに気になった箇所を述べていくということをしました。その際に、「なぜそこが気になったのか」「なぜその考えに至ったのか」などを聞くようにしました。 そのおかげで、自分では気が付かなった指摘事項に関しても、導き出し方がわかるようになりよりレビュー観点が広がりました。
テストケースの作成に関しては、誰が見ても何をしたいかテストの意図がわかるものにすることが非常に難しいなと今でも頭を悩ませています。開発エンジニアをしていた時に、「自分の書いたコードをしばらく経ってから見返すとわからない」という事象に直面することが何度かありましたが、自然言語で記入しているテストケースでも同じことが起きるんだなと思いました。
わかりにくくなる理由としては、暗黙知が含まれていることなどが考えられると思いました。なので、他の人にテストケースをレビューしてもらい、暗黙知の排除につとめました。
また、社外の勉強会でテストケースの作成に関わるものがあれば積極的に参加しました。 特に、JaSST’23 Tokyoでのテスト設計コンテスト U-30クラスのセッションは、テスト設計とはこんなに奥が深いものなのかと感銘を受けたのを今でも覚えています。
３ヶ月で得たこと・今後やっていきたいこと
個人としての一番の成果は、QAとしてテストプロセスを一通り経験できたことだと思っています。 ただ、プロセスの各工程をさらに深掘りしていく必要があります(特にテスト設計など)。また、幅広いテストタイプに対応できるようになりたいですし、今はシステムテスト(E2Eテスト)を主に担当していますが他のテストレベルの知識も身につけていきたいと考えております。 学べることが無限に広がっていてわくわくしますね。
チームの成果としては、QAチームに人が増えたことでライブラリアップデート・リファクタ時などにリグレッションテストを実施できるようになったことかと思っております。 しかし、実行に時間がかなりかかっており、素早いデプロイのボトルネックになっているように感じます。必要な部分はテストを自動化するなりして、質とスピードを担保していきたいです。 （※2023年10月現在 自動化ツールを導入してチームで進めることになったので、実現したいこと第一歩は達成）
