## 概要
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です。