Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

2,972 views

Published on

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

Published in: Technology
  • Be the first to comment

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

  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

×