プロセスアプローチから見たアジャイル

～大規模組込みソフト開発における導入事例～

2012年10月11日

パナソニックAVCテクノロジー株式会社

陸野 礼子

SPI Japan 2012

SPI Japan 2012 2

目次

１．背景

２．プロセス改善への取組み

２－１．CMMモデルベース

２－２．アジャイル（スプリント開発）の導入

２－３．現在の取組み

３．プロセス・アプローチから診てみると

４．まとめ

SPI Japan 2012 3

１．背景

■ 私達の開発現場

AV機器の組み込み

ソフトウェア開発

開発人員

約100名

開発規模

約2,800kstep

(約8～9割は流用）

多機種・時間差・並行開発

による遅れの慢性化。

年間20機種以上を開発。

ハード構成の違い、機能差

分に対応しながらの開発

前機種の仕様

変更やバグ収束

遅れが

次々と連鎖！

SPI Japan 2012 4

１．背景

■ 問題～抜けられない負のスパイラル～

日程は

変わらないので

この状態ですでに５年目。疲弊感いっぱいの現場この状態ですでに５年目。疲弊感いっぱいの現場

仕様が

決まらない

次機種の

要件開発が

遅れる

開発が収束

しない

バグ・仕様変更

多発！

ソフト開発の

着手が遅れる

間に合わせる

ために

レビュー・テストを

省略

SPI Japan 2012 5

２．プロセス改善への取組み

� 2002年～：プロセス改善活動を開始

� 社内アセスメントにてレベル２を達成。組織標準を策定。

� 「かんばん」を使ったタスク管理、レビューの徹底など、QCD向上に向

けた取組みもされ、効果が出ていた。

� 2007年～：開発機種が急増し、ソフトウェア開発が爆発！

� それまでの良い取組みは一部のチーム（チーム構成はコンポーネント

単位）でのみ実施され、横展開はされず。

� 組織標準も実態に合わないまま、形骸化。負のスパイラルが始まる。

� 2009年～：トップダウンによる改善活動の立て直し

� プロセスの全面見直し

� 設計力強化に向けた取組みを打ち出すが…。

２－１. CMMモデルベースの改善活動

たとえトップダウンでも、やりたくないことは、たとえトップダウンでも、やりたくないことは、

やらない開発メンバー多数やらない開発メンバー多数……。プロセスアレルギーも？！。プロセスアレルギーも？！

失敗！！

SPI Japan 2012 6

２．プロセス改善への取組み

個人やチームが実践しているプラクティスを個人やチームが実践しているプラクティスを

集めて、みんなで良くなる方法を考えよう！集めて、みんなで良くなる方法を考えよう！

� 2010年1月

� アジャイル社内第一人者がプロセス改善活動に参画し、プロセス

重視ではなく、“ひと”重視の改善活動に切り替えた。

� この厳しい状況でも、ちゃんと商品はできている。つまり、そこには

個々の工夫があるはず？

•今までのプロセスはいったん凍結。

•チーム（コンポーネント単位で構成）の活動や工

夫をWikiにアップし共有化を図る。

•自分達で計画をつくり、自分達で工夫して、計

画を守る、そんな姿勢を期待！

トップダウンがダメならば…

SPI Japan 2012 7

２．プロセス改善への取組み

２－２． スプリント開発の導入

スプリントの

開始日

（基本は月曜日）

S2 S3 S4 S5

2/14

S6

2/21 2/28 3/7 3/14 3/21

2222月月月月 ３３３３月月月月 ４４４４月月月月 ５５５５月月月月１１１１月月月月

▼2/18

仕様DR

▼3/18

α版

ST

▽5/7

MP版

実装仕様

S1

2/7

仕様検討 設計 テスト実装

機能A

機能B

機能C

1週間単位でゴールを設定し、各機能のゴールを決定。

例）機能AのゴールはS3（期日2/25）

1週間の最初にその週の作業を確認（ゴール単位かつ

コンポーネント単位で確認）、最後に振り返りを実施し、

進捗・課題・全体計画との整合性を確認。

GOAL

G3 バーンダウンチャートG3 バーンダウンチャートG3 バーンダウンチャートG3 バーンダウンチャート

0

50

100

150

200

250

300

2/11 2/18 2/25 3/4 3/11 3/18

残チ

ケッ

ト数

計画

実績

（（（（ 設計・実装・結合テストのチケット設計・実装・結合テストのチケット設計・実装・結合テストのチケット設計・実装・結合テストのチケット ））））

設計・実装・結合テスト（バグ修正含む）設計・実装・結合テスト（バグ修正含む）設計・実装・結合テスト（バグ修正含む）設計・実装・結合テスト（バグ修正含む） バグ修正バグ修正バグ修正バグ修正

◆◆◆◆3/14 ◆◆◆◆3/17ST移行判定テスト移行判定テスト移行判定テスト移行判定テスト

α版リリース：3/18

G3 バーンダウンチャートG3 バーンダウンチャートG3 バーンダウンチャートG3 バーンダウンチャート

0

50

100

150

200

250

300

2/11 2/18 2/25 3/4 3/11 3/18

残チ

ケッ

ト数

計画

実績

（（（（ 設計・実装・結合テストのチケット設計・実装・結合テストのチケット設計・実装・結合テストのチケット設計・実装・結合テストのチケット ））））

設計・実装・結合テスト（バグ修正含む）設計・実装・結合テスト（バグ修正含む）設計・実装・結合テスト（バグ修正含む）設計・実装・結合テスト（バグ修正含む） バグ修正バグ修正バグ修正バグ修正

◆◆◆◆3/14 ◆◆◆◆3/17ST移行判定テスト移行判定テスト移行判定テスト移行判定テスト

α版リリース：3/18

バーンダウンチャートバーンダウンチャートバーンダウンチャートバーンダウンチャート

他取組み内容

• 昼会／ふりかえり、KPTなど

• 結合テスト責任コンポーネント

• 結合テスト結果シート

• 最終スプリントを設計STへ

• 進捗管理はRedmineを活用

＠＠プロジェクト

コンポーネントA

コンポーネントB

コンポーネントC

コンポーネントC

コンポーネントC

初めてのスプリント開発で、初めてのスプリント開発で、αα版を計画通りリリース！版を計画通りリリース！

SPI Japan 2012 8

２．プロセス改善への取組み

� 仕様変更の多発とバグ収束の遅れにより日程遅延！

でも、プロジェクトが終わってみると・・・

S7 S8 S9 S10

4/254/254/254/253333/28/28/28/28 4444////4444 4/114/114/114/11

4/184/184/184/18

STフェーズで仕様変更発生仕様確立遅れ

５５５５月月月月

▼5/17

MP版

S2 S3 S4 S5

2/14

S6

2/21 2/28 3/7 3/143/21

2222月月月月 ３３３３月月月月 ４４４４月月月月１１１１月月月月

▼2/18

仕様DR

▼3/18

α版

ST

▽5/7

MP版

実装仕様

S1

2/7

S11

遅延！！

何がダメなのか何がダメなのか……。。

� これまで設計＋プロセスを改善するアプローチはしていた

� 全体設計する／単体テスト仕様を書く／結合テスト設計する・・・

� SPI活動はしてきたものの、牽引するべきリーダ達が回っていない

� 明確な効果があらわれないまま現状開発で精一杯

SPI Japan 2012 9

２．プロセス改善への取組み

� 開発のベースとなる計画が作られていない

� 具体的な計画／設計を共有しないまま、

プロダクトバックログ化→チケット化

� 結果的にメンバ個人の工夫依存の場当たり開発

� コンポーネント内外で様々な工夫を共有していない

� チケットにエンジニアリングの流れが現れてこない

� 全体設計／レビュー／設計テストが大幅に不足

� エキスパート不足のため、スキルアップの機会も少ない

� 開発のベースとなる計画が作られていない

� 具体的な計画／設計を共有しないまま、

プロダクトバックログ化→チケット化

� 結果的にメンバ個人の工夫依存の場当たり開発

� コンポーネント内外で様々な工夫を共有していない

� チケットにエンジニアリングの流れが現れてこない

� 全体設計／レビュー／設計テストが大幅に不足

� エキスパート不足のため、スキルアップの機会も少ない

２－３． 現在の取組み

課題

マネジメント不足が

致命的

設計力不足

場当たり的開発

「マネジメント力強化」と「設計力強化」を両輪に

上流の設計完成度を向上させ、

日程を遵守できるチーム（全体）になる！

SPI Japan 2012 10

２．プロセス改善活動

基本動作仕様書基本動作仕様書

詳細設計詳細設計

実装実装

全体設計全体設計

結合テスト結合テスト

単体テスト単体テスト

システムテストシステムテスト

要求分析

基本設計

スプリント #1

スプリント #1

スプリント #0

スプリント #0スプリント #n

スプリント #n・・・・・・

要件開発 α版 量産

スプリントで

ぐるぐる回す

結合・機能テスト

金曜日には結合テスト完で

内部リリースをすること！

設計／実装 バグ対策

マネジメントと設計力、両輪の取組みを仕組みにして、定着化。マネジメントと設計力、両輪の取組みを仕組みにして、定着化。

ゴール設定で全体計画と

連携 →「TargetVersion」

コンポーネント単位の進捗

→親子プロジェクト設定

ロードマップにて、ゴール

単位での各コンポーネン

トの進捗を週次で確認

Redmineデータを元に

進捗状況の可視化

SPI Japan 2012 11

４．プロセス・アプローチから診てみると。

アジャイルのプラクティスを取り入れていくとしても、

100名もの開発者の力を結集するには、

やはりルール化やプロセス化は重要！

まず決める →実践と同時に手順化 →問題が出れば即時検討して見直す。

この繰り返しで、改善スピードアップを図る。

では、プロセスとしてどう定義すればいいのか？

今までのプロセスはウォーター

フォール的なものばかり。

今の私達の開発に合わせられ

る、なにか良いプラクティスは

ないのかな？ １から作る

のは大変…

SPI Japan 2012 12

４．プロセス・アプローチから診てみると。

• 開発標準（プロセス）の階層

– パナソニックソフトウェア開発プロセスガイドラインより

JIS X 0160入出力は決めていない

作業項目をプロセスごとに

まとめている。

パナソニック

SW開発プロセスガイドライン

当社として標準的な作業

項目を具体化、標準的な入出力を記載

製品の情報セキュリティの考え方を追加

ドメインとして実施すべき作業項目へ

さらに具体化、入出力資料を組織で

使用している名称で記載

手順をプロジェクトの

特性別にさらに詳細化

開発プロセス部

→MIS-X-0027

各組織でＳＰＩ

が、この部分を

作成

全社として

本社が作成

組織単位開発標準

プロジェクト

開発標準

プロジェクト

開発標準

プロジェクト

開発標準

プロジェクトプロジェクトプロジェクトプロジェクト

計画計画計画計画

プロジェクトプロジェクトプロジェクトプロジェクト

計画計画計画計画

プロジェクトプロジェクトプロジェクトプロジェクト

計画計画計画計画

個々のプロジェクトの計画

プロセスアプローチガイドブック 開発標準を用いて計画策定

工夫しだいで

多様なプロセス

に適応できる

ことがわかった

※詳細は別資料

にて説明

SPI Japan 2012 13

４．まとめ

� 私が考える、大規模開発プロジェクトでアジャイルを導入する時

の留意点。

� やはり、開発者のマインドマインドとスキルスキルは必須！

� 一般的に、全員がアジャイルを実践できるだけのマインドとスキルを持っ

ていることは稀である。⇒10名までのチーム編成として、マインドやエン

ジニアリングスキルのコーチ係を置き、「ちゃんと作る」ことを徹底できる

体制を作るとより効果が得られるかも。（現在は100名に対し、コーチ的

役割は2名なので、ケアしきれない。）

� 円滑に推進できるなら、特にアジャイルを意識してもらう必要はないかも

しれない。ただ、ソフトウェアはやはり、“ひと”が創るものなので、個々の

姿勢が品質に影響する。アジャイルについても、ちゃんと理解してもらっ

た上でマインドを育て、今後の成長に向けての取組みとしていきたい。

『自責として課題を捉え、自ら行動し変化を起こす』『『自責として課題を捉え、自ら行動し変化を起こす自責として課題を捉え、自ら行動し変化を起こす』』

引き続き引き続きチャレンジチャレンジしていきます！していきます！

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