overhall

# プロジェクト概要 - 大手人材会社が求人と求職者のマッチングを行い、就業・転職を斡旋するためのWEBツール開発 - 上記既存システムのクラウド環境への移行とリプレイス開発 - GoogleMapをベースとしたシステム開発 # チームの編成と業務内容概要 要件定義フェーズに２名のエンジニア、開発フェーズに最大６人のエンジニアの編成 要件定義メンバー兼、開発エンジニアの一人として参加し、テックリードを担当した。 - 要件定義、プロジェクトマネージャー ２名 - 開発者 ６名（要件定義メンバー兼任） - クライアント企業の担当者との連携 # 課題 以下のような課題点があり、このプロジェクトに至った。 - クライアント会社独自クラウドを利用していたが、AWS環境への移行が必要となった。また、開発が終了しているWEBフレームワークを利用している、PHPのバージョンが5.6などのメンテナンス問題もあったため、リニューアルが必要になっていた。 - DB構造が最適化されておらず、高負荷時のAPIレスポンスに大量の時間がかかりツールが利用できないケースが存在した。特に緯度経度情報を持つデータの検索の処理が重く、システム全体の遅延原因となっていた。 - 長期間にわたる運用により、設計初期に想定されていたデータ量より多くのデータを扱う構造になり、また機能増加による処理時間の遅延が発生していた。 # 取り組み - 最新バージョンのLaravel・PHPによるサイトリニューアル、煩雑していたフロントエンドへのReact導入でソースの品質管理が行いやすいようにした。 - DBへの高負荷によるパフォーマンス影響が状態化していたため、DB構造の見直し・クエリの実行計画・パフォーマンス検証などを行い、よりよいテーブル構造への最適化を行った。また、Mysqlのバージョンを5.6から8系のAuroraに乗り換えた。 - 高負荷、もしくは実行に時間がかかっていた機能の実装方法を見直すことで処理の高速化をはかった。 - 運用の効率化を図るため、従来はエンジニアによるサーバーログインをしたうえでの手動デプロイから、GithubActionを利用した自動デプロイを導入した。 # 工夫した点 - 従来のインフラ環境では、デプロイ作業がサーバー内にログインした上で、完全手動により行われていた。それに対して、自動デプロイの仕組みを組んだ。 - 要件定義時にパフォーマンスの問題になっている機能・DB構造の調査を十分に行うことで、ある程度の見通しを立てながらリプレイス開発を行うことができた。緯度経度情報を持つデータの検索に対しては、「空間インデックス」というインデックスを導入することで検索速度の改善を図った。 - 導入したLaravel（※）、Reactのパフォーマンスについてはチームメンバーの知見が十分ではなかったため、メンバーへの導入・指導も含めて担当した。 ※ Railsを主に利用している会社ではあるが、クライアントの要望としてPHPでの実装が必要になったためLaravelを選択、そのためチーム全員がLaravelに明るい状態ではなかった。 # 成果 - テーブル構造を大幅に見直し、緯度経度データを扱うDBアクセスのパフォーマンスを改善した結果、主なボトルネックと鳴っていた検索機能のパフォーマンスが30％以上改善した - 遅延していたデータ取り込み機能の速度が5倍以上になった。 - チームメンバーへの知識導入、主にフロントエンドのパフォーマンス向上にコミットした結果、「また一緒に仕事がしたい」という言葉をいただけた。

# プロジェクト概要 チケット販売サービスのリニューアルにおける要件定義・詳細設計 ※ 現在進行系で詳細設計をしており、今後開発のフェーズが開始する状況 # チームの編成と業務内容概要 要件定義、詳細設計のメンバーとして、クライアント・社内メンバと現行システムの機能調査、リニューアル後の要件定義、を行っている。 詳細設計フェーズでは、設計リーダーチーム（５人）の一人として、各メンバーの詳細設計書のレビューとクライアントとの調整を行っている。 - 開発者（要件定義時）５名 / 開発者（詳細設計時）1５名 - デザイナー 5 名以上 # 課題 以下のような課題点があり、このプロジェクトに至った。 - 「購入者が集中していたときの待合室のシステムが適切に機能しておらず、先にサイトが落ちてしまう」 - 「想定外のユーザー挙動や、高負荷時に外部決済サービスと内部データの不整合が発生する」 - 「あらかじめ高性能インスタンスを一定数立てておくといった体制にしているため、インフラコストが高い」 - サービス開始から10年程度し、上記のようなケースの顕在化や、今後も利用者増加を見込んでいるため、負荷に対応出来るシステム構成にする必要があった。もともとサービスをメンテナンスしていたベンダーではなく、リニューアルを弊社が担当することになった。 # 取り組み - 現行システムを担当しているベンダが独自導入した待合室システムが適切に機能できていなかったため、外部の待合室サービスを導入、システムとの整合性を取る設計を行った。 - クライアントが新規システムで希望する購入挙動、チケット販売構造、導入予定の外部決済サービスの仕様から、購入データやチケットのデータ構造設計を中心となって行った。 # 工夫した点 - 従来のシステムでは、長期運用によりデータのステータス区分けなどがわかりにくい構造になっていた。新システムの設計では、社内メンバーと相談しながら、適切なステータス区分の設定を行った。また、データの状態遷移パターンを資料化することで共通理解の構築と矛盾点の解決が迅速に行えるように努めた。 # 成果 - 現行システムでクライアントがもともと抱えていた問題点を解決できる見込みのシステム設計が進んでいる - クライアントが未検知のシステム不備の発見・改善提案を行ったり、現行機能を新システムでの適切な仕様へのアップデートをする設計が出来ている。