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 Init...
Search
moomoo-ya
June 01, 2022
Technology
0
1.2k
サービスを陳腐化させない組織だった技術刷新 / 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
92
一番安い子だーれだ?~黒字化のための無慈悲なタスク配分~ / Distribute tasks
moomooya
1
2.9k
はじめてのオンラインイベント配信 with COVID-19 バグあり版 / Online-Event-includes-bug
moomooya
0
790
やはり俺のLT登壇はまちがっている。 / my-lightning-talk-is-wrong-as-i-expected
moomooya
4
2.1k
Gatsby.jsで.md/.adocが混在できるテンプレートを作ったときの苦しみ / Pain-to-create-gatsby-template-that-supports-markdown-and-asciidoc
moomooya
0
570
LADRのすすめ&先行技術検証PRJの紹介 / Introducing-LADR-and-Technology-verification
moomooya
5
2.3k
技術書へのアクセスを劇的に向上させた話 / oreilly-safari-and-acm-membership
moomooya
2
7.3k
モノリスにおけるビジネスロジックの設計 ~アグリゲートパターン~ / aggregate-pattern-for-domain-modeling-on-monolithic
moomooya
2
1.4k
オブジェクト指向を学んでから20年間でモヤったこと / Object-Oriented-groomy-in-20-years
moomooya
0
480
Other Decks in Technology
See All in Technology
Power BI は、レポート テーマにこだわろう!テーマのティア表付き
ohata_ds
0
140
ゆもつよがこの30年間自ら経験してきたQA、テストの歴史と未来
ymty
3
630
アジャイル開発とスクラム
araihara
0
130
Kubernetesでメールの大量配信をしている話/k8sjp-20250205
hfukamachi
0
320
パブリッククラウドのプロダクトマネジメントとアーキテクト
tagomoris
4
960
Googleマップ/Earthが一般化した 地図タイルのイマ
mapconcierge4agu
1
180
まだ間に合う! エンジニアのための生成AIアプリ開発入門 on AWS
minorun365
PRO
4
500
Larkご案内資料
customercloud
PRO
0
280
依存関係があるコンポーネントは Barrel ファイルでまとめよう
azukiazusa1
3
470
生成AIの利活用を加速させるための取り組み「prAIrie-dog」/ Shibuya_AI_1
visional_engineering_and_design
1
130
デザインから逆算して難易度を見積もるための観点
fumiyasac0921
0
110
ろう・難聴者のコミュニケーションを円滑化する取り組み
chiemi627
0
120
Featured
See All Featured
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
27
1.9k
jQuery: Nuts, Bolts and Bling
dougneiner
63
7.6k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
44
7k
A Modern Web Designer's Workflow
chriscoyier
693
190k
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
193
16k
Statistics for Hackers
jakevdp
797
220k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
666
120k
Optimizing for Happiness
mojombo
376
70k
StorybookのUI Testing Handbookを読んだ
zakiyama
28
5.5k
Facilitating Awesome Meetings
lara
51
6.2k
Six Lessons from altMBA
skipperchong
27
3.6k
Code Reviewing Like a Champion
maltzj
521
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. 🙂