Agile Day参加レポート(1/22 マイクロソフト)

 2010/01/23

1/22(金)にマイクロソフト社で実施されたAgile Dayのセミナーに行ってきました。 いつものように知った顔が多かったりします。スーツ比率は半々くらいかな。年齢層は20代前半、40代後半以降は少ない感じで、会社の現場を回している中堅~マネージャクラスが多かったのではないかと思います。 3月と6月にまたAgile Dayが開催される予定とのことで、個人的にはお勧めイベントだと思うので、興味のある方は是非。

マイクロソフト長沢さんのセッション

アジリティを向上させるためにマイクロソフトが行ったこと

主にマイクロソフトにおけるAgileへの取り組みや現場の回し方、体制等について事例を発表されました。 僕がAgileについて外部に研修するときに、Agileへの取り組みが進んでいる企業の一つとしてマイクロソフトをあげているけど、流石という感じ。

話の内容をいくつか抜粋。

  • Tech Fielderの取り組みについて説明。得てしてベンダー側はカタログスペックや美辞麗句を話がちになるところがあったり、セールストークになりやすいけれど、そうではなく、現場の人の経験や意見、技術を発表してもらい、共有する、というのを目指しているとのこと。マーケティングの手法としても、利用者の成功体験や口コミは大事だしね。
  • マイクロソフトでは、Scrumのプロセスを取り入れて開発を進めている。(以前Agile Conferenceでも聞いた)
  • 利用しているツールはTeam Foundation Server。残念ながら僕は利用したことが無いので機会があれば触ってみたい。
  • IBMのRational Team Concertと同様に、プロセステンプレートと呼ばれるものを利用して、Team Foundation ServerでScrumのようなプロセスの利用を可能にするとのこと。なお、プロセステンプレートはCodePlexで公開されているらしいので、既にTeam Foudation Serverを利用している人は評価してみると良いのではないか。是非結果とか教えてほしい。
  • マイクロソフトにおけるTeam Foundation Serverの利用事例は増えており、Team Foudation Serverの開発チーム自体でも開発中のTeam Foudation Serverを利用している。eat your own dog foodの原則通り、人に提供する前に自分たちで使っている。やはり自分が利用者になると色々な点に気付くことが多いから、普通のシステム開発をしている人も、もし自分が利用者だったらどう思うのか?という点については良く考えると良いだろう。
  • Visual Studioの開発の際は、新バージョンの開発に入る前に、既存の不具合・問題を4か月かけて片付けた。壊れた、もしくは品質に問題のあるコードベースへの機能の追加は将来に負債を抱える結果となるので、このアプローチは非常に重要。
  • 標語でいうと、Get Clean, Stay Clean。綺麗な状態にして、それを保ち続ける
  • マイクロソフトでの開発チームは、職能による物理チームに横櫛を通したバーチャルチームで構成する。チーム内での進め方は、共通のルールを守っている限りチームの自主性に任される。
  • Visual Studioでは、1スプリントは6週間に設定されている。レビューとしては実施計画レビューと実施結果レビューを行う。
  • 開発はチームごとにブランチを切って実施
  • 品質のチェックはQuality Gateという17のチェック(静的解析、コードカバレージ等)で定点チェックされ合格しないと出荷できない

三井さんのセッション

開発現場でのムダ取り・改善活動

岐阜と東京を行ったり来たりして、Agileの普及や実際の開発現場の支援をされている三井さんのセッション。前回聞いたのは昨年後半にIBMで行われたセミナー。相変わらずパワフルな印象。50歳過ぎて現場のスクラムマスターを続けているというのは尊敬するし、その経験の蓄積が顧客からの信頼の源泉なのだと思う。セミナー開始前に食事をご一緒させていただいて、趣味もパワフルということが判明(笑)

主なところを抜粋。

  • ソフトウェアにおいて全機能の65%が利用されない、またはほとんど利用されない、という調査結果があり、作りすぎのムダがある。
  • 作りすぎのムダを無くすためには常に有言実行の行動が必要である。
  • 頭脳労働においては一人の担当者を固定すると、思考停滞等の無駄が発生する。
  • ムダを改善するスタイルとしては、二人ひと組の作業チームを組んで決められたタイムボックスの中で作業するのが良い。(XPにおけるペアプロを業務におけるコーディング以外の部分にも適用してしまうという風に理解)
  • 作業チームによる作業は効率が良く、生産性は倍になるケースも。頭がフル回転して思考停止しないので、非常に疲れる。それ故にそもそも残業が少なくなる。
  • 作業チームを作る場合は、中間管理職の意識改革が必要で、チームが自発的にやるようにしないといけない。
  • 見積もりゲーム→ペアプロ→ローテーションで、チーム内の仕様認識を統一できる。「ソースコードがきれいなら」詳細設計書はいらない。
  • 作業の見える化が必要。始める前の見積もり時間と実績時間を記録する。粒度は細かい方が良く、三井さんのチームでは0.25時間単位とのこと。自分のチームでは0.5時間単位で、10を超えるような大きいタスクは分割する習慣。当たり前のことかもしれないが、仕事の中身への理解度が高い程、タスクの粒度は細かくなる傾向にある。
  • 改善活動は常にやり続ける必要がある。止めると陳腐化する。
  • Agileを本だけ見てその通りにやるのはうまくいかないことが多い。
  • 会議では、チームの悩みをどんな小さなことでも出せるようにすることが必要。それがリスクの見える化になる。
  • 振り返りがチームの意欲を引き出す。
  • Agileを経験した人はWFに戻っても効率が高い(自分はコミュニケーションパスと頻度の違いと理解)
  • CMMIやiso9001とAgileが合わないという意見もあるが、そうではない。CMMI5は自立したチーム。

ebackyさんのセッション

あなたにとって、アジャイルとはなんですか?

ebackyさんらしいセッション。以前Shibuya.tracの勉強会に来た時と同じパターン。参加者に考えさせる機会を与えて、色んなキッカケにしている。

  • Agileとは何?という質問を繰り返して、ちょっとずつヒントを与えながら参加者に考えさせる。
  • (ちなみに僕にとってのAgileは、「お客さんに最大の価値を提供する、チームを幸せにする、勤務先の会社に利益をあげる、これらのための道具」です)
  • Agileの押しつけはその時点でAgileでなくなってしまう危険がある。けれども学習の段階では時に盲目的にプラクティスに従ったほうが良いこともある。
  • 我々がやるべきことは、Agileが本当に意味するところを「説得」するのではなく「説明」できるようにすることだ。
  • Agileの探究は良いけれども、とにかく、「現場や開発チームから目を離さない!」ということを大事にする。
  • あきらめずに「戦略的なtry & errorを繰り返す」ようにする。
  • AgileはPeople Oriented。

ライトニングトーク

僕もちょっと話して来ました。アンチパターンの紹介と言って良いかな。 僕が言いたかったのは、チームの自立性を維持するためには、周りの人(特に力を持っている人)にAgileを誤解させないような努力が必要だ、ということ。日本の受託型SIやコンサル→開発の案件において、プロジェクト開始時点でチームに関係ない外的要因によって失敗の可能性が増えてしまう、というのは避けたいし、そうならないようチームが努力するべきなんだと思う。

僕がお話した内容

個々の内容については、マイクロソフトのサイトにしばらくした後掲載されると思う。

  • アジャイル開発 まずは社内の誤解に立ち向かえ(←僕)
  • TDD ってどんな感じ? ~ FizzBuzz を作ってみる
  • アジャイルソフトウェア開発現在進行形

僕個人のまとめ

僕は自分自身が他の会社の人にAgileを教える立場なんだけど、長沢さん、三井さん、ebackyさんの話のストーリーに感服でした。 押しつけじゃなく、自分たちの経験を伝えていて、それは銀の弾丸では無いんだけれども、参加者の共感を確実に得ている。 認知→共感→実行のプロセスを経て、参加者が何かを実行できる土台になっていた。 プラクティス自体はそれはそれで素晴らしいんだけど、押しつけでなく、自分達が良い、と思って実行できる環境づくりが大事なんだと改めて認識。

その他

LTで投票結果が1位だったとのことで、色々なグッズを頂いてきました。長沢さんありがとうございます。

  • Windows7のロゴ入り手帳。この間Windows7入れておいて良かった(笑)
  • Visual Studioのロゴ入りプランニングポーカー!。これで上司に見積もりゲームやってても、何トランプやってるんだ?と言われなくなります(そもそも言われませんけど)

  • Windows7のバッチ付きポーチ
 2010/01/23

著作

寄稿

Latest post: