kmiki220

・テスト 3,000円〜

新卒から一貫してテストを担当しています。 「大規模で複雑かつ命に関わるため、安全重視の自動車製品」と「価値あるプロダクトを早く届けることを重視するWeb・モバイルアプリ」のテスト業務経験があります。 前者ではトレーサビリティの取れたドキュメント作成、テスト計画やテストケースのレビューを丁寧に実施、後者ではテスト自動化や要件定義で不具合を作り込まない活動など取り組みの幅を広げてきました。

・転職・キャリア相談 1,500円〜

3回の転職経験があり、受託系・メガベンチャー・スタートアップなど幅広い企業での就業経験があります。転職、キャリアのお悩みや気になることについて、今までの経験からお力添えできそうなことがあればご相談いただけますと幸いです。

・コネクティッドカー向けの車載通信機（DCM）第三者検証 / リーダー / QAエンジニア 2019年4月 〜 2021年8月

# プロダクト コネクティッドカー向けの車載通信機（DCM）を担当 クライアントは大手自動車部品メーカーで、第三者検証として参画 # 組織 - PJ全体 約60人 (QAの請負メンバーのみ) - チーム　2～5人 # 参画時の状況と役割 - 2年以上の大規模プロジェクトで、実車試験を主に担当するチームに所属 - 2~5名のチームリーダー（2020/9～2021/8） # 開発環境 - ミドル・SW - Tomcat、VMware、IIS - 通信プロトコル - TCP/IP、USB、CAN # リード・主体的に取り組んだこと ## 実車試験で使用するテストケースを0から作成 ## チームリーダー業務 - テスト計画 / 設計の顧客レビューで説明を担当。また、工数管理、スケジュール調整、顧客との窓口や関連会社とのやり取りなどを担当。顧客から評価を受け、メンバーを1名増員することができた ## 実車環境、基地局シミュレーターを使った模擬環境構築 - ネットワークや複雑なドメインの知識が必要なテスト環境構築のトラブルシューティングや教育を担当 ## 周知事項の確認状況の見える化 - 国内外に複数拠点があり、テストに関連する重要な内容がメールや口頭での連絡に留まっており、把握できていない拠点があった - メンバーは内容を確認し、不明点が無ければタスク管理ツール上の自分の名前にチェックを入れる「周知事項の確認状況が見える」場をRedmine上に作成 - 質問がある時はツール上でオープンに問い合わせることで、同じ質問が来ることが減った - リーダー層は「どの拠点が見ていないか」が一目で分かるようになり、フォローがしやすくなった # 工夫した点 ## リーダー業務で以下を意識した - 「指示が無くても積極的に自ら行動してくれること」をよく観察し、ただ空いている人を割り当てるのではなく、できるだけ個人の強みを伸ばせる業務にアサイン - 相手から言葉を引き出し、自分の考えを言い切れる雰囲気づくりなど、「コーチングを意識したコミュニケーション」を心掛けた ## 「周知事項の確認状況が見える」場の作成では以下を意識した - 過去に起きた失敗から「継続して使われる」、「本質的な原因の解決に繋がること」を重要視。 - 具体的には「国内外の約60名のメンバーにとって大きな負担にならない」、「双方向のコミュニケーションの場にすることでお互いに責任を持つ」を方針にした - すぐには浸透しなかったが、根気強く呼びかけたことで周知事項がある場合にはその場を使うことが共通認識となった

・大企業向けの人事管理Saas「Teamspirit EX」工数管理機能開発 / QAエンジニア 2021年9月 〜 2022年5月

# プロダクト 大企業向けの人事管理Saas「Teamspirit EX」を担当 工数管理機能を開発するスクラムチームに所属 # 組織 - スクラムチーム　8人 プロダクトオーナー:2、エンジニアリングマネージャー:1、エンジニア:3、QA:2 - QAチーム　13人 日本：7人、SG：6人 # 参画時の状況と役割 - 工数管理機能の2人目のQAとして参画 # リード・主体的に取り組んだこと ## シンガポールのQAチームとの連携 - リリース前に行う全体的なテストは日本とシンガポールの開発メンバーで実施するため、その取りまとめを担当 ## QAチームでテストの進め方や観点を共有する会を開催 - 同じQAエンジニアでもプロジェクトが異なるため、お互いの知見が共有されないことへの課題感や、違う視点から見るといい解決策が見つかる可能性もあると考えてマネージャーに提案して実施 - チームごとの課題感や取り組みについて意見交換することができた - ただ、明確に業務上の課題があったわけではなかったので、業務上の成果というよりはお互いの共通認識が増える会になったと考えている ## 手動リグレッションテストの実施効率の改善 - 新機能開発後、新しいテストケースがただ表の下に追加されていくだけの状況だった。上から順に実施していくと機能を行き来することになり、実施効率に課題があった。 - 全体的なリグレッションテストが定期的にあるプロジェクトでテストの頻度が多い状況だった - 同じ機能は固めて実施できるように整理し、テストケースを追加する際のルールを追加した ## UIのE2Eテスト自動化（Autify）やAPIテスト実装 - どちらも未経験でGitも使ったことがない状況だったが、知見のある方に積極的に吸収しに行き、簡単な実装が1人称でできるようになった # そのほかに取り組んだこと - テスト観点表の改善、メンテナンスの運用ルール決め # 工夫した点 - 初めてのスクラム開発で慣れないことが多かったが、意見が合わない時は「一番懸念していること」を話し合い、腹落ちできるコミュニケーションを意識した - シンガポール側とも英語、主にチャットで密にコミュニケーションを取り、情報格差が生まれないように心がけた

・ネットショップ「メルカリShops」のQA 2022年5月 〜 2023年1月

# プロダクト ネットショップ「メルカリShops」を担当 アプリ（Webview）や社内のマーケティング- CS部門が使用するツールの開発を行うスクラムチームに所属 # 組織 - スクラムチーム　11人 プロダクトオーナー:2、エンジニアリングマネージャー:2、エンジニア:6、QA:1 - QAチーム　5人 # 役割 - ネットショップ「メルカリShops」や社内のマーケティング- CS部門が使用するツールのQAとして参画 # リード・主体的に取り組んだこと ## 自動テストのカバレッジ定義 - 自動テストについて、カバレッジが定義されておらず、闇雲に自動化を進めている状況だった。カバレッジの定義作成を担当し、QAチームに提案（結果的に提案したものよりは小さい粒度で始めることになった） - 提案したカバレッジ 　 ①Cypressで自動化済ケース数 / 自動化用 全テストケース数 　　 目的：自動化の網羅率を示すこと 　 ②自動化用テストケース数 / スモークテストとして必要なケース数 　　 目的：①の分母（自動化用テストケース数）の妥当性を示すこと - 最終的なカバレッジ 　 画面単位でのカバレッジ - その後、テスト実装を2名で推進し、分担をしながら進めて約4ヶ月でカバレッジを50→90%に上げることができた ## 軽微なプロダクト改修を実施 - 簡単な実装についてエンジニアに教えてもらう機会があり、画面上の文言修正などの軽微なバグは、バグ報告ではなく自分で修正のPull Requestを作成 # 工夫した点・業務を通じて意識した点 - 自動テストのカバレッジで考えた案とは別の案で進むことになった。かなり時間をかけて綿密なカバレッジを考えてしまい、時間をかけすぎず相談することと、（十分に目的が満たせるなら）なるべく負担が少なく始められる方法の検討を意識している - 複数の機能が平行して開発されていたため、スピードを落とさずにリリースできるように各機能のビジネス優先度やテストの複雑さを事前に整理した上で、テスト分析など準備を早めに始めた - 「考えすぎる時がある」という自分の弱みを理解し、小さなことでも質問するように強く意識し、試用期間が終わるタイミングではマネージャーから「スクラムチームでの信用を得られている」との評価をいただいた - 仕様へのフィードバックでは以下のようなコミュニケーションを意識 - 仕様に対しての指摘だけでなく「ドキュメントを修正しても良いか」などスムーズで前向きなコミュニケーション - 適切なタイミング・粒度でのレビュー（仕様が荒い段階から細かすぎる指摘をしない、など）

・コミュニティサクセスプラットフォーム「commune」のモバイルアプリ開発 / QAエンジニア 2023年2月 〜 2026年8月

# 参画した時の状況と役割 - アプリチーム立ち上げから約半年の時に参画し、主に1人でアプリチームのQA業務全般を担当 - 2025年12月より、Webを含めたQAチームの窓口（正式な役職はないが実質的なリーダー）を担当 # リード・主体的に取り組んだこと ## QAチームの窓口を担当 - 組織変更があり、QAチームの窓口(実質的なリーダー)を担当することになった。 - チームメンバー数の変更がある中で、まずは「既存の業務を今までより少ない人数で回してリリースを止めないようにすること」を大目標として設定し、月ごとに段階をつけて目標とする状態を決めた。 - また、メンバーの現状のタスクの割合などのヒアリングやお互いの業務の引き継ぎなどの具体的な目標達成に向けた進め方を主体的に決め、ドキュメント作成等を実施した。 ## E2Eテスト ### ①モバイルアプリ・maestroの導入とテストの責務の整理 - E2E導入の効果の有無を判断するために、「過去のデグレがE2Eで検出できるものか」、「E2Eで代替できるリグレッションテストの工数」を調べて、効果が出る仮説を事前に検証 - E2Eテストを戦略的に進めるために、テストするべき内容を自然言語のテストケースにして、優先順位をつけて対応 - エンジニアと協力しながら進め、個人でもテストコードの実装、要素指定のためのSemantics Nodeの切り出し、PR作成まで担当 - 2026/4現在、モバイルアプリ全体の各テスト観点に対して、自動・手動テストの責務を2軸（実機検証の必要性・自動化適正）で整理し、自動テストカバレッジ向上と手動テストを戦略的に扱えるような仕組みの構築を推進中 ### ②Web・MagicPodの基盤の構築・最適化（200万円/年のコスト削減を実現） - 目標時間（10分）以内の完了のために必要な並列実行用のクラウド実行端末の見積もりをリードした - 前任者から引き継ぎ、数百件のテストケースが作成済みだがリリース前のCIでの実行時に作成済みのテストを載せられていない状況だった - 全体のテストケース数（直近3~6ヶ月で増える数も追加）、1ケースあたりの平均実行時間、クラウド実行端末の起動時間の除外などを考慮し1台あたりで純粋なテスト実行に使える時間、などの数値を整理して必要な台数を算出し、並列実行端末の準備を完了させた - また、全件並列実行ではインフラ負荷によるテスト失敗が判明。コスト面も踏まえてテスト戦略を見直し、CIでは重要テストに絞り、それ以外はDaily実行に切り替えることでコストと品質を両立した。 ## シフトレフトでプロジェクトの円滑な進行に貢献 - 仕様検討段階から参画し、考慮漏れや既存仕様との不整合を早期に発見・解消することで、手戻りの防止に貢献 - 目的・背景の曖昧な仕様に対し、関係者ヒアリングと要件整理を主導。手戻りリスクを早期に排除 - ただ仕様通りのテストをするだけでなく、機能を作る背景を理解した上で仕様書に記載がない点も含めて機能が要求を満たすのかを確認 - 機能開発や不具合修正で仕様に対する改善提案がある場合は、要件を整理→期待挙動の案とその理由を提案。サービス・モバイルアプリとしての体験をPdMと議論しながら進めた ## 性能テストの指標策定 - 機能の重要度やページの閲覧数上位などを参考にテストの対象を策定 - エンジニアと協力して、CPUやメモリなどの実際に測定する指標と具体的な値を策定 - XcodeやAndroid Studio、Flutter Dev Toolsを使用して性能測定を実施 - 今後のテストでの運用ルールを作成 ## 属人化・ドキュメント不備が常態化したプロジェクト引き継ぎを単独でリード 月2〜4件発生するオリジナルアプリ作成案件において、主要担当者の離脱とマニュアル不備が重なり、引き継ぎが困難な状況が発生。唯一ドメイン知識を持つメンバーとして、既存ドキュメントの精査・当時の実装担当者へのヒアリング・運用チームへの状況共有・方針策定を主体的に推進し、ドキュメントの整備の完了までやり切った ## JIRAを使った開発状況の定義や見える化 リアルタイムで開発状況が更新される仕組みを構築。具体的にはオートメーション機能でPull Requestがマージされた時点でJIRAチケットのステータスが自動で遷移する、など。導入から2年以上経過した現在もこのワークフローをベースに開発を進めている ## 開発視点を活用したテストスコープ精度の向上 - Pull Requestの修正内容を確認して、影響範囲の情報をインプットしてテストに活用 - 要件に記載のない範囲のファイル修正がないか確認。逆に限定的な場合はピンポイントでのテストのみ実施 - GithubのBlame機能を使って、修正箇所が実装された過去の経緯を確認した上でテストを考え、デグレを検出 - ブランチ戦略の理解 - ブランチの状態を意識したテストやリリース内容の確認、E2Eの実施タイミングの提案などを実施 ## スマホ検証端末の選定から稟議- 購入 - サポートしているOSバージョンが5~6バージョンあるため、多端末での検証が必要な状況。端末の揃え方の方針として仮想環境と実機の2つを検討し、テスト面での制約やコストを比較して実機を選定 - 中古で端末購入する場合、何点か考慮が必要。(端末のOSバージョンは事前に分からない・使用予定のSIM提供会社と相性の良い端末かどうか、など) 。情報を整理して、検証したいOSバージョンで確実に検証でき、かつコストが小さくなるように機種選びを進めた # そのほかに取り組んだこと - 不具合や障害の分析、人に依存しない対策の検討 - 新規参入者の仕様面の理解のフォロー - アプリチームの開発フロー- テストのフローのドキュメント化 - ポストモーテムの運用管理 # 工夫した点 - 理想的な体験の追求と実装上の制約やリソースのバランスを取って優先度を議論して進めるように心がけた - ビジネス側のメンバーへ影響を適切に周知する必要がある場合（不具合を許容する際など）は、他部門への信頼関係