『アジャイルサムライ横浜道場 特別編 パネルディスカッション』ノート

2012/09/06日に開催された『アジャイルサムライ横浜道場　特別編　パネルディスカッション』のノートです。

http://www.zusaar.com/event/355105


誰が何を発言したかというところで曖昧なところがあったので、話者の名前は全て伏せました。



◆インセプションデッキ使ったことはあるか？

◇登壇者A
・契約した段階でやることは決まるので、インセプションデッキをやったことはない
・それよりはチームビルディングをやっている
　→プロジェクトが始まったら、なぜここにいるか？をやる
　→これをやるとだんだんベクトルがあってくると思って活動を続けている

◇登壇者B
・実はアジャイルをやっていない
・アジャイルやる理由には方向づけが必要
・「とりあえず、イテレーションや振り返りをやっているからアジャイル」みたいな所も多い

◇登壇者C
・アジャイルは変化に対応すること
・アジャイルでは振り返りが一番大事だと思う
・振り返りの中から方向付けを行っている
・最初に決めたことは正しいとは思っていない
・何をやっていて何を目指すか、という方向付けは変わっていく

◇登壇者D
・結論として方向付けを失敗した
　→受託した段階で、お客様には何かしらの課題がある
　→参加したプロジェクトでは課題は明確だった
　→お客様に現状維持というところがあった
　→こちらから提案をして遂行していた
　→こちらとしての意向もあったが、そちらにはならなかった
・インセプションデッキでもなんでもよいので、お客様が抱えている問題をきちんと共有する必要がある

◇登壇者E
・チームがあって、チームである程度何を作るかが決まっている。
　→方向付けはそこでできていいる。
・インセプションデッキを作って一番盛り上がったのは、やらないことリスト
　→チームメンバーででやると考えていることがバラバラだった
　→これが方向付けになって盛り上がった

◇登壇者F
・アジャイルでやりたいという話がくる、このときに「やり始めたら上司は基本的に口を出さない」と約束する
・最初はチームはうまく回らない
　→心配になっても口は出さない
　→気になるなら私に相談しろと言う
・チームには段階がある
　→まずは期待や課題・やって欲しいこと（TiDD・タイムボックス的なもの）を伝える
　→やったら次の希望を言う
　→次に一時間面談を行う
　→→「あなたは何をやりたいか、どういう方向性をやりたいか」「こちらとして期待するものは何か」など
・そうやってチームとしてやりたいことの暗黙知をためていって、方向付けをしている


◆方向付けフェーズやお客さんの意向を探るときなど、どうしているか？

◇登壇者C
・今はご年配が使うシステムを作っている
　→そこでの使いやすさは"自分の使いやすさ"とは違う
　→想像して、ヒアリングして、ちゃんと対象の具体的なデータを集めてこないと具体的な方向性は出せない
　→→そこで手を抜くと、内側によった自分達だけが考えたシステムになってしまう
・自分達が生みだす価値が何かを考えたら、使う人をできるだけ想定するしかない
　→使うターゲットが明確なら楽

◇モデレータA
「自分は農協のシステムでタブをつけたら、それは誰も使わないと言われたことがある」

◇登壇者B
・ユーザ会社とシステム会社の偉い人で方向付けが違うことがある
　→そうすると作っても平謝りするハメになる
　→「そもそも何を作ろうか？」「何のために？」「何を効率化しようとしてたの？」というのをやらないといけない
・理解できないものに100%の頭を使うことはできない。

◇登壇者C
・大きいシステムだと全員に周知できないのが問題だと思っている
・方向をごく一部の人が握っているだけだとうまくいかない
・その齟齬を解消しようとするのがアジャイル

◇登壇者D
・お客様のほうで制度を変えようという話があって、お客・コンサル・偉い人の話は合っていた
　→でもそれぞれ方向付けは違っていたのかな？と思う


◆みんなの方向がバラバラだと気付いたときにどうしたか？

◇登壇者B
・バラバラなのは話がまとまってないから
・おなかがすいているというのが一致していても、それぞれの状態が異なる（とにかく食べたい、空腹だけど胃もたれしている…など）

◇登壇者F
・似たような状況があった
　→POはある程度の責任を持っている
　→でも彼がユーザにとって本当にいいアイデアを持っているかというと、そうではない
　→そうなるとPOに対して、いい関係を作ったりモデリングをしても答えが出ない
　→そうするとPOはしょうがないとして、エンドユーザを見つけてそこにアプローチしようとしている。
　→→でもエンドユーザは忙しい
　→→その上の人に働きかけして、デモの時間をもらったりした
　→→そうやって少しずつ関係を作っている
　→→→そうやるとチームが顧客の欲しいものについて考え始める

◇モデレータB
・そもそも人のことを知らなさ過ぎると思う
　→10年後何をしたいかとか、家族のこととか
・何でそれが問題かというと、チームを同じ方向に向けるときに全員に同じやり方ではうまくいかないから
　→「ならば、チームのことをしらないでどう働きかけるんだ？」という話になる
　→「お客はもちろんだが、チームを知るために何をしているか？」という話

◇モデレータB
・向け方はいろいろある

◇登壇者F
・強制しても向かないので、向くようにする必要がある

◇登壇者C
・人はかえられることを嫌がる。変わるようなヒントを提示しないといけない

◇登壇者F
・だから先に聞く
・そこから「そこを僕は期待している」というと喜んでもらえる
　→その人のキャリアも含めてモチベーションを上げていくことを考える

◇登壇者C
・どうしても合わない人もいると思う

◇登壇者A
・みんな人間なので、そこは信頼関係
・相手が困っていることを助け、信頼してもらうことを繰り返し、関係を築く
　→そうすると、こちらがやりたいことができるようになる

◇モデレータA
・チームにコミットしてもらい、チームとしてプロダクトにコミットしてもらわないといけない

◇モデレータC
・作るべきフェーズがとっくに終わってるのに、インセプションデッキが入って無いという話があったが…
→インセプションデッキはいつ作ってもよいもの


◆アジャイルをやると問題が早く見つかって早く対処できるという。本当に？

アジャイルで見つかるものも見つからないものもあると思うが？

◇登壇者C
・アーキテクチャの根幹に関わるようなもので、ちょうど見つからない問題があった
　→アジャイルはコミュニケーションを活発にする手段
　→→チームでは活発的になって、その中で出るような話題は見つかる
　→その隣のステークホルダー、想定しきれなかったユーザの持っている問題は見つけられない
　→→→それで酷い目にあったりする
・コンセンサスが取れていたというところで思い込みがあった
　→それはアジャイルどうこうというより対話のミス
　→そういうものはアジャイルでも取れないよ？

◇モデレータC
「その問題はなんで見つかったの？」

◇登壇者C
「リリース前に想定していたユーザに話をしたときに突っ込まれた」

◇モデレータB
「ポイントポイントでデモしてなかったんですか？
顧客プロキシにはデモしていたけど、顧客にはしていなかったってこと？」

◇登壇者C
「そう」

◇登壇者A
「前向きに捕らえたらリリース前に見つかったという話では」

◇登壇者C
「そうだけど、そのときに作ったひずみで今苦労しているという」

◇モデレータB
「アジャイルで早く見つかるものとそうでないものがある」

◇登壇者A
「今のケースは早くフィードバックを貰えたからいいのでは？」

◇モデレータB
「今のはウォーターフォールでも同じでしょ？」

◇参加者
「逆にアジャイルだからこそ見つからなかったことって？」

◇登壇者B
「アジャイルでは問題がイテレーションごとに解決される。
お客様が暗黙に期待してしまうことがある。
いつか何とかしてくれるでしょ？という」

◇モデレータB
「それはプロダクトバックログの運用ミスのような気がする」


◆参加者
「新しく機能が発生したゆえに、前の問題が出てきたことは？」

◇登壇者A
・ジャストインタイムで機能を提供していたときがあった
　→増改築の繰り返していた
　→何ヶ月かあとにアーキテクチャが破綻した

◇モデレータA
「それはじっくり設計したら回避できたパターン？」

◇登壇者A
「どこかでリファクタリングしていればどうにかなったと思うが、ある程度大きくなるとどうにもならない」

◇モデレータA
「リファクタリングしていればなんとかなった？」

◇登壇者A
「傷は浅かったと思う」

◇登壇者C
「リファクタリングし損ねたのと、アーキテクチャが破綻していたのは別」

◇モデレータA
・リファクタリングっていうのは、ご飯があふれているかきっちり詰まっているかの話でしかない
　→そこに入らないものはそもそも入らない

◇登壇者F
・今のような事例が起きたら、まずチームに問題があったのでは？と考える
　→案件やチームによって、その事態の重要度は違う
　→自己組織化が基本なので、それはチームで答えを出してもらって次に生かしてもらうようにしている
　→→要はチームの力不足
　→→本当は隣の人にも気をつけないといけなかった
　→→それはウォーターフォールでもアジャイルでも変らない
　→→ならどうして最初から考えられなかったのか？というのを促す


◆モデレータA
「チームの力で解決できると言う話であれば　…すごいチームなら何でもできる？」

◇登壇者F
・精鋭が集まればウォーターフォールでもアジャイルでも何でもできる
　→だから、問題にチームでアプローチし、チームなりに答えを出してもらう

◇登壇者D
・早くお客に見せていて気がついたことがある
　→コンサルのいうとおりに作っても、お客に「違うよ」という風に言われる
　→→コンサルの方向とお客の方向は違う
　→→アジャイルならそれを拾っていける

◇モデレータA
「実はコンサルが言っていることが正しくて、ユーザが間違っている場合があると思う。自分の中でユーザ側に倒した理由は？」

◇登壇者D
「お客様の声がすごい強かった」

◇モデレータA
「確実に地獄行きでも？」

◇登壇者D
「そこは取捨選択した」

◇モデレータB
・どのくらいの地獄かによる
→マイルドな地獄なら行かせる
→会社がやばくなるなら絶対とめる

◇モデレータD
「アジャイルかどうかと問題が早く見つかるかはあまり関係ないような気がする」

◇登壇者E
・アジャイルじゃないと「問題が見つからない」と言って隠す
　→アジャイルだと隠しようがない
・今までだと（作成中に）必要だとわかっていても、その時点ではやらなかった
→そのまま作って、使いにくくなってからやっていた
→アジャイルだとその段階で手を入れられる

◇登壇者D
・けっこう頻繁に聞けたときはあまり炎上しなかった
→結局、コミュニケーションがとれてないと駄目


◆ウォーターフォールについて

◇モデレータA
・ウォーターフォールはある時点での幸せな話
　→後で本当かどうかは誰にもわからない
・ウォーターフォールで違ったら、また滝を流せばよいだけ
　→そこでとめてしまうというのがそもそもの原因
　→→スパイラルで回せば解決するのでは？


◆ストーリーは必要になったら詳細化すればよいというが、そもそも詳細にしないと分からないことがあるよね？ということについて

◇参加者
・ユーザストーリのときは詳細に分析するなというが…
　→普通の人の場合、具体的な画面や例外ルールを見せて初めて気付いてくれることがある
　→→詳細な分析をして始めてユーザが受け答えできるという話
・詳細な分析をしてみないと、アーキテクチャに関わるような問題が見つからない場合がある
　→そこは難しい？

◇登壇者A
　→→それはリスクをどうヘッジするかと言う話
　→→→やったことがないというリスクを最優先にするか、価値を最優先にするか

◇参加者
アーキテクチャに関わるところはリスクだから最初にやろうということ

◇登壇者F
・平鍋さんが言っていたこと
　→ショートケーキを小さく作るのと同じで、アーキテクチャも本当に薄く作っていく
　→それでうまくいくのではないかと思ってやっている
　→アーキテクチャもアジャイル的に育てていっている

◇参加者
・ファウラーも「アプリもアーキテクチャも同じ人がやっていないと分厚くなる」言っていた

◇登壇者F
・チームでコミュニケーションできるようにして、横のつながりを作っている
・3週間枚に集まってアーキテクチャやフレームワークを入れていってもらっている


◆モデレータA
「アジャイルを始めるにあたっての最初の問題は？」

◇登壇者E
・ベロシティが0だった
・ストーリが大きすぎた上に、何をしたらいいのか分からない状態だった
・そこがわかってからはよくなった

◇モデレータC
「それは問題？見つかってよかったね？」という話では？


◆モデレータD
「誰も興味を持ってくれないとかは？」

◇モデレータD
・飲み会でうんというまでやるとか
・力を見せるとか
・最初から全ては使えないので一部分だけ使って効果を見せたり
・早く帰ることができるようにしたりとか

◇登壇者D
・名前で言うと拒否られるというのはあるんじゃないかな
　→アジャイルと言う名前を出さないときはよかった
　→アジャイルといった瞬間に「えー？」と言われた

◇登壇者C
・朝会が長いと言うのがある
　→チームにしゃべる人がいると長くなる
　→→個別の状況に入ったりとか
　→→→そういうときはきらないといけない

◇参加者
「それってファシリテーションの能力では？」

◇登壇者C
・そういう人がいるとわかっていても、結局長くなる
・的確な時間に収めるというのはやはり難しい

◇参加者
・朝会の問題は、毎日進捗会議をすることになってしまうということ

◇参加者
・朝会のあるある　…集まらないということが多い

◇モデレータB
・特定の人がいないと集まらないとか

◇モデレータA
・最初に席をたつ人はいつも同じとか


◆モデレータA
「振り返りとかで何かないですか？」

◇モデレータA
・問題を人に落とすというのがある
　→チームではなくて、犯人探しになるとか

◇登壇者F
・KPTがどんどんたまっていった
　→何をどうしたらいいか分からなくなったことがあった
・問題には新鮮さが必要
　→3週間前の問題なんかだんだん忘れてしまう

◇モデレータA
・賞味期限を決めて自動で捨てる人もいる

◇モデレータB
・アクションがないからそうなる
　→Doneの定義がないとなりがち

◇登壇者B
「KPTに何かアクションがとれなくて、ただの愚痴になる状況がある」

◇モデレータA
「制度と会社と仕組みのせい」というのが最初は出がち

◇モデレータB
・そういうのが多いのはもう組織の問題
・チームで拾えないものはマネージャが拾わないといけない
　→こんなこと無理だろうなと思って出てこなくなることの方が怖い

◇登壇者A
・顧客不在
・担当の方が日常業務を持っていて時間をとれないとか
・POが業務知識が薄かったり倒れたりして、来なくなったことがあった


◆そもそもアジャイルをやるスキルがない

◇？
・ペアプロでいいのでは？
・そういうのをやりたがらない文化がある

◇モデレータA
「空気を読んだり、気にしたらダメ」

◇登壇者C
・アジャイルをやるときのチームの意識を一定ラインに保たないとダレる
　→自分の中の人の規律を守らせないといけない
　→守らなかったからって明確なペナルティがあるわけではなくて、緩やかにダレていく
　→→そこでスクラムマスターが欲しいと思う。


◆モデレータB
「個人のバイオリズムもあるのでは？」

◇登壇者C
・気が乗らないとかそういう心理的なものを維持するのは本当に難しい
・でもそれができないとどんどんダレる


◆登壇者A
「だれる原因は？慣れとか？」

◇登壇者C
・自分自身のチームへの責任感をどこまで取れるか
・無理をするというのはアジャイルではない
　→確実にやれる範囲をやるというのはあるが、そこに甘えるとどんどん下がっていく


◆モデレータA
・それは期待マネジメントでは？
　→いつも真面目じゃなくていいのでは？

◇モデレータA
・これらは別
　→アジャイルやるぞ！というテンションの時のオーバーコミット的なもの、それがが落ち着いている
　→単にだれている

◇登壇者D
・ベロシティを計測していたら、見積もりも苦しまずにすむようになった

◇登壇者C
・やれる範囲の見込みがあがった

◇モデレータC
・見積もりの精度も上がった


◆モデレータA
「ベロシティって伸びてる？」

◇登壇者D
ちょっと伸びてるかもしれない

◇モデレータA
伸びてるならいい

◇登壇者D
・残業していないので、けっこう自習する時間がとれていろいろ見えてくるというのがある


◆参加者
「チームのベロシティの上がり具合というのは？」

◇登壇者C
「CI、ユニットテストを明確に意識してくれるようになった」

◇登壇者A
「もうちょっと進むとプラクティスがあるのは当たり前になる」


◆モデレータA
「お客様の変化ってありませんでした？」

◇登壇者B
・アジャイルをやったらフィードバックが早くなった
　→お客様がなんでも言うようになった
・聞き分けもよくなった
　→今まで見たいな無理押しがなくなった

◇登壇者D
・お客様とコミュニケーションを取っている
　→お互いに言いやすくなって信頼関係が築けるようになる

◇登壇者E
・メンバーが明るくなった
　→今まではもくもくとやっているだけだった
　→手が空いたら他の人を手伝ってくれるようになったり、活発になったような

◇明るくなったメンバー
・なんか明るくなったねって言われた
・「進んでこれやったらもっと楽になるのに…」というのをやるのに抵抗がなくなった
・やってもいいんだという気付きがあった

◇モデレータA
・前の会社でカスタマサポート向けの仕事をしていた
　→その仕事を何のためにやっているか、お客様の誰も知らなかった
　→お客様にプロダクトバックログを作ってもらった
　→→そうしたら、お客様が「最終的に会社の業績を良くするためには？」と考えるようになった
　→→→それはすごくよいと思った
　→→→これが最終形だと思う







アジャイルサムライ読書会 横浜道場事務局の皆様, モデレータの皆様, パネリストの皆様、ありがとうございました。

『アジャイルサムライ読書会 新宿道場#10 - トークセッション』ノート

2012/09/01に開催された『アジャイルサムライ読書会 新宿道場#10』のノート。これは前半のトークセッションです。やはり、マスターセンセイの体験から語られる言葉は一味違うというか　…私とは経験値が圧倒的に違うということを痛切に感じました。

何年か後に読み返したときに、今とはまた違った角度から読むことができれるくらいに経験を積んでいきたいと思います。



◆トークセッション

◇マスターセンセイ

・西村直人氏
・角谷信太郎氏


◇質疑応答

※「」がついている発言がマスターセンセイのものとは限りません。ご了承ください


Q. アジャイルやりたい人の転職率の高さは何か？

A. アジャイルはチーム開発。チームでないと始められない

「1人でペアプロしている時期もあった。少しずつ回りを巻き込めたが、本を読んでいるうちにもっと速いペースでやりたくなった」

「「あの人とやりたい！」か「会社を変えたい！」のどちらのパッションがあるかで行動が変わる」

「会社を変えることにパッションがある人もある。会社を変えるのはまた別のパッションということ。自分はそうではないので会社を変えた」



Q. 転職したらハッピーになれるのか？
Q. 転職してすぐにハッピーになれるのか？

A. 自分が転職したときは「アジャイルやってないよ？」といわれた

「客先常駐の仕事ばっかりだった」

「社内の勉強会、プロジェクト間での情報交換などをやっていた」

「アジャイルなプロジェクトはなかったので、アジャイルにできるところは勝手にアジャイルにして始めた。カンバンとか朝会も勝手に始めた」

「現場は少しずつよくなっていった。自分達のやり方が認められることはあったが、それでも変わらないことはあった」

「そのうち、二重にやることの限界が分かってきた。途中から「自分達で仕事を作るぞー」と集まってどうやって契約を取れるかを集まってやった」

「自分で客を取ってまで仕事をするぞ！という人が多かったので、勝算があるとは思っていた」

「売り上げのことは必ず言われる。数字さえ取れば文句は言われない」

「東京は手ぶらできたので色がなかった。自分達で開拓できた。「今までやっていた」ものがなかったのでやりやすかった」



Q. アジャイルって儲かるの？

A. あまり儲からない

「（アジャイルコーチは）いなくてもできるようにするのが仕事なので難しい」



Q. アジャイルの利点は適正なお金で働けること。儲かりすぎたらいけない。と聞いていたので安心した

A. もうちょっと儲かりたいとは思う

「食べられるかというと　…なんとか食べられる」

「もらえる額が決まっている場合、長期間働かされるのでしんどいが、アジャイルはやっただけなのでそこはよい」

「ただ、終わったらそこで終わりなので…」



Q. アジャイルってエンジニアのマインド・スキルが重要だという意識があるが？

A. チームでできるようになっていればかまわない。チームのスキルセットが偏るのはよくない

「スキル重要と呼ばれていく現場は、だいたいレベルが低い（アジャイルをやる以前で、そもそものスキルが低い）」

「お客に価値を届けるという人が多ければ価値をとどけやすい」

「今できない人もプロジェクトの中で学んでいけばいい」

「それは上の人がどれだけ関わるか。成果を出すためにどうすればいいか考えてくれれば結果が出る」

「集めてスクラムやって、だとそこそこの成果しかでない。」

「みんなにアジャイルの価値観がなくてもできる」

「最初は違っても、実際やれば化ける人がいる」」

「縦でスライスして動かすやり方を知り、今までとは違うやり方で成果が出せると気付くと変わる人いる」

「ユーザーからのフィードバックがあると、やっている方も面白く感じる」



Q. キャリアが与えられるものから自分で作るものとなってやる気が出るのか？

A. そうかもしれない

「チーム振り返ってもらうと「仕事の幅・視点が広がった」というフィードバックが多くもらえる」



Q. 与えられるものへの認識が"苦痛"から"もっとやりたいもの"へ変わるというところもあるか？

A. 何がヒットするかは人による

「押しても引いてもだめだという人もいる。絶対変わりたくない人もいるけど、それは100人に1人か2人。だいたいは（度合いはあるけど）順応できる」



Q. 仲間がいないとつらいというのがある。そこへのアドバイスは？

A. やりたい人がいるところに行くのがよいのでは？　一番お勧め！

「プロジェクトの進め方などについては話合うが、そもそも仕事をどうすべきか？ということを会社で普通に話すことはない（飲み会はともかく）。そのような会議体はないし、定例で行ったりもしない」

「言わないだけで考えている人はいる。送別会で「実は…」と切り出す人がいたりして「おいおい！遅いよ！」となることはある」



Q. 失敗談とかありますか？

A. 「なんとかうまく行ったけど、もう一回やれば（もっと）うまくいく！」というのはある。（そういう意味では）失敗ばかりしている

「お客さんの期待をコントロールし、どこまでできるか理解してもうことは重要」

「きちんと踏み込むことも重要」

「リリースにあたっての重要人物や本当の目的などのTough questionも重要」

「"安請負"や"やれると思ってた"で失敗することが多い」

「お客様から言われたことをただやれば価値になると思っていた時もあった」

「「ツールがこうしろと言っている。だからこうする」というのは駄目」

「ツールのせいにしたり、手順を強要したりするのは駄目」

「失敗をアジャイルのせいにするのはよくない。プロジェクトは1回しかないので、何かのせいにするしかないが…　でも、そういうところはアジャイルでなくても失敗する」



Q. ?

「今までの仕事のやり方とは変えていかないといけない」

「昔からある会社は（昔から）違うやり方をしているから、（変化を）やりづらくなっている。大きい組織なら少しずつ変えていくしかない。」

「組織のとしての理解・サポートが重要」

「決める人と作る人の距離を近くしないといけない」



Q. 書類を求めるような、「がちがちに作ってあるから変化に対応する必要がない」と、言っている現場にはアジャイルは向かないと思うが？

A. 「変化しない、タスクがぶれない、要求がぶれない」というのであれば無理してやらなくていい



Q.  テストが実装工程の後にあるプロジェクトの場合、テストファーストで書いていると（バグ発生率などで）困ってしまう。どうすれば？

A. 自分達が書いたテストを後工程でまとめて資料にする

「ついでに既に書いたテストを整理するのもよい」



Q. 大事な要素が後になって判明して大変なことになることがある。どうすれば？

A. わかってから着手すればよい。

「全部決めるのは難しいが一週間なら決められるよね？というのがアジャイル。先のことは難しいという話。フィックスしたものを作ればよい」

「逆はWBSの「先の話は見切ったー！」という話。でも三ヶ月後なんてわからない」

「考えたり、アイデアを出したり、というのも普通にストーリーに入れたりする。あやふやなものを細かくちぎってストーリーにするのが正しい」

「『ふわふわしたものをただ「アジャイルに」とやってもうまくいかない。ただそれはウォーターフォールでもアジャイルでも同じ」

「ユーザはストーリを書けない。それでは価値を計測することもできない。お客様のほうに説明することも大事」

「いったん小さくてもいいから決める。それに対して追加・変更を行う」

「ミニマムでも完成させれば、それは使えるものなので、そこにたいして追加・変更をもらう」

「「できません」とは言わない。「やるけど、できる量は決まっているのでどちらにしますか？」とする。それが変化に対応するということ」



Q. ?

「詳細設計が終わってドキュメントを作っても、結局やり直すことになる。引き継ぐならただ読むだけならだめで、その後ろにあるものも理解する必要があるから。「製造して」とドキュメントを渡されても、製造側は結局全部やることになる。」

「製造フェーズで全部やり直すことがあって、それを詳細要件定義と呼称したことがあった」



Q. ドキュメントをどれだけ作る？

A.  必要なものは作る

「中の人はほとんどドキュメントがいらない」

「お客などに毎日会う環境はいずれなくなる。自分達以外の誰かに引きつぐときにドキュメントを残す必要がある」

「ユーザに合わせて作る」

「全部作るかと言うとそうではなくて、減らせるものは減らせる」

「ドキュメントを書くかわりに、（動作を理解するための）スクリプトは全部作る、というやり方もある。そういう場合、こちらから自信をもって説明することが必要」



Q. 後から入ってくる人向けのドキュメントは？

A. 毎週入ってくるなら作る

「聞いたほうがドキュメントを作るのは良いプラクティス。ドキュメントができあがるので、教える側にもメリットがある」

「何が判らないのか、教える側には分からない。だから聞いた側がドキュメントを作る方がよい」



Q. その日のうちに作ってくれと言う現場があって、そういうところだとエンジニアには無限の負荷がかかる。ユーザ側から見た品質も悪い。そういう現場で人間らしい働き方をするためには？

A. まず見える化

「物凄い量の仕事が来ていることをきちんと見せる。あからさまにおかしいという状況を見せれば、口答えできる」

「退社時間や睡眠時間の見える化も有効」

「見せれば偉い人の誰かが気付く。気づかないなら、それは…」



◇その他

「イテレーションの運営の話について、アジャイルサムライの206ページにしれっと大事なことが書いてある」

「"昨日のテレビの面白いこと"と同列で"アジャイルをやりたい"では誰も信用しない。やはりパッションが必要」

「意外と学習効率って悪くて、学ぶには時間がかかることに気をつける。業務時間外に勉強会などに参加して学んでいる人と、たまたま隣の机に座っている人。使っている時間が全然違う」






西村直人様、角谷信太郎様、tmmkr様、tk0miya様、eji様、ありがとうございました。

アジャイルサムライ読書会 新宿道場#4

2012/03/31に開催された『アジャイルサムライ読書会 新宿道場#4』のノート。


今回の範囲は次のとおりです。

・第9章　イテレーションの運営：実現させる

・第10章　アジャイルな意思疎通の作戦

・第11章　現場の状況を目に見えるようにする


3チームに別れ、上記範囲内で話し合いたいことをそれぞれ決定し、ワールドカフェを行ないました。
以下はワールドカフェの成果物であるチーム毎の発表と模造紙を書き起こしたものです。



～発表～

1. チーム　ギロッポン

アジャイルな分析は何をどこまでやればいいかというテーマについて。

■第1フェーズ

・分析は『やりたいこと = ゴール』を決めるもの

ウォーターフォールの場合は一番初めに全部決めるが、アジャイルの場合はその時点でやりたいことを決める。言い換えると、WFは固定でアジャイルはスナップショット。

・『分析 = 要求をまとめること』という話

この点においてウォーターフォールとアジャイルは同じように見えるのだが、やはり違いがある。

モックはアジャイルとFWでは観点が全然違う。ウォーターフォールのモックは、それを作ることは設計を作ることである。やることをびしっと決めてしまう。アジャイルではあくまでもある時点でユーザが欲しいもののスナップショットである。より深く掘り下げるための材料として作っている。

■第2フェーズ

・アジャイルのメリットとデメリット

メリット ： 変化に強い。

デメリット ： エンドが見えない。なので契約ができない。

・局所最適化

アジャイルでやるとどうしても視野狭窄に陥りがち。選択するストーリーの順番によっては局所最適が発生してしまい、全体から見た場合にイケてない、ということが起こる可能性が高くなる。これは事実なので注意していかないといけない。

局所最適化の有無はストーリーの選択にかかってくる。つまり、局所最適化を避ける為には優秀なプロダクトオーナーが必要。

・アーキテクチャジャンプ

機能面・技術面からアーキテクチャジャンプが発生する可能性がでてくる。アーキテクチャジャンプに対しては、リファクタリングを行うことでリスクが低減できるかもしれない。アジャイルでやる場合は絶えずアーキテクチャジャンプを意識している必要がある。

また、アーキテクチャジャンプは、増大したエントロピーを下げる為に発生する。なので、エントロピーを上げないようにストーリーを選択する必要がある。

なお、ウォーターフォールは一番初めに全て決めているのでアーキテクチャジャンプは起こりえないらしい。個人的には絶対そんなことないと思う。

■第3フェーズ

・BDDをもっとしりたい、という話

BDDは仕様（やりたいこと）を決めたあとで、受け入れテストを書くものだという話を聞いている。

で、TDDとBDDは本質的には同じだ、という話になり、BDDとTDDの組み合わせでやれば一番いいのではないか、ということになった。

2. 運用島


大きく分けて二つの話題があった。

■朝会のメリットって何？

朝会のよくある話として、ただ進捗報告会になってしまうというのがあるが、そういう朝会は無駄である。

朝会には、みんなでプロダクトを作る、チームを固めていく、というメリットがある。
また、個人で抱えている問題を他のメンバーがサポートする、というメリットがなければならない。

これをやるためには他の人が何をやっているのかというのをちゃんと意識していくことが必要である。


■レトロスペクティブを上手くやるには？

KPTをいきなりやれと言われてもなかなか出せないもの。
そういった人を巻き込むにはどうしたらいいか。

守破離でいうところの守の部分をやってもらおうというのが第一歩として必要なのでは？
強制的にKPTをやらせてみることが必要で、ルーチン化してしまってもいいので、とりあえずやってみよう、と。
慣れてくれば、トライに対してフィードバックをディスカッションする、ということをやっていけばいい。

それを繰り返していくうちに「自分達が変わった」という実感が得られるはず。
そういった実感（ゲームでレベルが徐々に上がっていくというような間隔）を得ることができれば、自分達からレトロスペクティブをやりたいなという気持ちになるのではないか。



3. 宇宙チーム

『カンバンにおける情報共有・同期の方法』『見える化を持続するための取り組み』というテーマを中心に話しあった。


■カンバンの鮮度

カンバンを使っていても、皆が進捗を実績どおり頻繁に必要なときに更新してくれるわけではない。

こういう場合は朝会で共有するのがよい。今日・今週・今後やることをデイリーで更新し、毎日の朝会で進捗報告することで持続させられる。朝会以外では全く更新しない人も、朝会に対してなら更新してくれるだろう。


■タスクの粒度やふせんの色などによる見える化

タスクの種類でふせんの色を分けることで見える化を進めることができる。

・どれが滞っているか

・時間がかかっているか

・何か優先順位で待ちになっていてまずい

など。

『agile do it!』でスクエニの事例が発表されていた。


■待ちカテゴリがあるとよい

待ちの原因をふせんで分かるようにすることで、相手を気遣うという事例があった。

「自分のタスクが終らないと、彼は何もできないんだ」と思って、そのタスクの優先順位を上げて作業してくれたことがあった。

なので、待ちの優先順位をわかるようにするとよいのではないか。


■ゲーム感覚

ふせんをToDo, Done, Doingと動かすことでゲーム感覚を得られる。Excelにはそれはない。

Doneに近づく = ゴールに近づいているということが意識的に感じられるので楽しくできる。


■タスクの粒度

ToDo, Done, Doingなどで、タスクの粒度についてチームで合意していることが大切。


やっている人はタスクの粒度は半日から1日、長くても二日、短くてもせいぜい一時間と思っていたが「30分単位でタスクをきりたい」という人がいた。



ふせんの粒度はタスクの管理コストと相関する。『ゲーム感覚』の話で言えば、タスクは細かい方がいいのかもしれないが、管理コストについてチームで認識していることも重要。


■カンバンとモチベーションの話

カンバンについて自分の仕事を自分で選ぶことができればモチベーションがあがる。

終ったものリストを作りDoneをそこに集める、どれだけ作業したかを説明できるし、やった仕事が溜まるのでチームのモチベーションになり、よい。



■カンバンとバーンダウンチャート

カンバンとバーンダウンチャートを一緒に表示しておく。イテレーションの中はカンバンを見ればいいし、総残量はバーンダウンチャートで見ることができる。



■カンバンを使うメリット・デメリットをチームで共有した方がよい

メリット・デメリットを説明した上で、使うか否か・どのように使うかをチームで共有し合意を得る。
そうすることでカンバンに対する拒絶反応を減らし、楽しくできるのではないか。


■進捗を取り繕うという話

チームの空気が悪くなるので犯人探しをしない。
イテレーション中はやることに集中する。
振り返りの時に『チームとして』なぜ遅れたかという原因を把握し『チームとして』今度どうするかを決める。
チームをコントロールすることが大切で、誰が犯人であるという話ではない。


■質疑応答

Q. 遅れた原因について教えるところのコストをどう考えるか？

A. 最初に教えることで得られるメリット・将来性を考え、見込みで教えるべきか否かを考える。


Q. タスクの粒度の基準は時間という話だったが、重要度によってはたとえ30分であっても切る必要があるのでは？

A. チームで合意ができていれば30分のタスクを切ってもよいのでは。







～模造紙～

1. チーム　ギロッポン

■アジャイルな分析は何をどこまでやればよい？

□実装まで。でもウォーターフォールとはタイミングが違う

□分析でやりたい事（ゴール）を決める！

□分析って？
◆ユーザーストーリー
◆やりたいこと

□今はユーザーストーリーを出してユーザに見せる
◆全部始めにやった
◆最初にまとめてやったのは失敗だった？

□（アジャイルな）分析の定義は？
◆要求を決めることなんじゃない？

□メリット：変化に強い。デメリット：エンドが見えない。契約できない
◆局所最適化？
◇ストーリーの並べ方にコツがあるのでは
→どう予見？　回避は？

◇優秀なPOが欲しい。必要だよね！

□BDD
◆振る舞い駆動
◇Rubyが強いぜ！

◆RSpec
◆TDD
◆懇親会で！

□アーキテクチャジャンプの話
◆こまめなリファクタリング

□（アジャイル）受け入れテストを書いてから設計する(P.19)

□モックの意味
　ウォーターフォールにおける→固定
　アジャイルにおける→スナップ

□ウォーターフォールの場合は現行を全部調べる
◆アジャイルでは作るところだけ分析。ウォーターフォールは全部やってしまう

□ウォーターフォールでもモック作ってやってたけど？
◆アジャイルのとどう違う？
◇ウォーターフォールは全部作る？
→作って仕様を決めきってしまう
→設計書を作るためのもの

◇アジャイルは荒く作る
◇作ったモックを思い切って捨てるかどうかがアジャイルとの違い？
→小さく作っておかないと、捨てにくくなる

□ウォーターフォールの場合は全部決める→固定
　アジャイルの場合はその時点でやりたい事を決める→スナップ

□ウォーターフォールもアジャイルも根本的には「分析」は同じじゃね？

2. 運用島


■朝会のメリットって何？

□個人のかかえている問題を他のメンバーがサポートできればメリット
◆それをやるには他の人が何をやっているのかをちゃんと意識しないとダメ
→かんばんとかで共有するとかいいかも

□チームを固める

□「みんなで作る」チームにする

□アジャイルでなくてもできるのでは？

□ただの進捗報告会は無駄。役割分担を明確に
◆イテレーションゼロで固める

□「裸の王様」リーダーへのアプローチ
◆どうしても話が通じなければリーダーの上の人にアプローチ


■ふりかえりのときにだんだんとルーチン化してしまう。レトロスペクティブをうまくやる方法は！

□ルーチン化でもいいからまずやってみる。慣れてきたらディスカッション
◆「変わった」という実感が得られればいい。
→マイナスをゼロにするKPTからゼロをプラスにするKPT


■「建設的」にフィードバックする言葉
　※話の持っていき方はどんなものがあるのか

□（意見を）出せない人を巻き込むには
→とりあえず強制的に出させる

■？

□まず下のメンバーで結束
→そこからチーム
→リーダーをうごかす

□『人の動かし方』カーネギーのが参考になった

□「傾聴・否定しない」というルール決める
→でもリーダーの役割のことが多い
→打診するときに「メール＋即口答」

■その他

□チームを分割して全員が話してタスク化する。重要

□朝会は偉い人が話す場合、あまり意味がないように感じる

□朝会では2～3分/人。話し込んでしまって失敗したなぁと感じる

□リードの人（スクラムマスター）が集まる打合わせは毎日あるが、20人規模

□振り返り→KPT→振り返り…
◆（KPTで）アウトプットはできる
◆どうフィードバックにつなげるかディスカッションできれば
◆改善していく”体感”って大事

□アジャイルな意思疎通
◆ウォーターフォール/アジャイルに関わらず必要。

□KPT
◆サイクルを作る
＝re・input
◇tryを実行するのが重要
→かえられるという実感
→みんなから意見しやすい雰囲気

◇振り返りの振り返り
◇なぜうまくいかないのかを話あう

□他のチームが混ざって混乱したことがある
◆無関心を作らない雰囲気作り
◆内職したい人がいたら負け

3. 宇宙チーム

■カンバンにおける情報共有・同期の方法
　"見える化"を持続していく為のとりくみ
　カンバン向きのプロジェクトとは？
　カンバン・ストーリーボードって本当に貼り出さなくても使える？

□進捗をとりつくろう組織で使えるか？
◆助け合うというマインド
◇和の文化

□タスクはふせんの色で種類分け
◆「待ち」カテゴリを作る
◇待ちの原因をふせんで分かるようにしたので相手が気遣ってくれたりした

□タスクを書き出す→思いっきり忘れられる

□タスク：ふせんの色で粒度をわけてカンバンに貼る

□ストーリーをタスクに細分化する
◆ふせんの色を変える

□自分の好きなタスクを自分で選ぶ（モチベーション）

□（タスク）1日1日、個人で振り返りをする

□（タスクボード）できるだけ時間を使わずに管理できるようにする

□終わったリストが必要

□周囲の人達にタスクボードの説明をしておくといい

□今週・今日・将来をデイリーで更新→持続させやすい

□ふせんをリズム良くうごかしてテンポよくしていた。ゲーム感覚

□ゲーム感覚 vs Excel管理

□タスクボードをスクエニは上手く使っている
◆スライドをwebで見られる

□ToDO, Doing, Doneというタスクの粒度をチームで合意することが大切
◆管理コストをチームで認識を持つ

□カンバン
　・ライフハックの延長
　・プロジェクト管理というよりタスク管理
　・タスクの消化をゲーム感覚に

□フィーチャの実装はイテレーション。保守運用業務はカンバン
◆イテレーション中のわりこみ業務？
◆カンバンでフィーチャ実装　…見積もりは？
◇見積もりにバッファ持っておくしかない？

□カンバンを使うメリット・デメリットを共有しよう

□カンバンでタスクを終えるとゲームのような感覚になる

□カンバンとバーンダウンチャートを一緒に表示しておくといい

□カンバンは、一旦完成したものに対しての追加・修正に向いている？

□割り込みタスクとカンバン
　・緊急レーン
　・余裕を持ったアサイン

□フィーチャ開発はイテレーションがあってそう

□フィーチャ実装と運用でタスクの種類が違う？

□バグ・デフィーチャは別次元から差し込んでくる
◆バッファを持っておくしかない？

 □アジャイル→守破離


□犯人探しをしない。チームとしてどうするか
◆チームをコントロールすることが大切

□朝会で共有

□アジャイルは哲学だ！