アジャイルマネジメントとマインドセット 〜ヒーローを待っていても世界は変わらない〜

6,499 views
6,559 views

Published on

DevLOVE2012(http://devlove2012.devlove.org/)発表資料です。

発表概要。
アジャイルマネジメントとマインドセット 〜ヒーローを待っていても世界は変わらない〜
楽天の中でアジャイル開発を実践し、アジャイルコーチとして活動を始め2年が経とうとしています。今年私はマネージャとなり、エンジニアではない形で「アジャイル」を見つめなおすことができました。このセッションでは、アジャイル開発を実践導入する戦略や、チームに繰り返し伝えてきたマインドセット。これからの開発者を考えた時のマネジメントやパラダイムシフトについて、参加者の皆さんと考えていきたいと思っています。

Published in: Technology
0 Comments
34 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
6,499
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
47
Comments
0
Likes
34
Embeds 0
No embeds

No notes for slide

アジャイルマネジメントとマインドセット 〜ヒーローを待っていても世界は変わらない〜

  1. 1. 1
  2. 2. 藤原 大 @daipresents • 楽天株式会社 開発ユニット • アジャイルグループ マネージャ • 好きなヒーロー: ウルトラマンゾフィー ダイナマン、スーパーワン キョウダイン、ZZガンダムhttp://daipresents.com/
  3. 3. 上記以外にもサービスはあります。これだけいろいろなサービスがあると開発方法も様々です。
  4. 4. 現場•PO、DEVのチーム•スキルがまだ弱い若手•一体感のなさ
  5. 5. 今日お話することアジャイルコーチとして活動を始め2年。リーダー・マネージャーとして、チームに繰り返し伝えてきたマインドセットと、現場を救う未来のヒーローについてお話したいと思っています。よろしくお願いします。
  6. 6. アジャイルマネジメントとマインドセットhttp://www.flickr.com/photos/31029865@N06/5845786904/
  7. 7. Agile 2012 in Dallas
  8. 8. アジャイル開発の本質とスケ-ルアップ - ソフトウェア開発の実践 - http://goo.gl/vIsk9
  9. 9. 8つの変革
  10. 10. レガシーマインドセットたくさんのプロジェクト詳細なプロジェクト計画年間予算エライ人が作る年間計画WBSプロジェクトPMBOKWFのマイルストン
  11. 11. リーンアジャイルWIPを使ったかんばん軽量なビジネス案徐々に追加投資チームによる計画サイクル見積りと計画づくりリリーストレインアジャイルプロマネ現実に即したマネジメント
  12. 12. 1. たくさんのプロジェクトから WIPを使ったかんばんhttp://www.flickr.com/photos/31029865@N06/5845786904/
  13. 13. たくさんのプロジェクト•非効率な並行作業•横やり作業•忙しいは生産的か?
  14. 14. WIP制限した かんばん•かんばんを用意•朝礼で確認・共有•使いながら改善
  15. 15. MAX2枚 作業中 ゾーン
  16. 16. WIP制限した かんばん•WIP制限で安定化•見える化による発信•コミットメント宣言
  17. 17. 朝礼の 風景 ENG PRO ENGENG
  18. 18. 問題がよく起きる場所
  19. 19. 開発時間x6Before After
  20. 20. 作った時間の有効活用•価値のある手作業へ•気づきをつなげる サービスの触り心地確認•
  21. 21. 2. 詳細なプロジェクト計画 から軽量なビジネス案http://www.flickr.com/photos/31029865@N06/5845786904/
  22. 22. 詳細なプロジェクト計画•ヘビーなドキュメント•机上の空論スケジュール•守ることが目的に
  23. 23. 軽量なビジネス案•仕様書は正しくない•仕様はゴールではない•仕様は仮説でしかない
  24. 24. 小さいサイズ
  25. 25. 軽量なビジネス案•要求をカードに書く•デモ・リリース可能なサイズ•大事なら時間をかける
  26. 26. photo - http://www.flickr.com/photos/nknh/2447013697/
  27. 27. 軽量なビジネス案?• 汎用的に• スケールを考えて• キャッシュを入れて
  28. 28. 小さくリリース photo - http://www.flickr.com/photos/brucehh/7627194894/
  29. 29. 3. 年間予算から 徐々に追加投資http://www.flickr.com/photos/31029865@N06/5845786904/
  30. 30. 年間予算• 年末の道路工事現象• 使い方を決めて守る• 1年先見越してる パス 普通の予算型運営でやってるので 経験者募集中。 徐々に追加投資
  31. 31. 4. エライ人が作る 年間計画から チームによる 計画サイクルhttp://www.flickr.com/photos/31029865@N06/5845786904/
  32. 32. エライ人が作る年間計画•1年を見越した計画•綿密な計画•変更コストがでかい
  33. 33. チームによる計画サイクル•短期計画と長期計画•変更可能な開発計画•柔軟なリリース計画
  34. 34. ちゃんと計画する計画は変更する
  35. 35. 計画 1∼2週間のタイムボックス 比較的柔軟なリリース日 リズムを作る
  36. 36. 計画は道路標識レベル
  37. 37. 5. WBSからアジャイルな 見積りと計画づくりhttp://www.flickr.com/photos/31029865@N06/5845786904/
  38. 38. WBS•部品を組み立てても欲しい物ができない謎•項目の漏れによる打撃•管理作業の圧迫
  39. 39. アジャイルな 見積りと計画づくり•優先順位付けと見積り•タイムボックスで計画•頻繁な見直し
  40. 40. やることリスト
  41. 41. 見積もりで会話
  42. 42. こういう意見が 間に合うようにがんばってて欲しい
  43. 43. 見積りは確率だ がコミットメント は確率ではない楽天ブックス: アジャイルな見積りと計画づくり - マイク・コーン http://bit.ly/RhGkCO
  44. 44. 6. プロジェクトから リリーストレインhttp://www.flickr.com/photos/31029865@N06/5845786904/
  45. 45. プロジェクト•リリースでDONE•チーム解散、運用チームへ•人が集められる
  46. 46. リリーストレイン•継続的にリリース•職能横断的なチーム•チームに対しての仕事
  47. 47. レーンが計画
  48. 48. リリース計画 2Wごとの リリース
  49. 49. 7. PMBOKから アジャイル プロジェクト マネジメントhttp://www.flickr.com/photos/31029865@N06/5845786904/
  50. 50. PMBOK•WBS•ガントチャート•進捗報告
  51. 51. アジャイルプロジェクトマネジメント•新たな指標の設定•タイムボックスの活用•ゴールの確認
  52. 52. Velocity 予定多すぎない? 急激に落ち込んでない?当初は上がったり下がったり リリース後 安定していない 下がってない?
  53. 53. かんばんの状態 順調にDONE しているか? Doingが増加してい TODOが増えてない ないか?
  54. 54. ゴール• 仕様どおり• ビジネス価値が正しかった• これを安定して継続的に繰 り返すこと
  55. 55. 品質“Quality is valueto some person” by Gerald Weinberg
  56. 56. 価値 ユーザ ビジネスエンジニア
  57. 57. 8. WFのマイルストン 現実に即した マネジメントhttp://www.flickr.com/photos/31029865@N06/5845786904/
  58. 58. WFのマイルストン•計画に事実を合わせちゃう•机上の空論化
  59. 59. 現実に即したマネジメント•プロダクトの計測•効果測定を強化•現実に合わせて舵を切る
  60. 60. なぜ全部計測しない?
  61. 61. 効果測定•20% KPI上昇した!•想定以下の効果だった…•しかし何も起きなかった!
  62. 62. レガシー リーンアジャイルたくさんのプロジェクト WIPを使ったかんばん詳細なプロジェクト計画 軽量なビジネス案年間予算 徐々に追加投資エライ人が作る年間計画 分散回転式計画WBS 見積りと計画づくりプロジェクト リリーストレインPMBOK アジャイルプロマネWFのマイルストン 現実に即したマネジメント
  63. 63. ヒーローは 誰だ?http://www.flickr.com/photos/31029865@N06/5845786904/
  64. 64. Javaエンジニアとして働き出す SIerに就職し横浜に引っ越す 好き勝手やっていながら親に頭を下 03 げて専門学校に行かせてもらう 日記を書きだす 00 サークルにエンジニアビリヤードサークルを作る が多いことに気がつく 高校を卒業してフリーターになる 90 ICQでギリシャ人に話しかけられびっく りして電源を抜いてしまう Macに出会う、Windows95を使う
  65. 65. マネージャになる Agile Japanで発表 デブサミ2012で発表 アジャイルマニフェスト10周年 12 イベント開催に加わる 11 アジャイルコーチ開始 Agile2010に参加 10 はじめて勉強会で参加・発表 09 チームリーダーになる アジャイル開発に取り組みはじめる08 数日後、標準化を撲滅しようと決意する 現職に転職。標準化チームに配属される
  66. 66. 職業エンジニアどうすれば いいですか? アジャイルはバズワードだ 今 会社が○○ だから アジャイルやって みたいんですけど
  67. 67. 誰かなんとかしてくれただし、私の希望のとおりに楽天ブックス: ヒーローを待っていても世界は変わらない - 湯浅誠(社会運動家) 本 http://goo.gl/HBZfh
  68. 68. 96トレインスポッティング ポスターフレームセット:セレッサ http://goo.gl/oVDtW
  69. 69. 人生を選べ。仕事を選べ。キャリア、家族、大きなテレビ、洗濯機、車、CDプレーヤーや電気オープナー、固定金利、マイホーム、友達、レジャーウェアとそれにあった旅行かばん、こじゃれたスーツ、日曜大工や休日の午前に自分探しすること、お菓子を食べながらソファでクイズ番組を見ること、よぼよぼになって古くなった自宅で老いて行く事を選べ。未来を選べ。人生を選べ。・・・でも、それがいったい何なんだ? Trainspotting (film) - Wikiquote : http://en.wikiquote.org/wiki/Trainspotting_(film)
  70. 70. エンジニアの人生を選べ。未来を選べ。自分戦略を選べ。技術のトレンド、ビジネスを加速する、グローバル化、時代の変化、これからは英語がいる、生産性の向上、SIerはオワコン、ブラック企業、会社を変えると替える、社畜、業界構造、キャリアアップ、スキルセット、答えはあなたの中にあるとか、リーダーシップ、マネジメント、組織改革を選べ。未来を選べ。人生を選べ。・・・でも、それがいったい何なんだ?
  71. 71.
  72. 72. ふりかえりで成長を見える化する
  73. 73. 話し合いに入れなかった。 報告のレベルがわかりにくい。全体のスケジュールが見えない。 タスクDONEを共有できていない。タスクがなくなった。 人に任せっきりになっていた。 利用者と相談ができていなかった。 タスクが多かった。 仕様の理解不足。 横槍り作業を考えるのが大変。 メンバーに頼りすぎた。 レビューが完了できなかった。 DONEの定義が曖昧。 口頭のほうが早いことがあった。 デザイン当てに時間がかかる。 レビュー反映に時間がかかる。 テストの時間が足りていない。 誰が何をやっているかわからない。 確認ポイントがばらばら。 見積より時間がかかっている。 TODOが減ってきた。 これまでのレビューが怪しい。 コミット漏れがあった。 タスク洗い出しがうまくなかった。 自動化に時間をつかえなかった。 デモを完全な状態で見せたかった。 開発環境が整っていない。 メインタスク以外のタスクが影響。 体調があまりよくなかった。 タスクを拾うのが消極的。 影響範囲把握ができなかった。 ドキュメントが古い。 作業遅延の報告が遅い。 デモが意味なかった。 データが壊れて開発に影響した。ファイルのリリース漏れがあった。コードが汚くなってきた。 目的を理解せず作業してしまった。 空き時間ができてしまった。 再設計引き継ぎがうまくいってない。 タスクに入るためのタスクがあった。 寂しい。 リリース自動化に失敗してしまった。 開発開始まで時間がかかった。 テスト不足があった。 寂しい。 タスクが大きすぎた。 メンバーに頼りすぎた。 うっかり仕様抜けが発生した。 目に見える成果がなかった。マージ漏れがあった。 処理内容の理解不足があった。 デバッグが遅い。 チャレンジが足りなかった。 勉強会に参加できなかった。 バグがバグを生み出した。 実機を使ったテストが少ない。 英語に困っている。 優先順位がわからなくなった。 コミット漏れがあった。 完成するまで先が見えない。 スケジュール通りは厳しくなった。 ゴールが不明確な部分がある。 見積り忘れがあった。チームとマネージャで認識ずれ。 JSではまって時間を消費。 汎用的に作ると時間がかかる。 仕様を確認せず実装してしまった。 メンバーのフォローが遅れた。 担当していない機能の理解不足…144の『いまいち』
  74. 74. まず、見える化をしよう。 準備をしよう。 リーダにDONEを確認してもらう。 アジェンダを準備しよう。外部のタスクを把握しよう。チェックポイントを作ろう。技術MTGをはじめよう。 口頭で話そう。 ゴールの共有をしよう。確認者をちゃんと決めよう。 もうちょっと様子を見よう。明日計画MTGをしよう。レビュー時間をとろう。コミット前に差分確認しよう。 いないときは置き手紙をしよう。 自動化するレベルを考えよう。全員集合して分担をはじめよう。開発環境も並行してつくっていこう。タスクボードを朝礼後把握しよう。2週間分はかならずみつもろう。 腹巻きをしよう。 運用を考慮しよう。資料を残すようにしよう。環境構築も自動化していこう。レビューをもっとしよう。データを壊さないようにしよう。 勉強会しよう。 デザイナーと話してみよう。見積りを出そう。朝礼でカバーしていこう。チェックリストを作ろう。状況を整理してから共有しよう。 勉強会をしよう。 ENG MTGを活用しよう。最終確認までしたらリリースしよう。作業が止まらないように動こう。伝える時間を作ろう。 なぜから考えてみよう。 レビューを忘れずにしよう。ゴールを再定義してみよう。朝礼を有効活用しよう。遅いと思ったら改善しよう。再計画に時間をかけよう。 なぜから考えてみよう。 ソースレビューで検知しよう。ブラウザテストに時間をかけよう。確認手順を統一していこう。1日1タスクを考えていこう。付箋にして見える化していこう。 隣の人がを気にかけよう。 朝礼で共有していこう。付箋にして見える化していこう。残ったTODOに名前を書こう。テストを充実させていこう。 勉強会でナレッジ共有しよう。 朝礼で空き予定も共有していこう。はやめにアラートを出していこう。CIサーバを活用しよう。手でしかできないテストを洗い出せ。 アイデアを出しあっていこう。 ストーリの裏にゴールを書こう。実装の流れを書いてみよう。システムの理解を深めよう。テスト計画を張り出そう。 小さく作っていこう。STGなどの環境で確認を強化しよう。タスク洗い出しでDONEの定義。タスクの移動は朝礼でやろう。 積極的に学んでいこう。 確認のルールを決めよう・・・100の『チャレンジ』
  75. 75. スタンドアップMTGがよかった。タスクボードができた。 メンバーから意見が出た。 ゴールが明確だった。決定がスムーズだった。3キロ痩せた。 DONEの定義がよかった。ファシリテーションが良かった。誰が何しているかわかりやすい。 スキルの無さに気がついた。 問題解決の時間が短くなった。進んでタスクを取りに行けた。メンバーがサポートしてくれた。 サービスを全員で考えれた。 台風で早く帰ることができた。機能のブレストがうまくいった。メンバーのことがよくわかってきた。 要件以外の提案が出てきた。 コミュニケーションがとれている。ペアワークがうまくいっている。データ構造が理解できてきた。Rubyを勉強できた。 タスクをプル型でとれた。 リリースが成功した。既存ユーザの評価が良かった。トラブルのリカバリがスムーズ。 メンバーに元気をもらった。 周りがよく見えた。処理性能が高くなる実装ができた。デモの自動化が早くてよかった。自動リリースの範囲が増えた。 集中して開発できる。 開発∼テストの流れを理解できた。TODOを増やすことができた。インタフェースの検討ができた。免許をとれた。 改善活動を皆でやることができた。 メンバーが増えた。開発環境が使いやすい。前よりすぐに人に聞くようになった。設計∼リリースまで作業ができた。 チームのスピードが速い。 チーム感があった。座席変更がよかった。 全タスクをDONEできた。 アイスが美味しかった。 朝礼の遅延報告が良かった。勉強会がとてもよかった。リリースに自信をもつことができた。声かけしながらリリースできた。 新しいことにチャレンジできた。 メンバーとのペアオペがよかった。情報共有が良かった。 要件からENGが入ってきている。 メンバーの目標を聞くことができた。設計を経験できている。リリースまでの流れを理解した。 コードが綺麗とほめられた。 機能のデモが良かった。考えてソースを書くことができた。リリースまでの時間が短縮できた。リリースとテストの効率が上がった。 自分のコードがひどいことに気がつくことができた。 新機能開発の立ち上がりが速い。ペアプロが良かった。皆で仕様を考えた。設計が良かった。 何をやればいいかわかった・・・142の『よかった』
  76. 76. 世界は変わらないかもしれないけど
  77. 77. 誰でもヒーローになれる
  78. 78. 未来を選べ。人生を選べ。
  79. 79. 未来を選べ。未来は今だ。

×