「Agileごっこ」で終わらせないために(仮)
- 5. きんちゃん です
- 6. 自己 紹 介
- 8. 感謝
- 10. 宣伝
- 12. 宣伝 終了
- 13. 本日 お話する事
- 17. • アジャイルな開発とは • どんな現場で • どんな事をして • どんな知見を得たのか 3d*%yq*###!!
- 18. 今日の結論
- 20. • アジャイルな開発とは • どんな現場で • どんな事をして • どんな知見を得たのか 3d*%yq*###!!
- 21. アジャイル 開発
- 22. ？
- 25. ありがとう ございます
- 26. ソフトウェア 開発手法
- 27. アジャイル マニフェスト
- 29. • プロセスやツールよりも 人と人同士の相互作用を重視 • 包括的なドキュメントよりも 動作するソフトウェアを重視 • 契約交渉よりも 顧客との協調を重視 • 計画に従うことよりも 変化に対応することを重視
- 30. いまいち ピンと来ない…
- 35. • アジャイルな開発とは • どんな現場で • どんな事をして • どんな知見を得たのか 3d*%yq*###!!
- 40. 内製中心 開発スタイル
- 41. 良くある チームの スタイル
- 43. 例：ライフサポート系
- 45. 例：スマートフォンアプリ
- 47. 僕の 立ち位置 ＝ 【間接部門】
- 50. アジャイル 開発
- 52. 実は 弊社だと 大体できてる
- 54. 以上
- 55. …
- 58. 現実は
- 62. • アジャイルな開発とは • どんな現場で • どんな事をして • どんな知見を得たのか 3d*%yq*###!!
- 63. はじめてのScrum
- 64. Scrum?
- 65. Scrum とは • 自律改善型チームを育て • 優先順位の高い機能を • 繰り返し価値に変え届ける • 仕組み(フレームワーク) アジャイル開発手法の1つ
- 66. 期間固定のスプリントを繰り返す 月 火 水 木 金 月 火 水 木 金 前 後 月 火 水 木 金 月 火 水 木 金 前 後
- 69. プロダクトバックログ 会員登録ができる 5 会員は予約ができる 5 お知らせを登録できる 3 イベントを登録できる 3 会員は退会ができる 1 会員は決済ができる 13 優先順位付けられた機能一覧 スプリントバックログ スプリント内のタスク一覧 出荷可能な製品の増分 今回のスプリントで出来たモノ
- 70. 月 火 水 木 金 月 火 水 木 金 朝 一 午 前 午 前 午 後 午 後 デイリースクラム（朝会）：1回15分以内 スプリント(1開発期間)内のMTG • 昨日やった事 • 今日やる事 • 問題、障害になっている事
- 71. 月 火 水 木 金 月 火 水 木 金 朝 一 午 前 午 前 午 後 午 後 デイリースクラム（朝会）：1回15分以内 スプリント計画会議：やる事決め スプリント(1開発期間)内のMTG
- 72. 月 火 水 木 金 月 火 水 木 金 朝 一 午 前 午 前 午 後 午 後 デイリースクラム（朝会）：1回15分以内 スプリント計画会議：やる事決め スプリントレビュー：動く物を見せる ふりかえり（KPT等） スプリント(1開発期間)内のMTG
- 73. 月 火 水 木 金 月 火 水 木 金 朝 一 午 前 午 前 午 後 午 後 デイリースクラム（朝会）：1回15分以内 スプリント計画会議：やる事決め スプリントレビュー：動く物を見せる スプリント(1開発期間)内のMTG ふりかえり（KPT等） • Keep(良い事・続けたい事) • Problem(困っている事・問題) • Try(次のスプリントで取り組む事)
- 74. 期間固定のスプリントを繰り返す 月 火 水 木 金 月 火 水 木 金 前 後 月 火 水 木 金 月 火 水 木 金 前 後 計画して ふりかえる 計画して ふりかえる
- 75. •ライフ系① (2012/08～2012/12) •ライフ系② (2012/08～2013/03) •ゲーム系① (2012/10) •ゲーム系② (2012/11～2013/02) •ゲーム系③ (2014/01～2014/02) •ツール系① (2014/04～2013/07) • その他：社内アジャイル相談窓口 関与したプロジェクト
- 76. ライフ系① – 期間 • 2012/08 ～ 2012/12(約5ヶ月) – 目的 • 「新システム化」の進捗が出ない状況を打開 – 関わった事 • 「新システム化」プロジェクトへのスクラム導入支援 – 概要 • 後述の「ライフ系②」と同時期に開始 • 開発以外の人員を巻き込めず、プロダクトオーナー不在 • RedmineのBacklogsプラグインを利用した プロダクトバックログの管理
- 77. Keep – はじめてのScrum。何はともあれ最初の一歩 – 「Scrumやってみたい」と声を掛けてもらえた – 他部署との交流が出来た事 Problem – プロダクトオーナーを立てずに始めてしまった • 「なんちゃってプロダクトオーナー」危険 – 「Scrum」というよりは「Scrumごっこ」 • 僕自身が、ひとつひとつの判断に自信を持てなかった – 最後には、それ以前のスタイルに戻す事となった
- 78. ライフ系② – 期間 • 2012/08 ～ 2013/03(約8ヶ月) – 目的 • 「新システム化」の進捗が出ない状況を打開 – 関わった事 • スクラムマスターとしてプロジェクトへ横断参加 – 概要 • 開始当初はプロダクトオーナー不在 • 開発3ラインの内、2ラインを独立したバックログで管理 • 後半においては、部長をプロダクトオーナーとして 巻き込む流れを作る事が出来た
- 80. Keep – 写真で記録を残し始めた – 「○○だと思います」→「○○です」の言い切り – タスクかんばん、バーンダウンチャートの利用 – 複数ラインの状況をまとめて見える化 – 共有PCを利用したコードレビュー、ふりかえり – 新規参加メンバーも早期に業務の流れを理解 Problem – 開発メンバーの兼務により、リズムが不安定に
- 81. ゲーム系① – 期間 • 2012/10(約1ヶ月) – 目的 • 「うまく行っていない状態」の打開 – 関わった事 • 「プロジェクトふりかえり」の実施 • 「タスクかんばん」の作成・運用・横展開 – 概要 • ヒアリングの結果、「Scrumは不向き」と判断 • 「業務の見える化」「コミュニケーション増加」に 狙いを定め、「タスクかんばん」と「朝会」のみ導入
- 84. Keep – Scrumをオススメしなかった – 本当に必要な最小限に絞り改善のサイクルを作る – 「企画・開発」のタスクをまとめて見える化 – 100円ショップに毎週通うようになった – メンバーによる自律的なカンバンの再構築 Problem – 別フロアのプロジェクトであったため、 足を運ぶ頻度が少なくなってしまった。
- 85. ゲーム系② – 期間 • 2012/11 ～ 2013/02(約4ヶ月) – 目的 • 「ゴールの共有が出来ていない」状況への対処 • 「マイルストーンごとの進捗」を【見える化】したい – 関わった事 • 「見える化」支援 → スクラムマスター – 概要 • リリース2ヶ月前の追い込みからの支援だったため、 当初は「全部入りのScrum」は避ける事を提案 • 途中、メンバーの意向からScrumの形式で進める事に • 最後の時期は、オリジナルのタスク消化手法へと変化
- 87. Keep – グラフィッカー作業もスプリント内に含める – 「最初からプロダクトオーナーがいる」のは初 – プランニングポーカー→SML見積もり – 最後の追い込みの時期には、Scrumをやめた Problem – クライアント側、サーバ側の業務が違い過ぎて 技術者間での作業分担が出来ず、偏りが生まれた
- 88. ゲーム系③ – 期間 • 2014/01 ～ 2014/02(約2ヶ月) – 目的 • 「新規アプリのプロトタイプを2ヶ月以内に作成する」 – 関わった事 • スクラムマスターとしてプロジェクトへ参加 – 概要 • プロダクトオーナーがScrumに明るい状態 • グラフィッカーが別拠点にいる関係で、画像素材の 仕様や納品に関わる各種コストが増大 →週1回、プロジェクト計画会議の場に直接参加(出張) • 2ヶ月が経過したタイミングで、開発メンバー全員が 別拠点へ → 現地スクラムマスターへと引き継ぎ
- 90. Keep – グラフィッカー内でもプランニングポーカー – 自信を持ってツールをオススメ出来るようになった – 「すごく開発に集中出来る」と言ってもらえた Problem – 本業が多忙であったため、朝会にあまり出られず – プロトタイプの完成を見届ける前にチームを離れる
- 91. ツール系① – 期間 • 2014/04 ～ 2014/07 (約4ヶ月) – 目的 • 「我流スクラム」を見なおし、更なる成果に繋げたい – 関わった事 • スクラムマスターとしてプロジェクトへ参加 – 概要 • 「既存運用」と「新規開発」が並行する現場で、 双方のバランスを調整しながらのスプリント計画 • スマホネイティブアプリ開発者不足をカバーすべく、 各スプリント内で徐々にネイティブ開発タスクを分担
- 93. Keep – コンテンツ量産用の独自カンバンを作成 – ホワイトボード上で「すべての状態を見える化」 • 複数あった進捗管理（xlsx等）を排除。脱属人化 – スクラムマスターとして立ち回れるメンバーの育成 – 気が付いたら、だいたいの事をアドバイス可能に Problem – 計画会議、ふりかえり等での温度差 – 社内の異動に伴い、プロジェクトを離れる事に
- 94. • アジャイルな開発とは • どんな現場で • どんな事をして • どんな知見を得たのか 3d*%yq*###!!
- 100. Try – スクラムを実施する場合、プロダクトオーナーの 協力を事前に得た上で、皆で学習しながら進める – 導入についての相談をされた際には、 ビジネス的な価値への貢献を説明すると共に、 「チームの早期成長・改善」に意識を向けてもらう – 「スクラムはフレームワークに過ぎない」事を 常に意識のどこかに置いておく – 「完了の定義」が明確に出来るような仕組みづくり
- 101. 正直な所 まだまだ 経験不足
- 102. 今日の結論
- 106. 最後に宣伝
- 109. 自分たちの手で 変えてみよう
- 110. 実は 弊社だと 大体できてる
- 111. 興味を持った方は エイチーム 採用
- 112. 以上です ありがとうございました