Readingagilesamuraiinbiglobe20110829

アジャイルサムライ読書会　BIGLOBE道場　第1回

読書範囲：第1章～第2章

アジェンダ

• イントロ
• チェックイン
• 穴埋め問題
• ワークショップ

　　（休憩）

• フリートーク
• チェックアウト

チェックイン

• いろいろ勉強させてもらいたい
• 一人で読むと一人の視点になるので、いろいろな人の視点を知りたい
• 勉強会も始めてなので、いろいろ吸収したい
• がんばって今日の午後本を読みました

アジャイルサムライ穴埋め問題

文章が本当に伝えたいことを感じるのじゃ

• 本当に大事なことそれは、「動く」ソフトウェアを「定期的」に届けることだ。
• プロジェクトの途中で何かを捨てなきゃならなくなったとして日々の「テスト」だけは疎かにしちゃいけない
• だから「計画」を乱すような「現実」に遭遇したら、「計画」を変えるんだ。「現実」を変えるんじゃない。
• アジャイルに開発するというのは、これまで経験したことのないほど強烈な「スポットライト」を「浴びて」るみたいな感覚だ。
• やるべきことがあまりにも多すぎるという事態に直面したらどうするか。そのときは、やれることをやるだけさ。つまり「やること」を「減らすん」だ。
• 「チームの生産性を劇的に改善できる方法をひとつだけ挙げろ」と聞かれたら、間違いなくそれは、全員が「同じ職場に集まって」働くことだろう。
• 「役割」に人を合わせるのじゃなくて、人に合わせて「役割」分担を決める
• 3つの真実

　　１. プロジェクトの開始時点にすべての「要求」を集めることはできない

　　２. 集めたところで、「要求」はどれも必ずといっていいほど変わる

　　３. やるべきことはいつだって、与えられた「時間」と「資金」よりも多い

• 自分たちで判断し、自分たちが正しいと思うことを実行できるだけの「権限」を与えること。そうすればチームは自発的に自分たちのやり方で物事を進めていく。。。
• プロジェクトを成功させる唯一の方法は、「開発チーム」を成功させること

ワークショップ

以下のテーマについて２チームに別れて議論

テーマはこちら。

• 要件定義がうまくいかない理由
• チームをアジャイルにするコツ

アジェンダ

• 一人ずつ話す
• テーマについてディスカッションする
• 各チームでの議論の内容を発表する

チームをアジャイルにするコツ

• 空気を読むのがコツだ
• 質問をして真実を得られるようにすればいいのでは(質問することで考えることを促す)
• 自己組織化というキーワードがポイント
• 自分たちでその時々の状況を判断して行動していくチーム
• 一人じゃ組織じゃないよね
• 自己組織化するためには、集まる、みんなのために動く、みんなのやっていることを見ていく

質問

１．自己組織化ってなに？

火事が起きたときに、何をしますか？というときに、上司にどう消しますか？と聞くのではなくて、自分で考えて火を消す、というような感じ。

２．自己組織化以外のキーワードは出た？

気持ちの話、ウォーターフォールを捨てる、みんなの能力を把握する、コンセプトを理解する、

要件定義がうまくいかない理由

• 開発会社との距離がある
• 要求者の要求が伝わってこない
• 要求元とひとつ屋根の下に集まればいいが難しい
• 組織の壁を超えた役割（PO,SM）→お金の問題もある
• 改善していかなければいけないポイント
• 責任分界点がある状況が行けない
• BPなんか無理
• アジャイルの前提として計画なんてあってないようなもの
• 組織改革が必要！

質問

１．見えない要求のコントロールが難しい。見えない要求ってどうしてる？

BP示すことは難しい。ゴールを決めることが必要。 ゴールをもとに、一つ屋根の下で作業を進めればうまくいくのでは。 まずは、たくさん話しをすることをやりたい。

要求元が本気でない場合、忙しくて話をしてくれない場合。

２．ステークホルダーがすごくがんこな人な場合。要件多いが、期間短い。どうすればいい？

信用を置かれていない場合は、細かく信用度を積み上げていくアプローチ。 飲みに行く。 我々のチームはこの問題を解決できていると思う。 この考え方を共有していくべき。

フリートーク

• 読んでも抜けてしまう
• 読んでみて、失敗したプロジェクトと照らし合わせてみると、納得感がある
• 頑固で強烈な顧客の前に行くと、できることをやることも精神的に難しい。それはどうこなしていけばいいだろう。
• 開発環境って大事。Buildが１０分で終わること、とあったけど、３時間かかったプロジェクトがあった。
• いまの本の知識があったら、どう立ち回れたか
• アジャイルサムライを読めば、読んだ人が全員解決するのか？
• 解決する部分もあると思う
• 最初にやることを決めて（合意して）いれば、強烈な顧客にも対応できる
• 自分のところしか見えてない部分があって、要件定義のような部分まで見えてなかった。そのへんが課題だったかもしれない。
• いきなりすべてをアジャイルにするのは無理かもしれないから、できるところからやるのがいい
• 組織の壁をどうするか、責任や予算の線引きがあったりする。
• あえて、役割分担を明確にしない、というような考え方を会社組織でやるのは、重大な決断。やりきれるのか、それが課題。でも、何とかしてやりきりたい
• スクラムでは、チームにある程度権限が移譲されている感じがする。
• 見積を全員でやる。スタート地点で、共有できる。
• プロダクトオーナは見積に参加するべきか？優先順位付けなどでいたほうがいい。
• いままで、IT業界の経験が無いけど、本を読んだ時に、当たり前のことが書いてあるじゃん、と思った。
• アジャイルを広めようとしたときに、上の人たちは、ウォーターフォールで成功体験があるから、説得できない
• ドキュメントを最小限しか作らないというのが、受託開発とは違う。官公庁系など。。。
• お客さんと対等な立場でお話ができるのがやりやすい。

チェックアウト