『コードを書く以外の』エンジニアリング〜課金基盤移行プロジェクト推進のためのTips4選

Developers Summit 2026 Summer Day1登壇資料です。

Transcript

1. 『コードを書く以外の』  エンジニアリング 課⾦基盤移⾏プロジェクト推進のためのTips4選 由利優⼦ 株式会社SmartHR 技術統括本部プロダクト基盤開発部 2026/7/16
2. 本⽇お話ししたいこと
3. 『コードを書く以外の』 エンジニアリング 3
4. 話すこと 課⾦基盤をリアーキテクチャするにあたって困難 だったのは設計や実装だけではない 4
5. 話すこと プロジェクトを推進するにあたっての課題 • 他部署とのコミュニケーション不⾜ • プロジェクト完了までの具体的なスケジュー ルが引かれていない • チーム内での決定事項がまとまっていない • タスクの進捗管理 5
6. 話すこと プロジェクトを推進するにあたっての課題 • 他部署とのコミュニケーション不⾜ • プロジェクト完了までの具体的なスケジュー ルが引かれていない • チーム内での決定事項がまとまっていない • タスクの進捗管理 6 これらを解決しないとプロジェクトは完遂できない
7. 話すこと • 本⽇はコードを書く話はしません • コードを書く以外に、プロジェクトを推進す るためのTipsを紹介 7
8. 話すこと • リードの役割 • プロジェクトをリードするにあたってやったこと ◦ 他チームとの調整 ◦ 検証‧移⾏計画の策定 ◦ ドキュメント整備 ◦ タスクの優先度調整 8
9. ターゲット • これからプロジェクトをリードする⽴場にな る⼈ • 他部⾨とプロジェクトを進めることに難しさ を感じている⼈ 9
10. ⾃⼰紹介
11. ⾃⼰紹介 由利 優⼦（ゆり ゆうこ） yuriko 2023年11⽉にSmartHRに⼊社 プロダクトエンジニアとして課 ⾦基盤の開発を担当 11
12. 本⽇の登壇資料 12 https://speakerdeck.com/yuriko1211/engineering-beyond-coding X（@yuriko12111）でも流します
13. SmartHRとは
15. 15 SmartHRについて • ⼈事‧労務‧情シス領域の業務を効率化 • 「worker-friendly」を掲げ、働くみんなが使 いやすいシステムを⽬指している • 2015年ローンチ
16. SmartHRの課⾦基盤
17. SmartHRの契約形態 • テナントごとに利⽤したい機能が含まれるプ ランと必要であればオプションを選択して契 約する • 基本的には登録⼈数 × 単価で年額もしくは⽉ 額で課⾦される 17
18. SmartHRの課⾦基盤 18 サブスクリプション 管理アプリ Zuora • SmartHR基本 機能 • 各機能にアクセ スする際に、契 約しているプラ ンやオプション 機能を確認する • サブスクリプ ション管理 SaaS • テナントがどの プランやオプ ションを登録し ているか、何⼈ が利⽤してい て、いくら課⾦ するかを管理す る • 内製のサブスク リプション管理 アプリ • SmartHR本体 とZuoraを仲⽴ ちする • 管理画⾯を持 ち、SmartHR 社員が顧客のプ ラン‧オプショ ンを確認できる
19. SmartHRの課⾦基盤の旧アーキテクチャ 19 サブスクリプション 管理アプリ Zuora 判定のためにテナン トのプラン‧オプ ション情報がほしい APIを叩いて取得する APIを叩いて取得する • Zuoraに都度問い合わせるPull型の設計 • 実際は都度APIで取ってくるとパフォーマンスが悪化するので、 21⽇という⻑めのキャッシュを持たせている
20. 旧アーキテクチャの課題感 • 何かしら契約情報が変更になった場合に キャッシュを更新させる必要がある ◦ 運⽤⾯の煩雑さ • 柔軟な契約形態の提供が難しい ◦ 既存はテナント単位でプラン‧オプションを選択する が、テナント内でも社員の雇⽤形態によってプラン‧ オプションを選択できるようにしたい 20
21. 課⾦基盤⾃体の技術的負債 ローンチ当初から存在している基盤であり、 今まで抜本的解決がされずにコードが継ぎ⾜ しを重ねて作られている 21
22. ⽬指す事業価値 柔軟な契約形態を提供すること • 例 ◦ 雇⽤形態別に提供するプラン‧オプションを選択 できる ◦ 今後さらに契約形態をアップデートする際に開発 しやすい状態を作る 22
23. 新アーキテクチャ移⾏後のSmartHRの課⾦基盤 23 サブスクリプション 管理アプリ Zuora プラン‧オプション が変わったよ APIを叩いてプラン‧オプ ション情報を送る プラン‧オプション情報を DBに保持 判定時はDBに保持したプラ ン‧オプション情報を使⽤ • Zuoraが変更を検知して情報を送るPush型の設計
24. プロジェクトのスタート地点
25. プロジェクトのスタート地点 • ⼀部の契約形態には先⾏して新アーキテク チャを適⽤し、動くことを確認 • 既存の全テナント‧新規で作成される全テナ ントをこのアーキテクチャに移⾏していくプ ロジェクト 25
26. リードの役割
27. SmartHRにおけるリードの役割 • プロジェクトの不確実性を減らすこと ◦ 道を作る • プロジェクト完了に向かってチームが⾛れる 状態を作ること ◦ 道に⾞を⾛らせる 27
28. Tips1: 他チームとの調整
29. SmartHRの課⾦基盤（再掲） 29 サブスクリプション 管理アプリ Zuora • SmartHR基本 機能 • 各機能にアクセ スする際に、契 約しているプラ ンやオプション 機能を確認する • サブスクリプ ション管理 SaaS • テナントがどの プランやオプ ションを登録し ているか、何⼈ が利⽤してい て、いくら課⾦ するかを管理す る • 内製のサブスク リプション管理 アプリ • SmartHR本体 とZuoraを仲⽴ ちする • 管理画⾯を持 ち、SmartHR 社員が顧客のプ ラン‧オプショ ンを確認できる
30. SmartHRの課⾦基盤（再掲） 30 サブスクリプション 管理アプリ Zuora 課⾦基盤チーム（⾃チーム） 契約‧請求管理を担当している 別チーム
31. 課題 • サブスクリプション管理SaaSのZuoraを管掌 しているのはビジネスサイドの別チーム ◦ プロダクト開発チームとの距離 ◦ ⽂化的な違い ◦ コミュニケーションが乏しい 31
32. 起こった問題 • アーキテクチャ移⾏の計画について考えてい ることが全く違っていた 32
33. アーキテクチャ移⾏の認識ズレ 課⾦基盤チーム（⾃チーム） • 「◯⽉✕⽇から移⾏」ができると 思っていた • 新規で契約したテナントの移⾏か ら始めて、完了したら既存のテナ ントの移⾏をするという計画 契約‧請求管理を担当している別チーム • 請求書や⾒積書に影響があるとし たらある⽇付で切り替えるという のは難しい • 四半期末で運⽤を変えるのは、 セールス‧CSにも影響があって厳 しい 33
34. 気にしていたことのズレ 課⾦基盤チーム（⾃チーム） • システム的な移⾏が上⼿くいくか どうか • どう移⾏したら安全か 契約‧請求管理を担当している別チーム • 今まで通り運⽤できるかどうか ◦ セールス‧CSへの影響 • ユーザーに出す⾒積書や請求書へ の影響がないか 34
35. ズレ埋めが必要 • 考えていたことにかなりズレがあったので 焦った • まずはズレを埋めていかないと移⾏計画を⽴ てるのが難しい 35
36. コミュニケーションの場を作る • プロジェクトの定例会議をセッティング • プロジェクト⽤のSlackチャンネルの作成 36
37. 移⾏についての認識が揃った • 運⽤や請求書への影響は最⼩限に • 新規‧既存の区別をなくし、徐々に移⾏させ ていく⽅法に決定 37
38. 移⾏計画の図⽰ • プロジェクトメンバー間で移⾏計画について 認識を合わせる ◦ 双⽅が考えているタスクを洗い出して並べ る ◦ システム⾯だけではなく、運⽤⾯でも移⾏ できるかを確認 38
39. 移⾏計画の図⽰の例 課⾦基盤チーム（⾃チーム） 39 契約‧請求管理チーム Zuoraの設定値変更 ZuoraのWF改修 新規登録処理の移⾏ 既存移⾏のための Worker登録 先⾏移⾏の対象のフラ グ管理 変更になる画⾯につい てのユーザー周知 始めはやるべきタスクだけがバラバラに存在している状態
40. タイムラインで整理 40 サブスクリプション 管理アプリ Zuora ①Zuoraの設定値変更 ④ZuoraのWF改修 ⑤新規登録処理の移⾏ ⑥既存移⾏のための Worker登録 ②先⾏移⾏の対象のフ ラグ管理 ③変更になる画⾯につ いてのユーザー周知
41. ⽇程も整理 41 開始日 終了日 所要日数 タスク 担当チーム 7/1 7/2 1 Zuoraの設定値変更 契約・請求管理チーム 7/2 7/3 1 先行移行の対象のフラグ管理 契約・請求管理チーム 7/3 7/16 10 変更になる画面についてのユー ザー周知 課金基盤チーム 7/16 7/16 0 ZuoraのWF改修 契約・請求管理チーム 7/16 7/16 0 新規登録処理の移行 課金基盤チーム 7/16 7/17 1 既存移行のためのWorker登録 課金基盤チーム お互いがいつ‧何をやるかまでブレイクダウン
42. 成果 • それぞれのチームが歩み寄って、移⾏に必要 となるタスクを整理できた ◦ いつ何をやって、いつ移⾏が完了できるか まで明確化された • 開発中に発⽣した疑問点を気軽に聞いて解消 できるようになった 42
43. 考えていることの同期が重要 他部⾨と協⼒してプロジェクトを遂⾏するために 必要なことは、 お互いの考えていることを同期させること 43
44. ⾒ている世界が違うことを前提に動く • 扱っているものが違えば⾒ている世界も違う ◦ お互い気にしているポイントも違う ◦ 逆に⾔えば⾃分たちが気づいていない視点 でのコメントももらえる • とにかく気軽に話ができる体制を整えておく 44
45. Tips2: 検証‧移⾏計画の策定
46. 課題 • 「段階的に移⾏したい」という気持ちはあっ たが、どのように段階を踏むか具体化されて いなかった • どう移⾏すれば安全なのかがわかっていな かった 46
47. 契約形態のパターンが多いという課題 • 契約形態のパターンが⾮常に多い ◦ その時々の事業フェーズで必要な契約形態 を作ってきた ◦ 新規での契約が廃⽌になった契約形態も、 既存の契約は残り続けてしまう 47
48. 安全な移⾏を達成するために何が必要か • QAエンジニアと連携して、安全な移⾏を達成 するための進め⽅について検討 ◦ なにがわかれば検証や段階移⾏の観点が洗 い出せる？ 48
49. 契約形態の整理 • 契約形態やシステム的に差分が出る特徴を洗 い出し「属性」として定義 ◦ 属性に対してテスト計画を策定 ◦ 本番環境のテナントを属性ごとに分類し、 先⾏移⾏の対象をピックアップ 49
50. 属性のイメージ 50 テナントA テナントB 決済方法 クレジットカード 請求書 月払い or 年払い 月払い 年払い 属性 実際には20件ほどの 属性がある
51. テスト設計 • 属性をもとにテストケースを作成 ◦ 多彩な契約形態をカバー • テスト設計時も契約‧請求管理を担当してい る他チームとの密なコミュニケーション 51
52. 属性ごとにテスト項⽬を決める • 属性のかけ合わせで検証したいパターン ◦ カード払い × ⽉払い • 属性単独で検証できるパターン ◦ グループ会社をまとめた請求形態 52
53. 先⾏移⾏の対象選定 • 先⾏移⾏で期待することを整理 ◦ 第1グループでは移⾏の⼿順の最終確認 ◦ 第2グループでは属性の代表をピックアッ プしての最終確認 53
54. 切り戻しのための⼿順整備 • 切り戻しができるかの調査と、切り戻しのた めの⼿順整理 ◦ 切り戻しをするための⼿順整備やスクリプ ト作成に⼯数を割く判断 54
55. プロジェクトのスタート地点（再掲） • ⼀部の契約形態には先⾏して新アーキテク チャを適⽤し、動くことを確認 • 既存の全テナント‧新規で作成される全テナ ントをこのアーキテクチャに移⾏していくプ ロジェクト 55
56. 当初切り戻しを考えていなかった理由 • 先⾏して適⽤していた⼀部契約形態ではデー タ上切り戻しが不可能 • チーム内でなんとなく切り戻しはできない想 定で動いていた 56
57. 本当に切り戻しができないのか再考 • 切り戻しはできた⽅が安全 • 改めて調査した結果、ほとんどのパターンで は切り戻しが可能だとわかった 57
58. 切り戻しを実施する基準を決める • どういう場合に切り戻しを実施するべきかを チームで認識をあわせる ◦ SmartHRの機能提供に影響がある場合は切 り戻す 58
59. 成果 • 属性を定義したことで、最終的な移⾏テスト で過不⾜ないテスト設計ができた • 切り戻しの体制が整ったことで、より安全に 移⾏をする準備が整った 59
60. 属性の洗い出しは⼤変だったが役に⽴った • 検証する必要のある属性を洗い出したこと で、テストパターンの設計や、段階移⾏の計 画を⽴てるのに役⽴った ◦ 洗い出し⾃体は時間もかかったがやってよ かった ◦ 過度なテストを防ぐことができた 60
61. 切り戻しができることは⼤事 • 安⼼して移⾏に臨める • あらかじめどういう場合に切り戻しの判断を するか整理しておくのも必要 61
62. Tips3: ドキュメント整備
63. 課題 • 仕様書や設計書をきちんと残す⽂化のない チームだった • 会社のドキュメンテーションツールがNotion に移⾏したタイミングだった ◦ ここからドキュメント管理をしっかりやり たいという機運が⾼まった 63
64. テンプレートの作成‧活⽤ • 仕様書、設計書、仕様調査ログ、技術調査ロ グ、議事録などのテンプレートを作成 • 他のチームの取り組みも聞きに⾏った 64
65. ユーザーストーリーベースの設計書 • 設計書はユーザーストーリーベースで書くよ うにした ◦ 何が変わるのか∕何が変わらないのか ◦ ユーザーは何ができるのか∕何ができない のか 65
66. ユーザーストーリーの例 • クレジットカードを登録してこれまで通りプ ラン登録ができる • クレジットカードを登録してプラン登録をし たユーザーが退会ボタンを押すことで退会で きる 66
67. 何を実装するかブレイクダウンする • クレジットカードを登録してこれまで通りプ ラン登録ができる • クレジットカードを登録してプラン登録をし たユーザーが退会ボタンを押すことで退会で きる 67 ‧退会できるかの判定 ‧契約の削除 ‧ユーザーの削除
68. チームとしての判断をドキュメントに残す • チームとしての判断、選択をログとしてド キュメントに残すようにした ◦ どんなやり⽅を検討したのか、決定案を選 んだ根拠 • なぜこの⽅法を選んだのか∕選ばなかったの かが追える 68
69. ドキュメントに残して助かった例 • SmartHR基本機能で持っているある値を Zuoraの情報をもとに更新する⽅法を検討 ◦ 定期バッチでZuoraから取得する ◦ 変更時にZuoraからAPIを叩いてもらう ◦ etc… 69
70. ドキュメントに残して助かった例 • 最初に考えていた⽅法では上⼿く⾏かなかっ た • 別の⽅法を選んだときの懸念点や事前調査が すでにドキュメントにまとまっていた • 懸念点をクリアできれば別の⽅法が取れそう ということがすぐにわかった 70
71. 成果 • 実装時‧調査時の⼿戻りが減った • AIコーディングを活⽤する中でドキュメントがあ ることは⾮常に役⽴った ◦ プロジェクトの途中からAIコーディングの機会 が増えた ◦ ⼈間が読む以上にAIに読ませる機会が増えた 71
72. ドキュメント化することは良かった • Notion AIによって、どこかに書いてさえいれ ば⾒つけられるようになった 72
73. ドキュメントの賞味期限管理が難しい • いつまで設計書をメンテナンスするべきか • 期限を区切るとしたら、期限はどう管理され ていると良いか 73
74. AIの書いたドキュメントの可読性 • プロジェクトの途中からドキュメントをAIに 書かせる取り組みをはじめた • AIの書いたドキュメントのレビューが難しい 74
75. Tips4: タスクの優先度調整
76. 課題 • 設計書を作成し、必要なタスクをチケット化 • チケット化されたタスクをそのままやってい くと上⼿くいかない ◦ 並⾏して進めるのが難しいチケット ◦ 事前の確認に時間がかかるチケット 76
77. チケット同⼠の前後関係の確認 • チケット同⼠の前後関係を確認し、どの順番 で進めると早く実装が終わるかを考える ◦ 他のチケットのブロッキングになるチケッ トの優先度を上げる ◦ コード上で同じところを触るチケットを同 じスプリントに⼊れない 77
78. 成果 • リードの頑張りで⼀定回ってはいた →これってリードがやらなければいけないこ となのか…？ 78
79. チームメンバーに役割を委譲 • 設計書の作成を進めたメンバーにチケットの 対応順序の調整もやってもらうようにした →これって⼈間がやらなければいけないこと なのか…？ 79
80. 考えていたことの⾔語化 • チケットの優先度を決める上で考慮すること ◦ 不確実性 ◦ 他タスクのブロッキングであるか ◦ タスク間でコードを触る箇所が被らないか 80
81. AIのSkillを活⽤ • AIにチケットを読ませ、チケットの内容を考 慮して優先順位をつけさせるSkillを作成 • Claude Codeを利⽤してリードの仕事をさせ るようにした 81
82. タスク消化の部分はAIに代替させていく • プロジェクトに向かってチームが⾛れる状態 を作ること →AIに代替させることができることが多そう  ⼈間がやるべき仕事を絞る 82
83. コードを書く以外の プロジェクト推進
84. SmartHRにおけるリードの役割（再掲） • プロジェクトの不確実性を減らすこと ◦ 道を作る • プロジェクト完了に向かってチームが⾛れる 状態を作ること ◦ 道に⾞を⾛らせる 84 何をすればこの2つが達成 できる？
85. やらなければいけないことを⾒つける • 落ちているボールを拾う ◦ 曖昧なままになっている事柄はないか ◦ プロジェクトを進める上で障壁はないか ◦ 担当者が決まっていないタスクはないか 85
86. やるべきことを⾒つけるポイント • プロジェクトメンバー間での会話 ◦ 「この作業っていつやるんですっけ？」 • 開発していて感じる困りごと∕不安 ◦ 「このまま進めて⼤丈夫なんだっけ？」 →やるべきことの種がある 86
87. ⾃分⼀⼈で解決する必要はない • 拾って適切な⼈にボールを投げる ◦ 例 ▪ タスク化してチームメンバーに依頼 ▪ QAエンジニアの巻き込み ▪ ユーザーコミュニケーションにおける PM、UXライターの巻き込み 87
88. プロジェクトの現在地
89. 本番環境での移⾏がスタート • テストが完了したところ • 第1グループの移⾏が始まったところ • ここからは計画に沿って進めていくフェーズ 89
90. まとめ
91. 本⽇話したTips • 他チームとの調整 • 検証‧移⾏計画策定 • ドキュメント整備 • タスクの優先度調整 91
92. AI時代のプロダクトエンジニア • AIによって様々な作業（設計‧コーディン グ）がサポートされるようになってきた • タスク化されていないやるべきことを⾒つけ る⼒がより重要になっていきそう 92
93. ⽬的はユーザーに価値を提供すること • コードを書くことだけでは価値を提供できな い • プロジェクトを推進するために必要なことを なんでもやるマインドが必要になる 93