ReadingAgileSamuraiInYushima20110727
湯島道場では範囲は第一部としたものの、章ごと節ごとの読み合わせや議論は行いませんでした。
むしろこの本を通じて思ったこと、感じたこと、日々困っていることなど一冊の本を通して生まれたコミュニティで、深く、温かく共有することを目的としました。
ダイアログが深まるよう、座談会の前に2つのLTが行われました。
nohdomiさんのLT：『アジャイルを始める前に』
ShiroKappaのLT：座談会テーマ
座談会で語られたことをまとめます。
『これからアジャイル開発を始める人にはずいぶん現実的じゃないか？もっと理想が前面に立っても良いのでは？』
・でもあまりに概念的過ぎるとかえって分かり辛いよね
『アジャイル開発の導入しますって事で、最初から【不確実】って感じで言うとお客さんに伝わりにくい…先が見えないとじゃぁ他のところに頼もうかってなるし…』
・アジャイルについて書かれてる本って大体やっぱり不確実なところからスタートする
『でもアジャイル開発のすごい夢を感じた！』
・現場に近い内容だから、実現の可能性も高いって思うよね
・実際だとある種の政治的な理由で導入が遅れたりってケースもある
(ex：上司の間違ったアジャイル開発に対する拒絶反応)
『実際に本に書かれてる【金額固定の契約だったらどうするの？できなかったら殺すよ？】って事は実際にお客さんに言われた』
・やっぱり顧客の理解って言うのが一番重要だと思う
・顧客も巻き込むのが一番良し
・実際、顧客にアジャイル開発を導入するって言うと大体【納期遅れるんでしょ？】って言われる
・2週間のイテレーションでも心変わりするんだから、半年後だとどうなるの？ってスプリントレビューで言ってみた。
・逆に、じゃあ半年後にはどこまでできてるのよ？って、突っ込まれない？
・勘、経験、度胸(KKD)で当たるも八卦、当たらぬも八卦をしてきたのだから、ギャンブル性としては変わらないよって返してみたら
『顧客のアジャイル開発に対する期待値って高くない？』
・その期待値をマネジメントするようにすればいいよ
・期待値のコントロールって難しいな…
・顧客は将来的には必要ないだろってものでも、現時点では絶対にいるって言うし
・終わってみたら使ったものの6割も使われてないとかね
・だからハードルを上げ過ぎるって言うのも辛い
・でも下げ過ぎると、どっか別の会社に…って事で他の会社に持って行かれてしまう
・奇跡なんて起きないって事をまずは理解してもらわないと
『そもそも顧客がどういうものが欲しいかとかを整理できていない』
・その為のプライオリティ付けとか
・段階的にどうやって作って行くかを向こうにイメージしてもらわないと
・顧客とのそういう時間ってなかなか取れない、向こうが忙しかったりして
『お客さんが時間取れないとかありえない』
・お客さんが協力しないとその時点で打ち切るってケースもよくあるよ
・後は、使われてない機能これだけありますよね、とか具体的な数字を出すと効果的だよ
・でもそれって海外の話じゃんｗなんて言われる
・大きい意味でのトレンドってのはそんなに変わらないよ、むしろ日本の方が五年も遅れてる
・日本の場合は発注者が責任を負わないケースが多いし、なんでもいいので作る事が重要で、予算を消化できればよい、とか。
『お客さんが見えないとなかなかアジャイルをやろうとかなりにくいね』
『最初の内はプラクティスの一部だけでもいいから導入していくとやりやすいかも』
・原則とかは抜きにしてプラクティスだけって言うのもね…
・間違ったアジャイルってのが広まっていく危険性もあるし
『最近だとお客さんの方からアジャイルをやりたいって話でスタートしてる仕事もあるよ』
・ユーザー企業にとってもアジャイルは広まりつつあるんだ
・となると後は持って行き方！
・でもそうやって受けた仕事でもうまくいってないケースもある
・振り返りが全然出来てないとかで、内容の理解の薄いまま始めたのも原因っぽい
『モノが欲しいのに見積り取りやすいとかカッコイイ稟議書欲しいとか、結局そういうの求められるよね？』
・見積ってあくまでも見積じゃん
・稟議書もあくまでも見積の稟議書
・不確実性のコーン
・見積と契約って全く別の話だよね
・そういう理解ってなかなか得られないんだよなぁ…
『でもそんな状態でそんなの受注して幸せなの？って思うわない？』
・体壊したりとか絶対分かってるのに、それ分かってて突っ込んでいくのってどうなんだろね？
・メンバーにはそういうのやって欲しくないじゃん
『ベンチャーとか小さい会社だとその仕事受けないと潰れちゃう！ってなっちゃうよ。そういう場合どうするの？』
・それも不確実性のコーンだよね
『お客さんの方もアジャイルやると何もできないんじゃないかって恐怖もある』
・アジャイルでやったら全部成功するワケじゃない
・プロジェクトを止めるケースだってある
・失敗が早い内に分かってそれを回避できてるじゃん。それって成功だよね？
『アジャイル開発のチームって選べる？』
・実際にやってみてもあまり自発的に動かなかったりとか…
・いや、実際やってみると育つよ！
・実際コマンドコントロールで12年間枠からはみ出さないようにってやってきたけど、取り入れてみるとチームで何とかしないとって責任感も出てくるし、チームもやらされている感が無くなる。チームの責任感も変わってくる。上から下へのピラミッド構造だったのが逆転するんだよね。誰か遅れてる人がいればチームの問題だし、チーム全体で解決すればそれはチームの学びになるよ
・うちも実験的にアジャイルを入れてみた
・例えば名前を付けないタスクボード導入してみて、最初はまごついてたけど、その内自主的にやるようになったし
『共有する事が重要だよね』
・うちの開発メンバーは元々チームが違うところから集まった。コンテキストだってバラバラだし、情報の共有なんてできなかった。当然うまくいかないよね。ユーザーストーリーの見積もりだって皆バラバラだし、そうしてる内に皆が不安になって、じゃぁ何が原因なんだろうって自発的に集まって、とにかく何が問題になっているかを皆出した。で、皆でその問題を解決すれば自然と情報の共有だってできるし、当初の差もなくなって見積もりの精度だって上がったよ
・当たり前の事ができてないって場合の方が多いよね
・だから業務時間内のタイムボックスをカッチリ決める。うちの場合は1日に1時間30分のコマを3つで区切る。メンバーはペアで作業する。4人でできるって事は1日でまんべんなく全員のメンバーとペアを組む事ができる。情報共有だって早いし、誰かが休んだってカバーできる。それを徹底してやる事で一体感も生まれる
