松熊利樹

状態マシンによる翻訳検証プロセスの制御

翻訳チェック→再翻訳のループを9状態の状態マシンで制御する設計にした。状態遷移ロジックとビジネスロジックを分離することで、条件分岐の変更が他のステップに影響しない疎結合な構造を実現した

可観測性を重視したイミュータブルスキーマ設計

全ステップの結果をDBに不変データとして記録する方式を採用。翻訳精度の問題発生時にSQLで原因を分析でき、将来のAIモデル改善にもデータをそのまま活用できる。また処理の進行状況をDB SELECTだけで把握でき、開発者の動作確認とビジネスサイドの翻訳品質チェックの両方の負担を軽減した

べき等なCeleryタスクによる耐障害設計

各状態遷移のステップをべき等なCeleryタスクとして実装。指数バックオフ+ジッターのリトライ設定により、APIのポーリング部分も安全に再試行できる。コンテナ自体が落ちてRedisキューが消失しても、DBに記録された状態からキュー情報を復元して処理を再開できる

生成AI（agent-browser）の非決定論的動作を踏まえたテスト方針策定

AIに無秩序に打鍵させるのではなく、段階的にテスト自動化を進める方針を策定。(1)まず打鍵仕様書で手動テストを体系化、(2)決定論的なE2Eテスト・コンポーネントテストへ移行、(3)agent-browserは打鍵ではなく決定論的なE2Eテストコードの生成にのみ活用

OnlyOfficeエディタ（Canvas実装）密結合UIのテスト方針

OnlyOfficeエディタのFake化はテスト有効性が低下すると判断。CanvasのDOM相対位置でのE2Eテストは不安定になりやすいため、正直にOnlyOffice密結合部分はE2Eを諦め打鍵に限定する方針に決定

UseCase/Repository/Domainの3層分離アーキテクチャの採用

翻訳検証ロジックをUseCase（ビジネスフロー制御）/Repository（データアクセス抽象化）/Domain（ドメインモデル・バリデーション）の3層に分離。生成AIの呼び出しをUseCase層に閉じ込めることで、AIモデル変更時の影響範囲を限定した

生成AIの意思決定をDBに永続化するスキーマ設計

生成AIが各検証ステップで下した判定（翻訳品質スコア・再翻訳要否・用語修正提案）をすべてDBレコードとして永続化する設計を採用。将来のAIモデル精度比較やプロンプト改善に必要なデータを蓄積する基盤とした

全文検索でも完全一致でもない「準完全一致」方式の設計

PostgreSQLの全文検索（tsvector）は日本語の助詞・句読点差異で過剰にヒットし、完全一致では表記ゆれで検索漏れが多発。正規化処理（句読点除去・空白統一・助詞パターン許容）を適用した上で文字列比較する中間方式を設計し、精度とリコールを両立させた

Celery同期ワーカー内でのasyncioイベントループ統合パターンの採用

Celeryの同期ワーカー（prefork）モデルを維持したまま、タスク内でasyncio.run()によりイベントループを起動するパターンを採用。Celery自体をasyncワーカーに変更する案はエコシステムの互換性リスクが高く、スレッドプール（ThreadPoolExecutor）はIO待ちでスレッドが無駄に占有される問題があったため不採用

段階的マッチング戦略による探索空間の削減

原文テキストとドキュメント構造（パラグラフ・セル・リスト項目）間のマッチングを、完全一致→正規化一致→部分一致の3段階で順次実行する戦略を採用。上位段階で確定した箇所を探索空間から除外することで、計算量を削減しながら精度を維持した

Vite + Biomeの選定（webpack + ESLint/Prettierからの脱却）

既存のwebpackベースのビルド環境をViteに移行し、ESLint+PrettierをBiomeに統合。Viteのホットリロード速度とBiomeの高速lint/formatにより、開発イテレーション速度を大幅に改善した

Volta導入によるNode.jsバージョン管理の統一

チーム内でNode.jsバージョンの不一致によるビルドエラーが散発していた問題をVoltaで解決。プロジェクトルートにバージョンを固定し、メンバーの環境差異を排除した

OpenAPI仕様をSingle Source of Truthとしたモック自動生成パイプライン

FastAPIが自動生成するOpenAPI仕様書を唯一の信頼源として、OrvalでTypeScript型定義・APIクライアントを、MSWでモックハンドラーを自動生成するパイプラインを設計。手動でモックを書く方式ではAPIの変更追従が困難なため、仕様書からの自動生成で型安全性とモック鮮度を同時に担保した

GHCRプル型デプロイの採用（手動SSH+SCP方式からの移行）

開発者がSSHでサーバーにログインしてSCPでファイルをアップロードするデプロイ方式から、GHCRにイメージをプッシュし本番サーバーがcronでプルするプル型デプロイに移行。デプロイの再現性を確保し、ロールバックもイメージタグの切り替えで即座に可能にした

GHCRの可視性・権限設定とイメージ管理の設計

GitHub Container Registryのイメージ可視性をOrganizationレベルで管理し、本番サーバーからのプルに必要な権限設定（Personal Access Token + read:packages scope）を整備。イメージのタグ命名規則も設計した

スクリプト注入方式によるOnlyOffice設定の外部化

OnlyOfficeの設定ファイルを直接マウントする方式ではバージョンアップ時に互換性問題が発生するため、Docker起動時にentrypointスクリプトで環境変数から設定ファイルを動的生成する方式を採用。TLS証明書パスとCORSオリジンを環境変数で切り替え可能にした

Docker Compose統合による環境構築手順の標準化

ローカルのReact+Pythonコンテナとリモートサーバー上のPHP+OnlyOfficeを連携させるためのDocker Composeネットワーク設定・環境変数テンプレート・接続確認手順を一つのドキュメントに集約。新規メンバーがドキュメント通りに実行すればE2E環境が再現できる状態を目指した

テスト対象の自動化可能領域と手動テスト領域の明確な線引き

OnlyOfficeエディタのCanvas要素に依存する操作はPlaywrightでの安定的なE2Eテストが困難なため、テスト対象を「翻訳ワークフローの操作フロー・API連携」と「OnlyOffice内のドキュメント操作」に二分し、前者のみE2Eテストでカバーする方針を策定した

MCPサーバーによる分散ログのClaude Code統合

React・Python・Celeryの各コンテナに分散するログをClaude Codeから横断検索できるMCPサーバーを構築。従来はdocker logs + grepで個別にログを確認していたが、MCPツール化によりClaude Codeの会話内からログ検索・フィルタリングが可能になった

agent-browserによるStorybook Story自動生成

既存のReactコンポーネントからStorybook Storyを自動生成するサブエージェントを構築。agent-browserでコンポーネントの実装を解析し、props・状態パターンを網羅したStoryファイルを自動生成することでUIカタログの整備を加速した

NotebookLM + markitdownによる低工数RAG構築

GoogleのNotebookLMを活用し、markitdownで社内資料（PDF/Word/Excel）をテキスト変換して投入する方式を採用。カスタムRAGの構築ではなく、既存SaaSの活用でコスト最小化を図った

SonarQubeによるレガシーコード品質の定量化

SonarQubeを使用して全コードを静的解析し、バグ・コードスメル・重複率・テストカバレッジの各指標を定量的に計測。改修リスクを客観的に評価できるデータを整備した

定量データに基づく改修優先度の提案

静的解析の結果をモジュール単位で整理し、改修リスクの高い箇所と影響範囲をマッピング。定量的な根拠に基づいて改修優先度を提案した

3択比較フレームワークによる戦略選定支援

7つの評価軸（開発リスク・コスト・工期・品質保証・運用影響・拡張性・ROI）で3択を比較するマトリクスを作成し、意思決定ツリー形式で判断フローを可視化した

Reactブラウザ拡張による低リスク改善アプローチの提案

Chrome拡張機能としてReact UIをレガシー画面に重ねるアプローチを提案。既存DBやバックエンドロジックを変更せず、フロント側で値引きマスタの階層ドロップダウン等を実装するPoC設計を行った

MECE×Issue Treeによる100仮説の構造化アプローチ

MECE（Mutually Exclusive, Collectively Exhaustive）とIssue Tree手法を組み合わせ、5軸定量スコアリング（リリース速度寄与度・バグ発生率寄与度・実行容易性・計測容易性・リードタイム）で100仮説を網羅的に列挙・評価した

8大課題の重要度順序付けと組織構造マッピング

最重要課題「既存アプリのデリバリー低下」への寄与度を基準に、実装者に直結する3課題を重点的に深掘りし、残り5課題はステークホルダー別に整理。8課題を重要度順に並べ替えた

5軸加重スコアリングによる施策優先度の客観化

Q寄与度(0.1)・C寄与度(0.1)・D寄与度(0.4)・金銭コスト(0.1)・所要工数(0.3)の5軸に重み付けしたスコアリング関数を設計。D（納期）への寄与度と所要工数を重視する重み配分にした

6フェーズ×3週間の段階展開ロードマップ設計

RANK.EQ関数でスコア順位をフェーズ番号に自動マッピングし、6フェーズ×3週間のガントチャートを自動生成。各フェーズに4〜5施策を配置し、前フェーズの成果を次フェーズの前提条件として段階的に展開

2部構成の経営提案資料設計（人材最適化＋チケット基盤再設計）

「AI翻訳事業における開発組織の人材最適化提案」（23スライド・全体像）と「チケット管理基盤の再設計によるQCD向上」（10スライド・深掘り）の2部構成で資料を設計した

Jira統一基盤の提案とツール比較による意思決定支援

Notion、Planio、Notion+Planio併用、Jiraの4選択肢を「チケット構造柔軟性」「部門横断連携」「UI/UX」「ワークフロー設計」「他ツール連携」の5軸で比較表を作成し、Jira+Jira Service Managementを推奨した

前日バッチ実体化（EventBridge+SQS）の採用

EventBridge+SQS+NestJS SQS Consumerによる前日バッチ実体化を採用

generate_series + UNION ALL による実体・未実体マージ方式

PostgreSQLのgenerate_seriesで日付展開し、テンプレートのJSON定義から20+カラムを復元、実体レコードとUNION ALL後にDISTINCT ONでデデュプリケーション

単一モデルでの3種類時間モデル統合

既存システムとの互換性を重視し、3種類の時間モデル（日付のみ・時刻あり・期間指定）を単一モデルに統合する設計を採用。将来の分離を見据え、テンプレート側にtimeModelの概念を持たせる拡張設計を文書化した

RBAC+ReBAC ハイブリッドACLモデルの採用

DB層はRBAC+ReBAC ハイブリッド（将来ABAC拡張可能）、UI層は3段階フェーズで段階的に公開する設計を採用

Deny-by-default + テンプレート方式の権限評価

デフォルト拒否、明示的denyが1つでもあればdeny、それ以外でallowがあればallow、どちらもなければdenyの3段階評価

scopeType+inheritChildren による階層継承のオプション化

継承フラグをスコープ別ロール割当に追加し、継承のオン/オフをロール割当時に選択可能にした

React.memo + useMemo による不要再レンダリングの排除

React DevToolsのProfilerでコンポーネントツリーの再レンダリングを可視化し、不要な再レンダリングをReact.memo、useMemo、useCallbackで排除。描画時間70%以上削減を達成

カレンダーUIをフルスクラッチで実装する決定

ライブラリに依存せず、React+CSSでゼロからカレンダーUIを構築した。3日/4日/週次等の可変日数ビューを外部パラメータとして受け取り、任意の日数幅でレイアウトが崩れないよう設計した

Apollo ClientをSSoTとしたドラッグ&ドロップ日付変更と逐次保存連携

Apollo Clientのキャッシュを唯一の信頼できるデータソース（SSoT）として設計。D&Dでの日付変更時も、編集モーダルでの逐次保存後もApolloキャッシュを更新することで、カレンダーがリアクティブに再描画される仕組みを構築

レスポンシブカレンダーUIとCSS scroll snapによるスマホ最適化

スマホ時はPC版とは大きく異なるUIに切り替え、日付タップでタスク一覧をスライド表示する設計を採用。CSS scroll snapを適用して、スクロールが常に日付単位でスナップし、中途半端な位置で止まらないようにした

フィールド単位onBlur逐次保存の採用（フォーム一括保存の不採用）

フィールドごとに独立したreact-hook-formインスタンスを持ち、onBlurイベントでisEqual差分チェック後にGraphQL mutationを即座送信する逐次保存方式を採用

コマンドをデータとして扱うRPC的アプローチによるフィールド変更のカプセル化

各フィールド変更をコマンドデータとして構造化し、UUIDでID付与してバックエンドに送信するRPC的方式を採用。リソース種別ごとに変更対象のフィールドセットを型定義し、変更操作をシリアライズ可能なデータとして扱う設計にした

インターン育成とコードレビューによるチーム品質底上げ

自身もコードレビューを積極的に実施し、インターンメンバーへのフィードバックを通じて育成を行った。レビューを通じてコーディング規約・設計パターンを実践的に伝えるOJT型のアプローチを採用

バックエンドチームへの窓口一本化とオーケストレーター型マネジメント

自分一人がB2Cアプリ全体の仕様を短期間で洗い出し、バックエンドチームリーダーと1対1で徹底的にすり合わせを実施。合意後にB2Cチームメンバー向けオンボーディングミーティングを開催し、全仕様を説明。チームから上がった質問・疑問点をまとめてバックエンドチームと解消するワンストップ窓口として機能した

仕様のタスク分解・依存関係整理・メンバー特性に基づくアサインメント

詰めた仕様をタスク分解し依存関係を明確にしてJiraチケットに落とし込み。メンバーの得意・不得意、スキルレベル、希望に応じてチケットをアサイン。タスク依存関係上、単一障害点（クリティカルパス）になりやすい箇所は自分が率先して引き受けた

4つのB2Cフォーム導線を共通DynamicForm基盤で実装

フォーム仕様定義クラスを中核に、共通のuseFormフック・入力コンポーネント群・バリデーションシステムを共有しつつ、導線ごとのページ構成・送信先・パラメータ差分のみを個別に定義する設計を採用

マルチページフォームのページ単位バリデーションと遷移制御

URLのページインデックス（1始まり）と配列インデックス（0始まり）を変換しつつ、useFormStateでページ単位のバリデーション状態を管理。trigger()をページスコープで実行し、未バリデーションのページへの遷移をブロック

Specificationパターンによる動的フォームバリデーション設計

Specificationパターン（ドメイン駆動設計のパターン）を採用し、条件式をオブジェクトとして合成可能な設計を実装

Specificationパターン×Yupカスタムメソッドによる相関バリデーション基盤

Yupのスキーマにカスタムメソッドを50+追加し、全スキーマ型に一括適用するパターンを実装。メタデータで依存フィールドを宣言的に記述し、依存グラフを自動構築

pnpmモノレポ構成でバリデーションをsharedパッケージに分離

pnpm workspaceでB2B・B2C・共通の3パッケージ構成を採用。バリデーション基盤を共通パッケージに配置し、B2B/B2Cからは再エクスポートで利用。列挙型レジストリでGraphQL由来のenum定義を一元管理

親子フィールド連動によるリロードなし選択肢フィルタリング

親子連動コンポーネントでuseWatch()を使い親フィールドの値変更をリアクティブに監視。フィルタ関数を子コンポーネントに渡し、useMemoで選択肢をフィルタリング。選択値リセッターが無効になった選択値を自動クリア

ウィジェット独立データフェッチアーキテクチャの採用

各ウィジェットが独立してデータフェッチを行うアーキテクチャを採用。Apollo Client useReadQueryを使用し、ウィジェットコンポーネント内でSuspense対応のデータ取得を完結させた

カスタムMasonryグリッドレイアウトのフルスクラッチ実装

カスタムグリッド配置アルゴリズムを実装。左右列の現在行インデックスを追跡し、高さの短い列にウィジェットを配置するロジックでMasonry効果を実現した

dnd-kit v6によるウィジェットドラッグ&ドロップ並べ替え

@dnd-kit/core v6.1.0 + @dnd-kit/sortable v8.0.0を採用。SortableContextでリスト管理し、useSortableフックで各ウィジェットのD&D状態を制御。DragOverlayで移動中のプレビュー表示を実装した

Storybook v8 + storycap + reg-suit + S3によるVRTパイプライン設計

@storybook/react-vite v8.1.5でStorybook環境を構築し、storycap v5.0.0でスクリーンショット自動取得、reg-suitでピクセル差分比較(閾値0.1%)、AWS S3への結果パブリッシュ、GitHub PR通知による差分レビューフローを構築した

GitHub Actions matrixストラテジーによるb2b/b2c並列VRT実行

GitHub Actionsのmatrix strategyでb2b/b2cを並列にstorycapで撮影し、アーティファクトとしてアップロード。後続のvrtジョブで統合してreg-suit runを実行する2ステージパイプラインを設計した