Skip to content

Readingagilesamuraiinsapporo20110818

irasally edited this page Aug 18, 2011 · 9 revisions

第2回読書会

  • 2011年8月18日 19:00-21:00
  • エスプランニング開発室
  • 参加者 14人
  • 第2章〜

第2章 アジャイルチームのご紹介

2.1 アジャイルなプロジェクトはどこが違うのか

  • アジャイルなチーム
  • 実際全てをそつなくこなせる人っているのかな
    • そんなにいないよね・・・
  • みんなでやったらどこかぬけちゃう、忘れちゃうとかないのかな
    • この本のチームの考え方は究極論
      • 周りの作業を分担するという気持ちでよいのかな
  • いきなり知らない人とはチーム作れない
    • 強みと弱みがはっきりしない
    • ちょうど今日新しいチームができて「何ができるか」を話し合ったところ
    • 偏愛マップを使ったよ
  • ここに書かれているアジャイルチームは一握りのとてもうまくいっているアジャイルチームだよなぁ
    • こうあるべきだとは思う
    • 理想はこの形
  • 成果責任
  • アジャイルじゃなくても「成果責任」を果たしているよ
    • 他は「成果責任」を果たしていないように読めたけどそんなことはない
    • 「チームで」成果責任を果たそうとする態度、と言っているのかな
    • 「品質保証部門の~?」のくだり → これは縦割りの悪い例
      • 責任の押し付け合いになっている例
    • Googleは役割分担がはっきりしているが責任を押し付けあったりしていない
      • お互いをプロフェッショナルとして認めているから「ここは自分の責任範囲外だ」となることはない
  • 契約上成果物に対して責任を果たしてはいけないこともある
  • 責任を持つことと、責任を果たそうとする心構えというのはちょっと違う
  • 責任を分かち合う=価値を作り上げる、共有する ことで生まれる喜び
    • アジャイルじゃなくてもできることもある
  • 成果責任を果たそうとすることはアジャイルじゃなくても大切なこと

2.2 チームをアジャイルにするためのコツ

同じ仕事場で働く

  • 同じ仕事場で働いている?
  • チームに「顧客を含む」と不可能に近い
  • 全員が集まれるだけの旅費を確保する
  • 現実離れしている・・・
  • まずそれができない
  • でも後のことを考えると「全然安いもの」だと思う
  • キックオフに予算を取るの大事
    • 上司の説得が大変
  • 一度も顔を見たことのない人と仕事をするとなんとなく「仮想敵」ができてしまう
  • 誰か一人でも顔を見てればちょっと雰囲気が変わったりする
  • 同じ仕事場にいてもうまくいかない場合もある
  • 詰め込み、軟禁状態で横のつながりがほとんどない・・・
    • (コワイ)
  • DBが現地にしかなくて後は分業
  • バグが発生した時に部署たらい回し
  • これって組み込みだけ?
  • Webでも同じような(ガチガチの)形態の場合はある
  • 中の人は大事
  • 最初に関係を作るためには顔を合わせるのは大切
  • Skypeでのやり取り
  • 最初から信頼関係があれば不便がない
    • ホワイトボードがないのは不便
  • ペアプロはリモートでもできる(リモートスクリーン)
    • Screenの共有
    • 離れているのに近い!
  • ただ、もともと知っていた事が大事
  • ソーシャルツールの制限ってないの
  • Skype禁止は多い
  • Messenger系禁止とか
    • 仕事のやり取りよりも「情報漏えい」を重要視している
  • かくれて(ry
    • 成果を出して次から導入OKされた
  • IRCいいよ!
  • IRCでやり取りをしていると初対面でも違和感無かったりする
  • 今だとtwitterがそれに近いのかな

積極的に深く関わる顧客の存在

  • お客さんがプロジェクトに関わる
  • 一番難しい
  • 犯罪的なプロジェクトに関わっている人 → 多数
  • エンドユーザーと対話したことがない
  • 一個だけできる良い方法
  • 自分がほしいアプリケーションを作る
  • 自分が顧客になる
  • 社内システムもユーザーがとても近い
  • ヒアリングとか色々できる良い環境
  • ブラッシュアップもできるし
  • 遠方のお客さんにリーダーを立ててもらい、定期的にMTGをする
  • 1年経ってやっとできるようになった
  • 「やばい」となってから体制が整備されてきた
  • 最初から上手いこと創り上げていきたいね
  • アジャイルじゃなくてもお客さんの参加は大事
  • 「日々一緒に働く」というのはイメージできない
  • フィードバックを返してくれる
  • 物理的に一緒の場所にいるということではないんじゃないかな
  • 「待ち」がない環境
  • 実は顧客だけが「アジャイル」であってもうまくいくんじゃいかな
  • ガチガチのウォーターフォールでも、お客さんがすごく口を出してくるプロジェクトはうまく回りそう
  • ソフトウェアを発注するということは「深く関わらなければいけない」という覚悟が必要なことということを顧客も意識しないといけない
  • 発注をうまくするなにか、ノウハウが広まったらいいな
  • 大きな会社の「システム部門」というのは顧客と近い環境
  • プロジェクトに対する危機感がある
  • 業務の違い、業態の違い
  • お互いに相手の事がわからない
  • 理解しあわなければいけないけどなかなか歩み寄りがない
  • 信頼貯金
  • 「人」と「人」との関わりとして
  • この人に開発をお願いしたい
  • そのソフトウェアは本当に必要か?
  • いらないものを売りつけている ということもままあるよね
  • スクラムオーナー認定試験
  • 誰が受けるの?
  • コンサルとか監査とか
  • 高望みしすぎて結びつかない合コンみたいな
  • 現実的には「どれだけお客さんを巻き込めるか」につきるよね
  • お客さんマターのことはチケットを全部お客さんにアサインする
    • 意識するようになるお客さんもいる
  • お客さんを巻き込む => 自分から飛び込む
    • 自分から向こうに出向いて「お客さんと一緒に仕事する」という意識
    • 現場を見る
  • プロジェクトによってはこれはとても大きな壁(セキュリティとかセキュリティとか)

自己組織化

成果責任と権限移譲

職能横断型チーム

2.3 よくある役割分担

2.4 チームメンバーを探すコツ

Clone this wiki locally