競艇予想サイト開発システムの刷新

2022年8月～2023年4月

使用した技術やツール

Nuxt.js
Express
Adobe XD
PHP
Python
MySQL
Docker
AWS EC2
GitHub
Notion

概要

競艇の予想を販売するサービス（以下、競艇予想サイト）を開発するシステムの刷新を行ないました。

当プロジェクトは、私が2020年10月～2023年3月に在籍していた会社で、2022年8月～2023年3月に参画していました。

上記の私が在籍していた会社は私が入社する前に、ベンダーが開発したシステム（以下、旧システム）により約15種類の競艇予想サイトを開発した実績がありました。

私自身、入社後に旧システムを使用して5種類の競艇予想サイトの新規開発に携わりました。

当プロジェクトは、旧システムの刷新ならびに刷新したシステム（以下、新システム）による競艇予想サイトの新規開発です。

目的

競艇予想サイトの開発に必要な日数の短縮が目的でした。

1年で20種類の競艇予想サイトのリリースを企画しているクライアントと取引を行なうにあたり、旧システムを利用した開発では間に合わないため当プロジェクトが始まりました。

旧システムでの課題

作業の完了待ち時間が発生

バックエンドエンジニアとフロントエンドエンジニアが、同時に作業できない状態でした。

競艇予想サイトを構成する各種のPHPファイルにバックエンドとフロントエンドのコードが共存していたため、同じファイルに対して同時に変更を加えることができず、双方の作業の完了を待つ時間が発生していました。

コードの変更が本番環境に即時反映

前述の各種のPHPファイルは旧システムのCMSで管理されており、コードの変更はCMSで行なう必要がありました。

また、コードの変更を保存すると即時に本番環境に反映されていました。

そのためコードの変更による挙動や表示の確認は、本番環境でしか行えない状態でした。

上記の状態のため、熟考したコードの変更と入念な確認が必要となり、コードの変更に際して多くの時間が掛かっていました。

エンジニアによるデザイン業務の発生

旧システムとは関係が無いものの、エンジニアによってデザインを行なう必要があった点も、開発に掛かる日数を増やす要因となっていました。

私が在籍していた会社のデザイナーが少数であり、かつ多数のプロジェクトを同時に行なっていただため、各プロジェクトのデザインには主に以下の内容が不足していました。

タブレット用やPC用のデザイン
主要なページ以外のページやコンポーネントのデザイン
テキスト量が可変する部分における、複数パターンのテキスト量のデザイン
アニメーション

上記の不足している部分はエンジニアがデザインを行なう必要があり、デザインが不得意なエンジニアは実装に多くの時間を要していまいた。

また、同じ部分においてデザイナーによるデザインと、エンジニアによるデザインと実装が並行して行われる場合がありました。

上記の場合において、デザイナーによるデザインが採用された場合に実装のやり直しが発生することで、さらに時間を消費していました。

プロジェクト完了後の効果

開発に必要な日数を1/3まで短縮

旧システムでは、約60日で1つの競艇予想サイトを開発していました。

新システムでは、約20日で1つの競艇予想サイトを開発できるようになりました。

本番環境の保護

本番環境に影響を与えることなく、開発ならびにデバッグが可能になりました。

エンジニアによるデザイン業務を大幅に削減

デザイナーがほぼ不足なくデザインを制作できるようになったことで、エンジニアによるデザインの業務がほぼ無くなりました。

プロジェクト完了までの時系列

2022年8月：競艇予想サイトシステム再開発に参画、ワイヤーフレームを作成
2022年9月～2022年10月：テンプレートリポジトリ作成
2022年11月～2022年12月：3種類の競艇予想サイトを新規開発
2023年1月～2023年3月：4種類の競艇予想サイトを新規開発

プロジェクトで行なった内容

バックエンドとフロントエンドの分離

フロントエンドのコードとバックエンドのコードを同一のファイルに記述せず分離することで、双方が双方に影響を与えることなく開発を進められるようになりました。

コードの分離によってフロントエンドでは、そのほかに主に以下の恩恵がありました。

APIが未完成の場合、モックデータを作成することで実装に着手できる
モックデータをバックエンドエンジニアに共有することで、APIのレスポンスの構造や含めてほしい要素を要望できる

バックエンドとフロントエンドの分離にあたり、使用する技術やフレームワークは以下の背景により選定しました。

バックエンド

CTOとバックエンドの実装を行なうメンバーが慣れている技術であることから、独自に開発したPHPのフレームワークが選定されました。

当独自PHPフレームワークは、単一のAPIエンドポイントにPOSTメソッドのみを受け付け、リクエストボディにAPIの種類や各種のパラメーターを指定することで機能する、GraphQLに似たAPIを構築していました。

また、上記のAPIでデータを取得する際はAPIはできるだけシンプルにデータを返し、データの整形やフィルタリングはBFFで行なうことにしました。

旧システムでの経験から、競艇予想サイトの開発においてはフロントエンドの要件が変わりやすく、かつ複雑な実装が必要になることが多かったため、上記の方針をとりました。

BFFの実装にあたり使用するフレームワークとして、ネット上のナレッジが豊富であると判断してExpressを選定しました。

フロントエンド

CTOから「メンバーのスキルアップを図ってほしい」という要望があったことと、メンバーの技術力や経験を考慮して、フレームワークにNuxt.jsを選定しました。

フレームワークの選定にあたり以下の点により、フロントエンドをできるだけサーバーサイドでレンダリングする方針にしました。

未認証ユーザーが要認証ページに遷移できないようにしたい
APIのリクエスト先やペイロードなどをできるだけ秘匿したい

次に、サーバーサイドレンダリングを実装しやすいフレームワークを調べた結果、Next.jsとNuxt.jsが候補に挙がりました。

フロントエンドのメンバーであるマークアップエンジニア2人と、人手不足のために駆り出されたマークアップの経験がほとんどないバックエンドエンジニア1人にとって、ReactのJSX記法は理解に時間がかかると考え、Nuxt.jsを選びました。

GitHubで本番環境のコードを保護

GitHubでコードを管理し、デプロイすることで本番環境に変更を反映させるようにしました。

これにより、コードを変更しても即時に本番環境に反映されないようになりました。

また、以下の構成と権限でGitHubのブランチを分けることで、本番環境のコードを保護しました。

main：本番環境のコード。developブランチからのプルリクエストをマージすることで更新。CTOがマージを担当しました。
develop：開発環境のコード。私がマージを担当しました。

メンバーによる実装や修正は、接頭語としてfeature-を付けたブランチを作成して、developブランチにプルリクエストを送ってもらい、私がコードレビューやマージを行なっていました。

複数のワイヤーフレームを作成

デザイナーによるレイアウトのデザインや仕様の確認の手間や時間を削減するため、レイアウトやボタンなどの挙動を設定した複数のワイヤーフレームを作成しました。

旧来はフロントエンドの実装の着手までに以下の流れを経ていました。

デザイナーがプロダクトマネージャーに仕様を確認しながらデザインを制作
デザインが完成している部分、かつバックエンドの実装が完了している部分をフロントエンドエンジニアが確認
フロントエンドの実装に着手

ワイヤーフレームを作成することで、以下の流れでフロントエンドの実装に着手できるようになりました。

プロダクトマネージャーが基本となるワイヤフレームを選定
デザイナーが選定されたワイヤーフレームにデザインを制作、フロントエンドの実装に着手
デザインが完成した部分に、さらにフロントエンドの実装

上記の流れの通り、プロダクトマネージャーがワイヤーフレームを選定次第、ただちにフロントエンドの実装に着手できるようになりました。

また、デザイナーはレイアウトに係るデザインの工数を削減ができ、旧システムでの競艇予想サイト開発時に作りこめていたなかった部分までデザインができるようになりました。

付随して、細部までデザインできるようになったことで、エンジニアがデザインを行なう部分の削減に繋がりました。

1対1でメンバーの教育

新システムでの競艇予想サイト開発開始時に以下の理由により、メンバー1人ずつに1対1で各種の技術やツールの概念や使い方などを教育しました。

教育を要するメンバーの総数が少ないため
作業用PCのOSやエンジニアリングに対する経験値や理解度などが、メンバーによって異なるため

教育の手法は、メンバーがメモを誤って取らないようにZoomで行ない録画しました。

また、録画は全員が視聴できるように共有しました。

そのほか、以下の内容をメンバーが読み書きできるドキュメントにまとめました。

頻出するエラーの内容と対応方法
技術的な質問を行なう際のテンプレート