ID:75750さん

外部仕様が複雑なドメインに再チャレンジして、品質保証業務の質を磨き、要件整理から運用まで円滑な進行により大きく貢献できるようになる

# 背景 - 今まで経験した業務の中で「分析的な工程で複雑なシステムの全体像とそれを構成する要素同士の関係を深く理解し、曖昧な仕様を整理したり、良いアイデアがないか検討したり試行錯誤できる業務（※1）」へのモチベーションが特に高いと考えている - 分析的な工程：全体像を把握→要素や仕組みの詳細を整理・分析→異なる視点・多角的な視点で見直し、全体と部分の関係を再評価する - 自動車という複雑な製品に対するテスト全般の業務、Webモバイルで要件整理〜運用まで広く全体に関わった経験を踏まえ、複雑な製品に対しての品質保証に再度チャレンジし、そこに閉じずにプロジェクトの円滑な進行のためにできることも増やしたい # ※1 具体例 ## テスト分析（仕様ベース） ### プロセス 1. 仕様の全体像を把握 2. 対象を要素ごとに分解し、詳細を理解・整理 3. 他機能との連携や関係性、開発の目的に立ち返り、仕様を再評価 ### アウトプット - 仕様の改善提案 - 要件検討時の考慮漏れの指摘 - UX向上の提案 - より低コストでUXを維持できる代替案 - 整理した情報（テスト設計のインプットとして活用可能） ## テスト分析（開発内容ベース） ### プロセス 1. 開発内容を確認 2. 動作の仕組みを理解 3. 開発・修正の背景に立ち返り、挙動を再評価 ### アウトプット - 要求を満たしていることの証跡 - 要求の再確認 - 明記されていないが、要求の可能性がある事項の共有 - 要求外の変化に伴うリスクの共有と、次の方針の合意 ## E2Eのトラブルシューティング（要素指定で希望の要素が取得できない場合） ### プロセス 1. さまざまなオプションを試し、取得できない原因を特定 2. 取得方法が見つかった場合はその理由を分析し、安定性を確認 3. 方法が見つからない場合や複雑な場合は、テストの目的を見直し、別の手順への置き換えを検討 ### アウトプット - 安定してテストの目的を十分に満たすテストコード - 必要最小限でありながら、E2Eとしての役割を十分に果たすテストケース ## 車載システムの検証環境の構築やトラブルシューティング ### プロセス 1. 基本的な検証環境の構築方法や動作の仕組みを理解 2. さまざまな検証やトラブルシューティングを通じて経験を積み、各機材の使い方や理解を深める **使用機材例:** 数種類のロガー・電流測定用テスター・特定の信号や電圧のみを対象にする/除外するための治具・他の車載システムを模擬する機材・基地局シミュレーター ### アウトプット - 初めて使用する車両や検証環境における環境構築 - テストの目的を満たし、正しくログが取得できる環境構築、トラブルシューティング