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

Slide 1

Slide 1 text

Slide 2

Slide 2 text

#RAKUSTechCon 2013年ラクス入社。北米向けサービス開発、国内向けサービス開発に携わり、スマホアプリ開発、AI機能開発などを主導し、新しい技術要素を積極的に導入してきた。 2020年に技術推進課を新たに立ち上げ、技術検証、現場の技術課題解決支援など幅広いミッションにマネージャーとして取り組んでいる。堀内泰秀（ほりうちやすひで） 2

Slide 3

Slide 3 text

#RAKUSTechCon 大手SIer、小規模ベンチャーを経て、2013年ラクスに入社。楽楽明細の開発にサービス開始2ヶ月から参加。コードレビュー率100%と、社内にビアバッシュ文化の定着を達成。その後、楽楽労務のアーキテクチャ検討＆初期開発担当を経て開発部門横断で技術検証や組織文化醸成などに携わる。 2020年から現在の技術推進課に所属。ラクスガンプラ部の部長でもある。鈴木勇（すずきいさむ） 3

Slide 4

Slide 4 text

#RAKUSTechCon ラクス「技術推進課」とは技術で横断的にチャレンジする組織と覚えて帰ってください

Slide 5

Slide 5 text

#RAKUSTechCon 「開発優先」で新しい技術にチャレンジできないこんなお悩みありませんか？

Slide 6

Slide 6 text

#RAKUSTechCon 優先順位は大事新機能顧客要望 CS 要望新技術リファクタ自動化

Slide 7

Slide 7 text

#RAKUSTechCon 優先順位は大事。顧客要望 CS 要望新技術リファクタ自動化

Slide 8

Slide 8 text

#RAKUSTechCon 優先順位は大事、だけど。。。新機能新技術リファクタ自動化最優先でお願い！わ、わかりましたー！

Slide 9

Slide 9 text

#RAKUSTechCon 新しい技術にチャレンジしないとどうなるのか

Slide 10

Slide 10 text

#RAKUSTechCon 性能時間技術進歩の「S字カーブ理論」技術開発の進展と性能の成長の関係を表す。性能は・最初ゆっくり・急激に早く・そして徐々に遅くなるという理論

Slide 11

Slide 11 text

#RAKUSTechCon 性能時間従来の技術新技術技術進歩の「S字カーブ理論」

Slide 12

Slide 12 text

#RAKUSTechCon 性能時間技術進歩の「S字カーブ理論」

Slide 13

Slide 13 text

#RAKUSTechCon 開発速度時間ラクス開発組織の危機感ラクスの開発速度競合他社の開発速度

Slide 14

Slide 14 text

#RAKUSTechCon ラクスのサービス開発のかねてからの課題 ● 新しい技術を使おうとしても時間的に余裕がない ● 古い技術だらけになったら社内のエンジニアもやめていきそう ● 個人で使った経験があってもプロダクションレベルでの利用がないとリスキーと判断されがち ● 実サービスでは問題が出ない限りコストメリットの見えない技術刷新の優先度低い

Slide 15

Slide 15 text

Slide 16

Slide 16 text

#RAKUSTechCon 似たような話「あとでクリーンにすればいいよ。先に市場に出さなければ！」開発者たちはそうやっていつもごまかす。だが、あとでクリーンにすることはない。市場からのプレッシャーは止まらないからだ。「先に市場に出さなければ」ということは、後ろに競合他社が大勢いるということである。競合他社に追い抜かれないためには、これからも走り続けるしかない。 Clean Architectureより引用

Slide 17

Slide 17 text

Slide 18

Slide 18 text

#RAKUSTechCon コストメリットの見えない技術刷新の優先度低い

Slide 19

Slide 19 text

#RAKUSTechCon これからも走り続けるしかない

Slide 20

Slide 20 text

#RAKUSTechCon 優先度上がってこないよね・・・

Slide 21

Slide 21 text

#RAKUSTechCon じゃぁどうするのか？

Slide 22

Slide 22 text

#RAKUSTechCon 普段から少しずつ検証しておくしかない

Slide 23

Slide 23 text

#RAKUSTechCon 試行錯誤を繰り返しながら

Slide 24

Slide 24 text

#RAKUSTechCon 2020年「技術推進プロジェクト」誕生

Slide 25

Slide 25 text

#RAKUSTechCon とはいえ自分たちだけ知ってても意味がない

Slide 26

Slide 26 text

#RAKUSTechCon

Slide 27

Slide 27 text

#RAKUSTechCon 取り組みの立ち上がりから継続していくための仕組みづくり

Slide 28

Slide 28 text

#RAKUSTechCon ● 2017年：前身となる「かみせんプロジェクト」発足 ○ 「かみせん」＝「開発の未来に先手を打つ」の略 ○ 各開発チームを横断したプロジェクトで正式な組織ではなかった ● 2018年：新規サービス開発のためプロジェクト休止 ● 2019年：プロジェクト再開 ● 2020年：課として発足、「技術推進プロジェクト」に改名技術推進プロジェクト組織の変遷

Slide 29

Slide 29 text

#RAKUSTechCon ● 2017年プロジェクト初期 ○ 各チームのベテランエンジニアを集めて複数テーマをまとめて検証 ● 2019年プロジェクト再開期 ○ 中堅エンジニアを巻き込んでいかないと継続できないという観点から参加メンバーを若年化 ○ 人数が多いとマネジメントコストが上がるので、少人数チーム（ 3人）に分割 ○ 1チームごとに1テーマに絞って検証を行い、負担を軽減 ● 2020年組織発足期～ ○ 2, 3人の少人数チーム、 1チーム1テーマが成り立つとわかったのでスケール ○ 2020年は6チーム、2021年は7チームで実施検証チームの構成、規模

Slide 30

Slide 30 text

#RAKUSTechCon 1チーム1テーマで負荷を軽減したが、メイン業務との兼務は大変。リーダーはプレイングマネージャー的な動きを求められるので特に。 ● リーダー ○ マネジメント（＋検証ヘルプ） ● メンバー ○ 検証に専念と役割を分けて、メンバーを1人追加するパターンを検証予定。さらなる改善：検証チーム構成の見直し

Slide 31

Slide 31 text

#RAKUSTechCon プロジェクト実施のサイクル

Slide 32

Slide 32 text

#RAKUSTechCon プロジェクトのサイクル約８ヶ月間の準備期間 ● テーマの必要性検討 ● 人員の確保 ○ 各部署との調整 ○ 興味とテーマのマッチング

Slide 33

Slide 33 text

#RAKUSTechCon ● 人員 ○ テーマごとに２～3人 ■ リーダー１人 ● ベテランエンジニア ■ メンバー1～2人 ● ３年目以降くらい ● 時間、期間 ○ 週５時間 ○ 半期もしくは通年 ■ ３人＝約2人月/半期 ● 実施 ○ チームごとに実施日を設定 ○ 実施日に集まって検証調査の様子～上期の例 ● 4～5月 ○ 顔合わせ ○ テーマについて調査 ● 6月 ○ 検証詳細を計画 ○ 検証環境の構築 ● 7～8月 ○ 検証実施 ○ 成果発表準備 ● 9月 ○ 成果発表

Slide 34

Slide 34 text

#RAKUSTechCon 各テーマの検証成果は開発組織内に共有。要否の判断も期待しているので ● 導入したいもの ● 導入の必要がないものの両方とも出てくる。検証成果について

Slide 35

Slide 35 text

#RAKUSTechCon なぜ自社で検証しているのか？

Slide 36

Slide 36 text

#RAKUSTechCon 情報はあるがラクスの事情を考慮した情報はない。 ● そこそこな規模＆10年以上稼働するサービス複数 ● オンプレミス環境も活用 ● B2B中心なので技術選定は安定性重視 ● B2Bサービスは法律に影響受けやすい ● サービスごとの所属エンジニア人数＆スキルマップ ● 採算性重視 ● などなど…… 世間には情報があふれているのになぜ自社検証？

Slide 37

Slide 37 text

#RAKUSTechCon 「ラクスで」使えるか？の検証は自分たちでやるしかない

Slide 38

Slide 38 text

#RAKUSTechCon 例えば「マイクロサービスアーキテクチャ」結論としては導入しないと判断した（2017年）。端的に言えば技術がターゲットとする規模の違い。流行りの技術が「使える」とは限らない GitHubですら後悔しているというツイートが話題になっていた

Slide 39

Slide 39 text

#RAKUSTechCon 開発組織全体の位置付けとしてはサービスの「技術刷新の促進」サービスに反映されるまでは2～4年くらいを覚悟 ● 大きな仕組み変更は年単位で計画している ● そもそも3年先の課題感を見越している確信持ってじっくりやるのが大事「使える」→「導入」までの間も長い

Slide 40

Slide 40 text

#RAKUSTechCon たくさん検証していくとすぐに活用されるテーマも。一部は検証した翌年に活用されました。 ● 「モバイルビルドプロセス改善」「MQ導入」（2020年検証） ○ それぞれ2021年に成果物をもとにサービスに導入された ● 「バンドルJSの肥大化対策」（2021年検証） ○ 2022年にサービスに導入され、副産物としてビルド時間も 1/9に短縮成果の活用までが早かった例

Slide 41

Slide 41 text

#RAKUSTechCon 継続は力なり

Slide 42

Slide 42 text

#RAKUSTechCon ラクスでは…… 長寿サービスを衰退させないために３年以上前から先手を打って陳腐化を防ごうとしています。というお話でした。

Slide 43

Slide 43 text

#RAKUSTechCon Thank you for your watching. 🙂