Nobuya Matsukizono

業務システムチームに移籍。 表に出ていない裏側に存在している業務システム(会計・管理画面)の開発、運用、設計。 以下は印象深かったプロジェクトです。 # 会計システム立て直し (2020 〜 2021年) 社内独自内製の会計システム立て直し ## チーム編成 - バックエンドエンジニア 1名 (私) - 経理チーム ## 使用した技術やバージョンなど - Ruby on Rails(5系と6系) - MySQL ## 要件 - 誰も触れなくなってしまった会計システムをメンテ可能な状態にすること - プロダクト側で走る新規施策に合わせて改修ができるようにすること - 壊れている会計データを直すこと ## 役割 - システム調査 - 再設計、修正、リリース ## リリースまでの課題やストーリー ### システム調査 このシステムを設計したエンジニアは退職し、ドキュメントも残っておらずメンテナが数年間不在な状態でした。 「どこで何が動いているのか」すら不明だったため「過去少しだけデータメンテで触っていた方々」から情報を集めることから始めました。 (デプロイサーバーで人知れずバッチが動いていたりと謎な部分が多いシステムでした) 内部構造をドキュメント化し、整理しました。 また内部ロジックを理解し、改修箇所が判明したため修理することになりました。 ### 修理 数年放置してきたため、プロダクト側が作るデータと会計システムが作るデータにかなりの差異が発生していました。※差異は経理チームが毎月手動で補正 経理チームと密接に連携し一つずつ誤りを直し続けました。 1年半かかりましたが、プロダクトと会計システム間の差異は発生しなくなりました。 この時の整理とドキュメント、確立した改修手法により「プロダクト側の新規施策に合わせて会計システムを改修する」ことが可能になりました。 (例: ブログ機能とブログ購入機能が導入されましたが、それに合わせて会計側も追従して金額データを正しく算出させることが可能になりました) # 電話システムをHeroku → AWSへ引っ越し (2022年) ココナラには出品者と購入者の間で通話を行い、通話時間に応じて料金を支払う仕組みがあります。 この通話機能をつかさどる(表には出ていない)内部システムをHerokuからAWS内に移管しました。 ## チーム編成 - バックエンドエンジニア 1名 (私) - インフラチーム 2名 ## 使用した技術やバージョンなど - Ruby on Rails(5系) - PostgreSQL - MySQL ## 要件 - アプリケーションの挙動は変更しないこと - Railsのバージョンを5.1.2から6系最新へ上げること - HerokuのPostgreSQLからRDSのMySQLへデータを移管すること - Twilioとの連携は変更しないこと ## 役割 - コンテナ化とRailsバージョンアップを行うこと - テストカバレッジを上げること ## リリースまでの課題やストーリー ### テストカバレッジ向上 このシステムは2017年から手が入っておらず、誰も内部を知らない状態でした。 カバレッジは41%。「低すぎず高くもなく」という事態でした。 一つ一つ内部実装を読みspecを追加していきました。 結果、41% → 94%まで向上しました。 ## Railsバージョンアップ システム自体はシンプルで、利用しているgemもさほど多くなかったのでここは特に苦労しませんでした。 個人的には2021年12月に出たRails7系まで上げたかったのですが、それをするためにはRubyのバージョンを上げる必要がありました。 - Rubyバージョンを上げると大量の警告が出る - 警告を抑えるためには内部のコードを書きかえる必要がある - 上記はプロジェクト工数的に厳しい という判断によりRails7は断念しました。 ## PostgreSQLからMySQLへ 300万件超えのデータをAWS(RDS MySQL)へどう移動するかで悩みました。(pg_dump → mysqldumpコンバート？) (pg_dumpにdata-onlyオプションやバルクINSERT形式で出力するオプションがあったため、それらを用いることで解決しました) 無事にHerokuからAWS内へ移管完了し、特に大きな事故無く稼働中です。