DDD(大臣 Driven Development)のすゝめ
こんにちは!@HonMrakHuntです!
この記事はラクス Advent Calendar 2016の18日目の記事です。
昨日は@Black-Spiderさんのゲーム作り(C++&DxLib)を通してオブジェクト指向プログラミングを学ぶ方法(環境構築~画面の中で物が動くまででした!
明日は@iketomo1207さんの投稿予定です!
目次
- はじめに
- チームの悩み
- 解決策
- で。それ、いつ、誰がやるの?
- さぁ!DDD(大臣 Driven Development)だ!!
- DDD(大臣 Driven Development)
- 大臣 Driven Developmentとは?
- ルール
- DDDのワークフロー
- 大臣任命
- 問題を明文化する
- 大臣を任命する
- 大臣活動
- 頑張れ大臣!
- 報告だ!大臣!
- 大臣任命
- 2ヶ月やってみて
- なぜWorkするのか?
- 課題
- まとめ
はじめに
突然ですが、みなさんのチームは困っていますか?
僕は困っています。
今日はチームの悩みを解決する(かもしれない)、DDD(大臣 Driven Development)をご紹介します。
(ドメインの話は出て来ません。本当にすみません。)
チームの悩み
日々のチーム開発に悩みは尽きません。私の所属しているチームにも悩みがあります!
- あふれんばかり出て誰も手をつけなくなったのエラーログ。
- 放置されるお問い合わせ。
- 追いつけない外部APIのアップデート。
- etc...
チームの悩みはチームの数だけあります。
解決策
もちろん世の中にはそんな悩みを解決することができる方法や知見であふれています。 例えば、上にあげた
あふれんばかり出て誰も手をつけなくなったのエラーログ。
私のチームではエラーログが出ると、Slackのエラーログ部屋に通知が来ます。
日に1件や2件なら誰かが対応できますが、10件、20件、30件...エラーが多くなってくると出るのが当たり前になってめんどくさg誰も対応しなくなります(なりました)。
しかし、エラーログの監視、調査はElasticsearch
+ Kibana
などを使うことでとてもいい感じに素晴らしい感じにすることができます。
https://www.elastic.co/guide/en/kibana/current/discover.html
じゃあ早速Elasticsearch
を導入だぁー!
で。それ、いつ、誰がやるの?
で、それ。誰がやるんですかね?
最初のやる気は何処へやら、日々の忙しい業務に揉まれてElasticsearch
の導入は忘れ去られてしまいます。
最悪の場合、誰かが半年後に「エラーログの監視、調査はElasticsearch
+ Kibana
などを使うことでとてもいい感じに素晴らしい感じにすることができるんじゃない?」と、発言します。
...もちろんこれはエラーログだけの話ではありません。
チームの数だけ悩みはあり、チームの数だけ解決策があります。
さて、どうしたらいいでしょう?
さあ!DDD(大臣 Driven Development)だ!!
私のチームでは二ヶ月ほど前から、チームリーダーのnagaa052さんの発案で
DDD
- D : 大臣
- D : Driven
- D : Development
を導入しています!!!!
前置きが長くなりましたが、本日はこのようなチームの悩みに立ち向かう、大臣 Driven Developmentについてご紹介します!!
DDD(大臣 Driven Development)
大臣 Driven Developmentとは?
さて、大臣 Driven Developmentとはなんでしょう?自分で書いといてあれですが、名前落ち感がすごいですね。
大臣 Driven Developmentはチームの悩みに立ち向かうために生み出されました。
例えば私のチームの抱えていた悩みは、
* あふれんばかり出て誰も手をつけなくなったのアラート。 * 放置されるお問い合わせ。 * 追いつけない外部APIのアップデート。 * etc...
こんなのでした。
これを大臣 Driven Developmentで解決していきます。 いきますよ。
はい、DDD完了です。
そうです。大臣 Driven Developmentとは、
チームの悩みごとに大臣を任命し、大臣が責任を持って悩みと向き合う制度 です!
ルール
DDDのルールをご紹介します。
1. 大臣はあくまで責任者であり、担当ではない。
以上です。
このルールについては後述します。
DDDのワークフロー
私のチームで導入されているDDDのワークフロをご紹介します。
- 大臣任命
- 問題を明文化する
- 大臣を任命する
- 大臣活動
- 頑張れ大臣!
- さあ行け大臣!報告だ!
1. 大臣任命
まずは大臣を任命して行きましょう!
1.1 問題を明文化する
チームの問題・改題・悩みをあげていきます。
私のチームではスプリントの終わりごとに振り返りがあるので、KPTでProblemをあげて行きます。
1.2 大臣を任命する
問題(Problem)が見つかったら大臣を任命します!
私のチームではチームで技術定例を行なっています。その際に話あって大臣を決ました。 ひとまず自選他選問わず。ノリで決めました。
2. 大臣活動
大臣が決まったら活動して行きます!
2.1 頑張れ大臣!
任命された大臣が頑張ります!
余談ですが私はアラート大臣を任されています。日々飛んでくるアラートをissueにまとめてみたり、数を数えてみたり、そんな活動をしています。
ここで大切なのは、
- 大臣はあくまで責任者であり、担当ではない。
このルールです。アラートなんて見ても全くわからない時がほとんどです。見わからなければ誰かに相談してみます。 決して自分が全て解決しないといけないわけではありません。任命された問題に責任を持って活動すれば良いのです!
2.2 報告だ!大臣!
毎日の活動は夕会で報告します。
今日のアラート数やわからないことなどを報告します。大臣が活動していることがチームに浸透して行くと自然と周りも協力してくれるようになって来ました。
2ヶ月やってみて
以上で、なんとなく大臣 Driven Developmentがどんなものかわかっていただけたかと思います。
私のチームでは2ヶ月が経ちました。振り返りも兼ねてチームがどう変わったかを書いて行きます。
なぜWorkするのか?
ある者は生まれつき偉大、それ以外は強いられて偉大になる。 君にとって、これが偉大になるチャンスだ。
さて、困っていることに大臣を任命して活動するアホみたいな施策ですが、実は結構Workしています。
なぜWorkするのでしょうか?
我らがチームリーダーのnagaa052さんに教えてもらった言葉を紹介します。
「立場が人を作る。」
大臣に任命されると謎のやる気が出ます。
今更0からelasticserch学ぶことを決意。
— ホンマークハント (@HonMarkHunt) December 16, 2016
私もアラート大臣という立場に感化されて、気づいたらElasticsearch
学ぶ宣言をしていました。
この、立場によって生み出される責任感がDDDがワークする理由だと思います。
課題
始まって2ヶ月のDDDですが、課題もちらほら出てきています。最後に今後のために現状の課題をまとめておきます。
- 大臣の任期を決めていなかったので、終わりが見えない。交代制にする?
- 大臣の兼任はいくつまで?たくさん兼任すると大臣活動で忙殺されてしまう
この辺の改善は日々解決して行きたいです!
まとめ
チームにはチームの悩みの数だけ問題があると思います。
悩みを打ち破る手段はたくさんありますが、もしだれがやるのかが決まらなかったら。大臣にやってもらうのはいかがでしょうか?
最後までご覧いただき、誠にありがとうございました。
Frontrend Vol.8 - 帰ってきたフロントレンド 行ってきたメモ
はじめに
- Frontrend Vol.8 - 帰ってきたフロントレンドに参加してきました!
- ハッシュタグ #frontrend
- FRESH!にてライブ配信されていた模様です
- 1年半ぶりの開催とのことでしたが初参加させていただきました!
- ブログ絶対に書くマン枠にて参加させていただいたので、投稿させていただきます。
開会の挨拶
- frontrend久しぶりなのは社内のノウハウが枯渇しかけたから
- 充電満タン
- 1年くらいはfrontrendまた継続していきたい
発表アジェンダ
- Design Systems as a Product プロダクトとしてのデザイン・システムについて
- Lightning Talks
- Introduction to Resource Hints
- atomic designで助かった人たち
- 祭りから半年たったプロジェクトにジョインしてみた
- 最近のお仕事について
- アメブロフロント刷新にみる ひかりとつらみ
Design Systems as a Product プロダクトとしてのデザイン・システムについて
- 登壇者: @cssradar
デザイン・システムとは?
- デザインや技術に関わる事柄、ユーザが利用するプロダクトに関わる全てを網羅するシステム
- ex)
- Bootstrap
- Material design
- ORIGAMI
なぜ必要なのか?
- マルチデバイス
- デザインの技術的負債
- 使う側はそのサービスのどこに触れたとしても同じ体験ができる
- 作る側も共通の言語(一つの真実)があることでぶれずに早く実装を進めることができる
- 変化の激しいフロントエンドでカオスを管理する
構成要素
- STYLE GUIDES
- デザインに関わる材料やガイドライをドキュメント化する
- BRAND IDENTITY
- DESIGN ランゲージ
- VOICE AND TONE
- CODE STYLE
- PATTERN ライブラリーす
- And more...
- デザインに関わる材料やガイドライをドキュメント化する
導入
- 技術的な難しさよりどう運営していくか
ゴール
- デザイナーにとって
- デザインをする際のビジュアルリファレンスになるパターンライブラリを作る
- エンジニアにとって
- それを見てデザイナの思想を実装できるようにコードスニペットを利用できる
- デザイン・システムはプロジェクトではなくプロダクトによって作られたプロダクトである
必要な人材
- デザインが成し遂げたい思想を理解している人
- エンジニアがシステムを作る手段や方法を理解している人
- その中間にたてるバランス感覚を持っている人
- そんな人はいない、いたら連れてきてくれ(雇う)
- つまりエンジニアとデザイナにはギャップがある
デザイン・システムはそのギャップを解決できる
- デザイナとエンジニアの継続的コラボレーションとなる
- デザイナとエンジニアは成し遂げたいゴールは同じなのに共通言語がない
- デザイン・システムが共通言語となり得る
チームモデル
- デザインシステムを作成(導入?)していくチームの体制
単性モデル
利点
- ある一つのプロダクトだけのUIライブラリ集
- mini bootstrapを作って使ってもらう
- 確立されたパターンライブラリの存在は大きな利点
弱点
- ある問題を解決するためにデザイン・システムが生まれてしまう
中央集権モデル
利点
- どのチームにも属さずデザイン・システムを作成する
- 様々なチームの要望を聞い作成する
- 多くの人に受け入れてもらう(一般化)
弱点
- 実際のプロダクトのつながりが弱い
連合モデル
利点
- マテリアルデザイン
- デザイナ, エンジニアが集まって意思決定する
弱点
- 人材の管理が困難
どれがベストか?
- 時と場合による
- 会社の規模や、デザイン・システムがどれだけその規模を網羅するのか...
まとめ
- デザイン・システムとはプロダクトである
- プロジェクトは作り終えることがゴールになってしまう
- システムが生き続けるには必要な運営を考えなければいけない
- 必要なものはチーム
- デザイナとエンジニアのギャップが一番小さくなる
- デザインとエンジニアリング両方できる人はいない
Lightning Talks
- Introduction to Resource Hints
- atomic designで助かった人たち
- 祭りから半年たったプロジェクトにジョインしてみた
- 最近のお仕事について
Introduction to Resource Hints
- 登壇者: @1000ch
- Resource Hintsについて
- Introduction to Resource Hints
atomic designで助かった人たち
登壇者: @becyn
デザインを5つのコンポーネントに分割する
- シンプルな考え
- デザインが統一されやすい
- デザイナと仲良くなれる
祭りから半年たったプロジェクトにジョインしてみた
登壇者: @asukaleido
辛いこと多い
- コードの品質 != サービスの品質
- なぜか
- 思想が一貫する
- フレームワークを使っていない => 思想が強制されない
UI実装の最高とa11y
登壇者: @ahomu
残念なデザインとは?
- 色々あるがコードが残念toka
- 使えないをなくしたい
- 実装が貧弱
- クライアントがプア
- 使えない は 使いづらい の延長線上
アメブロフロント刷新にみる ひかりとつらみ
- 登壇者: @kouhin @herablog
関連資料 developers.cyberagent.co.jp
なぜ
- PVが落ちた
- 特に月末
- 表示速度が他に比べて遅い
- バックエンドがAPI化されていた
ゴール
表示速度改善
コンセプト決める
- 速度を図る
- SpeedCurve
HTMLのサイズ減らす
- SSR(サーバーサイドレンドリング) SPA 共存
- LazyLoad
- HTML20%減
- Reactの
renderToString()
遅い- キャッシュ最適化
システムモダン化
exampleアプリのように作る
- 正しいものを正しくつかう
React with Redux
- コンポーネント志向
- pure functin
- Redux stateの状態だけで表示内容が確定できる
- CSS Modules
- css-loader
- スコープが切れる
- 影響範囲が絞れる
- Atmic Design
- 状態と処理を持つContainerと表示だけをするContainer
- Babel
- 決まっている未来は早めに試そう
- async/await
- ESLint/Stylelint
- 好みはあるがルールを統一して一貫生を保つ
- CI
- CirculeCI
- Docker
- Node.jsのポータビリティー
- Nodeのアップデートが観覧
- Dockerfileを変えるだけ
- 最新のNodeを使う
- OSSっぽく開発
- 外でもそのまま使える技術を
UX
- No more ガタン
- 誤タップはモバイルUXで最悪の出来事
- コンテンツファースト
- 横幅をMAXまで使う
つらみ
- Reduxむずい
- Action/Reducer理解するまで時間かかる
- Lintがスパルタ
- 最初はCIでエラー
- アメブロモジュール多すぎ
- 周辺技術多すぎ
結論
- みんながんばろ
感想
今回は初参加させていただいたfrontrendですが、非常に濃い内容でLTも30分枠で聞きたい内容ばかりでした!
発表資料も今後アップされて行くと思いますが、FRESH!で生放送されていた動画があるようなので、是非ご覧になってみてください!私のまとめ記事の1000倍は内容があると思います!!
さて、勉強会のタイトルでもあるように自分なりに今日のお話を聞いて frontのtrend を感じました、それは
- デザイン・システム
- Atomic Design
です!
デザイン・システムは今までCSSの便利ライブラリくらいに捉えていたBootstrapがエンジニア、デザイナ間での共通言語として、どんな目的のために利用して行くべきなのか。自分の中で明確になりました。
また、LTで @asukaleido さんの仰っていた「コードの質とユーザビリティーは必ずとも一致しない。なぜならコードに統一された意思があるから。」というプロダクトのコードに統一された意思をもたらす面でも役立つのかなと思いました。
Atomic Designは画面のコンポーネントを最小単位から順に5つの大きさに分類する。というもので、コンポーネントの再利用性・デザインの向上などの恩恵もあるようでしたが、自分はデザイナとの共存が一番のメリットに感じました。
少し話は進んで、アメブロの @herablog さんのお話にもあったように、Atomic DesignをReactやVue, AngularといったJSライブラリ群とどう共存させるか。というのも興味が湧いて来ました。
乱暴な言い方ですが、デザイン・システムもAtomic Designも
- デザイナ・エンジニアの共存性向上
- UI/UXの改善
- つまりエンドユーザーにより高い価値のものを届ける
という点においては、達成したいものは同じなように感じました。そしてこれが今の、ひいてはこれからのfrontendの課題なのではとも感じました。