© DMM.com 新卒研修２週間で一つのWebサービスをチー ムで作り切った話 合同会社DMM.com マーケティング・テクノロジー部 CRMグループ 濱田 翔馬 

© DMM.com 自己紹介 名前：濱田翔馬（2021年新卒） 所属：マーケティング・テクノロジー部 CRMグルー 　　　 プ 領域：フロントエンドその他（最近は主にバックエ　　　ンド・ インフラを触っています） 趣味：創作活動・開発・お酒 

© DMM.com 今回の目的 ● 話すこと ○ Webサービスに関して ○ フロントエンド領域での工夫 ○ 短期間で作り切るために何をしたか ● 話さないこと ○ 新卒研修の詳細 ○ バックエンド・インフラなど今回の趣旨から外れ る技術の詳細 

© DMM.com チームで開発したサービス 4 栄養バランスの取れたメニュー（献立）から好きなものを選び、 実際に作った料理を記録していくことで成長を実感する、 自炊支援サービス 

© DMM.com チームで開発したサービス 5 5 ECサイトの機能も持ち合わせたWebサービス 

© DMM.com 使用した技術 6 6 

© DMM.com 使用した技術 7 7 linaria ● CSS in JSのライブラリ ● ビルド時にJSファイルからCSSを解析して CSSファイルとして書き出してくれる ● styleの解析にかかる時間が削減できるの でパフォーマンス ⭕ vite ● HMR（Hot Module Replacement）など、 ネイティブのESモジュールに対して豊富な 機能拡張を提供するビルドツール ● Rollupで高速バンドル ● Vue での使用例が目につくが、ちゃんと React でも使える！！ 

© DMM.com 使用した技術 8 8 linaria ● CSS in JSのライブラリ ● ビルド時にJSファイルからCSSを解析して CSSファイルとして書き出してくれる ● styleの解析にかかる時間が削減できるの でパフォーマンス ○ vite ● HMR（Hot Module Replacement）など、 ネイティブのESモジュールに対して豊富な 機能拡張を提供するビルドツール ● Rollupで高速バンドル ● Vue での使用例が目につくが、ちゃんと React でも使える！！ 

© DMM.com 使用した技術 9 9 lint-staged & pretty-quick の導入により、メンバーの開発環境に依存しないコード品質の 維持 

© DMM.com 使用した技術 10 10 色を一つの変数で管理し、グローバル変数に展開して各 コンポーネントから呼び出すように整備 ● 各コンポーネントで使用する 色 を統一的に管理できる ● Figmaから色を抽出する手間 がなくなる 

© DMM.com 今回行った開発の流れ 11 11 1. サービス企画 2. ワイヤーフレームの作成 3. 必要機能の抽出＆着手の優先順位付け 4. プロジェクトの環境構築＆準備（フロント＆バックエンド＆デザイン） 5. デザイン作成 6. 必要機能の再抽出＆やる・やらないの決定 7. デイリースクラムで進捗のボトルネックを再整理し、潰す一手を打つ 8. 7を繰り返し、完成を目指す 

© DMM.com 課題点 12 12 下記の課題点を、プロジェクト初期に想定して対処しました ● チームメンバーの役割が不明瞭になる恐れ ● チームメンバーの得意な技術領域にばらつきがあった ● デザイナーとエンジニアの意思共有が難しい 

© DMM.com 課題点 13 13 ● チームメンバーの役割が不明瞭になる恐れ ● チームメンバーの得意な技術領域にばらつきがあった ● デザイナーとエンジニアの意思共有が難しい 

© DMM.com 課題点 14 14 ● チームメンバーの役割が不明瞭になる恐れ ⇒ 重複した作業、意見の衝突が発生するおそれ ⇒ 出戻りによるスケジュール超過 ⇒ 未完成 

© DMM.com 課題点 15 15 ● チームメンバーの役割が不明瞭になる恐れ 意思決定権のレイヤーを分割して解決（以下は、実際に行ったチーム体制） ● プロダクトオーナー：Aさん（エンジニア） ● スクラムマスター：Bさん（エンジニア） ● フロントエンド：Cさん（エンジニア） ● バックエンド＆インフラ：Dさん（エンジニア） ● デザイン：Eさん（デザイナー） 

© DMM.com 課題点 16 16 ● チームメンバーの役割が不明瞭になる恐れ ● チームメンバーの得意な技術領域にばらつきがあった ● デザイナーとエンジニアの意思共有が難しい 

© DMM.com 課題点 17 17 ● チームメンバーの得意な技術領域にばらつきがあった ⇒ 開発に必要な画面数が多く、フロントエンドの比重が大きい ⇒ フロントエンドへの重点的な開発リソースの投下が必要 ⇒ メンバーのフロントエンドへの理解力に偏り があった 

© DMM.com 課題点 18 18 ● チームメンバーの得意な技術領域にばらつきがあった CSSのBEM（Block Element Modifier）記法をコード規約として設定し、 その勉強会を開いて対応。主に、以下の形式でチームの共通認識を作りました ● Block：要素のレイアウトを行う ● Element：要素自体のデザイン ● Modifier：要素にあるデザイン差分の追加 

© DMM.com 課題点 19 19 ● チームメンバーの得意な技術領域にばらつきがあった ● チームメンバーの役割が不明瞭になる恐れ ● デザイナーとエンジニアの意思共有が難しい 

© DMM.com 課題点 20 20 ● デザイナーとエンジニアの意思共有が難しい ⇒ デザイナーが仕上げたデザインと実装の実現性の間に齟齬 が生まれる ⇒ 一部デザインの修正作業の発生 ⇒ 出戻りにより、期間内に完成しない 

© DMM.com 課題点 21 21 ● デザイナーとエンジニアの意思共有が難しい プロダクトオーナーがデザインの助っ人 として参加する ● 2倍の進捗になるため、開発メンバーにスムーズなタスク割り振りが可能 ● デザイナーとデザインでコミュニケーションすることで、 POの目指すゴールを伝えやすくする ● エンジニアの観点から、出戻りの発生しにくい（開発しやすい）デザインの提案 が可能 

© DMM.com 課題点 22 22 下記の課題点を、プロジェクト初期に想定して対処しました ● チームメンバーの役割が不明瞭になる恐れ ● チームメンバーの得意な技術領域にばらつきがあった ● デザイナーとエンジニアの意思共有が難しい 

© DMM.com まとめ 23 23 ● ワイヤーフレームの作成段階で、メンバー一人一人が納得するものを作り 上げられた点が大きい ● 開発のゴールをメンバー全員が明確に持てたからこそ、出戻りを一切出さ ずに開発しきることができたといえます