「開発優先」の中で取り組む組織的な新技術への挑戦/20230208_horiuchi_suzuki

「機能開発を優先しているためリファクタリングができない」この状態に陥っている方、多いのではないでしょうか。
サービス開発では立ち上げから売れ始めるまでの間、プロダクトマーケットフィットを目指して最短距離を走ることを求められます。
その中で行われる意思決定では必ずしもすべてが最適解を得られるわけではありません。また時を経るにつれて最適解が最適解でなくなることもあるでしょう。
「サービスがある程度軌道に乗り、開発体制も整ってきたらリファクタリングやリアーキテクトしたい」――しかしベテランエンジニアの方はそんなタイミングが訪れないと知っているはずです。
そんな厳しい現実を直視して、ラクスではどのような対応を取ってきたのかをご紹介しようと思います。

本発表では以下のような内容をお話しします。

・ラクスにおける取り組みの概要
・取り組みの立ち上がりから継続していくための仕組みづくり
・取り組み実施のサイクル
・自社で検討することのメリット

Transcript

1. #RAKUSTechCon © 2023 Rakus Co.,Ltd
 「開発優先」の中で取り組む組 織的な新技術への挑戦 2023.2.8 技術推進課 堀内泰秀、鈴木勇
2. #RAKUSTechCon 2013年ラクス入社。 北米向けサービス開発、国内向けサービス開発に携わり、 スマホアプリ開発、AI機能開発などを主導し、新しい技術要素を積極的に導 入してきた。 2020年に技術推進課を新たに立ち上げ、技術検証、現場の技術課題解決 支援など幅広いミッションにマネージャーとして取り組んでいる。 堀内 泰秀（ほりうち やすひで） 2
3. #RAKUSTechCon 大手SIer、小規模ベンチャーを経て、2013年ラクスに入社。 楽楽明細の開発にサービス開始2ヶ月から参加。 コードレビュー率100%と、社内にビアバッシュ文化の定着を達成。 その後、楽楽労務のアーキテクチャ検討＆初期開発担当を経て 開発部門横断で技術検証や組織文化醸成などに携わる。 2020年から現在の技術推進課に所属。 ラクスガンプラ部の部長でもある。 鈴木勇（すずきいさむ） 3
4. #RAKUSTechCon ラクス「技術推進課」とは 技術で 横断的に チャレンジする組織 と覚えて帰ってください
5. #RAKUSTechCon 「開発優先」 で新しい技術に チャレンジできない こんなお悩みありませんか？
6. #RAKUSTechCon 優先順位は大事 新機能 顧客 要望 CS 要望 新技術 リファク タ 自動化
7. #RAKUSTechCon 優先順位は大事。 顧客 要望 CS 要望 新技術 リファク タ 自動化
8. #RAKUSTechCon 優先順位は大事、だけど。。。 新機能 新技術 リファク タ 自動化 最優先でお願 い！ わ、わかりまし たー！
9. #RAKUSTechCon 新しい技術に チャレンジしないと どうなるのか
10. #RAKUSTechCon 性能 時間 技術進歩の「S字カーブ理論」 技術開発の進展と性能の成長の関係を表す。 性能は ・最初ゆっくり ・急激に早く ・そして徐々に遅くなる という理論
11. #RAKUSTechCon 性能 時間 従来の技術 新技術 技術進歩の「S字カーブ理論」
12. #RAKUSTechCon 性能 時間 技術進歩の「S字カーブ理論」
13. #RAKUSTechCon 開発速度 時間 ラクス開発組織の危機感 ラクスの 開発速度 競合他社の 開発速度
14. #RAKUSTechCon ラクスのサービス開発のかねてからの課題 • 新しい技術を使おうとしても時間的に余裕がない • 古い技術だらけになったら社内のエンジニアもやめていきそう • 個人で使った経験があってもプロダクションレベルでの利用がないとリ スキーと判断されがち • 実サービスでは問題が出ない限りコストメリットの見えない技術刷新の 優先度低い
15. #RAKUSTechCon ラクスのサービス開発のかねてからの課題 • 新しい技術を使おうとしても時間的に余裕がない • 古い技術だらけになったら社内のエンジニアもやめていきそう • 個人で使った経験があってもプロダクションレベルでの利用がないとリ スキーと判断されがち • 実サービスでは問題が出ない限りコストメリットの見 えない技術刷新の優先度低い
16. #RAKUSTechCon 似たような話 「あとでクリーンにすればいいよ。先に市場に出さなければ！」 開発者たちはそうやっていつもごまかす。 だが、あとでクリーンにすることはない。 市場からのプレッシャーは止まらないからだ。 「先に市場に出さなければ」ということは、後ろに競合他社が大勢いるという ことである。競合他社に追い抜かれないためには、 これからも走り続けるしかない。 Clean Architectureより引用
17. #RAKUSTechCon 似たような話 「あとでクリーンにすればいいよ。先に市場に出さなければ！」 開発者たちはそうやっていつもごまかす。 だが、あとでクリーンにすることはない。 市場からのプレッシャーは止まらないからだ。 「先に市場に出さなければ」ということは、後ろに競合他社が大勢いるという ことである。競合他社に追い抜かれないためには、 これからも走り続けるしかない。 Clean Architectureより引用
18. #RAKUSTechCon コストメリットの見えない 技術刷新の優先度低い
19. #RAKUSTechCon これからも走り続けるしかない
20. #RAKUSTechCon 優先度上がってこないよね・・・
21. #RAKUSTechCon じゃぁどうするのか？
22. #RAKUSTechCon 普段から少しずつ 検証しておくしかない
23. #RAKUSTechCon 試行錯誤を繰り返しながら
24. #RAKUSTechCon 2020年「技術推進プロジェクト」誕生
25. #RAKUSTechCon とはいえ 自分たちだけ知ってても 意味がない
26. #RAKUSTechCon
27. #RAKUSTechCon 取り組みの立ち上がりから 継続していくための仕組みづくり
28. #RAKUSTechCon • 2017年：前身となる「かみせんプロジェクト」発足 ◦ 「かみせん」＝「開発の未来に先手を打つ」の略 ◦ 各開発チームを横断したプロジェクトで正式な組織ではなかった • 2018年：新規サービス開発のためプロジェクト休止 • 2019年：プロジェクト再開 • 2020年：課として発足、「技術推進プロジェクト」に改名 技術推進プロジェクト組織の変遷
29. #RAKUSTechCon • 2017年 プロジェクト初期 ◦ 各チームのベテランエンジニアを集めて複数テーマをまとめて検証 • 2019年 プロジェクト再開期 ◦ 中堅エンジニアを巻き込んでいかないと継続できないという観点から 参加メンバーを若年化 ◦ 人数が多いとマネジメントコストが上がるので、少人数チーム（ 3人）に分割 ◦ 1チームごとに1テーマに絞って検証を行い、負担を軽減 • 2020年 組織発足期～ ◦ 2, 3人の少人数チーム、 1チーム1テーマが成り立つとわかったのでスケール ◦ 2020年は6チーム、2021年は7チームで実施 検証チームの構成、規模
30. #RAKUSTechCon 1チーム1テーマで負荷を軽減したが、メイン業務との兼務は大変。 リーダーはプレイングマネージャー的な動きを求められるので特に。 • リーダー ◦ マネジメント（＋検証ヘルプ） • メンバー ◦ 検証に専念 と役割を分けて、メンバーを1人追加するパターンを検証予定。 さらなる改善：検証チーム構成の見直し
31. #RAKUSTechCon プロジェクト実施のサイクル
32. #RAKUSTechCon プロジェクトのサイクル 約８ヶ月間の準備期間 • テーマの必要性検討 • 人員の確保 ◦ 各部署との調整 ◦ 興味とテーマのマッチング
33. #RAKUSTechCon • 人員 ◦ テーマごとに２～3人 ▪ リーダー１人 • ベテランエンジニア ▪ メンバー1～2人 • ３年目以降くらい • 時間、期間 ◦ 週５時間 ◦ 半期もしくは通年 ▪ ３人 ＝ 約2人月/半期 • 実施 ◦ チームごとに実施日を設定 ◦ 実施日に集まって検証 調査の様子～上期の例 • 4～5月 ◦ 顔合わせ ◦ テーマについて調査 • 6月 ◦ 検証詳細を計画 ◦ 検証環境の構築 • 7～8月 ◦ 検証実施 ◦ 成果発表準備 • 9月 ◦ 成果発表
34. #RAKUSTechCon 各テーマの検証成果は開発組織内に共有。 要否の判断も期待しているので • 導入したいもの • 導入の必要がないもの の両方とも出てくる。 検証成果について
35. #RAKUSTechCon なぜ自社で検証しているのか？
36. #RAKUSTechCon 情報はあるがラクスの事情を考慮した情報はない。 • そこそこな規模＆10年以上稼働するサービス複数 • オンプレミス環境も活用 • B2B中心なので技術選定は安定性重視 • B2Bサービスは法律に影響受けやすい • サービスごとの所属エンジニア人数＆スキルマップ • 採算性重視 • などなど…… 世間には情報があふれているのになぜ自社検証？
37. #RAKUSTechCon 「ラクスで」使えるか？ の検証は自分たちでやるしかない
38. #RAKUSTechCon 例えば「マイクロサービスアーキテクチャ」 結論としては導入しないと判断した（2017年）。 端的に言えば技術がターゲットとする規模の違い。 流行りの技術が「使える」とは限らない GitHubですら後悔しているという ツイートが話題になっていた
39. #RAKUSTechCon 開発組織全体の位置付けとしてはサービスの「技術刷新の促進」 サービスに反映されるまでは2～4年くらいを覚悟 • 大きな仕組み変更は年単位で計画している • そもそも3年先の課題感を見越している 確信持ってじっくりやるのが大事 「使える」→「導入」までの間も長い
40. #RAKUSTechCon たくさん検証していくとすぐに活用されるテーマも。 一部は検証した翌年に活用されました。 • 「モバイルビルドプロセス改善」「MQ導入」（2020年検証） ◦ それぞれ2021年に成果物をもとにサービスに導入された • 「バンドルJSの肥大化対策」（2021年検証） ◦ 2022年にサービスに導入され、副産物としてビルド時間も 1/9に短縮 成果の活用までが早かった例
41. #RAKUSTechCon 継続は力なり
42. #RAKUSTechCon ラクスでは…… 長寿サービスを衰退させないために ３年以上 前から先手を打って 陳腐化を防ごうとしています。 というお話でした。
43. #RAKUSTechCon Thank you for your watching. 🙂