From Legacy to Agile　～レガシー開発からアジャイル開発へ～

• 野口さん
• 塩谷さん
• レガシー開発からアジャイル開発へ
  • 移行するのに障害があるはず。それをどのように乗り越えていくか。またキャリアデザインなど

アジェンダ

• 3周回った俺達のアジャイル
• レガシーの現実
• レガシーからアジャイルへ
• クロージング

3周回った俺達のアジャイル

• 塩谷さん
• dwango の中の人。1月からドワンゴモバイル。

このセッションについて

• 去年の9月にXP祭りで喋ってきた内容の再演みたいなもの
• もう少し時間をかけて、大勢の前で喋りたいと思った
• カオスなゲーム開発からSI式ウォーターフォール(略)アジャイルという草原にやってきました
• 一昨年のdevsumiで、 @yoshiori さんの3周遅れのXP → ベストスピーカー賞
  • その時はまさか同じ会社で働くことになるかとは思わなかった
• 一昨年そのセッションで感銘を受けた人が、実際に現場に入ってみてどう感じたかを紹介します

きっかけ(社内事例紹介)

• きっかけ1
  • ホワイトボード1枚にタスクボードとバーンダウンチャートをつけている
  • 新卒で入って1年目、がんばってタスクボード更新したりしてる
• きっかけ2
  • プランニングポーカーをして見積もりをしているチームがある
• きっかけ3
  • コードレビューをたくさんやっている
  • ペアプログラミングが大好きで、作業量全体の半分くらいはペアプロでやっている
  • セオリー通り、キーボードを奪い合うような感じではなく、後ろでコード書いているところを見守るとかしてる
• きっかけ4
  • 朝会（夕方やっているので夕会）
  • イテレーションを1週間でやっている。リリースとはリンクしていなくて、振り返りするための区切りにしている
  • KPTをアレンジ -> KPTZ
  • Z -> 雑感
  • 「今日は8/33。夏休み終わりたくないでござる」
  • 「烏賊がなくなりそうでござる」
    • 大所帯なので、コミュニケーションの役に立っている
• 傾向
  • 導入プラクティスは割りと共通
    • 朝会、CI、バーンダウン、
  • アレンジを恐れない
    • 本に書いてあるとおりに続けて硬直化して続かないよりも、現場に合わせた方がいい好例
  • 飢餓感
    • プラクティスに縛られない。自分たちのチームをよくしていこう、という意識が強い
• アジャイルサムライが発売されてすぐの時期のこと
  • 「今までやってきたことに名前がついているのを知った」

まとめ

• 高速道路がたくさんある
  • こうするとうまくいくことが多い、うまくいく可能性が高い、という知識は本とかWEBに書いてある
  • 高速道路を活用すればいいが、現場では守破離が大事
  • 守 → 最初はセオリー通りにやる
  • 破 → アレンジしてみる
  • 離 → 自分たちのやり方を確立させる

自分がやったこと

• 壁にホワイトボードでタスク看板作成、みんなで(企画職の人も含めて)朝会
• 見える化されたので、他職種の人ともタスク量を共有することができた
  • こういうアナログなツールは、Redmineとかよりも効果を発揮するケースがある
• 事例を紹介しましたので、devsumiの「次は君の番」の慣例に従って、あなたのところでもやってみてください

レガシー開発の現実

自己紹介

• 野口さん
• 2011年12月に転職。dwangoの中の人。ニコニコ静画とかやってます
  • それまではエンタープライズ向けシステム開発

レガシー開発とは

• 開発をレストランだと考えてください
  • 予約されたコースをその通りに出す(フルコース)
  • カウンターで、お客さんと話しながら一つ一つ注文していく
• それぞれにメリット、デメリットがある
  • 結婚式とかのパーティーに向いているのはどっち？
  • 無駄が多いのはどっち？
• カウンターで、お客さんと話しながら一つ一つ注文していく → アジャイル
• 予約されたコースをその通りに出す(フルコース) → レガシー
• 変更を許容しない
• 顧客と開発者は別
• 決められたとおり（仕様書）に従ってモノを作る

現場のあるある

• ヒトが倒れたりするw
• それ、〇〇さんの書いたコードなんで
• 「なんかいけてないんだよねー」(ざっくりした要求)
  • ざっくりした要求をマネージャーが部下にRT(右から左に流すだけ)
• 「仕様書とテスト項目少ないよ」 → 「え？これ以上どうしろと？」
  • 仕様書少なすぎるパターン
• 「何ステップ書いた？」 → 「200くらい。見積もりより少ないです」 → 「少なすぎ。さぼってね？」
  • コード何ステップ書いた？パターン。ステップ数で生産性図る時点で問題がある
• 「あー、今回もデスマだったけどリリースできたわー」「3日寝てねーからつれーわ」

レガシー開発をまとめると

• 人のコードは人のもの
• 伝言ゲーム
• Document Driven Development
• 開発標準 ISO9001
• 「開発ってのは辛いもの」というイメージを持ってしまう。仕事だから辛いのは当たり前だよね

生存戦略

• このスライド、今回のデブサミで相当見ていると思うんですけどｗ
• これからこの生存戦略を皆さんと一緒に考えていこうと思います

質疑応答

• レガシーな会社を変えることができるか？
  • できると思っています (野口さん)
• なぜ会社を変えたんですか？
  • 人生そんなに長くないので、つまらないことには付き合いきれないなと思った (野口さん)

座談会的な

• アジャイルに対する誤解
  • 優秀な人たち向け
  • モノだけ作る
  • お客さんのいいなり
  • 対話とかいいから、お前ら手を動かせ

優秀な人たち向け

• よれよれと手書きでホワイトボードに書いているようなやり方でも実践できる
  • そう言えるのは優秀だからですよね？ｗ
• レガシーのやり方だと、数割のスゴイ人と残りの普通の人だけど、アジャイルだとみんなでスゴイことをやろうよ、というやり方。
  • できるところからみんなでやろう

モノだけ作る

• 仕様書とかドキュメントとかは要らない？
• 仕様書は30kg納品してください → 仕様書の単位としておかしい。環境破壊だからヤメレ
  • 引継ぎのドキュメントとか、共有にドキュメントが必要であれば最適で効率的なやり方を探した方がいい
  • wikiは便利だけど、wiki最高！は思考停止
• エクセル方眼紙は人の心を汚す
  • 最近のエクセルは方眼紙がデフォルトテンプレート。マイクロソフトはソフトウェアエンジニアをこｒ(ｒｙ

お客さんのいいなり

• お客さんを「同じバスに乗せる」というのが成功に一番近い
• 「お客さんがこう言っているから」というマネージャーのセリフはおかしい
  • お客さんをコントロールできるマネージャーは強い。はい、というよりいいえ、といえる方が強い。それはアジャイルであれレガシーであれ変わらない

対話とかいいから、お前ら手を動かせ

• アジャイルのツールの多くはコミュニケーションのためのものなので、対話要らないってことはない
• 朝会が「朝礼」になっちゃっているとかヒドイ。1時間朝礼で立ちっぱなしとか
• 開発現場でしゃべるか？
  • その場の空気。隣の席の人とチャットすることもあれば、大声で話すこともあるし

アジャイルはじめるには？

• ドキュメントどうする？
  • 砂でも入れておけば。アマゾンで1トン買うとか
  • 全くドキュメントを書かない、と思っている人がいるが、そんなことはない。必要なドキュメントは書く
• ペアプロの生産性
  • チームのコードの作り方を学んだり、教育にとても有効
  • 書いたものをレビューするよりも、書きながらレビューする方が品質は高い。お得。割安。
  • コードの読みあわせ。プリントアウトしたものを1時間くらいかけて説明するようなことをレガシー開発ではやってた
• 見積もりは？
  • お客さんとの信頼をコツコツと作っていくしかない
• 仕様変更
  • 仕様変更は、発生するのが当然として考えておかないとダメだと思う(野口さん)
  • 仕様変更が発生するのは、別に誰も悪くないと思う(塩谷さん)
    • エンジニアにできるのは、仕様変更に強い作りにしておくことだと思う
  • レガシーな開発だと100%納品が求められる
• スケジュールは
  • 確定するのは難しいので、だからこそお客さんを巻き込むのが重要
  • 正確な見積もりは不可能だし、要件はどんどん変わっていくので、外れた時にどうするのかコンセンサスをとっておくことが大事
  • ガントチャートがない世界に行きたいｗ
    • 変化がある以上、期日通りにはなかなか難しい

アジャイル関連書籍

• アジャイルマニフェスト
  • レガシーなものとアジャイルの対比、で書かれている
  • 10年経っても色褪せない
• アジャイルサムライ
  • 各地で読書会が開催されているヤツ
  • カッコ悪さを隠していないところがいい。脱力しまくりのイラストとか、それが現場のリアル
• アジャイルプラクティス
  • Javaとかで言うデザインパターンとかに近いような気がする
  • 八重洲ブックセンターで「なんじゃこりゃ」って手にとった本。衝撃的だった。
  • 現場で試しにやってみよう、というのであればアジャイルプラクティスは最適。朝会とかやり方が具体的に書いてあるし。
• アジャイルな見積もりと計画作り
  • 見積もり手法について書いてある。計画ってのは立てて完遂するのが美ではない。いかに修正するか
  • 自分のチームの生産性を把握しておくことが重要
  • チームが5~6人以上であれば、読んでおくことをオススメ

プランニングポーカー

• 他の人のタスクであっても、みんなで見積もりして共通認識を作るのって大事

(第2部は手書きなので後ほど・・・)