ソフトウェアの品質向上に資する開発・運用現場の情報管理 ∼現場主導によるITS導入∼( #JaSSTKansai #RxTstudy9 @akahane92 )

6,591 views

Published on

■2013年8月2日 JaSST'13Kansai 発表資料(公開版)
■2013年11月30日 RxTstudy #9 発表資料(公開版)
 
ソフトウェアシステムは複雑化し、ネットワークをまたいだ相互作用によって稼働する巨大な仕組みとなっている。システム稼働後も多くの変更が加えられ長期間にわたって運用され続ける。システム全稼働期間中の品質維持を考える時、各工程の現場で生じる情報群(要求背景・経緯・人・意思決定・資料・成果物)の逸失と関連性の断絶が品質劣化に拍車をかけ、効率的な評価を妨げているとは考えられないだろうか。
 
  → 不確かな記憶 / 断片・陳腐化した文書 / 散逸する電子Mail / 人員異動による「記憶」の喪失
 
株式会社 島津ビジネスシステムズでは、島津製作所グループの業務システム開発・運用を少人数で実現するなかで、専用の課題管理システム(ITS:Issue Tracking System)の導入によりシステム障害を減少させ、業務の処理効率を向上させつつある。業態や対象領域によって焦点こそ異なるが、人間とソフトウェアシステムが深く関わる場所には底通する問題があると考え、対策実践の一例として経験を発表したい。

Published in: Technology
  • Be the first to comment

ソフトウェアの品質向上に資する開発・運用現場の情報管理 ∼現場主導によるITS導入∼( #JaSSTKansai #RxTstudy9 @akahane92 )

  1. 1. JaSST Kansai ’13 2013年8月2日
  2. 2. 本資料は2013年8月2日 JaSST’13 Kansai の発表スライド内容をベースとし てRedmine運用関係の実数値等を一部更 新し、同年11月30日のRxTstudy #9で の発表したものです。
  3. 3. (セッションの概要) ソフトウェアシステムは複雑化し、ネットワークをまたいだ相互作用によっ て稼働する巨大な仕組みとなっている。システム稼働後も多くの変更が加え られ長期間にわたって運用され続ける。システム全稼働期間中の品質維持を 考える時、各工程の現場で生じる情報群(要求背景・経緯・人・意思決定・ 資料・成果物)の逸失と関連性の断絶が品質劣化に拍車をかけ、効率的な 評価を妨げているとは考えられないだろうか。   → 不確かな記憶 / 断片・陳腐化した文書 / 散逸する電子Mail /     人員異動による「記憶」の喪失 株式会社 島津ビジネスシステムズでは、島津製作所グループの業務システ ム開発・運用を少人数で実現するなかで、専用の課題管理システム (ITS:Issue Tracking System)の導入によりシステム障害を減少させ、業務 の処理効率を向上させつつある。業態や対象領域によって焦点こそ異なる が、人間とソフトウェアシステムが深く関わる場所には底通する問題があ ると考え、対策実践の一例として経験を発表したい。
  4. 4. ・赤羽根 州晴(@akahane92) ・島津製作所 業務系システム子会社  → 開発技術者   Shimadzu Business Systems 話者紹介   → 障害対策専任   → 内部統制    → 基盤技術標準化 (現在) 4 参加団体 ・JaSST関西 ・RxTstudy ・AFFORDD 関西部会 ・京都アジャイル勉強会 ・WARAIテスト勉強会
  5. 5. Shimadzu Business Systems 5 上流工程 下流工程 ソフトウェアの開発・運用現場で各工 程が抱える困難に対して、課題管理シ ステムがいかに応え、現場を助け、品 質に資するのか。 今日お話しすること
  6. 6. Shimadzu Business Systems 6 今日お話しすること 島津製作所グループ  (国内外拠点 57カ所) ITS導入による現場改善  1)障害件数 半減  2)残業時間 改善
  7. 7. Shimadzu Business Systems 教えてください 7 管理者 or 現場担当? 課題管理システムを 使ったことがある? → はい 95% → 現場担当 70% リーダー/管理者 30%
  8. 8. Shimadzu Business Systems 8 第一部 何が問題なのか? 第二部 問題の原因と対策 第三部 実践結果と今後の展望
  9. 9. Shimadzu Business Systems 9 第一部 何が問題なのか?
  10. 10. Shimadzu Business Systems 10 ソフトウェア開発の状況 (IPA調べ 2012-04 [*3]) ソフトウェア開発プロジェクトの73.3%は 派生開発。→ 現場の実態・感覚に合致 73.3%
  11. 11. Shimadzu Business Systems 11 業務システムの運営状況 業務システム 103種 利用者 7000人 案件36000 件 改版(コミット) 20500回 1783 KLOC 開発運用 200人 /年 /年 /年 自動生成コード含む
  12. 12. Shimadzu Business Systems 12 ソフトウェアシステムのNetworking 103種の業務システムはネットワークを 跨いだ相互作用によって稼働 全体を掌握する人は皆無
  13. 13. Shimadzu Business Systems 13 業務システム全生涯の変更要求 7~15年 3.6万 2万コミット 1783 KLOC 1 2 3 4 5 6
  14. 14. Shimadzu Business Systems 14 業務システム全生涯の変更要求 7~15年 3.6万 3.6万 3.6万 3.6万 3.6万 3.6万 2万コミット 1783 KLOC 1 2 3 4 5 6 2万コミット 1783 KLOC 2万コミット 1783 KLOC 2万コミット 1783 KLOC 2万コミット 1783 KLOC 2万コミット 1783 KLOC
  15. 15. Shimadzu Business Systems 15 業務システム全生涯の変更要求 7~15年 3.6万 3.6万 3.6万 3.6万 3.6万 3.6万 2万コミット 1783 KLOC 1 2 3 4 5 6 2万コミット 1783 KLOC 2万コミット 1783 KLOC 2万コミット 1783 KLOC 2万コミット 1783 KLOC 2万コミット 1783 KLOC 案件36万/10年 20万コミット/ 10年
  16. 16. Shimadzu Business Systems 16 各工程で生じる情報群の記録状況【実際】 7~15年 1 2 3 4 5 6 台帳共有 後日、 理解不能 退職 離任 これを続けるとどうなるか?
  17. 17. Shimadzu Business Systems 17 システム障害発生状況 - 【当時】 2005 2007 障害 111件 54件 重大停止 78回 36回 計測期間 4ヶ月を通年換算
  18. 18. Shimadzu Business Systems 18 システム障害発生状況 - 【当時】 2005 2007 障害 111件 54件 重大停止 78回 36回 計測期間 4ヶ月を通年換算 ・日常的なシステム障害は技術で半減 ・残る問題はアプリケーション ・手探り状態のシステム変更からの脱却が鍵
  19. 19. Shimadzu Business Systems 19 問題点要約 1. 人の記憶が頼り「生き字引き」 2. システム毎の管理台帳で情報死蔵 3. 経緯は担当者のMail-Boxに蓄積 4. 組織と部門の壁が情報流通を阻害 5. パートナー契約、引継ぎ至らず    「無知見プロジェクト化」[*4, 5, 12] 6. 横断検索できない。
  20. 20. Shimadzu Business Systems 20 第二部 問題の原因と対策
  21. 21. Shimadzu Business Systems 21 課題管理 背景モデル 1/2    課題 3 ~ 課題・要望 問合せ受付 調査と確認 状況報告 方針決定 対処と確認 結果報告 時間  課題 2 ~ 変更 問合せ受付 調査と確認 状況報告 方針決定 対処と確認 結果報告 時間  課題 1 ~ トラブル 問合せ受付 調査と確認 状況報告 方針決定 対処と確認 結果報告 時間 複数 ユーザー複数 ユーザー複数 ユーザー 複数 ユーザー複数 ユーザー複数 担当者 C事業部 B事業部 A事業部 X System Y System Z System 関係者増加 / 事案多様化/システム増加・分散 N  :  N  :  N
  22. 22. Shimadzu Business Systems 22 課題管理 背景モデル 2/2  課題 3 ~ 課題・要望 問合せ受付 調査と確認 状況報告 方針決定 対処と確認 結果報告 時間  課題 2 ~ トラブル 問合せ受付 調査と確認 状況報告 方針決定 対処と確認 結果報告 時間  課題 1 ~ タスク 問合せ受付 調査と確認 状況報告 方針決定 対処と確認 結果報告 時間 複数 ユーザー複数 ユーザー 複数の 国内外支社 ・販社 担当者 複数 ユーザー複数 ユーザー 複数の 国内外部門 ・担当者 N  : N :  N l Global Issue Tracking System
  23. 23. Shimadzu Business Systems 23 課題の情報属性 - 事案モデル 事 案 作成者 担当者 関係者 経 緯 意思決定 履歴資料 成果物 リボルバーモデル (名称発案 宿口雅弘氏)
  24. 24. 関係性 Shimadzu Business Systems 24 実際の情報構造 3.6万件/年 2万コミット 1783 KLOC /年
  25. 25. 関係性 Shimadzu Business Systems 25 実際の情報構造 3.6万件/年 2万コミット 1783 KLOC /年
  26. 26. 関係性 Shimadzu Business Systems 26 実際の情報構造 3.6万件/年 2万コミット 1783 KLOC 二次元 Excel ? 表現できる…何か /年 ×
  27. 27. Shimadzu Business Systems 27 なぜこのような事態になってしまうのか? 問題の核心 •電子計算機の業務利用を取り巻く 環境変化に、案件管理方式が追い付 いていない。 汎用の媒体では業務事案の複雑性と 管理フローを表現できない。 専用システムが必要
  28. 28. Shimadzu Business Systems 28 【対策】案件記録・抽出方式の統一モデル 4 SVN 全システム 全案件 統一格納 7~15年 1 2 3 5 6 7000人 3.6万件/年 2万コミット 1783 KLOC
  29. 29. Shimadzu Business Systems 29 【対策】案件記録・抽出方式の統一モデル 4 SVN 全システム 全案件 統一格納 7~15年 1 2 3 5 6 7000人 3.6万件/年 2万コミット 1783 KLOC もしも:  全システムの各工程で生じた情報群が、  1)意味ある連鎖・参照構造を保持し、  2)関連ファイル、コード、設計書、    メールと共に格納され、  3)Googleの様な検索・抽出感覚を    実現できたら・・・ 業務システムに関係する全員が幸せになれる
  30. 30. Shimadzu Business Systems 30 【対策】現状のモデル分析 要求の源泉 7000人 マーケッター/サポート/ ユーザー/経営管理者 業務システム : E-Type 103種 2万コミット/年 1783 KLOC/年 仕様化 設計 実装 評価 システム運 用開発 200人
  31. 31. Shimadzu Business Systems 31 【対策】現状のモデル分析 要求の源泉 7000人 マーケッター/サポート/ ユーザー/経営管理者 業務システム : E-Type 103種 2万コミット/年 1783 KLOC/年 仕様化 設計 実装 評価 システム運 用開発 200人
  32. 32. Shimadzu Business Systems 32 【対策】現状のモデル分析 要求の源泉 7000人 マーケッター/サポート/ ユーザー/経営管理者 業務システム : E-Type 103種 2万コミット/年 1783 KLOC/年 仕様化 設計 実装 評価 システム運 用開発 200人 実際は?
  33. 33. Shimadzu Business Systems 33 【対策】現状のモデル分析 要求の源泉 7000人 マーケッター/サポート/ ユーザー/経営管理者 業務システム : E-Type 103種 2万コミット/年 1783 KLOC/年 仕様化 設計 実装 評価 システム運 用開発 200人 Multi-Level Multi-Loop Multi-Agent Feed-Back System M.リーマン,1974 [*6] Lehman's laws of software evolution
  34. 34. Shimadzu Business Systems 34 【対策】オープンソース開発プロセス M.リーマン E-Typeシステムの 進化モデル[*6] Open Source Softwareの 開発スタイル[*7] Multi-Location Multi-Time Phase Multi-Feed-Back Loop OSS開発の現場を支える Issue Tracking System の「情報表現力」
  35. 35. Shimadzu Business Systems 35 【対策】全てを統合 統合管理 全面導入 SVN Mail [*9] チケットを 京大式カードの 延長線と考える んや! (想像) [*8] [*10]
  36. 36. Shimadzu Business Systems 36 4つの要点
  37. 37. Shimadzu Business Systems 37 【要点1/4】情報容器の規格化 (「知的生産の技術」梅棹忠夫, 1969 [*8]) ITS チケット 作成者 担当者 関係者 経 緯 意思決定 履歴資料 成果物 「チケット」と いう規格化され た容器に入れ、 ITSへ格納され る。
  38. 38. Shimadzu Business Systems 38 【要点1/4】情報容器の規格化 (「知的生産の技術」梅棹忠夫, 1969 [*8]) ITS チケット 作成者 担当者 関係者 経 緯 意思決定 履歴資料 成果物 「チケット」と いう規格化され た容器に入れ、 ITSへ格納され る。 規格化により、投入・連鎖・ 検索しやすくなる
  39. 39. Shimadzu Business Systems 39 【要点2/4】チケットの表現力 •カスタムクエリ 入力項目 •本文に要約 •履歴に経緯 •添付ファイル 中間成果物 •リポジトリ     特定の改版内容とリンク •関係チケット 連鎖 •親子チケット 連鎖 •Wiki記法  連鎖・表現力 •全テキストが検索対象
  40. 40. Shimadzu Business Systems 40 【要点2/4】チケットの表現力 •カスタムクエリ 入力項目 •本文に要約 •履歴に経緯 •添付ファイル 中間成果物 •リポジトリ     特定の改版内容とリンク •関係チケット 連鎖 •親子チケット 連鎖 •Wiki記法  連鎖・表現力 •全テキストが検索対象
  41. 41. Shimadzu Business Systems 41 【要点3/4】ITSは情報システム部門のERP ( あきぴー @akipii, 阪井誠 @sakaba37 [*11]) 各種資産とシス テム・業務を連 鎖すると処理の スループットが 向上する。 例)部門、プロ ジェクトを横断 する申請書 ITS 資産管理 サーバー インフラ ネット インフラ 業務 (永続) システム (永続)
  42. 42. Shimadzu Business Systems 42 【要点4/4】事案に一意番号を付与 全ての事案(Ticket)に対して 恒久的な一意IDを付与 → URI (Universe Resource Identifier) ITSの外部に向かって連鎖が拡大 あらゆるドキュメントに一意IDが記載 ITSが情報の中心となり、 全ての情報がつながり始めた。
  43. 43. Shimadzu Business Systems 43 【対策】まとめ 1. 現実の業務を表現できる。    → Multi Feed-Back System 2. 入力,連鎖コスト < 利便,利益 3. 必要十分な再利用性,検索性 4. 完全な追跡可能性 5. 部門横断(事案連鎖) 6. いつでも。どこでも。直ちに見つかる。 7. Vendor-lock-inされない。 7種の要求を満たすツール
  44. 44. Shimadzu Business Systems 44 第三部 実践結果と今後の展望
  45. 45. Shimadzu Business Systems 45 課題管理システム - 全体像 Project A 問合せ 要望・課題 障害・バグ タスク Project B 問合せ 要望・課題 障害・バグ タスク 課題管理システム (ITS) 自動化ツール ビルド テスト リリース 構成管理ツール •Subversion, CVS •版数管理 (差分・結合・分派) (未着手) ■日常業務に浸透 •トータルで負担減少 •状態の掌握が容易 •コミュニケーション促進 ■トレーサビリティー        一意性 永続的な   連鎖性        履歴追跡性 ■変化への適応  状況変化を記録し  追従する。後々の  参照が容易になる。
  46. 46. Shimadzu Business Systems 0 70 140 0 50000 100000 全チケット数 プロジェクト数ITS導入 ー 計測 20112010 2012 100,000 Tickets 130 Projects 350 Users 46 2013 2013年11月29日時点
  47. 47. Shimadzu Business Systems ITS導入 ー 計測 0 50 100 0 50000 100000 2010 後 2011 前 2011 後 2012 前 2013前 全チケット数 1日平均発行数 完了率 47 Closed 92% 3000 Tickets/Month 20112010 2012 2013 2013年11月29日時点
  48. 48. Shimadzu Business Systems 48 システム障害の発生件数 2005 2007 2012 障害 111件 54件 12件 重大停止 78回 36回 4回 計測期間 4ヶ月を通年換算
  49. 49. Shimadzu Business Systems 49 システム障害の発生件数 2005 2007 2012 障害 111件 54件 12件 重大停止 78回 36回 4回 日常的なシステム障害から解放 定時後、週末のOffice風景が変わった。 計測期間 4ヶ月を通年換算
  50. 50. Shimadzu Business Systems 50 管理水準も飛躍的に向上 ITSを含む、各種改善効果があった。 非公開資料
  51. 51. Shimadzu Business Systems 51 まとめ
  52. 52. Shimadzu Business Systems 52 【対策】まとめ OSS 開発手法 経営上の 利点 現場の 利点 主 導
  53. 53. Shimadzu Business Systems 53  IT全般統制  ISO  ITIL  FDA (Part 11)  省庁監査 【統制要求】  統制実現  コスト低減  属人性軽減  品質, CS向上  業績貢献 【経営要求】  現業務を表現可能なTool  入力コストに見合うTool  <ユーザー体験>   いつでも どこでも   素早く必ず見つかる   休みやすい 【現場の要求】   【管理手法】
  54. 54. Shimadzu Business Systems 54 一意識別 ↓ 関連維持 ↓ 追跡可能 ↓ 信頼可能  IT全般統制  ISO  ITIL  FDA (Part 11)  省庁監査 【統制要求】  統制実現  コスト低減  属人性軽減  品質, CS向上  業績貢献 【経営要求】  現業務を表現可能なTool  入力コストに見合うTool  <ユーザー体験>   いつでも どこでも   素早く必ず見つかる   休みやすい 【現場の要求】   【管理手法】
  55. 55. Shimadzu Business Systems 55 一意識別 ↓ 関連維持 ↓ 追跡可能 ↓ 信頼可能 個人の利益を動機とする 局所 最適型 行動規範が、(結果とし て) 経営に資する知識管理システ ムとして、全体最適型 の均衡を 得ていた。  IT全般統制  ISO  ITIL  FDA (Part 11)  省庁監査 【統制要求】  統制実現  コスト低減  属人性軽減  品質, CS向上  業績貢献 【経営要求】  現業務を表現可能なTool  入力コストに見合うTool  <ユーザー体験>   いつでも どこでも   素早く必ず見つかる   休みやすい 【現場の要求】   【管理手法】
  56. 56. Shimadzu Business Systems 56 ご清聴 ありがとう ございました
  57. 57. 協 力 島津ビジネスシステムズ 57
  58. 58. Shimadzu Business Systems 島津製作所のご紹介    島津製作所グループ   事業領域    ・分析計測    ・医用機器    ・航空機器    ・半導体機器    ・油圧, 光学 58
  59. 59. Shimadzu Business Systems 59 質疑応答
  60. 60. Shimadzu Business Systems 60 参考文献 1.ソフトウェア品質保証の考え方と実際 / 日科技連 / 保田勝道 3.「ソフトウェア産業の実態把握に関する調査」調査報告書 ―速報版― / IPA, 2012   http://www.ipa.go.jp/sec/softwareengineering/reports/20130426.html 4.派生開発推進協議会 カンファレンス 2013 チュートリアル資料 /(株)デンソー 古畑慶次 5.無知見プロジェクトに対する XDDP の適用 / SQiPシンポジウム 2009 論文 / (株)デンソー 中井栄次, 間瀬研二, 古畑慶次   http://www.juse.or.jp/software/83/attachs/ippan_2-2.pdf 6.Lehman-Laws Of Software Evolution / Proceedings of the IEEE Sept. 1980/ MEIR M. LEHMAN 7.OSS開発モデル, 伽藍とバザール / Eric S.Raymond, 1999   http://cruel.org/freeware/cathedral.html 8.知的生産の技術 / 岩波新書 / 梅棹忠夫, 1969 9.Redmineによるタスクマネジメント技法 / 翔泳社 / 小川明彦, 阪井誠, 2010 10.Redmine / OpenSource Software / Jean-Philippe Lang   http://www.redmine.org/ 11.プログラマの思索 / Webブログ / @akipii   http://forza.cocolog-nifty.com/ 12.「派生開発」を成功させるプロセス改善の技術と極意 / 技術評論社 / 清水吉男, 2010

×