チケット駆動開発の大切なこと（バランス編）
•
15 likes•12,639 views
2013年8月24日GxP様 無料セミナー『SIの現場で使えるチケット駆動開発』での講演資料
Recommended
More Related Content
What's hot
What's hot (20)
Similar to チケット駆動開発の大切なこと（バランス編）
Similar to チケット駆動開発の大切なこと（バランス編） (20)
More from Makoto SAKAI
More from Makoto SAKAI (20)
チケット駆動開発の大切なこと（バランス編）
- 2. 自己紹介 • 阪井誠（さかば、Twitter: @sakaba37） • ソフトウェアプロセス、チケット駆動開発(ＴｉＤＤ)、 アジャイルに興味を持つ「プロセスプログラマー」 • 現場からコンサル・研究まで、論文、書籍、雑誌など 2 レ ビ ュ ー NEW NEW NEW
- 3. ソフトウェア開発の大切なこと • 技術のコンテキスト（背景）を考える – パラダイムシフト（生産性の向上、リスクの変化、etc.） – 弁証法的な視点（補完関係・対立構造、揺り戻し） • 現実の問題のバランスをとる – 管理と自律 – 組織とチーム • 戦略的に全体最適をねらう – 防水透湿性素材 – サーバントリーダーシップ – 実践のバランスと視点 3
- 4. 目次 • ソフトウェア開発の大切なこと • コンテキスト – パラダイムシフト – 日本のソフトウェア管理・開発の歴史 • チケット駆動開発 – はじまり、バージョン管理とチケット – ツール連携とチケット・コミュニケーション支援 – 事例 • バランスと戦略 – 対立から協調へ（防水透湿性素材） – 自律と支援（サーバントリーダーシップ） – 実践のバランスと視点 4
- 6. ソフトウェア業界のパラダイムシフト • 1990年代に始まった • ネオダマという標語によってソフトウェアハウスは ＳＩ ｅｒに変わった • 高機能ソフトの開発が容易になり、自由度が増し た反面、リスクが増えた • 技術者の守備範囲はソフトからシステムになり、 今、ビジネスに広がりつつある • 常に新しい分野へのチャレンジが求められるよう になった 6
- 8. 技術者の責任範囲 • 開発の効率化とともに責任範囲は広がった – ビジネスは広がったが純粋なソフトウェア開発が 減少した 8 ソフトウェア ハードウェア ビジネス ネットワーク ネオダマ Ｗｅｂ クラウド
- 9. 要求の不安定さ • ハンフリーは機能・インタフェース・環境の変更は 管理されないと開発は不安定になるとした • Watts S. Humphrey, ソフトウェアプロセス成熟度の改善, 日科技連, 1991. 未知の要求 知っているつもりが、 使ってみて違いに気 づく 誤解された要求 実現するために必 要な詳細を理解して いない 不安定な要求 大体わかっているか もしれないが、詳細 は流動的 • プロトタイプ、分離、段階的な開発など、アジャイル やオブジェクト指向につながる提案をしている
- 10. 日本のソフトウェア管理・開発の歴史 – 日本の従来企業では組織的な管理活動が普及したが、 チームの開発支援が遅れている – ゲーム・Webサービスなど新規ビジネスを中心にアジャイ ル開発の導入が進んでいる 10 組織的管理 プロジェクト管理 現場の自律性 1980s 成果物標準化 メトリクス QCサークル 1990s CMM/CMMI ISO9000 PMBOK (TSP) (People CMM) (PSP) 2000s (アジャイルと規律) XP、ファシリテーション (他のアジャイル開発) 2010s (ISO/IEC29110) スクラム リーン
- 11. 日本のソフトウェア産業の特徴 • ビジネスとの距離が離れている – 1990年代のRADのスキップにより、ビジネス価値、プロトタイ プ、マルチリリースへの対応が遅れた • 既存の業務で実現している細かな要望が多い – 新規開発が少ない。リプレスは一括 （バグまで同じに、） • DOAの普及によるオブジェクト指向普及の遅れ* – アジャイル開発向きでない組織構造 (「善は急げ」より「急がば回れ」） *児玉，UMLモデリングの本質 第2版 11
- 12. 日本のソフトウェア管理・開発の歴史 求められるもの • ビジネスへの適応力（変化への対応、自律性） • 組織とチームの全体最適（オープンなプロジェクト運営） 12 組織的管理 プロジェクト管理 現場の自律性 1980s 成果物標準化 メトリクス QCサークル 1990s CMM/CMMI ISO9000 PMBOK (TSP) (People CMM) (PSP) 2000s (アジャイルと規律) XP、ファシリテーション (他のアジャイル開発) 2010s (ISO/IEC29110) スクラム リーンチケット駆動開発
- 13. 具体的な課題 • プロセス改善がレベル3（定義されたプロセス）で 止まり、チームの自律性が低い – チームの能力が生かせていない – 情報共有に基づく、チームの自律的な行動が必要 • アジャイル開発が組織的に可視化されていない – チームの個別性が高く、複数プロジェクトを一貫して 管理することが困難 – 電子化された可視化情報が必要 ＝＞チケット駆動開発なら解決できます！ 13
- 17. 目次 • ソフトウェア開発の大切なこと • コンテキスト – パラダイムシフト – 日本のソフトウェア管理・開発の歴史 • チケット駆動開発 – はじまり、バージョン管理とチケット – ツール連携とチケット・コミュニケーション支援 – 事例 • バランスと戦略 – 対立から協調へ（防水透湿性素材） – 自律と支援（サーバントリーダーシップ） – 実践のバランスと視点 17
- 18. ＴｉＤＤのはじまり • masuidrive的プロジェクトの方針(2007) http://blog.masuidrive.jp/index.php/2007/07/11/masuidrive-working-style/ • まちゅ, 「もうひとつのTDD」, ITpro Challenge のライト ニングトーク http://www.machu.jp/diary/20070907.html#p01 • Ｓｈｉｂｕｙａ.Ｔｒａｃキックオフ • XPJUG関西 TiDD勉強会発足 (2008) • 「Redmineによるタスクマネジメント実践技法」(2010) • RxTstudy、Ｓｈｉｎａｇａｗａ.Ｒｅｄｍｉｎｅ(2011) • 「チケット駆動開発」(2012) ： 18 Ｔｒａｃブーム チケット駆動開発 誕生
- 19. チケット駆動開発 • ＩＴＳ（ＢＴＳ）のチケットで障害、課題、タスクを 管理して個人のタスクとプロジェクトを管理する • 構成管理、Ｗｉｋｉ、継続的統合などツールを チケットに連携させて自動化する • プロジェクトの情報をチケットに関連付けて 管理することで、コミュニケーションを支援する 現場による、現場のための改善活動 プロジェクトの関心事の電子化 19
- 20. バージョン管理とチケット（仕様変更） 20 仕様変更 タスク１ タスク2 新規追加 更新 更新 タグ 競合チェックアウト アップデート 解決 関連タスク トレーサ ビリティ
- 27. パラダイムシフトを生き抜くには • 環境、フレームワーク、ユーザーインタフェース、ビジ ネスは日々変化している • ソフトウェア開発は、常に挑戦！ • 開発中にノウハウやアイデア、気づきを蓄積し、共有 し、活用しないといけない チケット駆動開発を活用して、現場の自律とリスクの低 減を実現した事例を紹介します 27
- 28. TiDDによる自律とリスク低減の実現 • 開発時の履歴をその後の開発につなげます • 開発者の気付きをチケットに記録します • 協調作業を支援してプロジェクトを活性化します 28 ハーケン(釘) カラビナ(止め具) ザイル(ロープ)
- 29. チケット駆動開発の効果 ツールを有効活用してプロジェクトの負担を減らす • ツールが想定するプロジェクトに近づく • 過去： – 履歴の蓄積(経緯の確認、ノウハウの利用) • 現在： – 障害、課題、タスク、実行結果の管理 – 情報共有、自動化、コミュニケーション • 未来： – 計画、備忘録、リスクの見える化 29
- 30. 事例の概要 • 文教パッケージのカスタマイズ(最大8人x1年) o 短納期 ＆ 仕様の決定遅れ・変更 o スキルは高いが経験者が少ない(リーダは途中交代) o オープンフレームワークの初めての組み合わせ （サブシステム、ミドルウェアのバージョン） o 義務感と不安、重苦しい雰囲気、閉塞感、、、 o 守りに入るので、コミュニケーションが悪い システムテストの時期になると、計画外の環境構築やリリース準備 作業が明らかになった（環境に関連するバグも、、、） ⇒ そうだ！チケット駆動開発をしよう！ 30
- 31. オープンなフレームワークの苦しみ 長所 • 同じようなコードが減る • 個別の業務要件に対する固有の開発だけでよい 短所 • お約束が多い複雑な作業で、気が抜けない • 工夫できる余地が少ない • 少人数で大規模なシステムが作れてしまう • セキュリティ対策で実行環境の構成は日々変化 ⇒ 煩雑なのに情報が少ない、、、大変！ 31
- 32. TiDDの実施方式 • アダプタブルウォーターフォール(補完型ＴｉＤＤ） • WBSと併用（と言っても更新作業は全てチケットあり） • オープンな運用 • だれでもチケットが作成できる • システムテスト以降 • システム全体 • メンバー全員 • trac（単独） ・・・ SRA共通開発環境（trac,subversion,mailmanの仮想環境）
- 33. チケット駆動開発の導入 • 宣言と実行 「 バグだけではなく、ソースを触るときや、WBSにない作業をするとき は、チケットを登録してください！」 • 環境の準備 o レポート(チケットの一覧)の作成 bugのみ、 taskのみ、 その他、など o 権限の追加 tracの権限の設定が堅かったので、チケットを修正できるように 全ての権限を与えた（リスクを考慮して設定してください) • 教育 • パッケージチームとのＱＡの経験はあった 33 ハーケン(釘) カラビナ(止め具) ザイル(ロープ)
- 34. 結果 • チケットの数(BUG以外) o システムテスト：３１ o 本番環境構築：４２ データの準備、環境準備、BUG関連で増えた作業、 細かな仕様変更など、手順書にない1回だけの作業 • 作業漏れ減少！納期までに作業が完了！ (知らないこと、気付かないことはできませんでした、、、orz) それ以外にも、メンバーに変化が、、、 34
- 35. 目が輝いた！ サブリーダ(クラス)なのに遠慮をして いたメンバーが、生き生きしだした • 「チケットを切ってもいいですか？」 ⇒ 義務的な作業からの解放 • 「チケットを切っておかないと忘れてしまう！」 ⇒ すぐに使いこなしていた • 「ちゃんとクローズしてね」 ⇒ 他の人に指導をしていた！ • 「残っているチケットが多くてわかりにくいから整理 しますね」 ⇒ 今後のことも考えている
- 36. 事例のまとめ • システムテスト以降にTiDDを導入 • 備忘録のつもりで気づいたことをチケット化した • 手順はＷｉｋｉにまとめた • 計画外の作業を管理できた • 作業を見える化することで コミュニケーションが向上した • メンバーが前向きになり、 プロジェクトが元気になった 36
- 37. 事例からの学び • 新しい環境、実装方法、アプリケーションに挑戦 するには、以下の点を考慮しないといけない – 気づいたことが共有されること – 少ない経験が蓄積されること – 蓄積した経験が生かせること ふさわしいチケット駆動開発の運用方法が必要 37
- 38. テーラリング１： 気づいたことが共有されること • チケットが容易に起票できるようにする – 起票の権限をメンバーに与える – ワークフローの制限を少なくする • チケットの種類や属性を増やしすぎない – 考えなくて良い様にする – 記入項目を減らす • リアルタイムに共有してモチベーションを高める – メール、RSS、Eclipseとの連携 – コミュニケーションのタイムラグ減ると利用が増える 38
- 39. テーラリング２： 少ない経験が蓄積されること • チケット駆動を習慣づける – 基本的な教育 – メリットを感じさせる – 備忘録としての利用 • 利用に向けた支援 – カスタムレポートの用意など環境整備 – アドバイスのための棚卸し – ルールの整備 (“No Ticket, No, Commit!!”をどこまで守るか、など) 39 ハーケン(釘) カラビナ(止め具) ザイル(ロープ)
- 40. テーラリング３： 蓄積した経験が生かされること • 経験の種類に応じて整理する – 一度だけの作業はチケットを起票する – 手順やチェックリストはＷｉｋｉにまとめる • 書きっぱなしのチケットを防ぐ – 完了条件を明確にする – 適切な棚卸しをする • 発想力・提案力の向上 – 棚卸しの頻度を増やしすぎない – 自律的なチーム 40
- 41. 課題と可能性 • CBR(Case Based Reasoning)の経験による問題 解決する際にはインデックスが重要とされている – 現状では日々の情報整理が必要 – チケット駆動開発の事例報告が少ない – より多くの事例を集めて整理したい • チケットシステムの活用でリスクが低減できる 可能性がある – ソフトウェア開発は常に挑戦だと認識する – チケット駆動開発を活用する – 発想力・提案力のあるチーム作りをする 41
- 42. 目次 • ソフトウェア開発の大切なこと • コンテキスト – パラダイムシフト – 日本のソフトウェア管理・開発の歴史 • チケット駆動開発 – はじまり、バージョン管理とチケット – ツール連携とチケット・コミュニケーション支援 – 事例 • バランスと戦略 – 対立から協調へ（防水透湿性素材） – 自律と支援（サーバントリーダーシップ） – 実践のバランスと視点 42
- 43. バランスと戦略 • 全てのモデルは単純化されている – 単純化できないことに気を付ける – 多様性のない開発は脆弱で非効率 – 全体主義でも部分最適でもなく、全体最適のバランスを 目指す • 能力を最大限に発揮させる* – 管理だけではリスクをカバーできない – 早期発見と戦略的解決には、自律を促す管理が必要 • 実践のバランスと視点が重要 * W・ハンフリー， TSP ガイドブック：リーダー編，翔泳社， 2007． 43
- 44. 対立から協調へ • 組織とチームには、管理の都合と開発の都合の せめぎあいがある – 開発標準は肥大化する傾向にあり、テーラリングの 許容範囲は狭くなりがち – プロジェクトはゴールに向かって暴走しがち – 情報共有に基づく合理的な判断、組織内での協調、 チームの保護が必要 44 組織 チーム マネージャ SEPG、SQA、 PO リーダー （SQA） SM 開発者 集合性（かや） P.30* 私たちが、何かを行動に移 すとき、実は、「かや」の行 動の一部を演じている ＊杉万，「グループ ダイナミックス入門」 ， 世界思想社，2013．
- 45. 対立から協調へ • 防水透湿性素材 – チームを守る防火壁*は途中経過も隠ぺいする – チケットシステムや途中の成果物を公開することで、 組織的な活動とのバランスをとる * James O. Coplien他，組織パターン，2013． 45 組織 チーム 成果物 チケット 進捗 メトリクス（尺度） トレーサビリティ ・門番 ・プロダクトの主導者 ・防火壁 ・プライベートな パージョニング ・スタンドアップ ミーティング ・スケジュールを 小分けにする ・ワークキュー・聴衆の参加
- 46. 自律と支援 リーダーシップは国により異なる* • 目標達成リーダーシップ – 日本では「部下が最大限に働くことを要求」 – アメリカでは「契約を順守することを要求」 • 人間関係円滑化リーダーシップ – 日本では「個人的な問題にも気を使う」 – アメリカでは「上司が首を突っ込んではいけない」 • 良きリーダー – 日米では、上記2種類のリーダシップが必要 – 中国では「徳（仁徳）のリーダーシップが必要」 ＊杉万，「グループダイナミックス入門」 ， 世界思想社，2013． 46 ゴールを示して、 能力を最大限に 発揮させる 細かなことは 言わないで、 気を使う 責任を持つ 親分肌
- 47. 自律的なチーム作り • サーバントリーダーシップ – コマンドコントロールをやめ、 メンバーが能力を生かせるように支援する • マクロマネジメント – マイクロマネジメントをすると依存するようになり、 自律性が失われる • 濡れぞうきんはしぼらない – 本田宗一郎氏がＩＩＪ鈴木幸一社長に送った言葉 – ガチガチの管理からは柔軟な発想は生まれない 47
- 48. 実践のバランスと視点 • バランス – パラダイムシフト・効率化 • 大きく変えるか、小さく変えるか • 大きく変えるときは一つずつ成功体験を積み上げる – 暗黙知・形式知 • 暗黙知だけでは再利用が難しい • 形式知だけでは伝わらない（TiDDには長い朝会が必要） – ツールによる自動化・ 人中心の支援 • ツールによる自動化は、手段が目的化しやすい • 人中心の支援は無駄な作業に注意し、自動化も考える 48
- 49. 実践のバランスと視点 • 平準化とリズム – 平準化により作業が安定すればリズムが生まれ、習 熟と効率化が可能になる • 能力発揮：負担軽減・情報共有 – 無駄をなくし、負担を軽減することで、より高度な作業 が可能になる – 情報共有はノウハウを蓄積し、再発明を防止する • ジャストインタイム – 不要な情報は管理の負担。情報は必要最低限に絞る – 選択肢を残すべく、決定をなるべく遅らせることも必要 49
- 50. 例：放置されるチケット • チケットがルーチンワークでないと登録を忘れがち • メリットと必然、チケットへの依存、リズム • 他のチケットがないときにチェックを忘れて実施漏れ • 粒度の大きいチケットの後で発生 • 粒度が小さいとリズムが生まれて、発生しにくい • 棚卸のバランス • 防げるが自主性も大切！「チケット見てる？」 • クローズしにくいもの (担当がない、チェックリスト的) • 課題、リスクに多い。棚卸し、 Wikiを利用する • 気が付かないことはチケットにできない • 自由な雰囲気、経験者への依頼、情報収集が必要 50
- 51. おわりに • 多様性のない開発は脆弱で非効率 – バランスと戦略がポイント • パラダイムシフトによりリスクは増え続けている – 自律的なチーム作りが重要 • チケット駆動開発 – プロジェクトの情報を集中管理 – 気づきや経験を蓄積して活用 – 自動化やコミュニケーションの支援ができる – バランスと戦略が大切 => ぜひ皆さんも活用してください 51