チケット駆動開発を用いたソフトウェア品質改善事例
- 1. シスメックス株式会社 小枝 徳晃 チケット駆動開発を用いた ソフトウェア品質改善事例 臨床検査機器メーカー （血液分析装置が主） 工業用粒子計測装置に コア技術を応用
- 2. 商品開発プロジェクトの実際 ・・・・ 実用化開発 商品開発 ｼｽﾃﾑ 評価 量産 予定では・・・ 現実は・・・ 実際は！ 実用化開発 商品開発 ｼｽﾃﾑ評価 量産 評価 遅れ 遅れ 遅れ 実用化開発 商品開発 量産 積み残し 積み残し 積み残し テスト 修正 ・・・・ テスト 修正 評価といいながら 不具合対策 発売 発売 発売
- 3. 改善のための分析 システム評価の段階で不具合発見による手戻り 「システム評価」 といいながら、 実際は 「不具合修正」 を行っている。 プロジェクト全体の開発工数を圧迫 最終段階で発生するため、リカバリーが困難 積み残し 積み残し 積み残し 積み残し 遅れ 遅れ 遅れ 遅れ ～ ～ ～ ～ ～ ～ ～ ～
- 4. システムテスト でバグを見逃す テスト技術力が 低い システムテ ストでの手戻 りが多い バグが多い バージョン アップが 多い 仕様の追加 変更が多い 市場のニーズ がわからない 要求管理が 不十分 仕様決定が 遅い システム設計 が不十分 システム設計 技術力が低い 共通化が 進んでない 開発期間が 少ない テスト工数が 不十分 情報共有が 不十分 変更管理が 不十分 ソース管理 が不十分 先祖帰りの 発生 修正漏れの 発生 テスト期間が 短い 現状問題点構造ツリーによる分析 仕様の誤解 発生 事前テストが 不十分 プロジェクト管理が 不十分
- 5. 分析結果からの考察 システムテストの手戻り 開発期間が短い ボトルネック UDE （好ましくない結果）が集中している 仕様の誤解 仕様の漏れ コミュニケーションの問題 プロジェクトマネジメントの問題 プログラマは 正しい と思って作っているため、単体テストでは防げない！ 多発する変更が誘発
- 6. どう品質を改善するのか？ まず、仕様の誤解、漏れをなくす チケット駆動開発の採用 優先すべきは、システムテストの手戻り対策 多発する変更要求、バグを間違いなく伝え、変更確認する手法が必要！
- 7. Mantis を使ったチケット駆動開発の例 全ての業務をチケットに分解して、指示を徹底 全ての業務の進捗がプロジェクト員全員が確認できる 不具合のカテゴリー・重要度・ステータス（どういう状態にあるか）など一目でわかる。 特にステータスは、色別で直感的にわかりやすいため、不具合が放置されっぱなしになることはなくなる 各項目修正毎に第 3 者の検証を実施。 問題を早期に解決
- 8. チケットのワークフロー 起票 プロジェクトメンバー 担当者割り当て 実施 リーダ確認 起票者確認 差し戻し リーダ 担当者 リーダ 起票者 完了 中止
- 9. チケット駆動開発の原則 イテレーションより早く PDCA をまわす！ １．全ての作業をチケットに登録 ３．チケットの成果をレビューする ４．チケットの定期的な棚卸をする。 ２．チケットの成果を明確にし、公開する
- 10. チケットの粒度 工数 少ない 多い 管理 概略 詳細 プロジェクトが管理したい粒度で決定する 大きい 小さい PDCA 大きい 小さい
- 11. アジャイルの導入 チケットがあふれる チケットの優先度がわからない スケジュールが見えにくい チケット駆動開発で発生しやすい問題点 優先度の高いものをランク分け 各ランク毎に完了目標を設定 アジャイル型開発の採用
- 12. アジャイル開発の適用 チケットをイテレーションに割り当てることで優先度を決定 イテレーション内の優先度は、担当者に任せる 開発にリズムがでて、モチベーションが向上
- 13. チケット駆動開発では解決できない問題 １．システム設計が不十分 ２．テスト技術力が低い ３．要求管理が不十分 TiDD やアジャイルはプロジェクト管理ツール プロジェクト管理以外は別の方法を考えるべき
- 14. システムテスト でバグを見逃す テスト技術力が 低い システムテ ストでの手戻 りが多い バグが多い バージョン アップが 多い 仕様の追加 変更が多い 市場のニーズ がわからない 要求管理が 不十分 仕様決定が 遅い システム設計 が不十分 システム設計 技術力が低い 共通化が 進んでない 開発期間が 少ない テスト工数が 不十分 情報共有が 不十分 変更管理が 不十分 ソース管理 が不十分 先祖帰りの 発生 修正漏れの 発生 テスト期間が 短い TiDD とアジャイルによる改善効果 仕様の誤解 発生 事前テストが 不十分 プロジェクト管理が 不十分 TiDD で改善 アジャイルで改善 別の対策が必要
- 15. まとめ及び今後の課題 チケット毎に修正後の確認を行うことで、短く PDCA が回った アジャイル開発手法を取り入れ、開発にリズムが生まれた チケット駆動型開発により、進捗の見える化ができた チケット毎に仕様を明確にすることにより、仕様の誤解が減った ・分散開発への適用 ・テストリンクとの連携 ・要求管理手法との連携 今後の課題 まとめ