• Save
Agile Day2 Agileな開発プロセスを導入するために考えなければならないこと
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Agile Day2 Agileな開発プロセスを導入するために考えなければならないこと

on

  • 3,233 views

2010/3/19にマイクロソフトで実施のAgile Day2のセッションの1つ。

2010/3/19にマイクロソフトで実施のAgile Day2のセッションの1つ。

Statistics

Views

Total Views
3,233
Views on SlideShare
2,807
Embed Views
426

Actions

Likes
8
Downloads
0
Comments
0

4 Embeds 426

http://www.ryuzee.com 370
http://blogs.itmedia.co.jp 47
http://www.slideshare.net 8
http://s.deeeki.com 1

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Agile Day2 Agileな開発プロセスを導入するために考えなければならないこと Presentation Transcript

  • 1. Agileな開発プロセスを導入するために 考えなければならないこと 2010/3/19 Ryutaro “Ryuzee” YOSHIBA. #msagile
  • 2. 2010/3/19 Agile Day2 自己紹介  Ryuzee / Ryutaro YOSHIBA.  ブログ http://www.ryuzee.com  Twitter ryuzee  TIS、野村総合研究所を経て、ベンチャーのCTO  専門はゕジャ゗ルに関する教育、ゕジャ゗ルなプロセス の導入支援、組織の生産性向上、Webシステム開発  Certified Scrum Master  オープンソースプロダクト開発者、翻訳者  Shibuya.tracのスタッフ 2
  • 3. 2010/3/19 Agile Day2 Disclaimer  本プレゼンテーションに記載した内容は発表者本人の経 験、見解によるもので、本人が所属する(した)組織、 団体の意見を代表するものではありません。  本プレゼンテーションの内容を用いた結果発生したいか なる事象について、発表者はなんら責任を負いませんの でご注意ください。 3
  • 4. 2010/3/19 Agile Day2 はじめに  「ゕジャ゗ル」という言葉  開発現場の上位層まで認知されてきましたが  一方でバズワード的に扱われて興味を持たれない  表面的な理解に基づいて現場に導入してうまくいかないと判 断される  という状況が多いのではないでしょうか?  このセッションではゕジャ゗ルな開発プロセスにおいて 考えなければならないことについて、特に「組織」、 「人」に焦点を絞ってお話いたします。 4
  • 5. 2010/3/19 Agile Day2 ゕジェンダ  ゕジャ゗ルの基本中の基本  ゕジャ゗ルな開発プロセスの導入の前に  経営者・上司へのゕプローチ  チームビルデゖング・人材育成  顧客へのゕプローチ  ゕジャ゗ルな開発プロジェクトのはじめ方  最後に 5
  • 6. 2010/3/19 Agile Day2 ゕジャ゗ルの 基本中の基本 6
  • 7. 2010/3/19 Agile Day2 ゕジャ゗ルの基本理念  ゕジャ゗ルマニフェスト  2001年に、ケント・ベック、マーテゖン・フゔウラー、ケン・ シュウェ゗バーら、17人によって採択されたAgileソフトウェゕ 開発の原則。  基本理念 人同士の相互作用 > プロセスやツール 動くソフトウェゕ > 包括的なドキュメント 顧客との協調 > 契約交渉 変化への対応 > 計画の順守 出典: www.agilemanifesto.org 7
  • 8. ゕジャ゗ルの12の基本原則  我々は価値のあるソフトウェゕをできるだけ早い段階から継続的に引き渡すことによ ってお客様の満足度を高めることをもっとも優先します。  要件の変更は例え開発の後期であっても受け入れます。ゕジャ゗ル・プロセスは変化を 味方につけることによってお客様の競争力を引き上げます。  動くソフトウェゕを2~3週間から2~3ヶ月というできるだけ短い時間間隔で繰り返し 引き渡します。  ビジネスをする人と開発者はプロジェクトを通して日々一緒に働かなければなりませ ん。  意欲に満ちた人々を集めてプロジェクトを構成します。ですから彼らが必要とする環 境と支援を与え仕事が無事終わるまで彼らを信頼してください。  開発チームに対して、あるいは開発チーム内部で情報を伝えるもっとも効率的で効果 的な方法は面と向かって話をすることです。  動いているソフトウェゕこそが進捗の最も重要な尺度です。  ゕジャ゗ル・プロセスは持続可能な開発を促進します。スポンサ、開発者、ユーザは一 定のペースで永続的に保守できるようにしなければなりません。  卓越した技術と優れた設計に対する不断の注意こそが機敏さを高めます。  単純さ - 作業せずに済む量を最大限に引き上げる技量 - が本質です。  最良のゕーキテクチャ、要件、設計は自己組織的なチームから生み出されます。  どうしたらチームがもっと効率を高めることができるかを定期的に振り返り、それに 基づいて自分たちのやり方を最適に調整します。 http://www.metabolics.co.jp/XP/AgilePrinciples.html より引用
  • 9. 2010/3/19 Agile Day2 ゕジャ゗ルな開発プロセスの特徴  ビジネス価値を基準  ビジネス上の価値を基準に優先順位付けされた機能順に開発  小さい単位でリリース  機能が誤っていても、早期検出が可能になる  全て完了させて次へ  次の機能の選択や開発を行う前に、前の機能の選択、開発、テス ト、デプロ゗を全て完了させる  依存性の排除  機能レベルでのリスクが、他の機能に関連しないよう独立させる  無駄を省く  無駄を省くという基本思想のもと、今必要ではないものには手を 触れない。必要になってからゕクションを起こす 9
  • 10. 2010/3/19 Agile Day2 ゕジャ゗ルはリスクマネジメント  リスク  必要なものが本当に必要な時に出来上がるか  無駄なコストが発生する可能性  不確実なものを大きく予測しそれに従って行動する 優先度の高いものから着 手するため、早い段階で リスクが発覚 結合試験あたりからビック バンによるリスク、受け入 れ試験での仕様相違リスク 等が顕在化 ゕジャ゗ルは顧客、開発側双方にとっての リスクマネジメント手法 http://www.unitedcrew.co.jp/service/service06.htmlよりグラフを引用 10
  • 11. 2010/3/19 Agile Day2 ゕジャ゗ルは単なる技術論ではない  現場の開発者の方は、  ゕジャ゗ル=技術的な課題解決方法  ゕジャ゗ル=個別のプラクテゖス  ゕジャ゗ル=現場の話  と思われているかもしれませんが、 ゕジャ゗ルは単なる技術論ではありません。 色々なことを意識する必要があります 11
  • 12. 2010/3/19 Agile Day2 ゕジャ゗ルなプロセス の導入の前に 12
  • 13. 2010/3/19 Agile Day2 導入の目的を考える  ゕジャ゗ルな開発プロセスの導入の目的  WFでやっていてうまくいかない?  顧客の満足度を向上したい?  もっと開発現場が楽したい?  もっと利益を上げたい? あなたが今日ここに来ている目的はなんですか? ただ現状がうまくいっていないのでゕジャ゗ルへ! というゕプローチはうまくいかない 13
  • 14. 2010/3/19 Agile Day2 現状分析のすすめ  ゕジャ゗ルな開発プロセスの導入の前に「何が」「どの ように」うまく行っていないのか?を棚卸する必要があ る  棚卸できていない=改善のプロセスが働いていない  問題が把握できなければ、改善のしようもなく、目標の設定もで きない  極論すれば、現状の問題はゕジャ゗ルな開発プロセスの導入とは 関係のないところで解決できるかもしれない 問題をオープンにするところから プロセス改善ははじまる 現状に目をつぶって逃げないこと! 14
  • 15. 2010/3/19 Agile Day2 導入の目的検討の視点  どのような視点で考えるべきか?  開発現場の視点  経営者、管理者の視点  顧客の視点 すべてのステークホルダー視点で考える! 15
  • 16. 2010/3/19 Agile Day2 目的達成の判断指標を考える  なにをもってゕジャ゗ルな開発プロセスの導入に成功し た、と言えるのかを事前に考えておく必要がある  顧客満足度の向上?  プロジェクトのQCD?  エンジニゕのQOL? 16
  • 17. 2010/3/19 Agile Day2 経営者・上司への ゕプローチ 17
  • 18. 2010/3/19 Agile Day2 立場によるゕジャ゗ルの意味の違い  経営者、管理者  ビジネス・経営戦略としてのゕジャ゗ル  トップダウンでのゕプローチ  現場開発者  現場改善としてのゕジャ゗ル  ボトムゕップでのゕプローチ 18
  • 19. 2010/3/19 Agile Day2 組織における問題  ピラミッド組織における問題  特に中間層は変化を恐れる  通常職能別組織に分かれており、社内での責任論になりやすい  顧客の価値よりも社内の政治を重視してしまう文化  意思決定プロセスが長くビジネス機会を損失しやすい  意思決定プロセスが形式的な準拠に終始しやすい  責任範囲を超えた範囲については思考停止する これらが組織のゕジリテゖ向上の妨げとなっている。 これらの問題の解決は経営者、管理者のミッション。 19
  • 20. 2010/3/19 Agile Day2 組織が変化しないことのリスク  あらゆる企業には競争相手が存在する  競争相手は進化しつづける  自組織が変化しない場合、相対的な競争力は低下していく  顧客のニーズや市場環境が変化する  いままで提供していたものに価値がなくなる(かもしれない)  顧客はもっとQCDを求めるようになる  組織の存続自体が目的化されてしまう 変化を先送りすることで、ゆっくりと 組織が衰退に向かっていく 20
  • 21. 2010/3/19 Agile Day2 どうやって行動するか?  ボトムゕップゕプローチ  なぜ変化が必要なのかを、説明・納得してもらうための材料を用 意する  ビジョンやゴールを準備する  自分の所属しているチームを巻き込む  巻き込む人のレ゗ヤーを上げる 可能な限り、ボトムゕップ・トップダウンの  高い視点を保ち、全体のことを考えている上司・経営者 双方からゕプローチする!  自己の保身、立場を気にする人は巻き込まない  ビジョンの実現のためには一時的に痛みを覚えるかもしれないと いう覚悟を持つ  トップダウンゕプローチ  会社全体の推進支援が得られやすい、改革への抵抗勢力が排除し やすい、という点でトップダウンゕプローチは有効 21
  • 22. 2010/3/19 Agile Day2 説明・納得してもらうための材料  導入には、説明と納得の材料が不可欠  外部の調査事例や内部プロセスの分析結果を用意する  人が納得するためには、客観性と論理性が必要  例:①海外の導入実績調査事例  例:②オフショゕ開発との比較  例:③懸念するであろう点についての答えの用意  例:④パ゗ロットプロジェクトの実行結果を具体的な指標データ とともに経営上位層に報告し関心を引く 22
  • 23. 2010/3/19 Agile Day2 ①海外での調査事例(1)  The State of Agile Development ©2008 VersionOne 80カ国3061人の回答者。 自社のプロジェクトのうち、 ゕジャ゗ルな開発を行ってい るプロジェクトの割合。 プロジェクトの半分以上をゕ ジャ゗ルな開発プロセスで実 施している企業が50%程度 23
  • 24. 2010/3/19 Agile Day2 ①海外での調査事例(2)  STATE OF AGILE SURVEY ©2009 VersionOne  ゕジャ゗ルな開発プロセス導入で得られたメリット  優先順位の変更に対応できるようになった=90%  プロジェクトが可視化された=83% 24
  • 25. 2010/3/19 Agile Day2 ②ゕジャ゗ルとオフショゕの比較  オフショゕとAgileを比較した調査  調査結果は20年間に行われた8000のプロジェクトを対象とし、 似たようなLOC規模のものを比較したもの  プロジェクト全体の平均コストは350万$で、オフショゕの場合 320万ドル、Agileの場合は220万$が平均となった  時間という面で見ると、オンショゕで12.6か月、オフショゕで オフショゕという変化を選択できたのなら、 9.6か月、Agileで7.8か月が平均  ゕジャ゗ルという変化も選択できるかも! 品質面でみると、オンショゕは平均2702の不具合、オフショゕ は驚くことに7565の不具合。そしてAgileの場合はたった1372 個の不具合  オフショゕの方がプロジェクトコストが少なくなったとしても、 不具合の補修にお金がかかることになる  オフショゕは実はコストカットには繋がっておらず、Agileの方 が安くできる可能性が高い Zen, Project Management, and Life: Proof that Agile Works http://zen-pm.blogspot.com/2009/12/proof-that-agile-works.html 25
  • 26. 2010/3/19 Agile Day2 ③導入への懸念  導入に際しては以下の点 に懸念を持つ人が多い 事前の計画がない   ドキュメントがない  マネジメントされない  予測できない 無計画、ドキュメントなし、マネジメントなし、  管理職が変化に反対する スケーリングできない、というのは  スケーリングできない よくある誤解!  ゕジャ゗ルなプロセスの 価値感や方法論について 正しく説明することで懸 念を解消する必要がある The State of Agile Survey ©2009 VersionOne 26
  • 27. ④パ゗ロットプロジェクトの評価(例)  ゕジャ゗ルの実績/WFでの想定内容との対比 成果物定義の相違故に単 純比較はできないが、比 較評価としては十分参考 になる
  • 28. 2010/3/19 Agile Day2 顧客への ゕプローチ 28
  • 29. 2010/3/19 Agile Day2 顧客のおかれた状況  ビジネスの環境の変化  迅速な意思決定と具現化が求められる  変化しないことは市場から見捨てられるリスクがある  顧客自身が変化していくことが強く求められる  IT投資の目的の変化  業務効率化から戦略実現へ  いままではコスト削減、業務効率化ができていれば良かったが、 システムが他社との競争力の源泉になってきている  よいシステムを早期に市場に投入することが、強く求められる 29
  • 30. 2010/3/19 Agile Day2 顧客に伝えるべきこと  ゕジャ゗ルな開発プロセスで実施することの宣言  より早期に価値を市場に投入することの重要性  計画適応主義から変化適応主義へ  プロジェクトの計画と契約スキームの変更  納品物とそれらの価値についての合意  顧客がよりプロジェクトに積極的に関わる必要性  もちろん理解されない場合もある  縦割り組織、予算主義、丸投げ主義な顧客  耳障りの良い言葉だけを伝えない  結果ではなく価値も必ず伝える 顧客と同じゴールを目指すために、 プロジェクト開始前に必ず伝える! 30
  • 31. 2010/3/19 Agile Day2 契約スキーム  WFの契約スキームでゕジャ゗ルなプロジェクトを実施す ることには大きなリスクがある リソースとリリース時期  ゕジャ゗ルとWFにおける要件、リソース、時間の考え方 を固定し、実装する機能 を開発側も意識する必要がある 群は優先順位に従って開 発。随時見直す。 「契約交渉より顧客との協調を」とはいえ、契約内容 ゆえに失敗するプロジェクトも多い! 要求が固定。また初期の 段階で固定要求をもとに リソースとリリース時期 も固定してしまう 31
  • 32. 2010/3/19 Agile Day2 一括請負をAgileな開発に適用する問題  一括請負契約は危険な幻想(マーテゖン・フゔウラー)  顧客企業が一括請負契約を望んだ場合、受託側は、利益の最大化 という動機のために仕様変更は受け入れない。または仕様変更の たびに追加費用を請求する  または開発側は仕様変更分の費用を先に見積もりに追加している  受託側は当初の計画から変更「させない」ことに主眼を置くので 、顧客のビジネスでの状況が変わっても、システムを変化させる 動機が弱い  顧客から受託側に対して強い政治的な力がかかりやすく、それに よって発生するリスクが最後まで残る ただし、現在の日本的企業のほとんどはシ  端的にいえば、お互いの利益が相反しやすい契約スタ゗ルである ステム開発を委託する際に、内容の決定度 、といえる 合いに関わらず、一括での見積りを求めて  くるので、どう対応するかをよく検討する 一括請負するのであれば、顧客との協業的関係が既に成り立って いることが前提 べき 32
  • 33. 2010/3/19 Agile Day2 主な契約パターン  ゕジャ゗ルな開発プロジェクトの契約パターンは様々  スプリント契約  固定価格・固定スコープ  実費精算契約  実費精算契約(固定スコープ、上限コスト付き)  実費精算契約(変動スコープ、上限コスト付き)  フェーズ開発  ボーナス/ペナルテゖ条項  固定利益  早期中止、変更無料  ジョ゗ントベンチャー この文章は、Peter Stevensによる「10 Contracts for your next Agile Software Project」の日本語訳であり、 CreativeCommonsラ゗センスで配布されている。http://capsctrl.que.jp/kdmsnr/wiki/transl/?10-agile-contracts 33
  • 34. 2010/3/19 Agile Day2 チームビルデゖング・ 人材育成 34
  • 35. 2010/3/19 Agile Day2 オペレーションプロセスの変化  従来のコマンド・コントロール型から、自律化・自己組 織化への変化が求められる  コマンド・コントロール  上司の命令に従っていれば良い、という価値観  メンバーはやらされ感を持つ  上司の指示を遵守したかどうかが評価の観点に  人が育たない。通常は上司の劣化コピーに…  現状に不満をもつ優秀な人から順に退職…  自己組織化  上司は責任とチームで解消できない問題の解決を担う  上司は後方支援、フゔシリテーター役になる  チームを信じる 35
  • 36. 2010/3/19 Agile Day2 チーム運営  チームのビジョンの共有  チームがチーム足りえる目的を共有することでチームメンバーの モチベーションを維持する  自己組織化した組織における改善のループ  常に改善できることがないか?という意識を持つ  気づきの場としての振り返りミーテゖング  Keep  Problem  Try  振り返りで出た問題をそのままにしない、Tryが出来ているかの モニタリングを継続的に行う  そのチームの一員であることを誇りに思えるように! 36
  • 37. 2010/3/19 Agile Day2 現場リーダーや管理職の役割の変化  従来の役割・振る舞い  求められる役割・振る舞い  ピラミッド組織  ネットワーク型組織  コマンド・コントロール  自律・自発の支援  権威的  民主的  流動性がない  流動性のある  答えをいう  導く  叱る  褒める  否定  肯定  マ゗クロマネジメント  チームの自主性に任せる 自己組織化されたチームで仕事をできるようにするためには、外部からのマ ゗クロマネジメントを止める必要がある。 通常チームは指示があればそれに従ってしまうものであるため、外部からの 指示がなくならない限り、チームは自己組織化したチームにはならない。 37
  • 38. 2010/3/19 Agile Day2 リーダーシップのモデル(SL理論)  リーダーシップのモデル は左図のように4つに分類 される。  S1:具体的な指示と監督 考えを合わせて決めら 考えを説明し、疑問に  S2:説明と疑問への回答 れるように仕向ける 応える  S3:参加型  S4:委任型  ゕジャ゗ルなチームのリ ーダーはS3/S4を目指す 具体的に指示し、事細 かに監督する 。通常WFではS1に該当 仕事遂行の責任をゆだ ねる  有効なリーダーシップは 部下・組織の成熟度によ http://www.situational.com/ より図を引用 って異なる 38
  • 39. 2010/3/19 Agile Day2 ゕジャ゗ルなチームのリーダー  リーダーが持つべきもの  強いビジョンを持っていること  ビジョンの中に揺らぎない信念を持ち、チームを前に進め、困難 に打ち勝つために約束・決定すること  リーダーはビジョンの素晴らしさを共有するために、十分なエネ ルギーと熱意を注ぐこと  リーダーは人の話を聞いて対応できること  リーダーは問題解決能力を持っていること  リーダーは多くの邪魔が入ってもゴールの達成に集中する  リーダーは決定を下すことができる  リーダーは周りに教えることを厭わない、よいコーチである  周りを信頼し、正直であること  別にゕジャ゗ルなチームに限らない 39
  • 40. 2010/3/19 Agile Day2 人材育成について  チームが人を育てる  OJTによるマンツーマンな人材育成ではなく、チーム全員が協力 しあってお互いの能力を向上させる  チーム内での勉強会などの開催も有効。僅かな時間的投資が後に 何倍にもなる  自分がコミットしたことを守ろうとする文化。過小コミットしな い文化  文化や環境によって人の成長速度は変わる  評価プロセスの透明性  誰もが納得する評価基準  ゕジャ゗ルな開発プロセスにおける透明性を懲罰に利用しない  評価の不透明さは、人が育たなくなる第一歩 40
  • 41. 2010/3/19 Agile Day2 ゕジャ゗ルな開発プロ ジェクトのはじめ方 41
  • 42. 2010/3/19 Agile Day2 対象プロジェクトの選定  対象プロジェクト  小規模プロジェクトから始めて実績を作る  いきなり大規模プロジェクトや分散プロジェクトで実施するのは リスクが高い  ゕジャ゗ルな開発プロジェクトは顧客の協力が必須であるため、 顧客の協力が得られやすいプロジェクトを選ぶ  ミッションクリテゖカルなプロジェクトは避ける 42
  • 43. 2010/3/19 Agile Day2 体制  体制(チーム)構築は非常に重要  ゕジャ゗ルな開発プロジェクトの成否は人にかかっている  チームにはゕジャ゗ルな開発プロジェクトの経験者を入れる。難 しいようであれば外部のコーチやトレーナーを利用する(外部の コーチの導入はトップダウンゕプローチでのゕジャ゗ル導入の場 合はやりやすい)  全員同席できる場所を確保  チームのメンバーは他の案件を兼任させない  ただしDBのパフォーマンスチューニングエンジニゕなど特殊 職能の人は除く  メンバーの技術力はもちろん大事だが、コミュニケーション力は もっと大事 43
  • 44. 2010/3/19 Agile Day2 利用するプロセス  どのようなプロセスを利用するかはプロジェクト開始前 に決めておく  はじめてのゕジャ゗ルな開発の場合は、Scrum+XPのハ゗ブリ ッドがおすすめ  ゕジャ゗ルな開発の経験がない場合は、まずは教科書的にプラク テゖスに従う  ある程度慣れるに従って、チーム自身で改善、カスタマ゗ズ していく  モニタリングと自己評価 新しいプロセスを導入した当初は、以前よりも生産性が下がるかも しれない。定着期ゆえなので、そこで諦めない 44
  • 45. 2010/3/19 Agile Day2 ツールに対する考え方  ゕジャ゗ルな開発プロジェクトで利用するツール群  SCM、自動テスト、バックログ管理など  プロセスとツールの同時学習は負荷が高い  本当に必要なツールを用途にあわせて選択  ツールをベースにしてプロセスを規定し過ぎない  全てのチームで同じツールが適切であるとは限らない  改善のループの中で徐々にツールの適用範囲を増やす  大規模ゕジャ゗ルや分散ゕジャ゗ルにおいてはゕジャ゗ルプロジ ェクトマネジメントの専用ツールや、各種コミュニケーションツ ールによるサポートは欠かせない ツールの導入“自体”を目的にしないこと! 45
  • 46. 2010/3/19 Agile Day2 (参考)ツールの利用割合  ゕジャ゗ルなプロジェクトでもExcel大活躍! The State of Agile Development ©2008 VersionOne 46
  • 47. 2010/3/19 Agile Day2 横展開に向けて  横展開する前に、まずパ゗ロットチームのプラクテゖス を醸成する。表面的な結果のみから早急に横展開しない  横展開の際もパ゗ロットチームと同じように体制に気を 配る  一度にパ゗ロットチームを解体して、多チームに分散し てもうまくいかない  横展開したチームがパ゗ロットチームと同じ文化、プラ クテゖスになるとは限らない。成功体験を単純にあては めようとしないこと  横展開したチーム同士がコミュニケーションできる場を 用意する 47
  • 48. 2010/3/19 Agile Day2 最後に 48
  • 49. 2010/3/19 Agile Day2 これからどう行動するか?  あなたにとってのゕジャ゗ルとはなんですか?  今日ここに来た目的を是非もう一度考えてください  現状分析してみよう  社内の仲間を増やそう  説得ではなく納得  一緒にセミナーにいったり  一緒に悩んだり  外部のコーチやコンサルをうまく使おう そして何よりも、あきらめないで努力し続けよう! 49
  • 50. 2010/3/19 Agile Day2 私にとってのゕジャ゗ルとは?  私にとってのゕジャ゗ルとは、目的実現の道具  顧客の価値を実現したい  現場の開発者を幸せにしたい  自社にきちんと利益をあげたい 50
  • 51. 2010/3/19 Agile Day2 ご清聴ありがとうございました。 51