PMAJ関西 様【第123回関西例会】

プロダクト、プロジェクトともに価値をあげられるからアジャイル～ 価値をフィードバックし続けるアジャイルの本質 ～October 9, 2015
株式会社日新システムズ
未来戦略室 室長前川直也

Agenda1. いまどきのプロマネ？

2. ソフトビジネスの変化
3. プロダクトの価値を創る

4. プロジェクトの価値を創る
5. アジャイルになる！
2

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

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

CM3

－壱－
いまどきのプロマネ？

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

トップダウン型マネジメント

ボトムアップ型マネジメント

 経験・ノウハウが受け継がれる メンバがやるべきことがわかりやすい メンバ自身が考えて・工夫する 知識の共有が実現しやすい 経験がかえって邪魔になることも メンバが考えなくなってしまうリスク

 クローズ化してしまうと逆効果 ビジョンの共有が不可欠

どちらも重要ですが、違いを使いこなしていますか？
5

ダグラス・マクレガーのＸ理論Ｙ理論
人間観・動機づけにかかわる2つの対立的な理論【X理論】
人間は生来怠け者で、できれば働きたくない
強制されたり命令されなければ仕事をしない

or

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

サーバント型リーダシップ（支援型リーダシップ）

メンバのために「管理・命令」し、チームやプロジェクトを運営するスタンスのリーダではなくメンバを「信頼・支援」し、チームやプロジェクトの「成功・成長」のために奉仕するリーダ
コミュニケーションを重視しながら、一人ひとりの思いと行動により目標を達成する
ロバート・グリーンリーフ（米：1904～1990）が1970年に提唱

7プロジェクトは何のためにあるの？

8

 What 何を作りたいのか？
 Who

誰が作るのか？誰と作るのか？

 When いつまでに作るのか？
 Where どのような環境で？

 How

どうやって？
どんな技術？どんなプロセス？

プロジェクトは何のために存在し、なぜ自分たちがそこにいるのか Why
なぜ作らなければならないのか？

プロジェクトが成功すれば未来にどんな価値が描ける？

8

マズローによる欲求階層

自己実現
尊敬（承認）
所属と愛情
安全
生理的欲求
9

10

ほんとうの「Why」!?
企業・組織としてのWhy– 利益をあげねば– 競合他社に勝つ– 生産性をあげる– 高品質な商品

個人としてのWhy Why
なぜ作らなければ– リーダとしての成功– 新しい技術を得る– 自分の時間を作る– 残業しても高収入ならないのか？

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

趣味
家族

ゲーム
スポーツ
仕事

勉強やりたい！につながる「Why」になってますか？
10ビジネスで成功

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

業績アップ

企業・組織としてのWhy

自己成長
チーム成長
自分の時間

Why?

個人としてのWhy

あせり・指示やらされ感Command Control

思考停止
成長停止
11－弐－
ソフトビジネスの変化
12ソフト業界の変化

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

今のソフト業界では、環境の変化
ユーザニーズの多様化
競合他社との競争激化などで、先の読めない状況・・・

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

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

価値
要求インプットチェック

設 計

実 装チェック

アウトプットテスト

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

14開発開始段階の課題

15

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

日程前倒し

仕様変更

課題／バグ仕様追加

混沌としたソフト業界において、ソフトウェアの変化が発生しないというのはありえない変化を前向きに受け入れていく必要があるのだが・・・
16

開発中の課題

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

納品時の結果18

ソフト業界 約60年の歴史

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

2000年頃から、もう一度初心に戻り新たなアプローチが始まる『ソフトウェアは人が作るものである』

19

人にフォーカスする

WhatWhoHow

Where ／ When
20

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

21

スクラムが生まれたきっかけ

富士ゼロックスキャノン
ホンダ
NECの事例から分析

論文“The New New Product Development Game”（竹内弘高・野中郁次郎『ハーバード・ビジネス・レビュー』1986年）

アジリティの考えは、従来の米国製造業が限界を認識し、それを越えようとしていた時期に生まれてきました。つまり、製造業はもはやハードのみの生産者でなく、ソフト、サービスを融合した価値を提供する、あらたな存在を目指すべきである、と。そうでな
い限りグローバルな競争環境において生存不能だ、という認識です。こうした認識にもとづいて、ハード中心だったコンピュータ業界がソリューションなどのソフト、サービス指向へと変身し、消費者向け製品でもマス・カスタム化（顧客の注文による生産。ワン・トゥ・ワン・マーケティングもこの一種）が重要な考え方となりました。
『知識経営のすすめ －ナレッジマネジメントとその時代』 野中 郁次郎／紺野 登1999年12月20日 第1版

22

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

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

システム・製品の価値の最大化を考えるシステムや製品の価値を決めている主要な部門はどこですか？

24

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

－弐－
プロダクトの価値を創るhttp://agilemanifesto.org/

アジャイル開発はあたりまえになりつつあります
ただし、なぜアジャイルなのか？（目的）どんな価値を出すのか？（目標）をより明確にしなければ・・・
27

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

28

アジャイルとは？

アジャイルとは、お客様のビジネス価値を最大化するための「考え方」や「姿勢」のこと

29

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

スクラムチーム
プロダクトオーナー

スクラム
マスター

開発チーム

自己組織化チームは、作業を成し遂げるための最善の策を、チーム外からの指示ではなく、自らが選択する「スクラムガイド」より© 1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved
https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide-JA.pdf

30

スクラムの流れ

プロダクトオーナー

スクラム
マスター

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

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

プロダクトバックログ
ユーザストーリを集めたもの
優先順位を決める

開発
チーム

デイリー
スクラム

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

スプリントプランニング

スプリントレビュー

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

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

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

31

アジャイルの3つの要素とスクラムでのロール

オ プーロ
ナダーク
トAgile

何のために何をつくるかゴールを描き共有する

リズムを共有させてチームの動きを一つにし相互作用を引き出す

自分たちが作るもの
自分たち自身に愛着がありそのために力を注げる

一つのチームとして
連携

マ ス
ス ク
タ ラーム

開発
チーム

アジャイルを導入する前に・・・[チェックポイント] プロジェクトにエンジニアリング＆プロセスの基本スキルはどのぐらい？
 メンバが風土を変えるぐらいの改善意欲を持っていますか？
 自分たちが作っているものに愛着を持っていますか？
• お客様が何を求めているのか考えてる？

 改善指標を数値だけで判断していませんか？
• コミュニケーションは活発？

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

33

わかりやすい アジャイルの『ツボ』
1• 価値をゴールにし、優先順位をコミットする

1

ゴール
2

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

リズム

3
2

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

3• プロジェクトのベロシティを把握する• 動くもの＋状況の可視化でリズムを伝播させる

見える化
4• フィードバックにより変化を取り込む• 自分たちでふりかえる

4

自律• 自分たちで変えていく34

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

ゴール• リズムとゴールをマッチングさせる• プロジェクトを一定間隔のリズムで区切る

リズム• プロジェクトのベロシティを把握する• 動くもの＋状況の可視化でリズムを伝播させる

見える化 • フィードバックにより変化を取り込む• 自分たちでふりかえる

自律• 自分たちで変えていく35

プロダクト
オーナー

スクラム
マスター

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

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

プロダクトバックログ
ユーザストーリを集めたもの
優先順位を決める

開発
チーム

デイリー
スクラム

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

スプリントプランニング

スプリントレビュー

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

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

スプリント
レトロスペクティブ
スプリントごとにふりかえり36システム開発と製品開発の価値のありかの違い「たまに使う」に意味があったりしませんか？
システムの機能の利用度

いつも使う
7%
よく使う
13%

たまに使う
16%
ほとんど使われない
19%

全く使われない45%

Standish group study report in 2000 chaos report37

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

開発部門

企画部門

技術ニーズ
製品仕様

販売

世界のTV市場
エンドユーザ

製品の価値を最大化するために作り手側に何が求められているのか？
38これだとどう思いますか？

1. 世界初 4Kミラーレス一眼
2. 他社に負けないAFスピード
3. 動画プロフェッショナル対応※実際のコンセプトとは違います39

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

お客様の価値の最大化を考える
変化は当然（必要）ととらえ、すばやく変化を取り入れられるように進める40

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

41

価値を最大化するには？

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

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

なぜ作るのか？

What

スプリント
#0

何を作るのか？

How

どうやって作るのか？

仕様
一次Fix

When

スプリント
#1

いつまでに作るのか？

Who

スプリント
#2
スプリント
#3

Who

だれが作るのか？
どこで作るのか？

・・・・
全機能実装版

スプリント#n43

ゴールとリズムをつくる

設計基本のV字モデルをキープしながらいつまでに、何を、どう作るのかゴールを明確にして、一定期間のサイクルで回す

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

44

要求分析

システムテスト

基本設計

結合・機能テスト

詳細設計

単体テスト

実装

従来のプロセスとの違い

46

ゴールへのコミットメント形成
 ゴールをシミュレーションし、自分たちがコミットする
設計着手
仕様一次Fix

機器仕様
検討

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

プロダクト詳細シート

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

リリース
スプリント

ゼブラパターンを表示する

プロダクト
検討

要件番号 14A4079
企画優先度
A
主担当U
推進L

REC

難易度

B

どんな人が？
どんな目的（どんな気持ちで）こうなる機能プロの動画カメラマン（静止画カメラマンの一部も含む）
撮影対象の中に、白トビが発生していないかをリアルに確認する
ライブビュー、撮影中も確認できる
再生中は表示されない
設定した値以上の白が表示されている部分が、ライブビュー出力中に白黒縞々のパターンでマーキングされる（LCD、LVF、HDMI、外部モニターなどすべて）

事例
オ プーロ
ナダーク
トマ スス クタ ラームフィード
バック開発チーム

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

ご参考

【お客様は誰？】① フォーマットに合わせて、みんなでディスカッションをしてみましょう② 「お客様は誰ですか？」は、名前など特定できればOK③ 「どんな人ですか？」「求めているものはどんなもの？」を具体化していきましょう④ １人だけとは限りません
いろいろなパターンを考えてみましょう
48

ご参考

【お客様のハッピー】① 「お客様は誰？」の結果を書きましょう② お客様はどんなことをやってみたいと思っていますか？
求めているものは？
③ みなさんがつくり出すもので、どんなことが実現できますか？

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

49

ご参考

【ストーリーテラー】① フォーマットに合わせて、シンプルに書いてみましょう② 結果をもとに具体的なディスカッションにつなげてみましょう

50スプリントとゴールのマッチング（見積）
設計着手
仕様一次Fix

機器仕様
検討＜Output＞関連部署とのコミットメント
設計者の概要見積りをベースにリリース計画（各スプリントの実装要件）

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

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

スプリント
#1

スプリント
#2

スプリント
#3

スプリント
#4

各ストーリはチーム全員で見積を実施し実現可能かどうかを見極める
51

②一定間隔をリズムを継続させる• 価値をゴールにし、優先順位をコミットする

ゴール• リズムとゴールをマッチングさせる• プロジェクトを一定間隔のリズムで区切る

リズム• プロジェクトのベロシティを把握する• 動くもの＋状況の可視化でリズムを伝播させる

見える化 • フィードバックにより変化を取り込む• 自分たちでふりかえる

自律• 自分たちで変えていく52

プロダクト
オーナー

スクラム
マスター

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

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

プロダクトバックログ
ユーザストーリを集めたもの
優先順位を決める

開発チーム

デイリースクラム

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

スプリントプランニング

スプリントレビュー

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

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

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

53

ストーリをさらに細かいタスクに細分化する

全機能実装版

設計着手
仕様一次Fix

スプリント
#1

スプリント
#2

スプリント
#3

＜Output＞

1～2 week
スプリント
計画

スプリント
#4

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

成果レビュー
ふりかえり• スプリントバックログ（作業タスク）• 作業成果物

ストーリごとにV字モデルを回す

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

品質を継続的にキープするためにテスト駆動開発

デイリー
スクラム

（Test Driven Development）• コーディングミスが発生しにくい• コーディングでの誤り混入から発見までの時間が短い（数分～数10分程度）• コードの可読性が向上する

コードの共同所有

ペアプログラミング
スプリント• コードがきれいになる（レビュー率100％）• システムやコード、ツールなどの知識を共有できる• ペアの組み方によっては、トレーニングの効果を得られる• コミュニケーションが活発になり一体感を生み出す• 1人で悩んで停止しまうことが少なくなり作業が着実に進む

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

スプリント
#1

スプリント
#2

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

スプリント
#3

スプリント
#4

・・・・

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

一つのストーリ（要件でもあり、ファンクションでもある「実現すべき価値」）を日程や規模、ページ数などではなく設計、レビュー、テストなど全ての作業を合わせた『ストーリーポイント』として見積る（画像提供：楽天株式会社 さま）

56

③常に状況を見えるようにして変化へ対応する• 価値をゴールにし、優先順位をコミットする
ゴール• リズムとゴールをマッチングさせる• プロジェクトを一定間隔のリズムで区切るリズム• プロジェクトのベロシティを把握する• 動くもの＋状況の可視化でリズムを伝播させる
見える化• フィードバックにより変化を取り込む• 自分たちでふりかえる
自律• 自分たちで変えていく57

プロダクト
オーナー

スクラム
マスター

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

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

プロダクトバックログ
ユーザストーリを集めたもの
優先順位を決める

開発
チー
ム

デイリー
スクラム

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

スプリントプランニング

スプリントレビュー

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

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

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

58

価値の最大化するためのフィードバック

アジャイルは単に早い・高品質なだけではなくフィードバックにより価値を最大化していかなければ効果がない
59

実際にうごくもので価値を確認する

 スプリントごとに価値をフィードバックするには？
価値が確認できるレベルに動作していること
シンプルに設計し、リファクタリングができること
今必要としていないものをムダに作りこまないこと

ライブラリ
デバイスドライバ

ファンクション単位でアプリケーション

レイア単位ではなく
60

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

かんばん

バーンダウンチャート

にこにこカレンダー
61

プロジェクトの見える化

Redmineでのチケット駆動開発
ゴールごとのチケット完了状況の確認

進捗確認

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

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

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

設計着手
仕様一次Fix

プロダクト
検討#1

プロダクト
検討#2

スプリント
#1
ふりかえり

プロダクト
検討#3

スプリント
#2
ふりかえり

プロダクト
検討#4

スプリント
#3
ふりかえり

スプリント
#4
ふりかえり

動くもの（見えるもの）を作り上げ、価値を確認することで次のスプリントにフィードバックさせていく
63

－参－
プロジェクトの価値を創る

野中先生提唱のSECIモデル
身体・五感を駆使、直接経験を通じた暗黙知の共有、創出

対話・思慮による概念・デザインの創造（暗黙知の形式知化）

形式知を行動・実践のレベルで伝達、新たな暗黙知として理解・学習

形式知の組み合わせによる新たな知識の創造（情報の活用）I = 個人G = 集団O = 組織E = 環境66

スクラムの理論

スクラムは、経験的プロセス制御の理論（経験主義）を基本にしている。
経験主義とは、実際の経験や既知に基づく判断によって知識が獲得できるというものである。スクラムでは、反復的で漸進的な手法を用いて、予測可能性の最適化とリスクの管理を行う。
「スクラムガイド」より© 1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved
https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-GuideJA.pdf

6767

スクラムチームの特徴スクラムチーム
スクラムチームは、プロダクトオーナー・開発チーム・スクラムマスターで構成される。スクラムチームは自己組織化されており、機能横断的である。自己組織化

チームは、作業を成し遂げるための最善の策を、チーム外からの指示ではなく、自らが選択する。機能横断的チームは、チーム外に頼らずに作業を成し遂げる能力を持っている。スクラムにおけるチームのモデルは、柔軟性・創造性・生産性に最適化されたものとなっている。
「スクラムガイド」より© 1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved
https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide-JA.pdf

68

④自分たち自身の価値も向上させる• 価値をゴールにし、優先順位をコミットする
ゴール• リズムとゴールをマッチングさせる• プロジェクトを一定間隔のリズムで区切る
リズム• プロジェクトのベロシティを把握する• 動くもの＋状況の可視化でリズムを伝播させる
見える化• フィードバックにより変化を取り込む• 自分たちでふりかえる
自律• 自分たちで変えていく69

プロダクトオーナー

スクラム
マスター

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

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

プロダクトバックログ
ユーザストーリを集めたもの
優先順位を決める

開発チームデイリースクラム

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

スプリントプランニング

スプリントレビュー

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

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

スプリント
レトロスペクティブ
スプリントごとにふりかえり70アジャイルのレフトウィング

平鍋さんブログ「An Agile Way」より
http://blogs.itmedia.co.jp/hiranabe/2012/09/rightwing-and-leftwing-of-agile.html

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

時代にどう合わす？

【2000～02】
ペアプロ
TDD

反復特有の技術アップ

設計技術をどう回す？

Agile
アジャイル開発

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

ビジネスとしてとらえる【2007～】
要求開発
ビジネスアジャイル

人に向き合う！
チームビルディングPM【2005～】【2002～】
コーチング
ファシリテーション

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

トヨタ生産方式
アジャイルの変遷とプロジェクトファシリテーション

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

価値原則

プラクティス
朝会

コミュニケーション
行動
気づき
信頼関係
笑顔

見える化
リズム

かんばん
KPT
ペアボード

名前付け

ニコカレ

問題vs.私たちの構図

アイスブレイク

カイゼン

MindMap

偏愛マップ

etc.
73

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

74

75

75

76

76

Doneの定義

 ストーリへの「完了条件を定義してない」「共有していないこと」がズレの始まりに・・・ どんなテストを完了していますか？
 レビューは完了していますか？
 お客様視点で動作できますか？

一つひとつのゴールもずれていないか
きちんと定義して共有する
77

チームのコミットメント

コミットメントは個人の目的を、チームの目標達成に融合させて最大のパフォーマンスを発揮するためのもの
メンバー全員が共通のゴールに向けて進んでいる
効果的な協同作業を行うためのプロセスをつくるか選び、活用する

成果物やプロセスは素早いフィードバックで常に改善していく
78タイムボックスというリズムの効果「変わらない時間の測定基準」を使ってプロジェクトのパワーを測り、引き出していく79

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

80

KPTは成長を促すツール Keepで、チームとしての共感を得る
よかったことを褒めあうと、チームを信頼できる Problemを共有する問題を誰かのせいにするのではなく、チームの問題であると認識する

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

81プロジェクトのリズムを使った成長☞ 定期的に成長するしくみ– 一定期間の短いリズムでふりかえる– 習慣にして継続させる☞ 「歩み」を実感しつづける– 成長していることは、自信につながる82

－四－アジャイルになる！

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

トップダウン

ボトムアップ

リファクタリング

サインアップ
ペアプロ
ニコカレ

KPT
チームの活動を引き出す

プランニングポーカー

TDD

朝会

見える化と改善

チケット駆動開発
84

アジャイルとは、お客様のビジネス価値を最大化するための「考え方」や「姿勢」のこと

85

「みんな違ってみんないい」金子みすず「わたしと小鳥と鈴と」より一人ひとりが、いろいろな「文化」を背負っています

地域の文化組織の文化

個人の文化一人ひとり違ったメンバを信頼できていますか？
86自分を開いて伝えよう！
相手を知りながら自分自身を知ってみよう！

87

成長を続けることでプロジェクトの価値をアップ

 自分たちを成長させていく 成長を感じることでより活発化していく プロジェクト自体が「自律」しはじめる！
 自律しながら「自分たちの道」を探す

プロジェクト価値をアップすることがアジャイルの最大メリット88

Do Agile

キーワードは「自己組織化」

変化を受け入れるのではなく社会に対して変化を生み出していく

90