価値ある製品を生み出すためのアジャイル実践ポイント

価値ある製品を生み出すためのアジャイル実践ポイント

22 August 2015 13:30～17:00

株式会社日新システムズ

陸野礼子・前川直也

第63回 SEA関西プロセス分科会

プロフィール

陸野礼子（りくのれいこ）株式会社日新システムズ品質保証部

• 2004年より、パナソニック株式会社の組み込みソフトウェア開発のプロセス改善業務に従事し、ホームエレクトロニクス/カーエレクトロニクス製品等の開発現場を舞台に、QMS、CMMI・PSP/TSP、Automotive-SPICE、アジャイルを活用し、プロセスだけでなくチーム力アップをモットーに現場密着型の改善活動に奮闘。

• パナソニック研修所にて、TSP(Team Software Process)をベースに『成功するチーム』の運営法、Redmine活用事例といった研修講師を担当

• 2015年6月、日新システムズに転職

→“WakuWaku”をコンセプトに組織改革に取組み中！

HU-3 【ET West 10周年記念】組込み10年のチャレンジ！これからの10年は!? 3

『システム開発現場のファシリテーション』（技術評論社）

『これだけは知っておきたい組込みシステムの設計手法』

（技術評論社）

『わかりやすいアジャイル開発の教科書』

（ソフトバンククリエイティブ

株式会社日新システムズ社長付主査兼事業戦略部主査

1994 ～日本コンピューター・システム株式会社 1998 ～パナソニック株式会社 2015 ～株式会社日新システムズ

組込みアジャイル

プロジェクトファシリテーション

プロセス改善

産業カウンセラー

アジャイルでお困りの際はお気軽にメールください

ET West 実行委員

@nao_maru

http://www.facebook.com/NaoyaMaekawa

http://www.amazon.co.jp/gp/product/images/4774140147/ref=dp_image_0?ie=UTF8&n=465392&s=books

Agenda

1. 組込みソフトの課題

2. アジャイルのツボ

3. チームビルディング

ワークショップ

4. 品質アプローチ

5. 価値を描く

4

今日のベースはこれです！

CM

5

http://www.sbcr.jp/products/4797371284.html

http://www.sbcr.jp/products/4797371284.html

6

－壱－組込みソフトの課題

以前は、狙っていけば的中する確率が高かった

今の組込み業界では、

環境の変化

ユーザニーズの多様化

競合他社との競争激化

などで、先の読めない状況・・・

環境変化

競合

ソフト業界の変化

7

『要求される価値』から『創り出す価値』の時代に突入！

これまでのソフトウェア開発

設計テスト実装

チェックチェック

要求

価値

インプットアウトプット

決められた機能を要件に落とし込み計画をほぼ変えることなくものづくりができた時代から・・・

8

日程前倒し

課題／バグ

仕様変更

仕様追加

混沌とした組込み業界において、ソフトウェアの変化が発生しないというのはありえない

変化を前向きに受け入れていく必要がある

ソフトウェア開発に変化はつきもの

9

開発開始段階の課題

10

開発中の課題

コミュニケーションギャップ設計・実装上の都合・納期、等

11

納品時の結果

12

規模が大きくなった弊害

営業→企画→開発→QA→製造などのバトンが複雑化しその分、ドキュメントによるバトンリレーが発生しやすくなるそこに「ギャップ」は発生していないだろうか？

13

ソフト業界約60年の歴史

ソフトウェアが商業ベースになりそれにつれて、工学的にアプローチ『誰でも同じように作れるソフトウェア』

2000年頃から、もう一度初心に戻り新たなアプローチが始まる

『ソフトウェアは人が作るものである』

14

人にフォーカスする

What How

Who Where ／ When

15

どちらがエンジニアを活かせますか？

16

短い『タイムボックス』で回しながら、細かくフィードバックし、価値を膨らませていく開発スタイル

今求められているソフトウェア開発

17

製品の価値の最大化を考える

18

製品の価値を決めている主要な部門はどこですか？

企画部門

ニーズ

エンドユーザ

開発部門

製品仕様

技術

販売

世界のTV市場

製品の価値の最大化を考える

19

製品の価値を最大化するために作り手側に何が求められているのか？

大規模メーカーにありがちな罠

一つの商品にかかわるステークホルダが多い

大人数の大規模開発になりがち（ソフトウェア子会社も巻き込んで）

ものづくりのステップ移行で重たくなる（必然的なウォーターフォールに？）

最終ユーザが見えない場合が多い

品質は重要だがQCDのQが大きくなりすぎる

価値のフローが流れにくくなる

20

企画側（What）製品企画段階で

価値ある要求が発見できない

開発側（How）企画段階で

価値を高める提案ができていない

価値を共有できていないため、開発に無駄が発生

21

価値の最大化するためのプロセス

22

アジャイルは単に早い・高品質なだけではなく価値を最大化していかなければ元の木阿弥

変化を味方につけお客様のビジネス価値を最大化する

23

－弐－アジャイルのツボ

ハード部門や工場など関連部門とは

どうしたらいいのか？

上司にどう説明すれば、アジャイルを

導入できるのか？

SQAはどこでステップ移行監査や品質をチェックすればいいのか？

既存の組織プロセスがあるけど、どうしたらいいの？

～組織編～

組込み開発だと顧客が明確でない場合のフィードバックとは誰がするのか？

こんな不安、疑問を持たれてませんか？

25

品質確保できるのか？

開発を委託している場合、どうしたらいいのか？委託元の役割とは？

要素開発で、ハード系仕様がなかなか決まらない、変更が激しい場合はどんな形で導入したらいいのか？

アジャイルを熟知している人がいないと、上手くいかないのでは？

～開発現場編～

こんな不安、疑問を持たれてませんか？

26

アジャイルを導入する前に・・・

[チェックポイント]

プロジェクトにエンジニアリング＆プロセスの基本スキルはどのぐらい？

メンバが風土を変えるぐらいの改善意欲を持っていますか？

自分たちが作っているものに愛着を持っていますか？

• お客様が何を求めているのか考えてる？

改善指標を数値だけで判断していませんか？

• コミュニケーションは活発？

メンバとゴールを共有できていますか？

27

http://agilemanifesto.org/

28

組込みでの開発の方がアジャイルは向いているといえますただし、なぜアジャイルなのか？（目的）どんな価値を出すのか？（目標）をより明確にする必要があります

http://agilemanifesto.org/

スクラムにおけるチームモデル

スクラムチーム

プロダクトオーナー

スクラムマスター

開発チーム

自己組織化チームは、作業を成し遂げるための最善の策を、

チーム外からの指示ではなく、自らが選択する

「スクラムガイド」より

© 1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved

https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide-JA.pdf

29

プロダクトバックログ

ユーザストーリを集めたもの優先順位を決める

スプリントプランニング

スプリントに落とし込みスプリントバックログを作る

スプリントスプリントに落とし込み 1 ～ 4 Week

デイリースクラム

スプリントレビュー

動くソフトウェアでレビュー＋フィードバック

スプリントレトロスペクティブスプリントごとにふりかえり

開発チーム

プロダクトオーナー

スクラムマスター

開発チームの作業とプロダクトの価値の最大化に責任を持つ

スクラムの理解と成立に責任を持つ

スクラムの流れ

30

従来のプロセスとの違い

31

アジャイルソフトウェア宣言の背後にある原則

32

そんな時はもう一度『原則』に戻ってみる

アジャイルとは？

アジャイルとは、お客様のビジネス価値を最大化するための

「考え方」や「姿勢」のこと

33

※ ご注意ここからはとある大規模プロジェクトでの事例を使いながら、ご説明いたします決してパーフェクトな事例ではないかもしれませんが組込みアジャイルのツボを実践するうえでヒントになるはずです

AV機器の組込みソフトウェア開発

• 開発人員約100名（社員4割、協力会社6割） • ソフト開発チームリーダー（TL）

以下フラットな体制

開発規模約2,800kstep

(約8～9割は流用）

SPLグループ

ソフト開発チームTL

ユニットA

UL

ユニットB

UL

ユニットC

UL

ユニットD

UL

ユニットE

UL

ユニットF

UL

機種①

SPL

機種②

SPL

ユニットはコンポーネント単位で分割され、それぞれユニットリーダー（UL）を任命、担当ユニットの開発日程と品質に責任を担う

機種ごとにSPL（ソフトウェアプロジェクトリーダー）を任命、機種のソフト開発の日程と品質に責任を担う

事例：とある大規模ソフト開発現場

35

事例

多機種・時間差・並行開発による遅れの慢性化

年間20機種以上を開発ハード構成の違い、機能差分に

対応しながらの開発

前機種の仕様変更やバグ収束遅れが次々と連鎖！

バグ対応／仕様検討／設計／実装のプロセスが

同時に進行ユニットでスケジュールを

調整しながらの四苦八苦の対応

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

ソフト構造がムダに複雑化（スパゲッティ化）

全体設計を意識したソースコードになってない（意図のないコードが増えバグの温床）

36

事例

従来の開発の流れ

システムテスト

区切りがあるようでない／終盤は実装だけ？

設計着手全機能実装版

仕様検討要求分析

要求分析要求分析

要求分析

・・・・・

設計

詳細設計実装基本設計テスト

詳細設計実装テスト

詳細設計実装

詳細設計実装基本設計テスト

・・・・・

検証

実装テスト

実装実装

実装

テスト設計

ここが最初のゴール約３ヶ月

0次試作 1次試作

2次試作

ゴールまで長いのでダラダラ…

37

事例

自分たちで考え成長を促すために

風土を進化

スムーズに流すため体制と役割を進化

ゴールとリズムで開発の流れを進化

メリハリつける！

協調する！

考える！

3つの改善ポイント

38

事例

わかりやすいアジャイルの『ツボ』

ゴール

• 価値をゴールにし、優先順位をコミットする

• リズムとゴールをマッチングさせる

リズム

• プロジェクトを一定間隔のリズムで区切る

• プロジェクトのベロシティを把握する

見える化

• 状況を見えるようにしてリズムを伝播させる

• 変化を受け入れる

自律

• 自分たちでふりかえる

• 自分たちで変えていく

1

2

3

4

1

2

3

4

①価値をゴールに設定し、コミットする

ゴール



リズム



見える化



自律



ゴールとリズムをつくる

設計基本のV字モデルをキープしながらいつまでに、何を、どう作るのか

ゴールを明確にして、一定期間のサイクルで回す

ゴールを分割して、プロセスの流れを作る

41

要求分析

詳細設計

実装

基本設計結合・機能テスト

単体テスト

システムテスト

5W1Hで考えるのはアジャイルでも同じ

スプリント

#1

スプリント

#2

スプリント

#n

スプリント

#0

・・・・

スプリント

#3

仕様一次Fix

全機能実装版

Why なぜ作るのか？

What 何を作るのか？

How どうやって作るのか？

When いつまでに作るのか？

Who だれが作るのか？

Who どこで作るのか？

設計着手仕様一次Fix

スプリント #1

スプリント #2

スプリント #3

スプリント #4

機器仕様検討

プロダクト検討

関連部署とのコミットメント

設計者の概要見積りをベースにリリース計画（各スプリントの実装要件）

＜Output＞ • プロダクトバックログ（ストーリー実装リスト） • リリース計画／スプリント計画 • その他、関連ドキュメント

ストーリーA：見積り２ポイントストーリーB：見積り 1ポイントストーリーC：見積り 3ポイント

・・・

44

スプリントのゴール設定事例

どんな機能を、何のために作るのかを決めてリストアップ荒い見積は実施するが、ここで確定させてしまうわけではない

プロジェクトのベロシティを把握する

スプリント #1

スプリント #2

スプリント #3

スプリント #4

・・・・

（画像提供：楽天株式会社さま）

一つのスプリントで実現できる作業量（ベロシティ）を自分たちで把握することができる

一つのストーリ（要件でもあり、ファンクションでもある実現すべき価値）を日程や規模、ページ数などではなく設計、レビュー、テストなど全ての作業を合わせた

『ストーリーポイント』として見積る

ストーリーポイントは開発にかかわるチーム全員で見積るカードを使った「プランニングポーカー」を活用し全員でコミュニケーションしながら見積を実施する場合もある

②一定間隔をリズムを継続させる

ゴール



リズム



見える化



自律



価値を一緒に描き、共有していく

部門の壁を越えて、製品の価値を共有するには、一緒に描き、一緒に作り、一緒に確認していく必要がある

47

推進Lこうなる機能

設定した値以上の白が表示されている部分が、ライブビュー出力中に白黒縞々のパターンでマーキングされる（LCD、LVF、HDMI、外部モニターなどすべて）

企画優先度 A

難易度 B

どんな目的（どんな気持ちで）

撮影対象の中に、白トビが発生していないかをリアルに確認するライブビュー、撮影中も確認できる再生中は表示されない主担当U REC

ゼブラパターンを表示するリリーススプリント

要件番号 14A4079 どんな人が？プロの動画カメラマン（静止画カメラマンの一部も含む）

ユニットC ユニットB


機器仕様検討

プロダクト検討

関連部署とのコミットメント

SPLとULでレビューどんな手順で開発を進めるのか双方のイメージ合わせ

ユニットA

UL

ユニットごとに要件別プロセス別見積りを実施 UL

機種

SPL フィードバック

48

メンバー全員でゴールへのコミットメント

ゴールへのコミットメント形成

ゴールをシミュレーションし、自分たちがコミットする

プロジェクトでのコミットメント

事例

プロダクト詳細シート

【お客様は誰？】

① フォーマットに合わせて、みんなでディスカッションをしてみましょう

② 「お客様は誰ですか？」は、名前など特定できればOK

③ 「どんな人ですか？」「求めているものはどんなもの？」を具体化していきましょう

④ １人だけとは限りませんいろいろなパターンを考えてみましょう

ご参考

49

【お客様のハッピー】

① 「お客様は誰？」の結果を書きましょう

② お客様はどんなことをやってみたいと思っていますか？求めているものは？

③ みなさんがつくり出すもので、どんなことが実現できますか？

④ 実際にお客様が使ってみると、どんな気持ちになりますか？

ご参考

50

【ストーリーテラー】

① フォーマットに合わせて、シンプルに書いてみましょう

② 結果をもとに具体的なディスカッションにつなげてみましょう

ご参考

51

設計着手全機能実装版

仕様一次Fix

スプリント #1

スプリント #2

スプリント #3

スプリント #4

1～2 week

スプリント計画

2日程度の粒度のタスクで開発実施

成果レビューふりかえり

機能ごとに V字モデルを回す

52

一定間隔のリズムで区切る事例

プロダクトバックログをスプリントバックログに細分化することは基本的にWBSと似ているが、リズムが一定間隔なことが重要

＜Output＞ • スプリントバックログ（作業タスク） • 作業成果物

③常に状況を見えるようにして変化へ対応する

ゴール



リズム



見える化



自律



様々な見える化により透明性を実現する

54

Redmineでのチケット駆動開発

進捗確認

55

プロジェクトの見える化

ゴールごとのチケット完了状況の確認

各チケットの状況でどの作業が残っているか簡単に把握できる

リアルタイムにバーンダウンチャートを見ることで進捗状況の共有化を図る

事例

スプリントにあわせたRedmineの活用

L開発プロジェクト

ユニットA

ユニットB

ユニットC ユニットC ユニットC

親プロジェクトで全体計画サブプロジェクトでユニット計画を管理し連携する

スプリントのゴール進捗をロードマップで管理

「ターゲットバージョン」で全体計画と連携ユニット単位の進捗はサブプロジェクトで設定

ロードマップにて、ゴール単位の各ユニット進捗を週次で確認 Redmineデータを元に

進捗状況の可視化

事例

ターゲットバージョンの設定

ゴール名称を登録 →スプリントNo_機能名

期日を登録（基本は週の最終稼動日）

チケットごとにゴールを設定する

プロダクト検討#3




スプリント #1

スプリント #2

スプリント #3

スプリント #4

プロダクトバックログはスプリントごとに変化がないか確認

リリースされ価値に変化が発生することもありえる

確認するためには品質の高いリリースが重要

Point


58

ゴールは固定されるのではなく継続的にふりかえる

ふりかえりふりかえりふりかえりふりかえり

事例

④自分たち自身の価値も向上させる

ゴール

•価値をゴールにし、優先順位をコミットする


リズム



見える化



自律



59

平鍋さんブログ「An Agile Way」より

http://blogs.itmedia.co.jp/hiranabe/2012/09/rightwing-and-leftwing-of-agile.html

アジャイルのレフトウィング

60

Agile

【1990年代】オブジェクト指向

モデリング

設計技術をどう回す？

時代にどう合わす？

【2000～02】ペアプロ TDD

反復特有の技術アップ

【2002～】コーチングファシリテーション

人に向き合う！

【2005～】

プロジェクトファシリテーション TPS／SECIモデル

チームビルディング PM

【2007～】要求開発

ビジネスアジャイル

ビジネスとしてとらえる

【2000】アジャイル宣言

ファシリテーション

トヨタ生産方式

アジャイル開発

プロジェクトファシリテーション

【プロジェクトファシリテーション】とは？プロジェクトマネジメント（PM）が重要であることは昨今強く言われています。 PMが「計画達成のマネジメント」に重点を置くのに対してPFは「参加者の協調の場作り」に重点を置いています。PMは、計画の立案と実行、差異に注目した管理が中心で、どちらかと言うと「コマンド･コントロール型」のマネジメントスタイルが背後にあります。これに対してPFは、その場その場の変化に対応し、チームが協力し合って創発的に成果を出していく、「リーダーシップ･コラボレーション型」の新しいチーム作りの形です。（オブラブ公式Webサイトより http://www.objectclub.jp/community/pf/）

アジャイルの変遷とプロジェクトファシリテーション

プロジェクトファシリテーションとは？

61

プロジェクトファシリテーションの価値・原則

コミュニケーション

行動

気づき

信頼関係

笑顔

価値

見える化

リズム

名前付け

問題vs.私たちの構図

カイゼン

原則

朝会

かんばん

KPT

ペアボード

ニコカレ

アイスブレイク

偏愛マップ

MindMap

etc.

プラクティス

62

スクラムは、経験的プロセス制御の理論（経験主義）を基本にしている。経験主義とは、実際の経験や既知に基づく判断によって知識が獲得できるというものである。スクラムでは、反復的で漸進的な手法を用いて、予測可能性の最適化とリスクの管理を行う。

「スクラムガイド」より © 1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide-JA.pdf

63

スクラムの理論

63

スクラムチームの特徴

スクラムチームスクラムチームは、プロダクトオーナー・開発チーム・スクラムマスターで構成される。スクラムチームは自己組織化されており、機能横断的である。自己組織化チームは、作業を成し遂げるための最善の策を、チーム外からの指示ではなく、自らが選択する。機能横断的チームは、チーム外に頼らずに作業を成し遂げる能力を持っている。スクラムにおけるチームのモデルは、柔軟性・創造性・生産性に最適化されたものとなっている。

「スクラムガイド」より © 1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide-JA.pdf

64

【X理論】人間は生来怠け者で、できれば働きたくない強制されたり命令されなければ仕事をしない

【Y理論】生まれながらに嫌いということはなく、働くことは人間の本性条件次第で責任を受け入れ、自ら進んで責任を取ろうとする問題解決のための創意工夫をこらす能力は誰でも持っている

ダグラス・マクレガーのＸ理論Ｙ理論

人間観・動機づけにかかわる2つの対立的な理論

or

65

タイムボックスというリズムの効果

「変わらない時間の測定基準」を使ってプロジェクトのパワーを測り引き出していく

66

ジャンプして届くゴールの繰り返し

67

－参－チームビルディング

ここで、みなさまに質問です

今まで、成功プロジェクトを体験したことありますか？

69

今まで参加したプロジェクトでこんな失敗の経験はないですか？

６ヶ月で完了する計画だったのに

気がつけば、２ヶ月遅れ、さらに２ヶ月遅れ

やっとリリースした商品は欠陥が多く

リワークで多額のロスコストが発生した

この失敗の原因として考えられることは何でしょうか？

70

そもそもスケジュールが非現実的だった

適切な人員がそろえられなかった

仕様変更が多発した

進捗管理が不十分なため、早い時期に遅れに気づくことができなかった

品質を保証できるテスト設計ができていなかった

火消し作業による不具合対策に追われ、効率的な対策がうてなかった

一見、マネジメント（リーダー）の問題？？？

実は、チームワークの問題である場合が多い

失敗の原因を考えてみると．．．

71

チームワークの問題＝コミュニケーションの問題

リーダーとのコミュニケーション不足リーダーから言われたスケジュールに対して、できないと知りつつ、

できないと言わない

課題があっても報告しない

開発者間のコミュニケーション不足隣のメンバーが何をしているか知らない

自分の作業がどこに影響を与えるか知らない

外部（顧客や関連部門）とのコミュニケーション不足仕様が決まらないか、決まった仕様に思い違いがあった

プロジェクトが失敗する原因①

72

厳しい開発スケジュールにあわせる「プレッシャー」

途中のプロセスの実施を省略する

十分な検証をしないまま、新しい言語やツール、手法を利用する

とりあえず手を動かすことを優先して、

計画的、効率的な取り組みが実施されない

プロジェクトが失敗する原因②

73

開発規模の増大と開発期間の短縮化今日の開発プロジェクトは、一人ではできないほど規模が大きい

多くのビジネスにて、市場へ出すまでの時間をできるだけ短くする必要がある

チームは幅広い才能と能力を提供する一人で経験できることは、それほど多くはない

メンバーの才能を最大限に活用する

チームに参加する事で個人の仕事が改善するメンバーは補完しあうスキルをもち、お互いに学び助け合いサポート

レビューや設計のブレーンストーミングなどの場を活用して、

より高度なアドバイスや支援を得て、

個々のスキルを伸ばしていくことができる

「TSPガイドブック：リーダー編」よりワッツ・S・ハンフリー著秋山義博監訳 JASPIC TSP研究会訳

チームが必要とされる理由

74

チームワークはスキルであり、高いパフォーマンスが要求される

チームの真の力は、その合成された力から生じる

自律的なチームを目指すメンバーは言われなくても何が必要か感じ取って、協力して助け合い、仕事を成し遂げるために必要なことはなんでもやる

開発業務における自律的なチームの必要性創造的な開発業務では、全員の心からの参画が必要

質の高い作業は、考え、気を遣い、動機づけられた人々が行う

でも、動議づけってどうすればいいの？！


チームに求められる力とは

75

モチベーション（Motivation）＝動機づけ、やる気

モチベーションがないと、多くのことはうまくいかない

個人でもチームでも、特に創造的な仕事にはモチベーションが重要となる

チームの動機づけ


76

コミットメント個人とチームが約束したことをやりたいと思う気持ち

動機づけの種類

恐怖指示したとおりにタスクを完了しないと職を失うぞ！

思考停止反応を引き起こす

保身的な行動や非合理な行動さえ生じさせる

金銭欲もっと稼げると思うやり方で仕事をする

ノルマ分だけ働く

必要な努力を最小にして最大報酬を得ようとする


77

どのように動機づけをするかが重要ソフトウェア開発では予期せぬことがあるのが普通

予期せぬことには時間と工数がかかるというのが常識

いかに注意深くコミットメントを作っておいても、最後は超人的な努力が必要となる場面もある

では、開発者はどうしてそんな無理をしてくれるのか？コミットメントで動機づけされているから

この動機づけがないと、開発者が燃え尽きてしまうこともある

コミットメント

チームのコミットメントの方が個人のコミットメントより動機づける力が強い


78

個人の目的を、チームの目標達成に融合させて、最大のパフォーマンスを発揮するためのもの

チームのコミットメント

メンバー全員が

共通のゴールに向けて、

仕事をしている

効果的な協同作業を行うための

プロセスがあり、遵守している

成果物やプロセスは、

素早いフィードバックで、

常に改善されている

79

KPTは成長を促すツール

Keepで、チームとしての共感を得る

よかったことを褒めあうと、チームを信頼できる

Problemを共有する

問題を誰かのせいにするのではなく、チームの問題であると認識する

そして、みんなでTry!

誰かがやってくれる、のではなく、自分が、そして誰もがやる！

80

プロジェクトのリズムを使った成長

☞ 定期的に実施する

– 続けるためには、習慣にしてしまう

– 一定期間の短いリズムでふりかえる

☞ 「歩み」を実感しつづける

– 成長していることは、自信につながる

81

結合テストシート

KPT みえる化

昼会

課題管理表

SPL朝会

改善プラン

トップダウンかボトムアップか？

トップダウンボトムアップ

Redmine改良

エンジニアリング

82

事例

座談会課題などについて、ユニットL、有識者、SPLとで意見交流をする「場」

83

ポイント：自由な雰囲気の中での、真剣な話し合い

就業時間内に開催、時間厳守

「会議」にならない配置、お菓子も用意した方がベター

SPLは進行係として「和気あいあい」を徹底、

全員が意見を自由に発言できるようにふるまう

どんな意見が出ても「否定しない」

いい意見が出たら「褒める」

いい案がまとまったら、実行計画をすぐにまとめて、

アクションプランを作成してしまう。

時間内に何もまとまらなかったら、次の機会を作る

トップダウンかボトムアップか？事例

面談個対個の面談で、思いを引き出す「場」

84

ポイントプロセス改善担当者が開発メンバー全員と面談目的：組織方針について、どんな考えを持ってるのか、

仕事に何を期待しているのか、正直な意見を引き出す。聴き手（プロセス改善担当者）のスタンス：

相手に関心を持つどんな意見でも受け入れて、さらに引き出す褒める

メンバーの様々な想いを引き出し、まとめて、組織改善プランにフィードバックする全員に自分たちの「改善計画」だと認識してもらう

事例トップダウンかボトムアップか？

85

最初は個人ごとに様々な目標を持っている

チームは偶然にできあがるものではない

チームを作り上げるには時間がかかる

プロジェクトを推進しながら、チームの成長を促す仕組みを取り

込むことが重要

朝会（スタンダップミーティング）

チームの評価

チーム全員が「メンター」になり、お互いのスキルアップを促す役割を担う

事例チームの成長を促す

定常的なFace to Faceのコミュニケーション

チーム全員が集まって情報を交換する効果的な方法

立ったままで短時間で済ませる（目安15分）

主に確認事項は３つ昨日やったことは？

今日やることは？

進捗が遅れている問題点は何？

検討が必要な課題は別途、打合せの場を設定

問題を抱えている場合は、積極的に助力を求める

チーム全員が他のメンバーが何をしているか知ることができる

86

事例チームの成長を促す～朝会～

Keep

Problem

Try

87

KPTの時にメンバーに確認してみる

新しいチームほど定期的に評価

フィードバックと改善を継続

チームの評価ポイント

全員、チームのメンバーだと共通の意識がある？

全員が共通のゴールに対してコミットしてるか？

チームの中で発生した問題を自分たちで解決してるか？

信頼関係が築かれているか？

正直であること（知らないことは聞く）

ありのままであること（誰でもミスはするもの）

チームのアイデアや意見が尊重されていること

事例チームの成長を促す～チームの評価～

88

チームで効果的な協同作業をする

効果的な協同作業のために個々のスキルを高める

初心者でも「メンター」になれるエキスパートに質問することで、彼らを刺激し動機づけられる

エキスパートは他のメンバーに教えることで、逆に自分も知識を深めることができる

問題に対して、解決のために全員で惜しみなく

知識を分け合うことは、メンバーだけでなく

チームワークのスキルアップにつながる

最初はスクラムマスターが「メンター」を担い、いずれは全員が！

事例チームの成長を促す～チーム全員が「メンター」～

ワークショップ

89

レゴスプリント

ここで一度

90

やってみないとアジャイルはわからない！

メンバーで最終ゴールをイメージする

レゴスプリント

レゴを使ったグループワーク

『最高の飛行機を作ってください！』

92

このグループで・・・

どんな最高の飛行機つくる？

５分

『Smiling Adventure』を使ってみましょう！

93

【お客様は誰？】

① フォーマットに合わせて、みんなでディスカッションをしてみましょう

② 「お客様は誰ですか？」は、名前など特定できればOK

③ 「どんな人ですか？」「求めているものはどんなもの？」を具体化していきましょう

④ １人だけとは限りませんいろいろなパターンを考えてみましょう

ご参考

94

【お客様のハッピー】

① 「お客様は誰？」の結果を書きましょう

② お客様はどんなことをやってみたいと思っていますか？求めているものは？

③ みなさんがつくり出すもので、どんなことが実現できますか？

④ 実際にお客様が使ってみると、どんな気持ちになりますか？

ご参考

95

【ストーリーテラー】

① フォーマットに合わせて、シンプルに書いてみましょう

② 結果をもとに具体的なディスカッションにつなげてみましょう

ご参考

96

ビジネスゴールを常に意識した開発

プロジェクトメンバーと最終形態を一緒に描くことで、プロジェクトの基礎固めができる

ゴールを共有できてるかどうかはプロジェクトに大きく影響する

グループワークからのポイント

97

みんなで描いたゴールをもとに

「タスクをピックアップ」

5分

レゴ飛行機は約1０分×2回で開発します！ 2回とも（完成）させます

98


みんなで考えること

みんなの得意分野は何？

計画段階はイメージ力が重要

短いサイクルでの繰り返し開発には工夫が必要 99

ソフトウェアかんばん

ToDo 未実施

Doing 実施中

Done 完了

サザエ

カツオ

ワカメ

【使い方】

① カードを未実施に貼る

② 実施する前に実施中にカードを移動する

③ タスクが完了したら完了に移動する ※ 貼りかえはリアルタイムに

100

KPTはプロセスを適応させるツール

Keepで、チームとしての共感を得る

よかったことを褒めあうと、チームを信頼できる

Problemを共有する

問題を誰かのせいにするのではなく、チームの問題であると認識する

そして、みんなでTry!

誰かがやってくれる、のではなく、自分が、そして誰もがやる！

101


ほめると伸びる＋欠点も認める

行動（スイッチ）につながる

「人」に視点を置くからこそ「成長」もできる 102

『最高の飛行機」を作ってください！

１０分×２回

1０分×2イテレーション

朝会＋タスクの確認（1分）

グループ作業（6分）

KPT（3分）

KPTの「ふりかえり」は２回目に反映！

かんばんも活用してください

ご完成おめでとうございます

－四－品質アプローチ

平鍋さんブログ「An Agile Way」より

http://blogs.itmedia.co.jp/hiranabe/2012/09/rightwing-and-leftwing-of-agile.html

アジャイルのライトウィング

106

技術品質を継続的にキープする

• コーディングミスが発生しにくい

• コーディングでの誤り混入から発見までの時間が短い（数分～数10分程度）

• コードの可読性が向上する

107

スプリント

デイリースクラム

テスト駆動開発（Test Driven Development）

ペアプログラミング

• コードがきれいになる（レビュー率100％）

• システムやコード、ツールなどの知識を共有できる

• ペアの組み方によっては、トレーニングの効果を得られる

• コミュニケーションが活発になり一体感を生み出す

• 1人で悩んで停止しまうことが少なくなり作業が着実に進む

コードの共同所有

その他にもノウハウはたくさん作るもの、プロジェクトに合わせ自分たちでプラクティスを活用していく

Doneの定義

ストーリへの「完了条件を定義してない」「共有していないこと」がズレの始まりに・・・

どんなテストを完了していますか？

レビューは完了していますか？

お客様視点で動作できますか？

『Doneの定義』を明確に！

対立構図から「問題対私たち」へ

109

製品品質を継続的に確かめ、価値をあげる

スプリントごとに価値をフィードバックするには？

価値が確認できるレベルに動作していること

シンプルに設計し、リファクタリングができること

今必要としていないものをムダに作りこまないこと

デバイスドライバ

ライブラリ

アプリケーション

レイア単位ではなく

ファンクション単位で

－五－価値を描く

もちろんメーカーとしてのメリットもある！

ブランドの力はやっぱりすごい！

技術力は世界トップレベル！

ターゲットに応じて組織体制を変えることができる！

マーケティングの4Pは手の内に！

お金ありまっせ！

112

最も強い者が生き残るのではなく、

最も賢い者が生き延びるのでもない。

唯一生き残ることが出来るのは、

変化できる者である。

チャールズ・ダーウィン

しかも、自分たちだけでなく、まきこめるかどうかも重要

ものづくり日本

みなさんがつくっているものの価値はなに？

システムの機能の利用度

全く使われない45%ほとんど使われな

い19%

たまに使う16%

いつも使う7%

よく使う13%

Standish group study report in 2000 chaos report

システム開発と組込み開発の違い

116

「たまに使う」に意味があったりしませんか？

117

これだとどう思いますか？

1.世界初 4Kミラーレス一眼

2.他社に負けないAFスピード

3.動画プロフェッショナル対応

※実際のコンセプトとは違います

製品の価値を最大化するには？

118

変化を味方につける（価値の共有）

お客様の価値の最大化を考える変化は当然（必要）ととらえ、

すばやく変化を取り入れられるように進める

119

変化を味方につける（開発側から）

120

「Why」を考えてみる

どうなりたいか（BE）がベースになる

Why

なぜ作らなければ

ならないのか？

企業・組織としての Why

個人としての Why

–利益をあげねば –競合他社に勝つ –生産性をあげる –高品質な商品

– リーダとしての成功 –新しい技術を得る –自分の時間を作る –残業しても高収入

いやなことはしたくない・・・

パワーを引き出す「素」は結局のところ「欲求」につながる

スポーツ

ゲーム趣味

家族勉強

仕事

121

「Why」の影響

Why? 企業・組織としての Why

個人としての Why

ビジネスで成功自己成長チーム成長

業績アップ自分の時間

あせり・指示やらされ感

Command Control 思考停止成長停止

二つのプラスがマッチングしたとき最高スペックに！

122

クレドを作ろう！

みなさんとやりたいこと

１．メンバを信頼し、リスペクトする

Sample

２．勇気をもってまわりを巻き込む

Sample

３．ビジネスとしての

成果を意識する

Sample

４．チームは１＋１を２以上にしてくれる

Sample

５．チームの笑顔がお客様の笑顔につながる

Sample

ハード部門や工場など関連部門とは

どうしたらいいのか？

上司にどう説明すれば、アジャイルを

導入できるのか？

SQAはどこでステップ移行監査や品質をチェックすればいいのか？

既存の組織プロセスがあるけど、どうしたらいいの？

～組織編～

組込み開発だと顧客が明確でない場合のフィードバックとは誰がするのか？

こんな不安、疑問を持たれてませんか？（こたえ）

129

価値やゴールをもっと共有しませんか？フィードバックも重要です

上司が目指すものは？

あなたが目指すものは？

ステップ移行も変化しますタイムボックスを

有効に活用しましょう大きく変える必要はありません

何を変えるべきかふりかえりましょう

顧客が明確でない製品を作っているの？価値判断できる人は？

品質確保できるのか？

開発を委託している場合、どうしたらいいのか？委託元の役割とは？

要素開発で、ハード系仕様がなかなか決まらない、変更が激しい場合はどんな形で導入したらいいのか？

アジャイルを熟知している人がいないと、上手くいかないのでは？

～開発現場編～

こんな不安、疑問を持たれてませんか？（こたえ）

品質も含めてタイムボックスでフィードバックします

目指す価値は同じはずお互いの役割を明確にしてリズムを共有しましょう

今必要としていることを明確にして

できるところからシンプルに！何度か繰り返すと形ができるはず

最後までそうではないです一人ひとりがメンターを目指しましょう！

130

131

アジャイルとは、お客様のビジネス価値を最大化するための

「考え方」や「姿勢」のこと

アジャイルは現場駆動人駆動です

変化を受け入れるのではなく

社会に対して変化を生み出していく

組込みだから、アジャイルっしょ。

133

実践こそが

アジャイル！

価値について考える

お客様はだれ？

ユーザーにとっての価値は？

考える習慣、意識を継続

まずは簡単なことからでもOK 実践してみる！

声のかけかた、会議のしかけなどでも現場は変わる

ボトムアップが組織を変える！

13

5

Social Change starts with YOU!!

「未来」は自分たちで描き、自分たちの手で変化を生み出そう！ 135

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