Agile Do It に参加してきた
日曜と祝日に挟まれた2012/3/19（月）、DeNAさんが主催の
「Agile Do It」に参加してきました。
場所は新宿NSビルの30階。上がるときのエレベータは外が丸見えの
ガラス張りだったで、ちょっとゾッとしましたが、眺めがイイ（良すぎる）。
開会の15:00まで後10分ってな時に会場受付完了。
おおっ、会場の前に見えるのはマスターセンセイことJonathan Rasmusson氏だ。
あ、@kakutani さんとか @kawaguti さんと話してる、なんて事を眺めてたら開始の時間に。
で、以下セミナーの内容ですが、、、正直、今回は参加者も多く（150名？）
既に色々と良いレポートが上がってるみたいなので、今回は一番最後の
パネルディスカッションに焦点を当てて、ブログ書きます。
（勿論、本編も興味深いセッションが盛り沢山でしたが、、、
キリが無いので、また詳細は別の機会に。
とは言うものの、何も書かないのはやはり勿体無いのでそれぞれ一言ずつ。
１．Jonathan Rasmusson氏の Agile In a Nutshell
⇒ 内容的には「アジャイルサムライ」の第1章あたりについてのお話。
ってか、英語もうちょっとヒアリングできるようにならないと。。。orz
@kawaguti さんのツイートの方が多分自分が書くより
よっぽど分かりやすい内容なのでパス。
⇒Agile Do It / Jonathan Rasmusson キーノートのメモ http://t.co/41O0oTG6
２．スクエニの橋本さんの「ゲーム開発プロジェクトマネジメント」
⇒ 確か以前Webに載せていた資料を見た気がするけど、そこから
大幅に改編されてました。「ゲーム作り」（におけるアジャイル）を
分かりやすく整理されていた発表でした。
⇒ ただ、（最近のゲーム業界の事はサッパリわからないけど）
「AAAのゲームを作る為に【良いゲームエンジン】と【プロジェクト体制】が必要」という
意見には個人的には若干「？」。後者はともかく、前者っていわゆる
土台部分だと思うので、目に見えなくてすごく重要ではあるけど
消費者側（ユーザ側）としては、正直どうでも良いかな、と。
例えば家を買う時に「この基礎工事がイイから買う」なんて事が無いように。
（※）「基礎工事をしっかりやってるから、うわものもしっかり作られてるだろうから買う」は
あると思いますが、上で言ってるのは「基礎工事そのものがイイから買うってのは無いよね」という意味。
いや、勿論基礎工事の部分は手を抜いて、「うわもの」だけ良ければイイ、とは言わないですが。
SI業界で言えば、その辺りはインフラであるとかフレームワークだろうから
ユーザさんにとって、実現手段（技術・方法）はSpiringだろうがEJBだろうが
PlayFrameworkだろうが何でもいいのと同じで、、、あ、長くなるので以降は省略。
⇒ 2点だけ興味深かった内容を。1点目はPJ運営における「防火」と
「消火」について話されていた部分ですが、賛成です。
「防火＝事前準備」、「消火＝事後の対応」について、まちがったWFでは前者にのみ注力し
逆に間違ったAgileでは後者のみに注力する、という話。
確かに自分の経験に照らし合わせてもそうだと思います。
2点目は2点見積もりについて。心理学的観点から「1点見積（＝あるタスクを「○日かかります」）」より
「2点見積（＝あるタスクを「スゴク上手くいけば○日、最悪の場合でも×日かかります」）
という見積の方が良い、という話でした。
「パーキンソンの法則（＝バッファは幾らあっても食いつぶされる）」
「学生症候群（＝夏休みの宿題は8/30から本気出す）」、
「喉元過ぎれば熱さ忘れる法則（＝一旦期限越えたら、更に遅れてもまぁいいや）」
という3つの理由を挙げて説明されたのはスゴク納得。
（前にもどっかで聞いたか、本で読んだ気がするけど、改めてその通りだと思いました）
３．ヤフーの小野澤さん、高橋さんの「爆速開発への挑戦！」
⇒ ヤフー社内でどのようにしてアジャイルを進めようとしてきたか（いるか）についての
事例紹介でした。小野澤さんが乗馬で学んだ「2つ先のポイントを見て馬を走らせる」というのと
「（馬を）信頼する。任せる。邪魔しない」っていうのはナルホドなーと。
1点だけ。（まぁ今回のセミナータイトルがそうなんだけど）「Agile Do It」って、
@ryuzee さんが以前ブログで書かれていた「Be Agile」の一歩手前の段階なのかな、と
個人的には思いました。
４．DeNAさんの貝瀬さん、大手さん、森さんの「Scrum絶賛拡大中 on DeNA」
⇒ いやー、デブサミの時の話を噂で聞いていたので、どうなるかなーと思ってましたが、、、
懇親会でタダ飯食ったので、ノーコメントで。
ただ1点。発表を聞いていて、Agileをやっていて「楽しそう」な印象は受けませんでした。
それが単なるキャラクター的な「持ち味」のせいなのか、単純に僕の受け手としての印象が
そうだっただけなのかはわかりませんが、、、（今日の他の発表もそうだったんですが）
基本的にAgile関係の発表は（シンドイかもしれないけど）楽しい、という印象を受けるんですね、個人的には。
でも、残念ながらそういう印象では無かったな、と。
５．パネルディスカッション
⇒ モデレータは@kakutani さん。登壇者は勿論Jonathan氏（なんと同時通訳付き！）、
それと角谷さんに推薦されて（？）登壇された @nawoto 氏、ヤフー（立木さん、高橋さん）、
DeNA（貝瀬さん、駒井さん）
角谷さんの「Let's get start it!」でディスカッションスタート。
（以下、なるたけ個人的意見・解釈は交えないようにして中で出た質問・意見についてメモ。
Jonathan氏は通訳が付いていて区別できたんで、Jonathan氏の発言だけはJR氏と付けとく）
↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓↓
Q1.スクラムマスター（以下SM)って実際どうなの？（しんどい？楽しい？）
・スクラムが合う・合わないは人それぞれだと思うが、自分達のチームは
スクラムの自由さ（「やらされ感」が無い）が楽しいと感じている。
・チームの雰囲気は、スクラムを入れることで徐々に改善してきている。
確かに入り始めは面倒な部分もあった（スプリント０で何をやったらいい？とか）。
・みんな楽しそう。ただ、（SMとしてチームを見ている立場では）
やっぱり始めは（メンバーが）シンドく見える場合がある。
⇒ 今迄見えてなかった（マズイ）部分が見えることによって、
そのマズイ事を「誰かが言い出さないかなー」というようなピリピリした
緊張感がある場合、とか。
（JR氏）スクラムとアジャイルについて見解を2点。
1点目。本当に様々なチームがあることに驚いている。
2点目。たった一人の人がチームに対してもたらす変革（変化）に驚いている。
⇒ だからアジャイル開発は面白い。タフでエキサイティングであり、
どんな（にイイ）システムが出来るかわからないところも。
Q2.チームのサイズは？
・10〜20人の間位
（JR氏）個人的には少人数のチーム（10人以下）が好ましいと考えている。
最適なのは2〜3人程度。
・5〜6人のチーム（を2チームほど見ている）
・6〜8人のチームが4つほど
・10名以下位のチーム
・2〜8名程度
（会場質問）適正なチームの人数を維持する為にどうやっているか？
・基本的に小さく（6人）するようにしているが、そこに3名程度のバッファ（枠）を設けて
新規参入者を受け入れられるようにしている。そして、その枠で調整することで
チームの人数が横ばいで安定するようにしている
（会場質問）チームの中にJenkins等のスペシャリストを入れているか？
・特にスペシャリストのはチームに組み込んでいない（チーム外にいてサポートしてもらっている）
（JR氏）個人的にはチームにはスペシャリストを置かないようにしている。
その方が「チームとして」Jenkins等に対する習熟・学習効果があるため
Q3.ユーザーストーリーをどのように作っている？
・プロダクトオーナー（以下PO）が叩き台のシナリオを作ってくれて、その後のスプリント計画で
チームの開発者も交えて調整を行っている。
（会場質問）チームの外側から「機能一覧」のようなものが来た場合はどうする？
・チームの外側からの要求は積極的に受け入れている。但し、POが
優先順位をコントロールしている。
（会場質問）非機能要求等の割込についてはどう扱っている？
・現在体制考え中。将来的にはPOが受け取ってコントロールする方向へ持って行きたい。
・割込タスクと既存タスクの優先順位付けをPOがしている。
・プロダクトバックログに入れて対応したり、スプリント完了定義に入れて対応したり、
2スプリント毎にパフォーマンステストをしたりもした。
・タイムボックス（20時間）を決めて試験をしたりして対応している。
（JR氏）予期しないことは発生するのでイテレーションごとに10%〜15%程度は（タスクの）
組み換えを行って対応を行った方が良いだろう。
Q4.SMとしてプロダクトバックログを見る場合に注意すべきことは？
・定期的に見直しをして、いらないものは消すように心がけている。
・優先度順はPOに任せているが、それぞれの背景や価値が明確になっているかを確認している。
（JR氏）プロジェクトの初期は、技術的なリスクを少なくするためにEnd to end になっているものを
見極める。3回、4回のイテレーションをする場合はスケジュールのテスト（確認）をしておいて欲しい。
即ち一番重要な課題を行う為の日付と、それにどれ位の時間が投入できるのか等を見極める事。
そして、ユーザさんに「価値がある」と思ってもらえるサービスを納品し続けるのが重要。
・プロダクトバックログの（優先順位が）上のものは「すぐに出来るのか？（＝準備できているのか？）」
という点について注意している。
Q5.SMとして、チームが「決定」を行う時の関わり方について、コツ・特有の難しさとかにはどんなものがあるか？
・スプリントの合間の振り返りに「そのスプリントで気になった事」をそれとなく示唆する。
また、自分の「こうしたい」という思いを振り返りの際に如何に間接的に伝えるか、が難しい。
・うまく行き始めると、詰め込みがちになるので、上手く（スコープを）減らすようにするのがコツ。
（会場質問）全然アジャイル・スクラムを知らないチームに導入する時は何から始めればよいか？
・最初は基礎的なガイドライン等を読むようにメンバーに伝える。
・一人一人対応が違う（＝個人単位で面談して対応を行う)
（JR氏）（周りの意見に）賛成。では、もう一つ例えばそのチームがアジャイル開発を
やった事が無い場合、皆さんはどうしますか？
まずPJを立ち上げる時BootCamp的なものを立ち上げることになる。
勿論その時にマスターの方から「アジャイル開発とはこういうものだ」と言う事を
説明するのも大切だが、メンバーが抱えている不安を払拭するのが大切。
と、いうのも一方的にアジャイル開発をやる、と伝えるのはフェアではないと考えているから。
そして、チームメンバーには「アジャイルを始めること」自体に「反対」という
意見を出すチャンスを与えなければならない。
要はしっかりと議論して始めた方が、成功確率が上がると考えている。
Q6.（SMの皆さんは）どれくらいプラクティスを実践してますか？（挙手で）
・テスト自動化は？
⇒ 大体出来ている。
・リファクタリングは？
⇒ あまり出来ていない。
・TDDは？
⇒ 殆どいなかった。
・CIは？
⇒ 少しいた。
（JR氏）今現在そのテクノロジーを分かっているかではなくて、
将来的にどのテクノロジーが分かっていたいか、という事が重要。
（現在分かっていない技術について）継続的に学習・カイゼンしていく事が大切。
（会場質問）（自分は組み込み開発をやっていて）Web系の開発はしっかりテストの
自動化ができてるイメージがあるが、どうだろう？
・Seleniumはまだ使っていない（使い始めてはいるらしいが、詳しくは不明）
・テストの自動化に取り組み始めたのは最近。4〜5年前のコードがレガシー化。
別途チームを作ってテストを書いて対応中。
（SMから質問）POに中々リファクタリングのチケットを認めてもらえない。
Jonathan氏ならどうする？
（JR氏）教科書的に答えると、大きな問題になる前に小さく小さくリファクタリングを
積み重ねる事が大切。とはいうものの、現実にこういう問題にぶち当たった場合、
私ならPOにこう言うだろう「今手をつけようとしているレガシーコードは
単体テストも無く、設計もダメダメでこのシステムに手を入れるより新たにシステムを
作った方がいいのではないか」と。
（と、ココで会場から「異論アリ」の声が）
（英語でのダイレクトな質問＆よく聞こえなかった部分もあるので自身は無いけど）
要約すると、レガシーシステムは（イケて無いものかもしれないが）少なくとも
動いており、顧客へ「価値」は提供している。しかし新しいシステムを作るとなると
その間の時間は顧客への価値の提供が滞ってしまう。その為、プロダクトオーナや
ユーザを説得する事が難しいのではないか？
（JR氏）結局同じ事を言っていると思う。まず、レガシーを触るのであれば
その部分に対してのテストは必ず追加するということ、それについては同感。
私の戦略としては、レガシーシステムの問題を隠さず単刀直入に
POにぶつける。そうでないと、POの（新システムに対しての）
期待値が上がりすぎてしまうためである。
また、POについては「リファクタリング」という単語を
何度もぶつけるようにしているがそれにはこんな話がある。
毎イテレーション毎にPOに「（ある程度大きな）リファクタリングをして下さい」
という事を言い続けると、POも嫌気がさしてしまう。
それは避けなければならない。
だから、その対処方法として（対象が大きくならないように）
毎週ごとに少しずつリファクタリングを行うように、POに
薦めるようにしている。
Q7.「荒ぶる四天王（時間・予算・品質・スコープ）」には、実際のところ
どうやって対処しているのか？
（JR氏）私の提案としては、そもそもスコープは臨機応変に対応しやすいようにバッファを
持たせておかなければならないが、まず初日にPOに
「やりたい事は山ほどあるが、時間はいつも無い」という事をしっかりと
伝えておく事が重要。それは早ければ早い方がいい。
何故ならチームのメンバーもその段階なら、まだクレイジーな状態には
なっていないだろうから、落ち着いてあなたの話を聞く事が出来るだろうから。
例えば、やる事が一杯になった状態で「更に投資するか？時間をかけるか？
ソースを見直すか？スコープを見直すか？どれにする？」と聞いたら、
絶対「スコープを見直す」と回答するだろう。
だから、そのような話はプロジェクト開始前にしておくべきだろう。
・スコープは調整しやすい。スケジュールの序盤から半分過ぎ位までは
どんどんユーザからの要望を受け入れるようにしておいて、
それから（ちょっとヤバくなってきたな、となってきた時に）
「スコープを調整させて欲しい」と持ちかけると、大抵飲んでくれる。
後、丸ごと機能を実装しない、という事をせずに何割かの
実装に留めた「廉価版」を提供することで、スムーズに調整できたりした。
・最近「○○機能を××日までに」という要求を受けたチームが
苦しんでいた事があったが、ユーザによくよく話を聞いたところ
「品質を落とすくらいなら納期は延ばしても良い」というような
回答が返って来た事があった。要はコミュニケーションを
しっかり取る事が（SMにとって）重要。
・チーム毎に何を優先とするかが変わってくる。例えば
「決済」というチームの場合、「スコープ」が重要事項のため
（＝どれかが欠けると丸ごと意味が無くなってしまう）、
「時間（期限）」の優先度を下げて対応を行った。
（会場質問）
・大規模チームの回し方のコツは？
（JR氏）スクラム・オブ・スクラムのような体制を組むという方法がある。
私からの提案としては、まずハイレベルのマスターストーリーリストを
作成してしまう。その下にサブストーリーリストを作成して
対応を行うという方法がある。
・最初はWFで進めておいて、途中から（ある程度固まってから）スクラムへ
切り替えるという方法をやった事がある。また、始めは小さいチームで始めて
徐々にそのチームを大きくしていった、という事もあった。
正直なところ、どれもパッとしなかった。勿論、メリット・デメリットは
それぞれあったが、大切なのは自分の現場に合わなかった場合は
固執せずに切り替えを行って対応することである。
Q8.良いSM、POになるためのコツは？
・（SMについては）忍耐力重要。チームとPOに
挟まれて、直接的な方法ではなく間接的にチームを導くために。
一般にも言われるようにファシリテーション能力も重要。
また、今エンジニアとSMを兼任しているが、
「帽子の切り替え」は重要だと考えている。
・SMは「空気を読まないこと」が重要。
「圧倒的な開発の姿」を常に念頭に置いた上で、それを如何に実現させるか、
その時に敢えて「空気を読まずに意見を言う」という事が大切。
POは「対象のプロダクトに対しての情熱」が重要。
・POにはユーザが求めるもの（例えばUX）等を
的確な日本語でチームに説明が出来る能力が重要。
（JR氏）SMの目標は「チームに求められるような存在に【ならないこと】」。
ココで「スクラム道」「スクラムギャザリング東京」のステマ(^^)
Q9.社内でのSMの交流はある？
・今、10人程度SMが社内にいるが、そのメンバーで共有会等を行っている。
・コーチを招いて、月1回程度MTGを行ったりしている。
（SMから質問）
・SMは役割として評価されにくいが、
モチベーションをどのようにして保っているか？
・終わった後に「こんな開発初めてです。楽しかったです！」と言われるのが
モチベーションの一つ。
・本来なら2ヶ月かかりそうなプロジェクトを3週間とかでできた時に
「チームが変わった（カイゼンした）」と実感できる時が嬉しい。
↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
