SEC セミナー住友電工における Agile(Scrum)の試行評価住友電気工業株式会社情報システム部中村伸裕 Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All r

(1)

Ingenious Dynamics

住友電気工業株式会社

情報システム部

中村　伸裕

2012.10.24

住友電工における

Agile(Scrum)の試行・評価

SEC セミナー

(2)

Ingenious Dynamics

Agenda

１．会社紹介

２．

Agile(Scrum) 導入の背景と狙い

３．

_{Agile(Scrum) の適用}

４．

_{Agile(Scrum) の試行結果}

５．

_{Agile(Scrum) の評価}

(3)

Ingenious Dynamics

(4)

P.4 Ingenious Dynamics

1.1 会社概要

　住友電気工業株式会社

商　号

　１８９７年（明治３０年）

創　業

　９９７億円

資本金

　松本　正義

社　長

　１８２，７７３人

連　結

従業員

　連結対象会社　３２５社　（国内１２４社、海外２０１社）

グループ

　連結売上高　　　　２兆３３８億円

業　績

　連結営業利益　　１０３８億円

（２０１１年３月末現在）

(5)

P.5

(6)

P.6 Ingenious Dynamics

1.3 製品

ワイヤーハーネス

多心光ファイバケーブル

フレキシブルプリント回路

銅荒引線

合成ダイヤモンド単結晶スミクリスタル®

超硬工具イゲタロイ®

40Gbit/s伝送用光トランシーバ

純緑色半導体レーザ

(7)

P.7 Ingenious Dynamics

1.4 住友電気工業(SEI)の組織図

((研究開発部門))

解

析

技

術

研

究

セ

ン

タ

ー

解

析

技

術

研

究

セ

ン

タ

ー

((コーポレートスタッフ部門))

法務部・広報部・人事総務部・人材開発部・安全環境部・経理部・財務部・経営企画部・

情報システム部・資材部・物流管理部・生産技術部・品質管理部・知財部・貿易管理室等

法務部・広報部・人事総務部・人材開発部・安全環境部・経理部・財務部・経営企画部・

情報システム部

・資材部・物流管理部・生産技術部・品質管理部・知財部・貿易管理室等

((事業部門))

電

線

・

機

材

・

エ

ネ

ル

ギ

ー

　

事

業

本

部

電

線

・

機

材

・

エ

ネ

ル

ギ

ー

　

事

業

本

部

エ

レ

ク

ト

ロ

ニ

ク

ス

　

事

業

本

部

エ

レ

ク

ト

ロ

ニ

ク

ス

　

事

業

本

部

情

報

通

信

・

シ

ス

テ

ム

　

事

業

本

部

情

報

通

信

・

シ

ス

テ

ム

　

事

業

本

部

産

業

素

材

事

業

本

部

産

業

素

材

事

業

本

部

自

動

車

事

業

本

部

自

動

車

事

業

本

部

<営業本部>

材料技術研究開発本部

材料技術

研究開発本部

情報通信研究開発

　　　　本部

情報通信

研究開発

　　　　本部

自

動

車

技

術

研

究

所

自

動

車

技

術

研

究

所

エ

レ

ク

ト

ロ

ニ

ク

ス

・

材

料

研

究

所

エ

レ

ク

ト

ロ

ニ

ク

ス

・

材

料

研

究

所

半

導

体

技

術

研

究

所

半

導

体

技

術

研

究

所

Ｎ

Ｅ

Ｘ

Ｔ

セ

ン

タ

ー

Ｎ

Ｅ

Ｘ

Ｔ

セ

ン

タ

ー

パ

ワ

ー

シ

ス

テ

ム

研

究

所

パ

ワ

ー

シ

ス

テ

ム

研

究

所

Ｎ

Ｅ

Ｘ

Ｔ

セ

ン

タ

ー

Ｎ

Ｅ

Ｘ

Ｔ

セ

ン

タ

ー

パ

ワ

ー

シ

ス

テ

ム

研

究

所

パ

ワ

ー

シ

ス

テ

ム

研

究

所

情

報

通

信

研

究

所

情

報

通

信

研

究

所

光

通

信

研

究

所

光

通

信

研

究

所

伝

送

デ

バ

イ

ス

研

究

所

伝

送

デ

バ

イ

ス

研

究

所

(8)

P.8 Ingenious Dynamics

1.5 情報システム部門の体制

住友電工

事

業

部

事

業

部

事

業

部

事

業

部

・・・

協

力

会

社

協

力

会

社

・・・

情報システム部

・システム企画

・

情報技術

(IT)

　

住友電工

情報システム

(株)

　設計、開発

　運用、保守

(9)

P.9 Ingenious Dynamics

1.6 オープン化への取り組み

年度

方式

_OS

言語

ＤＢ

～８０ホスト集中処理

IBM S370

NEC ACOS

COBOL

IMS

ADBS

８１～９０

汎用機分散設置

IBM 4300

NEC ACOS

DB2,DL/I

ADBS

９１～９４

_{分散処理（}

_telnet）

ＵＮＩＸ

Informix-4GL

Informix

９５～９６

_Ｃ／Ｓ

_{Developer2000}

Oracle

９７～９８

Webシステム

Windows NT

Cold Fusion

９９～０４

Linux

Java / Tomcat

Oracle, DB2

０５～０６

PostgreSQL

０６～

Linux + Xen

ポイント：

　・新規開発のシステムは、

全社同一プラットフォーム

　・比較的小さい規模で再構築する為、

全ＰＪ同一プロセス

で開発

(10)

P.10 Ingenious Dynamics

1.7 ＱＣＤ改善の取り組み

1991

Informix-4GL用

ジェネレータの開発

開発フェーズ

生産性

30%UP

1994

T字形ER手法の導入

（

DOA導入）

外部設計～結合テスト生産

性

_30%UP

1997

ファンクションポイントの導入

計測方法の見直し

1999

楽々

Framework の開発

(View, Controller)

UI Component

Struts相当の部品

2001

システム開発プロセス改善

（CMM）

CMMレベル３を達成

（2003年４月）

2003

楽々

Framework II の開発

組立型開発の開始

業務用コンポーネント

５００種類以上

2007

統計的品質管理（ＳＱＣ）

CMMI レベル３達成 (2007/7)

2011

品質予測モデル確立

CMMI レベル５達成 (2011/6)

(11)

P.11 Ingenious Dynamics

1.8 組織の強み

品質制御技術

統計的品質管理

再利用技術

楽々

_{Framework II}

（適用率

: 100%）

要件定義技術

Ｔ字形ＥＲ手法

（適用率

: 100%）

管理図の導入

(2007 ～)

開発量の大幅削減を

実現

(2003～)

要件定義のあいまいさと

内部矛盾を排除

(1994～)



核となる技術を組織全体で定着化

(12)

P.12 Ingenious Dynamics

1.9 他社との生産性比較



SEC『データ白書 2010-2011』との比較

当日のみ

(13)

Ingenious Dynamics

(14)

P.14 Ingenious Dynamics

２．１　

_{Agile（アジャイル）の現状}



「顧客満足を最優先し、価値あるソフトウェアを早く継続的に提供します」

「アジャイルソフトウェア開発宣言　アジャイルソフトウェア開発の原則」より



アジャイルが欧米の競争力に繋がっている（

IPA/SEC報告書）



CMMI, PMBOK, BABOK 等のモデルもアジャイル対応が進んでいる



海外におけるアジャイル普及状況

→日本では請負契約の問題で広まっていない（米国では準委任契約が主体）

_{引用元「非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査報告書」ＩＰＡ}

Scrumが全体の

70%を占める

(15)

P.15 Ingenious Dynamics

２．２　Ａｇｉｌｅ導入の目的



１．システムの価値を最大化

システム開発の費用と期間を固定し

システムの価値を最大化



２．開発者のモチベーション向上

　　自立的な活動



３．開発者の能力向上

開発者全員が計画、監視、制御、外部設計に関わることで能力が向上する



４．改善活動の定着化



５．

QCDの評価



品質：悪化しないのか



コスト：繰返し開発による手戻り量



納期：「顧客満足を最優先し、価値あるソフトウェアを早く継続的に提供」

(16)

Ingenious Dynamics

(17)

P.17 Ingenious Dynamics

プロダクト

オーナー

ＰＯ

スクラム

マスター

ＳＭ

開発チーム　５～９名

ユーザー

スプリント（２～４週間）

３．１　

_{Scrum（スクラム）とは}

スプリント

計画ミーティング　　　　　

　　　　

スプリント

レビュー

スプリント

レトロ

スペクティブ

Ｐａｒｔ１

（１～２時間）

Ｐａｒｔ２

（２～４時間）

Ｐａｒｔ２

（２～４時間）

上長（課長、部長）

デイリー

スクラム

（１５分／日）

•プロダクト開発の管理に使用されてきた

　プロセスフレームワーク

•スクラムの特徴：

　①軽量　②理解が容易　③

習得は非常に困難

（１～２時間）

プロダクト

バックログ

_{バックログ}

スプリント

バーンダウン

_チャート

プロダクト

繰り返し

スプリント

ゴール

(18)

P.18 Ingenious Dynamics

スプリント（

スプリント（２週間

２週間

）

３．２　試行ＰＪの概要

スプリント

計画ミーティング　　　　　

　　　　

スプリント

レビュー

スプリント

レトロ

スペクティブ

Ｐａｒｔ１

（１～２時間）

Ｐａｒｔ２

（２～４時間）

Ｐａｒｔ２

（２～４時間）

プロダクト

オーナー

ＰＯ

スクラム

マスター

ＳＭ

開発チーム　

開発チーム　６名（＋ＳＭ）

６名（＋ＳＭ）

ユーザー兼上長

デイリー

スクラム

（１５分／日）

（１～２時間）

プロダクト

バックログ

_{バックログ}

スプリント

バーンダウン

_チャート

プロダクト

時短勤務

２名

新人

２名

他ＰＪとの

掛け持ち

２名

• 基幹系システム二次

PJ（派生型開発）

• 開発規模：約２８人月

• １スプリント２週間　×　６スプリント

• ユーザ：システム部門

スプリント

ゴール

繰り返し

(19)

P.19 Ingenious Dynamics

スプリント（

２週間

）

３．３　プロダクトバックログ

スプリント

計画ミーティング　　　　　

　　　　

スプリント

レビュー

スプリント

レトロ

スペクティブ

Ｐａｒｔ１

（１～２時間）

Ｐａｒｔ２

（２～４時間）

Ｐａｒｔ２

（２～４時間）

プロダクト

オーナー

ＰＯ

スクラム

マスター

ＳＭ

開発チーム　

６名（＋ＳＭ）

ユーザー兼上長

デイリー

スクラム

（１５分／日）

（１～２時間）

プロダクト

バックログ

_{バックログ}

スプリント

バーンダウン

_チャート

プロダクト

スプリント

ゴール

繰り返し

(20)

P.20 Ingenious Dynamics

(21)

P.21 Ingenious Dynamics

スプリント（

２週間

）

３．４　スプリント計画ミーティング

スプリント

計画ミーティング　　　　　

　　　　

スプリント

レビュー

スプリント

レトロ

スペクティブ

Ｐａｒｔ１

（１～２時間）

Ｐａｒｔ２

（２～４時間）

Ｐａｒｔ２

（２～４時間）

プロダクト

オーナー

ＰＯ

スクラム

マスター

ＳＭ

開発チーム　

６名（＋ＳＭ）

ユーザー兼上長

デイリー

スクラム

（１５分／日）

（１～２時間）

プロダクト

バックログ

_{バックログ}

スプリント

バーンダウン

_チャート

プロダクト

スプリント

ゴール

繰り返し

(22)

P.22 Ingenious Dynamics

３．４　スプリント計画ミーティング

　説明を受けたプロダクトバックログより

　今回、開発できる機能を選択

　※優先度の高いものから取り組み

ＰＯより説明　

イメージ

_合わせ

概算見積

ゴールの

_決定

_{バックログ作成}

スプリント

スプリント計画ミーティング

Ｐａｒｔ１　（１Ｈ）　　　　　　Ｐａｒｔ２・・・基本的にはメンバーのみ（ＰＯは必要に応じて参加）　（４～８Ｈ）

マニュアルでは２～４Ｈだったが

実際は倍近くかかっていた

(23)

P.23 Ingenious Dynamics

スプリント（

２週間

）

３．５　スプリントバックログ

スプリント

計画ミーティング　　　　　

　　　　

スプリント

レビュー

スプリント

レトロ

スペクティブ

Ｐａｒｔ１

（１～２時間）

Ｐａｒｔ２

（２～４時間）

Ｐａｒｔ２

（２～４時間）

プロダクト

オーナー

ＰＯ

スクラム

マスター

ＳＭ

開発チーム　

６名（＋ＳＭ）

ユーザー兼上長

デイリー

スクラム

（１５分／日）

（１～２時間）

プロダクト

バックログ

_{バックログ}

スプリント

バーンダウン

_チャート

プロダクト

スプリント

ゴール

繰り返し

(24)

P.24 Ingenious Dynamics

(25)

P.25 Ingenious Dynamics

スプリント（

２週間

）

３．６　バーンダウンチャート

スプリント

計画ミーティング　　　　　

　　　　

スプリント

レビュー

スプリント

レトロ

スペクティブ

Ｐａｒｔ１

（１～２時間）

Ｐａｒｔ２

（２～４時間）

Ｐａｒｔ２

（２～４時間）

プロダクト

オーナー

ＰＯ

スクラム

マスター

ＳＭ

開発チーム　

６名（＋ＳＭ）

ユーザー兼上長

デイリー

スクラム

（１５分／日）

（１～２時間）

プロダクト

バックログ

_{バックログ}

スプリント

バーンダウン

_チャート

プロダクト

スプリント

ゴール

繰り返し

(26)

P.26 Ingenious Dynamics

３．６　バーンダウンチャート　

～部外者にもわかる進捗管理～

「着地」

タスクを計画通りにやりきること

大変

よくできました

失敗

(27)

P.27 Ingenious Dynamics

スプリント（

２週間

）

３．７　デイリースクラム

スプリント

計画ミーティング　　　　　

　　　　

スプリント

レビュー

スプリント

レトロ

スペクティブ

Ｐａｒｔ１

（１～２時間）

Ｐａｒｔ２

（２～４時間）

Ｐａｒｔ２

（２～４時間）

プロダクト

オーナー

ＰＯ

スクラム

マスター

ＳＭ

開発チーム　

６名（＋ＳＭ）

ユーザー兼上長

デイリー

スクラム

（１５分／日）

（１～２時間）

プロダクト

バックログ

_{バックログ}

スプリント

バーンダウン

_チャート

プロダクト

スプリント

ゴール

繰り返し

(28)

P.28 Ingenious Dynamics

３．７　デイリースクラム　

～日々の監視と制御～

当日のみ

(29)

P.29 Ingenious Dynamics

スプリント（

２週間

）

３．８　スプリントレビュー

スプリント

計画ミーティング　　　　　

　　　　

スプリント

レビュー

スプリント

レトロ

スペクティブ

Ｐａｒｔ１

（１～２時間）

Ｐａｒｔ２

（２～４時間）

Ｐａｒｔ２

（２～４時間）

プロダクト

オーナー

ＰＯ

スクラム

マスター

ＳＭ

開発チーム　

６名（＋ＳＭ）

ユーザー兼上長

デイリー

スクラム

（１５分／日）

（１～２時間）

プロダクト

バックログ

_{バックログ}

スプリント

バーンダウン

_チャート

プロダクト

スプリント

ゴール

繰り返し

(30)

P.30 Ingenious Dynamics

３．８　スプリントレビュー　

～結果報告とデモ～



メンバー



プロダクトオーナー、スクラムマスター、チームメンバー



ユーザ兼上長



実施



１時間程度で以下の内容を実施



スプリント結果報告

ゴールの達成状況、バーンダウンチャート、品質レポート



デモと質疑応答　　

「デモ」することはとても重要視されている



プロダクトオーナーによる完了判定

→改善要望はプロダクトバックログへ



うまくいったこと、問題点、解決方法（レトロスペクティブの前に）

スプリントレビューだけがプロジェクトトレースの場

これ以外はチームの邪魔をしてはいけない

通常はユーザ部門の利用者も参加する

（参加者は状況に応じて判断）

※今回は情報システム部門で利用するシ

ステム

(31)

P.31 Ingenious Dynamics

スプリント（

２週間

）

３．９　スプリントレトロスペクティブ

スプリント

計画ミーティング　　　　　

　　　　

スプリント

レビュー

スプリント

レトロ

スペクティブ

Ｐａｒｔ１

（１～２時間）

Ｐａｒｔ２

（２～４時間）

Ｐａｒｔ２

（２～４時間）

プロダクト

オーナー

ＰＯ

スクラム

マスター

ＳＭ

開発チーム　

６名（＋ＳＭ）

ユーザー兼上長

デイリー

スクラム

（１５分／日）

（１～２時間）

プロダクト

バックログ

_{バックログ}

スプリント

バーンダウン

_チャート

プロダクト

スプリント

ゴール

繰り返し

状況に応じて

(32)

P.32 Ingenious Dynamics

３．９　

スプリントレトロスペクティブ

　

～振り返りと改善の機会

当日のみ

まず良かった点から振り返る

メンバー１人ずつ順番に話す

Keep

Problem

Try

次へのＴｒｙは

問題の対策だけなく

継続すべき良かった事も

あげる（定着するまで）

次に問題点を振り返る

(33)

P.33 Ingenious Dynamics

スプリント（

２週間

）

３．１０　次のスプリントへ

スプリント

計画ミーティング　　　　　

　　　　

スプリント

レビュー

スプリント

レトロ

スペクティブ

Ｐａｒｔ１

（１～２時間）

Ｐａｒｔ２

（２～４時間）

Ｐａｒｔ２

（２～４時間）

プロダクト

オーナー

ＰＯ

スクラム

マスター

ＳＭ

開発チーム　

６名（＋ＳＭ）

ユーザー兼上長

デイリー

スクラム

（１５分／日）

（１～２時間）

プロダクト

バックログ

_{バックログ}

スプリント

バーンダウン

_チャート

プロダクト

スプリント

ゴール

繰り返し

(34)

Ingenious Dynamics

(35)

P.35 Ingenious Dynamics

スプリントレトロスペクティブ（メンバー自身の振り返り）

４．１　スクラムの実施　～着地までの道のり～

第１スプリント

約

90Hタスク残

・計画甘い

失敗

第２スプリント

約

60Hタスク残

・計画外のタスク発生

・遅れのトレース不足

失敗

第３スプリント

初めての着地！

・

20%バッファの活用

・デイリースクラムでの

トレース有効

成功

•投入予定の見直し

（スプリント期間中の各日の

　投入予定工数を積上げ）

•タスク毎に責任者の明確化

•予定工数の80%で計画

　（20%はバッファ）

•デイリースクラムで遅れトレース

これでうまくいくと思ったが・・・

(36)

P.36 Ingenious Dynamics

第７スプリント

・残り２回の準備期間

・開発はしない

（小改善のみ実施）

スプリントレトロスペクティブ

４．２　スクラムの実施　～再び着地を目指して～

第８スプリント

着地！

・

事前の仕様検討

・UT検収強化

ITシナリオ減(いじわるテスト増)

第９スプリント

着地！

・８ｽﾌﾟﾘﾝﾄでの仕様準備

・PG開発の進捗チェック

成功

ようやくわかってきた

チームも成長してきた

チームはもっと

成長できる

スプリント

設計

開発

設計

開発

事前に要件の理解と

設計に着手しておく

第４スプリント

約60Hタスク残

作業残

第５スプリント

約25Hタスク残

作業残

第６スプリント

１日遅れ

作業残

成功

•要件を理解する期間を確保

(37)

P.37 Ingenious Dynamics

４．３　９スプリントの結果

第１スプリント

約90Hタスク残

・計画甘い

リリース失敗

第２スプリント

約60Hタスク残

・計画外のタスク発生

・遅れのトレース不足

第３スプリント

初めての着地！

・20%バッファの活用

・デイリースクラムでの

トレース有効

第４スプリント

約

60Hタスク残

・メンバー入れ替えの

オーバーヘッド？

第５スプリント

約

25Hタスク残

・もうちょっとなのに

第６スプリント

着地したが１日超過

・成功と言えなくも

ないが・・・

第８スプリント

着地！

・事前の仕様検討

・UT検収強化

ITシナリオ減(いじわるテスト増)

第９スプリント

着地！

・８ｽﾌﾟﾘﾝﾄでの仕様準備

・

PG開発の進捗チェック

成功

第７スプリント

・

残り２回の準備期間

・開発はしない

（小改善のみ実施）

作業残

成功

作業残

リリース失敗

成功

終了

（予算100%消化）

(38)

Ingenious Dynamics

(39)

P.39 Ingenious Dynamics

４．

_{Agile試行の評価　　～Ａｇｉｌｅ導入の目的に対して～}



確認したかったポイント



１．システムの価値を最大化

システム開発の費用と期間を固定し

システムの価値を最大化



２．開発者のモチベーション向上

自立的な活動



３．開発者の能力向上

開発者全員が計画、監視、制御、外部設計に関わることで能力が向上する



４．改善活動の定着化



５．QCDの評価



品質：

JUAS報告によるとウォーターホール型開発よりバグ数１．５倍



コスト：繰返し開発による手戻り量



納期：「顧客満足を最優先し、価値あるソフトウェアを早く継続的に提供」

２ モ

チ

ベ

ー

シ

ョ

ン

(40)

P.40 Ingenious Dynamics

４．１　システムの価値を最大化



スプリント毎の価値の最大化

ユーザの要求を

実現する時間

ユーザの要求を

実現する脳

外部設計

基本設計

ＰＧ開発

ＩＴ

１人のＳＥ

　＋ＰＭ・ＰＬのレビュー

１つの価値観

価値観×価値観

チーム全員

複数名が１つの

設計に参加する

→複数のアイデアが出る

ウォーターフォール型

１０Ｈ／機能

１４Ｈ／機能

＋　５Ｈ／機能

動くものができることによって

さらに設計アイデアが出る

→設計時間をより多くかける

アジャイル型

★本ＰＪに現れた現象★

・議論の時間が増える

　（計画時に20%のバッファ確保）

・ＩＴフェーズでも機能追加

・設計リードタイムは1/2

・設計コストは２倍

・ホワイトボードで設計

　（イメージ合わせ）

　→直ぐにダメと指摘できる

機能に対する

価値を高めている

２ モ

チ

ベ

ー

シ

ョ

ン

(41)

P.41 Ingenious Dynamics

システムを構成する機能

４．１　システムの価値を最大化



機能別に見る価値の最大化

機能の価値

１　　２　　３　　４　　５　　６　　７　　８　　９　

１０ 「スプリント毎の価値の最大化」

→より価値を高める

「繰り返し開発による価値の最大化」

→より価値のある機能を選択し開発する

さほど価値（効果）の高くない機能

２ モ

チ

ベ

ー

シ

ョ

ン

機能

(42)

P.42 Ingenious Dynamics

４．２　モチベーションの評価　　

メンバー７名にアンケート

なぜ好印象をもってもらえたのだろう？

２ モ

チ

ベ

ー

シ

ョ

ン



スクラム開発について

「従来のウォーターフォール型と比べてどうです

か？」

　　　　　　

←　とても　　　　やや　　どちらともいえない　やや　　　　とても　→

　

良い　　　　　　|---○---+---+---|　悪い

面白い　　　　　|---○---+---+---|　面白くない

やる気がでる　　|---+-○---+---+---|　やる気がない

効率的　　　　　|---+----○---+---+---|　非効率

効果的　　　　　|---+-○---+---+---|　非効果的



スクラムを続けたいか？

　　　　　　

←　とても　　　　やや　　どちらともいえない　やや　　　　とても　→

　

続けたい　　　　|---○---+---+---|　続けたくない

(43)

P.43 Ingenious Dynamics

２ モ

チ

ベ

ー

シ

ョ

ン

４．２　モチベーションの評価　　



仕事が楽しくなる５つのキーワード

「ありがとう」といってもらえる仕事

「なぜ、何のために」がわかっている仕事

「ゴール」が見える仕事

「昨日より今日が」前進している仕事

「おめでとう」が言い合える仕事

スプリントレビュー

ユーザ（ＰＯ）から直接フィードバック

Ｓ計画ミーティング①など

ユーザ（ＰＯ）と直接コミュニケーション

スプリントゴール

スプリント期間

レトロスペクティブ

バーンダウンチャートの

着地をみんなで喜ぶ

•メンバーみんなで目標に向

かってやっていけた

•相談しやすい

•自主的に他の人のタスクを引

き取る

•機能設計するときに目的を意

識するようになった

•Ｔｒｙに対する結果が２週間後に

出る

•要求変更をエーッと思いながら

も取り込めた

•１次開発ではＰＧ担当でなぜは

わかってなかったが２次開発では

要求を理解しながら取り組めた

•１次に比べて機能が充実した

•機能設計で細かい事にこだわ

らない、ゴールを重視

スクラムのルール

アンケート結果

　・仕事が楽しくなるポイントを押さえているスクラムのルール

　・アンケート結果も対応

使命感

達成感

成長実感

一体感

充実感

参考文献

　「仕事が楽しくなる！２５のルール」

　大林伸安,ダイヤモンド社

(44)

P.44 Ingenious Dynamics

４．３　開発者の能力向上

２ モ

チ

ベ

ー

シ

ョ

ン

開発者の能力

ベテラン

中堅

若手

ＰＪ管理能力

（計画・監視・制御）

外部設計能力

プログラミング能力

－

統合テスト能力

(45)

P.45 Ingenious Dynamics

改善の分

類

①

②

③

④

⑤

⑥

⑦

⑧

⑨

計画

進捗

設計開発

コミュニ

ケーション

４．４　改善活動の定着化　

～レトロスペクティブの

_Try～

　・スプリントが終わる度にレトロスペクティブを実施

　・一人一人が必ず発言するので自ずと改善意識が高まる

　・次の２週間ですぐ実践できる

投入予定

時間を積上

日別人別

_投入計画

前半

/

後半

計画

PG

完了

予定日の意識

UT

ｴﾋﾞﾃﾞﾝｽ

作成指示

PG

開発

タスクの細分化

とトレース

遅れﾘｽﾄで

ﾄﾚｰｽ

全員で

ｲﾒｰｼﾞ合わせ

打合せ中に

ﾀｲﾑｷｰﾊﾟｰ

外部ﾁｰﾑとの

調整は前倒しで

要求・仕様を

理解する

期間の確保

ﾎﾜｲﾄﾎﾞｰﾄﾞに

見たﾁｪｯｸ欄

後半に回しても

いいタスク

プログラム

構造図の記述

予定工数の

80%

で計画

若手２名の

指導

ス　　プ　　リ　　ン　　ト

２ モ

チ

ベ

ー

シ

ョ

ン

(46)

P.46 Ingenious Dynamics

４．５　

_QCDの評価



Ｑ：品質



時間あたりの欠陥作り込み（ＰＧ開発）　　→組織標準より約２０％多い



規模あたりの流出欠陥（リリース後３ヶ月）→組織標準より約１５％少ない



Ｃ：コスト　生産性



規模（ＦＰ値）あたりの開発工数　→組織標準とほぼ同じ

※但し、今回は計測したのは機能拡張ＦＰ値（派生開発型）

　組織標準はアプリケーションＦＰあたりの標準工数なので

　厳密な比較ではない　（機能拡張ＦＰでの標準工数は規定無い）



Ｄ：納期



約２週間毎に対象機能を確実にリリース

　動くソフトを継続的にリリースできた

　厳密な比較はできていないが、さほど悪くならない

　欠陥作り込みは多いが流出はむしろ少ない

２ モ

チ

ベ

ー

シ

ョ

ン

(47)

P.47 Ingenious Dynamics

４．６　

_{Agile試行の評価　まとめ}

Agile試行　評価項目

結果

１．システムの価値を最大化

◎

２．開発者のモチベーション向上

◎

３．開発者の能力向上

◎

４．改善活動の定着化

◎

５．

_QCDの評価

_△

◎：効果がとても認められる

△：効果はあまり認められないが悪くなることもない

(48)

P.48 Ingenious Dynamics

評価項目

従来プロセス資産の活用度

開発者モチベーション

×

従来の

CMMIではモチベーションに関するPAはない

C

M

I

の

プ

ロ

セ

ス

エ

リ

ア

プロセ

ス

管理

OPD,OT,

OPM

組織プロセス定義

,組織トレー

ニング

_{,組織実績管理}

－

OPF

組織プロセス重視

△

レトロスペクティブでなぜなぜ分析を実施

OPP

組織プロセス実績

◎

組織ベースライン、ｕ管理図（工数ベース）活用

PJ管

理

QPM

定量的プロジェクト管理

◎

PP,PMC,

IPM

プロジェクト計画、監視と制御、

統合プロジェクト管理

×

アジャイルではスプリントバックログ、バーンダウン

チャート、デイリースクラムなど活用

SAM

供給者合意管理

－

RSKM

リスク管理

×

コスト超過・納期遅延のリスク小

REQM

要件管理

○ 業務要件の理解→画面設計の技術は同じ

エンジ

ニアリ

ング

RD

要件開発

○ TS,PI

技術解

,成果物統合

◎

ウォーターフォールとほぼ同じ

VER,VAL

検証

,妥当性確認

◎

支援

MA,CM

測定と分析

,構成管理

◎

PPQA

プロセスの成果物と品質保証

－

試行ＰＪだったので

SQA検証など実施せず

DAR

決定分析と解決

○ チーム開発による複数案

CAR

原因分析と解決

－

補足

.AgileScrum試行における従来プロセス資産の活用度

ＣＭＭＩモデル適用のウォーターフォール型プロセス

(49)

P.49 Ingenious Dynamics

補足．開発メンバーからの提言　

～アジャイルを取り組む方へ～



開発チームは一箇所集中



コミュニケーションが最大の効果を生む



ＰＪルーム、席を集めるなど（７人でも席が端と端だと効率落ちるという声も）



打合せを頻繁に行うので他の人に気兼ねなくできるスペースが望ましい



１日最低５時間のコアタイム確保　　　

_{※コアタイム＝全員が揃っている時間}



本ＰＪでは実質３時間（

10:00～14:00）



時短メンバー、他

PJとの掛け持ちメンバーおり実質はもっと少なく

コミュニケーションロスが多かったという声



メンバー構成



少なくとも、ウォーターホールの各工程をできる人が集まっている事

　設計だけできる人のチーム、ＰＧだけできる人のチームでは何もリリースできない



期間が短いのでフレ幅が小さく安定して開発できる人

（＝自己品質管理ができる人）が理想



チームワーク



与えられた仕事をだけをやるスタンスではダメ



チームの達成すべきゴールを理解し、

それに対して自分がどういう貢献できるかという取り組みが必要

(50)

Ingenious Dynamics

The END

SEC セミナー 住友電工における Agile(Scrum)の試行 評価 住友電気工業株式会社 情報システム部 中村 伸裕 Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All r

Ingenious Dynamics

住友電気工業株式会社

情報システム部

中村 伸裕

2012.10.24

住友電工における

Agile(Scrum)の試行・評価

SEC セミナー

Ingenious Dynamics

Agenda

１．会社紹介

２．

Agile(Scrum) 導入の背景と狙い

３．

Agile(Scrum) の適用

４．

Agile(Scrum) の試行結果

５．

Agile(Scrum) の評価

Ingenious Dynamics

P.4

Ingenious Dynamics

1.1 会社概要

住友電気工業株式会社

商 号

１８９７年（明治３０年）

創 業

９９７億円

資本金

松本 正義

社 長

１８２，７７３人

連 結

従業員

連結対象会社 ３２５社 （国内１２４社、海外２０１社）

グループ

連結売上高 ２兆３３８億円

業 績

連結営業利益 １０３８億円

（２０１１年３月末現在）

P.5

P.6

Ingenious Dynamics

1.3 製品

ワイヤーハーネス

多心光ファイバケーブル

フレキシブルプリント回路

銅荒引線

合成ダイヤモンド単結晶 スミクリスタル®

超硬工具 イゲタロイ®

40Gbit/s伝送用光トランシーバ

純緑色半導体レーザ

P.7

Ingenious Dynamics

1.4 住友電気工業(SEI)の組織図

((研究開発部門))

解

析

技

術

研

究

セ

ン

タ

ー

解

析

技

術

研

究

セ

ン

タ

ー

((コーポレートスタッフ部門))

法務部・広報部・人事総務部・人材開発部・安全環境部・経理部・財務部・経営企画部・

情報システム部・資材部・物流管理部・生産技術部・品質管理部・知財部・貿易管理室 等

SEC セミナー住友電工における Agile(Scrum)の試行評価住友電気工業株式会社情報システム部中村伸裕 Ingenious Dynamics Copyright (C) 2012 Sumitomo Electric Industries, Ltd All r

中村　伸裕

_{Agile(Scrum) の適用}

_{Agile(Scrum) の試行結果}

_{Agile(Scrum) の評価}

　住友電気工業株式会社

商　号

　１８９７年（明治３０年）

創　業

　９９７億円

　松本　正義

社　長

　１８２，７７３人

連　結

　連結対象会社　３２５社　（国内１２４社、海外２０１社）

　連結売上高　　　　２兆３３８億円

業　績

　連結営業利益　　１０３８億円

合成ダイヤモンド単結晶スミクリスタル®

超硬工具イゲタロイ®

情報システム部・資材部・物流管理部・生産技術部・品質管理部・知財部・貿易管理室等

・資材部・物流管理部・生産技術部・品質管理部・知財部・貿易管理室等