システムの全体像や仕組みの理解を深め、技術的な課題に対して自分の手を動かしながら解決までを主導できる役割を担いたい
# 背景 - 今まで経験した業務の中で「分析的な工程で複雑なシステムの全体像とそれを構成する要素同士の関係を深く理解し、良いアイデアがないか検討したり試行錯誤できる業務（※1）」へのモチベーションが特に高いと考えている - 分析的な工程：全体像を把握→要素や仕組みの詳細を整理・分析→異なる視点・多角的な視点で見直し、全体と部分の関係を再評価する - 久しぶりにE2Eに取り組む機会があり、上記のような業務へのモチベーションの高さを再認識 - 何かを読み解いたり評価するだけでなく、E2Eや環境構築のように「試行錯誤しながら、一から何かを作っている」という感覚を持つことに強くやりがいを感じると気付いた - ここ1,2年で苦手なことに前向きに取り組む考え方にも向き合ってきたので、そういったことも取り組みながら、「好きこそ物の上手なれ」の考え方で熱量が高い業務の幅を広げたい # 興味 - Devops, インフラなどの分野でのキャリアに興味があり、学習を進めている - 基礎知識（Linux、ネットワーク、フロントエンド・バックエンドなど） # ※1 具体例 ## テスト分析（仕様ベース） ### プロセス 1. 仕様の全体像を把握 2. 対象を要素ごとに分解し、詳細を理解・整理 3. 他機能との連携や関係性、開発の目的に立ち返り、仕様を再評価 ### アウトプット - 仕様の改善提案 - 要件検討時の考慮漏れの指摘 - UX向上の提案 - より低コストでUXを維持できる代替案 - 整理した情報（テスト設計のインプットとして活用可能） ## テスト分析（開発内容ベース） ### プロセス 1. 開発内容を確認 2. 動作の仕組みを理解 3. 開発・修正の背景に立ち返り、挙動を再評価 ### アウトプット - 要求を満たしていることの証跡 - 要求の再確認 - 明記されていないが、要求の可能性がある事項の共有 - 要求外の変化に伴うリスクの共有と、次の方針の合意 ## E2Eのトラブルシューティング（要素指定で希望の要素が取得できない場合） ### プロセス 1. さまざまなオプションを試し、取得できない原因を特定 2. 取得方法が見つかった場合はその理由を分析し、安定性を確認 3. 方法が見つからない場合や複雑な場合は、テストの目的を見直し、別の手順への置き換えを検討 ### アウトプット - 安定してテストの目的を十分に満たすテストコード - 必要最小限でありながら、E2Eとしての役割を十分に果たすテストケース ## 車載システムの検証環境の構築やトラブルシューティング ### プロセス 1. 基本的な検証環境の構築方法や動作の仕組みを理解 2. さまざまな検証やトラブルシューティングを通じて経験を積み、各機材の使い方や理解を深める **使用機材例:** 数種類のロガー・電流測定用テスター・特定の信号や電圧のみを対象にする/除外するための治具・他の車載システムを模擬する機材・基地局シミュレーター ### アウトプット - 初めて使用する車両や検証環境における環境構築 - テストの目的を満たし、正しくログが取得できる環境構築、トラブルシューティング
要望、不具合報告、使いづらい点や感想など、お気軽にお寄せください。
いただいたご意見は、今後のサービス向上に活用させていただきます。
なお、このフォームは受付専用のため、返信を行っておりません。
返信を希望する場合はお問い合わせよりご連絡ください。