広く複雑なプロダクトの 高速キャッチアップに取り組む

今回はプロダクトの領域が広く、複雑な場合に、効率的に業務知識を得るために、どのような取り組みをしているのかということについて話したいと思います。 現在私が、開発メンバーとして加わっている人事労務freeeもプロダクトとして大きくなってきており、またプロダクトに関わるメンバーも増えてきました。そうなってきたとき、プロダクト領域の広さと複雑性から必要な業務知識の量も多くなってきました。結果として、当時、多くの問題が起こっていました。今、その問題を解決するために、『DDDなどの設計手法を用いて、実装と業務が一致したモジュールに分割することで必要な業務知識を少なくする』という取り組みを行っていますが、そこに至る道筋は単純ではありませんでした。
今回はこの取り組みに至るまでの仮説検証をどのように行ってきたのかということについて話していきたいと思います。　

Transcript

1. 広く複雑なプロダクトの 高速キャッチアップに取り組む 2018.07.10 freee株式会社 moai
2. 2 今日話すこと DDDなどの設計手法を用いて、 実装と業務が一致したモジュールに分割することで 必要な業務知識を少なくする という試みを行っています。 しかし、そこに至るまで様々仮説検証が必要でした。 今回はこの仮説検証の話をしようと思います。 (DDDの話はしません。)
3. 2015/10月にfreeeにjoin。 現在は人事労務freee開発チームで 要件定義・設計・実装・運用に携わる。 3 山崎遼介 moai freee株式会社 エンジニア
4. 4 人事労務freeeについて • 変革しようとしていることって？ • この変革のために乗り越えなければならない常識の 壁って？
5. 5 人事労務freeeは何を変革するソフトか？ 非生産的な定型業務をなくし、 生産的な業務に集中できるようにする 非生産的な定型業務 • 書類作成 • 給与計算 生産的な業務 • 従業員の目標設定 • 評価制度
6. 6 なぜ非生産的な定型業務が多いのか？ • 書類が多い • ステークホルダーが多い
7. 7 書類が多い 入社手続きにおいては、最低11枚の書類を取り扱う • 雇用条件通知書 • 雇用保険被保険者証 • 年金手帳 • 源泉徴収票 • マイナンバー • 扶養控除等異動申告書 • 給与支払報告・特別徴収にかかる給与所得者異動届出書 • 被保険者資格取得届(健康保険) • 健康保険被扶養者（異動）届・ 国民年金第3号被保険者 資格取得等届 • 被保険者資格取得届(厚生年金) • 資格取得届(雇用保険)
8. 8 ステークホルダーが多い 書類のやり取りするステークホルダーは大まかに6つもある。 一人の従業員を入社したら、従業員+5つの機関とやり取りする。 • 雇用条件通知書 • 雇用保険被保険者証 • 年金手帳 • 源泉徴収票 • マイナンバー • 扶養控除等異動申告書 • 給与支払報告・特別徴収にかかる給与所得者異動届出書 • 被保険者資格取得届(健康保険) • 健康保険被扶養者（異動）届・ 国民年金第3号被保険者 資格取得等届 • 被保険者資格取得届(厚生年金) • 資格取得届(雇用保険) 従業員 税務署 市区町村 健康保険組合 年金事務所 ハローワーク このやり取りを従 業員の人数分
9. freeeの場合 • 品川区 • 関東IT健保
10. 10 乗り越えなければならない常識の壁は？ 業務が複雑 ↓ 業務知識が多く必要
11. 背景 11 きっかけは何だったのか？ • 様々な仮説検証を行うことになった問題意識は何？
12. 12 様々な仮説検証を行うことになった問題意識は何？ サービススコープの拡大、 開発メンバーの増加をきっかけに 『業務知識が足りない』、 『人事労務freeeの実装方法への理解が足りない』ことによる 問題が多く起こったから。
13. 13 フェーズは１→10 (2017/8) もともとあった給与計算機能を軸に 周辺機能だった勤怠、社会保険の手続きを強化する
14. 14 スコープの拡大に伴い、メンバーの増加 3人から13人になる
15. 15 しかし、ここで問題がおこる サービススコープが広がる。 → 必要な知識の領域は広がる。 しかし、開発者は必ずしも人事労務freeeの開発に詳しくない。 よって、 『業務知識が足りない』、 『人事労務freeeの実装方法への理解が足りない』 ことによる 問題が多く起こることになりました。
16. 16 バグがバグなのか分からない① 退職月に2カ月分の保険料が引かれる 給与から 2カ月分の健康保険料が 引かれています。 間違っていないですか？ 一見バグのようだが バグではない
17. 17 バグがバグなのか分からない② 家族は2人しかいないのに扶養親族等の数は3になる。 家族は2人しかいないのに 扶養親族等の数が3になっています。 間違っていないですか？ 従業員 (男) 妻 子供 (障害者) 一見バグのようだが バグではない
18. 18 修正の影響範囲がよくわからない 全てのロジックがつながっているため、 修正箇所の影響がどこに及ぶのかよくわからない。 • 勤怠が給与明細に転記されるのは理解できるが • 社会保険の書類の数字にまで影響するのは想像が難しい。 勤怠 給与明細 社会保険の 書類の数字 転記 転記 出勤簿 給与明細 月額変更届
19. 何か対策を考えなければ
20. 20 ターニングポイント：足りない問題の解決 1→10のフェーズになる ↓ 業務知識が足りない 実装方法への理解が足りない ↓ 解決しよう!!
21. 仮説検証 21
22. 22 22 どのように仮説検証していったのか？ 結果的に3回の仮説検証を経て 『実装と業務が一致したモジュールに分割することで 必要な業務知識を少なくする』に至る。 簡単な試みから始めて、徐々に本格的な対策を考える。
23. 仮説検証①
24. 24 これまでの状況まとめ 原因 原因の詳細/対策 業務知識が足りない 何もわかっていない。 人事労務freeeの実装方法へ の理解が足りない
25. 25 対策を考える たくさん座学で勉強する →たくさん勉強したくない!!!却下。 ↓ もっと簡単にできることはないか？ ↓ コードリーディングすれば 良いのでは？
26. 仮説：業務知識と実装理解は同時に進められる 1. コードリーディングをすれば、実装理解は進む 2. 実装を読み、少しの業務知識を得ることになれば、 それをきっかけに、自発的に業務についても勉強するだろう 3. 自発的な業務知識のキャッチアップが促進できれば 業務知識もつく 一挙両得
27. 27 バグの模擬Fix会を実施。 過去のバグチケットを モブプログラミングする会。 • 参加型の方が 知識の定着率がよさそう。 • 座学は嫌い。 • 目的があったほうが 集中できそう。
28. 28 28 検証：業務知識と実装理解は同時に進んだのか？ 以下の事実が判明した。 • 実装の変更方法や、 アーキテクチャの理解は深まった。 ◦ モデル構成 ◦ 他システムとの連携
29. 29 29 検証：業務知識と実装理解は同時に進んだのか？ 以下の事実が判明した。 • 実装の変更方法や、 アーキテクチャの理解は深まった。 ◦ モデル構成 ◦ 他システムとの連携 • 体系的な業務知識はつかない。 ◦ 必要なものだけを覚える ◦ 業務について自発的には 勉強しない
30. 30 30 振り返り：この取り組みでわかったこと • 人事労務の実装方法の学習は少しのきっかけで自然と進む。 ◦ 自発的なアーキテクチャの勉強会なども開催された。 ◦ アーキテクチャに関する議論も活発になった。 • 業務知識の学習に関しては少しのきっかけでは進まない。 ◦ ごく一部のメンバーが自発的に学ぶこともある。 ◦ やはり、座学は嫌いだった。
31. 仮説検証②
32. 32 これまでの状況まとめ 原因 原因の詳細/対策 業務知識が足りない 何もわかっていない。 人事労務freeeの実装方法へ の理解が足りない コードリーディングを行えば、実装理解はできる。
33. 33 対策を考える 業務知識を足りない問題を 解決しなくては ↓ たくさん座学で勉強する →たくさん勉強したくない!!!却下。 ↓ ？？？？
34. 34 freeeには人事労務freeeだけではなく
35. 会計freeeもある 35
36. 36 36 業務知識を身につける方法を教えてもらおう!! 良く分かっていなければ、よくわかってそうな人に聞きに行けばいい • freeeでは人事労務以外に会計のプロダクトがある • 業務知識があるっぽいエンジニアが、そこにも実はたくさんいる • 他のチームではあまり業務知識で困ってないらしいぞ • その人達に聞いてみれば銀の弾丸が見つかるのでは……!? • そうしたら勉強しないで済む！！
37. 仮説：業務知識得るいい方法がすでにあるのでは？ • エンジニアが業務知識を得る方法はすでに発見されており、 他のチームで実践されている。 • その方法を人事労務freeeの開発チームに適用すれば、 業務知識が足りない問題も解決できる。 最高だ。
38. 38 38 ヒアリング風景
39. 検証：単体の業務分野なら知識を得る方法はある ほかのチームにはいい方法があったが、 人事労務freeeのチームに当てはまらない。 銀の弾丸はやっぱりなかった。 他チームが業務知識を求められなかった理由 • 業務知識の一部を覚えればよい • とても良いリファレンスがあり、 それを参照すれば、必ず解決する
40. 40 40 他チームと比較することでわかったこともある 人事労務freee独特な問題が浮き彫りになってきた。 他チームと比較して分かったこと • 人事労務freeeの開発には 暗記が必要な項目が多く、しかも多岐に渡る。 • 勤怠、給与計算、社保の手続き、年末調整などの 機能の実装が密接に入り混じっているソフトだから • エンジニアは区切られて業務単体なら理解できるが、 人事労務は連結してるから難しい。
41. 41 41 振り返り：この取り組みでわかったこと • ヒアリングすることで他の人の経験値を自分のものにできる。 ◦ 業務知識の取得方法などは結局使えなかったが 一部参考にすることができた。 • 比較をすることで自分たちの立ち位置は明確になる。 ◦ 自分たちだけで考えていると分からないことも 比較をすることでわかることがある。
42. 仮説検証③
43. 43 これまでの状況まとめ 原因 原因の詳細/対策 業務知識が足りない • 人事労務freeeの開発には 暗記が必要な項目が多く、しかも多岐に渡る。 • 勤怠、給与計算、社保の手続き、年末調整などの 機能の実装が密接に入り混じっているソフト。 • エンジニアは区切られて業務単体なら理解できる が、人事労務は連結してるから難しい。 人事労務freeeの実装方法へ の理解が足りない コードリーディングを行えば実装理解はできる。
44. 44 対策を考える 業務知識を足りない問題を 解決しなくては ↓ 連結しているすべての業務を勉強する →たくさん勉強したくない!!!却下。 ↓ ？？？？
45. 45 45 仮説：業務に対して、プロダクトを分けられる 業務が密接につながっているといっても 分割することはできるはず。 分割することができれば、 エンジニアは 特定の業務知識だけを習得すればよい。
46. 46 46 どこで業務を分けられるのか？ 業務が分割できると実装も分割できるが、 どこで分割できるのかというのは不透明だった。 そこで、実装と業務の両方に詳しいメンバーと一緒に 人事労務freeeで取り扱っている業務全体の関係性を分析することに。 業務の関係性が明らかになれば、分割ポイントも明らかになるはず。
47. 47 47 どこで分けれるのか？ •
48. 48 48 業務をマクロ的に分析する 1日(3人)かけて、業務の関係性を分析をしてみる。
50. 給与明細 50 人事労務freeeがカバーする（将来も含む）複雑な部分 住民税の税額 従業員の住所 扶養控除親族の情報 従業員控除設定 基本給設定 割増賃金の基礎 勤怠控除の基礎 週次勤怠 日次勤怠 打刻 割増率 月次勤怠 住民税 基本給 手当 年末調整 会計連携 賃金台帳 所得税 勤怠控除 割増賃金 労働時間制度 算定基礎届 月額変更届 いろんな数字 出勤簿 労働保険の 年度更新 従業員の標準報酬月額 従業員銀行口座情報 算定基礎賃 金集計表 給与明細 一覧表 住民税の 納付 非課税通勤手当 課税通勤手当 健康保険料 こども・ 子育て拠出金 介護保険料 通勤手当設定 従業員手当設定 その他 の控除 総合振込 ファイル (労災保険料) 雇用保険料 雇用保険の 賃金額 月の源泉控 除税額 月の社会保 険等の控除 額の合計 月の課税 対象支給額 複数時給 差し引き支給額 社会保険の賃金額 厚生年金保料 •設定 •勤怠 •支給額 •控除 •集計された数字 •出力される書類など 締め日支払い日の 影響を避けられない エリア
51. 51 業務をマクロ的に分析するとわかったこと • 各業務の間には切り分けポイントが見つかった。 • 例) 勤怠はすべてが給与明細につながると思っていたが、 月次の勤怠がポイントだとわかる。 月次の勤怠 給与明細 日次の勤怠 週次の勤怠 月次の勤怠 給与明細 日次の勤怠 週次の勤怠
52. 検証：プロダクトの実装を業務によって分割できる 業務を分析して分かったこと • 勤怠、給与計算などの機能の実装が 密接に入り混じっているが、 分割ポイントが存在する。 • 実装を業務に沿って分割できれば、 必要な業務知識も減る。
53. 53 53 振り返り：この取り組みでわかったこと • 機能拡張を繰り返す過程で、実装が密に関係していた。 結果、多くの業務知識が必要となるという負債を抱えがち。 • DDD等の設計手法の勉強からは逃れられない。
54. 仮説検証④ (現在検証中)
55. 55 壁を乗り越えようと行っている挑戦 DDDなどの設計手法を用いて 実装と業務が一致したモジュールに分 割することで 必要な業務知識を少なくする
56. 56 56 マクロ分析→ミクロ分析 業務のマクロ的な分析を終え、 ミクロの分析に着手している。 この図はミクロな業務分析を行っているホワイトボードメモ。 このような分析を各所で行っており、 いくつかの問題を解決することもわかってきた。 DDDなどの設計手法も社内で勉強会を実施。
57. 57 目指している将来の姿 原因 原因の詳細/対策 業務知識が足りない • 人事労務freeeの開発には 暗記が必要な項目が多く、しかも多岐に渡る。 • 勤怠、給与計算、社保の手続き、年末調整などの 機能の実装が密接に入り混じっているソフト。 • しかし実装が業務に沿って分割されているため、実 は個別の開発に必要となる知識は多くない。 人事労務freeeの実装方法へ の理解が足りない コードリーディングを行えば、実装理解はできる。
58. 振り返り 58 この一連の仮説検証を 通して思ったこと
59. 59 59 振り返ってみると、今の試みは当たり前のもの 業務知識を足りないのはなぜ？ ↓ 業務が広く、複雑だから ↓ なぜ複雑なの？ ↓ 機能が入り混じっているから ↓ 分割しよう
60. やってきたことに 意味はなかったのかな？
61. いや、そんなことはない
62. 62 全体がわからなくても前に進んできた 何から手を付ければいいかすら、わかっていなかった。 でも、前に進んできた。だから、今がある。 原因 原因の詳細/対策 業務知識が足りない 何もわかっていない。 人事労務freeeの実装方法へ の理解が足りない
63. 63 63 やっていくうちに分かることもある 小さく仮説検証してきたことが、 現在やっていることの正しさを明らかにしてくれている。 業務知識を足りないのはなぜ？ ↓ 業務が広く、複雑だから ↓ なぜ複雑なの？ ↓ 機能が入り混じっているから ↓ 分割しよう ここは仮説検証の途中で 明らかになった。
64. 64 1→10のフェーズは危ういという教訓も得られた 機能拡張を繰り返す過程で、 実装が密に関係することで、 多くの業務知識が必要となるという負債を抱えがち。
65. 無駄じゃなかった
66. よくわからない状況でも その時に思いつく最善手を 愚直にやっていくことで わかることがある
67. freeeの価値基準
69. アウトプットすることで 状況を改善することができる
70. 小さくとも 仮説検証を繰り返すことが 大事
71. 頑張ろう。
72. 現場からは以上です。
73. freee 株式会社 ご清聴ありがとうございました