モデルベース開発におけるＤＩコンテナの活用と

テスト省力化の取り組み

ヤマハ株式会社ＤＭＩ開発統括部

技術開発部安立直之

アジェンダ

• 対象商品/背景

• 流用開発における課題と解決策

–モデルベース開発に基づいた活動計画

• ３つのアプローチ

–システム上のアプローチ

• DIコンテナを用いた分割統治

–品質保証上のアプローチ

• DIコンテナとテストフレームワーク

–多機種展開のアプローチ

• プロダクトライン開発の運用と品質

• 考察と今後の課題

-3-

対象商品背景

ヤマハ株式会社の紹介

• 弊社は音・音楽を中心に展開する企業グループです

–オートバイのヤマハ発動機は兄弟企業です

• 楽器、ＡＶ機器、音響設備、音源ＬＳＩ、カーパーツ、ＦＡ、リゾート、スポーツ用品・・・を事業領域としております

• 本事例は電子楽器が対象です

ｖ

-5-

対象商品と背景

• 録音、オーディオ、カラオケなど付随機能の増加

• 電子楽器のネットワーク化

• 音楽環境の変化

進化のスピードは指数関数的-6-

流用開発における課題と解決策

流用開発の問題点

• モジュールの複雑化

–システムデザインを無視したパッチワーク的変更の積み重ね

• プログラムのビッグバン

–整理・削減されることなく膨れあがった200万stepのシステム

• 設計文書と実装の乖離

–プログラムに仕様が隠蔽

– メンテナンス不可能な虫食い状態の設計文書

• 属人性の高い開発体制

–低コスト開発戦略による人材の固定化

再利用性・開発効率低下が顕著→機能追加もままならない状況に陥る

-8-

問題の要因分析

膨張する担当範囲

少人数戦略

機能別の担当性

効率優先の部分最適型開発スタイル

モジュール結合が強く、関数の複雑度が高い

レイヤの崩壊

作業量 作業の難易度

設計指針の不在

活用されないドキュメント

低コスト開発戦略

潜在する弊害

生産性低下要因

修正中心の開発経験

促進する

増加させる

低下させる

機能中心の設計

差分開発に

偏ったスキル

開発者のモティベーション低下

要員交替・高齢化リスク

生産性

増加させる

低下させる

内部品質に対する意識の低さ

組織の弱み

元の品質の問題

技術面のポリシー欠如

根本原因は

「技術ポリシーの欠如」と「元のソフトウェアの品質」

課題解決の５ヶ年計画

プロセス フレームワーク

仕様定義

品質定義構造定義

実現性検証

プロダクトライン要求分析

機能設計 評価試験

工程管理ドメイン定義

ユースケース定義

品質基準定義

テストメソッド定義

オブジェクト生成管理メカニズム定義

実装パターン定義

標準ライブラリ定義

プロトタイプ作成

評価方法定義

ハード・物理層選定

サービスコンテンツ定義

反復型開発

構成管理システム

サブシステム定義アーキテクチャ定義

タスクマッピング

技術導入基準定義

例：Networkの組込方法検討

例：ドライバ組込方法検討

例：Object管理自動化ツール

例：Class Wizard

作成

例：U/I自動生成

例：コンテンツ連携ツール

例：Class Pattern

Inspector作成

例：開発環境へのCppUnit組込

例：SVNと派生管理

従来のシステムデザインの範囲

活動全体の範囲

プロジェクト管理システム

例：Redmine

と変更管理

-10-

５ヶ年計画の成果

• ユースケースモデリングと派生要求分析法

–全ユースケースのモデル化と派生シナリオ記述による仕様整理

• チケット駆動の大規模反復型開発

–チケット駆動による全変更管理と反復型開発

• 文書管理とトレーサビリティ

– コードのみならず全文書のSubversion管理とRedmine連動によるトレーサビリティ実現

• 継続的インテグレーションと常時静的解析

– Jenkinsによる自動ビルドと静的解析の常時実行

• etc...

-11-

具体的な施策はボトムアップで解決

今回の成果発表の範囲

DIコンテナと品質にフォーカスし３つのアプローチについて報告致します

• システムの密結合解消のためのアプローチ

– DIコンテナを用いた分割統治による疎結合の実現

• 品質保証におけるテスト効率化のためのアプローチ

– DIコンテナの応用によるテストフレームワークの実現

• 多機種展開における差分管理のためのアプローチ

–プロダクトライン開発における差分管理と品質保証の実際

-12-

システム密結合解消のためのアプローチ

～ＤＩコンテナを用いた分割統治～

流用開発におけるシステムの課題

• 他のシステム同様、レイヤー構造は概念上存在したが・・・

• 実装定義がなく、PMの目を逃れて想定外の実装が作られる・・・

• 工数やパフォーマンスの都合のため、レイヤーを無視した実装が増加

• 機種毎に似て非なるインターフェースやモジュールを増設

Ｕ／Ｉ

Application

Mechanism

Driver

機能α

メカニズム①

ドライバ甲

ＣＰＵ

Driver乙

Sub System

Sub System

サービスＡ サービスＢ

機能β

機能γ

メカニズム②

ハードウェア

レイヤーを無視したモジュールの増設

レイヤーを無視したモジュールの接続

上位レイヤーのOS・ハード依存

-14-

システムの課題の実例

• レイヤー構造の崩壊

–例：パフォーマンスを出すためにU/Iが直接ハードウェアのボリューム値を読み出して表示してしまう

–例：ファイル層でリード対象のファイルを検索するために、U/Iの表示値を直接取得している

• 似て非なる実装の増殖

–例：ピアノとギターの音の違いのために、引数が異なるが殆ど同じ関数が作られる

–例：楽曲再生と楽譜表示とで、殆ど同じ音楽ファイルの解析処理が別々に作られる

-15-

見通しの悪いシステムで設計効率が低下重複コード増殖により検証工数が増加

interfaceX

Dependency Injection(依存性注入)

• Dependency Injection(依存性注入)=Javaを中心にEnterprise系で普及した部品化技術

• 部品間の関連を、部品以外（フレームワーク）で管理することで、独立性を向上させる考え方

• 部品間の関連は「コンテナ」と呼ばれるフレームワークで定義、管理するため、関数の呼び出しはシステム管理者の手を介して行われる– 無秩序なモジュールの関連を作りにくく、レイヤーの維持に効果

functionX obj = new classB();

obj.BBB_Method( ParameterB );

classA

classB

interfaceX

classAの中にclassB依存のコードが混入

classA

classB

functionX obj =

container.getComponent();

obj.XXXmethod( Parameter );

classAの中に記述されるのは汎用インターフェースのみ

コンテナ呼び出し関連を定義した設定ファイル

生成しclassAに渡す=依存性注入

参照

■従来の依存関係 ■DIコンテナによる疎結合

functionX obj = new classB();

obj.CCC_Method( ParameterC );

DIコンテナによる実装置換

• 部品間の関連づけはコンテナが定義するため、同じインターフェースで異なる部品を追加することが可能

• 呼び出し側の実装を変更することなく、コンテナの定義を書き換えるだけで動作を変えることができる

functionX obj = new classB();

obj.BBBMethod( ParameterB );

functionX obj =

container.getComponent();

obj.XXXmethod( Parameter );

classA

classB

interfaceX

classC

他の動作に置き換えるにはclassAの修正が必要

classA

classB

interfaceX

classC

コンテナ

classAは一切修正せず設定ファイルで動作の置き換えが可能

依存性定義G

■従来の依存関係 ■DIコンテナによる疎結合

依存性定義F

DIコンテナによる実装置換の例

-18-

U/I Wave再生

コンテナobj = container.getComponent();

obj.Command( PLAY_SONG );

param = obj.Parameter( SONG_NO );

U/Iに記述されるのはフレームワークと「曲を再生せよ」という抽象的な命令のみ

■従来のモジュール結合

■DIコンテナによる結合

U/IWave再生

obj = new classB();

obj.doWavPlay();

obj.getWavNo();

MP3再生obj = new classC();

obj.doMp3Play();

obj.getMP3No();

MP3再生

WaveファイルからMP3に変更するにはそれぞれの関数を直接記述する⇒派生開発では#ifだらけのスパゲティコードに！

void

classC::Command( MP3No )

{・・・}

void

classB::Command( WaveNo )

{・・・}

既存システムに導入する際の課題

1. ハードウェアの制約で機種毎のチューニングが必要！

–機種Ａはタスク間通信でもよいが、低コストなシステムの機種Ｂは割り込みで直接アクセスしないと間に合わない

2. 機種毎のI/Fの違いを抽象化するなんて無理！

–モジュール毎にデータ型の扱いが異なる

–将来引数を増やしたい時にどうするのか

3. 既存のソースコードが膨大で切り分け出来ない！

– １００万行以上あるので全体を置き換える工数がない

–複数機種のコードが#ifで混在していて、手をつけられない

-19-

1.DIコンテナとOS依存性の排除

class A class B

task I/F

semaphore

OS

利用する

異なるタスクを利用する

■OS依存のモジュール結合

■OS機能を隠蔽したDIコンテナ

class A class B

コンテナ

OS

obj = container.getComponent();

obj.XXXMethod();

I/Fを直接記述するだけでなくOSのAPIも埋め込む

必要がある

FactoryMethod+StrategyPatternにより事前にID毎に割り当てたプロセスを提供する

OSシステムコールはDIコンテナの中で暗黙的に使われる

cre_mbx( ID, MailBox);

snd_msg( ID, pMessage );

rcv_msg( pMessage, ID );

classB obj = new classB();

obj.XXXMethod( pMessage );

依存性を定義した

設定ファイル

task I/F

semaphore

2.インターフェース抽象化の鍵

• 旧資産とのインターフェースとデータの取扱がネック

–同じ意味でもモジュールによって型や扱いが異なる

• 電子楽器で扱うデータを「音楽記号」クラスにて抽象化

–システム内で流通するデータを一元化

– Translatorクラスがそれぞれの型に変換

-21-

AbstructData

DataTypeA

Translator

class A

class B

コンテナ

class C

シリアライズデータ

表示値 内部値

「翻訳」の概念を取り入れることでモジュール間のデータの違いをならす

タスク間通信に必要なシリアライズ処理もTranslatorに機能を隠蔽

コンテナ

3.段階的なモデルベース化

• 旧資産とのI/FをDIコンテナ化

–モデル内に「AbstractDriver」を配置してブリッジ

–漸次旧資産を置き換えることで開発負担を分散化

• モデル＝実装を維持するリバースエンジニアリング

– Enterprise Architectのリバースエンジニアリング機能でモデルと実装を常に一致

–設計レビューでチェック

-22-

IManua lEventConvert er

+ convert(MESSAGE_TYPE*, UINT8) : MusicalSignature*

同期前の状態

同期後の状態IManua lEventConvert er

+ getParam(void) : UINT32+ convert(MESSAGE_TYPE*, UINT8) : MusicalSignature*

AbstractDriver

classA

旧資産

classB

アーキテクチャ構造の改善結果

• Doxygenによるモジュール間の依存性解析結果

レイヤー明確

単方向関連

構造が簡素、単方向による疎結合化で設計効率が大幅に向上

■改善前 ■改善後

ソフトウェア品質特性の改善結果

• ソフトウェア品質特性のメトリクス集計

–オージス総研様の協力の下にAdquaにて計測

• http://www.ogis-ri.co.jp/product/b-08-000001A6.html

• ソフトウェア品質６特性（信頼性、効率性、保守性、移植性、再利用性）で得点化

ソフトウェア品質特性も大幅に改善

ケース 改善前 改善後

A社 71.19 80.42

E社 67.69 85.20

G社 71.10 -

J社 53.47 -

ヤマハ 70.46 84.27

平均 70.18（未掲載分も含む） 80.16（未掲載分も含む）

ソフトウェア品質特性の改善結果詳細

• より詳細に品質副特性までを従来機種と比較

–システムの堅牢さに繋がる「信頼性」、「効率性」に効果

–保守性の中でも「試験性」が大幅に向上

• 再利用性はU/I自動生成部を含むため低く出ている（後述）

-25-

項目 改善前 改善後

信頼性成熟性 87.07 93.13

障害許容性 87.43 91.87

効率性時間効率性 72.27 73.94

資源効率性 71.13 87.60

保守性

解析性 81.03 83.07

変更性 75.78 71.83

安定性 75.60 77.10

試験性 68.14 72.25

再利用性 62.56 57.43

信頼性・効率性・試験性の向上でタイミング依存の難解な不具合が激減

DIコンテナによる分割統治の実際まとめ

1. DIコンテナにOSを隠蔽しフレームワークの強制を高める

–設計方針の逸脱を防ぎ、将来に渡りレイヤーの崩壊を防いだ

–その場凌ぎの結合が引き起こす、組込特有のリアルタイム性・タイミングの問題が減った

2. DIコンテナに加えデータ翻訳機構を取り込む

– DIコンテナの効用である実装置換をしやすくした

–翻訳機構をＰＭが掌握することで抽象的なI/Fを確実に作らせた

3. DIコンテナを通し新資産/旧資産を切り分け

–段階的なモデルベース化を実現した

–呼び出し側モジュールを修正せずに新/旧の入替が可能になりテスト工数の削減にも繋がった

-26-

品質保証におけるテスト効率化のためのアプローチ

～ コンテナによるテストフレームワークの実現～

組込システムにおけるテスト環境の課題

1. デュアルターゲットへの対応

– ターゲット・ホスト両方で実行可能なクロス環境の確保

2. Mock/Stubオブジェクト作成と置換の手間

–モジュール出力先のMock作成と置き換えが手間

– ドライバなどのMock化、ハードウェア検査の仕組みが必要

3. 継続的インテグレーションの実現

–定期ビルドがしづらい環境

DIコンテナの活用で解決

1.DIコンテナを活用したクロス開発環境

• DIコンテナにOSのシステムコールを隠蔽したことで、システム全体をクロス開発＆テスト環境で動作可能に

class A class B

DIコンテナ

組込OS

obj = container.getComponent();

obj.XXXMethod();

PC OS

コンテナ実機環境用依存性定義

組込環境のソースコードがそのままPC環境でも動作

コンテナ内でシステムコールを置き換えることでどんな環境でも等しく動作・テスト可能

PC環境用依存性定義

実機での依存関係

2-1.DIコンテナを活用したテストスタブ

• テストコード内で自由にclassBをMock/Stub化できるのでclassAのテストが作りやすくなる

-30-

class A class B

DIコンテナobj = container.getComponent();

obj.XXXMethod();

コンテナ

依存性を定義した

設定ファイル

UnitTestCode

スタブオブジェクト

containerStub

CppUnit

①スタブオブジェクトの宣言

②テスト実行

③送信データの検査

containerStub stub = container.Stub( ID ); /* ① */

classA obj = new classA();

obj.MethodA(); /* ② */

int param = container.DumpStub( ID, commandID ) ;

CPPUNIT_ASSERT_EQUAL( CORRECT_NUM, param); /* ③ */

動的入替

実機での依存関係

2-2.DIコンテナを活用した実機ログ機構

• 実機上でも、依存性定義にログ機構クラスを追記するだけで動作ログを出力

-31-

driver A class B

DIコンテナ

コンテナ

依存性を定義した

設定ファイル

ログクラス

class Logger

シリアル出力

関係追加

DependencytTable[] = {

{ INTERFACE_X, classB, taskN, ・・・ };

{ INTERFACE_X, classLogger, taskL, ・・・ };

・・・

DIコンテナの恩恵でハードウェア周辺もHook可能に

3-1.テスト駆動開発の実現

• DIコンテナがもたらしたモデルベース＆テスト駆動開発

– クロス環境上での動作とテスト実施

–モジュールの自動Stub化＆データダンプが標準装備

-32-

モデルからのスケルトン生成

全I/FをUnitTest

UnitTest実装

Object実装

インターフェース登録

常にテストされた状態を維持しているため機能単位で新/旧資産の置き換えを安定して進められる

機能単位の反復型開発

3-2.テスト駆動開発の運用/ルール設定

• 品質管理の関所として「実装コードとテストコードの同時コミット」を義務化

– ドライバ層などはレビューで代替可にして柔軟性を残す

• モジュールの品質はテストコードが一対か監視すればよい

-33-

実装

テスト設計

UnitTest コードレビュー

コミット

実装コード

テストコード

レビュー記録

リポジトリ

設計

PMはコミット状況だけを監視

3-3.テスト駆動開発の運用/運用監視

• コミットログからテストコード/レビュー記録が同時コミットされているか自動解析

–各ソースの最終コミットにテストコードがあるか集計

–ビルド毎に集計、テストされているか監視

• 実装行数/UnitTest行数比率をチェック

–マクロレベルでテストの過不足を監視

–月（イテレーション）単位でモジュール毎のテスト量を監視

-34-

Subversionのコミットログ テストコードの有無＆行数比率

3-4.テスト駆動開発のための自動化

• 継続的インテグレーション

–全機種について１日３回の定期ビルド＆内部リリースを実施（弊社では15年前から実施）

• Jenkinsを用いた自動ビルドとテスト

– コンパイラ警告の収集

–静的解析の実行

–ユニットテストログ収集

–実行結果の自動通知

• ユニットテストの自動実行は行わない

–対象外のモジュールを考慮

– CIの実行時間の削減

開発フェーズから見る品質改善結果

機種バグ密度 バグ件数

結合前 統合 システム 結合以前 統合以降

適用

機種A 1.22 0.32 0.43 62.0% 38.0%

機種B 2.69 0.26 1.02 67.7% 32.3%

機種C 1.43 1.69 0.78 36.7% 63.3%

機種D 0.17 0.18 0.41 37.1% 62.9%

非適用

機種W 1.67 1.82 1.01 77.5% 22.5%

機種X 0.49 1.53 0.98 16.3% 83.7%

機種Y 0.25 0.43 1.41 11.8% 88.2%

機種Z 0.60 0.34 0.74 35.8% 64.2%

適用機種平均 1.38 0.61 0.66 47.1% 52.9%

非適用機種平均 0.75 1.03 1.04 25.2% 74.8%

-36-

テスト駆動開発が前行程での不具合検出に効果

DIコンテナ応用のテストの実際まとめ

1. DIコンテナにOSを隠蔽しクロス開発環境を実現

–実機レスでより開発環境の低コスト化を実現

–実機では非効率なユニットテストや網羅テストも効率的に実施

2. DIコンテナ対応の汎用スタブを提供

–誰でも手間いらずでスタブを作れることでテスト工数を削減した

3. 新/旧資産の併存を意識した開発フロー策定

–ユニットテストを促進するためのルール作りと、旧資産のための柔軟な対応でシステム刷新を確実に進めた

–モジュール単位でテスト可能なため、常に動作を維持し品質確保しながら徐々に旧資産を入れ替えることができた

-37-

多機種展開における差分管理のためのアプローチ

～プロダクトライン開発における差分管理と品質保証～

プロダクトライン開発における課題

1. 派生モデルの差分管理

–派生モデルを作る度に増える差分

–バリエーション・バリアントの集約と管理

2. プロダクトラインの維持コスト

– コア資産開発と機種開発両方の開発者が必要

– コア資産と機種との要求調整に時間が掛かる

3. 派生モデルの品質管理

–限られたリソースで如何に多数の機種の品質確保を行うか

軽量プロダクトライン開発を模索

classA

classB

interfaceX

classC

コンテナ機種①用

依存性定義表機種②用

依存性定義表

1-1.DIコンテナでソフトウェア資産管理

• DIコンテナにより機種間の差異はインスタンスの差し替えで実現

• 依存性定義表に従って自動的にコンパイル・リンク対象を選択＆インスタンス生成

– #ifによる差分実装を完全排除

UI

1-2.DIコンテナのU/I自動生成への展開

• U/Iは表示コンポーネント化

• DIコンテナ＆I/F抽象化で「振る舞い」まで自動生成対象に

Application

State Trigger

Parameter

View

Command

更新通知

イベント

設定

設定設定

Adapter

Component表示更新

1-3.自動生成とコーディングレス開発

• U/Iは機種毎の状態遷移表だけで構築

• 自社開発の自動化ツールにより約30万行を自動生成

– U/I起因のバグは１プロジェクト通しで0.022件/klocに減少

依存性定義＆状態遷移表の入替だけで差分管理

2.少人数でのプロダクトライン開発

• 本来ならばコア資産＋機種開発で倍の開発者が必要

• 機種毎に必要なclassを作成、インスタンス割当

–渡り鳥のように次々と機種開発し、開発後にコア資産化

–機種側で品質確保することでコア資産専任者を置かない体制

機種A

ベース機種

機種B 機種B+

機種C

機種C+ 機種C++

機種D 機種D++

機種E

機種A#

機種B#

3-1.プロダクトラインでのW字モデル考察

• Wモデルはコストが掛かる

–そもそも「テスト専門技術者」も「テスト専門部署」もいないことも

• Ｗモデルのいいとこ取りを検討

–下流工程はUnitTestによるテスト駆動で充分

–上流工程の「分析精度」を如何にコストを掛けずに上げるか

-44-

要求分析 テスト計画

システムテスト設計

結合テスト設計

単体テスト設計

受入テスト実施

システムテスト実施

結合テスト実施

単体テスト実施

要件定義

アーキテクチャ設計

詳細設計

実装

運用デバッグ

システムデバッグ

結合デバッグ

単体デバッグ

下流工程はUnitTestで担保

上流工程の品質を如何に上げるか

3-2.上流品質の分析精度向上の課題

• 上流工程での課題とは？

–テスト視点では「仕様記載漏れ」が53%– 「設計者自身による設計品質作り込み

-テストエンジニア視点の活かし方-

如何に「漏れ」をなくすか」(大立薫)より

» http://www.juse.or.jp/software/167/attachs/3-2_report.pdf

• 「仕様記載漏れ」の防止

–仕様書記載にテスト視点を取り入れるには？を起点とし、逆にテスト設計における漏れ原因から考察

–仕様書に反映されるのは「因子」まで

-45-

53%29%

18%

仕様不具合原因

仕様記載漏れ

仕様記載間違

い仕様記述不明

瞭

機能漏れ 仕様書の大項目に相当

因子考慮漏れ 仕様書の小項目や動作仕様の内容に相当

水準考慮漏れ 動作の有効範囲を示す水準は記載されるが、それ以外は仕様書には記載されない

組み合わせ考慮漏れ 特異なケースを除き記載されることはない

3-3.分析精度向上/因子抽出に注力

• 要求仕様書の品質特性でリスク大は「正当性」と「完全性」

–正当性：要求仕様書に記述されている要求が、ソフトウェアが満たすべき事柄と一致していること

–完全性：顧客や利用者のニーズが、漏れなく要求仕様書に記述されていること

• 因子のMECE性(完全な全体集合)に注力

-46-

「漏れなく」因子が抽出されているか

因子間の漏れ・ダブりがないか

3-4.分析-テストの２段階モデル

• テストケース作成を２段階化

–要求分析時にマインドマップを使って「因子抽出」を実施

• マインドマップはMECE性の判断が容易– 抽出結果を仕様書にフィードバックし設計漏れをなくす

– 因子の数をテスト計画の見積にも活用

–結合テスト時に「デシジョンテーブル」作成

• 設計～実装での追加・修正要求を手戻り無く反映

• デシジョンテーブルにすることで派生開発での流用性も確保

仕様要素を抽出し、因子となりうる「条件」「トリガー」「結果」に整理

デシジョンテーブルならば行列の追加・削除で派生機種に対応可能

3-5.同時並行開発での品質確保

• 機種開発を１～数ヶ月のイテレーションに分割

• 常に製品レベルの動作を確保しつつ、要求分析時の漏れとテスト作成の手戻りを最小限に抑える

設計・実装

結合・統合テスト

テスト因子抽出

UnitTest

要求分析

プロダクトライン全体を反復開発 機能単位の

反復型開発

プロダクトライン開発の品質結果

年度 総工数 新規行数 バグ数(個) バグ密度

初年度 195.8% 95.6% 119.7% 125.2%

２年目 101.1% 96.5% 22.2% 44.0%

３年目 64.3% 154.0% 27.3% 25.5%

４年目 35.9% 79.1% 62.5% 73.5%

５年目 85.5% 127.0% 31.7% 17.9%

-49-

• ５年間で全６シリーズ/21機種に適用

• 各機種について旧機種開発時とのメトリクスを比較

生産量を維持しつつ工数・バグとも減少

２年目以降はU/I自動生成部を除いた数字！

プロダクトライン開発の実際のまとめ

1. DIコンテナの実装置換機構を用いて差分管理

–依存性定義表から自動でインスタンス生成＆リンクを実現

– U/Iをコンポーネント化し、全コード自動生成を果たした

2. コア開発者を置かない軽量プロダクトライン体制

–機種開発後に実装差分をマージする方式で開発・調整の工数を抑制できた

3. テスト工程の２段階化で上流品質を向上しつつ省力化

–因子のMECE性に集中することで、仕様・設計の漏れ・ダブりを徹底的になくした

–後工程でテストケースに落とすことで、設計・実装時の修正によるテストケース修正の手戻りも削減できた

-50-

考察と今後の課題

ボトムアップからの継続的改善の実現

• DIコンテナのフレームワーク導入が発端

• 第２章以降のテストフレームワークへの展開、プロダクトラインの施策は全て開発者からのボトムアップ

• 最初に描いた大きなビジョンを共有したことが５年間の継続に繋がった

–誰に・何をお願いすることなく、自主的に改善領域を決めて取りかかってくれた

-52-

ビジョン

考察

• DIコンテナを活用したフレームワークの適用に加え、インターフェース抽象化＆抽象データ型で疎結合を実現

–データ型の一元管理で運用崩壊も防止

• DIコンテナにOS機能の取り込みを行う事で、移植性向上に加えクロス開発環境を実現

–将来のシステム変更にも対応

• モジュール単位/プロジェクト全体両輪の反復型開発

–テスト駆動開発の徹底のためDIコンテナをフル活用

• 品質確保のための２段階テスト計画

–上流品質確保のための低コストテストプロセス

今後の課題

• インターフェースクラスとデータ翻訳クラスの自動生成

–必要なデータのパターンがほぼ分かったため、自動化を試みたい（一部では実施）

• UnitTestの自動実行とカバレッジ計測

–ビルド＆実行時間の兼ね合いから本プロジェクトでは実施してこなかったが、UnitTestの実効性向上のためトライを検討

• コア資産上での継続的インテグレーション＆回帰テスト

–別の機種で作られた部品の組み合わせによる不具合が、後の開発で結合して初めて発覚

–敢えて「コア資産開発専任者」を作らなかった少人数開発とのバランスを模索する必要がある

謝辞

このプロジェクトに多大な支援をしていただいた方々に

この場をお借りして謝辞を申し上げます。

株式会社オージス総研 阿佐美勝様

株式会社オージス総研 三宅光様

株式会社オージス総研 渡辺和正様

ヤマハ株式会社 杉山四郎マネージャー

-55-

ご清聴ありがとう御座いました

-56-