ID:82149さん

# 役割概要 ## プロダクト全体の技術方針の策定（チーム規模10名） - メンバー10名程度の技術的な意思決定、アーキテクチャ設計の指針策定を担当。 - コードレビューや設計レビューの最終防衛ラインとしてプロダクトの信頼基準を担保。 ## 特定プロジェクトの進捗管理や関係者調整（対象3-4名） - サブチームのリーダーとして、タスクの切り出しや進捗管理、クライアントフェイシングなどを担当 ## 採用活動の貢献 - エンジニア採用における一次面接を担当。主に技術力のジャッジを行う。 ## レビュー・育成における取り組み - レビューでは結論だけでなく判断材料（前提・リスク・代替案）を言語化し、チームの意思決定が再現可能になるように支援 - また、デプロイ時や非同期処理の境界でエラーやデータが壊れることがないかを重点的に指摘 - 感情的な指導や叱責は行わず、心理的安全性を前提としたフィードバックを重視 - 1on1 では、本人のスキルや状況を踏まえ、最も伸びる一点に絞って具体的な改善点を提示 - 日本語表現やドキュメントの書き方など、成果物の品質に直結する基礎スキルの支援も実施 - 個々の実装品質だけでなく、チームとしての判断基準やレビュー観点が揃うことを目的に、設計・実装の背景を言語化して共有 # 代表的な取り組み ## プロダクト立ち上げ期における会計データ出力の不備 ### 課題 会計システムが利用する CSV 出力について、特定条件下で正しく計上されない不具合が潜在していることを発見した。 当該 CSV は 月次集計に利用され、外部会計システムへ連携されるほか、複数部署が参照するデータであり、リリース後に不具合が発覚した場合、会計データの修正・再計上に多大なコストが発生するリスクがあった。 ### 判断・行動 - 仕様と実装を突き合わせて検証した結果、ポイントの有効期限失効時に、会計上正しく計上されないケースが存在することを特定 - 計上ルール自体は正しい一方で、そのルールを前提とした設計になっていなかったことが根本原因であると判断 - 一時的な補正ではなく、計上ルールに合致する形へ設計を是正し、修正を実施 ### 結果 - 月次・外部会計・複数部署参照という条件下で、会計データが誤った形で確定する事態をリリース前に未然防止 - 「システム上は正常だが、会計としては壊れている」状態をリリース前に排除 ## クレジットカード会社とのデータ連携（30万件／時間制約） ### 課題 クレジットカード会社とのデータ連携において、30万件のデータを1時間以内に Web アプリケーション内に安全に取り込むという制約があった。 誤投入や二重投入が発生すると、利用者情報やポイント残高が誤ったまま確定し、後追い修正が困難になるリスクがあった。 ### 判断・行動 - 外部仕様がデータ番号の昇順に適用していけば良いという方針を先方から受け取ったが、そもそもの例外が多く、データ投入単位でまとまっていないため、そもそものルールの再定義を行った - 並列処理の安全単位を確定するため、受領レコード単位（カード単位）からユーザー単位のキーを特定し、投入単位・ロック粒度・補正ロジックを設計した - 大量取り込みと誤投入防止がトレードオフになるため、Validation と投入を分離し、投入条件を厳格化する判断をした - またデータ投入時にエラーが発生することも考え冪等性を担保し、再実行時にもデータが壊れない構造を設計 - 取り込み途中でアカウント統合が発生する可能性を考慮し、ロックによって状態を確定させた上で投入（状態変更があった場合は適切にデータを補正） - 結果として安全で実測で約6分での取り込みを実現 ### 結果 - トランザクション整合性を厳密に要求される要件と高速かつ安全なデータ連携を実現 - 運用・再実行・障害時にも正しさを説明できる構造を確立 ## クレジットカード会社とのファイル連携基盤更新（HULFT／運用切替） ### 状況・課題 既存のクレジットカード会社とのファイル連携基盤について、 サーバーOS・通信アプリケーション・暗号方式の更新が必要となり、 連携停止時の業務影響が大きい高リスクな切替作業であった。 関係者は以下の4名で構成されていた。 - 自社：バックエンド担当（本人）、インフラ担当 - 先方：IT部門統括、インハウスカード事業マネージャー 当初はリスク低減のため、段階的な切替を前提に検討を進めていた。 ### 判断・行動 - 更新対象となる OS／通信アプリケーション／暗号ソリューションを整理し、技術的な前提条件と制約を明確化 - ネットワーク構成・通信経路について、先方 IT 部門と詳細を詰め、段階的切替を前提とした進め方で一度合意 - その後、インハウスカード事業側から「クレジットカード会社側の切替コストが数百万円規模になる」という新たな制約が提示された - コスト・リスク・復旧可能性を再評価し、段階切替を撤回して一括切替に方針転換する判断を実施 - 一括切替に備え、インフラ担当と連携してバックアップ・復旧手順を整理し、切替当日の重点監視体制を構築 ### 結果 - 致命的な障害なく切替を完了し、ファイル連携を再開 - 外部関係者を含む意思決定と、リスクを取る判断を主導し、業務影響を最小化した形で連携基盤の更新を完遂 ## 性能改善要求に対する設計判断（速度改善を止める判断） ### 課題 性能改善要請があり特に現状調査も行われず同僚の案で進むことになった。ただ、現行構造のまま最適化を進めると、将来的にデータ整合性を破壊するリスクが高い状況だった。 この案を進めた最悪の場合、ポイント残高が誤ったまま確定し、取引履歴の再計算・復旧ロジックが二重化して原因追跡も困難になる懸念があった。 ### 判断・行動 - これはポイント残高計算のロジックの根幹箇所で変更されなくなったデータを確定箇所であるが、そもそも実装難易度が高く理解できている人が限られている状態であった - 実行が求められた primitive 化などの局所最適は、Python では cache locality があたらないため効果が低いどころか復旧ロジックの二重化・理解困難化を招くという仮説を立てた - 調査の結果、ボトルネックがアプリケーションではなくMySQL の commit 時 fsync に待ちがあることを特定 - SWE としての実装継続では解決しないと結論づけ、現状のボトルネック調査した上でcommit 数削減や責務分離といった代替案を提示した上でタスクを PM に差し戻し ### 結果 - 長期的に破綻する可能性のある設計分岐を回避 - データ整合性を最優先とする判断を組織として合意 ## サービスリリース直後に発生したメモリリークの原因特定と再発防止 ### 課題 サービスリリース直後には Web サーバーにメモリリークが顕在化し、本番運用に影響する不具合が発生していた。 ### 判断・行動 - DB接続周りのライフサイクルを中心に調査し、functools.cache による永続キャッシュが Engine を参照し続けることでメモリが解放されないことを特定 - キャッシュ設計を見直し、重いオブジェクトを保持しない／必要なら明示的に破棄できる構造（clear/dispose）へ変更 - 以後の変更でも同種のリークを起こさないよう、責務とライフサイクル（生成・再利用・破棄）の方針を整理 ### 結果 - メモリ使用量の継続増加を解消し、安定稼働を回復 - 本番運用でのトラブルシュートを“属人対応”ではなく“構造”に落とし込んだ ## アプリリリース後に顕在化した DB デッドロックの原因特定と収束設計 ### 課題 アプリリリース後、本番環境で DB デッドロックが発生し、特定の処理が失敗、不安定な状態になっていた。障害対応として単発のリトライでは収束せず、継続的に発生する設計起因の問題と判断した。 ### 判断・行動 - デッドロック対象の更新処理を特定し、複数テーブル（例：A / B）への行ロック取得順序がエントリポイントによって揺れていることを原因として切り分け - テーブルAは常に更新対象でロックが必要である一方、テーブルBは条件により更新されるため、結果としての順序が混在し、相互待ちが発生していた - ある経路では「A → B」 - 別経路では「B → A」 - 収束方針として、ロック順序を「A を必ず先に取得」へ統一し、B は必要な場合のみ後続で取得する設計に変更（ロック順序の規約化） ### 結果 - ロック取得順序の揺れを排除し、デッドロックを恒久的に解消 - 事象対応（リトライ・運用）ではなく、トランザクション設計の規約化により再発しない構造へ収束 ## その他プロジェクト - クレジットカード会社とのファイル連携基盤の構築（HULFT／運用設計） - 大手スポーツ量販店のポイントシステム刷新とその運用 - 大手スポーツ量販店の派遣人員募集サイトの作成 - 大手スポーツ量販店の派遣人員募集サイトの更新（リード） - ポイントシステムのネイティブアプリ対応（サーバーサイド）

# 役割概要 大規模データ基盤において、アプリケーション・データ移行・集計・ビジネス運用を横断し、データの正当性・再現性・説明可能性を担保。 # 代表的な取り組み ## SSP 収益データ取得・確定ワークフロー設計 ### 業務内容 各メディアが利用する SSP の収益データを取得し、AWS Athena で分析可能な形に整備。最終的にはビジネスサイドで記事の配信元と按分する。 ### 判断・行動 - 収益発生日から60時間後に速報値を確定し、72時間後に数字を確定しこれ以降は変更しないという特殊仕様に対応 - Digdag（Workflow Engine）の想定外の挙動に直面しながらも、実装をブラックボックス化せずコードを精査して原因を特定・解決 ### 成果 - ビジネス要件とデータ整合性を両立したワークフローを構築 - 予期せぬ挙動に対しても再現性をもって対処できる基盤を確立 - 参考： https://tech.gunosy.io/entry/escape-from-pitfall - この際にビジネスで収益按分割合の誤りを指摘 ## データ基盤民主化に向けたワークフローテンプレート作成 ### 業務内容 特定チームのみが利用していたワークフローエンジンを、他チームでも安全に使えるようにするためのテンプレートを設計。 ### 判断・行動 - bash による最低限の入力で利用可能なテンプレートを作成 - 利用者側と基盤側の責任分解点を明確に定義 ### 成果 - ワークフロー作成・運用コストを大幅に削減 - 基盤チーム・利用チーム双方の負担を軽減 ## 運用負荷低減を目的としたワークフロー整理 ### 業務内容 エラー通知が「データ欠損防止」という観点で設計されておらず、不要な運用負荷が発生していた。 ### 判断・行動 - 時間経過により自然に正しい状態へ収束するパターンを分類 - 入力・出力別に「次セッションで必ず正しくなる」構造へワークフローを再設計 ### 成果 - データ正当性を維持しつつ、運用負荷を体系的に削減 - 障害対応を“人の判断”から“構造”へ移行 ## その他プロジェクト - オンライン機械学習基盤構築 - 特許データの前処理と検索基盤の構築 - データマート作成と保守