組込みシステム産業振興機構さまプライベートセミナー(2017/11/02)
TRANSCRIPT
プロジェクト改善のアジャイルから製品の価値を上げるアジャイルへ
~ 組織全体のアジリティをあげるために ~
November 2, 2017 13:00~17:00
株式会社日新システムズ
前川 直也
様
2
『システム開発現場のファシリテーション』(技術評論社)
『これだけは知っておきたい組込みシステムの設計手法』(技術評論社)
『わかりやすいアジャイル開発の教科書』(ソフトバンククリエイティブ
株式会社 日新システムズ未来戦略室 室長
兼 品質保証部 部長 兼 事業戦略部 主査
前川 直也
1994 ~日本コンピューター・システム株式会社
1998 ~パナソニック株式会社
2015 ~株式会社日新システムズ
アジャイル導入・実践
プロジェクトファシリテーション
プロセス改善
産業カウンセリング
アジャイルでお困りの際はお気軽にメールください
ET West 実行委員
@nao_maru
http://www.facebook.com/NaoyaMaekawa
会社概要
社名 株式会社日新システムズ設立 1984年7月2日
売上高 約32億円(2016年度実績)
社員数 213名 (内、エンジニア:151名)
・平均年齢 34歳
・男女比率 男性:178名、女性:35名(女性管理職6名)
事業所 <京都本社>〒600-8482 京都市下京区堀川通綾堀川町293-1
<東京支社>〒101-0024 東京都千代田区神田和泉町1番地
<沖縄開発センター>〒901-0152 沖縄県那覇市字小禄1831番地1
住友電気工業株式会社
3
えるぼし 「女性が働きやすい職場づくり」に取組む企業認定トモニン 仕事と介護を両立できる職場環境の整備促進に取組む企業認定
4
会社概要
5
社長
経理部
総務部
未来戦略室
事業戦略部
E&Eシステム事業部
インダストリアル・ソリューション事業部
ソーシャル・ソリューション事業部
品質保証部
システム開発事業部
Agenda
13:00~13:30 第1部:なぜアジャイルなのか?
13:30~14:50 【ワークショップ】 レゴスプリント
(10分間の休憩)
15:00~15:50 第2部:製品価値をあげるために
(10分間の休憩)
16:00~17:00 第3部:みなさまとディスカッション
明日からのアクションプランを作ろう
7
8
-第1部-なぜアジャイルなのか?
Copyright © 2016 NISSIN SYSTEMS All right reserved
9
ビジネスの世界はどう変る?
10
価値に向き合ってますか?
以前は、狙っていけば的中する確率が高かった
今の組込み業界では、
環境の変化
ユーザニーズの多様化
競合他社との競争激化
などで、先の読めない状況・・・
環境変化
競合
ソフト業界の変化
11
『要求される価値』から『創り出す価値』の時代に突入!
これまでのソフトウェア開発
設 計 テスト実 装
チェック チェック
要求
価値
インプット アウトプット
以前は、決められた要求(機能)を要件に落とし込み計画をほぼ変えることなくものづくりができた時代
「 思い(要求)」がインプットされる
12
日程前倒し
課題/バグ
仕様変更
仕様追加
混沌とした組込み業界において、ソフトウェアの変化が発生しないというのはありえない
変化を前向きに受け入れていく必要がある
ソフトウェア開発に変化はつきもの
13
開発開始段階の課題
14
開発中の課題
コミュニケーションギャップ設計・実装上の都合・納期、等
15
納品時の結果
16
規模が大きくなった弊害
営業→企画→開発→QA→製造などのバトンが複雑化しその分、ドキュメントによるバトンリレーが発生しやすくなるそこに「ギャップ」は発生していないだろうか?
17
短い『タイムボックス』で回しながら細かくフィードバックし、価値を膨らませていく開発スタイル
今求められているソフトウェア開発
「 思い(要求)」から「カタチ(価値)」を作り上げる
18
製品の価値の最大化
19
製品の価値を決めている主要な部門はどこですか?
変化を味方につける(価値の共有)
お客様の価値の最大化を考える変化は当然(必要)ととらえ、
すばやく変化を取り入れられるように進める
20
お客様の「思い(要求)」を真摯に受け止めしかも、お客様と作り手側のコラボレーションによってさらに膨らませていくことで「予想以上の形(価値)」を作り上げていくことを目指す
思いをカタチとして作る
インプットされた通りに作る
お客様との価値のフィードバックを繰り返す
21
変化を味方につける(開発側から)
22
最も強い者が生き残るのではなく、
最も賢い者が生き延びるのでもない。
唯一生き残ることが出来るのは、
変化できる者である。
チャールズ・ダーウィン
メーカーの苦悩
企画部門
ニーズ
エンドユーザ
開発部門
製品仕様
技術
販売
世界のTV市場
製品の価値の最大化を考えるにしても?
25
製品の価値を最大化するために作り手側に何が求められているのか?
IoT市場を牛耳るには?
国内だけでも2019年には16兆円!?
26
世界規模なら5000兆円を超えるという予測も
社会の変化 「ものづくり」から「ことづくり」へ
(出典)総務省「「コトづくり」の動向とICT連携に関する実態調査」(平成25年)
27
新しいコア技術があるわけではなくいかに「こと」視点で組み合わせるか
IoT
クラウド
大規模メーカーにありがちな罠
一つの商品にかかわるステークホルダが多い
大人数の大規模開発になりがち(ソフトウェア子会社も巻き込んで)
ものづくりのステップ移行で重たくなる(必然的なウォーターフォールに?)
品質は重要だがQCDのQが大きくなりすぎる
最終ユーザが求める価値が見えにくい
価値のフローが流れにくくなる
28
企画側(What)製品企画段階で
価値ある要求が発見できない
開発側(How)企画段階で
価値を高める提案ができていない
価値を共有できていないため、開発に無駄が発生
29
変化を味方につけお客様のビジネス価値を最大にするために・・・
30
http://agilemanifesto.org/
31
組込みでの開発の方がアジャイルは向いているといえますただし、なぜアジャイルなのか?(目的)
どんな価値を出すのか?(目標)をより明確にする必要があります
価値の最大化するためのプロセス
32
アジャイルは単に早い・高品質なだけではなく価値を最大化していかなければ元の木阿弥
33
アジャイルとは、お客様のビジネス価値を最大化するための
「考え方」や「姿勢」のこと
スクラムにおけるチームモデル
スクラムチーム
プロダクトオーナー
スクラムマスター
開発チーム
「スクラムガイド」より
https://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-Japanese.pdf
34
プロダクトバックログ
ユーザストーリを集めたもの優先順位を決める
スプリントバックログ
一つのプロダクトバックログをスプリントに落とし込みスプリントバックログを作る
スプリント1 ~ 4 Week
デイリースクラム
スプリントレビュー
動くソフトウェアでレビュー+フィードバック
スプリントレトロスペクティブスプリントごとにふりかえり
開発チーム
プロダクトオーナー
スクラムマスター
開発チームの作業とプロダクトの価値の最大化に責任を持つ
スクラムの理解と成立に責任を持つ
スクラムの流れ
35
わかりやすい アジャイルの『ツボ』
ゴール
• 価値をゴールにし、優先順位をコミットする
• リズムとゴールをマッチングさせる
リズム
• プロジェクトを一定間隔のリズムで区切る
• プロジェクトのベロシティを把握する
見える化
• 動くもの+状況の可視化でリズムを伝播させる
• フィードバックにより変化を取り込む
自律
• 自分たちでふりかえる
• 自分たちで変えていく
1
2
3
4
1
2
3
4
36
①価値をゴールに設定し、コミットする
ゴール
• 価値をゴールにし、優先順位をコミットする
• リズムとゴールをマッチングさせる
リズム
• プロジェクトを一定間隔のリズムで区切る
• プロジェクトのベロシティを把握する
見える化
• 動くもの+状況の可視化でリズムを伝播させる
• フィードバックにより変化を取り込む
自律
• 自分たちでふりかえる
• 自分たちで変えていく
37
プロダクトバックログ
ユーザストーリを集めたもの優先順位を決める
スプリントバックログ
一つのプロダクトバックログをスプリントに落とし込みスプリントバックログを作る
スプリント1 ~ 4 Week
デイリースクラム
スプリントレビュー
動くソフトウェアでレビュー+フィードバック
スプリントレトロスペクティブスプリントごとにふりかえり
開発チーム
プロダクトオーナー
スクラムマスター
開発チームの作業とプロダクトの価値の最大化に責任を持つ
スクラムの理解と成立に責任を持つ
38
開発着手仕様一次Fix
スプリント#1
スプリント#2
スプリント#3
スプリント#4
機器仕様検討
プロダクト検討
関連部署とのコミットメント
設計者の概要見積りをベースにリリース計画(各スプリントの実装要件)
<Output>• プロダクトバックログ
(ストーリー実装リスト)• リリース計画/スプリント計画• その他、関連ドキュメント
ストーリーA:見積り 2ポイントストーリーB:見積り 1ポイントストーリーC:見積り 3ポイント
・・・
39
スプリントのゴール設定
どんな機能を何のために作るのかを決めてリストアップ見積は実施するが、ここで最終まで確定させてしまうわけではない
ストーリーとして描く
http://www.slideshare.net/Ryuzee/ss-8332120
ユーザーストーリーとは?
要求仕様を自然言語で簡潔に記述したもの <役割>として <機能や性能>が出来る それは<ビジネス価値>のためだ
例えば、「グループでキャンプに」行く場合
• テントを設置する• BBQ準備をする• 串焼きを作る
• 風を感じながら寝られる• 全員で肉が焼ける• 取りやすい串焼きにする
スタッフ視点 お客様視点
40
価値を一緒に描き、共有していく
部門の壁を越えて、製品の価値を共有するには一緒に描き、一緒に作り、一緒に確認していく必要がある
41
みなさんがつくっているものの価値はなに?
Quality
Cost
Delivery
Scope
製品の価値を最大化する
44
②一定間隔をリズムを継続させる
ゴール
• 価値をゴールにし、優先順位をコミットする
• リズムとゴールをマッチングさせる
リズム
• プロジェクトを一定間隔のリズムで区切る
• プロジェクトのベロシティを把握する
見える化
• 動くもの+状況の可視化でリズムを伝播させる
• フィードバックにより変化を取り込む
自律
• 自分たちでふりかえる
• 自分たちで変えていく
45
プロダクトバックログ
ユーザストーリを集めたもの優先順位を決める
スプリントバックログ
一つのプロダクトバックログをスプリントに落とし込みスプリントバックログを作る
スプリント1 ~ 4 Week
デイリースクラム
スプリントレビュー
動くソフトウェアでレビュー+フィードバック
スプリントレトロスペクティブスプリントごとにふりかえり
開発チーム
プロダクトオーナー
スクラムマスター
開発チームの作業とプロダクトの価値の最大化に責任を持つ
スクラムの理解と成立に責任を持つ
46
ゴールを使ってリズムをつくる
設計基本のV字モデルをキープしながらいつまでに、何を、どう作るのか
ゴールを明確にして、一定期間のサイクルで回す
ゴールを分割して、プロセスの流れを作る
47
要求分析
詳細設計
実装
基本設計 結合・機能テスト
単体テスト
システムテスト
開発着手 完成仕様一次Fix
スプリント#1
スプリント#2
スプリント#3
スプリント#4
1~2 week
スプリント計画
2日程度の粒度のタスクで開発実施
成果レビューふりかえり
機能ごとにV字モデルを回す感じ
49
一定間隔のリズムで区切る
プロダクトバックログをスプリントバックログに細分化することは基本的にWBSと似ているが、リズムが一定間隔なことが重要
<Output>• スプリントバックログ
(作業タスク)• 作業成果物
③常に状況を見えるようにして変化へ対応する
ゴール
• 価値をゴールにし、優先順位をコミットする
• リズムとゴールをマッチングさせる
リズム
• プロジェクトを一定間隔のリズムで区切る
• プロジェクトのベロシティを把握する
見える化
• 動くもの+状況の可視化でリズムを伝播させる
• フィードバックにより変化を取り込む
自律
• 自分たちでふりかえる
• 自分たちで変えていく
50
プロダクトバックログ
ユーザストーリを集めたもの優先順位を決める
スプリントバックログ
一つのプロダクトバックログをスプリントに落とし込みスプリントバックログを作る
スプリント1 ~ 4 Week
デイリースクラム
スプリントレビュー
動くソフトウェアでレビュー+フィードバック
スプリントレトロスペクティブスプリントごとにふりかえり
開発チーム
プロダクトオーナー
スクラムマスター
開発チームの作業とプロダクトの価値の最大化に責任を持つ
スクラムの理解と成立に責任を持つ
51
様々な見える化により透明性を実現する
52
製品品質を継続的に確かめ、価値をあげる
スプリントごとに価値をフィードバックするには?
価値が確認できるレベルに動作していること
シンプルに設計し、リファクタリングができること
今必要としていないものをムダに作りこまないこと
デバイスドライバ
ライブラリ
アプリケーション
レイア単位ではなく
ファンクション単位で
53
Doneの定義
ストーリへの「完了条件を定義してない」「共有していないこと」がズレの始まりに・・・
どんなテストを完了していますか?
レビューは完了していますか?
お客様視点で動作できますか?
『Doneの定義』を明確に!
54
技術品質を継続的にキープする
• コーディングミスが発生しにくい
• コーディングでの誤り混入から発見までの時間が短い(数分~数10分程度)
• コードの可読性が向上する
55
スプリント
デイリースクラム
テスト駆動開発(Test Driven Development)
ペアプログラミング
• コードがきれいになる(レビュー率100%)
• システムやコード、ツールなどの知識を共有できる
• ペアの組み方によっては、トレーニングの効果を得られる
• コミュニケーションが活発になり一体感を生み出す
• 1人で悩んで停止しまうことが少なくなり作業が着実に進む
コードの共同所有
その他にもノウハウはたくさん作るもの、プロジェクトに合わせ自分たちでプラクティスを活用していく
④自分たち自身の価値も向上させる
ゴール
•価値をゴールにし、優先順位をコミットする
• リズムとゴールをマッチングさせる
リズム
• プロジェクトを一定間隔のリズムで区切る
• プロジェクトのベロシティを把握する
見える化
• 動くもの+状況の可視化でリズムを伝播させる
• フィードバックにより変化を取り込む
自律
• 自分たちでふりかえる
• 自分たちで変えていく
56
プロダクトバックログ
ユーザストーリを集めたもの優先順位を決める
プロダクトバックログ
一つのプロダクトバックログをスプリントに落とし込みスプリントバックログを作る
スプリント1 ~ 4 Week
デイリースクラム
スプリントレビュー
動くソフトウェアでレビュー+フィードバック
スプリントレトロスペクティブスプリントごとにふりかえり
開発チーム
プロダクトオーナー
スクラムマスター
開発チームの作業とプロダクトの価値の最大化に責任を持つ
スクラムの理解と成立に責任を持つ
57
平鍋さんブログ「An Agile Way」よりhttp://blogs.itmedia.co.jp/hiranabe/2012/09/rightwing-and-leftwing-of-agile.html
アジャイルのレフトウィング
58
ソフト業界 約60年の歴史
ソフトウェアが商業ベースになりそれにつれて、工学的にアプローチ
『誰でも同じように作れるソフトウェア』
2000年頃から、もう一度初心に戻り新たなアプローチが始まる
『ソフトウェアは人が作るものである』
59
どちらがエンジニアを活かせますか?
60
人にフォーカスする
What How
Who Where/When
人にフォーカスしたアジャイルだからこそ
「ものづくり」から「ことづくり」アプローチに変えやすいはず61
スクラムは、経験的プロセス制御の理論(経験主義)を基本にしている。経験主義とは、実際の経験や既知に基づく判断によって知識が獲得できるというものである。スクラムでは、反復的で漸進的な手法を用いて、予測可能性の最適化とリスクの管理を行う。
「スクラムガイド」よりhttps://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-Japanese.pdf
62
スクラムの理論
62
スクラムチームの特徴
スクラムチームスクラムチームは、プロダクトオーナー・開発チーム・スクラムマスターで構成される。スクラムチームは自己組織化されており、機能横断的である。自己組織化チームは、作業を成し遂げるための最善の策を、チーム外からの指示ではなく、自らが選択する。機能横断的チームは、チーム外に頼らずに作業を成し遂げる能力を持っている。スクラムにおけるチームのモデルは、柔軟性・創造性・生産性に最適化されたものとなっている。
「スクラムガイド」よりhttps://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-Japanese.pdf
63
トップダウン or ボトムアップ?
トップダウン型マネジメント
経験・ノウハウが受け継がれる
メンバがやるべきことがわかりやすい
経験がかえって邪魔になることも
メンバが考えなくなってしまうリスク
ボトムアップ型マネジメント
メンバ自身が考えて・工夫する
知識の共有が実現しやすい
クローズ化してしまうと逆効果
ビジョンの共有が不可欠
どちらも重要ですが、違いを使いこなしていますか?
64
【X理論】人間は生来怠け者で、できれば働きたくない強制されたり命令されなければ仕事をしない
【Y理論】生まれながらに嫌いということはなく、働くことは人間の本性条件次第で責任を受け入れ、自ら進んで責任を取ろうとする問題解決のための創意工夫をこらす能力は誰でも持っている
ダグラス・マクレガーのX理論Y理論
人間観・動機づけにかかわる2つの対立的な理論
or
65
サーバント型リーダシップ(支援型リーダシップ)
メンバのために「管理・命令」し、チームやプロジェクトを運営するスタンスのリーダではなく
メンバを「信頼・支援」し、チームやプロジェクトの「成功・成長」のために奉仕するリーダ
コミュニケーションを重視しながら、一人ひとりの思いと行動により目標を達成する
ロバート・グリーンリーフ(米:1904~1990)が1970年に提唱
66
対立構図から「問題対私たち」へ
67
KPTは成長を促すツール
Keepで、チームとしての共感を得る
よかったことを褒めあうと、チームを信頼できる
Problemを共有する
問題を誰かのせいにするのではなく、チームの問題であると認識する
そして、みんなでTry!
誰かがやってくれる、のではなく、自分が、そして誰もがやる!
68
プロジェクトのリズムを使った成長
☞ 定期的に実施する
– 続けるためには、習慣にしてしまう
– 一定期間の短いリズムでふりかえる
☞ 「歩み」を実感しつづける
– 成長していることは、自信につながる
69
ジャンプして届くゴールの繰り返し
70
タイムボックスというリズムの効果
「変わらない時間の測定基準」を使ってプロジェクトのパワーを測り引き出していく
71
72
アジャイルとは、お客様のビジネス価値を最大化するための
「考え方」や「姿勢」のこと
73
アジャイル宣言の背後にある原則
私たちは以下の原則に従う:
顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
http://www.agilemanifesto.org/
74
情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
動くソフトウェアこそが進捗の最も重要な尺度です。
アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
シンプルさ(ムダなく作れる量を最大限にすること)が本質です。
最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
http://www.agilemanifesto.org/
キーワードは「自己組織化」
Do Agile
Agility
変化を受け入れるのではなく
社会に対して変化を生み出していく
組込みだから、アジャイルっしょ。
77
実践こそがアジャイル!
価値について考える
お客様はだれ?
ユーザーにとっての価値は?
考える習慣、意識を継続
まずは簡単なことからでもOKとにかく実践してみる!
ワークショップ
79
レゴスプリント
80
やってみないとアジャイルはわからない!
メンバーで最終ゴールをイメージする
レゴスプリント
レゴを使ったグループワーク
『最高の飛行機を作ってください!』
82
このグループで・・・
どんな最高の飛行機つくる?
5分
83
ビジネスゴールを常に意識した開発
プロジェクトメンバーと最終形態を一緒に描くことで、プロジェクトの基礎固めができる
ゴールを共有できてるかどうかはプロジェクトに大きく影響する
グループワークからのポイント
84
みんなで描いたゴールをもとに
「タスクをピックアップ」
5分
レゴ飛行機は約10分×2回で開発します!2回とも(完成)させます
85
グループワークからのポイント
みんなで考えること
みんなの得意分野は何?
計画段階はイメージ力が重要
短いサイクルでの繰り返し開発には工夫が必要86
ソフトウェアかんばん
ToDo未実施
Doing実施中
Done完了
サザエ
カツオ
ワカメ
【使い方】
① カードを未実施に貼る
② 実施する前に実施中にカードを移動する
③ タスクが完了したら完了に移動する ※ 貼りかえはリアルタイムに
87
KPTはプロセスを適応させるツール
Keepで、チームとしての共感を得る
よかったことを褒めあうと、チームを信頼できる
Problemを共有する
問題を誰かのせいにするのではなく、チームの問題であると認識する
そして、みんなでTry!
誰かがやってくれる、のではなく、自分が、そして誰もがやる!
88
グループワークからのポイント
ほめると伸びる+欠点も認める
行動(スイッチ)につながる
「人」に視点を置くからこそ「成長」もできる89
『最高の飛行機」を作ってください!
10分×2回
10分×2スプリント
朝会+タスクの確認(1分)
グループ作業(6分)
KPT(3分)
KPTの「ふりかえり」は2回目に反映!
かんばんも活用してください
ご完成おめでとうございます
プロジェクト改善のアジャイルから製品の価値を上げるアジャイルへ
-第2部-製品価値をあげるために
論文“The New New Product Development Game”(竹内弘高・野中郁次郎『ハーバード・ビジネス・レビュー』1986年)
アジリティの考えは、従来の米国製造業が限界を認識し、それを越えようとしていた時期に生まれてきました。つまり、製造業はもはやハードのみの生産者でなく、ソフト、サービスを融合した価値を提供する、あらたな存在を目指すべきである、と。そうでない限りグローバルな競争環境において生存不能だ、という認識です。こうした認識にもとづいて、ハード中心だったコンピュータ業界がソリューションなどのソフト、サービス指向へと変身し、消費者向け製品でもマス・カスタム化(顧客の注文による生産。ワン・トゥ・ワン・マーケティングもこの一種)が重要な考え方となりました。『知識経営のすすめ -ナレッジマネジメントとその時代』 野中 郁次郎/紺野登 1999年12月20日 第1
版
スクラムが生まれたきっかけ
富士ゼロックスキャノンホンダNECの事例から分析
95
ものづくり日本の
失われた20年?日本アジャイルの15年
96
97
ことづくりとは、単に優れた製品を作るだけでなく、コンセプトやストーリー、ユーザーエクスペリエンスなどの高い付加価値が込められた製品を作ること、そのような付加価値を創出すること、あるいは、優れた製品を生み出すための活力となり得る夢や目標を設けることである。
Weblio辞典 IT用語辞典より抜粋
価値 ストーリー
99
アジャイルとはお客様のビジネス価値を最大化するための
「考え方」や「姿勢」
ビジネスのためのアジャイルへ
組込みソフトウェアの環境変化
第一次:ソフトウェア規模増大
第二次:価値向上のためのソフトウェア
Agility
変化を受け入れるのではなく
社会に対して変化を生み出していく
デザイン思考
リーンスタートアップ
エコシステム
アジャイル
日本のソフトウェア業界の構図
自分たちの考える価値を思った通りに作ってくれる
高品質だけど、できれば安く(お客様の業績次第)
日本ではかかった時間にお金を支払うことが多く、工数で見積
ごくまれに機能を提案してくれる
継続的に付き合ってくれる
これまでのソフトウェア開発
受託
発注
何を作りたいかはお客様が決められる
狙ったものを狙った通りに撃ち落とすことができる時代
受託
開発
Quality
CostDelivery
QCDを意識して求められるものを作りだす
開発企業に求められるもの
メーカーSIerゼネコンetc.
組込みソフトウェアハウス
105
自分たちが成功できる価値を一緒に考え、作りだしてくれる
いらないものをいらないと言ってくれる(価値の優先度判断)
高品質かつ、想定以上のものを迅速に届けてくれる
ビジネスで成功する価値に対する対価として予算を決めてくれる
頼りになるビジネスパートナー
これからのソフトウェア開発
協調
何を作りたいかをお客様も悩んでいる
狙うもの自体を定めることが難しい時代
ソリュー
ション
Quality
Cost
Delivery
Scope
QCD+Scopeを意識してお客様のビジネス価値を
最大限に引き出すことができる
開発企業に求められるもの
IoTクラウド
組込みソフトウェアハウス
メーカーSIerゼネコンetc.
106
エコシステムズ
ビジネスのためのアジャイルに
必要な4つのデザイン
107
価値のデザイン
(ストーリー)
作り方のデザイン
(リズム)
チームのデザイン
(リスペクト)
品質のデザイン(価値の保証)
価値をデザインする
110
お客様のビジネス価値を最大化すると同時に自分たち自身の価値を最大化していく!
価値を感じる感性を高めていく
社会の・・・価値
お客様の・・・
自分たちの・・・
111
Biz/Zine https://bizzine.jp/今週中には第一回目が掲載開始予定
意志をブランドにして伝えるArchBRANDING~匠Methodによるビジネスデザイン~
「関西匠塾」定期的に開催中!
作り方をデザインする
113
アジャイルの3つの芯
開発チーム
プロダクト
オーナー
スクラム
マスター
何のために何をつくるかゴールを描き共有する
一つのチームとして連携
リズムを共有させてチームの動きを一つにし相互作用を引き出す
自分たちが作るもの自分たち自身に愛着がありそのために力を注げる
※『信』は「アジャイルの魂」で!
114
ゴール
プロダクトの価値は何ですか?
企業・部門の価値は何ですか?
目指す価値を明確にしベクトルを合わせる
115
リズム
プロジェクトの力を伝搬させる
企業・部門の力を伝搬させる
スモールステップアップでメンバのパワーを
引き出す
116
愛
作るもの作り出すチームに
愛着を持つ
所属して良かったと思える
組織・部門
リスペクトすることが全てのパワーにつながる
チームをデザインする
118
スクラムチームは、プロダクトオーナー・開発チーム・スクラムマスターで構成される。スクラムチームは自己組織化されており、
機能横断的である。自己組織化チームは、作業を成し遂げるための最善の策を、チーム外からの指示ではなく、自らが選択する。機能横断的チームは、
チーム外に頼らずに作業を成し遂げる能力を持っている。スクラムにおけるチームのモデルは、柔軟性・創造性・生産性に最適化されたものとなっている。
「スクラムガイド」より
スクラムチーム
組織・チーム・プロジェクト・メンバの未来の価値を描く119
組織の壁をストーリーでつなげていく
品質をデザインする
122
DevQA
Agile RCA
キーワードは「自己組織化」
Do Agile
日本のものづくりを「ことづくり」に変えたい!
宮本武蔵像(島田美術館蔵熊本県指定重要文化財)
一気通貫アジャイル
名刺交換お待ちしております!
Social Change starts with YOU!!
あなたが動くと、チームが、組織が、そして社会が変わる
ご清聴ありがとうございました