almond

### 概要 freee サインとロジクラ（freee に M&A された在庫管理プロダクト）の Public API を、MCP クライアント（Claude Desktop / Claude Code 等）から自然言語で操作できる Local / Remote MCP サーバーとして設計・実装した。 ### 目指す利益 - freee グループの主要プロダクトを AI クライアントから直接操作可能にし、文書送付・進捗確認・在庫オペレーションを自然言語で完結できる環境を提供 ### 解決したい顧客課題 - 既存 Public API は人間が触る前提で、AI クライアントからの操作には認証・スキーマ理解の参入障壁が高かった - M&A プロダクト（ロジクラ）が freee 認証統合前にも MCP 提供できる仕組みが必要だった ### 担当 - Sign Local MCP の設計・実装（OAuth2 認証・API ラッパー・configure 対話フロー） - Sign Remote MCP の Design Doc 執筆と PSIRT/SRE 合意形成 - Sign Remote MCP の本実装（二層 OAuth、Redis トークンストア、SSRF/path traversal 多層防御） - Logikura Local MCP の設計・実装 - OSS 公開リポジトリ（freee/freee-mcp）へのマージ ### 出した成果 - 200+ の API エンドポイントを CRUD 単位の数個のツールに集約し、エンドポイント仕様を Skill 自動生成で外出しする設計により、MCP コンテキストの圧迫を回避 - Sign Remote MCP の Design Doc を起点に PSIRT・SRE と非同期で合意形成し、本番デプロイ前提のインフラ設計を確定 - Skill 配布（freee-mcp の Skill リポジトリへ同梱し `npx skills add` で一括更新）の仕組みを Sign / Logikura 両方で実装 - 個人 OSS [oura-mcp](https://github.com/YasuakiOmokawa/oura-mcp)（Oura Ring API v2 用 MCP サーバー、MIT ライセンス）を設計・実装し、GitHub と npm（@yasuakiomokawa/oura-mcp v0.2.1）で公開 ### 成果に繋がった工夫 #### 1. ネームスペース分離パターンの確立と他プロダクトへの再利用 ##### 1.1 課題 freee 本体の MCP に Sign / Logikura を追加する際、freee 側のコードと相互依存させると、将来の freee 認証統合時に撤去コストが膨らむ構造になる懸念があった。 ##### 1.2 対応 ###### 1.2.1 代替案の比較検討 モノレポ（bun workspaces）／別リポジトリ／DI・プラグインアーキテクチャを代替案として検討。プロジェクト規模・共有コード同期コスト・抽象化コストとのトレードオフから、プロダクト単位のディレクトリ・ネームスペース分離を採用。 ###### 1.2.2 bin エントリポイントの分離 `--sign` フラグ等のモード切替ではなく、`freee-sign-mcp` / `freee-inventory-mcp` を独立コマンドとして分離。freee 側のエントリポイントにサイン・在庫の知識が入らない構造とした。 ###### 1.2.3 既存コード変更の最小化 freee 本体への変更を、コールバックサーバーのポート override と MCP 設定追加の汎用関数抽出の2箇所に限定。いずれも後方互換で freee 本体の動作に影響しない。 ##### 1.3 結果 - Sign で確立したパターンを Logikura に再利用し、開発工数を大幅圧縮 - 将来の freee 認証統合時の撤去対象が、プロダクト固有ディレクトリとスキーマ・リファレンスに閉じる構造を担保 #### 2. Remote MCP の二層 OAuth 設計とセキュリティ多層防御 ##### 2.1 課題 Remote MCP は MCP クライアントとの通信、および ninja-sign.com（サインの上流認可サーバー）との通信で異なる認証方式が必要。さらに公開サーバーとして SSRF・path traversal・PII 漏洩・impersonation の各リスクを潰す必要があった。 ##### 2.2 対応 ###### 2.2.1 二層 OAuth の設計 層1（MCP クライアント ⇄ Sign Remote MCP）は OAuth 2.1 AS として PKCE 必須・DCR 対応・JWT Bearer Token を発行。層2（Sign Remote MCP ⇄ ninja-sign.com）は confidential client（client_secret 保持・PKCE なし）として authorization_code / refresh_token grant を実装。 ###### 2.2.2 SSRF / path traversal の多層防御 MCP ツールに渡す path を Zod スキーマで API バージョンの prefix 始まりに制限し、絶対URL経由の Bearer トークン外部流出経路を遮断。path traversal（`..` / `%2e%2e`）は Zod refine と URL 組み立て後の pathname 再検証の二重ガードで拒否。 ###### 2.2.3 Impersonation 防止 Remote モードで認証コンテキストが取れない場合、ローカルファイルシステムのトークンへ fallback する経路を禁止。 ###### 2.2.4 PII 漏洩防止 サイン上流との通信エラー本文を先頭200文字に truncate。ユーザー識別エンドポイントのレスポンスを Zod schema で型検証し、id の型不正による Redis キー衝突を防止。 ##### 2.3 結果 - 重篤度 Normal 以下で PSIRT レビュー通過 - SSRF 攻撃 path（絶対URL／protocol-relative／API バージョン外）と path traversal を E2E QA で全て拒否確認 #### 3. 共有 Valkey での名前空間分離 ##### 3.1 課題 freee 本体と Sign Remote MCP が同一 Valkey（ElastiCache）を共用する構成では、キー衝突・rate-limit カウンター混入・意図しない eviction の波及などのリスクがあった。専用 Valkey を新規構築すると運用コストが膨らむ。 ##### 3.2 対応 ###### 3.2.1 prefix + RBAC の二段分離 サービス別のキー prefix で名前空間を分離し、加えて Valkey RBAC（IAM Role ACL）で各 Pod が自身の prefix 以外にアクセスできない権限を付与。rate-limit キーもサービス別 prefix に分離した。 ###### 3.2.2 maxmemory-policy の整合 本番 Valkey は `noeviction` デフォルトで稼働させ、cross-DB の巻き添え eviction を回避。ローカル開発環境の Redis にも同設定を適用し、本番挙動と整合させた。 ###### 3.2.3 観測の独立化 Datadog Agent を Node 単位で OTLP 受信する構成にし、freee 本体と Sign の OTel trace を独立観測。 ##### 3.3 結果 - 専用 Valkey 新規構築を回避しつつ、論理的な完全分離を実現 - 共有インフラでもクロスサービスの巻き添え障害が発生しない構成として SRE レビュー通過 #### 4. PSIRT / SRE との Design Doc 駆動合意形成 ##### 4.1 課題 Remote MCP は外部公開サーバーとして PSIRT のセキュリティレビューが必須。加えてインフラ（Istio Gateway、ALB TargetGroupBinding、WAF、ECR、ArgoCD）は SRE 領域で、アプリチーム単独では完結しない。同期ミーティングを増やさず、複数施策を並行で進める必要があった。 ##### 4.2 対応 ###### 4.2.1 Design Doc を起点とした非同期合意 ネットワーク経路・主要コンポーネント・二層 OAuth フロー・データモデル・セキュリティ対策・運用設計を1つの DD に集約し、PSIRT・SRE が非同期でレビュー可能な状態に整備。 ###### 4.2.2 やらないことの明文化 専用 Valkey 新規構築・Sign public API 修正・freee 認証化・複数 team 対応・モバイル対応・RDS 新規構築・既存 stdio モード変更を「やらないこと」として明記。スコープ境界を先に固めることで、レビュー観点を絞り込んだ。 ###### 4.2.3 重篤度の根拠提示 「重篤度 Normal 以下」の根拠を、ユーザー明示の MCP ツール呼び出しのみが書き込み発生・OAuth 2.1+PKCE 認証制御・ninja-sign.com 側 OAuth 二重防御・public API Rate Limit セーフティネット・実装済みセキュリティ対策の5点で構造化して提示。 ##### 4.3 結果 - DD 起点の非同期レビューで PSIRT・SRE 合意を獲得 - インフラ実装（CI workflow 4本、ECR、ArgoCD、Datadog APM）まで含めた本番デプロイ前提の設計が固まった #### 5. CRUD 単位の MCP ツール設計と Skill 自動生成 ― コンテキスト圧迫の回避 ##### 5.1 課題 freee と Oura の Public API は合計200以上のエンドポイントがある。MCP ツールを API エンドポイントに 1:1 対応させると、ツール定義だけで LLM のコンテキストウィンドウを圧迫し、実用に耐えなくなる。さらに、API 側のエンドポイント追加のたびに MCP ツール定義を手で増やす必要があり、横展開コストが高くなる構造だった。 ##### 5.2 対応 ###### 5.2.1 CRUD 単位へのツール集約 MCP ツールを `*_api_get` / `*_api_post` / `*_api_put` / `*_api_patch` / `*_api_delete` の CRUD 単位に集約。エンドポイント毎の専用ツールを作らず、path 引数で切り替える方式とした。これによりツール数は API エンドポイント数によらず固定（数個）に収まる。 ###### 5.2.2 API リファレンスの Skill 側への外出し 各 API エンドポイントの仕様（path・request/response schema・例）は Skill ファイル（Markdown）として持つ。OpenAPI スキーマからエンドポイント単位で Skill ファイルを自動生成するスクリプトを実装し、API 追加時はスクリプトを再実行するだけで反映される構造にした。ユーザーの自然言語要求は LLM が Skill を参照してエンドポイントを特定し、CRUD ツール経由で呼び出すフローとなる。 ##### 5.3 結果 - MCP コンテキストサイズを大幅に削減（200+ ツール定義 → 数個の CRUD ツール定義） - API 側のエンドポイント追加に対し、Skill ファイル自動生成のみで追従できる構造を獲得 - 同じパターンを Sign / Logikura / Oura に横展開し、別ドメイン API への適用を実証 #### 6. 個人 OSS による知見の汎用化 ― oura-mcp の自作公開 ##### 6.1 課題 freee-mcp で確立したパターン（ネームスペース分離 / configure 対話フロー / OAuth ブラウザ認証 / Skill 同梱 / クライアント自動検出）が、自分の理解として腑に落ちているかを検証したかった。社内案件のコンテキストに依存せず、別ドメインの API でゼロから組み立て直せるかが問いだった。 ##### 6.2 対応 個人プロジェクトとして [oura-mcp](https://github.com/YasuakiOmokawa/oura-mcp)（Oura Ring API v2 用 MCP サーバー）を設計・実装し、GitHub と npm で公開。 ###### 6.2.1 freee-mcp で得たパターンの転用 freee-mcp で確立したパターン一式（configure 対話フロー・OAuth・トークン永続化・主要 MCP クライアント設定の自動追記・Skill 同梱・CRUD 単位ツール + Skill 自動生成）を Oura ドメインに合わせて組み直した。 ###### 6.2.2 公開・配布の整備 MIT ライセンスで GitHub 公開、`@yasuakiomokawa/oura-mcp` として npm 公開（v0.2.1）。CI を GitHub Actions で構築し、MCP Registry への登録準備まで実施。 ##### 6.3 結果 - freee-mcp で得たパターンが別ドメイン・別組織のコンテキストでも通用することを自分で実証 - npm 公開・MCP Registry 登録準備までの一連の OSS リリースフローを個人プロジェクトで習得 - パターンを「他人の文脈に依存しない自分の道具」として定着させた ### 得られた知見 #### パターン化と再利用のポイント - 1つ目のプロダクトでネームスペース分離・bin 分離・既存コード変更最小化のパターンを確立すれば、2つ目以降は再利用で大幅に工数削減できる - 「3つ目のプロバイダ追加時にモノレポ or DI への移行を再検討」のような移行トリガーを Decision Log に書いておくと、将来の判断コストが下がる - 業務で得たパターンを個人 OSS として組み直すと、「他人のコンテキストへの依存」と「本当に身についた知見」が切り分けられる #### 共有インフラの名前空間分離のポイント - 専用インフラ新規構築の代わりに、prefix + RBAC + 設定整合の三段で論理分離すると、運用コストを抑えながら必要な隔離を実現できる #### Design Doc 駆動の横断合意のポイント - PSIRT・SRE が同期ミーティング不要でレビュー可能な粒度（ネットワーク経路図・脅威モデル・代替案却下理由・スコープ境界）に DD を整えると、合意形成のリードタイムが短縮できる - 「やらないこと」の明文化はレビュー観点を絞り込み、合意の収束を加速する #### LLM コンテキストを意識した API ラッパー設計のポイント - API エンドポイントが多いプロダクトを MCP 化するとき、ツールを 1:1 対応させるとコンテキストが圧迫されるため、CRUD 単位の数個に集約するのが有効 - エンドポイント仕様を Skill ファイル（Markdown）として外出しし、OpenAPI から自動生成することで、API 追加に最小コストで追従できる - 「ツール定義の肥大化」と「API リファレンスの参照可能性」のトレードオフは、LLM 側に検索を任せる構造で両立できる ### キャリアビジョンに対するふりかえり #### 具体的にやりたいことのアップデート - 業務で確立した設計判断を別プロダクトへ丸ごと転用できる粒度でパターン化し、個人 OSS で別ドメインへの適用を検証する動き方を身につけた - LLM コンテキスト制約を踏まえた API ラッパー設計（CRUD 単位ツール + Skill 自動生成）の型を獲得 - 共有インフラに後付けで論理分離（prefix + RBAC + 設定整合の三段）を入れる手法を獲得 - PSIRT・SRE 横断の合意形成を Design Doc 駆動で進めるスタイルを実践 #### 今後の課題 - freee 本体と Sign で重複している OAuthProvider / callback / http-server / redis-token-store の抽象化（撤退容易性とのトレードオフが論点） - 3つ目以降のプロバイダ追加時のモノレポ or DI への移行判断

### 概要 freeeサインは freee グループに Join したプロダクトでありながら、認証・ドメイン・ユーザー所属モデルが freee 基盤と分断されており、サインの今後の事業拡張に対して構造的なボトルネックになっていた。本プロジェクトでは、サインを freee ドメイン配下に移し、認証主体を freee ID に寄せ、所属モデルを freee 基盤と整合させる統合アーキテクチャを設計した。 ### 目指す利益 - freee 基盤を利用した横断機能開発が着手可能になる ### 解決したい顧客課題 - freee とサインで二重ログインが発生し、操作のロスと UX 低下を招いていた ### 担当 - 統合アーキテクチャ設計（ドメイン・認証・セッション・データモデル） - 段階リリース計画の再編 - 設計書からユーザーストーリー作成・タスク分解・スプリント計画・Jira 起票までの一貫リード ### 出した成果 - 送信者・受領者の8パターン Before/After 画面遷移図を FigJam で作成、TechLead/PdL/QA との体験整理を効率化 - Design Doc に「検討した代替案と却下理由」セクションを追加する型を確立、非同期レビューの質を底上げ - 同期ミーティングは初期の方向合わせ1回に収束、以降は Design Doc 起点の非同期レビューで進行 - 設計書からユーザーストーリー17件・タスク54件・19スプリント計画・Jira チケット50枚規模の起票までを一貫リード ### 成果に繋がった工夫 #### 1. 縮退設計の徹底 ##### 1.1 課題 統合期間中にユーザーがログイン不能になるリスクが最大の障害だった。サイン既存ユーザー、freee 連携済みユーザー、freee 未連携ユーザー、新規ユーザーの4状態が並存し、いずれの状態でも体験を壊さない設計が必要だった。 ##### 1.2 対応 ###### 1.2.1 並行稼働設計 旧ドメインを移行期間中は残置し、新ドメインを正規入口として確立。撤去条件を管理し、段階的に旧ドメイン依存を解消する設計とした。 ###### 1.2.2 例外状態の許容 未紐付け・未作成・同期遅延などの例外状態を許容し、フォールバック導線・自動補完処理で吸収。「ユーザーが突然ログイン不能になる状態を発生させない」を全 Phase 共通の前提として徹底した。 ###### 1.2.3 各 Phase でロールバック可能な状態を維持 致命的障害時に旧導線・旧ドメインへ即時フォールバックできる状態を組み込んだ。 ##### 1.3 結果 「ログイン不能ゼロ」という測定可能な目標を、開発・運用・CS 全関係者で共有できる共通言語として確立。 #### 2. 段階リリースの再編 ##### 2.1 課題 当初の Phase 0〜5 の6段階構成は、PdM/QA/SRE への説明と意思決定で認知負荷が高く、運用判断のオーバーヘッドになっていた。 ##### 2.2 対応 ###### 2.2.1 説明粒度と実装粒度の分離 外部説明・進行管理は Stage 1/2/3 の3段階に集約。実装側では Phase 0〜5 と Feature Flag で細粒度の制御を継続する二層構造を採用。 ###### 2.2.2 Go 条件を Stage 単位に定義 各 Stage の Go 条件（新ドメイン安定稼働率／既存ユーザーの freee ログイン移行率／旧 URL アクセスの誘導率など）を明文化し、判断の客観性を確保。 ##### 2.3 結果 説明・運用判断のコストが下がり、ステークホルダー横断の合意形成が円滑化。 #### 3. データモデル統合の不整合解消 ##### 3.1 課題 サインの Team と freee の Company が、データ生成順序によって整合しなくなる構造的な問題があった。 ##### 3.2 対応 ###### 3.2.1 データのあるべき姿を先に定義 To-Be のデータモデル（Team:Company = 1:1, FreeeUser:User = 1:1, TeamUser.role ↔ RoleAssignment.role_key）を先に確定。 ###### 3.2.2 データ生成順序のパターン列挙 freee 起点・サイン起点・並行稼働期の例外パターンを網羅し、各パターンでの整合性確保ルールを明文化。 ###### 3.2.3 データモデル・データクラス設計 Membership Builder（サインの権限を freee に反映させる常設同期コンポーネント）の設計土台を作成。 ##### 3.3 結果 Phase 1 以降の実装タスクを依存関係付きでチケット化できる状態に到達。 #### 4. CSRF / Cookie 移行戦略の明文化 ##### 4.1 課題 ドメイン統合に伴う Cookie 共有の論点が散逸し、セキュリティ要件の整理がされていなかった。 ##### 4.2 対応 ###### 4.2.1 freee 共通 CSRF 機構の採用 新ドメイン移行後は freee 共通 CSRF 機構を利用、state-changing API（POST 系）は全て CSRF トークン検証必須とした。 ###### 4.2.2 Cookie 移行の段階方針 新ドメインでは freee 共通セッション、旧ドメインは旧 Cookie で稼働、Phase 5 で旧 Cookie 完全廃止という三段階の方針を確定。 ##### 4.3 結果 セキュリティ要件を踏まえた移行計画として確立し、PSIRT レビューに通る状態を整備。 #### 5. プロダクト境界の設計判断 ― OEM の取り扱い ##### 5.1 課題 freeeサインの OEM 提供プロダクトは freee 基盤と関係ない領域にあり、ID/セッション統合のスコープに含めるか否かの境界判断が必要だった。 ##### 5.2 対応 OEM を別プロダクトとして切り出すことも代替案として検討したが、開発・運用コストが見合わなかった。OEM を同プロダクトに包含し、旧ドメインで継続稼働させる設計を採用した。 ##### 5.3 結果 OEM ユーザーの既存体験を維持しつつ、ID/セッション統合のスコープ境界を明確化。 #### 6. 認証・権限・招待のスコープ判断 ― 既存実装の継続採用 ##### 6.1 課題 サインは認証に devise gem を採用し、権限基盤・招待機能も独自実装で運用していた。これらの基盤をすべて freee 側に寄せるか、サイン側の既存実装を残すかの境界判断が必要だった。 ##### 6.2 対応 すべての基盤を freee に寄せる案も代替案として検討したが、以下の理由で却下した。 - サイン既存プロダクションコードへの改修範囲が過大（devise を捨てた認証実装の入れ替え、権限・招待の総書き換え） - ID/セッション統合という目的に対し、認証・権限・招待まで寄せるのはオーバーエンジニアリング - 既存実装に依存する周辺機能への波及リスクが大きい 採用した設計は、freee 側に寄せるのはセッション・認証主体・組織コンテキスト（Company/Membership）に限定し、devise による認証実装・権限基盤・招待機能はサイン側の既存実装を継続採用する方針とした。 ##### 6.3 結果 改修範囲を ID/セッション周辺に限定でき、既存機能の安定性を維持したまま統合を進められる設計に到達。 #### 7. ストーリー作成・タスク分解プロセスのスキル化 ##### 7.1 課題 設計書（Design Doc）からユーザーストーリー、タスク分解、依存関係図、スプリント計画、Jira 起票までを一貫してリードする必要があった。1〜2 名チーム × 19 スプリント規模の計画を設計者一人の頭の中で進めると、属人化のリスクがあった。 ##### 7.2 対応 設計書を起点とする一連のプロセスを Claude Code のカスタムスキルとして型化した。 ###### 7.2.1 ストーリー作成（/self-story-mapping） 設計書から Phase ごとにユーザーストーリーを抽出し、ユーザー視点のストーリー文・受入条件・依存関係・スプリント配置までを一気通貫で生成。17件のストーリー・依存関係図・19スプリントマッピングを得た。 ###### 7.2.2 タスク分解と Jira 起票（/self-jira-create） ストーリーマップから具体的なタスクを依存関係付きで分解し、Jira チケットの一括起票までを実行。54件のタスク・50枚規模の Jira チケットを起票した。 ##### 7.3 結果 - 設計→ストーリー→タスク→Jira 起票のプロセスを再現可能な型として確立し、属人化を解消 - 同じスキルを別プロジェクトへ横展開可能な状態に #### 8. 検証ハーネスのスキル化 ― 計画段階と実装段階の自律検証 ##### 8.1 課題 ID 統合プロジェクトは扱うユースケースが多く（送信者・受領者の旧/新ドメイン各ジャーニー × 新規/既存ユーザー × freee 未連携/連携済 × 単一/複数事業所など組合せが爆発する）、計画段階と実装段階の両方で網羅性を担保するのが難しかった。属人的な「気合の網羅」では、受入条件の漏れ・実装の意図ズレ・PR 規約のブレが避けられない構造になっていた。 ##### 8.2 対応 計画段階の網羅性検証と、実装段階の受入条件準拠・規約準拠を、4 つの Claude Code カスタムスキルとして型化した。 ###### 8.2.1 受入条件の生成（/self-acceptance-criteria） ユースケースを軸に、ユーザー視点の受入条件を網羅的に生成するスキルを作成。「画面遷移パターン × ユーザー状態 × 入力境界 × 例外パス」の組合せで漏れを防止する型を組み込んだ。 ###### 8.2.2 MECE レビューと QA プラン生成（/self-mece-plan-review） 生成された受入条件と設計を MECE 観点で逆算的にレビューし、未カバーのユースケースを検出するスキルを作成。検出結果はそのまま QA プランとして利用可能な形式に整理される。 ###### 8.2.3 実装の品質レビュー（/self-quality-review） 実装完了後に、生成された受入条件に対してロジックが網羅されているかを検証するスキルを作成。RuboCop/ESLint で検出できない設計レベルの問題（受入条件未カバー、エッジケース未対応、責務分離の崩れ等）を検出する。 ###### 8.2.4 PR 前の最終レビュー（/self-final-review） コミット前・PR 作成前のタイミングで、プロジェクト規約への準拠とコードパターンの一貫性を自律的に確認・修正するスキルを作成。 ##### 8.3 結果 - 受入条件生成（8.2.1）→ MECE 検証（8.2.2）→ 実装準拠チェック（8.2.3）→ 規約準拠チェック（8.2.4）の 4 段ハーネスが完成し、計画段階・実装段階の両方で AI が自律的に抜け漏れを検証する仕組みが成立 - ユースケースが多い領域でも属人性に頼らず、設計ロジックの漏れと実装の意図ズレを構造的に検出可能に - 「気合で網羅する」運用から「型で網羅する」運用へ転換 ### 得られた知見 #### 設計の構造化のポイント - 設計の規模が大きい時、「説明粒度」と「実装粒度」を分離すると意思決定コストが下がる - 縮退設計は「ログイン不能ゼロ」のような測定可能な目標で表現すると、関係者全員が共通言語で議論できる #### 非同期コミュニケーションのポイント - Design Doc に「検討した代替案と却下理由」を必ず含めることで、非同期レビューの質が大幅に向上する - 設計の結論だけを書くと、非同期レビューで「なぜその判断をしたのか」が伝わらず、結果として同期ミーティングが必要になる #### プロセスのスキル化のポイント - プロジェクト固有の進め方を「使い捨て」にせず Claude Code スキルとして型化すると、組織のアセットとして横展開できる - 計画段階と実装段階の検証を別レイヤーのスキルに切り分けると、疎結合に磨けて全体として強い検証ハーネスになる - 生成系スキルと検証系スキルを組み合わせると、属人的な網羅性に頼らず構造的に漏れと意図ズレを潰せる ### キャリアビジョンに対するふりかえり #### 具体的にやりたいことのアップデート - Design Doc 駆動と「検討した代替案と却下理由」セクション必須化により、複雑な仕様を非同期に伝えられる型を確立 - 縮退設計を「測定可能な目標」で語る型を獲得 - ストーリー作成・タスク分解のプロセスを Claude Code スキル（/self-story-mapping, /self-jira-create）として型化 - 計画段階の網羅性検証（/self-acceptance-criteria, /self-mece-plan-review）と実装段階の準拠検証（/self-quality-review, /self-final-review）を Claude Code スキルとして型化し、4 段の自律検証ハーネスを構築 #### 今後の課題 - 設計者交代時の引き継ぎ品質を高める仕組みづくり - ステークホルダー横断（PM/SRE/QA/Security）の合意形成プロセスの再現性確保

## 概要 以下2つのアプローチによるfreeeサインチームの業務効率化 - エンジニア向けClaude Code 並列起動開発プロセスの導入 - セールス職向けプロダクト仕様調査工数の削減 ## 目的 - エンジニアPR数増加 - セールス商談数捻出のための調査工数削減 ## やったこと - git worktree + git worktree runnerをベース技術とし、並列起動開発の環境構築スクリプトとworktree環境の構築スクリプトを作成。手順書をつくって展開し、ワークショップをエンジニア向けに開催。 - Devinを利用し、プロダクトリポジトリを読み込ませ、ソースコードベースで技術質問に回答できるように設定。その後、技術以外の質問に回答できるよう、プロダクト連携仕様やプランごとに使える機能の一覧をプロダクトリポジトリにインプット。 ## 成果 - チーム全体PR数を1か月あたり25%増加 - セールスの調査工数を1か月あたり41時間削減 ## 工夫 - もともとDocker前提の構築手順であったが、遅いので、Docker非依存の構築手順をつくり、さらにworktreeセットアップ手順を別に作った。結果、worktreeをセットアップしてからClaude Codeを起動させるまでの時間を3分 => 1秒以下にした。 - Devinへの非技術インプットが読める最大行数が5000件以下であることが判明した。かつ、Devinに検索キーワードを与えないとインプットを読んでくれなかった。そこで、もともと1ファイル3万件程度のインプットだったものを14ファイルに分割し、それぞれのファイルにDevinが検索しやすいようにキーワードを追加した。結果、14ファイルすべて単純なプロンプトで読み取れるようになり、回答精度が2.5% => 81%に増加。 ## 自身の生産性について - もともと3並列だったものを5並列にし、1か月50PR => 1か月100PRまで増加

## プロジェクト名 アプリケーションで利用するマルウェアスキャンのセキュリティ強化対応 ### 役割・主業務 <!-- 例）〜という課題があったため、〜を担当し、〜を行った。 --> アプリケーション既存のマルウェアスキャンは、s3アップロード後のイベント駆動で動作していたため、検体ファイルがs3にアップロードされてしまう。加えて、s3アップロードをイベントとしたlambdaで起動しているため、s3ファイルアップロード以外が起点となるアプリケーション操作までカバーしきれていない。 よって、ファイルアップロードが起点となるすべてのアプリケーション操作を、アップロード前のos一時領域に格納されたタイミングで検知し、パーミッションレベルでアプリケーションから隔離するcloudoneを導入。ファイルアップロード起点処理の全てに新しい検体検出ロジックを差し込むことで、ファイルアップロード前に安全にマルウェアを除去できるようにした。 ### 成果 <!-- 任意。定量的な数字があると良い。 例）〜を行った結果、MAUが〜%改善した。 --> SREと協業し、検出ロジックの適用箇所を調査。12箇所あった旧ロジックに新ロジックをラップする形でPR数を5に抑え、かつ、本番障害ゼロを達成。 また、cloudoneはローカル開発環境を用意してないため、ローカル開発用にclaude codeでエミュレートツールを作成。開発のリードタイムを抑えた。 ならびに、旧検出ロジックを削除するため、プロダクトのリポジトリとインフラリポジトリを並行調査して作成したインフラ構成図とterraform改修作業計画をSREにレビューしてもらい、アプリケーション層とインフラ層それぞれでインシデントゼロで旧ロジック削除を達成。

## 概要 Amazon EKS Cluster の バージョンアップデート業務。 自身の担当アプリケーションが動作するEKS Cluster のEOLに対応するため、バージョンアップデート業務を担当。 ## 目指す利益 - サービス無停止による運用損失コストゼロ - インシデントによるサービス損失コストゼロ ## 解決したい顧客課題 サービスを無停止でアップデートを完遂させ、運用品質を維持しつづける。 ### システムの具体的な内容： freeeではプロダクトの単位で、EKS Cluster を導入してクラスタ単位の運営をしています。アップデートの宣言ファイルは Terraform、k8sクラスタ構成管理はhelmfileで実施されています。クラスタデリバリーはArgo CDで実現します。運用監視ツールはDatadogです。 アップデートはローリングアップデートではなくブルーグリーンデプロイで実施します。そのため、システム停止を伴わずに実現できます。具体的な実現方式は以下の4手順により実施します。 1. 新クラスタ準備 - クラスタ構成のみ作り、node や pod は起動させない状態 2. 旧クラスタのweight切り替え - 旧クラスタのautoHeal を off にしてworkerとcronを停止、新クラスタのnodeとpodを起動させる 3. トラフィック切り替え - 段階的に新クラスタへのトラフィックを増やして切り替え完了 4. 旧クラスタの廃棄 アップデート時のトラフィック切り替えには [tentez](https://github.com/FeLvi-zzz/tentez) を使い、段階的なトラフィック切り替えを実現することで動的なサーバリソース割り当てを安全に実施できるように工夫されています。 以上の手順を、integration, staging, productionの3環境に対して実施します。 ## 担当 手順準備、スケジューリング、作業実施（ArgoCD操作、k8s cli操作、yamlファイル作成）、関係者調整まで一貫して担当。 ## 出した成果 - スケジューリング遅延、システムダウン、インシデント、すべてゼロで作業を完遂。 ## 成果に繋がった工夫 ### 1. コミュニケーションサポート 手順はSRE部隊が用意したものがあったが、自プロダクト用に最適化されていなかったので問い合わせを重ねつつ懸念点を払拭。 検証環境にて手順をすべて事前検証し、必要な作業時間を予測されるエラーログの情報をすべて手順書にフィードバックして、当日の作業トラブルをゼロにした。 ### 2. 安全安心なスケジューリング アプリケーションチーム、QAチーム、SREと連携し、インシデントの要因をすべて事前に潰した。アプリケーションリリースのタイミングと作業をずらしつつ、システムが高負荷な時間帯と、バッチジョブの高頻度な時間を調査してバッティングしないようにし、かつ、EOLの1か月前以内に収まるようスケジューリング。 ### 3. 切り替えのためのリソース設計 切り替えにおいては、新旧の2クラスタが並行稼働するため、リソースが溢れないように設計しました。Aurora Postgresql のmax_connectionとRedisのコネクション数が現稼働数の2倍を許容できるかを調査し、かつ、クラスタのjobワーカーが2重起動しないように作業実施しました（手動で片側のワーカーを止めるか、2重起動しても問題ないようにアプリケーションのジョブを改修するかで迷いましたが、工数をみて前者の作業を取りました） 以上です。

## プロジェクトの概要 ■ 概要 freeeサイン「新リース会計基準対応」機能の新規開発。契約書からリース該当性をAIで自動判定し、必要情報を自動抽出する機能。 参考） https://www.freee.co.jp/sign/new-lease-accounting/ ■ 背景 2024年から新リース会計基準が適用され、企業は保有する全契約書についてリース該当性の判定が必要になった。手作業での判定・情報抽出は工数が膨大で、経理担当者の負担軽減が求められていた。 ■ 技術スタック Ruby on Rails 7.2 / React + TypeScript / standard-ui（freee内製デザインシステム）/ LLM + AI-OCR / PostgreSQL ■ チーム構成 8名（Design 1名、PdM 1名、Eng 4名、QA 2名） ■ 担当 開発エンジニアとして実装全般を担当。Eng 4名中、フルスタック担当として、フロントエンド・バックエンド両方の設計・実装をリードした。 ■ 実績 4ヶ月で213件のPRをマージ。 ## 目指す利益 - 新リース会計基準対応市場でのシェア獲得 - freee固定資産とのクロスセルによる収益拡大 - Standard/Advance/Enterpriseプランの価値向上 ## 解決したい顧客課題 1. 初年度の判定作業が膨大 - 新規適用時、過去の全契約書についてリース該当性を確認する必要がある - 経理担当者の工数が膨大になる 2. 判定の複雑さ - 新リース会計基準の3要件（資産特定・経済的利益・使用支配権）の判定には専門知識が必要 3. 抽出作業の非効率 - 長文契約書から契約期間・リース料等の必須項目を手作業で抽出 - 入力ミスのリスクが高い 4. 監査対応の負担 - 判定根拠の記録・保存が煩雑 - 監査時の証跡提出に工数がかかる ## 出した成果 ### プロジェクト成果 1. **スケジュール2ヶ月前倒しでリリース達成** - 当初見積もり：12月末リリース → 実績：10月末にコア機能実装完了 - 見積もり根拠：過去の同規模機能開発（契約台帳機能）の実績工数から算出 - 前倒しできた要因：Claude Code活用による実装工数削減（詳細は後述） 2. **レビュー改善要望の8割を取り込み** - 前倒しで確保した2ヶ月を、ユーザー体験の改善に投資 - 操作の連続性、エラー体験、認知負荷、操作効率の4観点で40件近くの改善を実施 3. **品質確保** - QA期間中に24件のバグ修正PRを迅速にマージ - リリース後1ヶ月時点で重大バグ（業務停止・データ損失）0件 - 軽微な表示崩れ等は3件報告、即日対応 ### 生産性の変化 Claude Code導入後PR数5.2倍増加 ## 成果に繋がった工夫 ### 1. standard-ui（freee内製デザインシステム）の導入 #### 1.1 課題 - freee Signでは新UIライブラリ（standard-ui）の導入事例がほぼなかった - 既存のサンプルコードが少なく、開発効率が上がらない状態だった - Eng 4名のうち、サインへのstandard-ui導入経験者は0名だった #### 1.2 対応 自分がstandard-uiの技術検証と設計を先行して行い、チームに展開する方針を取ることにした。 ##### 1.2.1 アーキテクチャ設計 hooks/pages/templates層の責務分離パターンを設計した。standard-uiの制約上、コンポーネントにビジネスロジックを持たせると再利用性が下がると判断したため、以下の分離を行った： - hooks層：API通信のみ - pages層：ビジネスロジック・状態管理 - templates層：UI表示のみ ##### 1.2.2 チームへの展開 - 設計パターンをドキュメント化（CLAUDE.md含む1,443行）し、他メンバー3名にレクチャーを実施 - PRレビューで一貫性を担保 - 結果として、他メンバーからの「設計どうすればいい？」という質問が3週目以降ほぼゼロに ##### 1.2.3 開発元との連携 ライブラリの制約による不具合を3件発見し、開発元チームに報告・改善提案を行った。うち2件はプロジェクト期間中にライブラリに反映された。 #### 1.3 結果 - UI/画面関連で39件のPRをマージ（チーム全体の約7割） - 他メンバー3名もstandard-uiで実装できる状態になった ### 2. Claude Codeを活用した開発効率化 #### 2.1 課題 - 新UIライブラリの既存サンプルが少なく、手動でのコーディングでは開発速度が上がらない - 当初の見積もりでは12月末リリース予定だったが、スコープ追加の可能性があった - 開発とレビューを両立させる必要があった #### 2.2 対応 ##### 2.2.1 CLAUDE.mdによるコード生成精度の向上 グローバルCLAUDE.md（全プロジェクト共通）とプロジェクト固有のCLAUDE.mdを整備し、Claude Codeの出力品質を最適化した。 **グローバルCLAUDE.mdの設計方針**: - 過度なエンジニアリングの禁止：要求されていない機能追加やリファクタリングを抑制 - 簡潔な応答：冗長表現を排除し、実行と結果報告を優先 - コメント記載原則：「What」ではなく「Why/Why Not」を書かせる - ハードコーディング禁止：特定のテスト入力に依存しない汎用的な実装を指示 **プロジェクト固有のCLAUDE.mdの設計方針**: - hooks/pages/templates層の責務と分離理由を明記 - アンチパターンと、なぜそれが問題なのかを記載 - 実装例（Good/Bad）を具体的に提示 設計書もマークダウン化し、Claude Codeが仕様を理解した上でコード生成できるようにした。 **コード生成の実測値**: - 生成コードのうち、修正なしでマージできた割合：約30% - 軽微な修正（変数名、型定義等）でマージできた割合：約40% - 大幅な修正が必要だった割合：約30% - 「7割のコード自動生成」とは、上記の「修正なし」+「軽微な修正」の合計 ##### 2.2.2 並列処理によるプロンプト応答の高速化 CLAUDE.mdに並列化の指示を明記し、Claude Codeの処理を最適化した。 ``` # CLAUDE.mdに記載した並列化ルール - 独立したタスクは必ず並列実行せよ - 並列化可能: 複数ファイルの読み込み、複数の検索、複数のAgent起動 - 依存関係のあるタスク（読む→分析→修正）は順次実行せよ ``` また、モデルの使い分けを指示し、コスト削減と高速化を両立した： - haiku（軽量）：簡単な作業、定型作業、タスク分解 - sonnet（標準）：一般的な実装 - opus（高性能）：複雑な実装、重要な意思決定、設計判断 Exploreサブエージェントを活用し、コードベース探索時のコンテキスト消費を抑制した。 ##### 2.2.3 git worktreeによる3並列開発 git worktreeを利用してClaude Codeを3並列で動かす環境を構築した。 - worktree A：機能実装 - worktree B：バグ修正 - worktree C：レビュー対応 1つのタスクがClaude Codeの応答待ちの間に、別のworktreeで作業を進められるようになった。 ##### 2.2.4 Claude Skillsによるコードレビュー自動化 Claude Skillsを利用して、PRのコードレビューを自動化した。 - 差分を読み込ませてレビューコメントを生成 - 定型的な指摘（命名規則、型定義、コメント記載原則など）はClaude Codeに任せ、自分はロジックの妥当性に集中 #### 2.3 結果 - Claude Codeによる7割のコード自動生成を実現（修正なし30% + 軽微修正40%） - 当初見積もり4ヶ月 → 実績2ヶ月でコア機能実装完了 - 余った2ヶ月でレビュー改善要望の8割を取り込むことができた - 個人の生産性が3.8倍、レビュー含めた総合的な貢献が2.6倍に向上 #### 2.4 Claude Code活用の再現性 本プロジェクトで得た知見は、以下の条件で他プロジェクトにも適用可能と考える： - **適用しやすい条件**：定型的なCRUD実装、既存パターンの踏襲、テストコード生成 - **適用しにくい条件**：複雑なビジネスロジック、セキュリティクリティカルな実装、既存コードの大規模リファクタリング - **環境非依存の知見**：CLAUDE.mdによるルール明文化、並列化の考え方、人間とAIの役割分担 ### 3. ユーザー体験の改善 #### 3.1 課題 リースチェック機能は経理担当者が数百件の契約書を判定する業務フロー。1件あたりの操作ストレスが積み重なると、全体の業務効率に大きく影響する。 #### 3.2 対応 ##### 3.2.1 操作の連続性を確保（フロー改善） 経理担当者が「判定 → 次の契約書 → 判定 → ...」を繰り返す業務フローを想定し、操作の中断を最小化した。 | 改善内容 | ユーザーのストレス | |---------|------------------| | 「続けて入力」機能の実装 | 1件判定するたびに一覧に戻る手間を削減 | | レコード間移動時のフォーム値保持 | 入力途中で移動しても値がリセットされない | | 文書保管完了後のリンク表示 | 次のアクションへの導線を明確化 | | ページング時にテーブル部分のみ更新 | 画面全体のちらつきを防止 | ##### 3.2.2 エラー体験の改善 エラーが発生したとき、ユーザーが「何が問題で、何をすればいいか」を即座に理解できるようにした。 | 改善内容 | ユーザーのストレス | |---------|------------------| | エラーメッセージの日本語化・統一 | 英語や技術用語による混乱を防止 | | エラー時にユーザーアクションを追加 | 「どうすればいいか」を明示 | | バリデーションメッセージの改善 | 入力ミスの原因を具体的に表示 | | 403エラーメッセージの統一 | 権限エラー時の対応方法を明確化 | ##### 3.2.3 認知負荷の軽減 初めて使うユーザーでも迷わないよう、情報設計を改善した。 | 改善内容 | ユーザーのストレス | |---------|------------------| | 空状態UIの追加 | 0件時に「何をすべきか」を明示 | | ヘルプページへのリンク追加 | 不明点をすぐに解決できる導線 | | アイコンと説明文の追加 | 機能の目的を視覚的に伝達 | | 見出し文言・構造の修正 | 画面の階層構造を明確化 | | 不要な必須ラベルの削除 | 視覚的ノイズを削減 | ##### 3.2.4 操作効率の改善 繰り返し操作のストレスを削減した。 | 改善内容 | ユーザーのストレス | |---------|------------------| | 一括操作UIの実装 | 1件ずつ操作する手間を削減 | | チェックボックス→トグルボタンへ変更 | 操作の意図をより直感的に | | ダブルサブミット対策 | 誤操作による重複処理を防止 | | 一括操作の確認ダイアログUI改善 | 操作内容の確認を明確化 | #### 3.3 結果 - レビュー改善要望の8割を取り込み - QA期間中に発見されたUX課題を24件迅速に修正 - リリース後1ヶ月時点で重大なUXバグ0件 **効果測定の課題**： 本プロジェクトでは定量的なUX指標（タスク完了率、エラー率等）の計測基盤がなく、定性的な評価にとどまった。今後の課題として、UX改善の効果を定量的に測定できる仕組みの導入を検討している。 ### 得られた知見 #### Claude Code活用のポイント 1. **CLAUDE.mdの階層設計** - グローバル（全プロジェクト共通）：過度なエンジニアリング禁止、コメント原則など汎用ルール - プロジェクト固有：アーキテクチャ、責務分離パターンなど文脈依存ルール - 「何を」だけでなく「なぜ」を書くと精度が上がる 2. **並列化による効率化** - CLAUDE.mdに並列化ルールを明記し、独立タスクは並列実行させる - モデル使い分け（haiku/sonnet/opus）でコスト削減と高速化を両立 - git worktreeで3並列開発環境を構築し、応答待ち時間を有効活用 3. **レビュー自動化** - Claude Skillsで定型的な指摘を自動化し、人間は本質的なレビューに集中 - 結果としてレビュー数2.1倍、品質も維持 4. **AIツール活用の限界認識** - 生成コードの30%は大幅修正が必要 → 過信せず検証が必須 - 複雑なビジネスロジックは人間が設計し、AIは実装を補助する役割分担が有効 #### 新技術導入のポイント - 1人が先行して検証・設計し、チームに展開する方式が有効 - 開発元との連携は早めに行うと、プロジェクト期間中に改善が入る #### ユーザー体験改善のポイント 1. **業務フロー全体を想定する** - 1件の操作だけでなく、数百件を繰り返す業務フローを想定 - 1件あたり数秒のストレスでも、積み重なると大きな負担になる 2. **エラー体験は「次のアクション」まで設計する** - 「何が問題か」だけでなく「どうすればいいか」を伝える - 技術用語を排除し、ユーザーの言葉で説明する 3. **開発効率化で生まれた余裕をUX改善に投資する** - Claude Code活用で2ヶ月前倒し → その時間をレビュー改善要望の取り込みに使用 - 技術的な効率化は、最終的にユーザー価値に還元すべき ## リリース後の取り組み - CSVエクスポート機能の追加開発（外部固定資産システム連携用） - ユーザーフィードバックに基づくUI改善 - パフォーマンス最適化 ## 今後の展開 - 契約内容変更時の再判定機能 - 網羅性チェック機能（取引タグとの紐づけ） ## キャリアビジョンに対するふりかえり 本プロジェクトで、Claude Code活用による開発効率化と、ユーザー体験改善を両立できた。技術的な効率化で生まれた余裕を、ユーザー価値に還元するサイクルを回せることが自分の強みだと認識した。 ### 具体的にやりたいことのアップデート - ユーザーの業務フロー全体を俯瞰し、ストレスポイントを特定 - 技術的な実現可能性を踏まえた優先順位付け - 開発効率化とUX改善の両輪を回すチームづくり ### 今後の課題 - UX改善の効果を定量的に測定する仕組みの導入 - AI活用のベストプラクティスをチーム・組織に展開する仕組みづくり

## 概要 freee人事労務に、雇用契約の人的ミスを改善する目的で雇用契約周りの業務を効率化するサービスを以前に開発しました（[詳細](https://www.freee.co.jp/employment-contract/)）。 サービス開発後、ユーザーテストを重ねるなかで、雇用契約の文書手続きを一括で行いたい要望を多く頂きました。プロダクトマネージャと協議を重ね、文書を一括で作成・送信する機能を開発しました。 ## 目指す利益 年間繰り返し利益（ARR）の2000万円向上。 ## 担当 要件定義から設計、開発、品質保証（QA）、セキュリティテスト、リリースまで一貫してプロジェクトに関与しました。 特に、QAとセキュリティテストのコミュニケーションをリードし、仕様の認識齟齬をゼロに抑え、スケジュールを前倒ししてリリースすることができました。 ## 解決したい顧客課題 人材会社のユーザーさんを例に説明します。 ある人材会社では1回の雇用契約更新で、派遣社員300人が対象にされます。これまでの機能は社員1人を選択して文書の作成と送信を行うUXであり、1通の文書の送信が実施されるまでに5分程度の時間が掛かります。更新期間1ヶ月以内に担当者1人でこの業務を行うには、他の業務の中断を余儀なくされます。 そこで、更新期間1か月の間に300人分の文書を担当者1人で送信可能にし、他の業務に支障をきたさない状態にすることが理想となります。 ## 出した成果 - リリース期間を2か月前倒しできた - 上記の理想状態を達成した（[詳細記事](https://www.freee.co.jp/cases/kanemotogumi/)） ※人材会社ではないが、同様に業務効率を改善した例として掲載 ## 成果に繋がった工夫 ### 現実的な期間でリリースを可能にする設計をした 一括処理をするさい、リッチな設計にするにはPub/Subが必要となります。しかし機能リリースを入社シーズンに合わせたかったので、処理は非同期にするもののイベント駆動のUXはやめました。その代わり、社内でUX検証をしてユーザーが気づきやすいUIを実装してカバーしました。 また、一括処理の外部サービスへのリクエストは、外部サービスの過負荷を避ける方式にしました。外部サービスは社内プロダクトですが、負荷検証環境がないのでリクエストが並列で実施された時にどれだけ高負荷になるか見立てができません。加えて、大量の文書が一回で処理しきれず、ジョブのタイムアウトに抵触する可能性がありました。そこで、一回の処理の上限を100文書にしてタイムアウト制限をクリアし、かつ、リクエストを直列にして外部サービスの過負荷を避けるようにしました。一括処理の完了時間が並列処理と比べて延びてしまうデメリットについては、処理中に別の処理を実施できるようにしてユーザーのフラストレーションを減らす工夫をしました。 ### つくる機能とつくらない機能の優先順位を設定 当初は、3つのサブ機能が対象となっていました。このうち2つが一括処理に必要な根幹機能であり、残りの1つは一括処理のヒューマンエラーを防ぐための機能となります。 ヒューマンエラーを防ぐ機能はUXの設計にかかる時間が予測しづらかったので、まずは根幹機能のみ作成しました。その後、社内のメンバーに機能を試用してもらう会を開催し、課題を洗い出しました。その結果、「ユーザーは一括で作成したい訳ではなく、文書をミスなく確実に送信できることを確認したい」という知見を得ました。 言い換えると、ヒューマンエラーを防ぐ機能のニーズは曖昧だということがわかったのです。ヒューマンエラーを防ぐ機能を用意することよりも、そもそもヒューマンエラーが起こりえないUXにすることのほうが求められていると感じました。 結果、ヒューマンエラー防止機能はリリースから除外し、リリース後に文書送信のエラー率の分析とユーザーテストを実施してからUX設計することに決定しました。 ### 仕様の認識齟齬をゼロに抑える QA（品質テスト）とセキュリティテストは外部のチームの方に実施いただいてました。通常、外部とのやり取りはテキストコミュニケーションがメインであるため、5~10%程度の認識齟齬が発生しますが、それらの齟齬を対面コミュニケーションを増やすことでゼロにできました。 QAについては、設計文書を厚めに記載し、さらに日次でミーティングを開催しました。その結果、テキストコミュニケーションでは見落としがちな微妙なニュアンスの言語化コストを削減できました。さらに、言語化しきれない相手のニーズをこちらが再言語化し、テスト実施に必要な準備のオンボーディングをご提案しました。リリース後のふりかえりでは「コミュニケーションがしやすく、前回のリリースと比較してとても仕事がしやすかった」とフィードバックを頂きました。 セキュリティテストについては、開発完了一か月前からこちらの進捗を相手に細かく伝え、スケジュールの認識合わせを重ねました。さらに、テスト内容についてガイドラインを貰い、診断対象の処理やAPIの数、定義してあるコードの場所、UIでどこをクリックしたときに実施されるのかを詳細に文書化してテスト実施者の頭の手間を削減しました。加えて、機能のチュートリアル動画を撮り、対面でオンボーディングミーティングを実施し、テストがスムーズに進むようサポートしました。担当の方からは「とてもテストがスムーズに実行できる。3日くらい前倒しできそう」とフィードバックを頂きました。 テスト中はトラブルがありましたが、関係者を集めて当日中に問題解決できたのでリリース遅延はしませんでした。 ## リリース後にやったこと ### つくらないと決めた機能のニーズ調査 Datadogで単一処理のAPIの実施回数を見て、一括処理に必要か検討しました。大まかには一括処理での必要性は見えるものの、実際のユーザーアクションから分析したほうが効果的だと分かりましたので、Webアナリティクス用のイベントロガーを実装して現在データが溜まるのを待っています。 ### 設計文書作成のプロセス改善 設計文書を作成する工程に思ったより時間を使いましたのでふりかえりをしました。時間を使った理由は、設計文書がQAなどチーム外の方に向けた情報とチーム内に向けた情報が一緒くたに記載されていたことが原因だと分かりました。そこで、チーム外向けの文書とチーム内向けの文書を分けることにしました。次の開発では設計文書の作成時間を半分にできました。 ### セキュリティテスト環境の改善 テスト中のトラブルについてSREの方と一緒にふりかえりをしました。結果として、テスト環境は開発者が他の意図で使うことを想定した仕組みを流用していたために起きたと判明しました。テスト用の専用環境を作ることが根本解決につながると分かり、今後テストの頻度も多くなることが分かったため、現在はSREの方にテスト用の永続環境を用意いただきました。改善できた工数は、テストのトラブル解消に使った4hとテスト環境の準備に使った16hを合計して20hです。

## 概要 [freee](https://www.freee.co.jp/)のビジョンである[統合型経営プラットフォーム](https://corp.freee.co.jp/vision/)を実現するために、freee共通の認証システムを[freeeサイン](https://www.freee.co.jp/sign/)に導入してユーザー体験を向上させる ## 顧客規模 freeeの有料課金ユーザー[約46万事業所](https://corp.freee.co.jp/service/) ## 担当 マネージャー1、PdM1、エンジニア4のスクラム開発体制において、エンジニアとして参加。 ※ スクラムマスターは特定の人間に割り当てず、エンジニア全員が分担してやっている スクラムは1週間スプリント。イメージ図は[こちら](https://speakerdeck.com/yasuakiomokawa/huroxiao-lu-falsexiang-shang-karashi-merukai-fa-sheng-chan-xing-falsegao-mefang-mohuwakuwoyan-ete-how-to-go-on-high-peformance-with-mob-work?slide=7) ## 解決したい課題 ### プロダクトとして解決したい課題 #### 1. freeeユーザーの体験が悪いので改善したい ##### 1.1. freeeプロダクトのあるべき姿 freeeのサービスはアカウントを共通管理しており、1つのアカウントでログインすると他のプロダクトに追加認証なしで遷移できるようになっています。たとえば、従業員がマイナンバー登録を行いたいときは[freee人事労務](https://accounts.secure.freee.co.jp/login/hr)にログインして従業員情報ページから[freeeマイナンバー管理](https://accounts.secure.freee.co.jp/login/mynumber)のリンクをクリックして登録を行うように実装されていますが、このとき従業員はfreeeマイナンバー管理に追加でログインする必要はありません。理由として、freee人事労務とfreeeマイナンバー管理のアカウントは、[freeeプロダクト共通のアカウント管理基盤](https://accounts.secure.freee.co.jp)で管理されており、アカウントのIDとセッションがプロダクトで共通のものになっているためです。 ##### 1.2. あるべき姿に対して、現状のfreeeサインはどうなっているか 一方、freeeサイン（以下：サイン）は、freeeのアカウント管理基盤を利用しておらず、freeeサイン内部の認証システムを利用しています（実装は[devise](https://github.com/heartcombo/devise)を使っています）。サインを利用するにはfreeeアカウントのログインに加え、サインのログイン画面にも遷移してログインしなければなりません。この体験がユーザー離脱の可能性を高め、クロスセルの機会も損ねています。数字の面でも、サインはfreeeの他のプロダクトと比べると年次成長率が期待通りになっていません。[ファクトブック](https://corp.freee.co.jp/ir/05_factbook_jp.pdf)にはプロダクト単位のYoYは公開されていませんが、freee全体のYoYの成長率を考慮すると、サインのアカウントを共通基盤に統合することでプロダクトの成長とユーザー体験の向上が期待できます。 ###### （補足）プロダクトの現状が生まれた経緯 経緯として、freeeサインはもともと別の会社が作ったNINJA SIGNというサービスをfreeeがM&Aしたもので、NINJA SIGNからfreeeサインにサービス名を変更したタイミングではfreeeのOpenId Connectを使ってアカウント情報を連携をしていました。当時はアカウントを統合しようとしても開発規模の試算すら難しい状況でしたので、連携という形を選択しました。 ここからは想像ですが、M&Aから2年以上が経過し、freeeの中で統合体験を顧客に提供することが経営ビジョンとして明確になり、サインのIDセッション統合を現実的に進めることが経営価値として認識されるようになったのではないかと思います。 #### 2. freeeの他のプロダクトとシームレスな連携ができないので改善したい ##### 2.1. サインの現在のプロダクト連携機能の概要 サインは現在、freee会計とfreee人事労務と連携する機能があります。これらはサインの[Web API](https://ninja-sign.com/v1/docs)を会計と人事労務が実行することで実現しています。また、サインのサブスクリプション管理システムはfreeeのマイクロサービスに連携しており、これはfreeeのアカウント管理基盤サーバを[RP](https://www.ogis-ri.co.jp/otc/hiroba/technical/openid-connect/chap3.html)としてサインがOpenId Connectで実現しています。 ##### 2.2. 上記の状況によって起きている問題点 ###### 2.2.1. アカウント情報を連携する手間が発生している 連携プロダクトは、サインのWeb APIを実行してサインのアカウント情報を取得し、連携プロダクトのアカウントと紐づけて情報を管理しています。このため、連携プロダクトは、自プロダクトのアカウント情報とサインのアカウント情報を定期的に同期しなければならないので手間です。アカウントを統合することで、プロダクト連携の手間を削減します。 ###### 2.2.2. サブスクリプションデータを非効率な方法で連携している freeeのサブスクリプション管理システムは[zuora](https://www.zuora.com/jp/)をラッパーしており、zuoraの内部処理はある程度のベストエフォートを許容することで高パフォーマンスを実現しています。内部処理が失敗した場合、5-10分くらい置いてから再びアクセスすると処理が成功していることが多いです。この仕様により、サインは1分程度の間隔でfreeeのサブスクリプションシステムに通信をして情報を同期しています。しかし、この処理はあまり効率的ではありません。freeeのシステムにpub/subを実装すればより効率的です。 一方で、freeeのシステムは他の全プロダクトから使われるシステムであり、サインの都合だけで機能追加してもコストメリットが判断できません。サインの出す利益率がfreeeの全プロダクトのなかで最上位でないため、優先的にやるべきか判断しにくいのが理由です。 以上の問題を、サインがfreeeのアカウント基盤を導入してサブスクリプションデータを基盤から参照することで解決します。 ### プロダクトとして解決したい課題をふまえ、今回のプロジェクトで解決したい課題 #### サインの現時点の利益率に比べると、かなり規模の大きい開発が予想されるため、実施に踏み切れない 上記1と2の課題を解決するためにIDセッション統合を進めたいのですが、サインの利益率はfreee全体で最上位でない一方、IDセッション統合は誰も見通しの見えないくらいに大規模な開発が想像されており、誰がどのように舵を切って進めればよいか明確ではありません。 freee内部でも、他プロダクトのIDセッションを統合するという開発は前例がないので、どう進めていいのか具体的な案が出ない状況です。 そこで、IDセッション統合を実装するために、技術的な範囲でどれくらいの工数がかかるのかを見積もるのが今回のプロジェクトの目的となります。 ## 取り組み ### 見積もる方式を決定する サインのIDセッション統合を最初に検討したとき、我々のチームのマネージャーがfreeeのCTOに試算で9か月と説明しました。案は以下の3パターンを出しました。 1. freeeの共通基盤を取り入れたプロダクトをゼロから作り、現在のサインと並行稼働する時期を設けて9か月かけて移行を完了する 2. 現在のサインにfreeeの共通基盤を導入し、現在のユーザーを9か月かけて導入した基盤に移行する 3. freeeの共通基盤を取り入れたプロダクトをゼロから作り、離脱率の低い優良ユーザーを9か月かけて移行させる。それ以外のユーザーは現在のサインを引き続き使ってもらうが、2年程度の猶予期間を設けたのち、現在のサインをサービス終了とする CTOからは、「パターンをいくつ出しても、9か月の内訳（具体的な開発テーマとそれぞれの見積もり工数）がハッキリしないことには実施判断が難しい」と言われました。とはいえ、上記3パターンすべてを見積もるにはチームリソースが足りず、サインの全エンジニアのリソースを割けるほどのコストメリットが当時の段階で見極められなかったのでチームで担当するしかありませんでした。 我々のチームはfreeeの共通基盤について知識がなかったので、1の案は現実的でありません。2と3は見積りという意味ではやることが同じだと判断したので、作業範囲の絞れている2の「現在のサインにfreeeの共通基盤を導入し、現在のユーザーを導入した基盤に移行する」方式を見積ることに決定しました。 ### 開発テーマを洗い出すため、freeeの共通基盤を学習する 我々のチームにはfreeeの認証基盤の知識がありませんでしたので、マネージャーにお願いしてfreeeの他プロダクトのエンジニアにレクチャーしてもらうようにしました。 そこでわかったことは以下の通りです。 1. 課金単位の概念が、サインは「チーム」という単語を使い、freeeは「事業所」という単語を使っている 2. サインはユーザーとチームが1:1関係だが、freeeはユーザーと事業所が1:n関係である 3. freeeは、ユーザーと事業所を紐づけるMembershipというモデルを定義しており、このモデルに各プロダクトごとのRoleというモデルを紐づけることで、「プロダクト単位のユーザーと事業所との紐付け」を管理している 4. サインの現在のOIDC連携は、freeeの会計Roleを使っている。統合にあたっては、サイン用のRole、つまり「サインRole」を定義してやる必要がある 以上4点を判断材料にした結果、ユーザー/事業所/Membershipという3つのモデルを、サインのデータベース上で一対一に紐づけた状態をIDセッション統合におけるゴールとして定めました。 ### 学習した結果をもとに、開発テーマを導出する 定めたゴールから逆算し、テーマを導出しました。 1. サインは会計Roleとして連携しているため、アカウント連携についてfreee共通基盤との不整合が既に発生している。これを解消する設計を行う 2. freeeの認証基盤を構成するgemがサインに導入できるかを調査し、導入設計を行う 3. freeeの共通基盤は、事業所という概念がある前提で認証を構成する。サインのチームという概念とfreeeの事業所という概念を不整合なく読み替えるため、サインのデータベースにfreeeのデータをどのタイミングでどのように紐づけるかの設計を行う 4. freeeの認証基盤を構成する要素としてredisを使っている箇所があり、サインのredisとコンフリクトさせないための設計を行う さらに、上記4テーマを実現するうえで必要となる以下の4テーマを定義しました。 1. freeeはユーザーと事業所が1:n関係であるため、サインのチームもユーザーとの1:n関係に対応させる設計を行う 2. サインはOEM機能を提供しており、各サービスプロバイダの識別にサブドメインを使っている。しかしfreeeの共通基盤を使うには、サインのドメインを「freee.co.jp」にしないと共通基盤のCookieが参照できない（現在のドメインはninja-sign.comなのでドメイン移行も必要だが、作業の不確実性がそこまで高くないので今回の見積もりからは外しました）。よって、サブドメイン以外によるOEM提供のための設計を行う 3. freeeの認証基盤を使うため、サインが使っているdeviseによる認証をすべてdevise以外で出来るように変更する。具体的には、deviseが実現しているパスワード変更やユーザーアンロックなどの機能を、フルスクラッチで作成して最後にfreeeの認証基盤でセッション管理するよう置き換えるための設計を行う 4. サインには受領者ユーザーという概念がある。このユーザーは、サインにアカウントを持たなくても、文書を受領したり契約にサインを行うことができるように導入した概念である。データ的には、チームに所属しないアカウントとして定義されている。このアカウントは現在、サインのUserモデルにフラグを追加することで定義しており、データ移行の際に障害となる。具体的には、文書とチームの所属関係を定義するデータモデルが、チームに所属するサインのアカウントと受領者ユーザーアカウントを混同して扱っているのが理由である。このため、受領者ユーザーという概念を別のモデルに分離するための設計を行う 以上、メイン4テーマ + 付随テーマ4の合計8テーマについて見積もりを行うことに決定しました。テーマの決定にあたっては、チームのマネージャー、サインのPdM、エンジニア同士でミーティングを行い決定しました。 ### 考慮しなくていいこと（やらないこと）を決める PdMと話し合い、以下のことを決めました。 #### OEMとして提供しているプロダクトにサインアップしているアカウントは移行しない アカウントの扱いは考慮しないといけないが、統合の対象ではないと判断しました。OEMはfreee連携機能を提供していないからです。 #### SAML連携をしているアカウントは移行しない サインはプロダクト連携の方法としてSAMLを提供していますが、SAML認証を使っているアカウントはOEMの文脈に似ているため、IDセッション統合の対象外としました。統合を終えた後に扱いを判断します。 ### メインテーマ4つについて設計書（DesignDocs）を書く サインに以前導入した[DesignDoc](https://note.com/omokawa_yasuaki/n/nd07e43c3e24f)のテンプレートに沿って、上記のテーマについてDesignDocを書いてゆきました。開発テーマの導出の時点でタスクが具体的になっていた付随テーマ4つについては書きませんでした。 メインテーマを再掲します。 > 1. サインは会計Roleとして連携しているため、アカウント連携についてfreee共通基盤との不整合が既に発生している。これを解消する設計を行う > 2. freeeの認証基盤を構成するgemがサインに導入できるかを調査し、導入設計を行う > 3. freeeの共通基盤は、事業所という概念がある前提で認証を構成する。サインのチームという概念とfreeeの事業所という概念を不整合なく読み替えるため、サインのデータベースにfreeeのデータをどのタイミングでどのように紐づけるかの設計を行う > 4. freeeの認証基盤を構成する要素としてredisを使っている箇所があり、サインのredisとコンフリクトさせないための設計を行う 以下、1のテーマから順に説明します #### 1. サインは会計Roleとして連携しているため、アカウント連携についてfreee共通基盤との不整合が既に発生していることの解消 データ不整合が発生するタイミングは以下の2つです。 1. freeeアカウント連携時にサインのチームが連携しているfreeeの事業所に所属しているかチェックしていないために起こるパターン 2. freeeで事業所とユーザーの所属情報が変更されるとサインで変更を追えないために起こるパターン（freeeの他のプロダクトは共通のアカウントであるため、変更を追う仕組みを実装していない） サインのデータベースを調査した結果、不整合のパターンは現在3パターン存在しました。 1. チームと連携した事業所に所属していないfreeeユーザーでサインに連携しているパターン 2. freeeで事業所への招待が取り消されたfreeeユーザーでサインに連携しているパターン 3. freeeで事業所自体を削除したfreeeユーザーでサインに連携しているパターン 上記パターンを解消するためのユーザー操作フローを作成しました。フローを作成する経緯としては、freeeの規約ならびにサービス運用の倫理的な観点として「ユーザーの同意を得る必要があるため」です。そのため、ユーザーのサインインを契機として、移行の操作をユーザー自身で行なってもらうような導線を設計しました。 #### 2. freeeの認証基盤を構成するgemがサインに導入できるかを技術調査する まず、freeeのgemが存在するGitHubリポジトリの参照権限がサインのエンジニアになかったので、マネージャー経由で権限を付与いただくようお願いしました。その上で、gemのReadMeを参照して導入を試みましたがうまくいきませんでした。 ##### 2.1. freeeのリポジトリで公開しているgemをサインのリポジトリに導入することをfreeeは意図していなかったため、gemを適切にインストールする方法が確立されていなかった freeeの方に、GitHub Packagesで公開いただきそちらをサインにインストールしました。 ##### 2.2. サインのテストが落ちる freeeのgemを使ってgRPCの設定をしたところエラーが発生しました。調査したところ、利用を試みているactioncableがredis-rb v5のpub/subを設定する際に、freeeのgemの内部でRedisのソースコードを拡張して使用している箇所のSubscribedClientを参照してしまってエラーとなっていました。freeeのエンジニアの方に調査いただいた結果、Redisのソースコードをfreeeのgemに導入するさい、モジュール名を`Redis`のまま導入してしまったのが原因と判明しました。モジュール名を置換いただいてエラーが解決しました。 ##### 2.3. サインに導入しているgemをダウングレードしないとfreeeのgemがインストールできない freeeのgemが[faraday](https://github.com/lostisland/faraday)に依存しており、サインもfaradayを使っているので問題なくインストールできると思われましたが失敗しました。freeeのgemはfaradayのv1に依存していますが、サインのはv2に依存しているため、サインのfaradayをダウングレードしないとfreeeのgemがインストールできないことが分かりました。 しかしfreeeのfaraday v1は、freeeの課金システムのクライアントプログラムが依存しているため簡単にアップグレードができないとのことです。対応策としては、freeeの認証gemから課金情報の取得箇所への依存を外してOpenAPI経由で課金情報を取得するような構成にすることを検討いただくことにしました。 なお、どうしてもサインのfaradayのダウングレードが避けられない場合に備え、ダウングレードしたときの動作確認のタスクも工数見積もりしました。 #### 3. サインのチームという概念とfreeeの事業所という概念を不整合なく読み替えるため、サインのデータベースにfreeeのデータをどのタイミングでどのように紐づけるか設計する ##### 3.1. データのあるべき姿を決める 読み替えるデータは、ユーザーデータと事業所データの2つですので、以下の方針で読み替えることにしました。 1. ユーザーについては、freeeの認証gemからfreeeユーザーのデータを一意に特定できるidが取得できるので、サインのデータベースに存在するユーザーのidと紐づける中間テーブルを作成する 2. 事業所は、freeeの認証gemからユーザーの所属事業所をプロダクト単位で一意に特定できるidが取得できるので、サインのデータベースに存在するチームのidと事業所のidを紐づける中間テーブルを作成する ##### 3.2. データの生成順序のパターンを決定します 以下の3パターンに決定しました。 1. freeeの他のプロダクトを使っているがサインを使ってないfreeeユーザーがサインにアカウント登録するケース 2. サインにアカウントが存在するユーザーがfreeeアカウントと連携するケース 3. データを紐づけるタイミングはユーザー操作を起点とします（サービスの規約に対応するため）。ただ、サインの既存機能でfreeeアカウント連携（OIDC連携）をしているサインのユーザーは規約に同意したものと判断できるので、backfillで対応します ##### 3.3. データモデル作成 ER図を作成し、メンバー間で共有しました。 ##### 3.4. データクラス設計 調査したところ、サインの既存機能であるfreee連携機能のモデルクラスのデータ生成タイミングと同様のタイミングで中間テーブルデータを作成することで対応できそうでしたので、既存のモデルクラスを改修することで対応します。具体的には、モデルクラスに`after_save` フックを適用して新規データを生成します。 ##### 3.5. タスクを洗い出す 以下の12タスクを洗い出し、見積もりました。 1. ユーザーを特定する中間テーブルの作成 2. 事業所を特定する中間テーブルの作成 3. モデルクラスの作成（ユーザー用） 4. モデルクラスの作成（事業所用） 5. 既にfreee連携を実施しているユーザーのデータを使って中間テーブルのデータをbackfillする 6. 中間テーブルが存在したら既存のfreee連携データを削除できないようにする。既存データは過去に実装した課金基盤統合で課金情報の取得に使っているため、完全に移行しきる前にこのデータを削除するとシステム障害となる 7. freeeの共通アカウント管理画面から、サインのアカウント登録機能を追加する 8. 今回新しく作成した中間テーブルからデータを取得し、テーブルがなければ既存の連携データからチームを取得するような事業所取得クラスを作る 9. 8と同じ要領でユーザーデータを取得するクラスを作る 10. 既存のfreee連携データを使ってチームとユーザーを取得する箇所をサインのソースコードから洗い出す 11. 既存のfreee連携データを使ってチームとユーザーを取得する箇所を、新しく作成した取得クラスへ置き換える 12. サインロールをfreeeアカウント管理に追加するよう依頼する #### 4. freeeの認証基盤を構成する要素としてredisを使っている箇所があり、サインのredisとコンフリクトさせないようにする 調査した結果、freeeの認証基盤は内部的に旧認証と新認証をそれぞれ使っていることがわかりました。当時は新認証の移行段階であり、旧/新の認証の設定が必要で、旧認証のほうがredisを認証基盤の内部で混在して使用していました。そのため設定が必要でした。 しかし、現在はすべて内部的に新認証を使って設定するようになっています。新認証はredisをラップする構成を取り、新認証を使うのであればredisの設定を完全に新認証の内部に隠蔽できるようになりました。よって、旧認証の設定であるredisの設定は不要ということが判明しました。 ### 設計したテーマを見積もる 主にメインテーマ4つを調査し、設計書を書き、タスクに分解して見積もりをした結果、タスクのストーリーポイントは合計で502ポイントとなりました。我々のチームのベロシティは1週間スプリントでだいたい18ポイントなので、27週間（6ヶ月）かかる見積もりを出しました。見積もりを出す期限が決まっていたせいか、見積もりの精度は35-40%程度です。あと100ポイントくらいは増える可能性はありますが、IDセッション統合を前に進めるための材料としては適切とCTOに判断されました。 ※ 付随テーマ4つに関しては見積もりまで完了できませんでしたが、メインテーマ4つでIDセッション統合の全体工数の6割以上を占めるということをCTOと認識合わせしていました。そのため、付随テーマの見積もりが完了しきらなくてもどう進めるかの検討は出来そうだと判断されたようです。 ## 出した成果 - IDセッション統合の技術的な課題とやること、現実的な期間の見通しが出たことで、次に何を決定しなければならないか明確になりました。 - IDセッション統合を現実的に進めるために関係各所が議論するための判断材料を提供できました。 やることのメリット/デメリットを検討し、現実的にエンジニアのリソースをどれだけ確保していつまでに統合しきるのかについて、工数見積もり後の1ヶ月以内に経営陣に決定させるよう後押しできました。 ## 成果につながった工夫 スプリントレトロスペクティブを繰り返してみて、我々のチームにはいくつかの工夫のパターンが見られました。 ※ 我々はレトロの手法に[KPT](https://shiftasia.com/ja/column/kpt%E3%81%A8%E3%81%AF/)を採用していますので、以下、KPTの用語が登場します。 おおきく3つに分けると、`モチベーションの維持`、`ちょくちょくふりかえる`、`ゴールをきちんと定めてから行動する`です。これらの工夫を行なった結果、メインテーマ4つを1ヶ月で設計して工数見積もりまで完了させることができました。 以下、それぞれの工夫を解説します。 ### モチベーションの維持 プロジェクトの前半において、メインテーマは4つに絞ってそれぞれチームメンバーをアサインしたものの、各自で調査をするときに小さなゴールを設定しきれず、なかなか進捗が出ませんでした。 普段の開発では、タスクを設定するときに準備条件と完了条件を定めるようチームでルール化しています。こうすることでアサインしたメンバーのモチベーションを高め、進捗のスピードを上げやすくすることが狙いです。しかし今回のテーマは不確実が大きすぎて準備条件も完了条件も定めることができず、メンバーもフラストレーションを感じ進捗も思うように出ませんでした。 プロジェクト開始当初のKPTのProblemを抜粋すると、以下の記述があります。 ``` 暗中模索みを覚えていて水中を突き進む感じがあるのでしばらくは産みの苦しみ ``` 当時着手していたタスクと見ると、スプリントプランニングで21ポイントがついていました。通常の開発であれば5ポイント以上のタスクは分割することをガイドラインとして定めてましたが、今回は分割できるほどタスクについての知識が無かったので、調査をしつつ課題が出たらそれをタスクにしていく方式で調査を進めました。 とはいうものの、何もアウトプットや課題が可視化できずに敗北感を味わうような日もありました。そこで、デイリースクラムやslackで積極的に自分たちの達成できたちょっとしたgoodをアウトプットするようにしました。たとえば、アウトプットを意識するようになった当時のKPTには以下のgoodが出ました。 ``` freeeの認証ライブラリ使って色々やってるんだよ的な機能の解説で少し安心というか脱・暗中模索感が10%ぐらいあった ``` このgoodは、freeeの認証gemを動かしてアカウントデータを取得できたときの喜びが表出されています。このように、ほんのちょっとしたことでも「自分達は進捗しているんだという意識づけ」に繋げることができました。加えて、KPTのときにはメンバーの日常生活で良かったこともgoodとして出すようにしました。具体的には以下のような感じです。 ``` 誕生日プレゼントもらいました。ありがとうございます! ``` 今まで我々のチームが取り組んだプロジェクトの中で最も不確実性が高いものだったので、細かい達成感を得られる機会を意図的に設けてモチベーションが維持されるようにしました。 ### ちょくちょくふりかえる レトロのProblemで以下の意見が出ました。 ``` そもそもゴールは本当に明確になっているのか？という疑問はある。どれだけタスクをこなしても向かっている先が違っていると困る ``` チームでも「たしかにそうだよね」という話になりました。不確実性の高いプロジェクトでしたので、1つ調査が進むと1つ不明確な点が出てくる、みたいな気が滅入る状態を私も含めみんな経験していたようです。 そこで、もともと1週間だったスプリントを3日にしました。レトロの頻度がこれまでの2倍になった計算です。デイリースクラムで毎日課題や状況の共有はしていましたが、「じゃあ次どうする？」といったネクストアクションに結びつけるための深いふりかえりができない状態だったことや、1つ調査が進むと1つ不明確な点が出てきて変化が激しかったので1週間スプリントは遅すぎると思ったのが理由です。 3日にした効果として、主に技術調査の進捗が大きくスピードアップしました。たとえばfreeeのgemをインストールするときにRedisのエラーが起きたとき、デイリースクラムでは解決策が見出せず、担当したエンジニアも「とりあえず一人でなんとか頑張る」状態でした。しかし3日スプリントにしてKPTでふりかえりをしたとき、「freeeのエンジニアの人に皆んなで聞いてみようか」という意見をチームから出すことができました。その結果、3日悩んだエラーの原因が30分のミーティングで判明し、1日後に解消いただきました。 その後のレトロで「もう少し早くfreeeの方に聞けたらよかった一方、組織が違うと気軽に聞きづらいのでみんなで聞けてよかった」という意見が出ました。もともとfreeeサインは別の会社が作ったプロダクトである関係で、我々のチームはfreeeサイン株式会社の所属で、相談した方はfreee株式会社の所属なのです。そのせいもあって、会社間で変に遠慮が発生することがありました。しかし実際に話を聞いてみたらfreeeのエンジニアの方は気さくで親切でフットワークも軽く、今後も積極的にコミュニケーションを取っていこうと思えた体験でした。 ### ゴールをきちんと定めてから行動する メイン4テーマの調査をするうち、優先度が頻繁に変わりました。たとえば、データ不整合と読み替えのテーマに関しては、データ不整合のパターンが明確になってデータの紐付けパターンが明確になった時点で読み替えの必要が薄れたため、テーマの優先度を下げたり、逆に後になって「パターンは明確になったけど、そのパターンのデータは実際にどう作るの？」という疑問が出たときは優先度を上げて対応したりといったことが起こりました。 我々のチームはアプリケーション基盤を扱うため、顧客や事業部、他のチームのエンジニアからの問い合わせが常に発生しています。今回のプロジェクトにかけられた実際のリソースは70%くらいで、残りはそれらの問い合わせ対応やfreeeの基盤を導入した開発環境を整備するためのリファクタリングに費やしていました。 そのため、スプリントゴールを重要視して「いま何をゴールとすべきか」の共通認識をとるようにしました。結果として、チームがバラバラにならず、メインテーマに集中できました。 ## 全体を通しての所感 今回のプロジェクトでは、技術調査以外はすべてモブワークを推進し、設計書を書くときも含めてすべてエンジニア4人で行いました。そのせいか、情報共有のスピードやふりかえり後のネクストアクションの決定のしやすさは以前に担当した他のプロジェクトと比較して早く進められたと認識しています。モブワークに関しては、以前実施したときに、メリットも大きいですが[デメリットも同じくらい大きい](https://note.com/omokawa_yasuaki/n/n46d4227e9ee5#c02e6309-2b79-4952-875b-1799e5deb8ca)と感じましたので使い所が難しいですが、今回のように不確実性が高く状況が頻繁に変化する状況においてはメリットが大きい方法だと再認識できました。 私は、[アジャイルの12の原則](https://agilemanifesto.org/iso/ja/principles.html)のなかで以下の原則を最も大事にしています。 ``` アジャイル･プロセスは持続可能な開発を促進します。 一定のペースを継続的に維持できるようにしなければなりません。 ``` 今回のプロジェクトはチームにとってかなり大きな負担をかけたので、持続可能という観点ではチームに私が貢献できるところはまだまだあると思いました。じっさい、見積もりが終わってチームに「このペースでどれくらい仕事できますか？」と訊いたところ、1ヶ月が限界だと言われました。当時のKPTで出たProblemを抜粋します↓ ``` - ここ最近疲れた。ちょっとこれで継続は合理的でない=ベストじゃない感があるので今後はこのあたりを調整してベストを尽くすようにしたい - 今回に限らず、突発＆締め切りがすでに決まった状態で降ってくるものがあると辛い ``` 個人的にもかなりメンタルに負荷をかけてしまったプロジェクトでしたので、今後は持続的な価値提供ができるチーム体制の構築を個人課題としていきたいと思います。加えて、チームの扱うテーマが広くなったせいで差し込みタスクや並行テーマが多い点も、安定したチームパフォーマンスの実現には好ましくないので改善を検討しています。 以上です。 最後まで読んでいただきありがとうございました。

## 概要 会社のビジョンにマッチするターゲット顧客として、個人事業主向けのサービスプランを用意し、オンデマンドで利用できるようにする ## 顧客規模 既存サービスに存在する潜在顧客30万人 ## 担当 8人チームの中でバックエンドをメインで担当。 バックエンドとフロントエンドの割合は8:2程度。 ## 課題 ### 1. 個人事業主へアプローチするプラットフォームがない - freeeサイン（以下：自サービス）は法人向けであり、個人事業主向けのプランがない。 - ミッション実現のためスモールビジネス市場を開拓したかったが、実現するためのプラットフォームがなかった ### 2. 必要な作業を自動化できていない - サブスクリプションサービスであるものの、Stripe Billingなどのサブスクリプション決済サービスを導入しておらず、請求情報は手計算していた。 - 個人事業主にはオンデマンドでサービスを提供しないと機会損失になる。請求を手計算するとコストメリットもスケールメリットも得られない ### 3. 既存サービスの顧客に、シームレスにサービスを提供できない - 自サービスはfreee会計（以下：外部サービス）との連携を強化して、外部サービスが持つ顧客に価値提供をする狙いがあった。 - しかし外部サービスとの連携機能がないため、価値提供ができない状態だった ## 取り組み ### 1. 「個人事業主へアプローチするプラットフォームがない」への対応 #### 外部サービスの課金単位と自サービスの課金単位をマッピング - 自動課金したときの連携情報を一意で把握できるようにした。 - サブスクリプション管理サービスであるzuoraを導入し、請求業務などを自動化できるようになった。 ### 2. 「必要な作業を自動化できていない」への対応 #### 自動課金機能の実装 - 課金情報を自サービスと連携してＤＢに保持 - 具体的には、Web APIを外部サービスに実装して自サービスから呼び出し、呼び出した結果を判定して自サービスのプラン情報データベースを更新して連携。 #### 実装した効果 - 手計算の業務時間である月30時間のコストをゼロ時間にした - 営業コストは月30万減少 - マーケティング効率は150%向上した ### 3. 「既存サービスの顧客に、シームレスにサービスを提供できない」への対応 #### 外部サービスアカウントを使ったシングルサインオンの実装 - 外部サービスのアカウントを使ってシングルサインオンを実現 - 外部サービスの持つ情報をスムーズに自サービスへ取り込みやすくした ## 工夫した点 #### 1. 外部サービスアカウントを使ったシングルサインオンの実装での工夫 ##### 1.1 セキュリティ対策 - OAuth2認証でシングルサインオンを実装しようとしたが、[セキュリティリスク](https://tech-lab.sios.jp/archives/13002)の問題からOpenID Connectで実装することにした ##### 1.2 工数削減 - 既存システムには[Doorkeeper](https://github.com/doorkeeper-gem/doorkeeper)を用いたOAuth2プロバイダがあったので、[OpenID Connect拡張](https://github.com/doorkeeper-gem/doorkeeper-openid_connect)を使って実装工数を50%程度削減しつつ実装できた ##### 1.3 ライブラリを使って実装の正しさを確認 - シングルサインオンのクライアントにはOpenID Connect拡張で推奨されている[omniauth_openid_connect gem](https://github.com/omniauth/omniauth_openid_connect)を使用 - 実装内容の正しさを素早く確認できた。たとえば、OpenID Connect拡張を使って実現した認可URL生成が[RFC](https://tools.ietf.org/html/rfc6749#section-3.3)と異なっていることを低コストで発見できた ##### 1.4 使用する技術について効率的な学習を実施 - OpenID Connectの実装を理解するため、omniauth_openid_connect gemを読んで得た知見を[登壇](https://speakerdeck.com/yasuakiomokawa/how-to-implements-csrf-detection-on-web-api)してアウトプット - 実装でつまずきそうな箇所を知ることができたので2週間程度は実装工数を前倒しできた - 登壇後は[感想ブログ](https://note.com/omokawa_yasuaki/n/ncdc97b3e4baa)を書いてふりかえりをした #### 2. 自動課金機能の実装での工夫 ##### 2.1 同期処理のエラー対策（冪等性確保対策） Zuoraは課金情報を登録するときにタイムアウトが発生しやすい。課金に失敗したときに同期用のWeb APIコールを実施したら同期エラーとなる。そのため、エラーにならないよういくつか案を検討した 1. (不採用)Webhookをzuoraを中継するシステムに導入する 1.1. zuoraとの連携が難しい 2. (不採用)自サービスのトップページに遷移したら同期処理を走らせるよう実装し、ユーザにはシステムメッセージでトップページに遷移してもらうよう促す 2.1. あまりにもユーザビリティを損ねる 3. (採用)画面遷移が実施されるたびに同期処理ジョブをSidekiqのlow-priorityキューに格納して同期処理を行う 3.1. toC向け以外の機能にも処理負荷が掛かるデメリットを受け入れた上で、リアルタイム同期に近い状態を作り出せるメリットを採択 #### 3. スケジュールを守るための工夫 - 進捗の遅れを挽回するためにモブワークを導入し、リードタイムを185%向上させた - 詳しい内容は[こちら](https://speakerdeck.com/yasuakiomokawa/huroxiao-lu-falsexiang-shang-karashi-merukai-fa-sheng-chan-xing-falsegao-mefang-mohuwakuwoyan-ete-how-to-go-on-high-peformance-with-mob-work)を参照