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
530
P3インスタンスではじめるDeep Learningと画像レコメンド
dmmlabo
2
3.3k
DMM.comのサービス開発におけるGitHub Enterprise活用の舞台裏
dmmlabo
2
980
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
今ならAmazon ECSのサービス間通信をどう選ぶか / Selection of ECS Interservice Communication 2025
tkikuc
21
3.8k
WebViewの現在地 - SwiftUI時代のWebKit - / The Current State Of WebView
marcy731
0
110
「Cursor/Devin全社導入の理想と現実」のその後
saitoryc
0
690
Cursor AI Agentと伴走する アプリケーションの高速リプレイス
daisuketakeda
1
130
スタートアップの急成長を支えるプラットフォームエンジニアリングと組織戦略
sutochin26
0
330
Node-RED を(HTTP で)つなげる MCP サーバーを作ってみた
highu
0
120
Systèmes distribués, pour le meilleur et pour le pire - BreizhCamp 2025 - Conférence
slecache
0
120
LT 2025-06-30: プロダクトエンジニアの役割
yamamotok
0
670
ニーリーにおけるプロダクトエンジニア
nealle
0
730
Result型で“失敗”を型にするPHPコードの書き方
kajitack
5
570
XP, Testing and ninja testing
m_seki
3
220
datadog dash 2025 LLM observability for reliability and stability
ivry_presentationmaterials
0
440
Featured
See All Featured
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
The Web Performance Landscape in 2024 [PerfNow 2024]
tammyeverts
8
680
Measuring & Analyzing Core Web Vitals
bluesmoon
7
500
Bootstrapping a Software Product
garrettdimon
PRO
307
110k
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.5k
GraphQLの誤解/rethinking-graphql
sonatard
71
11k
Rails Girls Zürich Keynote
gr2m
94
14k
Large-scale JavaScript Application Architecture
addyosmani
512
110k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
31
1.3k
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
Building a Scalable Design System with Sketch
lauravandoore
462
33k
Facilitating Awesome Meetings
lara
54
6.4k
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. ͍͞͝ʹ
͍͞͝ʹ 技術選定とは • Ϗδωεཁ݅Λຬ্ͨͨ͠Ͱɺ • ݱࡏͷϦεΫͱϦιʔεΛߟ͑ͯɺ • ྑ͖όϦϡʔΛಘΔ͜ͱ という考え⽅で⼀定の成果が出たと思っています。
όϦϡʔ͕มΘΕબఆมΘΔ 今回はԿͰ͍͍ͷͰϑϨʔϜϫʔΫͷݟΛೖ ख͢Δということをバリューに設定していますが、 ノウハウの貯蓄具合によってはとうぜんόϦϡʔ ࣗମ͕มΘͬͯ͘Δと思います。 ϦιʔεɺϦεΫɺόϦϡʔを考え、最適な技術 選択する事をこれからも⼼がけたいと思います!
͝ਗ਼ௌ͋Γ͕ͱ͏͍͟͝·ͨ͠ɻ