Downloaded 41 times
![15
変更リスクへの対応力
* [#TiDD] アジャイル風開発ラフシミュレーション（ソフトウェアさかば）
http://sakaba.cocolog-nifty.com/sakaba/2013/03/tidd-14ae.html](https://image.slidesharecdn.com/random-130825075241-phpapp01/85/slide-15-320.jpg)
![スマホゲームのチート手法とその対策 [DeNA TechCon 2019]](https://cdn.slidesharecdn.com/ss_thumbnails/techcon2019funakubo-190218065153-thumbnail.jpg?width=640&height=640&fit=bounds)
![[デブサミ関西2013]チケット駆動で プロジェクトチームを加速せよ](https://cdn.slidesharecdn.com/ss_thumbnails/kansumi2013b4yusukesuzukishare-130923191745-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
![[Node-RED] ファンクションノードのデバッグどうしてる？](https://cdn.slidesharecdn.com/ss_thumbnails/debugstyleoffunctionnode-190530142737-thumbnail.jpg?width=640&height=640&fit=bounds)
チケット駆動開発の大切なこと（バランス編）
- 1.
- 2. 自己紹介 • 阪井誠（さかば、Twitter: @sakaba37） •ソフトウェアプロセス、チケット駆動開発(ＴｉＤＤ)、 アジャイルに興味を持つ「プロセスプログラマー」 • 現場からコンサル・研究まで、論文、書籍、雑誌など 2 レ ビ ュ ー NEW NEW NEW
- 3. ソフトウェア開発の大切なこと • 技術のコンテキスト（背景）を考える – パラダイムシフト（生産性の向上、リスクの変化、etc.） –弁証法的な視点（補完関係・対立構造、揺り戻し） • 現実の問題のバランスをとる – 管理と自律 – 組織とチーム • 戦略的に全体最適をねらう – 防水透湿性素材 – サーバントリーダーシップ – 実践のバランスと視点 3
- 4. 目次 • ソフトウェア開発の大切なこと • コンテキスト –パラダイムシフト – 日本のソフトウェア管理・開発の歴史 • チケット駆動開発 – はじまり、バージョン管理とチケット – ツール連携とチケット・コミュニケーション支援 – 事例 • バランスと戦略 – 対立から協調へ（防水透湿性素材） – 自律と支援（サーバントリーダーシップ） – 実践のバランスと視点 4
- 5.
- 6. ソフトウェア業界のパラダイムシフト • 1990年代に始まった • ネオダマという標語によってソフトウェアハウスは ＳＩｅｒに変わった • 高機能ソフトの開発が容易になり、自由度が増し た反面、リスクが増えた • 技術者の守備範囲はソフトからシステムになり、 今、ビジネスに広がりつつある • 常に新しい分野へのチャレンジが求められるよう になった 6
- 7.
- 8.
- 9. 要求の不安定さ • ハンフリーは機能・インタフェース・環境の変更は 管理されないと開発は不安定になるとした • WattsS. 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
- 14.
- 15.
- 16.
- 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 新規追加 更新 更新タグ 競合チェックアウト アップデート 解決 関連タスク トレーサ ビリティ
- 21.
- 22.
- 23.
- 24.
- 25.
- 26.
- 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 BasedReasoning)の経験による問題 解決する際にはインデックスが重要とされている – 現状では日々の情報整理が必要 – チケット駆動開発の事例報告が少ない – より多くの事例を集めて整理したい • チケットシステムの活用でリスクが低減できる 可能性がある – ソフトウェア開発は常に挑戦だと認識する – チケット駆動開発を活用する – 発想力・提案力のあるチーム作りをする 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
- 52.
- 53.