Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
サービスを陳腐化させない組織だった技術刷新 / Technology Renewal Initiatives
Search
moomoo-ya
June 01, 2022
Technology
0
910
サービスを陳腐化させない組織だった技術刷新 / Technology Renewal Initiatives
2022.6.1実施のRAKUS Meetupにて発表した資料です。
moomoo-ya
June 01, 2022
Tweet
Share
More Decks by moomoo-ya
See All by moomoo-ya
はじめてのオンラインイベント配信 with COVID-19 バグ修正版 / Online-Event-bugfixed
moomooya
0
55
一番安い子だーれだ?~黒字化のための無慈悲なタスク配分~ / Distribute tasks
moomooya
0
2.6k
はじめてのオンラインイベント配信 with COVID-19 バグあり版 / Online-Event-includes-bug
moomooya
0
740
やはり俺のLT登壇はまちがっている。 / my-lightning-talk-is-wrong-as-i-expected
moomooya
4
1.8k
Gatsby.jsで.md/.adocが混在できるテンプレートを作ったときの苦しみ / Pain-to-create-gatsby-template-that-supports-markdown-and-asciidoc
moomooya
0
470
LADRのすすめ&先行技術検証PRJの紹介 / Introducing-LADR-and-Technology-verification
moomooya
5
2.1k
技術書へのアクセスを劇的に向上させた話 / oreilly-safari-and-acm-membership
moomooya
2
6.9k
モノリスにおけるビジネスロジックの設計 ~アグリゲートパターン~ / aggregate-pattern-for-domain-modeling-on-monolithic
moomooya
2
1.1k
オブジェクト指向を学んでから20年間でモヤったこと / Object-Oriented-groomy-in-20-years
moomooya
0
410
Other Decks in Technology
See All in Technology
生成AI活用推進の為にやったこと/やらなかったこと
ktc_wada
0
180
日本が誇るイタリアのダンスミュージック!? ユーロビートって何??
minorun365
PRO
2
230
PHP 9 に備えよ - 動的プロパティ、どうすればいぃ?
taisukearase
0
340
スクラムに出会って「できた」を実感できるようになってきた話 / Scrum makes me feel like I can do it
yayoi_dd
2
110
Cloudflare WorkersがPythonに対応したので試してみた
miura55
0
190
PhpStorm超絶技巧40分集中講義 #phpconkagawa
yusuke
4
780
複雑なビジネスルールに挑む:正確性と効率性を両立するfp-tsのチーム活用術 / Strike a balance between correctness and efficiency with fp-ts
kakehashi
5
3.6k
社内での継続的な機械学習勉強会の開催のコツ
yudai00
2
390
個人的、Kubernetes の最新注目機能! (2024年5月版) / TechFeed Experts Night#28 〜 コンテナ技術最前線
pfn
PRO
3
210
LINEヤフーのウェブアクセシビリティ
lycorptech_jp
PRO
2
180
SWC Transformerから見るTypeScript関数記述ベストプラクティス
fujiyamaorange
1
180
汎用ポリシー言語Rego + OPAと認可・検証事例の紹介 / Introduction Rego & OPA for authorization and validation
mizutani
1
160
Featured
See All Featured
The World Runs on Bad Software
bkeepers
PRO
61
6.7k
Gamification - CAS2011
davidbonilla
77
4.6k
Bash Introduction
62gerente
605
210k
Put a Button on it: Removing Barriers to Going Fast.
kastner
58
3.1k
Become a Pro
speakerdeck
PRO
13
4.6k
Clear Off the Table
cherdarchuk
86
310k
[RailsConf 2023] Rails as a piece of cake
palkan
29
4.1k
A Philosophy of Restraint
colly
197
16k
Adopting Sorbet at Scale
ufuk
69
8.6k
Building Applications with DynamoDB
mza
88
5.7k
VelocityConf: Rendering Performance Case Studies
addyosmani
321
23k
Code Reviewing Like a Champion
maltzj
516
39k
Transcript
#RAKUSMeetup ©2022 RAKUS Co., Ltd. サービスを陳腐化させない 組織だった技術刷新 2022.6.1 Isamu Suzuki
#RAKUSMeetup 鈴木 勇 / @moomooya LTの売人(足を洗い気味) 株式会社ラクス 技術推進課 • ガンプラ部
部長 • 技術推進プロジェクト 旗振り • 技術ロードマップ更新 主幹 • 各チームのお悩み相談 プライベート • 自宅ESXi管理者 ◦ 先日マイクラサーバー再稼働した ◦ 「書類、”共有”に入れておいた」 という一般的な家庭の会話 • ボドゲデザイナー • 写真展やったり • 料理したり ◦ 某Youtuberが経営してた店 より美味いらしい……
#RAKUSMeetup 今日のお題 1. ビジネスの成功 2. システムの陳腐化 3. 技術刷新タイミングの逸脱 4. ではどうするか?
#RAKUSMeetup ビジネスの成功→サービスの長命化 • ビジネスの失敗→サービスクローズ • ビジネスの成功→🎉長寿サービスの誕生🎉 エンジニアリングにとって 「作る」ことは大事 「続ける」ことはもっと大事(=大変)
#RAKUSMeetup サービスが成功すると 成長期に利益を伸ばすため 大量の機能を実装する =技術的負債の蓄積
#RAKUSMeetup 成熟期には顧客が多く 大規模な改修がしにくくなる 開発速度も余裕はない =システムの陳腐化
#RAKUSMeetup
#RAKUSMeetup 今回は 「システムの陳腐化」 について
#RAKUSMeetup なぜ大規模な改修がしにくいのか ビジネスサイドと合意しながら進める開発だと 「良くなりそうだけど 良くならないかもしれない でもきっと良くなる」 という開発項目は取り組みにくい。 本当は「◦◦を検証する」というタスクで予算確保できるとよい。 が、現実は厳しいことが多い。
#RAKUSMeetup 不確定性がなくなれば解決する? 成果が見えていれば開発項目に取り込みやすい。 →サービス開発とは別に予算確保できる仕組みを構築 ※実際には全サービスで割り勘してるだけ 先行検証の仕組みが整った
#RAKUSMeetup やりたいことは多い~理想と現実~ これで解決、とはいかない。 検証したい項目は無限にある。手当り次第やるわけにはいかない。 自社で「一番イケてないところ」から順番決めて取り掛かる。
#RAKUSMeetup イケてない>>(超えられない壁)>>>やるとカッコいい イメージとしては 並に出来てる(コスト5) → イケてる(コスト3) 2改善 よりも イケてない(コスト10) →
並に出来てる(コスト5) 5改善 を優先する。
#RAKUSMeetup https://speakerdeck.com/moomooya/distribute-tasks
#RAKUSMeetup 技術ロードマップ
#RAKUSMeetup 何を検証していくかのロードマップ 事業の成長ペースやサービス特性、顧客特性、技術トレンドを考慮し て必要になる技術の優先度付けをしたもの。 3年先までを目処に毎年更新。 更新作業は社内のベテランエンジニアを総出で駆り出す。 →このロードマップに従って技術検証を進める
#RAKUSMeetup 技術検証について 前提として「サービス開発の中で検証、導入検討する」のがベスト 技術ロードマップから拾いきれない部分を 先行検証プロジェクト(=「技術推進プロジェクト」)で別途対応。
#RAKUSMeetup 技術推進プロジェクト
#RAKUSMeetup 技術推進プロジェクトの実績 マイクロサービス 無停止運用 フレームワーク 匿名化情報 機械学習 認証認可 GraphQL ……
#RAKUSMeetup プロジェクトのサイクル
#RAKUSMeetup プロジェクトのサイクル 約8ヶ月間の準備期間 • テーマの必要性検討 • 人員の確保 ◦ 各部署との調整 ◦
興味とテーマのマッチング
#RAKUSMeetup 技術推進プロジェクトの様子~上期の例 • 4~5月 ◦ 顔合わせ ◦ テーマについて調査 • 6月
◦ 検証詳細を計画 ◦ 検証環境の構築 • 7~8月 ◦ 検証実施 ◦ 成果発表準備 • 9月 ◦ 成果発表 • 人員 ◦ テーマごとに2~3人 ▪ リーダー1人 • ベテランエンジニア ▪ メンバー1~2人 • 3年目以降くらい • 時間、期間 ◦ 週5時間 ◦ 半期もしくは通年 ▪ 3人 = 約2人月/半期 • 実施 ◦ チームごとに実施日を設定 ◦ 実施日に集まって検証
#RAKUSMeetup 技術推進プロジェクトでの検証成果 各テーマの検証成果は開発組織内に共有。 要否の判断も期待しているので • 導入したいもの • 導入の必要がないもの の両方とも出てくる。それもまた取り組みの成果。
#RAKUSMeetup 検証成果はできる限り公開 あまり社内ではアピールしてないけど ”openess” に従って 検証成果はできるだけ公開。 国内Webサービス発展の 一助となれば。 https://tech-blog.rakus.co.jp/
#RAKUSMeetup 本取り組み自体もオープンに テックブログでも記事にしていますが、今日話した仕組みについても オープンにしてます。 同じ悩みをもつ企業様で取り込む際の参考にしてもらえれば。 (その成果もオープンにしてもらえると嬉しい……) https://tech-blog.rakus.co.jp/entry/20211216/gisui
#RAKUSMeetup こういった取り組みの注意点 開発組織全体の位置付けとしてはサービスの「技術刷新の促進」 サービスに反映されるまでは3~4年くらいかかります。 • 大きな仕組み変更は年単位で計画している • そもそも3年先の課題感を見越している 確信持ってじっくりやるのが大事 ※「認証基盤」の話は珍しい例
#RAKUSMeetup ラクスでは…… 長寿サービスを衰退させないために 3年 以上 前から先手を打って 陳腐化を防ごうとしています。 というお話でした。
#RAKUSMeetup Thank you for your watching. 🙂