三周遅れのXP -僕とドワンゴ のXP-

  • 発表者プロフィール
  • タイトルの三周遅れってどういう意味？
    • ネガティブな意味でつけたわけではないそうです。
    • ドワンゴが（庄司さんが）、XPの3番目の実践者です。的な？
      • 一周目のケントベックさんが提唱し（方向を示す）
      • 二周目の角谷さんが先駆者として日本に紹介し（道を通す）
      • 三周目のドワンゴが加速させる！みたいなニュアンスで
        • でも、よく考えたら三周遅れにしちゃうと、四周目になっちゃうね。と前日気づいたそうです。お茶目ですね。
  • 車輪の再発明をしない
    • 開発における車輪の再発明をしないよう、ノウハウの共有をする
    • 知識の「高速道路の設置」をしよう
      • ブログへ書く、Twitterへ書くことで、後に続く人のための高速道路を設置している。
  • XP「4つの価値」
    • コミュニケーション
    • シンプルさ
    • フィードバック
    • 勇気
      • 「コミュニケーション」の一例として
        • ドワンゴでは、みなが気軽におやつを持ち寄って食べられる「おやつ神社」を設置している。
        • 気軽に話が出来る場所を設けることが大事。
      • 「勇気」の一例として
        • テストコードを書く、書いてあることで、リファクタリングをする勇気がわいてくる！みたいな

テスト駆動とは

    • 品質管理の話はしない
    • 目的はテストではない
    • テスト駆動とは「あくまで開発手法であり、テスト手法ではない」
  • TDDの２つの道
    • 開発にはゴールへの2つの道があるという（和田卓人さんの話から？）
      • すぐ動作する汚いコード
      • すぐには動かないキレイなコード
    • TDDは前者
      • まず動作するコードを書き、リファクタリングをするのがTDD
      • いかにテストを利用して開発をするか
      • 庄司さん「後者だとゴールできる気がしない」
  • みんな「テストしました」ってどう保証しているの？
    • ブラウザを、標準出力を、目視確認
    • 「めんどくさくない？」
    • 翌日までテスト結果を覚えている自信がない。（だからこそテストコードを書いている）
  • TDD（テスト駆動開発）の良さ
    • 自分の解決すべき問題を、小さく明白にできる
      • とりあえず赤を緑にすればいい。そこだけに集中できる
    • すぐにテストを実行できる
      • テストと結果があるので、自分のコードに自信を持てる
      • 自信があれば、リファクタリングをする勇気が出てくる
    • TDDにおけるテストを書く目的
      • 開発するためのテストを書くのです
      • 品質を担保するためのテストではないんだよ
  • 品質の為ではないそのテストは無意味なのか？
    • TDDのテストは品質を担保する為にあるのではない
    • （しかし）TDDという開発手法自体が品質をアップさせる、副次的な効果は持っている
    • 今日は自分がプロジェクトマネージャをしている新サービスのリリース日だが、メンバーに聞いたら「いなくても平気っす」だって
  • 伝わりづらいこと
    • Q.UnitTestになってしまい、網羅的にテストを書いてしまう
      • A. TDD != UnitTest
      • 開発を進める為の不安を取り除くためのテスト
    • Q.カバレッジが、品質が、どうなってるの？
      • A. 開発のためのテストであって品質のためのテストではない
        • 副作用として、品質があがることはあるけれどね
  • どうやってTDDを社内に浸透させたか
    • 社内でTDD写経会をしました
      • ドワンゴ入社当初、プロジェクトにはまったくテストがなかった
      • ペアプロしてください！とお願いし、何も言わずテストから書き始めた
      • WEB+DB vol.35テスト駆動開発の記事を写経
        • 情報古いけど、エッセンスは良い、そうです

ペアプロのススメ

  • ペアプロやろうよ！
    • コードの共有
      • ペアプロしていない == コードの共有をしていない
    • コードの共有がされていないと
      • チーム内で、担当分野以外の仕様を把握できていない
      • 修正されると、自己批判と感じてしまう
      • 「○○さんの書いたところだから…」はNG
      • コードはチームのもの！自分が直せ
      • コードの指摘を人格批判だととらえるな
      • コードの批判は人格批判ではない！ことを頭ではなく心で理解しよう
  • ペアプロのススメ
    • 新入社員には、コードをブログで書かせています。返信もブログにします
    • 自分のコードをさらすことに、徹底的に慣れてもらっています
    • コードを私物化しない、コードをチームのモノへ昇華させるようにしましょう

CIのススメ

    • CI (continous integration)
    • 継続的な結合
    • ドワンゴでは、HudsonでCIを行っています
  • CIを行っていく上で発生する問題
    • コード量が増えるに従い、SLOW TEST問題が発生してきます
      • テスト量が増えると、テスト実行が遅くなる
      • テスト実行が遅くなると、テストするのがおっくうになる
      • テストしなくなる
  • ドワンゴにおける、SLOW TEST問題へ対応
    • 開発環境では、オンメモリでテストするようにした（※よくわかんなかったです）
    • HudwonではDBを使用する
    • アップデートインサートが不要な機能テストについては、データの削除はやめた
      • e-applyでも、functionalテストの実行がかなり遅いので、参考になるかと思いました。

見積もりと計画

    • ストーリーを分割
    • プランニングポーカーで多人数で見積もる
      • 標準的なストーリーに基準ポイントをつける
      • あとのストーリーごとに、一斉に、カードのポイントを提示する
      • 下だった人の理由、上だった人の理由を聞く
      • 各人の考える、ボトルネックと解決策が共有できる
    • リリースの
      • １ヶ月単位でリリース
      • 二週間単位で１イテレーション
      • 一月に何ストーリーポイントを消化できるかログをとれる
      • １年後のリリースへの見積もりができる
    • いつでも誰でも見えるように
      • アナログで表示する
      • 誰が何をやってるか？
      • ユーザーストーリー単位のポストイットを貼る
      • Tracとポストイットを併用
      • デジタルとアナログを併用したプロジェクト管理
    • 正直に書くこと
      • 上司にいい顔をしたいからじゃない
      • 自分がどの程度すすんでいるかを正確に把握するために
  • ユーザーストーリーではなく機能別に
    • 現実がXPプラクティスに即していないなら
    • 現実にXPプラクティスを適した形に作り替えていくことこそがアジャイルではないのかね？
    • 入力項目の仕様をExcelで提出しなくてはいけない
      • プログラムでExcelを
      • どんどん自動化していく
  • ドワンゴで取り組んでいること
    1. Tracから日報を自動生成
    2. IRCの「all:」の発言を毎日メール
    3. IRCにチケット番号を書くと概要表示
  • 自動化プログラムをどんどんつくろう
  • まとめ
    • 大きなモノは
      • 把握できるよう
      • 小さくまとめよう
    • 小さなモノをこつこつと
  • 組織でTDDできないなら、まずは個人からはじめよう
    • チームへ伝播
    • いずれ会社全体に
    • いずれ世界へ

パネルディスカッション 出張! DDD難民救済キャンプ

    • 今の自分には少し難しい内容でした。
    • 後日改めたいと思います。

建築から開発プロセスを学ぶ ~パタンランゲージ

    • ソフトウェア開発の話ではなく、建築のお話が主でした
    • とてもエキサイティングなお話でした。
    • まとめられていないので、後日改めたいと思います。

個人的に感じたこと

TwitterのTLや、会場の反応などを見ていると、
アジャイルな開発の仕組みを導入するには、まず会社を説得するところから始めなければ、
というような意見が散見されました。
現在お世話になっている会社は、アジャイル開発への取り組みを積極的に行っていて、
とても良い会社さんだなと再認識しました。
今回のセッションの内容で、社内で導入済みの事例もいくつかあり、
先輩方への尊敬＆感謝の念を抱きました。

  • アナログとデジタルの併用

TDDのセッションで、気になったトピックが「アナログとデジタルの併用」でした
作業チケットについては、redmineで管理されているので、
自分の作業については意識できるのですが、
なかなか全体の作業の把握は難しいです。（やり方が分かっていないだけかもしれませんが？）
アナログで張り出しておけば、ミーティングの際に必ず目に入るので、
チーム全体で、誰が何やっているか、どこがネックになっているかを共有できるように思います。

TDDのセッションの、「ペアプロのススメ」の「コードの私物化」のトピックで、どきっとしました。
どうにもコードの誤りを指摘されると、自己批判をうけたように感じてしまう傾向にあるんで、改めたいなと思いました。
せっかく、リポジトリ管理とredmineという共有の仕組みが用意されているので、
積極的にコードを共有していけるようにせねばと思いました。
ペアプロの導入は開発スケジュール的になかなか難しいと思うので、
まずはWikiへの記入や、コードレビューをすることから始めていきたいと思いました。