Scrum Gathering Tokyo 2011 カンファレンス(10/19)参加レポート

 ツイート 6  シェア 0  Hatena 0

puzzle-piece

Scrum Gathering Tokyo 2011 カンファレンス(10/19)に参加してきました。

残念ながら公演のすべてを理解しメモに残すことはできませんでしたので、印象に残ったことを私の言葉に置き換えて記事にしました。

私の技量不足により、講演された方の意図とは違う解釈をしている部分があると思います。ご了承ください。

目次

  1. Henrik Kniberg 氏の講演
  2. Jeff Patton 氏の講演
  3. Yahoo! JAPANにおけるアジャイル開発、スクラムへの取組み
  4. 国内導入事例

Henrik Kniberg 氏の講演

Everybody wants Change, but nobody likes to Be Changed
(Change ~ 組織の特性に合わせた、アジャイル導入の勘所)

アジャイルの導入に際して、変化を嫌う組織や顧客を説得するには

  1. まずは自分自身の言動を変えるところから始める。
  2. 他人を変えることは非常に難しい。
  3. 変化に対するゴールと目的を明確にする。
  4. 抵抗は変化の影響を受ける人から発生する。抵抗を最小限に抑えるには、抵抗の原因を知らなくてはならない。
  5. 現在の状況・問題点を指摘し、解決のための具体案を提示する。
  6. 報酬を与えて変えさせる方法は長続きしない。変更を強制してはいけない。

6歳の子供に自発的に部屋を片付けさせるにはどうすればよいか、を事例に説明がありました。子供が目の前にいることを想像して、自分ならどうするか考えてみると面白いです。

興味のある人にやらせてみる

  1. 変化に興味がありそうな人を見つける。
  2. 全面的に支援する。
  3. プロセスを見える化する。
  4. 上手くいっているのが見えると他のチームも真似したくなる。

新しいことは、興味があって勢いのある人に走らせてみるのもよい方法です。うまくいった、楽しそうにやっていることを「見える化」することが大事ですね。

うまく行かなかったら元に戻す

一回やってみて、うまく行かなければ元に戻せばいいという思考でやってみる。

スクラムが合わないプロジェクト・組織・顧客は存在します。
都度改善していけばよいと思います。

問題の見える化

「問題の見える化」の効果について、モチベーションが下がっているチームが立ち直った事例の紹介がありました。

モチベーション低下を問題として見える化したことで全員の意識が変わり、問題を解決するにはどうすればいいかを考えるようになったそうです。なかなか興味深い事例でした。

問題解決へのステップ

  1. 妨害事項のトップ3を上げてもらった。
  2. トップ3に上がったものは必ず解決すると決めた。
  3. 簡単な問題はすぐに解決された。難しい問題が残った。
  4. 残ったのは、モチベーションが上がらないという問題。
  5. 仕事をするモチベーションが上がらない理由を上げてみた。
  6. そうしたらいろんな変化が起きてきた。誰が問題を解決しようと働きかけるわけでもなく、全員が問題解決にあたるようになり、楽しそうに仕事をするようになった。
  7. 問題を見える化したことで全員の意識が変わった。

Jeff Patton 氏の講演

Us them and the problem with Scrum
(プロダクトマネジメント情熱教室 ~ スクラムにおける「私たち」と「お客様」の関係を見直そう)

システムの要件は顧客が出すものではなく、開発者が一緒に考えるもの

今回の公演全体を通して一番心に残った言葉です。

システムは共同して制作するもの。
顧客と同じ言葉を話し、同じ認識を持つことが大事。

システムの要件は顧客が出すものではなく、開発者が一緒に考えるもの。

私が顧客と要件について打ち合わせをしている時に、「どう作ればいいか聞くのではなく、もう少しこちらサイドに寄って提案してください」と言われたことを思い出します。

この認識をプロジェクトメンバー全員が持っていると心強いです。

ロールではなくポジション

スクラムでは全員が基本技能を持った上で、その人が最も力を発揮できるポジションにつけばよい。

  1. 全員が平均的な能力にならなくても良い。基本技能は持っている必要はあるが。
  2. 各自が得意な能力を発揮できるポジションにいて、周りの動きを見ながら進めればよい

Yahoo! JAPANにおけるアジャイル開発、スクラムへの取組み

アジャイル導入のステップ

  1. アジャイル開発が大切にする考え方を説明、起こる変化を想像してもらう。
  2. 興味を持った人に対して導入を促していく。
  3. 会社、コーチが開発中の支援を全面的に約束。
  4. コーチはすべてのミーティングに顔を出し、ルールや考え方を何度も教え、それを守ってもらう。
  5. 課題を問いかけ、解決方法を自分たちで考えてもらう。
  6. 習熟してきたらコーチは振り返りのみの参加とし、状況を大雑把に把握しつつも自分たちでやらせる。適時アドバイスを送る。
  7. 任意にいつでも撤回可能。
  8. 強制的にやらせようとしない。

スクラム導入の理想型といえるのではないでしょうか。
武道でよく言われる「守破離」の考え方ですね。

手法

  1. スプリント計画ミーティングはワークフローによる承認制。
  2. タスクと進捗は壁で。能動的に見に行かなくても状況が目に入る。
  3. チームは物理的に集合させる。

スプリント計画ミーティングが承認制になっている点は参考になりました。
タスクボードはエクセルで管理するのではなく、見えるところに置くものだと思います。

国内導入事例

導入事例、体験談の共通点をまとめました。
大きな組織でも小さな組織でも、スクラム導入の効果を同じように感じています。

導入効果

  1. コミュニケーションの活発化。意見がどんどん出る。
  2. やるべき作業が明確になり、全員で共有できる。
  3. スプリント毎にふりかえりをやるので体制が継続して改善されていく。
  4. 外から見ていて楽しそう。他のチームに飛び火する。
  5. 人が育つ。
  6. 導入して数ヶ月で自己組織化の兆候がみられてきた。

導入の手法

  1. コーチに支援を依頼。
  2. トップダウン。
  3. 興味のある人をあつめて試験導入。
  4. 影響力のある人を集めて導入促進チームを作った。

ボトムアップよりトップダウンで導入したほうがうまくいく傾向があるように見えました。

終わりに

稚拙なレポートでしたが、最後まで読んでくださってありがとうございました。

参加された皆様、協力会社様に感謝申し上げます。

 ツイート 6  シェア 0  Hatena 0