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

Slide 1

Slide 1 text

広く複雑なプロダクトの高速キャッチアップに取り組む 2018.07.10 freee株式会社 moai

Slide 2

Slide 2 text

2 今日話すこと DDDなどの設計手法を用いて、実装と業務が一致したモジュールに分割することで必要な業務知識を少なくするという試みを行っています。しかし、そこに至るまで様々仮説検証が必要でした。今回はこの仮説検証の話をしようと思います。 (DDDの話はしません。)

Slide 3

Slide 3 text

2015/10月にfreeeにjoin。現在は人事労務freee開発チームで要件定義・設計・実装・運用に携わる。 3 山崎遼介 moai freee株式会社エンジニア

Slide 4

Slide 4 text

4 人事労務freeeについて ● 変革しようとしていることって？ ● この変革のために乗り越えなければならない常識の壁って？

Slide 5

Slide 5 text

5 人事労務freeeは何を変革するソフトか？非生産的な定型業務をなくし、生産的な業務に集中できるようにする非生産的な定型業務 ● 書類作成 ● 給与計算生産的な業務 ● 従業員の目標設定 ● 評価制度

Slide 6

Slide 6 text

6 なぜ非生産的な定型業務が多いのか？ ● 書類が多い ● ステークホルダーが多い

Slide 7

Slide 7 text

7 書類が多い入社手続きにおいては、最低11枚の書類を取り扱う ● 雇用条件通知書 ● 雇用保険被保険者証 ● 年金手帳 ● 源泉徴収票 ● マイナンバー ● 扶養控除等異動申告書 ● 給与支払報告・特別徴収にかかる給与所得者異動届出書 ● 被保険者資格取得届(健康保険) ● 健康保険被扶養者（異動）届・国民年金第3号被保険者資格取得等届 ● 被保険者資格取得届(厚生年金) ● 資格取得届(雇用保険)

Slide 8

Slide 8 text

8 ステークホルダーが多い書類のやり取りするステークホルダーは大まかに6つもある。一人の従業員を入社したら、従業員+5つの機関とやり取りする。 ● 雇用条件通知書 ● 雇用保険被保険者証 ● 年金手帳 ● 源泉徴収票 ● マイナンバー ● 扶養控除等異動申告書 ● 給与支払報告・特別徴収にかかる給与所得者異動届出書 ● 被保険者資格取得届(健康保険) ● 健康保険被扶養者（異動）届・国民年金第3号被保険者資格取得等届 ● 被保険者資格取得届(厚生年金) ● 資格取得届(雇用保険) 従業員税務署市区町村健康保険組合年金事務所ハローワークこのやり取りを従業員の人数分

Slide 9

Slide 9 text

freeeの場合 ● 品川区 ● 関東IT健保

Slide 10

Slide 10 text

10 乗り越えなければならない常識の壁は？業務が複雑 ↓ 業務知識が多く必要

Slide 11

Slide 11 text

背景 11 きっかけは何だったのか？ ● 様々な仮説検証を行うことになった問題意識は何？

Slide 12

Slide 12 text

12 様々な仮説検証を行うことになった問題意識は何？サービススコープの拡大、開発メンバーの増加をきっかけに『業務知識が足りない』、『人事労務freeeの実装方法への理解が足りない』ことによる問題が多く起こったから。

Slide 13

Slide 13 text

13 フェーズは１→10 (2017/8) もともとあった給与計算機能を軸に周辺機能だった勤怠、社会保険の手続きを強化する

Slide 14

Slide 14 text

14 スコープの拡大に伴い、メンバーの増加 3人から13人になる

Slide 15

Slide 15 text

15 しかし、ここで問題がおこるサービススコープが広がる。 → 必要な知識の領域は広がる。しかし、開発者は必ずしも人事労務freeeの開発に詳しくない。よって、『業務知識が足りない』、『人事労務freeeの実装方法への理解が足りない』ことによる問題が多く起こることになりました。

Slide 16

Slide 16 text

16 バグがバグなのか分からない① 退職月に2カ月分の保険料が引かれる給与から 2カ月分の健康保険料が引かれています。間違っていないですか？一見バグのようだがバグではない

Slide 17

Slide 17 text

17 バグがバグなのか分からない② 家族は2人しかいないのに扶養親族等の数は3になる。家族は2人しかいないのに扶養親族等の数が3になっています。間違っていないですか？従業員 (男) 妻子供 (障害者) 一見バグのようだがバグではない

Slide 18

Slide 18 text

18 修正の影響範囲がよくわからない全てのロジックがつながっているため、修正箇所の影響がどこに及ぶのかよくわからない。 ● 勤怠が給与明細に転記されるのは理解できるが ● 社会保険の書類の数字にまで影響するのは想像が難しい。勤怠給与明細社会保険の書類の数字転記転記出勤簿給与明細月額変更届

Slide 19

Slide 19 text

何か対策を考えなければ

Slide 20

Slide 20 text

20 ターニングポイント：足りない問題の解決 1→10のフェーズになる ↓ 業務知識が足りない実装方法への理解が足りない ↓ 解決しよう!!

Slide 21

Slide 21 text

仮説検証 21

Slide 22

Slide 22 text

22 22 どのように仮説検証していったのか？結果的に3回の仮説検証を経て『実装と業務が一致したモジュールに分割することで必要な業務知識を少なくする』に至る。簡単な試みから始めて、徐々に本格的な対策を考える。

Slide 23

Slide 23 text

仮説検証①

Slide 24

Slide 24 text

24 これまでの状況まとめ原因原因の詳細/対策業務知識が足りない何もわかっていない。人事労務freeeの実装方法への理解が足りない

Slide 25

Slide 25 text

25 対策を考えるたくさん座学で勉強する →たくさん勉強したくない!!!却下。 ↓ もっと簡単にできることはないか？ ↓ コードリーディングすれば良いのでは？

Slide 26

Slide 26 text

仮説：業務知識と実装理解は同時に進められる 1. コードリーディングをすれば、実装理解は進む 2. 実装を読み、少しの業務知識を得ることになれば、それをきっかけに、自発的に業務についても勉強するだろう 3. 自発的な業務知識のキャッチアップが促進できれば業務知識もつく一挙両得

Slide 27

Slide 27 text

27 バグの模擬Fix会を実施。過去のバグチケットをモブプログラミングする会。 ● 参加型の方が知識の定着率がよさそう。 ● 座学は嫌い。 ● 目的があったほうが集中できそう。

Slide 28

Slide 28 text

28 28 検証：業務知識と実装理解は同時に進んだのか？以下の事実が判明した。 ● 実装の変更方法や、アーキテクチャの理解は深まった。 ○ モデル構成 ○ 他システムとの連携

Slide 29

Slide 29 text

29 29 検証：業務知識と実装理解は同時に進んだのか？以下の事実が判明した。 ● 実装の変更方法や、アーキテクチャの理解は深まった。 ○ モデル構成 ○ 他システムとの連携 ● 体系的な業務知識はつかない。 ○ 必要なものだけを覚える ○ 業務について自発的には勉強しない

Slide 30

Slide 30 text

30 30 振り返り：この取り組みでわかったこと ● 人事労務の実装方法の学習は少しのきっかけで自然と進む。 ○ 自発的なアーキテクチャの勉強会なども開催された。 ○ アーキテクチャに関する議論も活発になった。 ● 業務知識の学習に関しては少しのきっかけでは進まない。 ○ ごく一部のメンバーが自発的に学ぶこともある。 ○ やはり、座学は嫌いだった。

Slide 31

Slide 31 text

仮説検証②

Slide 32

Slide 32 text

32 これまでの状況まとめ原因原因の詳細/対策業務知識が足りない何もわかっていない。人事労務freeeの実装方法への理解が足りないコードリーディングを行えば、実装理解はできる。

Slide 33

Slide 33 text

33 対策を考える業務知識を足りない問題を解決しなくては ↓ たくさん座学で勉強する →たくさん勉強したくない!!!却下。 ↓ ？？？？

Slide 34

Slide 34 text

34 freeeには人事労務freeeだけではなく

Slide 35

Slide 35 text

会計freeeもある 35

Slide 36

Slide 36 text

36 36 業務知識を身につける方法を教えてもらおう!! 良く分かっていなければ、よくわかってそうな人に聞きに行けばいい ● freeeでは人事労務以外に会計のプロダクトがある ● 業務知識があるっぽいエンジニアが、そこにも実はたくさんいる ● 他のチームではあまり業務知識で困ってないらしいぞ ● その人達に聞いてみれば銀の弾丸が見つかるのでは……!? ● そうしたら勉強しないで済む！！

Slide 37

Slide 37 text

仮説：業務知識得るいい方法がすでにあるのでは？ ● エンジニアが業務知識を得る方法はすでに発見されており、他のチームで実践されている。 ● その方法を人事労務freeeの開発チームに適用すれば、業務知識が足りない問題も解決できる。最高だ。

Slide 38

Slide 38 text

38 38 ヒアリング風景

Slide 39

Slide 39 text

検証：単体の業務分野なら知識を得る方法はあるほかのチームにはいい方法があったが、人事労務freeeのチームに当てはまらない。銀の弾丸はやっぱりなかった。他チームが業務知識を求められなかった理由 ● 業務知識の一部を覚えればよい ● とても良いリファレンスがあり、それを参照すれば、必ず解決する

Slide 40

Slide 40 text

40 40 他チームと比較することでわかったこともある人事労務freee独特な問題が浮き彫りになってきた。他チームと比較して分かったこと ● 人事労務freeeの開発には暗記が必要な項目が多く、しかも多岐に渡る。 ● 勤怠、給与計算、社保の手続き、年末調整などの機能の実装が密接に入り混じっているソフトだから ● エンジニアは区切られて業務単体なら理解できるが、人事労務は連結してるから難しい。

Slide 41

Slide 41 text

41 41 振り返り：この取り組みでわかったこと ● ヒアリングすることで他の人の経験値を自分のものにできる。 ○ 業務知識の取得方法などは結局使えなかったが一部参考にすることができた。 ● 比較をすることで自分たちの立ち位置は明確になる。 ○ 自分たちだけで考えていると分からないことも比較をすることでわかることがある。

Slide 42

Slide 42 text

仮説検証③

Slide 43

Slide 43 text

43 これまでの状況まとめ原因原因の詳細/対策業務知識が足りない ● 人事労務freeeの開発には暗記が必要な項目が多く、しかも多岐に渡る。 ● 勤怠、給与計算、社保の手続き、年末調整などの機能の実装が密接に入り混じっているソフト。 ● エンジニアは区切られて業務単体なら理解できるが、人事労務は連結してるから難しい。人事労務freeeの実装方法への理解が足りないコードリーディングを行えば実装理解はできる。

Slide 44

Slide 44 text

44 対策を考える業務知識を足りない問題を解決しなくては ↓ 連結しているすべての業務を勉強する →たくさん勉強したくない!!!却下。 ↓ ？？？？

Slide 45

Slide 45 text

45 45 仮説：業務に対して、プロダクトを分けられる業務が密接につながっているといっても分割することはできるはず。分割することができれば、エンジニアは特定の業務知識だけを習得すればよい。

Slide 46

Slide 46 text

46 46 どこで業務を分けられるのか？業務が分割できると実装も分割できるが、どこで分割できるのかというのは不透明だった。そこで、実装と業務の両方に詳しいメンバーと一緒に人事労務freeeで取り扱っている業務全体の関係性を分析することに。業務の関係性が明らかになれば、分割ポイントも明らかになるはず。

Slide 47

Slide 47 text

47 47 どこで分けれるのか？ ●

Slide 48

Slide 48 text

48 48 業務をマクロ的に分析する 1日(3人)かけて、業務の関係性を分析をしてみる。

Slide 49

Slide 49 text

No content

Slide 50

Slide 50 text

給与明細 50 人事労務freeeがカバーする（将来も含む）複雑な部分住民税の税額従業員の住所扶養控除親族の情報従業員控除設定基本給設定割増賃金の基礎勤怠控除の基礎週次勤怠日次勤怠打刻割増率月次勤怠住民税基本給手当年末調整会計連携賃金台帳所得税勤怠控除割増賃金労働時間制度算定基礎届月額変更届いろんな数字出勤簿労働保険の年度更新従業員の標準報酬月額従業員銀行口座情報算定基礎賃金集計表給与明細一覧表住民税の納付非課税通勤手当課税通勤手当健康保険料こども・子育て拠出金介護保険料通勤手当設定従業員手当設定その他の控除総合振込ファイル (労災保険料) 雇用保険料雇用保険の賃金額月の源泉控除税額月の社会保険等の控除額の合計月の課税対象支給額複数時給差し引き支給額社会保険の賃金額厚生年金保料 ●設定 ●勤怠 ●支給額 ●控除 ●集計された数字 ●出力される書類など締め日支払い日の影響を避けられないエリア

Slide 51

Slide 51 text

51 業務をマクロ的に分析するとわかったこと ● 各業務の間には切り分けポイントが見つかった。 ● 例) 勤怠はすべてが給与明細につながると思っていたが、月次の勤怠がポイントだとわかる。月次の勤怠給与明細日次の勤怠週次の勤怠月次の勤怠給与明細日次の勤怠週次の勤怠

Slide 52

Slide 52 text

検証：プロダクトの実装を業務によって分割できる業務を分析して分かったこと ● 勤怠、給与計算などの機能の実装が密接に入り混じっているが、分割ポイントが存在する。 ● 実装を業務に沿って分割できれば、必要な業務知識も減る。

Slide 53

Slide 53 text

53 53 振り返り：この取り組みでわかったこと ● 機能拡張を繰り返す過程で、実装が密に関係していた。結果、多くの業務知識が必要となるという負債を抱えがち。 ● DDD等の設計手法の勉強からは逃れられない。

Slide 54

Slide 54 text

仮説検証④ (現在検証中)

Slide 55

Slide 55 text

55 壁を乗り越えようと行っている挑戦 DDDなどの設計手法を用いて実装と業務が一致したモジュールに分割することで必要な業務知識を少なくする

Slide 56

Slide 56 text

56 56 マクロ分析→ミクロ分析業務のマクロ的な分析を終え、ミクロの分析に着手している。この図はミクロな業務分析を行っているホワイトボードメモ。このような分析を各所で行っており、いくつかの問題を解決することもわかってきた。 DDDなどの設計手法も社内で勉強会を実施。

Slide 57

Slide 57 text

57 目指している将来の姿原因原因の詳細/対策業務知識が足りない ● 人事労務freeeの開発には暗記が必要な項目が多く、しかも多岐に渡る。 ● 勤怠、給与計算、社保の手続き、年末調整などの機能の実装が密接に入り混じっているソフト。 ● しかし実装が業務に沿って分割されているため、実は個別の開発に必要となる知識は多くない。人事労務freeeの実装方法への理解が足りないコードリーディングを行えば、実装理解はできる。

Slide 58

Slide 58 text

振り返り 58 この一連の仮説検証を通して思ったこと

Slide 59

Slide 59 text

59 59 振り返ってみると、今の試みは当たり前のもの業務知識を足りないのはなぜ？ ↓ 業務が広く、複雑だから ↓ なぜ複雑なの？ ↓ 機能が入り混じっているから ↓ 分割しよう

Slide 60

Slide 60 text

やってきたことに意味はなかったのかな？

Slide 61

Slide 61 text

いや、そんなことはない

Slide 62

Slide 62 text

62 全体がわからなくても前に進んできた何から手を付ければいいかすら、わかっていなかった。でも、前に進んできた。だから、今がある。原因原因の詳細/対策業務知識が足りない何もわかっていない。人事労務freeeの実装方法への理解が足りない

Slide 63

Slide 63 text

63 63 やっていくうちに分かることもある小さく仮説検証してきたことが、現在やっていることの正しさを明らかにしてくれている。業務知識を足りないのはなぜ？ ↓ 業務が広く、複雑だから ↓ なぜ複雑なの？ ↓ 機能が入り混じっているから ↓ 分割しようここは仮説検証の途中で明らかになった。

Slide 64

Slide 64 text

64 1→10のフェーズは危ういという教訓も得られた機能拡張を繰り返す過程で、実装が密に関係することで、多くの業務知識が必要となるという負債を抱えがち。

Slide 65

Slide 65 text

無駄じゃなかった

Slide 66

Slide 66 text

よくわからない状況でもその時に思いつく最善手を愚直にやっていくことでわかることがある