大規模POSシステムのリプレイス案件

システム設計支援、設計レビュー

Google Cloudを使ったマイクロサービスの設計支援。

システム設計図を確認し、システムの機能要件、非機能要件を満たすか、何かリスクはないか、必要以上に複雑になり過ぎていないか、などの観点でレビューを中心に設計支援を実施。

前提として、GKEを使ったシステムであり、基本的な制御はGKEで行うが、自分はこの辺りの詳しい知見がないので、その辺りは詳しい方にお任せしている。

実施したレビューと効果は以下の通り

• 過度な非同期処理によるデータ整合性の制御が複雑化していた問題を、オーケストレーションパターンの導入によって緩和。これにより、マイクロサービス間の連携における異常系フローが簡素化され、設計コストや運用コストが削減された。
• 高トラフィックなリクエスト（10,000RPS相当）を処理するAPIの性能向上を目的に、既存設計に対する改善案の策定と、正常系および異常系フローの整理を実施。これによりメモリ使用量が半減し、レスポンス速度が安定化。システム要件を確実に満たすことができるようになった。
• マイクロサービス開発におけるデプロイ戦略を踏まえたDBスキーマのマイグレーション方式を提案。原案ではDBスキーマの整合性を確保することが現実的に困難だったが、改善案の提案により、現実的な解決策を提示し、問題を一定解消した。
• Pub/Subのメッセージ滞留に対する異常系処理方式を提案（デッドレターキューを活用）。メッセージ滞留時の対応策が設計に欠けていたが、この方式を提案することで、その部分の課題を方針レベルで解決できた。

アプリケーションのアーキテクチャに関する設計支援

GKE上のPodにデプロイされるアプリケーションは、JavaとSpring Bootで実装することが決まっていた。そのアーキテクチャについて、ある程度計画されており、レビュー依頼が来たため対応することになった。

設計を見ると、DDD（ドメイン駆動設計）とMVC（モデル・ビュー・コントローラ）が混在しており、全体の整合性が取れていない部分が目立った。そのため、どの方針に統一するかを検討する必要があった。

このアプリケーションは長期的に運用されることが想定されていたため、Clean Architectureのような堅牢性を重視したアーキテクチャの採用も考慮した。しかし、実装を担当するメンバーのスキルセットを踏まえ、シンプルで実装しやすいMVCアーキテクチャに統一することを決定した。

テストコードの分割単位については、当初あまり計画が立てられていない状態だったため、適切と思われる分割単位を提案し、無事採用された。

技術調査、検証

基本的には、現場のメンバーが困りそうなことを事前に対処したり、詰まっている部分に手を貸すことが多い。特に、プロジェクトの進捗においてボトルネックになりそうな箇所に重点的に取り組んでおり、それらを解決することで進捗に大きなプラス効果をもたらしている。

実施した内容は以下の通り

• Spring Bootにおける、RequestのValidationの実装方法 & テストの実装方法
• 複数の外部APIを並行処理で叩く処理の実装
• spring-data-jpa + Spannerにおいて、saveメソッドをupsertからinsertにする処理の実装
• Spanner EmulatorをSpring Bootと連携する方法
• Spannerにおける、ナチュラルキーをPrimary Keyに使用した時の、ホットスポットの回避方法
• Spannerにおける、timestampのBETWEEN検索における、ホットスポットの回避方法
• Pub/Subにおける、デッドレターキューの挙動やメッセージ内容の調査

お客様とのコミュニケーションパスの調整

最初はお客様とテキストベースで仕様に関するQAを行っていたが、情報が錯綜しており、テキストではQAは不可能という状態になった。

状況を見ている限り、このままだとQAが全く進まない状態になってしまうと判断したため、追加での定期MTGを計画し、実際に一定の期間MTGを実施した。これによりQAの建て付けの見直し、情報交換の円滑さなどに一定貢献した。

プロジェクトレベルでの情報整理とプランニング

MTGなどでキャッチした、プロジェクトの情報をメンバーに必要な分だけわかりやすく伝えるよう、必要に応じて情報整理をしたり展開したりをしている。

また情報を踏まえた上で、どのように動くかの計画を立てることも実施している。大体2週間単位の計画だが、状況がいきなり変わることもあるので、必要に応じて単位は調整している。

特定の手法を固定で使っているわけではなく、情報の箇条書きや図を都度状況に合わせて作成し、都度都度必要に応じて展開している。

タスク管理

未確定な情報が多い中で、何かしらの成果物を作る必要があり、曖昧な情報に対して「今の段階では一旦こういう仕様で作る」というものを都度できる範囲で設定した上で、お客様の要望をタスクとして切り出し、メンバーに展開している。

お客様の設計書のみでタスクを進めようとすると、混乱してタスクが滞ることが一定の頻度で発生するため、タスクが円滑に進むように自分の方である程度の調整を行っている。

また、タスクの進捗管理なども行っている。

オンボーディングの作成と運用

メンバー入れ替えが定期的に発生しており、新規参画メンバーの参画負荷を下げるためのオンボーディング用の情報連携と、オンボーディング用のアプリ開発課題を作成し、展開。

これにより、実際の開発に入る際の混乱を減らしており、内部QAのコストを軽減させることに成功した。

メンバーに対するフィードバック

メンバーのケイパビリティ向上と関係性強化のため、半年に一度のペースで、メンバー全員分のフィードバックを記載し、1on1形式で全員に渡している。
※この取り組みは自主的な取り組み。現環境ではフィードバックの量、質ともに不足しているのではないかという課題を感じて始めたものである。

効果は不明だが、メンバーとPMから好評な様子なので、今後も継続予定（2024年12月時点で2回目）。

内容としては、以下の通り

• ポジティブフィードバック
• ネガティブフィードバック
• 改善方法提案
• 課題ヒアリング
• 感謝

より具体的な内容はこちらの記事を参照。

アプリケーションの実装

基本的に手を動かすポジションではないが、タスク量に対して人手が足りていないため、一部のアプリケーションの実装に関わっている。

実施した内容は以下の通り

• いくつかの既存のAPIの機能改修やリファクタリング対応
• Pub/Subから受け取ったメッセージを元に、他APIを複数実行し、その結果を元にデータを作成し、Pub/SubにPublishするアプリケーションの新規実装