これからの「フロントエンド開発」の話

〜（デザイナー所属の）フロントエンドエンジニアでも知っておきたいこと〜

2016.07.23@UI Live ! in Kanazawa

自己紹介

● DMM.comラボ 2012年入社

○ システム本部 PF開発部

○ 第２グループ（会員基盤）

■ フロントエンドチームリーダー

■ 去年までどっぷりバックエンド担当

○ 身長186cm、バレー部、OK？

今日のお話は「開発のフロー」についてです。

お話の留意事項

1. エンジニア→デザイナー目線

● 特にコーダーからフロントエンドエンジニアに成り上がった方● 特に弊社のように、分業のレベルが激しい

● 開発フローの細かい話はしない予定● エンジニアの方には退屈かも、ごめんなさい

2. Not 深い話, But ふんわりとした話

● 最近の開発〜リリースまでの流れを把握しておけば　　開発フローも洗練され、いいサービスをより早く作れるのでは？

3. TL;DR

目次

1. お話のきっかけ

2. 最近耳にするxxx

3. 開発フロー全体の話

4. 各フローの補足説明

5. まとめ

ことの始まり

社内での気付きから...

● 社内向けUXセミナーでストーリーボードを見て衝撃

○ 全体を俯瞰してどう作るかわかりやすい！！！

● デザイナーの中でも自主的にgitが広まる

○ これはきっともっとわかりあえるぞ！！！

（この流れ）だから、このUIなのか！

もしかしたら...

● 開発フロー全体を知れば気づきがあるかもしれない！

○ ポイントだけ伝えても、きっと伝わっていない

○ git便利！じゃなくて、全体を踏まえた役割を知る

よく目にするxxx

おそらくよく目にしているxxx

● gitだ！githubだ！

● CIやりたい！Jenkinsだ！CircleCIだ！

● Dockerだ！Docker使いたい！

● ChatOpsでやってます！

● Ansibleで構成管理やってます！

おそらくよく目にしているxxx

● gitだ！githubだ！

● CIやりたい！Jenkinsだ！CircleCIだ！

● Dockerだ！Docker使いたい！

● ChatOpsでやってます！

● Ansibleで構成管理やってます！

決して難しいことをしたい訳ではない

やりたいことはいたって単純

変更 変更検証NG

すぐ修正

検証OK 変更

やりたいこと

変更 変更 変更検証NG

バグ大量

やりたくないこと

たとえばの話

カセットゲームを作るなら...

納品まとめ

動作検証

開発

在庫営業部隊お店B

お店C

お店A

開発を進める

開発

納品まとめ

動作検証

在庫営業部隊お店B

お店C

お店A

成果物としてまとめる

納品まとめ

動作検証

開発

在庫営業部隊お店B

お店C

お店A

その段階で問題なく動作するか検証

納品まとめ

動作検証

開発

在庫営業部隊お店B

お店C

お店A

最終的に販売パッケージ化を指示

納品まとめ

動作検証

開発

在庫営業部隊お店B

お店C

お店A

パッケージ化が済んだら在庫に保管

納品まとめ

動作検証

開発

在庫営業部隊お店B

お店C

お店A

パッケージ化が済み次第、販売を指示

納品まとめ

動作検証

開発

在庫営業部隊お店B

お店C

お店A

各店舗へ販売開始を伝達

納品まとめ

動作検証

開発

在庫営業部隊お店B

お店C

お店A

パッケージ化された製品を入荷

納品まとめ

動作検証

開発

在庫営業部隊お店B

お店C

お店A

あまり想像に難くない流れでは？

納品まとめ

動作検証

開発

在庫営業部隊お店B

お店C

お店A

先ほどの言葉を当てはめるなると...

納品まとめ

動作検証

開発

在庫営業部隊お店B

お店C

お店A

各フローの連携について

①開発ととりまとめの流れ

納品まとめ

動作検証

開発

在庫営業部隊お店B

お店C

お店A

cording&fix <-> git <-> github/stash

git

git

git

変更A

変更B

変更C

変更D

変更E

PUSH！

PUSH！COMMIT！　COMMIT！

PUSH！

git, githubを選ぶ理由

● cordingやfix作業において...

○ 各自だけの変更を記録可能

○ 変更を取込みやすい

○ 変更取込みを申請できる(PR)

②とりまとめからの検証の流れ

納品まとめ

動作検証

開発

在庫営業部隊お店B

お店C

お店A

github/stash <-> CI(Jenkins...etc.)

更新キタヨ！

githubやCIツールを選ぶ理由

● 検証を自動化するにあたり...

○ CIツールと連携しやすい

○ 変更を自動で検知して検証開始

③検証結果に応じて指示する流れ

納品まとめ

動作検証

開発

在庫営業部隊お店B

お店C

お店A

CI <-> ChatOps

OK！NG！

ChatOps <-> CI <-> Docker

保管して！パッケージして！

ChatOps <-> Ansible

server

server

server

展開！

各サーバへ展開して！

ChatOpsを選ぶ理由

● 作業を半自動化（指示を出すだけ）

○ 通知のプラグインが豊富

○ 作業指示のログがきっちり残る

○ いわゆるbotにお任せできる※手順がコードで管理されているため

知っておきたいポイント

特に知っておきたいポイント

● git

○ すでに浸透しつつある？

● Docker

○ ローカル開発環境として布教中...

● 継続的インテグレーションの流れ

まとめ

まとまらないまとめ

ただ個別にツールを使うだけではなく

開発フロー全体を俯瞰したほうが良い

開発からリリースまでの「流れ」を

　　　知っておく方がプラスになるはず

よりよいUIのために自分たちの開発フローにも目を向けてみませんか？