## 概要
[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を抜粋します↓
```
- ここ最近疲れた。ちょっとこれで継続は合理的でない=ベストじゃない感があるので今後はこのあたりを調整してベストを尽くすようにしたい
- 今回に限らず、突発＆締め切りがすでに決まった状態で降ってくるものがあると辛い
```
個人的にもかなりメンタルに負荷をかけてしまったプロジェクトでしたので、今後は持続的な価値提供ができるチーム体制の構築を個人課題としていきたいと思います。加えて、チームの扱うテーマが広くなったせいで差し込みタスクや並行テーマが多い点も、安定したチームパフォーマンスの実現には好ましくないので改善を検討しています。
以上です。
最後まで読んでいただきありがとうございました。