トヨタ開発方式の包括的利用によるソフト開発...

トヨタ開発方式の包括的利用によるソフト開発のＱＣＤ向上活動

1

品質保証本部商品品質保証部

比嘉定彦

All Rights Reserved - ADVANTEST CORPORATION

ソフトウェア品質シンポジウム2015

アドバンテストの紹介弊社は主に半導体試験装置の製造/販売を行っております

2 All Rights Reserved - ADVANTEST CORPORATION

→ 活動領域は半導体試験装置のソフトウェア開発


自己紹介

勤務地：株式会社アドバンテスト群馬Ｒ＆Ｄセンタ所属：品質保証本部商品品質保証部業務：ソフトウェアプロセス改善の推進 <履歴> ・1990年代からメトリクスを利用した欠陥の早期検出活動を展開・2002年から、CMMの社内普及活動を実施。その後、 EVM や CCPM を利用した開発管理プロセスの向上活動を展開。・2011年からトヨタ開発方式[1]を利用した開発管理プロセスの向上活動を展開。

3 3 All Rights Reserved - ADVANTEST CORPORATION


目次

1 . はじめに

2 . トヨタ開発方式の概要

3 ．問題の分析

4 ．活動の内容

5 ．活動の結果

6 ．考察

7 ．今後の課題



1．はじめに



1．はじめにトヨタ開発方式*1[1]は、開発工程の中で発生する「待ち」や「遅れ」の状態をムダであると考え（「欠陥」と同様に）改善する方法論。 *1） ”トヨタ製品開発システム”James M.Morgan、Jeffrey K.Liker著

当社では、トヨタ開発方式を必要な部分から順次カスタマイズし、段階的に導入（SQiP2013、2014で報告）。


・ステップ１(SQiP2013[2]) ‐マイルストーンの活用による同期化と平準化

・ステップ2(SQiP2014[3])

‐LAMDAサイクル*2の導入による問題解決（課題ばらし*3の質の改善） *2) LAMDAサイクルは次の略語で、２周分が PDCAサイクル１周分に相当する[4] -> Look -> Ask -> Model -> Discus -> Act 観察する問いかけるモデル化する話し合う行動する

*3) 設計/評価上の心配や不明な点を事前に一つ一つ具体的に示すこと[5]

-> トヨタ開発方式を導入する前から実施。



課題ばらしについて（補足説明）[5]

作業ばらし［心配や不明な点が無い場合］

課題ばらし［心配や不明な点が有る場合］

問題の事前抽出と解決

ＷＢＳ

1．はじめに（続き）

プロセス［前提］成果

作業を明確化

課題を具体化

重要な点：・課題ばらしが必要な場合に作業ばらしで済ませてしまうと、実装以降で後から分かった課題となって顕れる。・課題ばらしを実施するにはスキルが必要で、課題ばらしスキルの差は作業工数見積りのばらつきを生む要因となる。


1．はじめに（続き２）


・今回ご紹介する活動

今まで使っていなかったトヨタ開発方式を導入し、

課題ばらしの質の向上<SQiP2014>をさらに進める。

⇒トヨタＡ３ストーリ*4の利用で、改善（課題ばらしの質の改善）の継続性を確保する

⇒課題ばらしの再利用で、新規性が高い開発の際に、後から分かる課題を低減する

*4）問題解決に関する内容を1枚の標準形式にまとめて伝達するツール

例題：開発リーダが計画の線引きし直しと報告に、日々追われる。 └→この悪循環から脱却する方法が必要。

・活動後の実感 ⇒ トヨタ開発方式は問題の解決方法を提示している。


2．トヨタ開発方式の概要

開発には、企画内容を遂行して製品化する流れ(水平軸)と、その流れに直交し、組織的活動によって技術力を高める流れ(直交軸)が存在する。

トヨタ開発方式では、開発の２つの流れに沿って、独自の5つの土台が存在する[4]。


チーフエンジニアリング

市場価値を創り込み、製品開発の実現目標を設定し主導する働きを示す。

開発の流れの確立

マイルストーンに基づく同期/平準化により開発の流れを作り出すことを示す。

専門家チーム継続改善を探究する意思を持った技術者集団を指し、Ａ３ストーリを利用しチームで改善を進める事を指す。

知識の再利用ソフト開発においては、アーキテクチャ設計から詳細設計に至り技術課題の抽出/解決に関する知識（形式化された課題分析方法）を再利用(し改良)することを示す。

セットベース開発

多角的な視点から技術課題を検討し設計の最適解を導出することを示し、ソフト開発においては、機能/階層間で生じる相互作用を分析し解決が必要な課題を抽出することを示す。

製品化する流れ

チーフエンジ

ニアリング


知識の再利用

専門家チーム


2．トヨタ開発方式の概要 (続き2)

All Rights Reserved - Advantest Corporation 10

トヨタ開発方式の共通要素（LAMDAサイクル[4]）

LAMDAサイクルは、リーン製品開発の基礎となる仕事の進め方で、

ＰＤＣＡサイクルを開発設計向けに発展させたもの。

LAMDAサイクル２周分が PDCAサイクル１回分に相当する。

PDCA

A

LAMDA

D

A A

PとCに十分な時間を割くことで、問題解

決力を高める


3．問題の分析



3. 問題の分析


LAMDAサイクルの導入支援やマイルストーンの活用支援(網羅性の確保)だけでは解決が難しい新たな問題（次の2点）が判明した。

・改善課題が継続されない！＜→問題①＞

開発リーダの交代や改善活動の予定版（製品）が変更された場合、行っていた改善課題が引き継がれず改善が途切れることがある。

・新規性が高いと遅延する！＜→問題②＞

新規性が高いテーマになると、課題ばらしの時間を十分に確保しても後から分かる課題が多くなり終盤で大幅に遅れることがある。


3. 問題の分析と対策案（その１）

13

3.1 改善の継続性を妨げる(問題①）要因の分析


開発リーダの交代や改善活動予定版（製品）が変更されたケースの分析。

Ａ３ストーリは再利用性と継続性の向上が見込めると考え、問題解決の手段として使ってみることにした。（→改善案①）

・LAMDAの記録では改善活動を引き継ぐのに必要な情報が無かった。・LAMDAの記録には改善前/後の差分が明示されないため、改善を再スタートする位置が判らなかった。

問題の解決手段の候補としていたＡ３ストーリを調査してみると…

・活動ステップは LAMDAサイクルを継承している。・実施した改善活動の要点が一目で把握できる。・改善の Before/After が明確化され、次の改善開始点が明確。


3. 問題の分析と対策案（その２）

14

3.2 新規性が高い開発が遅れる(問題②）要因の分析


課題ばらしを実施しても後から分かる課題が多発したケースの分析。

マイルストーンの網羅性を確保する等の水平軸に属する活動は手を尽くしており、新規性の高い開発に対し水平軸の活動には限界があった。そこで、直交軸に属する活動を強化し、改善する方法（案）を検討。

・チームの力でスキルの差による影響を低減する（→改善案②-1）・課題ばらしを再利用して課題の抽出力を向上する（→改善案②-2）

・課題ばらしの時間は十分確保していた。・製品のジャンルや開発テーマの種類に関係なく遅れた。

・新規性が高いと担当者のスキルの差による影響が顕著に出る。・新規性に加えて複雑度が高くなるとベテランでも課題の抽出が難しくなる。


４．活動の内容



○○○改善実行シート

テーマ名：○○○○○○○○○○○○

３．現状

５．対策

６．効果

７．フォローアップ

４．現状に対する分析

Look_2

マイルストーン毎の実績

Ask_2

マイルストーン毎の

問題の傾向

Model_2

Discus_2

Act_2

後続のマイルストーンや

次のRev.へF/Bする事

パフォーマンス実績（目

標との差異）

次の改善に向けての

課題設定

４.1 改善の継続性を確保する活動


・Ａ３ストーリの利用＜改善策①＞

○○○改善検討シート

テーマ名：○○○○○○○○○○○○

１．導入部（背景）

２．提案（目的、定量化指標）

３．実施方針

必要条件

必要な理由

期待効果

４．未解決問題

予想される問題

解決策

５．行動計画

展開方法

時期

Look_1

Ask_1

Act_1

Discus_1

Model_1

改善の背景を普遍的

内容で明文化

提案を実行するのに必要な基

準やガイド、活動範囲、対象製

品などを明確化

提案内容に対する阻

害要因とその対策

期待効果は背景に対する

解になっていること

改善指標と定量指標を

セットで提案

Ａ３ストーリをカスタマイズし、Ａ３シート化する際に工夫した点。 ①改善の背景を普遍的内容で明文化 ②改善の導入から効果確認までの全ての過程を記録 ③定量的指標（課題ばらしの質*5の計測）を運用

*5）課題ばらしの質＝事前にばらせた課題 / (事前にばらせた課題＋後から分かった課題) 備考）一定以上の質が確保された状態がセットベース化された（課題抽出が充分に行われた）状態

改善検討シート LAMDAサイクル１周目のSTEP、改善の背景、定量的指標の定義、等

改善実行シート LAMDAサイクル２周目のSTEP、目標と実績、次期改善課題の設定

「専門家チーム」へ「セットベース開発」を組み合わせた活動



・見積精度ばらつきの低減＜改善策②-1＞

「専門家チーム」の活動

・課題抽出力の強化＜改善策②-2＞

「知識の再利用」の活動

４.2 新規性が高い開発で遅延を防止する活動

当社において知識の再利用とは、課題ばらしの再利用工夫点：

形式化におけるパターンの利用再利用のための汎化と多態化

課題ばらしスキルの差による影響をチームで低減する


４.2 新規性が高い開発で遅延を防止する活動（続き）


工夫点：パターンの概念を利用し、課題ばらしの内容を理解しやすい形で残せるようにする。

ソフトウェアアーキテクチャのためのパターン[7]

前提

設計上の課題が発生する状況

課題

その前提で繰り返し現れる設計上の課題 -容易に追加/変更できる -他機能に影響を及ぼさない

解決策

設計課題を解決するための処置

応用

課題ばらしを形式化するためのパターン

前提

課題ばらしが必要となる状況

課題

その前提で繰り返し現れる抽出すべき課題 -開発の阻害要因を解消/回避できる -相互作用の範囲/内容を特定できる

解決策

抽出した課題の解を導くアプローチ


４.2 新規性が高い開発で遅延を防止する活動（続き2）


工夫点：汎化と多態化をセットにして形式化し、再利用を行い易くする。

親クラス［一般的な前提/課題/解決策］

汎化

多態化

子クラス［具体的な前提/課題/解決策］

具体化例（子クラス)に対して汎化を問い

かけ

一般化例（親クラス)に対して多態化を問

いかけ

汎化のポイント：再利用時の多態化が可能となる抽象度で記述する。多態化のポイント：再利用時の課題ばらしに合うようにカスタマイズする。




4.3 改善活動と開発の流れ（水平軸と直交軸）の関係

＜SQiP2015＞・課題抽出力の強化・見積精度ばらつきの低減・ A3ストーリの利用

＜SQiP2014＞ LAMDAサイクルの導入による問題解決（課題ばらしの質の改善）

＜SQiP2013＞マイルストーンの活用による同期化と平準化


５．活動の結果



5.1 改善の継続性を確保する活動の結果


製品Aで行ったＡ３ストーリによる改善の結果＜改善策① ＞

開発終盤の欠陥を抑制（セットベース化）するのに必要な課題ばらしの質（定量化した値）を次の改善目標値として設定し、継続改善で必要となる次の改善の開始点と目標点を明確にできた。

(開発規模：約90人月、開発期間：約8ヶ月)

○○○○○○改善実行シート_トヨタＡ３報告シート_問題解決ストーリ

テーマ名：個人と組織が継続的な改善と進化を遂げるための取り組み成果(効果)の定量化

１．背景

　　記載略（改善検討シートと同一）

２．目標（ターゲット/ゴール）

　1) 課題バラシの質の定量化指標を定義する。　2) すべての課が、課題バラシの質の測定と評価を行える体制を整える。　3) 各課の取り組みを考察し、次の改善指標を定める。

３．現状（確認結果）

課題ばらしの質を計測し、マイルスト-ン毎の実績を基に改善の取組み状況を確認した。

　課題ばらしの質の計測の取組み経過：　　Alpha4～Alpha7：初期流動観察期間　　Alpha9～入検版：計測と振返りの実施期間

　課題ばらしの質の計測結果： "Ｐ" の値 178 / (178+40) = 0 .82 //△△△以外のユニット 46 / (46+18) = 0 .72　//△△△系

４．現状に対する分析７．フォローアップ（○○○ ⇒△△△ にむけての改善課題）【考察】　入検版での不具合がXXXXに集中しており、他のユニットに比較し　△△△はＰの値(課題ばらしの質の値)が低い。

　△△△の11件の不具合のうち 8件が課題ばらしの問題のため、　不具合の分析に記述されている"T"を実施することで、Ｐの値(課　題ばらしの質の値)が他ユニットと同一水準へ改善される。

・課題ばらしの質の計測目安値（暫定の適正値)は、0.82 とする（ユニット単位）。

　理由：取り組み成果の定量化　　1) 開発終盤に多くの不具合修正が発生したユニットにおいて分析通りに事前の課題抽出　　　　を行い目安値をクリアした場合、(当初予定に対する)工期の遅延を回避し、入検直前に　　　　行った多数の不具合修正を軽減(11件->3件)できたため。　　2)目安値をクリアしたユニットでは開発終盤の不具合修正が殆ど無く、リリース日を変更す　　　　る要因となるinc .も無かったため

５．対策今後の新製品開発に向けての課題：　1) 開発終盤に多くの不具合修正が発生したユニットにおいて分析通りに事前の課題抽出を　　行い目安値をクリアした場合、(当初予定に対する)工期の遅延を回避し、入検直前に行った　　多数の不具合修正を軽減(11件->3件)できた。

　2) 目安値をクリアしたユニットでは開発終盤の不具合修正が殆ど無く、リリース日を変更する　　要因となるinc .も無かった。

６．効果・パフォーマンス<品質>は、入検版に割り付けられた不具合対応の件数(12件)で算出する。　12 ÷ {(9160＋0)/100 } ≒ 0 .131[件/人月] // □□□の実績は、0.23件/人月

　12件の内訳：　　⇒xxxx_001 . inc (目的に記述された11項目 ←△△△系ユニットで11件の不具合)　　　補足）"P"値 0 .72は、入検直前に多数の不具合修正が必要となり、リリース日を変更

　　⇒xxxxxxxx_0110_013 . inc (背景に記述された1項目 ←△△△以外の５ユニットで1件の不具合)　　　補足）"P"値 0 .82は、開発終盤の不具合修正が殆ど無くリリース日の変更要因も無し

　上記実績により、開発終盤の不具合を抑制する課題ばらしの質の値は 0.82付近であると推定する。同時にこの数値は、後から分かる課題を一定以下に抑制(＝セットベース化)するのに必要な値であることを示す。


5.2 新規性が高い開発で遅延を防止する活動の結果


① 全ての課題を対象に新規性を確認（大／中／小)

→新規性が“大”について、②以降の対策を実施

② 担当者の課題ばらし結果を関係者で再確認

③ 工数バッファを持った計画を策定

④ 見積工数と実績工数の差を確認し分析

製品B で新規性に対する改善を行った結果＜改善策②-1 ＞ (開発規模：約180人月、開発期間：約30ヶ月、アジャイル方式により月１回のリリース)

＜設定した改善策＞

リリース期日達成率[%]*6 改善する前改善後

０％ ⇒ ８６％

＜結果＞

*6) リリース期日達成率＝期日達成リリース数 / リリース数 ×100[%]


5.2 新規性が高い開発で遅延を防止する活動の結果（続き）


製品Bで新規性に対する改善を行った結果（続き）＜改善策②-2 ＞

＜課題ばらしを形式化した例＞

使用した工数バッファの中身を解析した結果、大半は事前抽出が可能で、形式化が可能。可能なものについて、課題ばらしの形式化を実施。

課題ばらしを形式（テンプレート）化し再利用することで工数バッファの使用率を1/2程度にする効果あり（推定）

課題ばらしの再利用（親クラス）

機能追加時の変更箇所見落としの防止

機能追加で送信データの追加/変更を伴う場合、関連する他の

ユニット(データを受信する側のI/F)への影響を確認する必要が

ある。

機能追加を行うユニット側の対処だけでは不足がある場合、

関連する他のユニットで不整合(不具合)が発生する事がある。

Step1: 機能追加で送信データの追加/変更を伴う場合、関連す

る他のユニット(データを受信する側のI/F)への影響を

分析する（-> 影響有り or 影響無し）。

Step2: Step1で影響有りの場合、影響箇所を洗出し、内容を

分析する（内容は完全でなくても良い）。

Ste 3: 関連ユニットで摺合せを行って課題を明確化し、全体

から見て適切な解決策を出す。

タイトル

前提

課題

解決策

課題ばらしの再利用（子クラス）

△△△ユニット機能追加時の変更箇所見落としの防止

機能追加で書き込みデータ種類を増加する場合、関連する他

のユニット(XX, YYとのI/F)への影響を確認する必要がある。

機能追加を行うユニット側の対処だけでは不足がある場合、

関連する他のユニットで不整合(不具合)が発生する事がある。

Step1: 機能追加で書き込みデータ種類を増加する場合、関連

する他のユニット(データを取得するユニットのI/F)へ

の影響を分析する（-> 影響有り or 影響無し）

Step2: Step1で影響有りの場合、影響箇所を明確化し、内容を

分析する（-> 関数追加が必要）。

Step3: Step 3の分析に基づき、関連ユニットと打合せを行う。

タイトル

前提

課題

解決策

汎化多態化


5.3 改善結果のまとめ


直交軸*7の改善活動の目標と結果（ＧＭＴ指標[6]の適用） *7）組織的活動によって技術力を高める流れ

改善策① ：A3ストーリの利用（製品A）改善策②-1：見積精度ばらつきの低減（製品B）改善策②-2：課題抽出力の強化（製品B）

GMT指標改善策設定した目標結果

Ｇ（グレード）

開発活動において成し遂げたい状態

① 課題ばらしの質を測る指標を定義し、測定と評価を行える体制にする。

達成

②-1 新規性の高いテーマ向けの計画手順を改善する。

達成

②-2 新規性が高い開発の課題ばらし方法を改善する。

達成

Ｍ（メリット）

グレードの達成によりできるようにし

たいこと

① 今回の取組み結果を分析し、次の改善目標を設定したい。

達成

②-1 リリース予定通りに製品を出荷したい。達成

②-2 工数バッファの使用率を低減したい。達成見込

Ｔ（タイミング）

グレードに掲げた状態を達成する

時期

① 2015年 6月まで達成

② 2015年 8月まで達成


６. 考察



6.1 改善の継続性を確保する活動


再利用性：A3ストーリは、LAMDA(2周分)の実施結果（経過）を一目で把握でき、改善途中で開発リーダが代わっても新リーダは内容を容易に把握できる。

継続性：A3ストーリは、改善の（次の）開始点を容易に特定でき、活動予定版（製品）が変更された場合でも、改善活動のスタート点を容易に把握できる。

Ａ３ストーリは再利用性と継続性を向上するのに有効 →「専門家チーム」へ「セットベース開発」を組合せた活動により確認


チームで課題内容を確認すると新規性を見極める正確度を向上でき、見積り精度のばらつきを低減

するのに有効 →「専門家チーム」に属する活動により確認

後から分かった課題を形式化し再利用すると、事前に抽出できる範囲を拡大でき、課題の抽出力を強化するのに有効 →「知識の再利用」に属する活動により確認


6.2 新規性が高い開発で遅延を防止する活動ソフトウェア品質シンポジウム2015


6.3 考察のまとめ


水平軸の活動

直交軸の活動

トヨタ開発方式は開発の阻害要因（「待ち」、「遅れ」、「欠陥」）に対する解決法を提示している。特に直交軸に属する活動（専門家チーム / セットベース開発 / 知識の再利用）は、製品化する流れ(水平軸)を増強する働きがあり（今回の活動で確認)、新規性の高い開発では不可欠要素である。

増強！

原因

結果


７. 今後の課題




7. 今後の課題

五つの土台

2012年度

2013年度

2014年度

2015年度


導入運用運用

専門家チーム

調査/検討

導入運用

セットベース開発

調査/検討

導入運用

知識の再利用

調査/検討

導入

チーフエンジニアリング

調査/検討

運用

PM問題解決ナビへ移行

当社において、トヨタ開発方式のカスタマイズと現場への導入は、開発の流れの確立に始まり、次に専門家チームとセットベース開発の導入（ソフト開発のセットベース化)を行い、そして知識の再利用へと進んだ。

現在、PM（Project Management）問題解決ナビ*8を作成し（チーフエンジニアリング

を含む）、運用を準備中。 *8）開発工程の中で発生する「待ち」、「遅れ」、「欠陥」の問題の種類毎に、問題を解決した経験や知識を集めて体系化し、参照しやすい形で提供するツール


ご清聴ありがとうございました。



参考文献 • [1]James M.Morgan and Jeffrey K.Liker The TOYOTA Product Development System トヨタ製品開発システム(翻訳), 日経ＢＰ社, 2007 • [2]比嘉定彦他：SQiP2013_報文集_B3-1 「トヨタ開発方式の利用によるソフト開発のＱＣＤ向上活動」，(財)日本科学技術連盟，2013 • [3]比嘉定彦他：SQiP2014_報文集_A3-3 トヨタ開発方式の深掘りによるソフト開発のＱＣＤ向上活動，(財)日本科学技術連盟，2014 • [4]稲垣公夫：開発戦略は「意思決定」を遅らせろ，中経出版，2012 • [5]中村素子, 勝田博明：技術者・エンジニアの知的生産性向上日本能率協会マネジメントセンター出版, 2009 • [6]日本能率協会コンサルティング(JMAC):２軸思考・ＡＮＤ思考による開発力強 http://www.jmac.co.jp/training/development/rd_031.html • [7]Frank Buschmann / Regine Meunier / Hans Rohnert / Peter Sommerlad / Michael Stal / Pattern-Oriented Software Architecture ソフトウェア開発のためのパターン体系, 近代科学社, 2000



＜付録課題ばらしと作業ばらしの比__製品ＡとＡ’＞


製品Ａ

開発規模課題ばらしが有るインクリメント数

（中盤～）

課題ばらしが無いインクリメント数

（同左）

課題ばらし無しの割合

欠陥率

90人月 49 27 約36% 0.131

製品Ａ’

開発規模課題ばらしが有るインクリメント数

課題ばらしが無いインクリメント数

課題ばらし無しの割合

欠陥率

45人月 46 11 約19% 0.02

必要な課題ばらしの網羅点"X"

36%＞"X"＞19%

欠陥率＝工程終了後に他部署から指摘された不具合の件数 / 人月

セットベース化するポイントは、必要な課題ばらしを網羅する。


トヨタ開発方式の包括的利用によるソフト開発...

Documents

Transcript of トヨタ開発方式の包括的利用によるソフト開発...

トヨタ開発方式の包括的利用による ソフト開発...

Documents

Transcript of トヨタ開発方式の包括的利用による ソフト開発...

トヨタ開発方式の包括的利用によるソフト開発...

Transcript of トヨタ開発方式の包括的利用によるソフト開発...