SlideShare a Scribd company logo
1 of 14
Download to read offline
「超」短期間開発のための3つの開発マネジメント
Copyright© 2015 RDPi Corporation
Restricted Person Only
「超」短期間開発 仕組み構築のご提案
製品開発を取り巻く環境
2
製品開発を取り巻く環境は厳しさを増しており、製品の高機能化、複雑化、大規模化に加え、開発期間短縮、原
価低減の要求はとどまることはない。そのために、開発現場は大きく変容している。
要素技術の高度化・進化の進展
部品やモジュールの高機能化
主要部品の外部調達増加
部品やモジュールサプライヤーとの協業増加
製品の
高機能化・
大規模化・
複雑化
オフショア開発の増加
海外生産の強化
試作や金型作成などのアウトソーシング増加
海外の新規サプライヤーからの調達増加
終わりのない
開発期間短縮・
原価低減要求
高機能化・大規模化により外部依存度が高くなる
流れの中で、顧客の短納期の要求に応えることが
できる開発の仕組みが求められている
「超」短期間開発
開発を取り巻く環境が
大きく変化しているた
めに、解決が困難な構
造的な問題が発生して
いる。
(次ページを参照のこと)
製品開発を取り巻く環境の変化
=
Copyright© 2015 RDPi Corporation
Restricted Person Only
「超」短期間開発 仕組み構築のご提案
ハードウェア
開発プロセス
DR
先行開発
先行検討
商品企画
DR
DR
DR
初期
流動
量産 出荷
デバイスドライバー開発
部品/デバイスの開発
(サプライヤーでの並行開発)
DR
部品
納入
基本
設計
試作
#1
試作
#2
試作
#3
製造
移管
仕様
定義
システム
設計
設計
DR
製作・
単体テスト
DR
DR
結合テスト
総合評価
システムテスト
DR
ソフトウェア
開発プロセス
従来の開発の仕組みでは対応できない問題が噴出
3
厳しい競争を生き抜くための製品の高機能化、複雑化、大規模化が、外部調達の増加、開発方法の多様化、技術
移転の困難性などの問題を引き起こし、開発現場では様々な問題が噴出している。
HW担当とSW担
当との間で何度も
手戻りが発生
HWとSWは別々に
開発が進む
製品全体の動作
確認ができるの
は量産直前
製造への技術移転が時
間的にも技術的にも困
難になりつつある
購入品やOSSはブ
ラックボックスで設
計書を作成できない DRで工程品質を確認し
ても、その後の外部調
達品のアップデートで
デグレが発生する
DRでの判断
基準が曖昧
結合テストがはじま
るまで完成度や品質
を確認できない
部品やモジュール
により開発方法や
進 がバラバラ
購入部品/モジュー
ルの量産バラツキが
多発する
量産トラブルに
工場側の技術者
が対応できない
外部調達品の品質
が安定しない/制
御できない
先行開発からの
技術移転に手間
取る
Copyright© 2015 RDPi Corporation
Restricted Person Only
「超」短期間開発 仕組み構築のご提案
ハードウェア
開発プロセス
DR
先行開発
先行検討
商品企画
DR
DR
DR
初期
流動
量産 出荷
デバイスドライバー開発
部品/デバイスの開発
(サプライヤーでの並行開発)
DR
部品
納入
基本
設計
試作
#1
試作
#2
試作
#3
製造
移管
仕様
定義
システム
設計
設計
DR
製作・
単体テスト
DR
DR
結合テスト
総合評価
システムテスト
DR
ソフトウェア
開発プロセス
従来の開発の仕組みに内在する問題の原因(1)
4
問題を引き起こしている原因は、ISO や CMMI ベースの標準開発プロセス、ステージゲート方式、専門分業化、
工程管理、DR強化、設計文書化など、従来からの伝統的な開発の仕組みにある。
開発後半でし
か動かせない
製品全体
技術高度化に
ともなう引継
ぎの困難性
分業体制が
生む手戻り
増大する外
部調達品の
品質問題
工程ごとの積
み上げが前提
の品質管理
増加するブ
ラックボッ
クス領域
外部依存にと
もなうリスク
要因の増加
終わりのない
短納期要求
モジュールご
との独自性・
専門性の進展
最終評価工程
の強化による
品質確保
技術高度化に
ともなう引継
ぎの困難性
従来の開発プロセス、体制、マネジメントの
改善では対応できない変化が起こっている。
根本的な解決策が必要とされている。
Copyright© 2015 RDPi Corporation
Restricted Person Only
「超」短期間開発 仕組み構築のご提案
従来の開発の仕組みに内在する問題の原因(2)
5
従来の開発プロセス、開発体制、マネジメントの延長での改善では対応できない変化が起きていることが、問題
の原因である。これまでの延長ではなく、根本的な解決策が必要である。
開発後半でしか動かせない製品全体
技術高度化にともなう引継ぎの困難性
分業体制が生む手戻り
増大する外部調達品の品質問題
工程ごとの積み上げが前提の品質管理
増加するブラックボックス領域
外部依存にともなうリスク要因の増加
終わりのない短納期要求
モジュールごとの独自性・専門性の進展
最終評価工程の強化による品質確保
現状問題を引き起こしている原因
エレキ、メカ、ソフトという技術軸を基本とした体制では、技術変化に追従
できない。大切なのは、ハード、ソフトを含めたモジュール技術の専門性。
ブラックボックス部分の中身を把握するのは非効率。動作させて確認するの
が現実的。
外部調達の部品やモジュールのバージョンアップがあるため、繰り返し完成
度や品質を確認する必要がある。
外部調達の増加による不確定要因が増加することは避けることができず、よ
り早期に動作確認することが重要。
開発には、完成度や品質と納期(リリース)の選択ができることが要求され
ている。必要があれば早期リリースも可能な開発の仕組みが必要。
HWとSWの担当が分かれていることなどが、モジュールや製品としての完成
度や性能を上げる際のやりとりを複雑で非効率なものにしている。
要素技術部門から商品開発部門、商品開発部門から製造部門などの移管が、
内容が高度化しているため時間がかかる上に、十分には実施できない。
海外や中小メーカーからの外部調達品は、完成度の問題や量産バラツキがあ
ることが多く、受入試験では不具合を検出できないこともしばしばである。
外部調達品は完成度や品質、納期などを事前に確認することは難しく、現物
でしか確認できないというリスクがある。
結合評価やシステムテストという最終工程となる評価に多大な工数をかけて
品質確保する傾向が強い。実際に完成度や品質を確認できるのもこの段階。
Copyright© 2015 RDPi Corporation
Restricted Person Only
「超」短期間開発 仕組み構築のご提案
解決のための基本的な考え方
6
今起きている問題を解決するためには、従来からの開発の仕組みの延長ではなく根本から見直す必要がある。体
制、開発プロセス、進 管理の観点から、次ような考え方で見直すことが有効である。
開発後半でしか動かせない製品全体
技術高度化にともなう引継ぎの困難性
分業体制が生む手戻り
増大する外部調達品の品質問題
工程ごとの積み上げが前提の品質管理
増加するブラックボックス領域
外部依存にともなうリスク要因の増加
終わりのない短納期要求
モジュールごとの独自性・専門性の進展
問題を引き起こしている原因
HW, SW の区別なく、モジュールに合わせた一体化したチーム体制
をとることにより、より高度な独自性、専門性を追求することが可
能。また、チームは要素技術から商品化、製造まで一貫して、担当
モジュールについて開発責任を持つことにより、短期間で高度な機
能や性能の製品開発が可能となる。
ブラックボックス部分が増え、外部調達
の部品やモジュールが増えることは、机
上での設計確認や積み上げ式の動作確認
を非効率なものにしている。繰り返し動
作させて、完成度や品質を確認するのが
確実で現実的な方法である。
段階的な試作や評価を経てはじめて製品が完全に動作する方法では、
顧客のサンプル要求や営業段階でのデモ要求に応えることができな
い。また、完成度を上げることよりもリリースを早めることが要求
されるケースもある。このような要求に応えるためには、開発の初
期段階から常に動作するものにしておくことが有効である。
ユーザから見たときに「何が」
「どこまで」動いているのかと
いう物差しで、開発の進 を管
理することが、継続的に動作さ
せることで完成度を確認したり、
ユーザーからの早期のリリース
要求に応えることに有効である。
解決策の基本的な考え方
製品のモジュールに合わせたチーム体制
ユーザ視点完成度の進 管理実働による完成度・品質の見える化
リリースの柔軟性確保
Copyright© 2015 RDPi Corporation
Restricted Person Only
「超」短期間開発 仕組み構築のご提案
解決のための戦略
7
解決のための基本的な考え方から3つの戦略を策定した。実物による完成度管理を行うことで、超短期リリース
を実現し、さらにリリース時期の柔軟性を確保することができる仕組みが可能となる。
開発後半でしか動かせない製品全体
技術高度化にともなう引継ぎの困難性
分業体制が生む手戻り
増大する外部調達品の品質問題
工程ごとの積み上げが前提の品質管理
増加するブラックボックス領域
外部依存にともなうリスク要因の増加
終わりのない短納期要求
モジュールごとの独自性・専門性の進展
問題を引き起こしている原因
早期実働化
ムダの削減
技術高度化
実働による見える化
リリースの柔軟性拡大
基本的な考え方とその期待効果
製品のモジュールに
合わせたチーム体制
進 の見える化
リスク低減
フィードバック容易化
早期リリース
出荷の判断余地拡大
ユーザ視点の完成度
による進 管理
完成度の見える化
要件の明確化
解決のための戦略
モジュール化開発体制
ショートサイクル段階的開発プロセス
ユースケース・ベース進 管理
動作する実物を、2∼3週間の短いサイクルを
繰り返して作ることにより、段階的に完成度や
品質を確認する開発プロセス。繰り返すサイク
ルは従来と同様に逐次的な開発工程からなる。
製品の内部構造に合わせた開発チームを開発体
制の基本単位とし、その単位ごとに最適な開発
プロセスや技術開発、人材育成などの仕組みを
作り、実践する。
外部からどのように使われるか(ユースケース)
の観点で、製品あるいはモジュールの仕様と設
計を整理し、ユースケースを基準に開発の進
や完成度などを管理する。
体制
進 管理
開発プロセス
超短期リリースが可能!
Copyright© 2015 RDPi Corporation
Restricted Person Only
「超」短期間開発 仕組み構築のご提案
ショートサイクル段階的開発プロセス
8
InvestigateDesign Implement Test
Plan Design Implement Test
●	
 ●	
 ●InvestigateDesign Plan Cycle 1 Cycle 2 Cycle 3 Cycle N Test
動作する実物を、2∼3週間の短いサイクルを繰り返して作ることにより、段階的に完成度や品質を確認する開発
プロセス。繰り返すサイクルは従来と同様に逐次的な開発工程からなる。
InvestigateDesign Prototype #1 ManufacturingPrototype #2 Transfer
ステージゲート型/ウォーターフォール型 開発プロセス
ショートサイクル段階的開発プロセス
サイクルごとに動作させて機能確認する
どのサイクルでもリリースが可能
サイクルで仕様変更・設計変更に対応
Copyright© 2015 RDPi Corporation
Restricted Person Only
「超」短期間開発 仕組み構築のご提案
ショートサイクル段階的開発プロセスの技法・手法
9
ショートサイクル段階的開発プロセスを実現するためには、次のような技法・手法を導入するのが効果的である。
○ プロセスの依存関係解析
○ レファレンスデザインの作成
○ 金型
合理的なショートサイクルのためには、大きなフィードバックループを極力少なくする必要がある。そのためには、開発工程間、および、
モジュール間の依存関係を解析し、開発を進める上で必要となる判断(設計判断,マネジメント判断)を適切なタイミングで実施できる
ように開発プロセス全体を整理する。
開発を通じて繰り返し使える基板、機構、ソフトの基本パッケージを作成する。CPUボード周辺の制御関連機能を中心に、プロダクトラ
インを通じて共通となる部分を動作する形で作成する。既存の設計の分析・整理や今後の商品展開計画などもあわせて実施することによ
り、流用性の高いものにする。
現在、もっともリードタイムが長いもののひとつが金型作成である。金型を作ることと並行して、3Dプリンターを活用してショートサイ
クルを回す??
Copyright© 2015 RDPi Corporation
Restricted Person Only
「超」短期間開発 仕組み構築のご提案
モジュール化開発体制
10
製品の内部構造に合わせた開発チームを開発体制の基本単位とし、その単位ごとに最適な開発プロセスや技術開
発、人材育成などの仕組みを作り、実践する。
・・・
開発プロセス
プロジェクト管理
サプライヤー管理
中期技術開発
人材育成
製品
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
・・・
開発プロセス
プロジェクト管理
サプライヤー管理
中期技術開発
人材育成
ディスプレイ
カメラ
電池・電源
Wi-Fi
・・・
よりよい製品を作ることを目標に、す
べての関係者が同じ仕組みのもとで、
短期・中期の開発を進める。
それぞれのモジュールが
最高のものになるように、
モジュールの特性に合わ
せて短期・中期の開発を
進める。
従来の開発体制
モジュール化体制
Copyright© 2015 RDPi Corporation
Restricted Person Only
「超」短期間開発 仕組み構築のご提案
モジュール化開発体制の技法・手法
11
モジュール化開発体制を実現するためには、次のような技法・手法を導入するのが効果的である。
○ キャラクターの定義
○ エンゲージメントのスキル・トレーニング
チームとして開発を進める上で必要なキャラクターを定義する。キャラクターとは、技術的な役割分担ではなく、プロジェクトの始めか
ら終わりまでを通じて果たすべき役割である。PM や PL の仕事を分担すると考えるとわかりやすい。
エンゲージメントとは、チームの個々のメンバーが、チームや組織に対して貢献することが自分自身の価値観とも合致していると思える
ことである。チームリーダーを中心に、エンゲージメントを高めるスキルを身につけることが、チームが高いパフォーマンスを実現する
ことにつながる。
○ ミニマム開発プロセスの作成
モジュールを基本とするチームごとに、その特性や事情に合わせた開発プロセスやプロジェクト管理
などの方法を「設計」し、実践する。その「設計」作業を容易にするために、どのチームにも共通で、
組織として最低限の開発プロセスを作成する。開発の仕組みのミニマムセットである。
Copyright© 2015 RDPi Corporation
Restricted Person Only
「超」短期間開発 仕組み構築のご提案
Level 0
Level 1
Level 2
Level 3
ユースケース・ベース進捗管理
12
外部からどのように使われるか(ユースケース)の観点で、製品あるいはモジュールの仕様と設計を整理し、ユースケースを基準に
開発の進 や完成度を管理する。
使い方視点での機能の種類
機能の組み合わせの複雑さ
width
depth
width x depth
製品あるいはモジュールの使われ方の種類
(ユースケース)の全体。一つひとつは、仕
様、設計、内部構造が関連づけられている(ト
レーサビリティが確保されている)。
一つひとつのユースケースに
ついて、その動作(処理)の
違いを、例外や制約条件など
をもとにした複雑さの度合い
で分類したもの。 開発の全体を width x depth
であらわし、その全体に対す
る割合で設計や評価の進 を
管理する。
<depth の例>
Level 0:単機能(基本ユースケース)
Level 1:単機能のパラメータ組み合わせ(派生ユースケース)
Level 2:機能間の組み合わせ
Level 3:シナリオベース
視覚的に設計や評価の進 を確認できる
受入評価や回帰テストなどのイベントで
の確認範囲を明確にできる
•ハード、ソフトを区別せず製品あるいは
モジュールとしてのユースケースが基準
•電気的特性や機械的特性が仕様を満足し
ていることは大前提
Copyright© 2015 RDPi Corporation
Restricted Person Only
「超」短期間開発 仕組み構築のご提案
ユースケース・ベース進捗管理の技法・手法
13
○ 評価・テスト環境の整備
○ メトリクス管理
ユースケースは、仕様、設計、内部構造のトレーサビリティを確保することが重要である。このとき、内部構造の解析には動作ログ(ト
レースログ)をとることや、受入評価を繰り返し実行する必要があることなど、評価・テストを実施する仕組みがより重要になる。自動
化や標準化などの観点で環境整備を行う。
ユースケースを使うことで、プロダクトの使われ方をもとにその完成度を計測することができる。そのため、開発工程やレビューなどの
プロセス・メトリクスではなく、最終プロダクト指向のプロダクト・メトリクス中心の仕組みにする。さらに、プロダクトに直接関係
する「振る舞い」を計測するビヘイビア・メトリクスの仕組みを整備する。
○ 設計文書の再構築
従来の設計をユースケース設計手法で再設計し、次に使える形で文書化する。開発現場に新しい
設計方法や文書化をその方法を教育することで導入するのは困難であり、開発の際に参照できる
実物を作成することで、その意味や利便性、効果などを実感するとともに、参照することで新し
いやり方を実践できるようになる。
ユースケース・ベース進 管理を実現するためには、次のような技法・手法を導入するのが効果的である。
「超」短期間開発のための3つの開発マネジメント

More Related Content

What's hot

Хөгжмийн сэтгэл судлал
Хөгжмийн сэтгэл судлалХөгжмийн сэтгэл судлал
Хөгжмийн сэтгэл судлалazora14
 
Монгол орны Зэс-порфирын орд /заавал үз/
Монгол орны Зэс-порфирын орд /заавал үз/Монгол орны Зэс-порфирын орд /заавал үз/
Монгол орны Зэс-порфирын орд /заавал үз/Yanzaga Ch
 
Javne finansije za ispit 1. deo
Javne finansije   za ispit 1. deoJavne finansije   za ispit 1. deo
Javne finansije za ispit 1. deosanja1109
 
Lecture 4, 5
Lecture 4, 5Lecture 4, 5
Lecture 4, 5Bbujee
 
уулын үйлдвэрийн технологийн үндэс лк-5
уулын үйлдвэрийн технологийн үндэс лк-5уулын үйлдвэрийн технологийн үндэс лк-5
уулын үйлдвэрийн технологийн үндэс лк-5nominbyambadorj
 
101 16-erdes bayalag
101 16-erdes bayalag101 16-erdes bayalag
101 16-erdes bayalagXaz Bit
 
биет бус хөрөнгийн үнэлгээний өртгийн хандлага
биет бус хөрөнгийн үнэлгээний өртгийн хандлагабиет бус хөрөнгийн үнэлгээний өртгийн хандлага
биет бус хөрөнгийн үнэлгээний өртгийн хандлагаХонгорзул Лили
 

What's hot (9)

Хөгжмийн сэтгэл судлал
Хөгжмийн сэтгэл судлалХөгжмийн сэтгэл судлал
Хөгжмийн сэтгэл судлал
 
Монгол орны Зэс-порфирын орд /заавал үз/
Монгол орны Зэс-порфирын орд /заавал үз/Монгол орны Зэс-порфирын орд /заавал үз/
Монгол орны Зэс-порфирын орд /заавал үз/
 
Javne finansije za ispit 1. deo
Javne finansije   za ispit 1. deoJavne finansije   za ispit 1. deo
Javne finansije za ispit 1. deo
 
Gbss 8
Gbss 8Gbss 8
Gbss 8
 
Lecture 4, 5
Lecture 4, 5Lecture 4, 5
Lecture 4, 5
 
уулын үйлдвэрийн технологийн үндэс лк-5
уулын үйлдвэрийн технологийн үндэс лк-5уулын үйлдвэрийн технологийн үндэс лк-5
уулын үйлдвэрийн технологийн үндэс лк-5
 
азот 2.3
азот 2.3азот 2.3
азот 2.3
 
101 16-erdes bayalag
101 16-erdes bayalag101 16-erdes bayalag
101 16-erdes bayalag
 
биет бус хөрөнгийн үнэлгээний өртгийн хандлага
биет бус хөрөнгийн үнэлгээний өртгийн хандлагабиет бус хөрөнгийн үнэлгээний өртгийн хандлага
биет бус хөрөнгийн үнэлгээний өртгийн хандлага
 

Viewers also liked

リーダーづくり製品開発マネジメント
リーダーづくり製品開発マネジメントリーダーづくり製品開発マネジメント
リーダーづくり製品開発マネジメントRyozo Ishibashi
 
VandV:システムの評価と検証について
VandV:システムの評価と検証についてVandV:システムの評価と検証について
VandV:システムの評価と検証についてI Ueno
 
でぶさみ夏2013 キーノート オレンジレンジャーの資料
でぶさみ夏2013 キーノート オレンジレンジャーの資料でぶさみ夏2013 キーノート オレンジレンジャーの資料
でぶさみ夏2013 キーノート オレンジレンジャーの資料Tomohiro Fujii
 
夏サミ 2013 A2 セッション資料 #natsumiA2
夏サミ 2013 A2 セッション資料 #natsumiA2 夏サミ 2013 A2 セッション資料 #natsumiA2
夏サミ 2013 A2 セッション資料 #natsumiA2 智治 長沢
 
夏サミ 2013 基調講演 長沢パート資料 #natsumiS1
夏サミ 2013 基調講演 長沢パート資料 #natsumiS1夏サミ 2013 基調講演 長沢パート資料 #natsumiS1
夏サミ 2013 基調講演 長沢パート資料 #natsumiS1智治 長沢
 
ユーザー企業における標準化のあり方 : QCon Tokyo 2010
ユーザー企業における標準化のあり方 : QCon Tokyo 2010ユーザー企業における標準化のあり方 : QCon Tokyo 2010
ユーザー企業における標準化のあり方 : QCon Tokyo 2010Yusuke Suzuki
 
BluemixとIBM DevOps Servicesで始めるアプリケーション開発
BluemixとIBM DevOps Servicesで始めるアプリケーション開発BluemixとIBM DevOps Servicesで始めるアプリケーション開発
BluemixとIBM DevOps Servicesで始めるアプリケーション開発IBMソリューション
 
PMBOKで学ぶプロジェクトマネジメントの基礎
PMBOKで学ぶプロジェクトマネジメントの基礎PMBOKで学ぶプロジェクトマネジメントの基礎
PMBOKで学ぶプロジェクトマネジメントの基礎Hiroyuki Tanaka
 
初めての人の為のプロジェクトマネジメント入門
初めての人の為のプロジェクトマネジメント入門初めての人の為のプロジェクトマネジメント入門
初めての人の為のプロジェクトマネジメント入門尚 鈴木
 
夏サミ2013 基調講演 「DevOpsは開発現場とビジネスの間に何を生むか?」(新野淳一氏)
夏サミ2013 基調講演 「DevOpsは開発現場とビジネスの間に何を生むか?」(新野淳一氏)夏サミ2013 基調講演 「DevOpsは開発現場とビジネスの間に何を生むか?」(新野淳一氏)
夏サミ2013 基調講演 「DevOpsは開発現場とビジネスの間に何を生むか?」(新野淳一氏)Developers Summit
 

Viewers also liked (14)

リーダーづくり製品開発マネジメント
リーダーづくり製品開発マネジメントリーダーづくり製品開発マネジメント
リーダーづくり製品開発マネジメント
 
VandV:システムの評価と検証について
VandV:システムの評価と検証についてVandV:システムの評価と検証について
VandV:システムの評価と検証について
 
でぶさみ夏2013 キーノート オレンジレンジャーの資料
でぶさみ夏2013 キーノート オレンジレンジャーの資料でぶさみ夏2013 キーノート オレンジレンジャーの資料
でぶさみ夏2013 キーノート オレンジレンジャーの資料
 
夏サミ 2013 A2 セッション資料 #natsumiA2
夏サミ 2013 A2 セッション資料 #natsumiA2 夏サミ 2013 A2 セッション資料 #natsumiA2
夏サミ 2013 A2 セッション資料 #natsumiA2
 
サステイナブルなSIを実現する開発基盤のあり方/GxPセミナー
サステイナブルなSIを実現する開発基盤のあり方/GxPセミナーサステイナブルなSIを実現する開発基盤のあり方/GxPセミナー
サステイナブルなSIを実現する開発基盤のあり方/GxPセミナー
 
夏サミ 2013 基調講演 長沢パート資料 #natsumiS1
夏サミ 2013 基調講演 長沢パート資料 #natsumiS1夏サミ 2013 基調講演 長沢パート資料 #natsumiS1
夏サミ 2013 基調講演 長沢パート資料 #natsumiS1
 
Devsumi summer 2013_b2_share
Devsumi summer 2013_b2_shareDevsumi summer 2013_b2_share
Devsumi summer 2013_b2_share
 
ユーザー企業における標準化のあり方 : QCon Tokyo 2010
ユーザー企業における標準化のあり方 : QCon Tokyo 2010ユーザー企業における標準化のあり方 : QCon Tokyo 2010
ユーザー企業における標準化のあり方 : QCon Tokyo 2010
 
人工知能概論 11
人工知能概論 11人工知能概論 11
人工知能概論 11
 
プロジェクト管理における課題管理ツール運用の”勘所”
プロジェクト管理における課題管理ツール運用の”勘所”プロジェクト管理における課題管理ツール運用の”勘所”
プロジェクト管理における課題管理ツール運用の”勘所”
 
BluemixとIBM DevOps Servicesで始めるアプリケーション開発
BluemixとIBM DevOps Servicesで始めるアプリケーション開発BluemixとIBM DevOps Servicesで始めるアプリケーション開発
BluemixとIBM DevOps Servicesで始めるアプリケーション開発
 
PMBOKで学ぶプロジェクトマネジメントの基礎
PMBOKで学ぶプロジェクトマネジメントの基礎PMBOKで学ぶプロジェクトマネジメントの基礎
PMBOKで学ぶプロジェクトマネジメントの基礎
 
初めての人の為のプロジェクトマネジメント入門
初めての人の為のプロジェクトマネジメント入門初めての人の為のプロジェクトマネジメント入門
初めての人の為のプロジェクトマネジメント入門
 
夏サミ2013 基調講演 「DevOpsは開発現場とビジネスの間に何を生むか?」(新野淳一氏)
夏サミ2013 基調講演 「DevOpsは開発現場とビジネスの間に何を生むか?」(新野淳一氏)夏サミ2013 基調講演 「DevOpsは開発現場とビジネスの間に何を生むか?」(新野淳一氏)
夏サミ2013 基調講演 「DevOpsは開発現場とビジネスの間に何を生むか?」(新野淳一氏)
 

Similar to 「超」短期間開発のための3つの開発マネジメント

500% productivity improvement with the MDC. 生産性向上500%達成 MDC適用のknowhow
500% productivity improvement with the MDC. 生産性向上500%達成 MDC適用のknowhow500% productivity improvement with the MDC. 生産性向上500%達成 MDC適用のknowhow
500% productivity improvement with the MDC. 生産性向上500%達成 MDC適用のknowhowProductivity Partner, Inc.
 
日本の企業文化特性を生かした中堅企業グローバル化の促進について  
日本の企業文化特性を生かした中堅企業グローバル化の促進について  日本の企業文化特性を生かした中堅企業グローバル化の促進について  
日本の企業文化特性を生かした中堅企業グローバル化の促進について  Hiroshi Takahashi
 
Parts pick
Parts pickParts pick
Parts pickQuadcept
 
6. 特許評価と価値向上指針の提示
6. 特許評価と価値向上指針の提示6. 特許評価と価値向上指針の提示
6. 特許評価と価値向上指針の提示IDEATION JAPAN
 
クラウド時代にこそ求められるIt部門の役割
クラウド時代にこそ求められるIt部門の役割クラウド時代にこそ求められるIt部門の役割
クラウド時代にこそ求められるIt部門の役割Yusuke Oi
 
「納品のない受託開発」にみるソフトウェア受託開発の未来
「納品のない受託開発」にみるソフトウェア受託開発の未来「納品のない受託開発」にみるソフトウェア受託開発の未来
「納品のない受託開発」にみるソフトウェア受託開発の未来Yoshihito Kuranuki
 
コネクテッド・インダストリアル・ワークフォースとは
コネクテッド・インダストリアル・ワークフォースとはコネクテッド・インダストリアル・ワークフォースとは
コネクテッド・インダストリアル・ワークフォースとはAccenture Japan
 
Agile Quality アジャイル品質パターン (QA2AQ)
Agile Quality アジャイル品質パターン (QA2AQ)Agile Quality アジャイル品質パターン (QA2AQ)
Agile Quality アジャイル品質パターン (QA2AQ)Hironori Washizaki
 
ドメイン駆動設計と要求開発
ドメイン駆動設計と要求開発ドメイン駆動設計と要求開発
ドメイン駆動設計と要求開発Kent Ishizawa
 
超高速開発の基礎概念 20141119 0
超高速開発の基礎概念 20141119 0超高速開発の基礎概念 20141119 0
超高速開発の基礎概念 20141119 0正善 大島
 
市場動向並びに弊社製品の今後の展望について
市場動向並びに弊社製品の今後の展望について市場動向並びに弊社製品の今後の展望について
市場動向並びに弊社製品の今後の展望についてKen Azuma
 
アジャイル開発&DevOps-201904
アジャイル開発&DevOps-201904アジャイル開発&DevOps-201904
アジャイル開発&DevOps-201904Masaru Takahashi
 
市場動向並びに弊社製品の今後の展望について
市場動向並びに弊社製品の今後の展望について市場動向並びに弊社製品の今後の展望について
市場動向並びに弊社製品の今後の展望についてKen Azuma
 
Social Change 〜 ソフトウェア開発者が経営者になるまでと、これからの戦略
Social Change 〜 ソフトウェア開発者が経営者になるまでと、これからの戦略Social Change 〜 ソフトウェア開発者が経営者になるまでと、これからの戦略
Social Change 〜 ソフトウェア開発者が経営者になるまでと、これからの戦略Yoshihito Kuranuki
 
ものつくりでのAI活用 2020
ものつくりでのAI活用 2020ものつくりでのAI活用 2020
ものつくりでのAI活用 2020Ikuo Misao
 
失敗しないパッケージ導入1
失敗しないパッケージ導入1失敗しないパッケージ導入1
失敗しないパッケージ導入1小島 規彰
 
W&B webinar finetuning_配布用.pdf
W&B webinar finetuning_配布用.pdfW&B webinar finetuning_配布用.pdf
W&B webinar finetuning_配布用.pdfYuya Yamamoto
 
外部委託から内製化アジャイルへの切替支援を通してわかったこと #augj
外部委託から内製化アジャイルへの切替支援を通してわかったこと #augj外部委託から内製化アジャイルへの切替支援を通してわかったこと #augj
外部委託から内製化アジャイルへの切替支援を通してわかったこと #augj満徳 関
 

Similar to 「超」短期間開発のための3つの開発マネジメント (20)

500% productivity improvement with the MDC. 生産性向上500%達成 MDC適用のknowhow
500% productivity improvement with the MDC. 生産性向上500%達成 MDC適用のknowhow500% productivity improvement with the MDC. 生産性向上500%達成 MDC適用のknowhow
500% productivity improvement with the MDC. 生産性向上500%達成 MDC適用のknowhow
 
日本の企業文化特性を生かした中堅企業グローバル化の促進について  
日本の企業文化特性を生かした中堅企業グローバル化の促進について  日本の企業文化特性を生かした中堅企業グローバル化の促進について  
日本の企業文化特性を生かした中堅企業グローバル化の促進について  
 
Parts pick
Parts pickParts pick
Parts pick
 
6. 特許評価と価値向上指針の提示
6. 特許評価と価値向上指針の提示6. 特許評価と価値向上指針の提示
6. 特許評価と価値向上指針の提示
 
クラウド時代にこそ求められるIt部門の役割
クラウド時代にこそ求められるIt部門の役割クラウド時代にこそ求められるIt部門の役割
クラウド時代にこそ求められるIt部門の役割
 
「納品のない受託開発」にみるソフトウェア受託開発の未来
「納品のない受託開発」にみるソフトウェア受託開発の未来「納品のない受託開発」にみるソフトウェア受託開発の未来
「納品のない受託開発」にみるソフトウェア受託開発の未来
 
コネクテッド・インダストリアル・ワークフォースとは
コネクテッド・インダストリアル・ワークフォースとはコネクテッド・インダストリアル・ワークフォースとは
コネクテッド・インダストリアル・ワークフォースとは
 
Agile Quality アジャイル品質パターン (QA2AQ)
Agile Quality アジャイル品質パターン (QA2AQ)Agile Quality アジャイル品質パターン (QA2AQ)
Agile Quality アジャイル品質パターン (QA2AQ)
 
ドメイン駆動設計と要求開発
ドメイン駆動設計と要求開発ドメイン駆動設計と要求開発
ドメイン駆動設計と要求開発
 
超高速開発の基礎概念 20141119 0
超高速開発の基礎概念 20141119 0超高速開発の基礎概念 20141119 0
超高速開発の基礎概念 20141119 0
 
市場動向並びに弊社製品の今後の展望について
市場動向並びに弊社製品の今後の展望について市場動向並びに弊社製品の今後の展望について
市場動向並びに弊社製品の今後の展望について
 
アジャイル開発&DevOps-201904
アジャイル開発&DevOps-201904アジャイル開発&DevOps-201904
アジャイル開発&DevOps-201904
 
市場動向並びに弊社製品の今後の展望について
市場動向並びに弊社製品の今後の展望について市場動向並びに弊社製品の今後の展望について
市場動向並びに弊社製品の今後の展望について
 
Social Change 〜 ソフトウェア開発者が経営者になるまでと、これからの戦略
Social Change 〜 ソフトウェア開発者が経営者になるまでと、これからの戦略Social Change 〜 ソフトウェア開発者が経営者になるまでと、これからの戦略
Social Change 〜 ソフトウェア開発者が経営者になるまでと、これからの戦略
 
ものつくりでのAI活用 2020
ものつくりでのAI活用 2020ものつくりでのAI活用 2020
ものつくりでのAI活用 2020
 
失敗しないパッケージ導入1
失敗しないパッケージ導入1失敗しないパッケージ導入1
失敗しないパッケージ導入1
 
W&B webinar finetuning_配布用.pdf
W&B webinar finetuning_配布用.pdfW&B webinar finetuning_配布用.pdf
W&B webinar finetuning_配布用.pdf
 
ベンダーロックインフリーのビジネスクラウドの世界
ベンダーロックインフリーのビジネスクラウドの世界ベンダーロックインフリーのビジネスクラウドの世界
ベンダーロックインフリーのビジネスクラウドの世界
 
大企業の経営改革とベンチャーの活性化で日本を再び元気に
大企業の経営改革とベンチャーの活性化で日本を再び元気に大企業の経営改革とベンチャーの活性化で日本を再び元気に
大企業の経営改革とベンチャーの活性化で日本を再び元気に
 
外部委託から内製化アジャイルへの切替支援を通してわかったこと #augj
外部委託から内製化アジャイルへの切替支援を通してわかったこと #augj外部委託から内製化アジャイルへの切替支援を通してわかったこと #augj
外部委託から内製化アジャイルへの切替支援を通してわかったこと #augj
 

「超」短期間開発のための3つの開発マネジメント

  • 2. Copyright© 2015 RDPi Corporation Restricted Person Only 「超」短期間開発 仕組み構築のご提案 製品開発を取り巻く環境 2 製品開発を取り巻く環境は厳しさを増しており、製品の高機能化、複雑化、大規模化に加え、開発期間短縮、原 価低減の要求はとどまることはない。そのために、開発現場は大きく変容している。 要素技術の高度化・進化の進展 部品やモジュールの高機能化 主要部品の外部調達増加 部品やモジュールサプライヤーとの協業増加 製品の 高機能化・ 大規模化・ 複雑化 オフショア開発の増加 海外生産の強化 試作や金型作成などのアウトソーシング増加 海外の新規サプライヤーからの調達増加 終わりのない 開発期間短縮・ 原価低減要求 高機能化・大規模化により外部依存度が高くなる 流れの中で、顧客の短納期の要求に応えることが できる開発の仕組みが求められている 「超」短期間開発 開発を取り巻く環境が 大きく変化しているた めに、解決が困難な構 造的な問題が発生して いる。 (次ページを参照のこと) 製品開発を取り巻く環境の変化 =
  • 3. Copyright© 2015 RDPi Corporation Restricted Person Only 「超」短期間開発 仕組み構築のご提案 ハードウェア 開発プロセス DR 先行開発 先行検討 商品企画 DR DR DR 初期 流動 量産 出荷 デバイスドライバー開発 部品/デバイスの開発 (サプライヤーでの並行開発) DR 部品 納入 基本 設計 試作 #1 試作 #2 試作 #3 製造 移管 仕様 定義 システム 設計 設計 DR 製作・ 単体テスト DR DR 結合テスト 総合評価 システムテスト DR ソフトウェア 開発プロセス 従来の開発の仕組みでは対応できない問題が噴出 3 厳しい競争を生き抜くための製品の高機能化、複雑化、大規模化が、外部調達の増加、開発方法の多様化、技術 移転の困難性などの問題を引き起こし、開発現場では様々な問題が噴出している。 HW担当とSW担 当との間で何度も 手戻りが発生 HWとSWは別々に 開発が進む 製品全体の動作 確認ができるの は量産直前 製造への技術移転が時 間的にも技術的にも困 難になりつつある 購入品やOSSはブ ラックボックスで設 計書を作成できない DRで工程品質を確認し ても、その後の外部調 達品のアップデートで デグレが発生する DRでの判断 基準が曖昧 結合テストがはじま るまで完成度や品質 を確認できない 部品やモジュール により開発方法や 進 がバラバラ 購入部品/モジュー ルの量産バラツキが 多発する 量産トラブルに 工場側の技術者 が対応できない 外部調達品の品質 が安定しない/制 御できない 先行開発からの 技術移転に手間 取る
  • 4. Copyright© 2015 RDPi Corporation Restricted Person Only 「超」短期間開発 仕組み構築のご提案 ハードウェア 開発プロセス DR 先行開発 先行検討 商品企画 DR DR DR 初期 流動 量産 出荷 デバイスドライバー開発 部品/デバイスの開発 (サプライヤーでの並行開発) DR 部品 納入 基本 設計 試作 #1 試作 #2 試作 #3 製造 移管 仕様 定義 システム 設計 設計 DR 製作・ 単体テスト DR DR 結合テスト 総合評価 システムテスト DR ソフトウェア 開発プロセス 従来の開発の仕組みに内在する問題の原因(1) 4 問題を引き起こしている原因は、ISO や CMMI ベースの標準開発プロセス、ステージゲート方式、専門分業化、 工程管理、DR強化、設計文書化など、従来からの伝統的な開発の仕組みにある。 開発後半でし か動かせない 製品全体 技術高度化に ともなう引継 ぎの困難性 分業体制が 生む手戻り 増大する外 部調達品の 品質問題 工程ごとの積 み上げが前提 の品質管理 増加するブ ラックボッ クス領域 外部依存にと もなうリスク 要因の増加 終わりのない 短納期要求 モジュールご との独自性・ 専門性の進展 最終評価工程 の強化による 品質確保 技術高度化に ともなう引継 ぎの困難性 従来の開発プロセス、体制、マネジメントの 改善では対応できない変化が起こっている。 根本的な解決策が必要とされている。
  • 5. Copyright© 2015 RDPi Corporation Restricted Person Only 「超」短期間開発 仕組み構築のご提案 従来の開発の仕組みに内在する問題の原因(2) 5 従来の開発プロセス、開発体制、マネジメントの延長での改善では対応できない変化が起きていることが、問題 の原因である。これまでの延長ではなく、根本的な解決策が必要である。 開発後半でしか動かせない製品全体 技術高度化にともなう引継ぎの困難性 分業体制が生む手戻り 増大する外部調達品の品質問題 工程ごとの積み上げが前提の品質管理 増加するブラックボックス領域 外部依存にともなうリスク要因の増加 終わりのない短納期要求 モジュールごとの独自性・専門性の進展 最終評価工程の強化による品質確保 現状問題を引き起こしている原因 エレキ、メカ、ソフトという技術軸を基本とした体制では、技術変化に追従 できない。大切なのは、ハード、ソフトを含めたモジュール技術の専門性。 ブラックボックス部分の中身を把握するのは非効率。動作させて確認するの が現実的。 外部調達の部品やモジュールのバージョンアップがあるため、繰り返し完成 度や品質を確認する必要がある。 外部調達の増加による不確定要因が増加することは避けることができず、よ り早期に動作確認することが重要。 開発には、完成度や品質と納期(リリース)の選択ができることが要求され ている。必要があれば早期リリースも可能な開発の仕組みが必要。 HWとSWの担当が分かれていることなどが、モジュールや製品としての完成 度や性能を上げる際のやりとりを複雑で非効率なものにしている。 要素技術部門から商品開発部門、商品開発部門から製造部門などの移管が、 内容が高度化しているため時間がかかる上に、十分には実施できない。 海外や中小メーカーからの外部調達品は、完成度の問題や量産バラツキがあ ることが多く、受入試験では不具合を検出できないこともしばしばである。 外部調達品は完成度や品質、納期などを事前に確認することは難しく、現物 でしか確認できないというリスクがある。 結合評価やシステムテストという最終工程となる評価に多大な工数をかけて 品質確保する傾向が強い。実際に完成度や品質を確認できるのもこの段階。
  • 6. Copyright© 2015 RDPi Corporation Restricted Person Only 「超」短期間開発 仕組み構築のご提案 解決のための基本的な考え方 6 今起きている問題を解決するためには、従来からの開発の仕組みの延長ではなく根本から見直す必要がある。体 制、開発プロセス、進 管理の観点から、次ような考え方で見直すことが有効である。 開発後半でしか動かせない製品全体 技術高度化にともなう引継ぎの困難性 分業体制が生む手戻り 増大する外部調達品の品質問題 工程ごとの積み上げが前提の品質管理 増加するブラックボックス領域 外部依存にともなうリスク要因の増加 終わりのない短納期要求 モジュールごとの独自性・専門性の進展 問題を引き起こしている原因 HW, SW の区別なく、モジュールに合わせた一体化したチーム体制 をとることにより、より高度な独自性、専門性を追求することが可 能。また、チームは要素技術から商品化、製造まで一貫して、担当 モジュールについて開発責任を持つことにより、短期間で高度な機 能や性能の製品開発が可能となる。 ブラックボックス部分が増え、外部調達 の部品やモジュールが増えることは、机 上での設計確認や積み上げ式の動作確認 を非効率なものにしている。繰り返し動 作させて、完成度や品質を確認するのが 確実で現実的な方法である。 段階的な試作や評価を経てはじめて製品が完全に動作する方法では、 顧客のサンプル要求や営業段階でのデモ要求に応えることができな い。また、完成度を上げることよりもリリースを早めることが要求 されるケースもある。このような要求に応えるためには、開発の初 期段階から常に動作するものにしておくことが有効である。 ユーザから見たときに「何が」 「どこまで」動いているのかと いう物差しで、開発の進 を管 理することが、継続的に動作さ せることで完成度を確認したり、 ユーザーからの早期のリリース 要求に応えることに有効である。 解決策の基本的な考え方 製品のモジュールに合わせたチーム体制 ユーザ視点完成度の進 管理実働による完成度・品質の見える化 リリースの柔軟性確保
  • 7. Copyright© 2015 RDPi Corporation Restricted Person Only 「超」短期間開発 仕組み構築のご提案 解決のための戦略 7 解決のための基本的な考え方から3つの戦略を策定した。実物による完成度管理を行うことで、超短期リリース を実現し、さらにリリース時期の柔軟性を確保することができる仕組みが可能となる。 開発後半でしか動かせない製品全体 技術高度化にともなう引継ぎの困難性 分業体制が生む手戻り 増大する外部調達品の品質問題 工程ごとの積み上げが前提の品質管理 増加するブラックボックス領域 外部依存にともなうリスク要因の増加 終わりのない短納期要求 モジュールごとの独自性・専門性の進展 問題を引き起こしている原因 早期実働化 ムダの削減 技術高度化 実働による見える化 リリースの柔軟性拡大 基本的な考え方とその期待効果 製品のモジュールに 合わせたチーム体制 進 の見える化 リスク低減 フィードバック容易化 早期リリース 出荷の判断余地拡大 ユーザ視点の完成度 による進 管理 完成度の見える化 要件の明確化 解決のための戦略 モジュール化開発体制 ショートサイクル段階的開発プロセス ユースケース・ベース進 管理 動作する実物を、2∼3週間の短いサイクルを 繰り返して作ることにより、段階的に完成度や 品質を確認する開発プロセス。繰り返すサイク ルは従来と同様に逐次的な開発工程からなる。 製品の内部構造に合わせた開発チームを開発体 制の基本単位とし、その単位ごとに最適な開発 プロセスや技術開発、人材育成などの仕組みを 作り、実践する。 外部からどのように使われるか(ユースケース) の観点で、製品あるいはモジュールの仕様と設 計を整理し、ユースケースを基準に開発の進 や完成度などを管理する。 体制 進 管理 開発プロセス 超短期リリースが可能!
  • 8. Copyright© 2015 RDPi Corporation Restricted Person Only 「超」短期間開発 仕組み構築のご提案 ショートサイクル段階的開発プロセス 8 InvestigateDesign Implement Test Plan Design Implement Test ● ● ●InvestigateDesign Plan Cycle 1 Cycle 2 Cycle 3 Cycle N Test 動作する実物を、2∼3週間の短いサイクルを繰り返して作ることにより、段階的に完成度や品質を確認する開発 プロセス。繰り返すサイクルは従来と同様に逐次的な開発工程からなる。 InvestigateDesign Prototype #1 ManufacturingPrototype #2 Transfer ステージゲート型/ウォーターフォール型 開発プロセス ショートサイクル段階的開発プロセス サイクルごとに動作させて機能確認する どのサイクルでもリリースが可能 サイクルで仕様変更・設計変更に対応
  • 9. Copyright© 2015 RDPi Corporation Restricted Person Only 「超」短期間開発 仕組み構築のご提案 ショートサイクル段階的開発プロセスの技法・手法 9 ショートサイクル段階的開発プロセスを実現するためには、次のような技法・手法を導入するのが効果的である。 ○ プロセスの依存関係解析 ○ レファレンスデザインの作成 ○ 金型 合理的なショートサイクルのためには、大きなフィードバックループを極力少なくする必要がある。そのためには、開発工程間、および、 モジュール間の依存関係を解析し、開発を進める上で必要となる判断(設計判断,マネジメント判断)を適切なタイミングで実施できる ように開発プロセス全体を整理する。 開発を通じて繰り返し使える基板、機構、ソフトの基本パッケージを作成する。CPUボード周辺の制御関連機能を中心に、プロダクトラ インを通じて共通となる部分を動作する形で作成する。既存の設計の分析・整理や今後の商品展開計画などもあわせて実施することによ り、流用性の高いものにする。 現在、もっともリードタイムが長いもののひとつが金型作成である。金型を作ることと並行して、3Dプリンターを活用してショートサイ クルを回す??
  • 10. Copyright© 2015 RDPi Corporation Restricted Person Only 「超」短期間開発 仕組み構築のご提案 モジュール化開発体制 10 製品の内部構造に合わせた開発チームを開発体制の基本単位とし、その単位ごとに最適な開発プロセスや技術開 発、人材育成などの仕組みを作り、実践する。 ・・・ 開発プロセス プロジェクト管理 サプライヤー管理 中期技術開発 人材育成 製品 ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ ・・・ 開発プロセス プロジェクト管理 サプライヤー管理 中期技術開発 人材育成 ディスプレイ カメラ 電池・電源 Wi-Fi ・・・ よりよい製品を作ることを目標に、す べての関係者が同じ仕組みのもとで、 短期・中期の開発を進める。 それぞれのモジュールが 最高のものになるように、 モジュールの特性に合わ せて短期・中期の開発を 進める。 従来の開発体制 モジュール化体制
  • 11. Copyright© 2015 RDPi Corporation Restricted Person Only 「超」短期間開発 仕組み構築のご提案 モジュール化開発体制の技法・手法 11 モジュール化開発体制を実現するためには、次のような技法・手法を導入するのが効果的である。 ○ キャラクターの定義 ○ エンゲージメントのスキル・トレーニング チームとして開発を進める上で必要なキャラクターを定義する。キャラクターとは、技術的な役割分担ではなく、プロジェクトの始めか ら終わりまでを通じて果たすべき役割である。PM や PL の仕事を分担すると考えるとわかりやすい。 エンゲージメントとは、チームの個々のメンバーが、チームや組織に対して貢献することが自分自身の価値観とも合致していると思える ことである。チームリーダーを中心に、エンゲージメントを高めるスキルを身につけることが、チームが高いパフォーマンスを実現する ことにつながる。 ○ ミニマム開発プロセスの作成 モジュールを基本とするチームごとに、その特性や事情に合わせた開発プロセスやプロジェクト管理 などの方法を「設計」し、実践する。その「設計」作業を容易にするために、どのチームにも共通で、 組織として最低限の開発プロセスを作成する。開発の仕組みのミニマムセットである。
  • 12. Copyright© 2015 RDPi Corporation Restricted Person Only 「超」短期間開発 仕組み構築のご提案 Level 0 Level 1 Level 2 Level 3 ユースケース・ベース進捗管理 12 外部からどのように使われるか(ユースケース)の観点で、製品あるいはモジュールの仕様と設計を整理し、ユースケースを基準に 開発の進 や完成度を管理する。 使い方視点での機能の種類 機能の組み合わせの複雑さ width depth width x depth 製品あるいはモジュールの使われ方の種類 (ユースケース)の全体。一つひとつは、仕 様、設計、内部構造が関連づけられている(ト レーサビリティが確保されている)。 一つひとつのユースケースに ついて、その動作(処理)の 違いを、例外や制約条件など をもとにした複雑さの度合い で分類したもの。 開発の全体を width x depth であらわし、その全体に対す る割合で設計や評価の進 を 管理する。 <depth の例> Level 0:単機能(基本ユースケース) Level 1:単機能のパラメータ組み合わせ(派生ユースケース) Level 2:機能間の組み合わせ Level 3:シナリオベース 視覚的に設計や評価の進 を確認できる 受入評価や回帰テストなどのイベントで の確認範囲を明確にできる •ハード、ソフトを区別せず製品あるいは モジュールとしてのユースケースが基準 •電気的特性や機械的特性が仕様を満足し ていることは大前提
  • 13. Copyright© 2015 RDPi Corporation Restricted Person Only 「超」短期間開発 仕組み構築のご提案 ユースケース・ベース進捗管理の技法・手法 13 ○ 評価・テスト環境の整備 ○ メトリクス管理 ユースケースは、仕様、設計、内部構造のトレーサビリティを確保することが重要である。このとき、内部構造の解析には動作ログ(ト レースログ)をとることや、受入評価を繰り返し実行する必要があることなど、評価・テストを実施する仕組みがより重要になる。自動 化や標準化などの観点で環境整備を行う。 ユースケースを使うことで、プロダクトの使われ方をもとにその完成度を計測することができる。そのため、開発工程やレビューなどの プロセス・メトリクスではなく、最終プロダクト指向のプロダクト・メトリクス中心の仕組みにする。さらに、プロダクトに直接関係 する「振る舞い」を計測するビヘイビア・メトリクスの仕組みを整備する。 ○ 設計文書の再構築 従来の設計をユースケース設計手法で再設計し、次に使える形で文書化する。開発現場に新しい 設計方法や文書化をその方法を教育することで導入するのは困難であり、開発の際に参照できる 実物を作成することで、その意味や利便性、効果などを実感するとともに、参照することで新し いやり方を実践できるようになる。 ユースケース・ベース進 管理を実現するためには、次のような技法・手法を導入するのが効果的である。