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
DMM CM AWAEDS におけるフロントエンド技術選定について
Search
DMM.com
September 15, 2017
Programming
1
1.4k
DMM CM AWAEDS におけるフロントエンド技術選定について
17年8月22日に開催しました#DMMmeetup DMMフロントエンド開発最前線で発表した際の資料です
DMM.com
September 15, 2017
Tweet
Share
More Decks by DMM.com
See All by DMM.com
Neo4j with Spark for Big Data Analysis
dmmlabo
1
540
P3インスタンスではじめるDeep Learningと画像レコメンド
dmmlabo
2
3.3k
DMM.comのサービス開発におけるGitHub Enterprise活用の舞台裏
dmmlabo
2
1k
Digdagを導入してみて
dmmlabo
9
4.1k
DMM.comラボにおける Scality Ring 活⽤事例
dmmlabo
0
1.1k
デジタルコンテンツの安定配信とコスト削減の両立を実現したシステム刷新
dmmlabo
1
2.6k
エンジニアのパフォーマンス・モチベーション管理
dmmlabo
1
1.4k
DMMに於ける技術導入はじめの一歩
dmmlabo
1
1.3k
AWSエンジニアがオンプレミスと対峙するとき
dmmlabo
2
5.6k
Other Decks in Programming
See All in Programming
Understanding Ruby Grammar Through Conflicts
yui_knk
1
120
decksh - a little language for decks
ajstarks
4
21k
State of CSS 2025
benjaminkott
1
120
学習を成果に繋げるための個人開発の考え方 〜 「学習のための個人開発」のすすめ / personal project for leaning
panda_program
1
110
コンテキストエンジニアリング Cursor編
kinopeee
1
700
Langfuseと歩む生成AI活用推進
licux
3
300
DockerからECSへ 〜 AWSの海に出る前に知っておきたいこと 〜
ota1022
5
1.8k
20250808_AIAgent勉強会_ClaudeCodeデータ分析の実運用〜競馬を題材に回収率100%の先を目指すメソッドとは〜
kkakeru
0
200
開発チーム・開発組織の設計改善スキルの向上
masuda220
PRO
13
7.6k
STUNMESH-go: Wireguard NAT穿隧工具的源起與介紹
tjjh89017
0
380
ワープロって実は計算機で
pepepper
2
1.4k
CSC305 Summer Lecture 04
javiergs
PRO
1
110
Featured
See All Featured
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
50
5.5k
Fireside Chat
paigeccino
39
3.6k
Music & Morning Musume
bryan
46
6.7k
Product Roadmaps are Hard
iamctodd
PRO
54
11k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
126
53k
Speed Design
sergeychernyshev
32
1.1k
Facilitating Awesome Meetings
lara
55
6.5k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
10
1k
Docker and Python
trallard
45
3.5k
Navigating Team Friction
lara
189
15k
Testing 201, or: Great Expectations
jmmastey
45
7.6k
The Myth of the Modular Monolith - Day 2 Keynote - Rails World 2024
eileencodes
26
3k
Transcript
ʹ͓͚Δ ϑϩϯτΤϯυٕज़બఆʹ͍ͭͯ リソース、リスク、バリューから考える技術選定 DMM.comラボ デザイン本部 フロントエンド開発部 新規・流動チーム リードエンジニア 清宮 洋徳
ΞδΣϯμ
1. ⾃⼰紹介 2. プロジェクト背景 3. 技術選定とは? 4. 今回の技術選定 5. さいごに
1. ࣗݾհ
ਗ਼ٶ ༸ಙ LJZPNJZB Webサイトに携わり約20年。 Webに関することに⼀通り⾜ をつっこみ、2016年に DMM.com ラボへ参加。
৽ن/ྲྀಈνʔϜ σβΠϯຊ෦ ϑϩϯτΤϯυ ։ൃ෦ に所属 (not sys!) ৽نࣄۀのサイト構築に携わ ることが⽐較的多い。 ৽ن
/ ྲྀಈ ৽ ৽ ৽
2. ϓϩδΣΫτഎܠ
%..DPN৽نࣄۀ͕ଟ͍ձࣾ ここ⼀年を振り返ってみても、 多くのサービスサイトが⽴ち上がっている
ͦΜͳզʑͷνʔϜʹ ৽ͨͳϓϩδΣΫτͷґཔ͕ʂ
None
$.Ξϫʔυͱʁ DMMの各サービスを応援 する$.ಈըίϯςετ 最優秀賞はສԁ! ୈೋճ։࠵த!
たくさんデータあるけど 全部API叩けばいいから! $.Ξϫʔυͷϑϩϯτ։ൃཁ݅ 状態管理 ルーティング HistoryAPI 通信処理
੩తHTMLͰϦϦʔεͩʂ
͍··ͰͷϫʔΫελΠϧ HTML作成 php組み込み いままで • 異なる部署の成果物がີ݁߹ • クリティカルパスが存在 デザイン本部 システム本部
$.Ξϫʔυͷ։ൃ͜͏ͳΔ HTML作成 API作成 CMAWD • 異なる部署の成果物はૄ݁߹に! • クリティカルパスからの開放! デザイン本部 システム本部
͔͠͠ɺ͕͢͞ʹϑϨʔϜϫʔΫ ಋೖΛݕ౼͢Δ͖Ͱʁ
ಋೖ͍ͨ͠ཧ༝ • 投稿フォーム → 確認画⾯でデータを保持しておく • URLにより、APIに対して投げる値が変わる • モーダルを開いたときにURLを変えたい •
検索やページングなどの機能をフロントで実装 APIに投げるデータをたくさん保持しつつ、 データに応じて⾒た⽬とURLが変わる(逆も)
͍Ζ͍Ζ͋Δ͚ͲɺͲΕΛબͿʁ 何を拠り所として選んだらいいんだろう・・・? React Vue RIOT Angular BACK BONE
3. ٕज़બఆͱʁ
ٕज़બఆͱͳΜͩΖ͏͔
·ͣͪΖΜཁٻΛຬͨ͢͜ͱ いくら良い技術を使ったところで、 要求を満たせなくては意味がない。
ϦιʔεͱϦεΫͷఱṝ リソースには限りがある… 限られたリソースだから、 リスクはしっかり考えないと。
ϦιʔεͱϦεΫͷఱṝ リソースよりリスクが上回るとେมͳ͜ͱに いつ終わるかわからない、ϦϦʔεԆ ΫΦϦςΟなアウトプット 結果的にେͳίετ ਓʹґଘ͠ɺ͔ͭߴίετͳӡ༻ମ࣭
ϦιʔεͱϦεΫͷఱṝ つまり ϑϨʔϜϫʔΫಋೖʹؔͯ͠ͷఆϦεΫ ίετΛ͑ͳ͍ように設計する。
ͱ͍͑ৡΕͳ͍ͷ͕͋Δ ただ、リスク回避に主眼を置きすぎると jQuery͍͍͑Μ͡Όͳ͍ʁ ってなりがち。
ͦ͏͡Όͳ͍ɻ όϦϡʔ͕ඞཁͩɻ
όϦϡʔͱʁ 「తͷୡ」ではなく 「͞ΒͳΔՃՁ」であり、 ϊϋとなるもの。
ϊϋʹ͍ͭͯ ⾼い⼭でも 0からスタートするのと、 五合⽬からスタートするのでは かかるリスクが異なります。 この「五合⽬スタート」がノウハウです。
ࠓճ jQuery Λͬͯ ϊϋͨ·Βͳ͍ɻ
όϦϡʔͷઃఆ つまり ࠓճҎ߱ɺޒ߹͔ΒελʔτͰ͖ΔΑ͏ʹɺ खʹೖΕΔՃՁΛ͋Β͔͡Ίઃఆしておく。 何かしら学ぶことが重要。
ͪͳΈʹ ⼭はどんどん⾼くします。 でも開始位置も少しずつあがっていきます。 このΰʔϧͱܦݧͷํΛੵΈॏͶߴΊͯ ͍͘͜ͱが重要です。
ͭ·Γ
ٕज़બఆͱ • ϏδωεతཁٻΛຬͨ͢ • Ϧιʔε > ϦεΫ • όϦϡʔ >
ϊϋͷऔಘ
4. ࠓճͷٕज़બఆ
Ϗδωεతཁٻ 今回のケースでは • API連携が⼗分にできればよく、軽いもの (ϑϧελοΫෆཁʣ • ページ遷移時にデータを取り回せる • サーバーを持たない(SSRෆཁʣ •
࡞Γ͖ΓલఏͷͨΊɺӡ༻ੑॏࢹ͠ͳ͍
Ϧιʔεͱ੍ ぼくひとり。 2.5ヶ⽉程度の開発期間(not⼯数)を確保。 納期はマスト。 →͙͢ʹखΛ͚ΒΕɺࢿྉ͕ଟ͍ͱྑ͍
όϦϡʔ 何らかのクライアントサイドフレームワーク を導⼊し、知⾒を得ること。 →ࠓޙʹͭͳ͕Δ͜ͱΛߟ͑ΔͱɺͳΔ͘ ϝδϟʔͳͷ͕ྑ͍
ϏδωεཁٻΛຬٕͨ͢ज़ʹର͠ɺ ϦιʔεͱόϦϡʔ͔Β ϦεΫΛݕ౼͢Δ
ࢢௐࠪ 規模感と機能⾯の双⽅から、 いくつかのメジャーなアーキテクチャを 選定対象にしました。 React Vue RIOT
ϦεΫݕ౼ͷ؍ 選定対象のいずれも、要求を満たしており、 バリューも⼗分だと判断。 あとはリスクの精査から決めれば良い。 • 学習の容易さ(リスク) • ミニマムスタート(リスク) • 部内の知⾒、チーム内の知⾒(リスク)
• 運⽤の容易さ(リスク)
特筆すべきポイント ES6およびJSXについて、チーム経験値が⼗分にない。 よって環境構築に若⼲のリスクがある。 資料とサンプルの豊富さは魅⼒。 Case: React React
Case: Vue.js 特筆すべきポイント RouterやValidator含め、⽇本語での⼀次資料が群を 抜いて豊富である点はすごかった。 また記述⽅法がReactよりもHTML的であり(今に なって思えばそこまでJSXは難しくなさそうだが)、 我々のバックグラウンドに馴染みやすかった。 Vue
Case: Riot.js 特筆すべきポイント 軽量であることが素晴らしい。Vue.jsと同じくReact よりもHTML的に記述できる。 ただし部内での実績がなく、詳しくリスクを把握で きなかった。 RIOT
ϦεΫ ES6かつJSXを使うという敷居の⾼さ →学習&構築コスト⾼くなりそうな気配? とくに⼤きいリスクなし? 部内に実績がなかったため、 調査コストがかかりそうだと判断 React Vue RIOT
݁ͱͯ͠ 特に⼤きいリスクが⾒当たらなかったので、 その分学習に時間を割くことができそうだった に決めました。 Vue
バージョン名がEvangelionで気に⼊った という理由もある。(モチベはどんな形でも⼤事) ※本プロジェクトの開発時はまだ1系でした
݁Ռ
݁ՌͲ͏ͳ͔ͬͨʁ • リソース範囲内で学習と構築を完了 • MVVMの知⾒もGET • チーム⼒アップ(いまはReactも扱っている) • 部内外を問わず社内へフィードバックできた •
システムさんと連携しつつ、別で開発ができた • CMアワードそのものが成功した!(第⼆回へ)
5. ͍͞͝ʹ
͍͞͝ʹ 技術選定とは • Ϗδωεཁ݅Λຬ্ͨͨ͠Ͱɺ • ݱࡏͷϦεΫͱϦιʔεΛߟ͑ͯɺ • ྑ͖όϦϡʔΛಘΔ͜ͱ という考え⽅で⼀定の成果が出たと思っています。
όϦϡʔ͕มΘΕબఆมΘΔ 今回はԿͰ͍͍ͷͰϑϨʔϜϫʔΫͷݟΛೖ ख͢Δということをバリューに設定していますが、 ノウハウの貯蓄具合によってはとうぜんόϦϡʔ ࣗମ͕มΘͬͯ͘Δと思います。 ϦιʔεɺϦεΫɺόϦϡʔを考え、最適な技術 選択する事をこれからも⼼がけたいと思います!
͝ਗ਼ௌ͋Γ͕ͱ͏͍͟͝·ͨ͠ɻ