Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

jus研究会名古屋大会「Redmineでプロジェクトを【見える化】しよう!」

121,995 views

Published on

2013/06/22に開催された「オープンソースカンファレンス2013名古屋」にて発表した際に利用したスライドです。
https://www.ospn.jp/osc2013-nagoya/modules/eguide/event.php?eid=41

Published in: Technology
  • Be the first to comment

jus研究会名古屋大会「Redmineでプロジェクトを【見える化】しよう!」

  1. 1. jus研究会 名古屋大会RedmineCopyright (C) 2009 Martin Herr2013/6/22 Open Source Conference 2013 NagoyaTaku YAJIMA(@quindim)でプロジェクトを【見える化】しよう!
  2. 2. ですきんちゃん
  3. 3. って呼んでくださいきんちゃん
  4. 4. 感謝
  5. 5. 提供「名古屋」から「世界」を変える
  6. 6. 自己紹介
  7. 7. 矢島 卓Taku YAJIMA(@quindim)at Ateam Inc.(2011~)■Ops Engineerwith Infrastructure(current)■DeveloperWeb ApplicationAndroid Application■OtherScrum MasterCheer Leaderoutside the company■DevLOVE(Nagoya)■Super Sentai Studyand more...
  8. 8. jus研究会 名古屋大会RedmineCopyright (C) 2009 Martin Herr2013/6/22 Open Source Conference 2013 NagoyaTaku YAJIMA(@quindim)でプロジェクトを【見える化】しよう!
  9. 9. 本日言いたいコト
  10. 10. 現場のコミュニケーションを見える化しよう!
  11. 11. 本日お話する事
  12. 12. •基本的なRedmineの説明•基本的な社内Redmineの使われ方•基本的な「見える化」の話
  13. 13. 本日お話しない事
  14. 14. •プロジェクトマネジメント方面に寄り過ぎる話→工数管理,ガントチャート•開発方面に寄り過ぎる話→ TiDD, CI連携,VCS連携,コードレビュー,etc...
  15. 15. http://itpro.nikkeibp.co.jp/article/Watcher/20130521/478496/ちなみに先日こんな記事が
  16. 16. http://itpro.nikkeibp.co.jp/article/Watcher/20130521/478496/
  17. 17. http://itpro.nikkeibp.co.jp/article/Watcher/20130521/478496/IT現場が導入すべき「新3種の神器」
  18. 18. http://itpro.nikkeibp.co.jp/article/Watcher/20130521/478496/• Redmine• Jenkins• Chef
  19. 19. http://itpro.nikkeibp.co.jp/article/Watcher/20130521/478496/そんな紹介をされています
  20. 20. PM/情報共有ツール
  21. 21. http://itpro.nikkeibp.co.jp/article/Watcher/20130521/478496/母集団「直近2年間でPM/情報共有ツールを利用したことがある」と回答した回答者
  22. 22. • Redmine ?• MS-Project ?• JIRA,TFS,Trac?• or …any Spreadsheet?
  23. 23. ありがとうございます!
  24. 24. Copyright (C) 2009 Martin Herr~導入部分終了です
  25. 25. 本日のアジェンダ
  26. 26. ・Redmineとは?・弊社での活用事例・何を「見える化」する?
  27. 27. ・Redmineとは?・弊社での活用事例・何を「見える化」する?
  28. 28. Copyright (C) 2009 Martin Herr
  29. 29. Copyright (C) 2009 Martin HerrProjectManagementSoftware
  30. 30. Copyright (C) 2009 Martin HerrIssueTrackingSystem
  31. 31. Copyright (C) 2009 Martin Herr・プロジェクトマネジメント・バグトラッキング・関係者との情報共有・日々のタスク管理Use Cases
  32. 32. Copyright (C) 2009 Martin Herr• MS-Project• JIRA• Trac• BTS(Mantis,影舞)Similar Products
  33. 33. Copyright (C) 2009 Martin Herr事例
  34. 34. http://bugs.ruby-lang.orghttp://projects.puppetlabs.com
  35. 35. Copyright ©Rakuten, Inc.国内事例:楽天株式会社http://www.slideshare.net/daipresents
  36. 36. Copyright (C) 2009 Martin Herrの基本
  37. 37. ・Webベース・RubyOnRails・OpenSource・GPLライセンス
  38. 38. Copyright (C) 2009 Martin Herrの構成要素
  39. 39. ・プロジェクト・チケット・Wiki
  40. 40. プロジェクト
  41. 41. プロジェクトAプロジェクトBプロジェクトA-1プロジェクトA-2
  42. 42. プロジェクトAプロジェクトBプロジェクトA-1プロジェクトA-2各プロジェクト単位で情報の集約が可能(チケット/Wiki/etc)
  43. 43. チケット(Ticket)
  44. 44. チケット(Ticket)いわゆる「Issue」プロジェクトの中で発生している「課題や問題、タスク」
  45. 45. Issue1件につき1件のチケットを作成内容/優先度/担当者期日/進捗状況を記録していく
  46. 46. 「ワークフロー」制御作業依頼者 開発者
  47. 47. 「ワークフロー」制御新規作業依頼者 開発者
  48. 48. 「ワークフロー」制御新規担当作業依頼者 開発者
  49. 49. 「ワークフロー」制御新規担当完了作業依頼者 開発者
  50. 50. 「ワークフロー」制御新規担当完了確認完了作業依頼者 開発者
  51. 51. Wiki
  52. 52. Wikiプロジェクトに関わる文書をWebブラウザ上で編集しハイパーテキストで整理できる仕組み
  53. 53. Copyright (C) 2009 Martin Herrザックリ整理すると
  54. 54. Copyright (C) 2009 Martin Herr「プロジェクト」に関わる「課題/TODO/関連文書」と言った情報群を集約して管理できる仕組み
  55. 55. Copyright (C) 2009 Martin Herr例えば
  56. 56. Copyright (C) 2009 Martin HerrITSの無いプロジェクト
  57. 57. プロジェクトA_タスク一覧.xls
  58. 58. Copyright (C) 2009 Martin Herr
  59. 59. Copyright (C) 2009 Martin Herr•複数バージョンの乱立→同時編集に適さないため→○○_最新版.xls→○○_最新版_YYYYMMDD.xls•情報記載の限界→「セル」に収まらない→1行で1画面占拠、等
  60. 60. Copyright (C) 2009 Martin Herr苦し紛れの策
  61. 61. 1タスク=1ファイル
  62. 62. 1タスク 1ファイルちょwww
  63. 63. Copyright (C) 2009 Martin HerrITSのあるプロジェクト
  64. 64. Copyright (C) 2009 Martin Herr
  65. 65. Copyright (C) 2009 Martin Herr
  66. 66. Copyright (C) 2009 Martin Herr•同時閲覧、編集(※)が可能→更新時のメール通知有り•操作履歴の保存→変更点の確認が容易•長文もOK
  67. 67. Copyright (C) 2009 Martin Herrその他の便利な機能
  68. 68. Copyright (C) 2009 Martin Herr•ガントチャート–工期記入済チケットから自動生成•マイルストーン–リリースバージョン等の管理•リポジトリブラウザ–ソースコードの閲覧•フォーラム–議論のための場をRedmineに設置
  69. 69. Copyright (C) 2009 Martin Herrプラグインを利用した拡張も可能
  70. 70. Copyright (C) 2009 Martin Herr一連のデモ
  71. 71. Copyright (C) 2009 Martin Herrデモ終了
  72. 72. ・Redmineとは?・弊社での活用事例・何を「見える化」する?
  73. 73. •Redmineとは–WebベースのITS–RubyOnRails製のOSS•プロジェクト毎に情報を集約–チケット、Wiki–多人数での同時利用に適する
  74. 74. Copyright (C) 2009 Martin HerrRedmineとは?終了です
  75. 75. ・Redmineとは?・弊社での活用事例・何を「見える化」する?
  76. 76. ところで
  77. 77. •2軸のWeb系事業で成長中–ライフサポート事業–エンターテインメント事業•経営理念–みんなで幸せになれる会社–今から100年続く会社
  78. 78. 「名古屋」から「世界」を変える
  79. 79. BtoC主体事業モデル
  80. 80. 内製中心(一部委託開発有)開発スタイル
  81. 81. 開発スタイル運用開発S-INメンバー(ほぼ)固定
  82. 82. 良くあるチームのスタイル
  83. 83. 例:ライフ系サービスProductOwnerSalesDesignPlanning &PromotionProgramming
  84. 84. 例:ライフ系サービス
  85. 85. 例:スマートフォンアプリPromotionCustomerSupport
  86. 86. 例:スマートフォンアプリ
  87. 87. 活用事例
  88. 88. 活用事例• Webサービスの運用• Scrumでの利用• 外部デバッグへの対処• 問い合わせ対応
  89. 89. 活用事例• Webサービスの運用• Scrumでの利用• 外部デバッグへの対処• 問い合わせ対応
  90. 90. ProductOwnerBusinessDesignPlanning &PromotionProgramming
  91. 91. ProductOwnerBusinessDesignPlanning &PromotionProgramming• リリース済みサービス• 改修要件が複数名から(営業担当,編集担当)• サービスの質を担保→POの承認を要する
  92. 92. ProductOwnerBusinessDesignPlanning &PromotionProgrammingチケットの「ワークフロー」を活用
  93. 93. 企画/編集者プロダクトオーナー 開発者
  94. 94. 新規/承認待ち
  95. 95. 新規/承認待ち 承認
  96. 96. 新規/承認待ち開発承認
  97. 97. 新規/承認待ち開発開発完了承認テスト完了
  98. 98. 新規/承認待ち開発開発完了承認テスト完了リリース承認
  99. 99. 新規/承認待ち開発開発完了承認テスト完了リリース承認リリース完了確認完了
  100. 100. 新規/承認待ち開発開発完了承認テスト完了リリース承認リリース完了確認完了元々存在していた業務フローをシステムに載せる
  101. 101. 新規/承認待ち開発開発完了承認テスト完了リリース承認リリース完了確認完了チームによっては、機能単位でメンバーを分けた「プロジェクト」制を取り、そのプロジェクト単位で承認権限を持たせている
  102. 102. 活用事例• Webサービスの運用• Scrumでの利用• 外部デバッグへの対処• 問い合わせ対応
  103. 103. Scrumの各場面でRedmineを活用
  104. 104. Scrumとは・自律改善型チームを育て・優先順位の高い機能を・繰り返し価値に変え届ける・仕組み(フレームワーク)アジャイル開発手法の1つ
  105. 105. 3つの役割・プロダクトオーナー・開発チーム・スクラムマスター3つのイベント・スプリント計画会議・デイリースクラム・スプリントレビュー3つの成果物・プロダクトバックログ・スプリントバックログ・バーンダウンチャート
  106. 106. プロダクトオーナー優先順位・利益の責任者スクラムマスター規律を守り皆を促す【Scrumの守り人】開発チーム自己組織化された【生み出す人】
  107. 107. プロダクトバックログ会員登録ができる 5会員は予約ができる 5お知らせを登録できる 3イベントを登録できる 3会員は退会ができる 1会員は決済ができる 13優先順位付けられた機能一覧スプリントバックログスプリント内のタスク一覧バーンダウンチャート可視化された進捗グラフ
  108. 108. 月 火 水 木 金 月 火 水 木 金朝一午前午前午後午後デイリースクラム(朝会):1回15分以内スプリント計画会議:やる事決めスプリントレビュー:動く物を見せるふりかえり(KPT等)スプリント(1開発期間)内のMTG
  109. 109. 期間固定のスプリントを繰り返す月 火 水 木 金 月 火 水 木 金前後月 火 水 木 金 月 火 水 木 金前後計画して ふりかえる 計画して ふりかえる
  110. 110. http://www.scrumprimer.org/anime
  111. 111. http://www.redminebacklogs.net
  112. 112. ・プロダクトバックログの管理→「スプリント」ごとに分割・スプリントバックログの管理→「タスクかんばん」様式・バーンダウンチャートの表示
  113. 113. ・プロダクトバックログの管理→「スプリント」ごとに分割・スプリントバックログの管理→「タスクかんばん」様式・バーンダウンチャートの表示
  114. 114. ・プロダクトバックログの管理→「スプリント」ごとに分割・スプリントバックログの管理→「タスクかんばん」様式・バーンダウンチャートの表示
  115. 115. ・プロダクトバックログの管理→「スプリント」ごとに分割・スプリントバックログの管理→「タスクかんばん」様式・バーンダウンチャートの表示
  116. 116. ・プロダクトバックログの管理→「スプリント」ごとに分割・スプリントバックログの管理→「タスクかんばん」様式・バーンダウンチャートの表示
  117. 117. ・プロダクトバックログの管理→「スプリント」ごとに分割・スプリントバックログの管理→「タスクかんばん」様式・バーンダウンチャートの表示
  118. 118. ・プロダクトバックログの管理→「スプリント」ごとに分割・スプリントバックログの管理→「タスクかんばん」様式・バーンダウンチャートの表示
  119. 119. 一連のデモ
  120. 120. デモ終了
  121. 121. に加え・RedmineのWikiを利用して「ふりかえり(KPT)」を記録・ホワイトボードを利用しプロジェクトの状態を「可視化」
  122. 122. Scrumの各場面でRedmineを活用
  123. 123. デジタルツールですぐに出来ない事はアナログを利用
  124. 124. 活用事例• Webサービスの運用• Scrumでの利用• 外部デバッグへの対処• 問い合わせ対応
  125. 125. スマートフォンアプリ開発
  126. 126. 自社開発チーム開発委託企業デバッグ企業
  127. 127. かつての社外デバッグ
  128. 128. 現象 条件 詳細 再現性○○○ ○○ ・・・・・・ ・・・・・・△△△ △△ ・・・・・・ ・・・・・・□□□ □□ ・・・・・・ ・・・・・・デバッグ依頼結果表作成結果表送付
  129. 129. 現象 条件 詳細 再現性○○○ ○○ ・・・・・・ ・・・・・・△△△ △△ ・・・・・・ ・・・・・・□□□ □□ ・・・・・・ ・・・・・・デバッグ依頼結果表作成結果表送付・依頼から結果受け取り→リードタイム1日・対応がエクセル中心→同時編集に適さない→スクリーンショット問題
  130. 130. 新たな取り組み
  131. 131. ・デバッグにRedmineを利用→専用プロジェクトを作成し、外部企業との権限を分離・デバッグ担当はバグ発見時に都度チケットを発行し、POがその対応判断をおこなう
  132. 132. バグ発見 判断
  133. 133. バグ発見修正判断修正対応不要
  134. 134. バグ発見修正修正完了判断確認修正対応不要修正完了
  135. 135. バグ発見修正修正完了判断再確認確認修正対応不要修正完了
  136. 136. バグ発見修正修正完了判断再確認確認修正対応不要修正完了これをチケット化
  137. 137. バグ発見修正修正完了判断再確認確認修正対応不要修正完了・依頼から結果受け取り→チケット記載後、即時・1チケット 1課題→対応状況がリアルタイムに→スクリーンショット添付
  138. 138. バグ発見修正修正完了判断再確認確認修正対応不要修正完了一連のデモ
  139. 139. バグ発見修正修正完了判断再確認確認修正対応不要修正完了デモ終了
  140. 140. 活用事例• Webサービスの運用• Scrumでの利用• 外部デバッグへの対処• 問い合わせ対応
  141. 141. 例:管理部門 + 技術部門TechDivisionControlDivision
  142. 142. 例:管理部門 + 技術部門TechDivision社内問い合わせControlDivision
  143. 143. 例:管理部門 + 技術部門TechDivision社内問い合わせ技術質問等ControlDivision
  144. 144. 例:管理部門 + 技術部門TechDivision社内問い合わせ技術質問等回答等ControlDivision
  145. 145. 例:管理部門 + 技術部門TechDivision社内問い合わせ技術質問等回答等ControlDivision•Before–メールベースでの個別対応–発生事象 および 対応の記録はメールと個人の頭の中に存在
  146. 146. 例:管理部門 + 技術部門TechDivision社内問い合わせ技術質問等回答等ControlDivision•After(Redmine利用)–事象の記録、質問、回答のやりとりをチケット上で運用–体系化されたノウハウはWikiへ集約
  147. 147. 例:管理部門 + 技術部門TechDivision社内問い合わせ技術質問等回答等ControlDivision•チケットに残された情報は後から誰もが検索・参照可能–チケットが「緩い手順書」•やり取りの流れが「今」「どこで」「誰で」停滞しているかが一目瞭然
  148. 148. ・Redmineとは?・弊社での活用事例・何を「見える化」する?
  149. 149. •Webサービスの機能改修に–適切な承認経路を持たせた運用•Scrumプロジェクトに–Backlogsを利用した運用•ゲームデバッグ時のバグ管理に–チケットを利用した社外連携•その他、様々な場面に
  150. 150. Copyright (C) 2009 Martin Herr自社活用事例終了です
  151. 151. ・Redmineとは?・弊社での活用事例・何を「見える化」する?
  152. 152. いま我々のプロジェクトで何がどのように起こりどう進行しているのか?
  153. 153. いま我々のプロジェクトで何がどのように起こりどう進行しているのか?
  154. 154. いま我々のプロジェクトで何がどのように起こりどう進行しているのか?人と人とのコミュニケーションが発生するポイント
  155. 155. まずは「見える化」そして「共同所有」する事が肝心
  156. 156. つまりコミュニケーションの「見える化」「共同所有」
  157. 157. ソフトウェアを利用しない「見える化」や「共同所有」は容易
  158. 158. 「見える化」「共同所有」する事で「我々の場」の状況が分かる
  159. 159. 「場の状況」が分かると「不便な事」が見えてくる
  160. 160. その「不便な事」がカイゼンの対象
  161. 161. 今回紹介した事例は見える化された不便な事をツールで効率化しただけ
  162. 162. ツールが「何」を解決するのか
  163. 163. ツールがどのような「不便な事」を解決するのか
  164. 164. 便利そうだからツール置いたは非常に危険
  165. 165. 廃れるのが容易に想像できる
  166. 166. アジャイルマニフェスト
  167. 167. アジャイルソフトウェア開発の原則
  168. 168. • プロセスやツールよりも人と人同士の相互作用を重視• 包括的なドキュメントよりも動作するソフトウェアを重視• 契約交渉よりも顧客との協調を重視• 計画に従うことよりも変化に対応することを重視
  169. 169. • プロセスやツールよりも人と人同士の相互作用を重視• 包括的なドキュメントよりも動作するソフトウェアを重視• 契約交渉よりも顧客との協調を重視• 計画に従うことよりも変化に対応することを重視
  170. 170. 人と人の相互作用が最大化されるような使われ方
  171. 171. ツールが廃れないためには工夫が必要
  172. 172. Copyright (C) 2009 Martin Herr例えばにも工夫が必要
  173. 173. •利用を強制(義務化)–メリットを皆が実感していない状況での強制は…•つい見に来てしまう–「楽しい」感情と共に利用される状況があると嬉しい
  174. 174. •利用を強制(義務化)–メリットを皆が実感していない状況での強制は…•つい見に来てしまう–「楽しい」感情と共に利用される状況があると嬉しい
  175. 175. そんな時に知ったRedmineを「つい見に来てしまう」仕組み
  176. 176. RedmineMicrobloghttps://github.com/dabits/redmine_microblog@dabits
  177. 177. Redmine Microblog•TwitterライクなPlugin–短い投稿の連続により作られるタイムライン•空間ごとにタイムラインが存在–Redmine全体–プロジェクト別
  178. 178. 何か面白い事書いてあるかなー
  179. 179. フラッと見に来る
  180. 180. 人と人の相互作用が最大化されるような使われ方
  181. 181. Copyright (C) 2009 Martin Herr何を見える化するか?終了です
  182. 182. 本日言いたいコト
  183. 183. 現場のコミュニケーションを見える化しよう!
  184. 184. 見える化されたコミュニケーションをツールで更に便利に!
  185. 185. Copyright (C) 2009 Martin Herr例えばも、その1つ
  186. 186. Copyright (C) 2009 Martin Herr様々な場面で活用できる
  187. 187. Copyright (C) 2009 Martin Herrいつインストールするの?
  188. 188. Copyright (C) 2009 Martin Herr今でしょ!!
  189. 189. かんたん!2つの選択肢・BitNami::Redmine・ALMiniumCopyright (C) 2009 Martin Herr
  190. 190. ・対応OS→Windows→VM Ware・ワンクリックインストール→apache,ruby,mysql,Subversion,Git
  191. 191. ・Linux用インストーラ→CentOS6,SientificLINUX・周辺ツールの一括Install→各種VCS,Jenkins(CIツール)・各種Pluginを一括Install→Backlogs,CodeReview,etc…
  192. 192. ※CleanなOS環境で実行# yum install git# git clonehttps://github.com/alminium/alminium.git# cd alminium# bash ./smelt
  193. 193. 続きはエイチームでRedmine 使ってみたい
  194. 194. ご清聴ありがとうございました

×