読者です 読者をやめる 読者になる 読者になる

30億のデバイスで走るHonMarkHunt

JavaとJavaScriptと恐竜の絶滅について書いていきます。

DDD(大臣 Driven Development)のすゝめ

こんにちは!@HonMrakHuntです!

この記事はラクス Advent Calendar 2016の18日目の記事です。

昨日は@Black-Spiderさんのゲーム作り(C++&DxLib)を通してオブジェクト指向プログラミングを学ぶ方法(環境構築~画面の中で物が動くまででした!

明日は@iketomo1207さんの投稿予定です!

目次

  1. はじめに
    1. チームの悩み
    2. 解決策
    3. で。それ、いつ、誰がやるの?
    4. さぁ!DDD(大臣 Driven Development)だ!!
  2. DDD(大臣 Driven Development)
    1. 大臣 Driven Developmentとは?
    2. ルール
    3. DDDのワークフロー
      1. 大臣任命
        1. 問題を明文化する
        2. 大臣を任命する
      2. 大臣活動
        1. 頑張れ大臣!
        2. 報告だ!大臣!
  3. 2ヶ月やってみて
    1. なぜWorkするのか?
    2. 課題
  4. まとめ

はじめに

突然ですが、みなさんのチームは困っていますか?

僕は困っています。

f:id:HonMarkHunt:20161219000159p:plain

今日はチームの悩みを解決する(かもしれない)、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を導入だぁー!

f:id:HonMarkHunt:20161219000155p:plain

で。それ、いつ、誰がやるの?

で、それ。誰がやるんですかね?

最初のやる気は何処へやら、日々の忙しい業務に揉まれて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で解決していきます。 いきますよ。

  • あふれんばかり出て誰も手をつけなくなったのエラーログ。 -> アラート大臣
  • 放置されるお問い合わせ。 -> お問い合わせ大臣
  • 追いつけない外部APIのアップデート。 -> API大臣

はい、DDD完了です。

そうです。大臣 Driven Developmentとは、

チームの悩みごとに大臣を任命し、大臣が責任を持って悩みと向き合う制度 です!

ルール

DDDのルールをご紹介します。

1. 大臣はあくまで責任者であり、担当ではない。

以上です。

このルールについては後述します。

DDDのワークフロー

私のチームで導入されているDDDのワークフロをご紹介します。

  1. 大臣任命
    1. 問題を明文化する
    2. 大臣を任命する
  2. 大臣活動
    1. 頑張れ大臣!
    2. さあ行け大臣!報告だ!

1. 大臣任命

まずは大臣を任命して行きましょう!

1.1 問題を明文化する

チームの問題・改題・悩みをあげていきます。

私のチームではスプリントの終わりごとに振り返りがあるので、KPTでProblemをあげて行きます。

1.2 大臣を任命する

問題(Problem)が見つかったら大臣を任命します!

私のチームではチームで技術定例を行なっています。その際に話あって大臣を決ました。 ひとまず自選他選問わず。ノリで決めました。

2. 大臣活動

大臣が決まったら活動して行きます!

2.1 頑張れ大臣!

任命された大臣が頑張ります!

余談ですが私はアラート大臣を任されています。日々飛んでくるアラートをissueにまとめてみたり、数を数えてみたり、そんな活動をしています。

ここで大切なのは、

  1. 大臣はあくまで責任者であり、担当ではない。

このルールです。アラートなんて見ても全くわからない時がほとんどです。見わからなければ誰かに相談してみます。 決して自分が全て解決しないといけないわけではありません。任命された問題に責任を持って活動すれば良いのです!

2.2 報告だ!大臣!

毎日の活動は夕会で報告します。

今日のアラート数やわからないことなどを報告します。大臣が活動していることがチームに浸透して行くと自然と周りも協力してくれるようになって来ました。

2ヶ月やってみて

以上で、なんとなく大臣 Driven Developmentがどんなものかわかっていただけたかと思います。

私のチームでは2ヶ月が経ちました。振り返りも兼ねてチームがどう変わったかを書いて行きます。

なぜWorkするのか?

ある者は生まれつき偉大、それ以外は強いられて偉大になる。 君にとって、これが偉大になるチャンスだ。

さて、困っていることに大臣を任命して活動するアホみたいな施策ですが、実は結構Workしています。

なぜWorkするのでしょうか?

我らがチームリーダーのnagaa052さんに教えてもらった言葉を紹介します。

「立場が人を作る。」

大臣に任命されると謎のやる気が出ます。

私もアラート大臣という立場に感化されて、気づいたらElasticsearch学ぶ宣言をしていました。 この、立場によって生み出される責任感がDDDがワークする理由だと思います。

課題

始まって2ヶ月のDDDですが、課題もちらほら出てきています。最後に今後のために現状の課題をまとめておきます。

  • 大臣の任期を決めていなかったので、終わりが見えない。交代制にする?
  • 大臣の兼任はいくつまで?たくさん兼任すると大臣活動で忙殺されてしまう

この辺の改善は日々解決して行きたいです!

まとめ

チームにはチームの悩みの数だけ問題があると思います。

悩みを打ち破る手段はたくさんありますが、もしだれがやるのかが決まらなかったら。大臣にやってもらうのはいかがでしょうか?

最後までご覧いただき、誠にありがとうございました。

Frontrend Vol.8 - 帰ってきたフロントレンド 行ってきたメモ

f:id:HonMarkHunt:20161205214825p:plain

はじめに

  • Frontrend Vol.8 - 帰ってきたフロントレンドに参加してきました!
  • 1年半ぶりの開催とのことでしたが初参加させていただきました!
  • ブログ絶対に書くマン枠にて参加させていただいたので、投稿させていただきます。

frontrend.connpass.com

開会の挨拶

  • 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

atomic designで助かった人たち

  • 登壇者: @becyn

  • デザインを5つのコンポーネントに分割する

  • シンプルな考え
  • デザインが統一されやすい
  • デザイナと仲良くなれる

祭りから半年たったプロジェクトにジョインしてみた

  • 登壇者: @asukaleido

  • 辛いこと多い

  • コードの品質 != サービスの品質
  • なぜか
  • 思想が一貫する
  • フレームワークを使っていない => 思想が強制されない

UI実装の最高とa11y

  • 登壇者: @ahomu

  • 残念なデザインとは?

    • 色々あるがコードが残念toka
  • 使えないをなくしたい
    • 実装が貧弱
    • クライアントがプア
  • 使えない は 使いづらい の延長線上

アメブロフロント刷新にみる ひかりとつらみ

  • 登壇者: @kouhin @herablog

関連資料 developers.cyberagent.co.jp

なぜ

  • PVが落ちた
  • 特に月末
  • 表示速度が他に比べて遅い
  • バックエンドがAPI化されていた

ゴール

  • 表示速度を開演
  • システムのモダン
  • UXが今後10年戦えるUX
    • 表示速度はWebUXを支える最も重要
    • ダンなエコシステムは、いいアプリを作るために必要

表示速度改善

  • コンセプト決める

    • 速度を図る
    • SpeedCurve
  • HTMLのサイズ減らす

    • SSR(サーバーサイドレンドリング) SPA 共存
    • LazyLoad
      • HTML20%減
  • ReactのrenderToString() 遅い
    • キャッシュ最適化

 システムモダン

  • exampleアプリのように作る

    • 正しいものを正しくつかう
  • React with Redux

  • 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の課題なのではとも感じました。