O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

アジャイル開発10年間の軌跡

CEDEC2020の講演資料です

  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

アジャイル開発10年間の軌跡

  1. 1. アジャイル開発10年間の軌跡 2020年9月3日
  2. 2. 1. 自己紹介 2 田中 宏幸 ( 43 ) 株式会社イリンクス 代表取締役社長 経歴 • HAL大阪ゲーム学科2年生卒業 • 日本ファルコム株式会社 メインプログラマー • 株式会社カプコン PS2描画エンジンプログラマー • 株式会社ゲームリパブリック プログラマー統括 • 株式会社イリンクス 代表取締役社長 資格 PMI認定プロジェクトマネジメントプロフェッショナル 認定スクラムマスター
  3. 3. 目次 アジャイル開発との出会い スクラム始めました スクラム再スタート デジタル管理 停滞とトラブル ??? 転機 今、そしてこれから 2009年 2010年 2011年~2012年 2013年~2014年 2015年~2016年 2017年~2018年 2019年 2020年
  4. 4. 2009年 アジャイル開発との出会い
  5. 5. 5 2009年 - ゲームリパブリックに所属 「タイタンの戦い」というタイトルの 開発が終わったばかり
  6. 6. 6 ゲームリパブリック時代のスケジュール管理 結果、期間と仕様のトレードオフが出来なくなる リーダー リーダーがRedmineでガントチャート ベースのスケジュールを作成 ゲームは作ってみないと分からないので、 頻繁に再計画をし続ける必要があるが ガントチャートの修正は結構大変。 リーダー リーダー リーダーは常に忙しいのでスケジュール 修正が遅れたり、更新がされなくなり 誰もスケジュールが判らなくなる メンバー メンバー ???
  7. 7. 頻繁に デスマーチが発生
  8. 8. やりたくない ランキング 1位 徹夜 2位 休日出社 3位 残業 タイタン開発時は すっとこんな感じ
  9. 9. それだけ頑張って出来たものを 誰も称賛してくれないのが辛かった
  10. 10. AAAゲーム開発を成功させる 方法ってなんだろう…?
  11. 11. 12 何故アジャイルとスクラムなのか? ⚫ プロジェクトが大きくなってきている。 ⚫ より多くの人 ⚫ より多くのコード ⚫ より多くのリソース ⚫ ハードウェアとソフトウェアの複雑さの増加 ⚫ 変化に素早く反応する必要がある ⚫ 設計と計画の見直しを、より迅速に、より頻繁に。 ⚫ 同時に品質を向上させる必要がある CEDEC2009 最新技術事例「Star WarsThe Old Republic」での大容量ゲーム開発より抜粋
  12. 12. 13 スクラム ⚫ 人気のあるアジャイル開発プロセス ⚫ 1986年:竹内 博隆 氏、野中 郁次郎 氏 ⚫ ハーバード・ビジネス・レビューにて 論文「The New New Product Development Game」を発表 ⚫ スピードと柔軟性の向上を重視した開発手法 ⚫ 1991-2001:サザーランド博士、シュウェイバー博士、他 ⚫ 論文にソフトウェア開発用のアイデアを足し、 それをスクラムと呼ばれるようになった CEDEC2009 最新技術事例「Star WarsThe Old Republic」での大容量ゲーム開発より抜粋
  13. 13. 14
  14. 14. 15 これだぁぁぁぁぁぁ!!
  15. 15. 2010年 スクラム始めました
  16. 16. まずは2人で始めてみた
  17. 17. 講演だと簡単そうだったのに むっちゃ難しい…
  18. 18. 勉強だ!
  19. 19. ディレクターに 「スクラムやらせて!」と説得 認定スクラムマスター Project Management Professional (プロマネの国際資格)
  20. 20. ディレクター 「確かに良いかも。やってみますか」
  21. 21. Redmineで スプリントバックログ
  22. 22. 27 大量のマサカリが飛んで来るレベル 全然スクラムじゃない
  23. 23. 2010年 6月 ゲーム開発者向けにスクラムを 解説した本が発売 著者は米国で ゲーム用スクラムのコーチを している Clinton Keith →ゲーム会社のCTO (High moon studios) すごく分かりやすい!!
  24. 24. スクラム 完全に理解した
  25. 25. 意気込んだものの ゲームのプロトタイプが 完成した辺りで…
  26. 26. ゲームリパブリック倒産
  27. 27. 2011年~2012年 スクラム再スタート
  28. 28. トップダウンで スクラムを開始 本の通り 忠実に行う
  29. 29. プロダクトバックログ • 製品全体の機能リスト • 粒度はとても荒い (100人日というチケットも) • 日々追加されていく • 付箋&Excelで管理 赤い付箋は仕様待ち ・利点 見える化 付箋をスプリントに使える ・欠点 剥がれる 付箋の粘着力超重要 Excelとの2重管理が必須
  30. 30. リリースバックログ
  31. 31. スプリントプランニング
  32. 32. タスクボード
  33. 33. バーンダウン チャート
  34. 34. スプリントレビュー
  35. 35. ふりかえり
  36. 36. プラグマティック ペルソナ
  37. 37. 48 色々改善されたが 混沌な部分も多い
  38. 38. 49 2012年頃のスクラム • ふせんでバックログを作成し、それをステークホルダーやPO チームで確認し、足りない要素が無いか等洗い出しが出来てる • チームとスプリントプランニングやレビュー、ふりかえりで 対話をしつつ、バックログは減らせてる • 仕様の追加や変更が積み重なり、プロジェクト後半にバックログ が溢れ、全体スケジュールが間に合わない • リソース管理はかんばんを使用しているが、リソース数が多いた め、付箋だと手に余る状態 1年で様々な手法をトップダウンで取り入れたが 手探りで解決方法を探してる状態
  39. 39. 2013年~2014年 デジタル管理
  40. 40. ふせん!
  41. 41. ふせん!!
  42. 42. 53 ふせん!!!
  43. 43. 会社が大きくなり プロジェクトも大きくなり 付箋まみれに
  44. 44. • ふせんは計画を立てたり見え る化には便利だが、長期間の 運用で問題になった。 • 特にコンシューマゲームは開 発期間が数年になるため、ふ せんの数が数千枚となったり、 ふせんが破損したり無くなっ たりした。 • アナログだとベロシティや バーンダウンチャート数えた りするのが大変。 • 社外のステークホルダーに 説明する際にも困った。
  45. 45. Hansoftによる デジタル化
  46. 46. 58
  47. 47. 60 バックログもカード形式で印刷可能
  48. 48. 61 Hansoftとの出会い • タスクの日数もベロシティもバーンダウンも一瞬で表示される • 「プロダクトバックログの総日数が**日だから 多少バックログが増えてもマイルストーンに間に合う」等 直近のスプリントだけでなく、長期スケジュールも確認出来る • 様々な情報をPDF化してステークホルダーに提出出来る • やっぱり検索は便利 計画はふせん。運用、報告はHansoft。 スクラムにも慣れ、安定した状態に
  49. 49. 2015年~2016年 停滞とトラブル
  50. 50. 会社を設立し 本格的にスクラムを始めてから 約5年 停滞した空気が流れると 同時にトラブルも出始めた
  51. 51. その1 ふりかえりの廃止
  52. 52. 65 ふりかえりの廃止 • ふりかえりはKPTを開催 • 結構強めの発言をするプログラマーがメンバーにおり 度々ふりかえりの際に~が悪い的な空気を出すことがあった。 • そのため、POから「ふりかえりの開催を暫く辞めたい」と 相談された。 • その後再開の機会を度々打診はしたが、結局再開せずにプロジェ クトが終了し、その後もふりかえりのは行えず。 ふりかえりが重要なのは判っていつつ 問題が解決できず廃止してしまった。
  53. 53. その2 デイリースクラムを 1週間単位に
  54. 54. 67 当時のデイリースクラム • 人数が増え、スクラムオブスクラムが形成 • 1チーム8人を超えることも有り、スクラムオブスクラムとも合 わさり、どんどん報告に時間が掛かっていた • チームの成熟度も上がり、困ったらデイリースクラムを待たず 直ぐに声を上げるようになっていた デイリースクラムより他の良い方法があるのでは?
  55. 55. とは言え、デイリースクラムをやめると スプリントレビュー時にしか 状況把握できない (当時は3~4週間)
  56. 56. デイリースクラムを無くす代わりに スプリントを1週間にしよう!
  57. 57. ふりかえりと デイリースクラムを 変えてどうなったのか?
  58. 58. 特に問題なし タスクもスプリント内に消化できてるし スケジュールもトラッキング出来てる
  59. 59. 2017年~2018年 ???
  60. 60. タスクは消化出来ているが 「品質不足」 「機能が足りない」 「思っていたものと違う」 などでタスクが度々追加される
  61. 61. 一向に減らない プロダクトバックログ 遅延していくスケジュール
  62. 62. 2019年 転機
  63. 63. 【その1】 スクラムマスターを採用 2人で2プロジェクトを 見る体制
  64. 64. 77 2人体制の良さ • 新スクラムマスター(新SM)がSMとして チームに入り、私は新SMやPOを支援。 • スプリントプランニング終了時等で 二人で話し合い、次の施策などを決める。 ・自分だけでは気づかない事に、もう1人が気づく ・得意不得意を分担できる ・ゆとりが出来て、色々な事に気が回せる
  65. 65. ふたり体制 最高ーーー‼
  66. 66. 【その2】 アジャイルコーチを お願いする
  67. 67. 松元 健 元大手ゲーム会社でスクラムマスター アジャイルコーチ、中小企業診断士 他、認定研修の運営や書籍の翻訳、レビューなど 書籍「SCRUMMASTER THE BOOK」共訳者(翔泳社) 川口さん
  68. 68. 最近マネジメントが上手く行って ない様に思うのですが、何が原因 か判りますか? 「上手くいく」というのは どういう状態の事?
  69. 69. 上手く行っている マネジメントとは何か? その場では答えられず…
  70. 70. 新体制なってから数カ月… スプリントプランニング中に こんな話を耳にする
  71. 71. レビュー会を開催してほしいんですけど。 タスク単位ではなく、完成した機能について 話がしたいんだよね。 デザイナー ディレクター わかりました。どんな感じでやりましょうか? 新SM 私 あれ?これって…
  72. 72. 今チームに足りてない要素に 開発メンバーは気づいている
  73. 73. 86 ゲームの面白さ についての会話
  74. 74. 87 スプリントが1週間になった影響 スプリントを1週間にする 毎週スプリントプランニングとスプリントレビューは 大変なのでレビューがおざなりになる タスクやスケジュールについての 会話中心になる
  75. 75. ゲームについての会話が無くても タスクが消化出来れば開発は進み スケジュールも守れる それの何が悪いのか?
  76. 76. 89 スクラムチームは改善する問題を正しく選んでいますか? By Yoshiba Ryutaro https://slide.meguro.ryuzee.com/slides/97
  77. 77. 90 スクラムチームは改善する問題を正しく選んでいますか? By Yoshiba Ryutaro https://slide.meguro.ryuzee.com/slides/97
  78. 78. スクラムチームは改善する問題を正しく選んでいますか? By Yoshiba Ryutaro https://slide.meguro.ryuzee.com/slides/97
  79. 79. 気がついたらスクラムの スケジュールに関する プラクティスしかせず Outcome「成果」 についてが抜けている
  80. 80. スケジュールに間に合わせるために スクラムを始めた? NO
  81. 81. 面白いゲームを作ること そのためのスクラム
  82. 82. そして、ふりかえりが 無くなったので こんな単純なことに気づくのに 随分時間がかかった チームメンバーは 「成果」が抜けていることを 経験で知っていた
  83. 83. 2020年 今、そしてこれから
  84. 84. …というのが「マネジメントが上手くいって る状態って何?」という問いについての答え なのですが、どうでしょう? では、そのために、田中さんは まず何をしますか?(スパルタ) …ぴえん
  85. 85. 成果を出すために再起動
  86. 86. まずはスプリントレビューを しっかりやる
  87. 87. 100 スプリントレビューをしっかりやる • スプリントを4週にし、「価値」単位で バックログを作成する(INVESTを意識) • 4週で作った「価値」をしっかり画面で確認し フィードバックを得る • 次のスプリントやバックログに上記を活かす • デイリースクラムは一旦1週間単位で行う 面白いゲームを作るために対話を
  88. 88. 1 ふりかえりの再導入も 考えていきたい
  89. 89. 1 プロジェクトマネージャ保護者会 https://www.facebook.com/pmhogosyakai/ 飽きない、楽しいふりかえり
  90. 90. 1 まとめ 10年アジャイルすると どうなるのか
  91. 91. 1 【結果その1】 何のためにスクラムを しているのか忘れた 1日0.028%忘れた計算
  92. 92. 1 【結果その2】 結果的にスクラムの 凄さを知る
  93. 93. 106
  94. 94. 107
  95. 95. 1 スクラムの定義 スクラム(名詞):複雑で変化の激しい問題に 対応するためのフレームワークであり、 可能な限り価値の高いプロダクトを生産的かつ 創造的に届けるためのものである。
  96. 96. 109 スクラムでの改善イベント • 問題設定に対する改善 • スプリントレビュー • 開発力やチーム力に対する改善 • ふりかえり メンバーの経験値を 価値に活かせない
  97. 97. 1 【結果その3】 チームメンバーに スクラムで大切なことを 教えてもらう
  98. 98. 1 【おまけ】 アジャイルコーチって どうなの?
  99. 99. 1 問題点や改善方法といった事に対して 「気づくきっかけ」が得られる ただし、「気づき」を得るには 幾つか必要条件がある
  100. 100. 113 「気づくきっかけ」の条件 •目標が定まっていること • 何に対しての気づきが欲しいのか提示が必要 •聞く姿勢があること • 腹落ちしない限り、気づきに繋がらない •考えるゆとりがあること • ゆっくり考える時間がないと気づけない
  101. 101. 114 アジャイルコーチ活用術 By Yoshiba Ryutaro https://slide.meguro.ryuzee.com/slides/100
  102. 102. 1 ご清聴 ありがとうございました

×