【ゴールデンウィーク営業のお知らせ】
2025年4月29日(火)～2025年5月6日（火）の期間を休業とさせていただきます。
※4月30日（水）、5月1日(木)、2日(金)は通常営業いたします。
※休業期間中にいただいた審査申請については、結果をお返しするために数営業日いただくことをご了承ください。
エンジニアとして幅広い領域に挑戦しプロダクトの成功に寄与したい
プロダクトの成功には各領域の専門知識が必要と感じている為です。
現在主軸としているフロントエンドに加え、現在の業務ではあまり携われていないバックエンド、インフラの様々なアーキテクチャを経験し、最適な技術選定、提案、実装ができるエンジニアになることが目標です。
フロントエンドのリーダーとして下記を担当
・既存コードの改修
・コーディング規約の整理
・ESLint、Prettier、huskyによるルールの強制
参画した際のプロジェクトはTypeScriptを使用しているものの、携わってきたメンバーが多い上にルールが緩く半分程はJavaScriptで書かれている状態だった。
型安全な開発が出来ていないことで下記の課題が生じていた。
・コードリーディングに時間がかかり保守性の低下
・バグ発生による修正、テスト工数増
・仕様変更に対する修正工数が大きい
まずはany型の排除を行うことで既存コードの保守性の向上に取り組む
コーディング規約を作成し、メンバーに周知するがメンバーの入れ替わりも多く、浸透させるのに苦労した。
そこでESLint、Prettierのルールを見直し、エディター上で明確に規約違反を確認出来るようにし、違反があった際にはhuskyでコミット出来ないよう強制することでTypeScript化の推進を行った。
TypeScript化することにより、前途の課題の解決に加え、ドキュメンテーションの役割も果たし仕様の確認工数の削減にも繋がった。
Jestによる自動テスト実施
これまで社内でフロントエンドの自動テストを導入した実績がなく、本プロジェクトは初の導入となった。
技術調査を行い、今後のプロジェクトにも流用出来るよう実績を作った。
他のプロジェクトでも流用出来るよう、まずはログイン画面から最低限のテストコードを作成
次に本プロジェクトで手動でのテスト工数が大きい下記3点の自動テストを作成した。
開始当初、何に対してのテストを作成するのかを明確にしておらず、調査結果に基づいて五月雨でテストを作成していた為、全てのテストを作成するには工数が追いつかない状態になっていた。
その為、手動テストにおける工数が大きく自動化する恩恵が大きいものからテストコードを作成。
表示文言の確認、イベント発火等の手動でも工数が小さいテストに関しては手動で実施するといった取捨選択を行った。
まず何に対してのテストを自動化するのかを明確にすべきという教訓となった。
人の手によるテスト工数の削減。
特にバリデーションテストは一度作成すれば仕様変更があっても元のコードとテストコードを一緒に修正するだけで品質を担保できるようになりテスターの負担を大きく削減することになった。
開発チーム
週単位のリリースに向けて開発、テストまでを完遂する責務があります。
リリース日から逆算し、下記を管理しています。
①タスクの精査/割り振り
▪️問題点
・顧客要望が大量にあり、Backlogへタスク化する作業に膨大な時間がかかっていた
▪️工夫したこと
・Backlogへインポート用のスプレッドシートを作成し一括でのタスク化を実現
②開発完了目標日の設定
▪️問題点
・テスト期間を明確に考慮せずに開発を進めていたことによりリリース直前にバグ修正が重なりメンバーの負担となる事案が発生していた。
▪️工夫したこと
・明確に開発完了期間、テスト実施期間を設定することで現実的なラインでの開発期間を設定することが出来た。
上記により個々のスケジュールの進捗の管理が容易になり残業時間などのコントロールが上手く回るようになった。
③テスト実施
▪️問題点
・テスト仕様書の整備が追いついていない状態により、打鍵者任せのテストになっており品質に問題があった。
・入力チェックテストなど、バリエーションを要するテストに時間を取られていた。
▪️工夫したこと
・ドメイン知識の深いメンバーによりテスト仕様書を作成。タスク精査の段階でテスト仕様書を更新し誰が打鍵しても品質に差が出ないよう取り組む。
・Jestを用いた入力チェックテストを実施することで工数の削減に加え品質の向上/デグレ防止を実現した
1.フロントエンドのパフォーマンス、品質向上に関わる知見
2.DB設計やバックエンド開発言語の取得
3.AWSを中心としたインフラ周りのアーキテクチャ設計の知見