Embed Size (px)
Citation preview
技術とサービスをつなぎ 価値ある製品をつくるための 組込みアジャイル ～ 価値をフィードバックし続けるアジャイルの本質 ～
19 July 2015
株式会社日新システムズ
前川 直也
PM創生研様 向け
HU-3 【ET West 10周年記念】組込み10年のチャレンジ！これからの10年は!? 2
『システム開発現場のファシリテーション』 （技術評論社）
『これだけは知っておきたい組込みシステムの設計手法』 （技術評論社）
『わかりやすいアジャイル開発の教科書』 （ソフトバンククリエイティブ
株式会社 日新システムズ 社長付主査 兼 事業戦略部 主査
1994 ～ 日本コンピューター・システム株式会社 1998 ～ パナソニック株式会社 2015 ～ 株式会社日新システムズ
組込みアジャイル
プロジェクトファシリテーション
プロセス改善
産業カウンセラー
アジャイルでお困りの際は お気軽にメールください
ET West 実行委員
Agenda
1. 製品化ソフト開発の課題
2. アジャイルとは？
3. 価値を描く
3
今日のベースは これです！
CM
4
http://www.sbcr.jp/products/4797371284.html
5
－壱－ 製品化ソフト開発の課題
以前は、狙っていけば的中する確率が高かった
今の組込み業界では、
環境の変化
ユーザニーズの多様化
競合他社との競争激化
などで、先の読めない状況・・・
環境変化
競合
ソフト業界の変化
6
『要求される価値』から『創り出す価値』の時代に突入！
これまでのソフトウェア開発
設 計 テスト 実 装
チェック チェック
要求
価値
インプット アウトプット
決められた機能を要件に落とし込み 計画をほぼ変えることなくものづくりができた時代から・・・
7
開発開始段階の課題
8
開発中の課題
コミュニケーションギャップ 設計・実装上の都合・納期、等
9
納品時の結果
10
規模が大きくなった弊害
ソフトウェアが複雑化したぶん、 ドキュメントによるバトンリレーが発生しやすくなる そこに「ギャップ」が発生していませんか？
11
日程前倒し
課題／バグ
仕様変更
仕様追加
混沌とした組込み業界において、 ソフトウェアの変化が発生しないというのはありえない
変化を前向きに受け入れていく必要がある
ソフトウェア開発に変化はつきもの
12
ソフト業界 約60年の歴史
ソフトウェアが商業ベースになり それにつれて、工学的にアプローチ 『誰でも同じように作れるソフトウェア』
2000年頃から、もう一度初心に戻り 新たなアプローチが始まる
『ソフトウェアは人が作るものである』
13
人にフォーカスする
What How
Who Where ／ When
14
どちらがエンジニアを活かせますか？
15
短い『タイムボックス』で回しながら、 細かくフィードバックし、価値を膨らませていく開発スタイル
今求められているソフトウェア開発
16
製品の価値の最大化を考える
17
製品の価値を決めている主要な部門はどこですか？
企画部門
ニーズ
エンドユーザ
開発部門
製品仕様
技術
販売
世界のTV市場
製品の価値の最大化を考える
18
製品の価値を最大化するために 作り手側に何が求められているのか？
変化を味方につけ お客様のビジネス価値を最大化する
19
－弐－ アジャイルのツボ
http://agilemanifesto.org/
21
組込みでの開発の方がアジャイルは向いているといえます ただし、なぜアジャイルなのか？（目的） どんな価値を出すのか？（目標）をより明確にする必要があります
アジャイルソフトウェア宣言の背後にある原則
22
そんな時はもう一度『原則』に戻ってみる
アジャイルとは？
アジャイルとは、 お客様のビジネス価値を最大化するための
「考え方」や「姿勢」のこと
23
価値の最大化するためのプロセス
24
アジャイルは単に早い・高品質なだけではなく 価値を最大化していかなければ元の木阿弥
スクラムにおけるチームモデル
スクラムチーム
プロダクト オーナー
スクラム マスター
開発チーム
自己組織化チームは、作業を成し遂げるための最善の策を、
チーム外からの指示ではなく、自らが選択する
「スクラムガイド」より
© 1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved
https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide-JA.pdf
25
プロダクトバックログ
ユーザストーリを 集めたもの 優先順位を決める
スプリントプランニング
スプリントに落とし込み スプリントバックログを作る
スプリント スプリントに落とし込み 1 ～ 4 Week
デイリー スクラム
スプリントレビュー
動くソフトウェアで レビュー＋フィードバック
スプリント レトロスペクティブ スプリントごとにふりかえり
開発チーム
プロダクトオーナー
スクラム マスター
開発チームの作業と プロダクトの価値の 最大化に責任を持つ
スクラムの理解と成立に 責任を持つ
スクラムの流れ
26
わかりやすい アジャイルの『ツボ』
ゴール
• 価値をゴールにし、優先順位をコミットする
• リズムとゴールをマッチングさせる
リズム
• プロジェクトを一定間隔のリズムで区切る
• プロジェクトのベロシティを把握する
見える化
• 状況を見えるようにしてリズムを伝播させる
• 変化を受け入れる
自律
• 自分たちでふりかえる
• 自分たちで変えていく
1
2
3
4
1
2
3
4
価値を一緒に描き、共有していく
部門の壁を越えて、製品の価値を共有するには、 一緒に描き、一緒に作り、一緒に確認していく必要がある
28
設計着手 α版 仕様一次Fix
スプリント #1
スプリント #2
スプリント #3
スプリント #4
1～2 week
スプリント 計画
2日程度の粒度のタスクで 開発実施
成果レビュー ふりかえり
機能ごとに V字モデルを回す感じ
29
一定間隔のリズムで区切る 事例
プロダクトバックログをスプリントバックログに細分化することは基本的にWBSと似ているが、リズムが一定間隔なことが重要
＜Output＞ • スプリントバックログ （作業タスク） • 作業成果物
プロダクト 検討#3
プロダクト 検討#4
プロダクト 検討#2
設計着手 仕様一次Fix
スプリント #1
スプリント #2
スプリント #3
スプリント #4
プロダクトバックログはスプリントごとに変化がないか確認
リリースされ価値に変化が発生することもありえる
確認するためには品質の高いリリースが重要
Point
プロダクト 検討#1
30
ゴールは固定されるのではなく継続的にふりかえる
ふりかえり ふりかえり ふりかえり ふりかえり
事例
自分たち自身の価値も向上させる
ゴール
•価値をゴールにし、優先順位をコミットする
• リズムとゴールをマッチングさせる
リズム
• プロジェクトを一定間隔のリズムで区切る
• プロジェクトのベロシティを把握する
見える化
• 状況を見えるようにしてリズムを伝播させる
• 変化を受け入れる
自律
• 自分たちでふりかえる
• 自分たちで変えていく
平鍋さんブログ「An Agile Way」より
http://blogs.itmedia.co.jp/hiranabe/2012/09/rightwing-and-leftwing-of-agile.html
アジャイルのレフトウィング
32
スクラムは、経験的プロセス制御の理論（経験主義）を基本にしている。経験主義とは、実際の経験や既知に基づく判断によって知識が獲得できるというものである。スクラムでは、反復的で漸進的な手法を用いて、予測可能性の最適化とリスクの管理を行う。
「スクラムガイド」より © 1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide-JA.pdf
33
スクラムの理論
33
スクラムチームの特徴
スクラムチーム スクラムチームは、プロダクトオーナー・開発チーム・スクラムマスターで構成される。スクラムチームは自己組織化されており、機能横断的である。自己組織化チームは、作業を成し遂げるための最善の策を、チーム外からの指示ではなく、自らが選択する。機能横断的チームは、チーム外に頼らずに作業を成し遂げる能力を持っている。スクラムにおけるチームのモデルは、柔軟性・創造性・生産性に最適化されたものとなっている。
「スクラムガイド」より © 1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide-JA.pdf
34
タイムボックスというリズムの効果
「変わらない時間の測定基準」を使って プロジェクトのパワーを測り引き出していく
35
ジャンプして届くゴールの繰り返し
36
KPTは成長を促すツール
Keepで、チームとしての共感を得る
よかったことを褒めあうと、チームを信頼できる
Problemを共有する
問題を誰かのせいにするのではなく、チームの問題であると認識する
そして、みんなでTry!
誰かがやってくれる、のではなく、自分が、そして誰もがやる！
37
プロジェクトのリズムを使った成長
☞ 定期的に成長するしくみ
– 一定期間の短いリズムでふりかえる
– 習慣にして継続させる
☞ 「歩み」を実感しつづける
– 成長していることは、自信につながる
38
－参－ 価値を描く
最も強い者が生き残るのではなく、
最も賢い者が生き延びるのでもない。
唯一生き残ることが出来るのは、
変化できる者である。
チャールズ・ダーウィン
しかも、自分たちだけでなく、まきこめるかどうかも重要
みなさんが作り出しているものの価値？
システムの機能の利用度
全く使われない45%ほとんど使われな
い19%
たまに使う16%
いつも使う7%
よく使う13%
Standish group study report in 2000 chaos report
システム開発と組込み開発の違い
42
「たまに使う」に意味があったりしませんか？
製品の価値を最大化するには？
43
変化を味方につける（価値の共有）
お客様の価値の最大化を考える 変化は当然（必要）ととらえ、
すばやく変化を取り入れられるように進める
44
変化を味方につける（開発側から）
45
46
アジャイルとは、 お客様のビジネス価値を最大化するための
「考え方」や「姿勢」のこと
変化を受け入れるのではなく
社会に対して変化を生み出していく
47
48
Social Change starts with YOU!!
「未来」を一緒に描き、私たちの手で変化を生み出していきましょう！ 48
ご清聴ありがとうございました
