Tech Square
2022.04 – Present画面
目的
需要企業と供給企業がスマートファクトリーのパートナーを探し、メンタリング、中古設備取引、運用情報を利用できるB2B製造プラットフォームです。
役割 · 技術スタック
Node.js · Express · TypeORM · MySQL · Vue 3 · AWS · GitLab CI/CD
実績 01
JavaシステムからNode.jsプラットフォームへの段階的移行
- 背景・原因
- 既存のJava 8システムには品質と保守性の限界がありました。Vue 3の顧客・管理者チャネルと技術構成を合わせた新しいプラットフォームが必要でした。
- 検討・選択理由
- 移行の意思決定には参加していません。Node.js・Express・TypeORM基盤のシステムを共同構築し、データ移行を担当しました。フロントエンドと言語エコシステムを統一し、協業の境界を減らしました。旧・新システムを並行稼働して機能とデータを検証した後に運用を引き継ぎました。
- 結果
- 運用を止めずに新しいプラットフォームへ移行し、その後はAPIと顧客・管理者チャネルの運用・改善を単独で継続しました。
- 振り返り
- 運用システムの移行は、新技術だけでなく、データ移行、並行運用、引き継ぎ完了の基準を併せて設計してこそ安定して完了します。
実績 02
共通トランザクション層によるデータ整合性基準の統一
- 背景・原因
- 業務モジュールの増加に伴い、SQL実行とトランザクション境界がサービスごとに分散しました。同時リクエストや部分失敗でデータ整合性を一貫して扱うことが難しくなっていました。
- 検討・選択理由
- 各サービスにTypeORMを直接制御させる代わりに、共通のSQL・トランザクション層を作りました。分離レベルとコミット・ロールバックの責任を一箇所に集め、業務単位の成功・失敗基準を統一しました。業務条件とトランザクションを併用して重複リクエストも防ぎました。
- 結果
- 複数の業務モジュールが同じ実行・復旧基準を使うようになり、同時リクエストでも重複保存と部分反映を制御する基盤を整えました。
- 振り返り
- トランザクション共通化の目的はコード再利用ではなく、業務単位の成功と失敗の境界を一貫させることです。
実績 03
クエリ再構成による繰り返し参照の改善
- 背景・原因
- 会員、企業、メンタリングのデータ増加により、一覧の各項目で関連情報を再取得する構造が生まれました。検索条件が増えるほどクエリの組み合わせも複雑になっていました。
- 検討・選択理由
- 制限時間を延ばしたり無計画にインデックスを追加したりせず、繰り返し参照を結合と一括取得に置き換えました。動的な検索条件はパラメータバインディングに基づくクエリビルダーで整理し、実行構造と入力安全性をともに改善しました。
- 結果
- 繰り返し参照を減らし、検索条件を安全に組み合わせられるようにしました。一覧とExcelダウンロードも同じ参照基準を共有しています。
- 振り返り
- 遅い参照では、まず結果集合と繰り返し回数を確認し、クエリ構造を正してから必要なインデックスを選ぶべきです。
実績 04
ローカルファイルをS3ベースの共通ファイルフローへ移行
- 背景・原因
- アップロードしたファイルがサーバーのローカルパスに縛られ、環境によって参照・ダウンロード処理が変わっていました。PDF、Excel、画像ごとに個別の例外処理も蓄積していました。
- 検討・選択理由
- サーバーインスタンスとファイルのライフサイクルを分離するためS3へ移行しました。既存ファイルは一度に廃止せず、両方のパスを読める期間を設けました。アップロード、参照、削除、元のファイル名の復元を共通ユーティリティに集約し、保存方式の変更が業務コードへ広がらないようにしました。
- 結果
- 通知、報告書、見積書、画像など異なるファイルフローが共通の保存方式を使うようになり、環境依存のパスと重複処理を減らしました。
- 振り返り
- ファイルストアの移行は単なるオブジェクトコピーではなく、既存キー、元の名前、参照パスの互換性も保つデータ移行です。
実績 05
認証と入力の境界を段階的に強化
- 背景・原因
- ブラウザーからアクセスできる認証トークン、動的SQL、HTML入力、複数のアップロード経路がありました。それぞれが異なるセキュリティリスクを生んでいました。
- 検討・選択理由
- JWTをHttpOnly Cookieへ移し、ブラウザースクリプトからの直接アクセスを防ぎました。同時の401応答は一回のトークン更新に収束させました。SQLのパラメータ化とHTML・ファイルの許可リスト検証により、認証、データ、入力、ファイルの境界ごとに適切な防御を適用しました。
- 結果
- 顧客・管理者チャネルの認証フローを統一しました。スクリプト入力、SQLインジェクション、危険なファイルレンダリングにつながり得る露出経路を減らしました。
- 振り返り
- セキュリティは一つのフィルターでは解決できません。認証、入力、データ、ファイルの境界をそれぞれ確認し、段階的に絞り込む必要があります。
実績 06
ログ断片をリクエストフローにつなぐ可観測性の構築
- 背景・原因
- サービスごとの`console`ログだけでは、一つのリクエストがAPIとデータ処理をどこまで進んだかをつなげて確認することが困難でした。
- 検討・選択理由
- ログを増やす代わりに、全ソースを構造化ロガーへ統一し、リクエストごとに相関IDを付与しました。OpenTelemetryのtraceIdも接続し、ログ形式を保ちながらサービス境界を越えてリクエストフローを追跡できるようにしました。
- 結果
- 個々のログを別々に検索する代わりに、リクエスト単位で問題の発生箇所を絞り込める運用基盤を整えました。
- 振り返り
- 可観測性ではログ量より、異なる記録を同じリクエストフローにつなげられるかが重要です。
実績 07
シークレットとローカル開発環境を再現可能な構成へ移行
- 背景・原因
- 環境ごとの設定とシークレット管理方式が分散していました。ローカルのデータベーストンネルが切れると、アプリケーション接続も不安定になっていました。
- 検討・選択理由
- 少人数で混成のチームにおける運用負担を考え、Vaultより導入障壁の低いInfisicalを選びました。Docker Composeで実行環境を統一しました。データベーストンネルは切断検知、指数バックオフ再接続、二重起動防止を備えた別プロセスに分離しました。
- 結果
- シークレットをコードとデプロイファイルから分離し、開発者が同じ実行手順を再現できるようにしました。トンネル障害もアプリケーション全体の再起動に頼らず復旧できます。
- 振り返り
- 開発環境の標準化はツールを揃えるだけではなく、設定、シークレット、外部接続の失敗と復旧方法をともに定義することです。
実績 08
バッチ・通知パイプラインによる反復業務の自動化
- 背景・原因
- 外部データの取込み、状態確認、担当者への案内を人が繰り返すと、漏れや処理遅延が発生する可能性がありました。
- 検討・選択理由
- データベース往復を減らすため、大量データは一件ごとのリクエストではなく一括で取り込みました。業務条件ごとにcronジョブと通知フローを構成しました。重複実行、空の結果、環境ごとの送信可否を分け、例外状況で自動化が不要な作業を生まないようにしました。
- 結果
- 企業データの取込みと運用通知が定めた条件とスケジュールに従って実行され、担当者の繰り返し確認作業を減らしました。
- 振り返り
- バッチ自動化では、定期実行そのものより、重複処理、空の結果、部分失敗を安全に扱うことが重要です。