Más contenido relacionado La actualidad más candente (20) Similar a タイムボックス制約付きインクリメンタル開発 (20) タイムボックス制約付きインクリメンタル開発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. 2.プロセス概要
プ セス概要 アジャイル開発や
リーンソフトウェア開発
というよりKAIZEN活動
というよりKAIZEN活動
タイムボックス制約付きインクリメン
タル開発プロセスとは
1. 開発項目は に分割する
2. 分割した単位をイテレーションと呼び、PG-IT
を5日以下にする( )
3. イテレーションを繰り返して機能追加する
( )
Developers Summit 2010
4. 3.2つのヒント
のヒント
KAIZEN活動による生産性の向上
KAIZEN活動による生産性の向上
(非正味作業を減らし、正味作業を増やす)
非正味作業を減らし、正味作業を増やす)
プロジェクトの生産性・品質に大きな
ばらつきがあった。
ばらつきがあった。
Developers Summit 2010
5. 3.KAIZEN活動
活動
作業の平準化
「かんばん」、「あんどん」
」、 あ 」
1. 正味・非正味・その他に分類し ムダとり
作業カードにして見える化(VMボード
作業カ ドにして見える化(VMボ ド)
作業カードにして見える化(VMボード)
ドにして見える化(VMボ ド)
2. 1枚を2時間以下、1日5枚を目指す
制約条件を設定し、異常を検知する。
制約条件を設定し、異常を検知する。
3. 目的・目標・施策を設定し数値測定する
3 目的・目標・施策を設定し数値測定する
数値測定する。
する。
4. 朝会、KPTでコミュニケーションの活性化
朝会、KPTでコミュニケーションの活性化
変動対応力のある小集団を作り、
変化に対応しKAIZENできる人財を育成する。
Developers Summit 2010
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
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. 4-1 高品質・高生産
高品質 高生産
TRY&TEST型 集中型
→障害作込みが少ない →障害作込みが多い
リスクは少ない リスクは多い
強制するのは難しい レビュー・テストに
(仕事のやり方)
仕事のやり方) 高いスキルが必要
高いスキルが必要
TRY&TEST型 スキルに依存しない
TRY&TEST型はスキルに依存しない
スキルに依存しない。
しない。
300Step以下の開発の繰り返しのはず。
300Step以下の開発の繰り返しのはず。
想定が正しいかを検証しよう!!
想定が し かを検証しよう
Developers Summit 2010
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. 5.開発プロセスの改善
プロセスに着手するKAIZEN活動
プ セスに着手する
プロセスに着手するKAIZEN活動
セスに着手するKAIZEN
→開発作業はすべて正味にしていた
顧客価値でプロセスを考え、正味・非正味に分け
顧客価値でプ
客価値 プロセスを考え、正味・非正味に分け
を考 味 非 味 分
る。正味には手をつけない。「ハードディスクの作成は、
検査していたらコストに合わない」
検査 た 合わな
改善しなくては進めないように制約条件(高い数値
改善しなくては進めないように制約条件(高い数値
目標)を設定する。異常が発生しやすくする。
目標)を設定する。異常が発生しやすくする。
目的・目標・施策を設定し、数値測定をして改善す
目的・目標・施策を設定し、数値測定をして改善す
る。(管理する数値は顧客価値の単位で)
る。(管理する数値は
る (管理する数値は顧客価値の単位で)
(管理する数値は顧客価値
Developers Summit 2010
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
15. 5-4 在庫をなくす
在庫をなくす
1. 在庫がないと要求毎作る
1 製造を5日以下にしろ!
2. 要求と作成の差がわかる 1. 5日以下の繰返開発を計画
3. 要求スピードに合わせて
3 要求スピ ドに合わせて 2.
2 テスト回数が増加(自動化必須)
生産方式がかわる。 3. 製造と検証方法を先に考える
※ロット生産をやめろ!! 4. 設計書の見直しが入り、製造前の
4 設計書の見直しが入り 製造前の
だと問題が解決範囲が狭い 完成度があがる。
5.
5 製造時の規模が小さくなり障害が
減少し、スピードがあがる。
6. 1個の処理時間が短いため、
処理件数も増え、
生産性が向上する。
Developers Summit 2010
17. 6.プロセス変化の理由
プ セス変化の理由
3つのポイント
ポイン
1. 設計工程でのやるべきこととやり方の見直し
2.
2 インクリメンタルに製造するためのテスト方法
3. 時間的制約をつけた製造・検証工程
UI SS
ITD ITL0
PPL ITLn
PG SR PT IT
ST
設計 製造 検証
Developers Summit 2010
18. 6-1 設計プロセスの変化
設計プ セスの変化
UI/SS/PSと行っていたもの
UI/SS/PSと行っていたもの
UI/SS/ITD/PPLを同時進行で
UI/SS/ITD/PPLを同時進行で
スパイラルに行う。
製造方法を計画する。
→課題を分解しイテレーション回数を決める
課題を分解しイテレーション回数を決める
結合テストの計画を立てる。
結合テストの計画を立てる。
→品質保証・検証範囲を明確にする。
多面的に作業し、品質を作り込む。
多面的に作業し、品質を作り込む。
内容を変更せずやり方だけを変える。
内容を変更せずやり方だけを変える。
Developers Summit 2010
19. 6-2 製造プロセスの変化
製造プ セスの変化
修正内容に関係なく全機能をテスト
修正内容に関係なく全機能をテスト
繰り返しやるため、自動テスト
繰り返しやるため、
繰り返しやるため 自動テスト
NGの判定が簡単
NGの判定が簡単
2回目以降は、
1. テスト計画(ITD)
) 低コストで可能
2. テストセット作成(ITL0) 修正に躊躇する
ことがなくなる。
3. テスト実行 レベルダウン防止
自動化
4. テスト結果判定 工数=0 だれでもできる
5. 障害調査(PG,SR))
結果が残る。
が
障害が発生して 判定にばらつきが 解決するのは
もトレースできる。 少ない。 テストファーストでも
ユニットテストでもない
もな
Developers Summit 2010
20. 6-3 検証プロセス
検証プ セス
検証する目的を明確にする。
運用フローテスト
新機能確認テスト
障害修正全機能テスト
→レベルダウンの防止
テストの標準時間を規定する。(2週間)
テストの標準時間を規定する (2週間)
→非正味であり、提供までのスピードのボトルネックになる。
設
設計から検証までの最短期間は1.5カ月
検証 最短期間 月
(製品提供のスピード)
Developers Summit 2010
21. 7.事例紹介
事例紹介
GLOVIA/MIのシステム構成
GLOVIA/MIのシステム構成
ファイルを圧縮
する開発!!
GLOVIA/MI
データ取込
デ タ取込 分析/集計 出力/表示
取 集
取 現 デ 分 計 出 分
会計 ー 会計 他システム連携
り込 場情 析 エ 力 析
タ取 エン ン 部門別 エン レポ
込 自 Excel csv
受注 め 報 受注 ジ ジ ジ ー 由
る を ン ン ン ト な
イ そ ビ 視
ンタ 出荷 目的別
出荷 の ュー
タ ま ア
フ 点 集計表
ま
ェ ・・・ で
ー 高の
csv ス 根拠明細の即時確認 速
シーン定義 抽
出 グラフ
Excel 標準化 分析ルール定義 縦横集計定義 表示加工
多様な現場 簡単操作で
プログラムレスでの分析集計定義
システム データ高度活用
Developers Summit 2010
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. 7-2 顧客価値で分割
本プロセスのメリット
開発項目の進行が管理できる。
開発項目の中で優先度づけができスケジュールを変更で
きる。例えば、④と⑤を入れ替えるとか割込みを入れる
開発遅延、問題発生の範囲が局所化される
ローテーションがしやすい
デメリット
デメリットではない!!
管理する項目は増える
アラーム頻度が上がる
リーダ作業は増加する。
リ ダ作業は増加する
Developers Summit 2010
24. 8.運用するポイント
運用するポイント
変更しない事
変更 な 事
設
設計・製造・検証で作成する成果物
設計・製造・検証で作成する成果物
製 検証 す 果物
品質データのチェック及び工程完了判断
品質データのチェック及び工程完了判断
短期間に課題が抽出されるため、課題管理
短期間に課題が抽出されるため、課題管理を
短期間に課題が抽出されるため 課題管理を
きちんと行う。
手順は変更しても良いため細かく規定しない、
価値を共有する。
価値を共有する。
横やりに屈しない強靭な心
→例えば:分割で品質低下しないのか?
Developers Summit 2010
25. 9-1 目標達成の理由
設計品質の向上
重複設計の禁止(PSと
重複設計の禁止(PSとPG)
×PGを渡すためにプレコーディング
PGを渡すためにプレコーディング
同時進行と飛ばし禁止(RD/UI徹底)
同時進行と飛ばし禁止(RD/UI徹底)
×前提や制約を決めない
ITDやPPLによる設計書の相互見直し
ITDやPPLによる設計書の相互見直し
○テストの観点で設計書見直し
テストの観点で設計書見直し
○イテレーション分割により作業量の縮小
イテレーション分割により作業量の縮小
割 作業 縮
Developers Summit 2010
26. 9-2 目標達成の理由
開発技術の継承と資産化
開発技術の継承と資産化
各プロセスの目的の見直し
レビューは、観点による仕様確認
レビューは、観点による仕様確認
レビ は
教育はペア作業(SS/PS/PG)と
教育はペア作業(SS/PS/PG)とOJT
)
障害は「検出可能」でなく「検出すべき」
障害は「検出可能」でなく「検出すべき」
テスト自動化により
○デバック技術が伝搬する
デバック技術が伝搬する
○ローテーションが容易
Developers Summit 2010
27. 9-3 目標達成の理由
価値共有とマインド成長
価値共有とマインド成長
テスト=非正味=自動化
テスト=非正味=自動化
○繰り返し続けられる
○繰り返し続けられる
顧客価値を考
顧客価値を考えた作業分割
顧客価値を考
を考えた作業分割
作業分割
○製造前の明確な目標設定
ムダなものを作らない
○スケジュール詳細化
遅れの局所化、早めのアラーム
遅れの局所化、早めのアラーム
Developers Summit 2010
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. 11.KAIZEN活動のポイント
顧客価値でプロセスを考え、正味・非正味に分け
顧客価値でプロセスを考え、正味・非正味に分け
る。正味には手をつけない。
正味には手をつけない
②価値観の変更、共有が必要
改善しなくては進めないように制約条件(高い数値
改善しなくては進めないように制約条件(高い数値
目標)を設定する。異常が発生しやすくする。
目標)を設定する。異常が発生しやすくする。
①良いもぎとりが必要
目的 目標 施策を設定し、
目的・目標・施策を設定し、数値測定をして改善す
目的・目標・施策を設定し、数値測定をして改善す
施策を設定し、数値測定
る。(管理する数値は顧客価値の単位で)
る。(管理する数値は顧客価値の単位で)
③効果測定には数値が必要
やらなきゃいけない活動にすること
で人財が成長する
Developers Summit 2010
30. 添付資料1 開発単位FAQ
添付資料 開発単位FAQQ
疑問点 50Stepと300Stepのちがいなぜ
疑問点1 50Stepと300Stepのちが なぜ
p pのちがいなぜ
→6H~8Hの作業、付帯作業の割合が多いから
6H~8Hの作業、付帯作業の割合が多いから
疑問点2 能力の高い人の邪魔なるのでは
能力の高い人の邪魔なるのでは
→ならない。人によってはさらに向上する。
ならない。人によってはさらに向上する。
疑問点3 開発単位の分割のコツは?
開発単位の分割のコツは?
→よく考えろ!!とにかく分割しろ!!
よく考えろ!!とにかく分割しろ!!
→考えるための材料を与えているか?(要件・重要度)
考えるための材料を与えているか?(要件 重要度)
疑問点4 なぜ時間制約なのか
なぜ時間制約なのか
→考える時に想像しやすい。能力に関係ない。
考える時に想像しやすい 能力に関係ない
想像しやすい。能力に関係ない。
→→待ち行列の原理から、1個の処理時間が短くなれば
→→待ち行列の原理から、1個の処理時間が短くなれば
自然に生産性は向上する。制約をつければ、行動が
かわる。行動を変えるために価値を共有する。
Developers Summit 2010
31. 添付資料2 KAIZENボ ド
KAIZENボ
KAIZENボード
ボード
• 目で見る管理 活動の見える化
(Visible Management ) を利用 作業カード置き場
目的・方針・考え方
A3で3枚のス
A3で3枚のスペー
施策などを記入
• 自立管理の展開 ス
A4で2枚のスペース
• 経営管理と現場管理の融合
• 異常の認識
• グループ(チーム)の対話スペース
• •ねらい
小さなスペースで今すぐ
小さな ペ 今すぐ 生産性
測定グラフ
文字が小さいので距離が ふりかえり
縮まる (KPT)
議事録
数値による行動管理
Developers Summit 2010
32. 添付資料3 朝会
• 朝会(スクラムミーティング)を実施
仕事の共有・情報の共有・意識の共有を 朝会の様子
朝会 様
する。
•ねらい
短い時間(10分)で
作業調整と情報共有
仕事にリズムを作る
ズ
コミュニケ ションの改善
コミュニケーションの改善 スタンディングで10分
昨日の実績、今日の予定
問題の報告
作業 会議の調整
作業・会議の調整
Developers Summit 2010
33. 添付資料4 ふりかえり(KPT)
ふりかえり(KPT)
• ふりかえり(KPT)を週1回実施する。 ふりかえり(KPT)の様子
• テーマは各グループで決める。
• ブレーンストーミングでKeep Problem
try の順で行う 各10分ずつで30分
t の順で行う。各10分ずつで30分
• Tryはだれがやっても同じように
• になる)
なる
•ねらい
短い時間で解決
(KAIZEN意識)
( 識
仕事にリズムを作る KPTを10分ずつで行う
議事録を作成し、部で共有
議事録を作成 部 共有
言いたいことが言える
Developers Summit 2010