untitle

Size: px

Start display at page:

Download "untitle"

のぶあきことじ
5 years ago
Views:

1 五月雨式な大規模組み込みソフト開発におけるメトリクス活用事例トレーニング指向アプローチによる考え使う業務スタイルへの挑戦 ( 株 ) デンソークリエイトプロジェクトセンター山路厚 1/25

2 目次 1. プロセス改善の体制 2. プロセス改善の経緯 3. 五月雨式な組み込みソフト開発 4. 失敗経験 5. トレーニング指向アプローチ 6. 適用方式 7. 適用事例 8. まとめ : 勉強したこと 2/25

3 1. プロセス改善の体制経営企画本部 22 名企画部人事採用経理購買品質管理部 QMS 管理技術管理部社内システムイオタ事業室市販ソフト営業教育事業中国調達部中国関連窓口プロジェクトセンター 183 名現場改善推進室 SEPG SQA 定着企画推進事業部門技術開発室インフラ開発市販ソフト開発システム 1 室カーナビ HMI 関連システム 2 室システム 3 室システム 4 室カーナビコアソフト関連その他 ITS 関連車載用ソフト開発技術関連車載制御ソフト関連基盤ソフト関連現場主義現場主体のプロセス改善 3/25

4 2. プロセス改善の経緯 ISO9001 取り組み CMM/CMMI レヘル 2 取り組み CMMI レヘル 3 取り組み 96 年 ~ 02 年 (7 年間 ) 03 年 04 年 05 年 06 年 07 年現在 97 年 8 月 ISO9001(94 年版 ) 認証取得 01 年 9 月レベル 1! ISO9001(2000 年版 ) CMM 簡易アセス認証取得レベル 2 CMM 簡易アセスレベル 2 CMMI 簡易アセスレベル 3 レベル3 CMMI 公式アセス CMMI 簡易アセス五月雨式大規模組み込みソフト開発プロセス改善の先取りトップダウン方式 CMM 思想の持ち込みトップダウン方式現場主体にシフトトレーニング指向アプローチ文書化手順化やらされ感形式的表面的疲弊変化の兆し失敗の危惧仕事の質のモデル化現場密着型支援型 SQA 工数に着目したプロジェクト改善支援ツール : SURE SUCCESS : 現場カイゼンを実施する小集団活動 SURE:Step Up Review for Effectの略社内用語 SUCCESS:Step Up Cheerful Circle for Effect,Skill,Satisfactionの略社内用語 4/25

5 3. 五月雨式な組み込みソフト開発 : 大規模化組み込みソフトウェア開発仕様が曖昧未定システム評価は終盤に集中すり合わせ開発終盤に仕様変更多発量産日程は死守五月雨式なイテレーション開発 + 組み込みソフトの大規模化品質問題納期圧迫高負荷不十分な評価さらに深刻疲弊不十分な結合作業五月雨式な部品の変更開発の連続すり合わせしきれない規模期間 5/25

6 3. 五月雨式な組み込みソフト開発 : 変更開発の連続開発現場の状況開発計画抜粋試作評価フェーズ五月雨式な細かい部品単位の変更開発終盤に負荷を集中させない! 作り込み時に品質を確保したい細かい開発単位で可能か? 体制変動が激しい期間が長い仕様変更多発品質問題集中開発者不在大混乱メトリクスを使った確実な工程完了判断品質の見通しを良くしたい! 6/25

7 3. 五月雨式な組み込みソフト開発 : メトリクスが使えるか開発期間が短い 1.5 ヶ月以下 : 約 80% 2 週間以下の緊急対応が約 30% 小規模アイテムの集まり 2 人月以下 : 約 70% 開発期間分布開発規模分布平均開発期間 : 約 1 ヶ月案件数割合 1 週間 2 週間 3 週間 4 週間 5 週間 6 週間 7 週間 8 週間 9 週間 10 週間 11 週間 12 週間 13 週間案件数割合 100.0% 90.0% 80.0% 70.0% 60.0% 50.0% 40.0% 30.0% 20.0% 10.0% 0.0% 平均規模 : 約 1.8 人月 100.0% 90.0% 80.0% 70.0% 60.0% 50.0% 0.5 人月以下の緊急対応が約 40% 大きな規模のアイテムもある 0.5 人月 1.0 人月 1.5 人月 2.0 人月 2.5 人月 3.0 人月 3.5 人月 4.0 人月 4.5 人月 5.0 人月 5.5 人月 6.0 人月 6.5 人月 7.0 人月 7.5 人月 8.0 人月 8.5 人月 40.0% 30.0% 20.0% 10.0% 0.0% 小規模なアイテム ( 分母が小さい ) の集まり品質データのバラツキが大きくなる要因 1 工程あたり 2 日 3 日の開発期間になったりするんだ! 7/25

8 3. 五月雨式な組み込みソフト開発 : メトリクスが使えるか体制変動が激しい歩留まり率 : 約 50% 体制変動状況当初技術者当初比率 : 約 1/3 人の変動はバラツキの大きな要因 2006 年 11 月 2006 年 12 月 2007 年 01 月 2007 年 02 月 2007 年 03 月 2007 年 04 月 2007 年 05 月 2007 年 06 月 2007 年 07 月 2007 年 08 月 2007 年 09 月 2007 年 10 月 2007 年 11 月 2007 年 12 月 2008 年 01 月 2008 年 02 月品質データのバラツキが大きい不具合抽出件数分布 ( 規模あたり ) 平均値に対し 1/10( もしくは 0)~10 倍程度アイテム毎のバラツキ 100 倍以上アイテム毎で妥当な工程完了判断が難しいマクロ値では開発現場に合わない ( そのままでは使いにくい ) 平均 8/25

9 4. 失敗経験 : 陥りやすいミスここまでのおさらい五月雨式な部品の変更開発では終盤に負荷が集中する作り込み時に品質を確保したくメトリクス活用による管理手法に取り組む小規模な開発アイテムの集まり品質データのバラツキが大きい蓄積したメトリクスでは開発現場が使いにくい状況どうする? 基準を整備します細かな基準を作りますメトリクスの利用基準を作ります精度向上に取り組みますさらにデータを蓄積してメトリクスの精度を上げます陥りやすいミス基準マニア精度向上病失敗経験基準作り精度向上活動に終始し開発現場で活用されずに終わった!( 徒労に終わる ) 9/25

10 4. 失敗経験 : 基準マニア精度向上病陥りやすいミスメトリクスメトリクスが使えない基準化精度向上基準マニア精度向上病言い訳ギャップ想定外の要因新たな因子開発現場データ計測判断評価カイゼン開発の中で活かせない計測から先に進まない技術者の陥りやすいミス : 行き過ぎた精度向上病基準化に執着し精度向上に終始する! 細かな基準? データに精度が無いのにいつまで経っても開発現場で使われない! 基準化精度向上自体は良いことだからこそ行き過ぎを止められない! 10/25

11 4. 失敗経験 : 気づき 1 理系人間は方程式を欲しがる! 方程式法則公式に従って仕事がしたい勝利の方程式好きこの場合はこうすれば良いという成功方法が事前に欲しい銀の弾丸も同じ理由? 最初に決め後は考えずに仕事がしたいモノに対する考え方である 2 人のやることは方程式通りにはいかない! しかしソフトウェア開発は人のやることなので方程式通りにはいかないその場の状況に合わせ考えながら仕事をすることが重要状況を見るためには人とのコミュニケーションが不可欠しかしながらソフトウェア技術者は人と関わりを持つことが苦手 ( 嫌い ) だから関わりを持たないでも成功するより完璧な方程式法則を求める 3 人に着目した ( 焦点をあてた ) アプローチ! そこでソフトウェア開発は人に着目したアプローチが特に重要状況に合わせて考えるという要素を入れた方式人の能力を引き出すトレーニング指向アプローチ考えてメトリクスを使う 11/25

12 5. トレーニング指向アプローチ : 仕事の質のモデル化 SPI Japan2007: 仕事の質のモデル化は自ら考える業務スタイルに導く仕組枠組み人が育つ着眼点仕事の質のモデル化を適用することでメトリクスを使う業務スタイルへ! 12/25

5. トレーニング指向アプローチ : メトリクスを使う SPI Japan2007: やり方

を考慮してメトリクスを使う判断 5: フィートハック 4: 最適化 3: 標準化 2:

13 5. トレーニング指向アプローチ : メトリクスを使う SPI Japan2007: やり方を考える考えて判断評価するどんなモデル? モデル化の方式やり方 5: 最適化 4: 標準化 3: 定量的 2: 定性的 ( 確度高 ) 1: 定性的 ( 確度低 ) 0: 考えていない仕事の特徴 ( 規模人等 ) を考慮してメトリクスを使う判断 5: フィートハック 4: 最適化 3: 標準化 2: 定量的 1: 定性的 0: 評価していない成長モデルを活用仕事の特徴 ( 規模人等 ) を考慮して判断評価する仕事のやり方にフィードバックする 13/25

6. 適用方式 : 取り入れ方開発の中で使う方式陥りやすいミスメトリクスギャップ 5: 最適化 4: 標準化 3: 定量的 2: 定性的 ( 確度高 ) 1: 定性的 ( 確度低 ) 0: 考えていないデータ計測 1 計画段階で仕事の特徴を自ら考えメトリクスから計画指標を設定する開発現場ギャップメトリクス計画指標

14 6. 適用方式 : 取り入れ方開発の中で使う方式陥りやすいミスメトリクスギャップ 5: 最適化 4: 標準化 3: 定量的 2: 定性的 ( 確度高 ) 1: 定性的 ( 確度低 ) 0: 考えていないデータ計測 1 計画段階で仕事の特徴を自ら考えメトリクスから計画指標を設定する開発現場ギャップメトリクス計画指標メトリクスが使えない基準化精度向上言い訳判断評価カイゼン使う 5: フィートハック 4: 最適化 3: 標準化 2: 定量的 1: 定性的 0: 評価していない 2 レビュー時に計画指標実績値を使い判断評価する実績を振り返りメトリクスにフィードバックする現場の中で使う! 使うことで現場もデータも育つ方式! 14/25

15 6. 適用方式 :1 計画指標の設定の具体例計画の抜粋アイテム毎の変化点懸念点抽出考えるメトリクス抽出欠陥数 DR 時間計画指標設定テスト項目数工程別に設定 ( 全 21 項目 ) 計画段階で根拠を考え値とともに記録小規模アイテムの集まり ( 全 460 件 ) に適用する! 15/25

6. 適用方式 :2 判断評価の具体例成果種別成果量単位機能不具合件数成果物不具合件数不具合件数機能不具合 / 成果物不具合合計非不具合件数実績総レビュー時間成果量総成果量工数品質 ( 成果量単位 /H) レビュー品質成果品質 ( 不具合件数 / 成果量単位 ) 成果量の乖離について当初はは対象外としていたが顧客との調整の結果対応することとなったため

27 標準画面るきたため対象成果物計画 ( 予想 ) 実績単体テスト仕様書 ( 仕様分見出し 2 5 7 4 1.58H 19 12.00 0.

33 2008/2/1 ハンドコード工数品質成果物不具合の成果品質については問題なし機能不具合の成果品質については過去実績を元に発生する不具合を見込んだが今回のアイテムでは画面構成が他の機能と類似していたため参詳細設計書ページ 0 1 1 1 1.90H 22 11.58 0.

短い時間で問題ないことを確認できたためレ人数ののべ時ソースコード行 1 1 2 6 1.83H 113 50.18 間ではない 0.01 ) 2008/2/9 ビュー時間が減少した品質的には問題なし単体テスト仕様書項目 0 4 4 5 1.17H 121 97.

16 6. 適用方式 :2 判断評価の具体例成果種別成果量単位機能不具合件数成果物不具合件数不具合件数機能不具合 / 成果物不具合合計非不具合件数実績総レビュー時間成果量総成果量工数品質 ( 成果量単位 /H) レビュー品質成果品質 ( 不具合件数 / 成果量単位 ) 成果量の乖離について当初はは対象外としていたが顧客との調整の結果対応することとなったため計画よりも増加した問題なし工数品質機能不具合の成果品質については問題なし妥当性判断確認事項エビデンス妥当性判断の根拠 /NG 時の対策成果物不具合の成果品質の乖離については (OK/NG) 製作の成果量は規模に対して適量であの処理など既存のテスト仕様書を参考にで OK 対象規模 5.27 標準画面るきたため対象成果物計画 ( 予想 ) 実績単体テスト仕様書 ( 仕様分見出し H /1/30 計画ほど不具合が発生しなかった問題なしツールデータ工数品質成果品質ともに問題なし DRBFM 心配点 H /2/1 ハンドコード工数品質成果物不具合の成果品質については問題なし機能不具合の成果品質については過去実績を元に発生する不具合を見込んだが今回のアイテムでは画面構成が他の機能と類似していたため参詳細設計書ページ H /2/9 考にできる部分が多く不具合が発生しなかった計画時では中に表示情報が変化した際のタイマー更新処理を考慮に入れていなかったため製作工程での不具合検出除去状況は妥計画時よりも成果量が増加した OK 当である工数品質については担当者の経験を考慮し確認レビュー時間は計画実績ともに実時時間を多めに計画したが比較的容易な変更であ間で記入すること ( 時間り短い時間で問題ないことを確認できたためレ人数ののべ時ソースコード行 H 間ではない 0.01 ) 2008/2/9 ビュー時間が減少した品質的には問題なし単体テスト仕様書項目 H 成果量については既存の単体テスト仕様書を流用することができたことにより増加した工数品質の乖離については中にイベント受信した場合の確認項目の妥当性確認に時間を要したため計画よりもレビュー時間が増加した /2/5 成果品質については問題なし工数品質成果品質ともに問題なしテストデータ行 H /2/5 単体テスト報告書項目 H 計画では 1 件の不具合が発生すると見込んでいたが基本的に他のやを参考に設計することができ複雑な処理もなかったため /2/12 不具合が発生しなかった問題なし承認日アイテム毎のレビューでアイテム単位の完了判断工程完了承認エビデンス作成マニュアルに従い Diff Grepによる確認が実施されている最終プログラムに対し QACがかけられ顧客依頼項目が漏れなく除去されてい判断理由 OK OK 計画指標と実績値を基にレビューで工程完了判断計画の根拠と妥当性判断分析の結果必要と想定される成果量にて計画計画と実績の差異分析ほぼ計画通りのため問題なし標準 ( 過去の実績 ) 部品部品部品部品 / 規模部品 / 規模部品 / 規模関数関数行行 / 規模行 / 規模行 / 規模対象計画実績標準 ( 過去の実績 ) Iツールデータレビュー時間 3.40 時間 1.62 時間 1.12 時間部品 / 時間部品 / 時間部品 / 時間機能不具合検出数 2.00 件 0.00 件 1.16 件 2.41 件 / 百部品 0.00 件 / 百部品 1.29 件 / 百部品成果物不具合検出数 3.00 件 3.00 件 1.62 件 3.61 件 / 百部品 3.33 件 / 百部品 1.80 件 / 百部品ハンドコードレビュー時間 8.25 時間 4.83 時間 4.16 時間行 / 時間行 / 時間行 / 時間機能不具合検出数 4.00 件 3.00 件 5.46 件 9.32 件 / 千行 6.99 件 / 千行件 / 千行成果物不具合検出数 7.00 件 9.00 件 9.53 件件 / 千行件 / 千行件 / 千行全体レビュー時間時間 6.45 時間 9.72 時間 0.45 規模 / 時間 0.82 規模 / 時間 0.54 規模 / 時間機能不具合検出数 6.00 件 3.00 件 4.89 件 1.14 件 / 規模 0.57 件 / 規模 0.93 件 / 規模成果物不具合検出数件件 6.08 件 1.90 件 / 規模 2.28 件 / 規模 1.15 件 / 規模計画の根拠と妥当性判断仕様分析の結果および担当者の経験から計画計画と実績の差異分析レビュー時間については計画では2 人分を考慮した時間実績はレビューそのものの時間であるためほぼ計画通り機能不具合検出数については過去実績を元に発生する不具合を見込んだがでは機能構成が他の機能と類似していたため参考にできる部分が多く不具合が発生しなかった問題なし問題なく作成されている統合時に実施される計画となっている自ら考えた計画指標と実績を対比し工程完了判断! 16/25

17 7. 適用事例 : プロジェクト概要と効果の測定方法五月雨式な組み込みソフトウェア部品の変更開発期間 2006/11~2008/3( 約 17ヶ月 ) 規模約 1000 人月開発アイテム数 460アイテム全てに適用した開発工程仕様検討 ~ 部品の単体テスト計画の抜粋効果の測定方法 1 計画指標と実績値との差チームとしての成長度合い 2 流出不具合率作り込み欠陥率手戻り工数率作り込み品質の向上度合い 17/25

18 7. 適用事例 : 内製チームの成長度合い抽出欠陥 : 計画指標と実績値との差 500.0% 0%: 計画指標 = 実績値 400.0% 300.0% 計画指標に近づいてきた 200 % 200.0% 100.0% 0% 0.0% % % 7.0 不具合流出率不具合が流出している時間経過とともに計画指標に近づいてきた流出不具合がありまだまだ成長途中である 18/25

19 7. 適用事例 : 国内協力会社チームの成長度合い抽出欠陥 500.0% : 計画指標と実績値との差 0%: 計画指標 = 実績値 400.0% 300.0% 計画指標に近づいてきた 200 % 200.0% 100.0% 0% 0.0% % % 不具合流出率流出不具合も減少傾向 0.0 時間経過とともに計画指標に近づいてきた計画指標より実績値が下回る傾向にある流出不具合率が低下成熟してきた 19/25

20 7. 適用事例 : 海外協力会社チームの成長度合い抽出欠陥 500.0% : 計画指標と実績値との差 0%: 計画指標 = 実績値 400.0% 300.0% 当初から差が小さい 200 % 200.0% 100.0% 0% 0.0% % % 不具合流出率開発工程内摘出率工程内での摘出率が増加当初から差が小さいデータ操作の疑いあり流出不具合率は減少摘出不具合率は増加実力が分かり品質活動管理活動で未然に防止 /25

21 7. 適用事例 : チーム全体としての評価 (1/2) 抽出欠陥 : 計画指標と実績値との差手戻り工数率時間経過とともに計画指標に近づいてきた計画指標を下回る傾向が確認できた手戻りが削減されチームが成長してきた気づき計画より下回る傾向計画段階で課題懸念点を考えるから意識され手が打たれる結果として計画より作り込まれる欠陥が減っていく! 21/25

規模あたりの作り込まれる欠陥率 ( 月別 ) 25.0 作り込み欠陥率 20.0 15.0 10.0 5.0 0.

22 7. 適用事例 : チーム全体としての評価 (2/2) 作り込み品質が向上するメカニズム考える業務スタイル事前に考える考えて判断評価 ( 現場で使う ) 今回の方式意識レビューの質が上がる相乗効果作り込まれる欠陥が減る流出不具合が減る計画より下回る傾向得点レビューの質合格ライン評価やり方 06 年 8 月 06 年 11 月 07 年 3 月 07 年 8 月補足 : 仕事の質のモデルを基に内部アセスメントにて診断した結果より規模あたりの作り込み欠陥率 ( 月別 ) 規模あたりの作り込まれる欠陥率 ( 月別 ) 25.0 作り込み欠陥率レビューの質が上がり作り込まれる欠陥が減ってきた 2006 年 11 月 2006 年 12 月 2007 年 01 月 2007 年 02 月 2007 年 03 月 2007 年 04 月 2007 年 05 月 2007 年 06 月 2007 年 07 月 2007 年 08 月 2007 年 09 月 2007 年 10 月 2007 年 11 月 2007 年 12 月 2008 年 01 月 2008 年 02 月 22/25

23 7. 適用事例 : 効果の確認品質向上 : 流出不具合が約 1/8 に低減開発が進むにつれ流出不具合率が低下規模あたりの流出不具合率 ( 月別 ) 規模あたりの流出不具合率 ( 全体 ) ) 規模あたりの流出不具合率 ( 月別 ) 流出不具合率流出不具合件率約 1/ 年 11 月 2006 年 12 月 2007 年 01 月 2007 年 02 月 2007 年 03 月 2007 年 04 月 2007 年 05 月 2007 年 06 月 2007 年 07 月 2007 年 08 月 2007 年 09 月 2007 年 10 月 2007 年 11 月 2007 年 12 月 2008 年 01 月 2008 年 02 月前プロジェクト対象プロジェクト作り込みの品質向上に効果あり! 自ら考え使うことが日々のトレーニングとなる! 23 /25

24 8. まとめ : 勉強したこと 1 基準マニア精度向上病銀の弾丸理系人間は事前に方程式法則公式を欲しがる人のやることは方程式通りにはいかない! 解はいろいろ! 2 事前に考える意識が自然に手を打つ事前に考えると事実と真摯に向き合える事後に考えても言い訳になりやすい 3 データの質使うことが質を研ぐ開発現場が考え使うことによりデータの質が高まるなぜが分かり自ら成すべきことが見えてくる管理データが改善のためのデータに変わってくるソフトは人なり人に着目した ( 焦点をあてた ) アプローチ! 24/25

25 END: ありがとうございました END: ありがとうございました 25/25

スライド 1

スライド 1 - トレーニング指向アプローチの適用事例 - 現場主体の改善につながる EP 自己履行検証の仕組み ( 株 ) デンソークリエイトプロジェクトセンター山路厚 1/27 目次 1. プロセス改善の体制 2. プロセス改善の経緯 3. 失敗の危機 4. 発想転換 5.EP 自己履行検証方式 6. トレーニング指向アプローチ 7. 効果の確認 8. まとめ : 勉強したこと 2/27 1. プロセス改善の体制