サービスを陳腐化させない組織だった技術刷新 / Technology Renewal Initiatives

Slide 1

Slide 1 text

Slide 2

Slide 2 text

#RAKUSMeetup 鈴木勇 / @moomooya LTの売人（足を洗い気味）株式会社ラクス技術推進課 ● ガンプラ部部長 ● 技術推進プロジェクト旗振り ● 技術ロードマップ更新主幹 ● 各チームのお悩み相談プライベート ● 自宅ESXi管理者 ○ 先日マイクラサーバー再稼働した ○ 「書類、”共有”に入れておいた」という一般的な家庭の会話 ● ボドゲデザイナー ● 写真展やったり ● 料理したり ○ 某Youtuberが経営してた店より美味いらしい……

Slide 3

Slide 3 text

#RAKUSMeetup 今日のお題 1. ビジネスの成功 2. システムの陳腐化 3. 技術刷新タイミングの逸脱 4. ではどうするか？

Slide 4

Slide 4 text

#RAKUSMeetup ビジネスの成功→サービスの長命化 ● ビジネスの失敗→サービスクローズ ● ビジネスの成功→🎉長寿サービスの誕生🎉 エンジニアリングにとって　　「作る」ことは大事　　「続ける」ことはもっと大事（＝大変）

Slide 5

Slide 5 text

#RAKUSMeetup サービスが成功すると成長期に利益を伸ばすため大量の機能を実装する＝技術的負債の蓄積

Slide 6

Slide 6 text

#RAKUSMeetup 成熟期には顧客が多く大規模な改修がしにくくなる開発速度も余裕はない＝システムの陳腐化

Slide 7

Slide 7 text

#RAKUSMeetup

Slide 8

Slide 8 text

#RAKUSMeetup 今回は「システムの陳腐化」について

Slide 9

Slide 9 text

#RAKUSMeetup なぜ大規模な改修がしにくいのかビジネスサイドと合意しながら進める開発だと　「良くなりそうだけど　　良くならないかもしれない　　　でもきっと良くなる」という開発項目は取り組みにくい。本当は「○○を検証する」というタスクで予算確保できるとよい。が、現実は厳しいことが多い。

Slide 10

Slide 10 text

#RAKUSMeetup 不確定性がなくなれば解決する？成果が見えていれば開発項目に取り込みやすい。 →サービス開発とは別に予算確保できる仕組みを構築 ※実際には全サービスで割り勘してるだけ先行検証の仕組みが整った

Slide 11

Slide 11 text

#RAKUSMeetup やりたいことは多い～理想と現実～これで解決、とはいかない。検証したい項目は無限にある。手当り次第やるわけにはいかない。自社で「一番イケてないところ」から順番決めて取り掛かる。

Slide 12

Slide 12 text

#RAKUSMeetup イケてない＞＞（超えられない壁）＞＞＞やるとカッコいいイメージとしては　　並に出来てる（コスト5） → イケてる（コスト3） 2改善よりも　　イケてない（コスト10） → 並に出来てる（コスト5） 5改善を優先する。

Slide 13

Slide 13 text

#RAKUSMeetup https://speakerdeck.com/moomooya/distribute-tasks

Slide 14

Slide 14 text

#RAKUSMeetup 技術ロードマップ

Slide 15

Slide 15 text

#RAKUSMeetup 何を検証していくかのロードマップ事業の成長ペースやサービス特性、顧客特性、技術トレンドを考慮して必要になる技術の優先度付けをしたもの。 3年先までを目処に毎年更新。更新作業は社内のベテランエンジニアを総出で駆り出す。 →このロードマップに従って技術検証を進める

Slide 16

Slide 16 text

#RAKUSMeetup 技術検証について前提として「サービス開発の中で検証、導入検討する」のがベスト技術ロードマップから拾いきれない部分を先行検証プロジェクト（＝「技術推進プロジェクト」）で別途対応。

Slide 17

Slide 17 text

#RAKUSMeetup 技術推進プロジェクト

Slide 18

Slide 18 text

#RAKUSMeetup 技術推進プロジェクトの実績マイクロサービス無停止運用フレームワーク匿名化情報機械学習認証認可 GraphQL ……

Slide 19

Slide 19 text

#RAKUSMeetup プロジェクトのサイクル

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

#RAKUSMeetup 技術推進プロジェクトでの検証成果各テーマの検証成果は開発組織内に共有。要否の判断も期待しているので ● 導入したいもの ● 導入の必要がないものの両方とも出てくる。それもまた取り組みの成果。

Slide 23

Slide 23 text

#RAKUSMeetup 検証成果はできる限り公開あまり社内ではアピールしてないけど ”openess” に従って検証成果はできるだけ公開。国内Webサービス発展の一助となれば。 https://tech-blog.rakus.co.jp/

Slide 24

Slide 24 text

#RAKUSMeetup 本取り組み自体もオープンにテックブログでも記事にしていますが、今日話した仕組みについてもオープンにしてます。同じ悩みをもつ企業様で取り込む際の参考にしてもらえれば。（その成果もオープンにしてもらえると嬉しい……） https://tech-blog.rakus.co.jp/entry/20211216/gisui

Slide 25

Slide 25 text

#RAKUSMeetup こういった取り組みの注意点開発組織全体の位置付けとしてはサービスの「技術刷新の促進」サービスに反映されるまでは3～4年くらいかかります。 ● 大きな仕組み変更は年単位で計画している ● そもそも3年先の課題感を見越している確信持ってじっくりやるのが大事 ※「認証基盤」の話は珍しい例

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

#RAKUSMeetup Thank you for your watching. 🙂