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ですが、課題もちらほら出てきています。最後に今後のために現状の課題をまとめておきます。

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

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

まとめ

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

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

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