Ryota Sato

✅ 1. 概要 新入社員向けの技術研修のメンターを担当しました。 別プロジェクトの開発業務と並行して、社内でメインで利用する Scala, Playframework のメンターとして、これまで 4名の新入社員に対して、技術指導や 1on1 を実施しておりました。 ✅ 2. 課題とそれに対しての取り組み 設立から間もない会社であったため、研修体制が整い切っておらず、環境構築用のリポジトリしかない状況だったため、研修を受けるメンバーにとっては情報が少なすぎて、研修を進めることが難しい状況でした。 そのため、私が研修メンターを任された際には、自分がこれまで躓いてしまった部分を解決するための解説を作成したり、研修のステップを段階に分けて明確に定義することで、できる限りスムーズに研修を進められる環境を整備しました。 また、バックエンドの研修資料しかなかったため、フロントエンド（Angular）のリポジトリ作成やドキュメントの作成なども実施しました。 ✅ 3. 評価されたポイント 自分がこれまで技術的につまづいてきたこと、学習の方向性で悩んで解決できたことを全部伝えられるように、こまめに社内ドキュメントを更新し続けてきました。 また、初めて 1on1 を実施する立場となったため、どうしたら限られた時間の中でメンティーの成長に１ミリでも貢献できるかを考え、隔週で対面の 1on1 の時間を設定し、傾聴することを第一に取り組んできました。 １人１人に向き合って対話・サポートする姿勢を評価いただき、人事の方にもメンターとしての活動に対して最高評価をいただきました。

※現在進行中のプロジェクトのため随時、追記していきます ✅ 1. 概要 高速バス運営会社がサイトのフルリニューアルをして展開する、簡単に高速バスのチケットを予約できる toC向けのオンラインプラットフォームの開発 某高速バス運営会社の依頼により、チケット販売サイト（Webアプリケーション）を０から開発し、2023年7月にローンチ予定 データベースの設計やアプリケーションの基盤構築などのシステム設計、フロントエンド・バックエンドの開発、システムテストの実施・改修など、立ち上げメンバーとしてフルスタックに携わった **【案件に参画した時の想い】** 社内での開発体制を調整するにあたり、各人が案件を選べる状況となったときに、真っ先に新規開発のこのプロジェクトを選択しました。 理由としては、これまで保守案件は担当してきたものの、新規案件の開発経験がなかったため、0から1を生み出すフェーズを経験してサービスを世に作り出したい！と思い、自ら手を挙げてこのプロジェクトに決めました。 当時の上司からは、新規案件は保守案件と違って既存コードがないため難易度が高く、初期に参画したエンジニアのコードがプロジェクトに多大な影響を与えるため覚悟してほしい。と強く指摘を受けたものの、変化を恐れず新しいことに挑戦し続けたい。厳しい状況の環境こそ自己成長の機会につながるはず。という思いがあったため、全力で臨むことに決めました。 ✅ 2. チーム構成 日本側開発メンバーとしてプロジェクトに参画し、他の開発メンバーのタスク管理やコードレビューなども担当した。 - PM 1名 - 日本側テックリード 1名 - 日本側開発メンバー 3名 - ベトナム側開発メンバー 3名 - コミュニケータ 1名 - デザイナー 2名（外注） - QAエンジニア 2名（外注） ✅ 3. 使用技術 プロジェクトでの使用技術は以下の通りです。 自身の担当としては、主にフロントエンドとバックエンドを使用しました。 - フロントエンド：HTML, SCSS, TypeScript, Angular(14.2.4), jQuery - バックエンド：Scala(2.12.17), Playframework(2.8.19) - データベース：MySQL, Slick - インフラ：AWS（EC2, Lambda, S3, DynamoDB, RDS, ECS, ECR, OpenSearch Service 等） - IaC：Terraform - 仮想化基盤：Docker - CI/CD：GitHub Actions - 検索エンジン・ライブラリ：Elasticsearch, elastic4s - プロジェクト管理：JIRA, instagantt - ドキュメント管理：Confluence - ソースコード管理：Git, GitHub - デザインツール：Figma - コミュニケーションツール：Slack, Google Meet ✅ 4. 業務上の貢献・工夫した点 ## 4-1. 外部API連携 **【課題】** PDFにまとめられた外部API仕様書が非常にわかりづらく、GETリクエストとPOSTリクエストをそれぞれ処理する必要があったため、どの粒度でメソッドを抽象化すれば適切なのかを検討することがひとつの課題だった **【取り組み・工夫した点】** - リクエスト・レスポンスのすべての項目を洗い出し、どのDBの変数と突合させるのか関連性を把握しやすいように、スプレッドシートに可視化した。 - Scala での 非同期HTTPリクエストの処理は、Playframework の WSClient を利用して共通基盤を構築し、API の各機能ごとに適切なパラメータでリクエストを送れるように実装した - 何を示すデータか理解しやすいように、リクエスト・レスポンスで処理するすべてのJSONモデルに型定義を実施した。 ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー ## 4-2. DB設計 **【課題】** DB設計に着手したプロジェクト初期の段階では、要件が確定し切っておらず、要件定義・デザインの認識すり合わせと同時並行で進める必要があった。 **【取り組み・工夫した点】** 上記課題があったため、下記の取り組みを実施した。 - 先方とのステアリングコミッティに議事録担当として参加させてもらい、ドメイン知識へのキャッチアップを行なった。 - デザインに影響される可能性が少ないであろう、都道府県情報やユーザー情報などの不変な情報から設計を進めていった。 **【改善点】** - 外部APIから取得するデータを元に開発が進んでいたので、先にプロジェクトの核となる外部API の仕様を詰めて設計を進めたほうが効率的だった。 - DBやSQL、Slickの理解を深めて、インデックスの最適化や正規化の適用などを実施できるようにしていきたい。 ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー ## 4-3. バス検索UI のロジック修正 **【課題】** バックエンドを elastic4s（Elasticsearch の Scalaクライアントライブラリ）、フロントエンドを Angular Elements で実装された検索UI で、検索条件をいれたときにリアルタイムに検索ヒット件数が反映されない不具合が発生した。 **【取り組み・工夫した点】** - 出発地・到着地・詳細条件などの検索条件を定義している検索クエリーの構築処理を調査し、検索条件の反映漏れがないように一部修正を行なった - それに伴い、Angular 側で検索条件にヒットした件数を取得するメソッドを再定義し、UI に反映するようにした ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー ## 4-4. フロントエンドの機能実装 - 登録者情報変更フォームの実装 - jQuery Validation プラグインでバリデーションを対応 - 各フォームに適切なエラーメッセージの定義やルール設定などを実装 - Playframework の CSRF Filter で CSRF対策 - views 側に formField の定義、controller 側に CSRF フィルタリングを適用 - 画像データ遅延読み込み対応の実装 - jQuery プラグイン Lazy Load を利用 - 遅延読み込みさせたい画像の imgタグのclassには `lazyload` を入れる必要があったため、Playframework Twirl で img タグの共通コンポーネントを定義・利用することで、class の入れ忘れ防止を行なった。 - カルーセル機能の実装 - jQuery プラグイン lightSlider を利用 - 軽量かつシンプルで扱いやすいカルーセルプラグインだったが、リロード時に一瞬カルーセルの画像すべて表示させる不自然な挙動が発生していた - アクティブに表示させる画像以外は非表示となるように、jQuery と css で調整を行なった。 ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー ## 4-5. テックリードの負担軽減による開発促進支援 **【課題】** これまで、開発メンバーのマネジメントや要件定義・設計・インフラ構築・開発などのほぼ全ての工程をテックリードが管理している状況だった。 テックリード自身も重めのタスクを担当しなければ開発が進まない状況下で、開発が遅延し続けていった結果、納期までに完了できずに炎上してしまう事態にまで発展してしまっていた。 **【取り組み・工夫した点】** 上記課題を解決するために以下の取り組みを実施した。 - **一部の開発メンバーのタスク管理やコードレビュー** これまで全てのタスク管理やコードレビューをテックリードが担当していたが、役割分担を提案し、一次コードレビューを私が請け負うことによって、開発メンバーの管理コストを分散できた。 - **開発に関わるドキュメントの作成（環境構築手順書、議事録など）** 先方や社内での定例MTGで必ず議事録を作成したり、追加でアサインされるメンバーがキャッチアップしやすいように、環境構築手順書やREADMEの整備、その他ドキュメントをこまめに作成・更新を行なった。 - **デザイナーとの連携・UI/UX の改善の提案** これまでテックリードがデザイナーとのコミュニケーション窓口となり、要件定義に沿ったデザイン修正を依頼していましたが、それらの担当を引き継ぎ、テックリードのコミュニケーションコストの軽減に取り組んだ。また、404ページやファビコンなど、デザインが不足している箇所が多くあったため、密にコミュニケーションを取りながら作成依頼・相談などを行なった。 **【成果】** テックリードの開発工数を確保することができるようになり、一度は遅延して炎上してしまったものの、最小機能構成で改めてリリース日を設定し、その納期までに納品を完遂することができた。 開発業務のみならず、組織としてどのように動くべきかが目標達成には欠かせない要素だと気づくことができた。 **【改善点】** プロジェクト中盤〜終盤にかけて遅延が出始めていたタイミングで、人員増員やリリーススケジュールの交渉など、早めに手を打つことを検討しておくことで、テックリードに過度な負担をかけずに済んだのではないかと感じました。 ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー ## 4-6. プロジェクト終盤の新機能開発と品質保証の同時進行推進 **【課題】** プロジェクト終盤に差し掛かり、納品期日が迫ってくる中で、残機能の開発工数と並行して、QAエンジニアから上がってきたバグ改修の工数を確保する必要があった。 しかし、当時の人員構成では、期日までに「残機能の開発」と「バグ改修タスク」を完遂させることが難しい状況であることが発覚した。 **【解決策】** テックリードが残機能の開発をメインに、私がバグ改修をメインとして役割分担を行い、他の開発メンバーとともに2軸で開発を進める方針とした。 バグ改修のメイン担当として、 - バグ改修 - QAエンジニアとのコミュニケーション窓口 - 再現できたバグのタスク作成 - 他の開発メンバーのタスク管理 - 開発を進める中で気づいた UI/UX の改善 など、サービスの品質保証に全力で取り組んだ。 **【成果】** 「残機能の開発」と「バグ改修タスク」をはっきり分けたことによって、それぞれが自身のタスクに集中ことができ、責任感を持って最後までやり切ることができた。 # 5. 評価されたポイント プロジェクトにおいて、今の自分だからできることはなにか。を常に考えて取り組んできた。 他の開発メンバーの技術サポートや仕様の質問に対する回答、ベトナムメンバーのコミュニケーション窓口など、テックリードの負担を軽減させる行動を意識的に実施した。 また、実装でつまづいたところや仕様理解が複雑な箇所は、社内ドキュメントにまとめてアウトプットしたり、開発メンバーに技術共有を行なってきた。