タイムボックス制約付きインクリメンタル開発

2,709 views
2,614 views

Published on

タイムボックス制約付きインクリメンタル開発

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,709
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
90
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

タイムボックス制約付きインクリメンタル開発

  1. 1. タイムボックス制約付き インクリメンタル開発プロセス ~高品質、低コスト、納期厳守の同時実現を目指して~ 高品質 低コスト 納期厳守の同時実現を目指して 18-C-5 松浦豪一 富士通株式会社 産業 流通ソリュ ション本部 産業・流通ソリューション本部 GLOVIAエンジニアリング事業部 Developers Summit 2010
  2. 2. 1.自己紹介 自己紹介 1986年入社 旧:㈱富士通静岡エンジニアリング→ 旧:㈱富士通静岡エンジニアリング→ 現:㈱富士通ソフトウェアテクノロジーズ 現 ㈱富士通ソフトウ アテクノロジ ズ 汎用機ソフトウェア・ミドルウェアの開発 2001年からGLOVIA- 2001年からGLOVIA-C会計の開発 2005年からKAIZEN活動を実践 2005年からKAIZEN活動を実践 →KAIZEN塾(FST1期)伝道師型 KAIZEN塾(FST1期)伝道師型 2006年11月より、富士通㈱に出向 2007年8月よりGLOVIA/MIの開発リーダ 2007年8月より の開発リーダ Developers Summit 2010
  3. 3. 2.プロセス概要 プ セス概要 アジャイル開発や リーンソフトウェア開発 というよりKAIZEN活動 というよりKAIZEN活動 タイムボックス制約付きインクリメン タル開発プロセスとは 1. 開発項目は に分割する 2. 分割した単位をイテレーションと呼び、PG-IT を5日以下にする( ) 3. イテレーションを繰り返して機能追加する ( ) Developers Summit 2010
  4. 4. 3.2つのヒント のヒント KAIZEN活動による生産性の向上 KAIZEN活動による生産性の向上 (非正味作業を減らし、正味作業を増やす) 非正味作業を減らし、正味作業を増やす) プロジェクトの生産性・品質に大きな ばらつきがあった。 ばらつきがあった。 Developers Summit 2010
  5. 5. 3.KAIZEN活動 活動 作業の平準化 「かんばん」、「あんどん」 」、 あ 」 1. 正味・非正味・その他に分類し ムダとり 作業カードにして見える化(VMボード 作業カ ドにして見える化(VMボ ド) 作業カードにして見える化(VMボード) ドにして見える化(VMボ ド) 2. 1枚を2時間以下、1日5枚を目指す 制約条件を設定し、異常を検知する。 制約条件を設定し、異常を検知する。 3. 目的・目標・施策を設定し数値測定する 3 目的・目標・施策を設定し数値測定する 数値測定する。 する。 4. 朝会、KPTでコミュニケーションの活性化 朝会、KPTでコミュニケーションの活性化 変動対応力のある小集団を作り、 変化に対応しKAIZENできる人財を育成する。 Developers Summit 2010
  6. 6. 3-1 作業カードの推移 作業カ ドの推移 作業カ ド推移(MI開発チ ム) 作業カード推移(MI開発チーム) 45 予定枚数(グループ) 予定枚数をオーバ 実績枚数(グループ) 作業カードを使ったKAIZEN活動 40 目標を変更 正味作業 作業を正味・非正味・その他 35 非正味作業 に分ける。 分 る その他作業 1枚を2時間以下に分解する。 30 1日5枚実施する。 25 20 15 10 5 0 1日の作業カ ド増加(5枚→6枚) 1日の作業カード増加(5枚→6枚) 1枚あたりが1.7時間(目標値以下に減少) Developers Summit 2010
  7. 7. 3-2 伝道師のねらい 見える化でチーム力アップ 1列待ち1個ながし→負荷を均等にする 1列待ち1個ながし→ 列待ち 個ながし 制約で個人能力UP(合目標) 短時間作業 制約で個人能力UP(合目標) 全員参加する活動(競争原理) →在庫をなくす 全員参加する活動(競争原理) カ カード推移 推移 →生産性測定 KAIZEN活動 KAIZEN活動で成功を体感した 1日6枚 1枚あたり1 7時間 1枚あたり1.7時間 開発に特化した活動で成果を出したい Developers Summit 2010
  8. 8. 4.ばらつき ばら き 定期的な開発状況報告 →期間別 会社別の品質データを集計 期間別、会社別の品質データを集計 コンポーネント?外製と内製?開発言語? 外製と内製?開発言語? 特性に違いはなく、集計値では差がない 過去1年分のデータを明細で調査 →開発規模でデータをソート 50Step以下 開発スピード:1.0-1.5KS/人月 障害0件/KS 300Step以下 開発スピード:2.0-3.0KS/人月 300St 以下 開発スピ ド 2 0 3 0KS/人月 障害 5件/KS 300Stepより上開発スピード:0.5-1.0 KS/人月障害10-20件/KS 当てはまらないものが品質不良をおこしている 当てはまらないものが品質不良をおこしている 品質不良をおこしている。 をおこしている。 Developers Summit 2010
  9. 9. 4-1 高品質・高生産 高品質 高生産 TRY&TEST型 集中型 →障害作込みが少ない →障害作込みが多い リスクは少ない リスクは多い 強制するのは難しい レビュー・テストに (仕事のやり方) 仕事のやり方) 高いスキルが必要 高いスキルが必要 TRY&TEST型 スキルに依存しない TRY&TEST型はスキルに依存しない スキルに依存しない。 しない。 300Step以下の開発の繰り返しのはず。 300Step以下の開発の繰り返しのはず。 想定が正しいかを検証しよう!! 想定が し かを検証しよう Developers Summit 2010
  10. 10. 4-2 高品質パターン検証 高品質 タ ン検証 開発工数3日以内を10件用意(20人日) ベテラン、中堅、新人(投入工数:15人日)で何件 ベテラン、中堅、新人(投入工数:15人日)で何件 手順は今までどおり(ITは自動化) 手順は今までどおり(ITは自動化) 1. 開発 ピ ド 2.4KS/人月→目標:2.0KS/人月 開発スピード: 目標:2.0KS/人月 標 2. 障害作込み件数:1.1件/KS→目標:5件/KS以下 目標:5件/KS以下 3. 生産性:20件/月(3人で開発する件数) KAIZEN活動的アプローチ(制約) →製造工程(PG-IT)を5日以下 Developers Summit 2010
  11. 11. 5.開発プロセスの改善 プロセスに着手するKAIZEN活動 プ セスに着手する プロセスに着手するKAIZEN活動 セスに着手するKAIZEN →開発作業はすべて正味にしていた 顧客価値でプロセスを考え、正味・非正味に分け 顧客価値でプ 客価値 プロセスを考え、正味・非正味に分け を考 味 非 味 分 る。正味には手をつけない。「ハードディスクの作成は、 検査していたらコストに合わない」 検査 た 合わな 改善しなくては進めないように制約条件(高い数値 改善しなくては進めないように制約条件(高い数値 目標)を設定する。異常が発生しやすくする。 目標)を設定する。異常が発生しやすくする。 目的・目標・施策を設定し、数値測定をして改善す 目的・目標・施策を設定し、数値測定をして改善す る。(管理する数値は顧客価値の単位で) る。(管理する数値は る (管理する数値は顧客価値の単位で) (管理する数値は顧客価値 Developers Summit 2010
  12. 12. 5-1 顧客価値で分類 UI SS PS PG SR PT IT ST 正味・非正味に分解する テスト工程を分解した UI SS PS PG SR PT ITD ITL0 IT 修 ST 修正 設計・製造・検証に分離 設計 製造 検証 UI ITL0 ITLn ST SS PG SR PT IT レベルダウン防止 ITD 設計工程で品質を作り込む 品質の良い期間で製造 PPL 正味作業(顧客視点で価値がある) 非正味作業(顧客視点で価値がない) Developers Summit 2010
  13. 13. 5-2 制約条件の明確化 設計製造期間を1カ月、検証期間を2週間とする。 設計製造期間を1カ月、検証期間を2週間とする。 製造は、5日以下で繰返型にする。 製造は、5日以下で繰返型にする。 作成スピード明確化 生産量の明確化 スピード2.0KS/人月、障害5件/KSとする。 スピード2.0KS/人月、障害5件/KSとする。 品質の明確化 1人当たり3DIL/月実施する 1人当たり3DIL/月 1カ月 2週間 設計 製造 検証 UI テストセット作成 テストセ ト作成 繰り返し SS ITD ITL0 レベルダウン防止 レベ ダウ 防止 PPL ITLn ITLn PG/SR PG/SR ST /PT/IT /PT/IT 運用フロー 新機能確認 全障害確認 Developers Summit 2010
  14. 14. 5-3 測定する単位を決める DIL:ディルと読む、Development DIL:ディルと読む、Development Iteration count for Lean user valueの略で、製造の最 valueの略で、製造の最 少単位であるイテレーションの数をあらわす 少単位であるイテレーションの数をあらわす イテレーションの数をあらわす。 をあらわす。 開発項目を顧客価値の最小単位に分割し、5 開発項目を顧客価値の最小単位に分割し、5 日以下にする。DILの数が価値の数である 日以下にする DILの数が価値の数である DILの数が価値の数である。 日以下にする。DILの数が価値の数である。 目標値を設定する。(月産○○台生産) 7人体制とすると月産21DILが目標になる。 Developers Summit 2010
  15. 15. 5-4 在庫をなくす 在庫をなくす 1. 在庫がないと要求毎作る 1 製造を5日以下にしろ! 2. 要求と作成の差がわかる 1. 5日以下の繰返開発を計画 3. 要求スピードに合わせて 3 要求スピ ドに合わせて 2. 2 テスト回数が増加(自動化必須) 生産方式がかわる。 3. 製造と検証方法を先に考える ※ロット生産をやめろ!! 4. 設計書の見直しが入り、製造前の 4 設計書の見直しが入り 製造前の だと問題が解決範囲が狭い 完成度があがる。 5. 5 製造時の規模が小さくなり障害が 減少し、スピードがあがる。 6. 1個の処理時間が短いため、 処理件数も増え、 生産性が向上する。 Developers Summit 2010
  16. 16. 5-5 ムダが見える 制約により処理するスピードを定義する。異常 により開発スピードが遅いとか、生産性が低い により開発スピ ドが遅いとか により開発スピードが遅いとか、生産性が低い 開発スピ ドが遅いとか ことが分かる。 制約条件が明確になると、ムダが見えてくる。 制約条件が明確になると、ムダが見えてくる。 (設計やテストのやり方、編集作業など) 問題点が浮き彫りになる。 問題点が浮き彫りになる。 製品の機能不足が 確 な 。 製品の機能 製 機能不足が明確になる が明確になる。 品質問題が明確になる。 品質問題が明確になる。 保守するための資材が必要になる。 保守するための資材が必要になる。 知恵が生まれてくる Developers Summit 2010
  17. 17. 6.プロセス変化の理由 プ セス変化の理由 3つのポイント ポイン 1. 設計工程でのやるべきこととやり方の見直し 2. 2 インクリメンタルに製造するためのテスト方法 3. 時間的制約をつけた製造・検証工程 UI SS ITD ITL0 PPL ITLn PG SR PT IT ST 設計 製造 検証 Developers Summit 2010
  18. 18. 6-1 設計プロセスの変化 設計プ セスの変化 UI/SS/PSと行っていたもの UI/SS/PSと行っていたもの UI/SS/ITD/PPLを同時進行で UI/SS/ITD/PPLを同時進行で スパイラルに行う。 製造方法を計画する。 →課題を分解しイテレーション回数を決める 課題を分解しイテレーション回数を決める 結合テストの計画を立てる。 結合テストの計画を立てる。 →品質保証・検証範囲を明確にする。 多面的に作業し、品質を作り込む。 多面的に作業し、品質を作り込む。 内容を変更せずやり方だけを変える。 内容を変更せずやり方だけを変える。 Developers Summit 2010
  19. 19. 6-2 製造プロセスの変化 製造プ セスの変化 修正内容に関係なく全機能をテスト 修正内容に関係なく全機能をテスト 繰り返しやるため、自動テスト 繰り返しやるため、 繰り返しやるため 自動テスト NGの判定が簡単 NGの判定が簡単 2回目以降は、 1. テスト計画(ITD) ) 低コストで可能 2. テストセット作成(ITL0) 修正に躊躇する ことがなくなる。 3. テスト実行 レベルダウン防止 自動化 4. テスト結果判定 工数=0 だれでもできる 5. 障害調査(PG,SR)) 結果が残る。 が 障害が発生して 判定にばらつきが 解決するのは もトレースできる。 少ない。 テストファーストでも ユニットテストでもない もな Developers Summit 2010
  20. 20. 6-3 検証プロセス 検証プ セス 検証する目的を明確にする。 運用フローテスト 新機能確認テスト 障害修正全機能テスト →レベルダウンの防止 テストの標準時間を規定する。(2週間) テストの標準時間を規定する (2週間) →非正味であり、提供までのスピードのボトルネックになる。 設 設計から検証までの最短期間は1.5カ月 検証 最短期間 月 (製品提供のスピード) Developers Summit 2010
  21. 21. 7.事例紹介 事例紹介 GLOVIA/MIのシステム構成 GLOVIA/MIのシステム構成 ファイルを圧縮 する開発!! GLOVIA/MI データ取込 デ タ取込 分析/集計 出力/表示 取 集 取 現 デ 分 計 出 分 会計 ー 会計 他システム連携 り込 場情 析 エ 力 析 タ取 エン ン 部門別 エン レポ 込 自 Excel csv 受注 め 報 受注 ジ ジ ジ ー 由 る を ン ン ン ト な イ そ ビ 視 ンタ 出荷 目的別 出荷 の ュー タ ま ア フ 点 集計表 ま ェ ・・・ で ー 高の csv ス 根拠明細の即時確認 速 シーン定義 抽 出 グラフ Excel 標準化 分析ルール定義 縦横集計定義 表示加工 多様な現場 簡単操作で プログラムレスでの分析集計定義 システム データ高度活用 Developers Summit 2010
  22. 22. 7-1 分割スケジュール 分割スケジ ル 従来の開発スケジュール 全部終わるまでは提供できない。 顧客価値で考えると途中は UI SS PG SR PT IT すべて0であり、 完了してはじめて1になる。 開発規模から 全体で25人日 算出し、 算出し 割合で分割する。 ①価値=0 当プロセスの開発スケジュール ②新規&蓄積 設計(UI/SS/ITD/PPL) 7日 ③新規&ジャーナル 取込結果ファイル圧縮 5日 ④新規 取込結果ファイル解凍 3日 ⑤新規&既存 蓄積型取込み対応 効率を考え ⑥SE 1日 置換型取込み対応 一緒に開発 緒に開発 2日 参照機能対応 開発中に必要 3日→5日 移行ツ ル作成 移行ツール作成 性が発覚、追加 性が発覚 追加 見積ミス SE用ツール開発【追加】 した。 2日 で2日増加 Developers Summit 2010
  23. 23. 7-2 顧客価値で分割 本プロセスのメリット 開発項目の進行が管理できる。 開発項目の中で優先度づけができスケジュールを変更で きる。例えば、④と⑤を入れ替えるとか割込みを入れる 開発遅延、問題発生の範囲が局所化される ローテーションがしやすい デメリット デメリットではない!! 管理する項目は増える アラーム頻度が上がる リーダ作業は増加する。 リ ダ作業は増加する Developers Summit 2010
  24. 24. 8.運用するポイント 運用するポイント 変更しない事 変更 な 事 設 設計・製造・検証で作成する成果物 設計・製造・検証で作成する成果物 製 検証 す 果物 品質データのチェック及び工程完了判断 品質データのチェック及び工程完了判断 短期間に課題が抽出されるため、課題管理 短期間に課題が抽出されるため、課題管理を 短期間に課題が抽出されるため 課題管理を きちんと行う。 手順は変更しても良いため細かく規定しない、 価値を共有する。 価値を共有する。 横やりに屈しない強靭な心 →例えば:分割で品質低下しないのか? Developers Summit 2010
  25. 25. 9-1 目標達成の理由 設計品質の向上 重複設計の禁止(PSと 重複設計の禁止(PSとPG) ×PGを渡すためにプレコーディング PGを渡すためにプレコーディング 同時進行と飛ばし禁止(RD/UI徹底) 同時進行と飛ばし禁止(RD/UI徹底) ×前提や制約を決めない ITDやPPLによる設計書の相互見直し ITDやPPLによる設計書の相互見直し ○テストの観点で設計書見直し テストの観点で設計書見直し ○イテレーション分割により作業量の縮小 イテレーション分割により作業量の縮小 割 作業 縮 Developers Summit 2010
  26. 26. 9-2 目標達成の理由 開発技術の継承と資産化 開発技術の継承と資産化 各プロセスの目的の見直し レビューは、観点による仕様確認 レビューは、観点による仕様確認 レビ は 教育はペア作業(SS/PS/PG)と 教育はペア作業(SS/PS/PG)とOJT ) 障害は「検出可能」でなく「検出すべき」 障害は「検出可能」でなく「検出すべき」 テスト自動化により ○デバック技術が伝搬する デバック技術が伝搬する ○ローテーションが容易 Developers Summit 2010
  27. 27. 9-3 目標達成の理由 価値共有とマインド成長 価値共有とマインド成長 テスト=非正味=自動化 テスト=非正味=自動化 ○繰り返し続けられる ○繰り返し続けられる 顧客価値を考 顧客価値を考えた作業分割 顧客価値を考 を考えた作業分割 作業分割 ○製造前の明確な目標設定 ムダなものを作らない ○スケジュール詳細化 遅れの局所化、早めのアラーム 遅れの局所化、早めのアラーム Developers Summit 2010
  28. 28. 10. 補足事項 開発プロセスは開発環境に依存しない 開発プロセスは開発環境に依存しない 動作OSはWindowsで C言語 JAVA(JSP サ 動作OSはWi d Windowsで、 言語、JAVA(JSP,サー で、C言語、JAVA JSP,サー ブレット、アプレット)が混在している。 テストは、ユニットテストを使用していない。 生産性は安定しており、開発スピ ドも早い 生産性は安定しており、開発スピードも早い 生産性は安定しており、開発スピードも早い 開発スピ 開発者の人数の変動はあるが、1ラウンド20DIL 開発者の人数の変動はあるが、1ラウンド20DIL を実現している。 を実現している 開発スピードは、1.6-2.4KS/人月 開発スピードは、1.6-2.4KS/人月 自社開発分の3年間でレベルダウン障害は、1 件で、開発品質は良 。 件で、開発品質は良い。 件で、開発品質は良い。 開発品質は良 Developers Summit 2010
  29. 29. 11.KAIZEN活動のポイント 顧客価値でプロセスを考え、正味・非正味に分け 顧客価値でプロセスを考え、正味・非正味に分け る。正味には手をつけない。 正味には手をつけない ②価値観の変更、共有が必要 改善しなくては進めないように制約条件(高い数値 改善しなくては進めないように制約条件(高い数値 目標)を設定する。異常が発生しやすくする。 目標)を設定する。異常が発生しやすくする。 ①良いもぎとりが必要 目的 目標 施策を設定し、 目的・目標・施策を設定し、数値測定をして改善す 目的・目標・施策を設定し、数値測定をして改善す 施策を設定し、数値測定 る。(管理する数値は顧客価値の単位で) る。(管理する数値は顧客価値の単位で) ③効果測定には数値が必要 やらなきゃいけない活動にすること で人財が成長する Developers Summit 2010
  30. 30. 添付資料1 開発単位FAQ 添付資料 開発単位FAQQ 疑問点 50Stepと300Stepのちがいなぜ 疑問点1 50Stepと300Stepのちが なぜ p pのちがいなぜ →6H~8Hの作業、付帯作業の割合が多いから 6H~8Hの作業、付帯作業の割合が多いから 疑問点2 能力の高い人の邪魔なるのでは 能力の高い人の邪魔なるのでは →ならない。人によってはさらに向上する。 ならない。人によってはさらに向上する。 疑問点3 開発単位の分割のコツは? 開発単位の分割のコツは? →よく考えろ!!とにかく分割しろ!! よく考えろ!!とにかく分割しろ!! →考えるための材料を与えているか?(要件・重要度) 考えるための材料を与えているか?(要件 重要度) 疑問点4 なぜ時間制約なのか なぜ時間制約なのか →考える時に想像しやすい。能力に関係ない。 考える時に想像しやすい 能力に関係ない 想像しやすい。能力に関係ない。 →→待ち行列の原理から、1個の処理時間が短くなれば →→待ち行列の原理から、1個の処理時間が短くなれば 自然に生産性は向上する。制約をつければ、行動が かわる。行動を変えるために価値を共有する。 Developers Summit 2010
  31. 31. 添付資料2 KAIZENボ ド KAIZENボ KAIZENボード ボード • 目で見る管理 活動の見える化 (Visible Management ) を利用 作業カード置き場 目的・方針・考え方 A3で3枚のス A3で3枚のスペー 施策などを記入 • 自立管理の展開 ス A4で2枚のスペース • 経営管理と現場管理の融合 • 異常の認識 • グループ(チーム)の対話スペース • •ねらい 小さなスペースで今すぐ 小さな ペ 今すぐ 生産性 測定グラフ 文字が小さいので距離が ふりかえり 縮まる (KPT) 議事録 数値による行動管理 Developers Summit 2010
  32. 32. 添付資料3 朝会 • 朝会(スクラムミーティング)を実施 仕事の共有・情報の共有・意識の共有を 朝会の様子 朝会 様 する。 •ねらい 短い時間(10分)で 作業調整と情報共有 仕事にリズムを作る ズ コミュニケ ションの改善 コミュニケーションの改善 スタンディングで10分 昨日の実績、今日の予定 問題の報告 作業 会議の調整 作業・会議の調整 Developers Summit 2010
  33. 33. 添付資料4 ふりかえり(KPT) ふりかえり(KPT) • ふりかえり(KPT)を週1回実施する。 ふりかえり(KPT)の様子 • テーマは各グループで決める。 • ブレーンストーミングでKeep Problem try の順で行う 各10分ずつで30分 t の順で行う。各10分ずつで30分 • Tryはだれがやっても同じように • になる) なる •ねらい 短い時間で解決 (KAIZEN意識) ( 識 仕事にリズムを作る KPTを10分ずつで行う 議事録を作成し、部で共有 議事録を作成 部 共有 言いたいことが言える Developers Summit 2010

×