Readingagilesamuraiinsapporo20110818

第2回読書会

• 2011年8月18日 19:00-21:00
• エスプランニング開発室
• 参加者 15人
  • web開発の人、組み込み系の人、バリバリ人月契約の人、社内SE、などの開発者が参加しています
• 第2章〜2.3途中まで

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

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

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

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

同じ仕事場で働く

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

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

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

自己組織化

• 人に合わせて役割分担を決める
• それってある程度アタリマエのことなんじゃないのかな、向いている人に向いているものを合わせるのが
  • 向いているものに向いている人を合わせているのが多い
• ここで言っているのは「自分がこれをやるよ」と仕事を自ら取ってくること
• トップダウン（役割に人を合わせる）事が多い
  • 「自分これはできるよ」と言えることが少ないから
  • 「これやって」と言われることだけを「こなす」ので精一杯のメンバー
• チームで自分たちの組織を良くしていく、というのはいいなと思う
  • 「Agile Conference tokyo 2011 マーチン・ファウラー氏の基調講演 http://www.publickey1.jp/blog/11/21agile_conference_tokyo_2011.html
    • プロセス駆動じゃなくて人駆動
  • ある程度いろいろな方法を知ってぐるっと回って今がある
    • 一つの方法に縛られるのではなくて色々な手法を知った上で螺旋状に上昇していくのがよいよね

成果責任と権限移譲

• 許可が降りるまで待たない
  • ・・・なんてことしたら大問題になることもある
• 自分の責任で見積もりをやることって大事
  • 自分たちが納得した数値に対しては意識するようになる
• 「刺身にたんぽぽをのせるだけのお仕事」
  • 原書は「野菜を切る」
  • オリジナルは日本？外国？

職能横断型チーム

• ジェネラリストやスペシャリストが「ひとりでもいる」チームっていうのが贅沢
  • チームメンバーを見つけよう
  • 人のリソースが足りないところでどう回すかの解決策がなかなかない
    • 作ればいんじゃない？
    • 見つけるのと作るのと、どっちが大変なのかな
• ジェネラリストやスペシャリストを育てるのが難しいよね
• この本には「教育する」「育てる」という観点がない
  • 学ぶという意思がない人はこの本を読んでいない前提
  • 勝手に育っていく読者が対象
  • 対象をある程度切り捨てている
  • 「意欲に満ちた人を集めて」というのが原則だもんね
  • そういう意味で対象読者に求めるものは高い
• Webと組み込みでの「ジェネラリスト」の需要の違い
  • 組み込みだとこの言語だけできればいい、パッケージだと仕様もだいたい同じ -> でやっていけてる
    • 10年同じ所とか
    • Webだと違うのかな？
  • Webだと選択肢が色々広い
    • 「とりあえずいろんなことがそこそこできる」人は重宝される
    • 引き出しが多様すぎるジャンル
  • 組み込みも知らなければいけないことは多いよね
    • 言語というよりはハードのほうで -> マルチコアとか
    • 結局新しい知識が必要だよね
  • 変化の要因はWebの方が多いよね

2.3 よくある役割分担

アジャイルな顧客

• 顧客
  • Agile Customer
  • 「客」お金を払ってものを貰う というイメージが強い
    • ユーザー、利用者という意味があまりない
• 文化、価値観の違い
  • 海外のお客さんとの仕事（組み込みの事例）
    • 要求はすごく曖昧
    • トライアルでどんどん作っていく
    • 本当に中の中まで知りたがる、口を出したがる
    • 発注元の人がどんどんテストをする
      • 本当にほしい、必要なものに関わっている人が多い
    • 曖昧、フィーリングで話をする、使ってみてブラッシュアップしたいという要望が多い
    • 逆に旧来的な日本のプロジェクトと摩擦が起きることも
    • 海外の75%はAgile的な開発をしている？という数字もある
  • 誰が使うかわからないものを作るなんて無意味なことはない、自分が使いたいものを作るのが一番 （Dropbox作者のインタビュー）
• 自分が変わるしかない
  • お客さんの懐に飛び込んでいくしかないよね
• 開発側とお客さんとの信頼関係
  • 信頼関係を築けていないと双方に損なことがあるよね
    • お互いに信用していない
      • 顧客ははっきりした数字や根拠を求める -> 開発側の作業が増える
      • 開発側は顧客がこれから仕様変更や困ったことを言ってくるのではないかと思う -> 予算のリスク係数が跳ね上がる
  • お客さんがほんとうに欲しいのであれば、開発側がお客さんの不安を解消してあげるとよいよね
    • 不安なのはお客さんの方
    • 安心してまかせてほしい
  • お客さんがソフトを発注するのではなく、自分の家を買うのだったら？ -> もっと真剣になるんじゃないかな
  • 信頼貯金大事
    • もちつもたれつをすることで、新しいビジネスが生まれることもある
    • もちつもたれつでズブズブになることもある（前回サービスしたんだから今回も、みたいな）
  • 理想と現実
    • 現実は厳しい
    • 「代わりはいくらでもいる」になったらおしまい
      • 交換可能で誰でもできるようなプロセスとか、実際無理だと思う
      • 開発者の地位の向上
  • なかなか解決策がない
    • 小さな仕事を受けて、小さな仕事からやることでその体験はできるかも
      • 確実に内部のスキルは上がる
      • 欲を言えばそこから大きくなっていけばいいよね
  • アジャイルでやっている企業も増えている
• お客さんが優先順位を決められない「全部大事」-> 結局全部やらなければ行けないということがある
  • それは開発側が優先順位を判断する材料を用意しきれていないのでは？
  • コストやメリット、それによる価値をお客さんに伝えるのは開発側の仕事
    • どれがどれだけ大変なのか全くわからない
    • それをきちんと伝えることは開発者として大事なこと
    • 「簡単じゃない」と思って発注してくれるお客さんとは良い関係になれることが多い
  • その材料でお客さんが優先順位を決められるようにする

---

ここまででした。 次回は 8/30（火）にします！！！