長期運用サービス改善のために構築した開発環境の話
koyano氏：それでは始めさせていただきたいと思います。よろしくお願いします。
（会場拍手）
「長期運用サービス改善のために構築した開発環境の話」をさせていただきたいと思います。
まず自己紹介させていただきます。koyanoと申します。
DMM.comにて動画配信事業部で働いているフロントエンドエンジニアです。普段は「DMM動画」というサービスでView周りのコーディングやサイト改善などを担当しています。
今日は、以前、弊社のブログ「DMM inside」に投稿した記事をもとに、長期運用サービス改善のために作ったフローやツールや開発環境のお話をさせていただきたいと思います。
アジェンダはこんな感じでいきたいと思います。
まずは問題とアプローチについてお話しします。最初にサービスについてです。みなさんDMM動画知っていますか？ 使っているという方いたらぜひ手を挙げていただけるとうれしいです。
（会場拍手）
ありがとうございます。DMM動画ですが、実はDMMができた最初からあるサービスです。なので、20年も運用されています。
ということは、それなりに技術的な負債が溜まっています。長期運用中のサービスにありがちな、ガイドラインの崩壊したデザインやコードだったり、影響範囲がわからないCSSやJSだったりと、リリースを優先するあまり後回しにしてきた結果、蓄積された問題です。
この問題が積み重なると、実装や影響範囲の確認などに時間が取られるようになり、結果、工数がかさんでいきます。今回はこの問題を解決することを目標にしています。
問題解決へのアプローチ方法です。
サービスの規模的にリニューアルは難しい状態です。なので、今回は既存のものはそのままにして、小さなブロック単位の修正・置き換えを繰り返していって、やがて全部置き換えようということを目指していきます。
フレームワークはVue.jsを使って、カスタムコンポーネントでスタイルもカプセル化していきます。Vue.jsを選択した理由は、jQueryが使えるデザイナーにReactやVue.jsのチュートリアルを試してもらったところ、デザイナーでも使えるぐらい学習コストが低くてサクサクコードが書けたことから、Vue.jsを選択しました。
今回の改善で目標にしたいことです。
最適化したスタイルガイドの作成、それをサービスへ適用すること。デザインデータやHtml/Javascript/Styleを管理しやすい状態、コンポーネント化などをして、資産化を目指していきます。まとめると、すばやくサービスを改善できるような状態にしたいということです。
ちょっと前置きが長くなってしまいましたが、ここから実際にどのような作業をしているのか、どんなツールを使っているのかをお話ししたいと思います。
デザインの開発の流れ
まずデザイン側の開発の流れです。
最初に行ったのがUIインベントリというものです。これはサービスのデザインがどんな状態になっているかを把握するために、複数人でサービスのスクリーンショットを撮り集めて、パーツ単位に分解・分類していく作業です。その結果をもとに整理しスタイルガイドの作成を行いました。
スタイルガイドができたあとは、対象のページとブロックを決めて、スタイルガイドの適用や、必要に応じてUIの見直し、データの作成を実施しています。
今回のフローで使っているツールやサービスです。コミュニケーションツールはSlack、デザインツールはSketchです。
そしてデザインサービスの「Figma」というサービスを使っています。
弊社は開発拠点が石川と東京にありまして、遠隔でコミュニケーションを取りながら作業をすることが多いです。そこで使用するのが、Slackのビデオチャットと、リアルタイムで共同作業ができるFigmaです。
ちなみにFigmaを使っていらっしゃる方はいらっしゃいます？
（会場挙手）
けっこういますね。ありがとうございます。実際にUIインベントリとスタイルガイドの作成はFigma上で行いました。全体としてこんな感じで整理していくという感じです。
オンライン上で共同で作業できるので、Slackで会話をしながら一斉に編集していきます。非常にスピード感を持って作業できます。画像を見ながらしゃべるので細かなニュアンスなども伝えやすいです。
シンボル化やコメント追加など、UIデザインツールとして必要な機能が備わっているので、わりと不自由なく作業ができています。
とくにプロトタイピングが便利でして。
実際新しいUIを試すときは、サクッと作って、URLを発行して、自分のスマホで確認作業を行なっています。
フロントエンドの開発フロー
次にフロントエンドの開発フローになります。実はFigma上での作業は、デザイナーだけでなく、フロントエンドエンジニアも参加しています。なので、デザインがある程度見えた段階から作業に入ってしまいます。
だいたいのデザインをもとにどのように分解してコンポーネントにしていくのかを話し合い、コンポーネント作成、できたらビルド、実ページに組み込むという作業になります。
パーツの製作や管理には、Storybook for Vueを使用しています。
Storybookは登録したコンポーネントを表示したりテストしたりできるUI開発環境です。機能追加も可能でして、ネット上には色々なアドオンが公開されています。弊社では公式が出しているKnobというアドオンを使っています。
Storybookは、静的ファイルも出力できるので、プルリクエストやマージのタイミングでCircleCIを使ってAWS上にアップして、いつでもブラウザで確認できるようにしています。
パーツカタログという使い方だけでなく、開発環境として使っています。色々な使い方ができるので、デザイナーはデザインやインタラクションを確認、サーバサイドはコンポーネントへ渡すデータの確認といった感じで使っています。
コンポーネントはAtomic Designをベースにした粒度とカテゴリで管理しています。
ただ、アトミックデザインを厳格に守ろうとすると、製作者間の認識の違いで非常に悩むことがよくあります。なので、すごく簡単にルールを決めて、すぐに粒度を変えられるようにしています。
粒度の中にカテゴリを切って、その中にコンポーネントフォルダを置くかたちで管理しています。
実際に新規でコンポーネントを作るときには、すぐ作り始められるように、コマンドを叩くと、粒度を選んで、その中にあるカテゴリを選んで、コンポーネント名を入れると、必要なテンプレートが該当の箇所に出力されるようなスクリプトを使っています。
このような感じでファイルが生成されます。
生成されたあとは、まずドキュメントを書きます。次にstories.jsファイルにアドオンのKnobが動くように設定を記載、vueファイルにコンポーネントを作成します。spec.jsファイルにテストを記録という流れで作成します。コンポーネント製作者が必要なものを一通り作れる流れにしています。
一応、EditorConfig、ESLint、Stylelintでそれなりに縛っています。
コンポーネントの使い方です。
基本的に作ったコンポーネントをビルドして、読み込みたいページで読み込み、該当のブロックに反映するといった、簡単な使い方をしています。現時点では本当にパーツライブラリ的な使い方です。
現在の目標に対する到達度です。
正直まだまだぜんぜん達成できていない状態です。引き続きがんばっていきたいです。
開発環境を作って変わったこと
ただ、環境を作って変わったこともちょっとありました。
まずカプセル化によって、想定外の影響がサービスに出にくい状態になったので、非常にのびのびとコーディングができる環境になりました。
次に、コンポーネントを作れば作るほど再利用可能なパーツが増えていくので、生産性が上がってきました。最後にもう1つ、これが一番うれしかったのですが、パーツの作り方やルールができたので、デザイナーが自分でコンポーネント作りたい・編集したいという意見が出てくるようになりました。
まとめです。ざっくりサービス改善に向けて作ったフローや環境のお話をさせていただきました。この環境は運用を始めてだいたい半年ぐらい経ちましたが、実は当初作ったものからかなり変わっています。
結局のところ、目的達成に向かって、最善ならばルールを変えていくというスタンスで運用するのが大事なのかなと思っています。もちろん運用のルールは大事なんですが、ルールを守ることが目的とならないように気をつけています。
開発環境というよりはフローのお話になってしまいましたが、みなさまのご参考になれば幸いです。今日登壇した内容はこちらのブログに書いた内容をもとにしています。もしよろしければご覧ください。ご清聴ありがとうございました。
（会場拍手）
