2011年7月27日：アジャイルサムライ@ドワンゴ道場

進め方：

• 各節の要約を持ち回りで発表
• そのテーマでディスカッション

参加者：

• @lchin @kwappa @yamashiro @kusigahama @xga @skyguild @akitsukada @erukiti @tlync @meso（他に、ニコ生、ニコモバ開発者数人）

ゲスト：@skyguild

第1章：ざっくり分かるアジャイル開発

1.1 価値ある成果を毎週届ける

• 誰がお客さん？
• (とある社内システム) : テンプレートが走る
• テンプレを書く人 → 企画を立てる人
• 近いお客さんとは合意しやすい → 遠いお客さんとは合意しにくい
• 顧客の代理
• サービスを使うユーザからの直接のフィードバックではない
• 代理は正しく要求を伝えている？
• 会社としての期待
• コストとか
• 遠い偉い人の天の声
• 提案に穴を用意しておいてツッコミを待つ
• ドワンゴではどのくらいアジャイル開発が浸透している？
• カウボーイとアジャイル開発の間
• ドワンゴはXPに挑戦したわりと早い企業
• 「ニワンゴ部屋」（2003年、2004年くらいらしい）
• 全社的にスタンドアップミーティング、ふりかえり、trac、定期的なリリースが定着している
• やろうとしているチームは多い
• うまくいってるかどうかはまた別
• 意識を浸透させるのは難しい

1.2 アジャイルな計画づくりがうまくいく理由

• 「アジャイルな見積りと計画づくり」読んだ人？
• 最近読んだ本の中では一番役立ってる、という意見も挙がった
• プログラマの教育では、プログラミングは学べる(趣味、学校)、見積は学べない
• ベロシティによる測定が特に有効
• 理想日ベースでの導入チームがある
• 見積できるのが理想、外的要因によるタイムボックスがあることも
• 落とす機能を決める = 暗黙に見積もってるのでは？
• 属人性が大きくなりがち
• 無理矢理やらざるを得ない状況
• がんばりでカバーしてしまうことも
• 数字としては無茶な値
• うまくいかない理由になっちゃった
• うまくいく理由
• 相談の余地がある場合 (外部からの無茶な要求)
• オープンにする (ステークホルダーに対して)
• タスクリストを見せる
• アンチパターン(他社の経験)
• リーダーしか見積もらない → 見積どおりに進めることを強要される
• 全員で見積の合意を取るのがよい
• メンバーが多くなると見積のコストが大きくなりすぎる (9人とかおおすぎ)
• 分割するべき
• 無茶をして間に合わせることの弊害
• デフォルトにされてしまう
• チーム状況の悪化
• 長期的なデータ（ベロシティの推移など）を残すのが重要
• 説得材料になる

1.3 「完了」とは完了のことだ

• 「進捗95%」？なにそれ？
• 「だいたいできた」「もう少し」
• binaryにしろよ → リリースできないなら価値はない
• 「できました」の品質
• 人によるので難しい
• デザインはゴールがない
• 完成の定義も分割する
• 行程ではなく機能単位で
• 「デプロイできるのがゴール」
• デプロイを意識していないプロダクトはリスク
• 外部要因による待ち
• テンプレ、品質保証
• チームがひとつじゃない
• 品質保証に出すことがリリース、という定義もあり
• 「実践アジャイルテスト」
• 品質保証チームもチームに入るべき
• 実際は難しい (現在の組織では)
• 制度的な問題
• 「品質保証が混んでるので外注」
• 新たな「無茶なスケジュール」の発生原因
• 硬直した運用ルールによる問題

1.4 3つの真実

• 他のチームのことを知るのが大事
• 意識があって、いくつかのプラクティスを実行してれば「アジャイル」な開発
• どこのチームも「オレオレアジャイル」
• アジャイルはマーケティング用語
• 開発プロセスの改善もアジャイル
• TAOAD　http://www.amazon.co.jp/dp/4873113954
• カスタマイズ重要
• 格闘技と一緒
• 「カラテ」「ニンジャ」「アイキドー」で分割する必要はない
• 守離破
• 総合で強いヤツが強い
• いろいろあるから難しい
• やってみる、改善してみる

第2章：アジャイルチームのご紹介

2.1 アジャイルなプロジェクトはどこが違うのか

• 「企画側」
• チーム内にいる感じはしない
• ウォーターフォールな世界観
• スケジュールありきの案件
• 「『側』禁止！」
• 無茶なスケジュールによるデメリットを説明せねば
• 彼らは普段なにやってるんだ？
• 計画に参加してもらう
• ストーリーの優先順位
• (とあるサービス)
• チーム間で縦割り感
• 機能でチーム編成できると理想的
• 縦の伝達が悪くなる？
• アーキテクチャによる分断
• 分かれざるを得ない
• 案件次第、状況次第
• アナリストって？
• 英語圏には「SE」という概念はない
• 役割分担はあるが上下はない
• ドワンゴでは「エンジニア力のある企画職」がやることが多い

2.2 チームをアジャイルにするためのコツ

• ドワンゴは距離が近い
• 在宅勤務のエンジニアとも距離感を感じない
• デブサミでヨシオリがその話してた　http://d.hatena.ne.jp/Yoshiori/20100127/1264570722
• 週1社内を回ります
• キックオフミーティングには出ます
• フロアが違うだけでもコミュニケーションの障害に
• インフラチームと遠くなってコミュニケーションが滞っている
• 先日のレイアウト変更でどうなった？
• (とあるフロア)
• 「企画側」と近くなって、コミュニケーションは増えた
• (とあるチーム)
• テンプレは近くなったので効果はある
• 企画は遠いのでなかなか(10F / 11F)
• IRCによるコミュニケーション
• 企画職にもIRC参加してほしい
• 実施したチームは効果が出ている
• 深く関わる顧客
• 訳が難しい
• engaged customer
• SIではやる気のない客に出会った
• 向こうにやる気がないと巻き込みづらい
• 開発出身の企画職は深く関わってくれる
• 毎日ちょっとでも話せるとやりやすい
• 開発者だけの定例MTGはできるだけなくしたい
• 自己組織化
• ドワンゴは弱いような気がする
• 担当部分で閉じている
• しっかりリーダーが仕切っちゃう
• どうする？→ オープンにする、対話を作る
• 得意分野(キャラ)がかぶってると自己組織化しにくい
• チーム編成から
• 自分から関わる姿勢
• オーナーシップ→プロダクトへの目的意識の共有
• リーダーの横のつながりが重要だよね
• 見積をみんなでやるといいよね
• 関わってない人も見積もるために説明する必要がある→考えるきっかけになる
• 時間かかるんじゃない？→経験の蓄積でどんどん早くなる
• リーダーまでは権限委譲されている
• 責任を押し付けたいだけかも？
• 言われたことをやる人が多いチームだった
• リーダー経由のコミュニケーションを改める
• モチベーションあがる、という成果は出てると思う
• 「責任を押し付けられた」と感じる人の対応
• バランスだいじ
• 性格と能力を見つつ
• 委譲される→意味が分かる→楽しくなる
• 委譲が進むと俗人化するのでは？ (企画と直接やりとりとか)
• コミュニケーション大事
• ペアプロのシャッフル
• 窓口を固定しても同じ問題が
• コミュニケーションによるタスクの発生がチームに共有されない問題
• コミュニケーションルートの問題？
• エンジニア：trac / IRC、企画：Excel
• ジェネラリストが望ましい
• お前らOS知らなすぎ
• インフラとの距離が原因？
• ジェネラリストチームは楽しい / 生産性が高い

---

次回は「2.3 よくある役割分担」からやります

ドワンゴ道場トップ