こーひーあーる

チーム規模: 5名 (内、部長1名、要件定義・サービス設計1名、運用設計1名、WebAppバックエンド2名)

概要: 特定の媒体より通販注文を受け付けられるWebAPIの開発プロジェクト。(媒体や協力会社については非公開)

取り組んだこと:

• LaravelとOracleDBを組み合わせたPHPUnit実行環境の整備
• OracleXEコンテナを用いた開発用DBの構築（検証用DBからスキーマ・マスタデータをdump・importして環境を再現）

チーム規模: 6名 (内、部長1名、要件定義・サービス設計1名、フロントエンド1名、バックエンド2名) ※企画部門や倉庫部門含めると数十名

概要: Yahoo/楽天型の自社ECモールを、AmazonライクなECモールにする

背景・状況:

• 開発担当としてアサインされたもののシステム全体像が不明瞭で何を開発すればいいかわからない状態だった
• ERPシステムの制約（仕様変更すると在庫管理・販売管理が影響を受け、部門業務の変更が必要になる）
• 業務フローは存在したが、開発可能な粒度まで落とし込まれていない

取り組んだこと:

• 企画・倉庫・カスタマー・販売管理・経理など、関係部門を網羅した業務フロー図を作成して確認を投げるところから着手
• 業務フローからシステム接点を抽出し、ユースケース図を作成、ERPパッケージ運用担当にヒアリングし制約条件を確認、以上を踏まえて開発が必要な機能一覧を作成して、スケジュール表に落とし込む
• WebAPI経由でERPの受注データを取得する仕様を設計
• 商品登録・変更、倉庫保管手数料算出のための記録仕様、の叩き台を作成
• ECモールWebアプリ・管理アプリのバックエンド実装（初期フェーズ）
• 納品計画登録画面のバックエンド実装

成果:

• 業務フロー・ユースケース図により、システム全体像を可視化
• 開発スコープを明確化し、「何をすれば完了か」をチーム全体で共有
• ERP制約を整理し、既存業務への影響を最小化した

学び:

• 曖昧な要件を図解で可視化することで、関係者の認識を揃えられることを実感
• 既存のシステムを活用する際には制約条件を確認しておく必要性を学んだ

チーム規模: 4名 (内、部長1名、別機能担当エンジニア2名、自分)

概要: 10年以上前に協力会社により作成された、ERPと各種アプリケーションを連携させているSOAPプロトコルのWebAPIを内製化し、RESTishなWebAPIにリプレイスするプロジェクト。エラーレートの削減による機会損失の低減、機能要件に自社で対応できるようにすることが目的だった。

背景・状況:

• ERPとその他のアプリケーションとで不整合がしばしば発覚することはわかっていたが、何が原因かはチームでわかっていなかった
• ERPが稼働し続ける限りAPIも同様に稼働させ続ける必要があったので、メンテナンスしやすいアプリ構成にする必要があると感じた
• これまで活用していたCodeIgniter3がメンテナンス切れていたため、バージョンを上げるかフレームワークを変える必要があった
• テストコードが勤め先のシステムでほとんど書かれていない状況

取り組んだこと:

• 現行サーバのIISからSOAP WebAPIのアクセスログを取得しパフォーマンス上の問題を分析
• Laravelを用いたプロトタイプを作成・共有し、学習リソースが豊富なLaravelの採用を提案
• Podmanコンテナを用いた環境構築の提案と実装
• 協力会社が10年前に開発したC#製アプリケーションのコードを解析し、Laravelで再実装
• REST APIのエンドポイントおよびIN/OUT設計
• OpenAPI仕様書と実装が乖離していないかのPHPUnit実装
• GitLab Runnerを使った CI/CDパイプラインの構築
• LaravelPint&Larastan&PHPUnitをgit precommitで検証するスクリプトを作成してメンバーに配布
• MVC+UseCase構成を採用し実装

成果:

• ログ分析より、決まった時間のERPの日時処理におけるデータベースインデックス再作成のタイミングでAPIエラーが多発することを特定
• 構成をコンテナファイル化することで、環境の容易な配布や、再現性の高い環境構築が可能になった
• テストコードを整備し、標準的な開発フローに近づけた。OpenAPI仕様書と実装の乖離を自動検知できるようにした

学び:

• テストコードを敷いておくことで、特に書き込み系のWebAPIの動作確認がやりやすくなることがわかった
• オニオンアーキテクチャかMVC+UseCaseを採用するかで非常に悩んだ、が組織の身の丈にあった構成を選ぶことが大事だと感じた
• 技術スタックを組織で統一するメリットを体感した、教えることが少なくできるし、採用難易度も下がるし、チームで知見を共有しやすくなる
• 既存システムの制約を変える際は影響範囲を把握し、影響をケアするための追加実装も必要になることを学んだ

チーム規模: 5名 (内 ディレクター1名、プランナー1名、Webデザイナー1名、プログラマ2名)

概要: Flashで遊べる版権ソーシャルゲームのサーバサイド追加開発・保守業務

背景・状況:

• レベニューシェア型のプロジェクトで、プラットフォーム・版元・権利取得会社へのマージンなどを加味した上で、チームで毎月数千万の売り上げを求められる現場だった
• フレームワークなどがないレガシーなコードベースで、追加開発の難易度が高い状態だった
• コード内ループで大量のSQL発行やスロークエリが頻発しており、イベント終了間際になるとサーバ負荷が高くなりゲームが重くなる状態だった
• すべてのテーブルでMyISAMエンジンが使われており、当時は排他制御がされてなく、課金アイテム増殖などのデータ不整合が頻発している状態だった

取り組んだこと:

• あるデッキを組んで連続どこまでバトル勝利できるか、などのバトルシステムのWebシステム追加開発
• MySQLのクエリログを分析し、スロークエリや発行過多なクエリを特定し、インデックス追加やクエリ改善を実施して負荷軽減
• 課金アイテムを増殖するバグを発見し、楽観的排他制御の実装により修正

成果:

• 新規バトルシステムの追加開発を担当してリリースした
• クエリ改善により、イベント終了間際のサーバ負荷が軽減された
• 楽観的排他制御の実装により、データ不整合の発生頻度が削減された

学び:

• 特にゲーム系アプリにおいて、DBアクセスの最適化がユーザー体験に与える影響の大きさを実感
• システム開発の先には、お金を払ってくれるユーザーがいることを痛感した