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

タイムボックス制約付き
インクリメンタル開発プロセス
～高品質、低コスト、納期厳守の同時実現を目指して～
高品質低コスト納期厳守の同時実現を目指して

18-Ｃ-5 松浦豪一
富士通株式会社
産業流通ソリュション本部
産業・流通ソリューション本部
ＧＬＯＶＩＡエンジニアリング事業部
Developers Summit 2010

１．自己紹介
自己紹介
１９８６年入社
旧：㈱富士通静岡エンジニアリング→
旧：㈱富士通静岡エンジニアリング→
現：㈱富士通ソフトウェアテクノロジーズ
現㈱富士通ソフトウアテクノロジズ
汎用機ソフトウェア・ミドルウェアの開発
２００１年からGLOVIA-
２００１年からGLOVIA-C会計の開発
２００５年からKAIZEN活動を実践
２００５年からKAIZEN活動を実践
→KAIZEN塾（FST１期）伝道師型
KAIZEN塾（FST１期）伝道師型
２００６年１１月より、富士通㈱に出向
２００７年８月よりGLOVIA/MIの開発リーダ
２００７年８月よりの開発リーダ

２．プロセス概要
プセス概要アジャイル開発や
リーンソフトウェア開発
というよりKAIZEN活動
というよりKAIZEN活動

タイムボックス制約付きインクリメン
タル開発プロセスとは

1. 開発項目はに分割する
2. 分割した単位をイテレーションと呼び、PG-IT
を５日以下にする（）
3. イテレーションを繰り返して機能追加する
（）

３．２つのヒント
のヒント
KAIZEN活動による生産性の向上
KAIZEN活動による生産性の向上
(非正味作業を減らし、正味作業を増やす)
非正味作業を減らし、正味作業を増やす)
プロジェクトの生産性・品質に大きな
ばらつきがあった。
ばらつきがあった。


３．ＫＡＩＺＥＮ活動
活動
作業の平準化
「かんばん」、「あんどん」
」、あ」

1. 正味・非正味・その他に分類しムダとり
作業カードにして見える化（VMボード
作業カドにして見える化（VMボド）
作業カードにして見える化（VMボード）
ドにして見える化（VMボド）
2. １枚を２時間以下、１日５枚を目指す
制約条件を設定し、異常を検知する。
制約条件を設定し、異常を検知する。
3. 目的・目標・施策を設定し数値測定する
3 目的・目標・施策を設定し数値測定する
数値測定する。
する。
4. 朝会、KPTでコミュニケーションの活性化
朝会、KPTでコミュニケーションの活性化

変動対応力のある小集団を作り、
変化に対応しKAIZENできる人財を育成する。

３－１作業カードの推移
作業カドの推移
作業カド推移（MI開発チム）
作業カード推移（MI開発チーム）
45 予定枚数（グループ）

予定枚数をオーバ実績枚数（グループ）作業カードを使ったKAIZEN活動
40
目標を変更正味作業作業を正味・非正味・その他
35 非正味作業に分ける。
分る
その他作業１枚を２時間以下に分解する。
30
１日５枚実施する。
25

20

15

10

5

0

１日の作業カド増加（５枚→６枚）
１日の作業カード増加（５枚→６枚）
1枚あたりが１．７時間（目標値以下に減少）

３－２伝道師のねらい
見える化でチーム力アップ
１列待ち１個ながし→負荷を均等にする
１列待ち１個ながし→
列待ち個ながし
制約で個人能力UP（合目標）短時間作業
制約で個人能力UP（合目標）
全員参加する活動（競争原理） →在庫をなくす
全員参加する活動（競争原理）
カ
カード推移
推移
→生産性測定

KAIZEN活動
KAIZEN活動で成功を体感した
1日６枚１枚あたり１７時間
１枚あたり１．７時間
開発に特化した活動で成果を出したい


４．ばらつき
ばらき
定期的な開発状況報告
→期間別会社別の品質データを集計
期間別、会社別の品質データを集計

コンポーネント？外製と内製？開発言語？
外製と内製？開発言語？
特性に違いはなく、集計値では差がない

過去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
当てはまらないものが品質不良をおこしている
当てはまらないものが品質不良をおこしている
品質不良をおこしている。
をおこしている。

４－１高品質・高生産
高品質高生産
TRY＆TEST型集中型
→障害作込みが少ない →障害作込みが多い

リスクは少ないリスクは多い
強制するのは難しいレビュー・テストに
（仕事のやり方）
仕事のやり方）高いスキルが必要
高いスキルが必要

TRY＆TEST型スキルに依存しない
TRY＆TEST型はスキルに依存しない
スキルに依存しない。
しない。
300Step以下の開発の繰り返しのはず。
300Step以下の開発の繰り返しのはず。
想定が正しいかを検証しよう！！
想定がしかを検証しよう

４－２高品質パターン検証
高品質タン検証
開発工数３日以内を１０件用意（２０人日）
ベテラン、中堅、新人（投入工数：１５人日）で何件
ベテラン、中堅、新人（投入工数：１５人日）で何件
手順は今までどおり（ITは自動化）
手順は今までどおり（ITは自動化）

1. 開発ピド 2.4KS/人月→目標：2.0KS/人月
開発スピード：目標：2.0KS/人月
標
2. 障害作込み件数：１．１件/KS→目標：５件/KS以下
目標：５件/KS以下
3. 生産性：２０件/月（３人で開発する件数）

KAIZEN活動的アプローチ（制約）
→製造工程（PG-IT)を５日以下

５．開発プロセスの改善
プロセスに着手するKAIZEN活動
プセスに着手する
プロセスに着手するKAIZEN活動
セスに着手するKAIZEN
→開発作業はすべて正味にしていた
顧客価値でプロセスを考え、正味・非正味に分け
顧客価値でプ
客価値プロセスを考え、正味・非正味に分け
を考味非味分
る。正味には手をつけない。「ハードディスクの作成は、
検査していたらコストに合わない」
検査た合わな

改善しなくては進めないように制約条件（高い数値
目標）を設定する。異常が発生しやすくする。

目的・目標・施策を設定し、数値測定をして改善す
る。（管理する数値は顧客価値の単位で）
る。（管理する数値は
る（管理する数値は顧客価値の単位で）
（管理する数値は顧客価値

５－１顧客価値で分類
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
正味作業（顧客視点で価値がある）非正味作業（顧客視点で価値がない）

５－２制約条件の明確化
設計製造期間を１カ月、検証期間を２週間とする。
設計製造期間を１カ月、検証期間を２週間とする。
製造は、５日以下で繰返型にする。
製造は、５日以下で繰返型にする。作成スピード明確化
生産量の明確化
スピード2.0KS/人月、障害５件/KSとする。
スピード2.0KS/人月、障害５件/KSとする。品質の明確化
１人当たり３DIL/月実施する
１人当たり３DIL/月
1カ月２週間

設計製造検証
UI テストセット作成
テストセト作成繰り返し
SS
ITD ITL0
レベルダウン防止
レベダウ防止
PPL ITLn ITLn
PG/SR PG/SR ST
/PT/IT /PT/IT 運用フロー
新機能確認
全障害確認

５－３測定する単位を決める
DIL：ディルと読む、Development
DIL：ディルと読む、Development Iteration
count for Lean user valueの略で、製造の最
valueの略で、製造の最
少単位であるイテレーションの数をあらわす
少単位であるイテレーションの数をあらわす
イテレーションの数をあらわす。
をあらわす。
開発項目を顧客価値の最小単位に分割し、５
開発項目を顧客価値の最小単位に分割し、５
日以下にする。DILの数が価値の数である
日以下にする DILの数が価値の数である
DILの数が価値の数である。
日以下にする。DILの数が価値の数である。

目標値を設定する。（月産○○台生産）
７人体制とすると月産２１DILが目標になる。


５－４在庫をなくす
在庫をなくす
1. 在庫がないと要求毎作る
1 製造を５日以下にしろ！
2. 要求と作成の差がわかる 1. ５日以下の繰返開発を計画
3. 要求スピードに合わせて
3 要求スピドに合わせて 2.
2 テスト回数が増加（自動化必須）
生産方式がかわる。 3. 製造と検証方法を先に考える
※ロット生産をやめろ！！ 4. 設計書の見直しが入り、製造前の
4 設計書の見直しが入り製造前の
だと問題が解決範囲が狭い完成度があがる。
5.
5 製造時の規模が小さくなり障害が
減少し、スピードがあがる。
6. １個の処理時間が短いため、
処理件数も増え、
生産性が向上する。


５－５ムダが見える
制約により処理するスピードを定義する。異常
により開発スピードが遅いとか、生産性が低い
により開発スピドが遅いとか
により開発スピードが遅いとか、生産性が低い
開発スピドが遅いとか
ことが分かる。
制約条件が明確になると、ムダが見えてくる。
制約条件が明確になると、ムダが見えてくる。
（設計やテストのやり方、編集作業など）
問題点が浮き彫りになる。
問題点が浮き彫りになる。
製品の機能不足が確な。
製品の機能
製機能不足が明確になる
が明確になる。
品質問題が明確になる。
品質問題が明確になる。
保守するための資材が必要になる。
保守するための資材が必要になる。

知恵が生まれてくる

６．プロセス変化の理由
プセス変化の理由
３つのポイント
ポイン
1. 設計工程でのやるべきこととやり方の見直し
2.
2 インクリメンタルに製造するためのテスト方法
3. 時間的制約をつけた製造・検証工程
ＵＩＳＳ
ＩＴＤＩＴＬ０
ＰＰＬＩＴＬｎ
ＰＧＳＲＰＴＩＴ
ＳＴ

設計製造検証

６－１設計プロセスの変化
設計プセスの変化
UI/SS/PSと行っていたもの
UI/SS/PSと行っていたもの
UI/SS/ITD/PPLを同時進行で
UI/SS/ITD/PPLを同時進行で
スパイラルに行う。
製造方法を計画する。
→課題を分解しイテレーション回数を決める
課題を分解しイテレーション回数を決める
結合テストの計画を立てる。
結合テストの計画を立てる。
→品質保証・検証範囲を明確にする。

多面的に作業し、品質を作り込む。
多面的に作業し、品質を作り込む。
内容を変更せずやり方だけを変える。
内容を変更せずやり方だけを変える。


６－２製造プロセスの変化
製造プセスの変化
修正内容に関係なく全機能をテスト
修正内容に関係なく全機能をテスト
繰り返しやるため、自動テスト
繰り返しやるため、
繰り返しやるため自動テスト
NGの判定が簡単
NGの判定が簡単
２回目以降は、
1. テスト計画（ITD)
) 低コストで可能
2. テストセット作成（ITL0) 修正に躊躇する
ことがなくなる。
3. テスト実行レベルダウン防止
自動化
4. テスト結果判定工数＝０だれでもできる

5. 障害調査（PG,SR))
結果が残る。
が
障害が発生して判定にばらつきが解決するのは
もトレースできる。少ない。テストファーストでも
ユニットテストでもない
もな

６－３検証プロセス
検証プセス
検証する目的を明確にする。
運用フローテスト
新機能確認テスト
障害修正全機能テスト
→レベルダウンの防止
テストの標準時間を規定する。（２週間）
テストの標準時間を規定する（２週間）
→非正味であり、提供までのスピードのボトルネックになる。

設
設計から検証までの最短期間は1.5カ月
検証最短期間月
（製品提供のスピード）

７．事例紹介
事例紹介
GLOVIA/MIのシステム構成
GLOVIA/MIのシステム構成
ファイルを圧縮
する開発！！
GLOVIA/MI
データ取込
デタ取込分析／集計出力/表示
取集
取現デ分計出分
会計ー会計他ｼｽﾃﾑ連携
り込場情析エ力析
タ取エンン部門別エンレポ
込自 Excel csv
受注め報受注ジジジー由
るをンンントな
イそビ視
ンタ出荷目的別
出荷のュー
タまア
フ点集計表
ま
ェ・・・で
ー高の
csv ス根拠明細の即時確認速
シーン定義抽
出グラフ
Excel 標準化分析ルール定義縦横集計定義表示加工
多様な現場簡単操作で
プログラムレスでの分析集計定義
システムデータ高度活用


７－１分割スケジュール
分割スケジル
従来の開発スケジュール
全部終わるまでは提供できない。
顧客価値で考えると途中は
UI SS PG SR PT IT
すべて０であり、
完了してはじめて１になる。
開発規模から全体で２５人日
算出し、
算出し
割合で分割する。 ①価値＝０
当プロセスの開発スケジュール ②新規＆蓄積
設計（UI/SS/ITD/PPL) 7日 ③新規＆ｼﾞｬｰﾅﾙ
取込結果ファイル圧縮 5日 ④新規
取込結果ファイル解凍 3日 ⑤新規＆既存
蓄積型取込み対応効率を考え ⑥SE
1日
置換型取込み対応一緒に開発
緒に開発
2日
参照機能対応
開発中に必要 3日→5日
移行ツル作成
移行ツール作成性が発覚、追加
性が発覚追加見積ミス
SE用ツール開発【追加】した。 2日
で２日増加

７－２顧客価値で分割

本プロセスのメリット
開発項目の進行が管理できる。
開発項目の中で優先度づけができスケジュールを変更で
きる。例えば、④と⑤を入れ替えるとか割込みを入れる
開発遅延、問題発生の範囲が局所化される
ローテーションがしやすい
デメリット
デメリットではない！！
管理する項目は増える
アラーム頻度が上がる

リーダ作業は増加する。
リダ作業は増加する

８．運用するポイント
運用するポイント
変更しない事
変更な事
設
設計・製造・検証で作成する成果物
設計・製造・検証で作成する成果物
製検証す果物
品質データのチェック及び工程完了判断
品質データのチェック及び工程完了判断
短期間に課題が抽出されるため、課題管理
短期間に課題が抽出されるため、課題管理を
短期間に課題が抽出されるため課題管理を
きちんと行う。
手順は変更しても良いため細かく規定しない、
価値を共有する。
価値を共有する。
横やりに屈しない強靭な心
→例えば：分割で品質低下しないのか？

９－１目標達成の理由
設計品質の向上
重複設計の禁止(PSと
重複設計の禁止(PSとPG)
×PGを渡すためにプレコーディング
PGを渡すためにプレコーディング
同時進行と飛ばし禁止（RD/UI徹底）
同時進行と飛ばし禁止（RD/UI徹底）
×前提や制約を決めない
ITDやPPLによる設計書の相互見直し
ITDやPPLによる設計書の相互見直し
○テストの観点で設計書見直し
テストの観点で設計書見直し
○ｲﾃﾚｰｼｮﾝ分割により作業量の縮小
ｲﾃﾚｰｼｮﾝ分割により作業量の縮小
割作業縮

９－２目標達成の理由
開発技術の継承と資産化
開発技術の継承と資産化
各プロセスの目的の見直し
レビューは、観点による仕様確認
レビューは、観点による仕様確認
レビは
教育はペア作業（SS/PS/PG)と
教育はペア作業（SS/PS/PG)とOJT
)
障害は「検出可能」でなく「検出すべき」
障害は「検出可能」でなく「検出すべき」
テスト自動化により
○デバック技術が伝搬する
デバック技術が伝搬する
○ローテーションが容易


９－３目標達成の理由
価値共有とマインド成長
価値共有とマインド成長
テスト＝非正味＝自動化
テスト＝非正味＝自動化
○繰り返し続けられる
○繰り返し続けられる
顧客価値を考
顧客価値を考えた作業分割
顧客価値を考
を考えた作業分割
作業分割
○製造前の明確な目標設定
ムダなものを作らない
○スケジュール詳細化
遅れの局所化、早めのアラーム
遅れの局所化、早めのアラーム


１０．補足事項
開発プロセスは開発環境に依存しない
開発プロセスは開発環境に依存しない
動作OSはWindowsで C言語 JAVA（JSP サ
動作OSはWi d
Windowsで、言語、JAVA（JSP,サー
で、C言語、JAVA JSP,サー
ブレット、アプレット）が混在している。
テストは、ユニットテストを使用していない。
生産性は安定しており、開発スピドも早い
生産性は安定しており、開発スピードも早い
生産性は安定しており、開発スピードも早い
開発スピ
開発者の人数の変動はあるが、１ラウンド２０DIL
開発者の人数の変動はあるが、１ラウンド２０DIL
を実現している。
を実現している
開発スピードは、1.6-2.4KS/人月
開発スピードは、1.6-2.4KS/人月
自社開発分の３年間でレベルダウン障害は、１
件で、開発品質は良。
件で、開発品質は良い。
件で、開発品質は良い。
開発品質は良

１１．KAIZEN活動のポイント
る。正味には手をつけない。
正味には手をつけない
②価値観の変更、共有が必要
①良いもぎとりが必要
目的目標施策を設定し、
施策を設定し、数値測定
③効果測定には数値が必要
やらなきゃいけない活動にすること
で人財が成長する

添付資料１開発単位FAQ
添付資料開発単位FAQQ
疑問点 50Stepと300Stepのちがいなぜ
疑問点１ 50Stepと300Stepのちがなぜ
p pのちがいなぜ
→6H～８Hの作業、付帯作業の割合が多いから
6H～８Hの作業、付帯作業の割合が多いから
疑問点２能力の高い人の邪魔なるのでは
能力の高い人の邪魔なるのでは
→ならない。人によってはさらに向上する。
ならない。人によってはさらに向上する。
疑問点３開発単位の分割のコツは？
開発単位の分割のコツは？
→よく考えろ！！とにかく分割しろ！！
よく考えろ！！とにかく分割しろ！！
→考えるための材料を与えているか？(要件・重要度）
考えるための材料を与えているか？(要件重要度）
疑問点４なぜ時間制約なのか
なぜ時間制約なのか
→考える時に想像しやすい。能力に関係ない。
考える時に想像しやすい能力に関係ない
想像しやすい。能力に関係ない。
→→待ち行列の原理から、１個の処理時間が短くなれば
→→待ち行列の原理から、１個の処理時間が短くなれば
自然に生産性は向上する。制約をつければ、行動が
かわる。行動を変えるために価値を共有する。

添付資料２ KAIZENボド
KAIZENボ
KAIZENボード
ボード
• 目で見る管理活動の見える化
（Visible Management ）を利用作業カード置き場
目的・方針・考え方
A3で３枚のス
A3で３枚のスペー
施策などを記入
• 自立管理の展開ス
A4で２枚のスペース
• 経営管理と現場管理の融合
• 異常の認識
• グループ（チーム）の対話スペース
• •ねらい
小さなスペースで今すぐ
小さなペ今すぐ生産性
測定グラフ
文字が小さいので距離がふりかえり
縮まる（KPT）
議事録
数値による行動管理

添付資料３朝会
• 朝会（スクラムミーティング）を実施
仕事の共有・情報の共有・意識の共有を朝会の様子
朝会様
する。

•ねらい
短い時間（１０分）で
作業調整と情報共有
仕事にリズムを作る
ズ
コミュニケションの改善
コミュニケーションの改善スタンディングで１０分
昨日の実績、今日の予定
問題の報告
作業会議の調整
作業・会議の調整


添付資料４ふりかえり（KPT）
ふりかえり（KPT）
• ふりかえり（KPT)を週１回実施する。ふりかえり（KPT)の様子
• テーマは各グループで決める。
• ブレーンストーミングでKeep Probｌem
ｔｒｙの順で行う各１０分ずつで３０分
ｔの順で行う。各１０分ずつで３０分
• Ｔｒｙはだれがやっても同じように
• になる）
なる
•ねらい
短い時間で解決
(KAIZEN意識）
( 識
仕事にリズムを作る KPTを１０分ずつで行う
議事録を作成し、部で共有
議事録を作成部共有
言いたいことが言える

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

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

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

Similar to タイムボックス制約付きインクリメンタル開発 (20)

Recently uploaded

Recently uploaded (12)

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