Zusaar(告知)
http://www.zusaar.com/event/355105
ツイートまとめ(ゆかりんノート)
https://yukar.in/note/ckFkBf

「アジャイルサムライ横浜道場」は以下の書籍をターゲットとした読書会です。
![]() | アジャイルサムライ−達人開発者への道− (2011/07/16) Jonathan Rasmusson 商品詳細を見る |
今回は書籍を読むのではなく、特別編としてパネルディスカッションが繰り広げられました。
メインテーマ: 貴方のアジャイルとの関わり方
上記のテーマについて、以下6名のパネラーを中心に、スタッフと参加者を交えてディスカッションが繰り広げられました。
@tsuyok
@LascasM
@dproject21
@joker1007
@shin_semiya
@terahide27
以下、パネルディスカッションでの議論内容について、自分向けの覚書メモです。
1.方向付けをどうしていますか?
方向付けをどうやってますか?例えば、インセプションデッキとかチーム作りとか。
---
■まず、あなたはなぜここにいるのか?という話をする。
→ チームが進むべき道筋が合ってくる。
■ウォーターフォールでもアジャイルでも方向付けは必要。
■今何をやってて、何を目指していくかは、どんどん変わっていく。
なので、基本的に「振り返り」が大事。
「振り返り」で、何をしていかないといけないか、目指すことを決める。
■方向付けに失敗した。客が現状維持的な思想で、客の方向に流されざるを得なかった。
ただ、インセプションデッキでもいいけど、共有は大事。
■「やることリスト」と「やらないことリスト」を作る。
→ チームの方向付けで盛り上がった。(特に「やらないことリスト」で)
■まず、アジャイルを始めるときの約束を2つする。
・上司は、チームに対して口を出さない。
・上司からチームに、「こういう風になって欲しい」と伝える。
■最初の課題として、「チケット駆動ができない」というのがある。
→ チームに「守ってください」と言う。
■一人ひとりヒヤリングする。
・どういう風になりたいのか
・どういう風になってほしいのか
→ 明確にしておく。
■市場調査(顧客がやりたいことの調査)に手を抜くと、自分たちの考え(間違った思い込みもありえる)に倒れてしまう。
■方向付けは、システム部門がしてしまった。
→ ユーザからクレームが来た。
→ やはり、何のために作るのか、の目的が大事。
■押し付けられた目的に、100%の力を出すことはできない。
■同じ方向に向ける、というのには2つの観点がある。
・どこに向かせるのか
・どうやって向けるのか
■みんなが同じ方向を向いていない時、どうするか。
■土台がハッキリしてないから議論ができない。議論ができないから、バラバラになる
■関係者がお互いを知ることが重要である。
■エンドユーザを明確にしてからアプローチする。
→ 上司に対して協力を働きかける。少しずつ関係性を作る。
→ チームが、客が何を欲しがっているのかを自分たちで考え始める。
→ これが重要な点で、こうなったら勝ち。
■方向性を向ける対象(≒チームメンバ)のことを知らな過ぎ。
・各チームメンバーの年齢とか家族構成とか趣味とか。いつも何を考えて仕事しているのか、とか。
(ある人にとっては、早く帰りたい、というのが最重要と考えていたりするかもしれなかったり)
・同じ方法では、チームメンバ全員は同じ方向を向かない。
・メンバによって、向け方を変える必要がある。それには、相手のことをわかってないと、できない。
・チームメンバのことを知るために、何かやってますか?相手のこと、ちゃんと知ってますか?
・無理やり同じ方向を向かせようとしても、向かない。なぜなら、人は変えられることを嫌がるから。
・同じ方向を向くように、まずヒヤリングして、そこから方法を探す。
ヒヤリングして、相手のことを知っておく必要がある。
・同じ方向を向くためには、信頼関係を築いておくことが大事。
(例えば、手が空いたらチームメンバの仕事を手伝ったり、困ってる人がいたら助けてあげたりとか)
・信頼関係があると、同じ方向を向きやすくなる。
■インセプションデッキはいつ作っても良い。必要なときに作ればよい。
2.問題は早く見つかるのか?
「アジャイルをやると問題は早く見つかるのか?本当に?」というのが、スタッフミーティングで盛り上がった議題だったそうです。
---
■問題が早く見つからないことがあった。
・そんときは、エンドユーザが距離的に遠くて、直接ヒヤリングとかでずコミュニケーション取れてなかった。
・思い込みによる所、対話できていない所で失敗した。(エンドユーザの要望と乖離した)
・デモがPOレベルにしかできておらず、エンドユーザにデモできなかったのが問題だった。
■反復開発で増改築を繰り返し、徐々にアーキテクチャが破綻した。
・小さく小さくリファクタリングしていれば、傷は浅くなる。
・反復開発といっても、データモデルとはかきちんと決めておくことが大事。
■問題が出たとき、「チームに問題があるのでは?」とまず考える。
・答えは1つではない。なぜそうなったかを考えて、チームで答えを出すことが大事。
・プロセスの問題ではなく、チームの問題だと認識することが大事。
・完全なチームというものは無い。
・アジャイルは「振り返り」があって、そこで同じ問題を繰り返さないようにできる。
■ウォーターフォールだと、問題が見つかると隠蔽する。アジャイルだと、隠蔽がしにくい。
・アジャイルだと、常に情報がオープンになってるので、隠蔽できない。
・アジャイルは信頼関係が前提にある(ハズ)なので、そもそも隠蔽しようとしない。
・アジャイルは反復開発なので早く問題が見つかる。傷口が浅くて済む。
■最近はアーキテクチャを、必要なところから先に薄く作るようにしている。
(⇔ ウォーターフォールだと、厚くアーキテクチャを作り込む。)
アーキテクチャを作るチームとアプリを作るチームの、横の繋がりを強くしている。
3.最初の問題は何でしたか?
アジャイルをやってみて最初に遭遇した問題について。
これからアジャイル初めてみようと思ってる人にとって、最初にぶつかる課題というのは身近なテーマです。
---
■スプリントの期間を1週間にして開始したら、1週間では何も成果が出ず、ベロシティが0になった。
→ ストーリーの抽出単位がデカすぎたのが原因。修正したら成果が出始めた。
■誰にも興味を持ってもらえない。
・解決案1:
アジャイルやると「得する」と思ってもらえるよう頑張る。(成果を出して納得させる)
・解決案2:
腕を見せて、言うことを聞かせる。
(これは「腕(=腕力)で従わせる」と「腕{≒能力)を示して従わせる」の2種類の意味があると感じた)
■アジャイル用語(例えば「朝会」)を出すと拒絶された。
・「朝会」= 長いイメージ
・「朝会」「昼会」「夕礼」のような進捗管理三昧なイメージを連想
■朝会が長くなった。
・朝会が長くなると、進捗会議を毎日やってるのと同じ。
・朝会の話が長くなる人がいる場合、空気を読んで話を切る人がいないとダメ。
■朝会に人が集まらない。
・特定の人がいないと始まらない。
■問題をメンバに名指ししてしまう。
・○○のせいだ。
・犯人探し
■KPTが溜まり過ぎる。
・問題には新鮮さが必要。期限を決めて、期限が切れたPは捨てる。
・Pに対して具体的なアクションを決めないと、いつまでも残る。
・Doneの定義が重要。
■チームでアクションが取れない問題がある。
→ マネージャがアクションを取らないとダメ。(例えば、経営層や顧客のエラい人に話をつけるとか)
ただ、チームでアクションが取れない問題が頻発するようなら、それは組織に問題がある。
■顧客不在
・忙しくて時間を割いてもらえない
・POが業務知識を持っていない
■デキる人がいない
→ ペアプロとかで教えてあげて、デキる人を作る
■チームの意識を一定に保たないと、ダレる
・規律を守らなくなると、緩やかにチームがダメになっていく。
・規律を保つ専任のスクラムマスターが欲しい。。。
・モチベーションの維持が難しい。当然、気が乗らない日もある。
逆に、アジャイルをやってみて改善された問題はあるか?
■見積もりの精度が上がった。
・見積もりがブレることが無くなり、残業が無くなった。
■ユニットテストとCI(継続的インテグレーション)をメンバーが明確に意識してくれるようになった。
■「それはできない」と顧客に言っても、納得してくれるようになった。
・それまでに成果を出し続けて、顧客の信頼を得ていた。
・信頼しているチームが「できない」と言うのだから、妥当な理由なんだな、と納得してくれるようになった。
■メンバーが明るくなった。
・手が空いていたら、他の人を手伝ってくれるようになった。
■良いこととをやるのに、抵抗が無くなった。
・やってみたことに対し、メンバから「スゲー」とか、反応が返ってくる。
・以前は、良いことをやろうにしても、上司の許可とか、工数の捻出先とかばっかり気にする必要があった。
以上でパネルディスカッションのメインは終了し、いつものKPTの時間になりました。
その後の懇親会にも参加してきましたが、ここでも有意義なお話ができました。
懇親会でKPTの話をしたんですが、前回のKPTに今回のKPTを上書きで貼る、という話がありました。
自分の職場ではイテレーション最後のKPTで毎回新しい模造紙使ってて、前回のKPTを貼ったままの紙に
上書きで貼るってのはやってませんでした。これも有効そうなので、やらないといけないなぁ、とか思ったり。
いくつか気付きが得られて良かったです。
あとパネルディスカッションで「方向性を向ける対象(≒チームメンバ)のことを知らな過ぎ」という議題が
出てましたが、この一言は私にとって結構強烈な一言でした。
確かに、メンバとは普段フツーに会話してますが、相手のことをよく理解できているかというと、ぜんぜんダメです。
これは反省点として、もう少し相手のことを知る努力をしていきたいと思います。
今回も有意義な時間を過ごす事ができました。スタッフの皆様、いつもありがとうございます。
こーゆうイベント的なの、良い企画だと思います。これからも続けて欲しいです。
次回も楽しみにしてます。
- 関連記事
-
- 「第4回 スタートHaskell2」に参加しました
- 「アジャイルサムライ横浜道場 特別編 パネルディスカッション」に参加しました
- 「函数プログラミングの集い 2012 in Tokyo」に参加しました