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

2022.6.1実施のRAKUS Meetupにて発表した資料です。

Transcript

1. #RAKUSMeetup
   ©2022 RAKUS Co., Ltd.
   サービスを陳腐化させない
   組織だった技術刷新
   2022.6.1
   Isamu Suzuki
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

7. #RAKUSMeetup
   

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

14. #RAKUSMeetup
    技術ロードマップ
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

27. #RAKUSMeetup
    Thank you for your watching.
    🙂
    

    View Slide