組込みシステム産業振興機構さまプライベートセミナー（2017/11/02）
•
1 gefällt mir•676 views
組込みシステム産業振興機構（ESIP）さま 第２回プライベートセミナー（大阪） プロジェクト改善のアジャイルから、製品の価値を上げるアジャイルへ ～ 組織全体のアジリティをあげるために ～ http://www.kansai-kumikomi.net/schedule/info/2017/171102.html?20171017
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (17)
Ähnlich wie 組込みシステム産業振興機構さまプライベートセミナー（2017/11/02）
Ähnlich wie 組込みシステム産業振興機構さまプライベートセミナー（2017/11/02） (20)
Mehr von Naoya Maekawa
Mehr von Naoya Maekawa (12)
Kürzlich hochgeladen
組込みシステム産業振興機構さまプライベートセミナー（2017/11/02）
- 1. プロジェクト改善のアジャイルから 製品の価値を上げるアジャイルへ ～ 組織全体のアジリティをあげるために ～ November 2, 2017 13:00～17:00 株式会社日新システムズ 前川 直也 様
- 2. 2 『システム開発現場のファシリテーション』 （技術評論社） 『これだけは知っておきたい組込みシステムの設計手法』 （技術評論社） 『わかりやすいアジャイル開発の教科書』 （ソフトバンククリエイティブ 株式会社 日新システムズ 未来戦略室 室長 兼 品質保証部 部長 兼 事業戦略部 主査 前川 直也 1994 ～ 日本コンピューター・システム株式会社 1998 ～ パナソニック株式会社 2015 ～ 株式会社日新システムズ アジャイル導入・実践 プロジェクトファシリテーション プロセス改善 産業カウンセリング アジャイルでお困りの際は お気軽にメールください n.maekawa@co-nss.co.jp ET West 実行委員 @nao_maru http://www.facebook.com/NaoyaMaekawa
- 3. 会社概要 社名 株式会社日新システムズ 設立 1984年7月2日 売上高 約32億円（2016年度実績） 社員数 213名 （内、エンジニア：151名） ・平均年齢 34歳 ・男女比率 男性：178名、女性：35名（女性管理職6名） 事業所 ＜京都本社＞〒600-8482 京都市下京区堀川通綾堀川町293-1 ＜東京支社＞〒101-0024 東京都千代田区神田和泉町1番地 ＜沖縄開発センター＞〒901-0152 沖縄県那覇市字小禄1831番地1 住友電気工業株式会社 3 えるぼし 「女性が働きやすい職場づくり」に取組む企業認定 トモニン 仕事と介護を両立できる職場環境の整備促進に取組む企業認定
- 4. 4
- 5. 会社概要 5
- 7. Agenda 13:00～13:30 第1部：なぜアジャイルなのか？ 13:30～14:50 【ワークショップ】 レゴスプリント （10分間の休憩） 15:00～15:50 第2部：製品価値をあげるために （10分間の休憩） 16:00～17:00 第3部：みなさまとディスカッション 明日からのアクションプランを作ろう 7
- 9. Copyright © 2016 NISSIN SYSTEMS All right reserved 9 ビジネスの世界はどう変る？
- 10. 10 価値に向き合ってますか？
- 12. これまでのソフトウェア開発 設 計 テスト実 装 チェック チェック 要求 価値 インプット アウトプット 以前は、決められた要求（機能）を要件に落とし込み 計画をほぼ変えることなくものづくりができた時代 「 思い（要求）」がインプットされる 12
- 14. 開発開始段階の課題 14
- 16. 納品時の結果 16
- 24. メーカーの苦悩
- 28. 大規模メーカーにありがちな罠 一つの商品にかかわるステークホルダが多い 大人数の大規模開発になりがち （ソフトウェア子会社も巻き込んで） ものづくりのステップ移行で重たくなる （必然的なウォーターフォールに？） 品質は重要だがQCDのQが大きくなりすぎる 最終ユーザが求める価値が見えにくい 価値のフローが流れにくくなる 28
- 35. プロダクトバックログ ユーザストーリを 集めたもの 優先順位を決める スプリントバックログ 一つのプロダクトバックログを スプリントに落とし込み スプリントバックログを作る スプリント 1 ～ 4 Week デイリー スクラム スプリントレビュー 動くソフトウェアで レビュー＋フィードバック スプリント レトロスペクティブ スプリントごとにふりかえり 開 発 チ ー ム プロダクト オーナー スクラム マスター 開発チームの作業と プロダクトの価値の 最大化に責任を持つ スクラムの理解と成立に 責任を持つ スクラムの流れ 35
- 36. わかりやすい アジャイルの『ツボ』 ゴール • 価値をゴールにし、優先順位をコミットする • リズムとゴールをマッチングさせる リズム • プロジェクトを一定間隔のリズムで区切る • プロジェクトのベロシティを把握する 見える化 • 動くもの＋状況の可視化でリズムを伝播させる • フィードバックにより変化を取り込む 自律 • 自分たちでふりかえる • 自分たちで変えていく 1 2 3 4 1 2 3 4 36
- 37. ①価値をゴールに設定し、コミットする ゴール • 価値をゴールにし、優先順位をコミットする • リズムとゴールをマッチングさせる リズム • プロジェクトを一定間隔のリズムで区切る • プロジェクトのベロシティを把握する 見える化 • 動くもの＋状況の可視化でリズムを伝播させる • フィードバックにより変化を取り込む 自律 • 自分たちでふりかえる • 自分たちで変えていく 37
- 38. プロダクトバックログ ユーザストーリを 集めたもの 優先順位を決める スプリントバックログ 一つのプロダクトバックログを スプリントに落とし込み スプリントバックログを作る スプリント 1 ～ 4 Week デイリー スクラム スプリントレビュー 動くソフトウェアで レビュー＋フィードバック スプリント レトロスペクティブ スプリントごとにふりかえり 開 発 チ ー ム プロダクト オーナー スクラム マスター 開発チームの作業と プロダクトの価値の 最大化に責任を持つ スクラムの理解と成立に 責任を持つ 38
- 39. 開発着手 仕様一次Fix スプリント #1 スプリント #2 スプリント #3 スプリント #4 機器仕様 検討 プロダクト 検討 関連部署とのコミットメント 設計者の概要見積りを ベースにリリース計画 （各スプリントの実装要件） ＜Output＞ • プロダクトバックログ （ストーリー実装リスト） • リリース計画／スプリント計画 • その他、関連ドキュメント ストーリーA：見積り ２ポイント ストーリーB：見積り 1ポイント ストーリーC：見積り 3ポイント ・・・ 39 スプリントのゴール設定 どんな機能を何のために作るのかを決めてリストアップ 見積は実施するが、ここで最終まで確定させてしまうわけではない
- 40. ストーリーとして描く http://www.slideshare.net/Ryuzee/ss-8332120 ユーザーストーリーとは？ 要求仕様を自然言語で簡潔に記述したもの ＜役割＞として ＜機能や性能＞が出来る それは＜ビジネス価値＞のためだ 例えば、 「グループでキャンプに」 行く場合 • テントを設置する • BBQ準備をする • 串焼きを作る • 風を感じながら寝られる • 全員で肉が焼ける • 取りやすい串焼きにする スタッフ視点 お客様視点 40
- 44. 製品の価値を最大化する 44
- 45. ②一定間隔をリズムを継続させる ゴール • 価値をゴールにし、優先順位をコミットする • リズムとゴールをマッチングさせる リズム • プロジェクトを一定間隔のリズムで区切る • プロジェクトのベロシティを把握する 見える化 • 動くもの＋状況の可視化でリズムを伝播させる • フィードバックにより変化を取り込む 自律 • 自分たちでふりかえる • 自分たちで変えていく 45
- 46. プロダクトバックログ ユーザストーリを 集めたもの 優先順位を決める スプリントバックログ 一つのプロダクトバックログを スプリントに落とし込み スプリントバックログを作る スプリント 1 ～ 4 Week デイリー スクラム スプリントレビュー 動くソフトウェアで レビュー＋フィードバック スプリント レトロスペクティブ スプリントごとにふりかえり 開 発 チ ー ム プロダクト オーナー スクラム マスター 開発チームの作業と プロダクトの価値の 最大化に責任を持つ スクラムの理解と成立に 責任を持つ 46
- 49. 開発着手 完成 仕様一次Fix スプリント #1 スプリント #2 スプリント #3 スプリント #4 1～2 week スプリント 計画 2日程度の粒度のタスクで 開発実施 成果レビュー ふりかえり 機能ごとに V字モデルを回す感じ 49 一定間隔のリズムで区切る プロダクトバックログをスプリントバックログに細分化することは基本的に WBSと似ているが、リズムが一定間隔なことが重要 ＜Output＞ • スプリントバックログ （作業タスク） • 作業成果物
- 50. ③常に状況を見えるようにして変化へ対応する ゴール • 価値をゴールにし、優先順位をコミットする • リズムとゴールをマッチングさせる リズム • プロジェクトを一定間隔のリズムで区切る • プロジェクトのベロシティを把握する 見える化 • 動くもの＋状況の可視化でリズムを伝播させる • フィードバックにより変化を取り込む 自律 • 自分たちでふりかえる • 自分たちで変えていく 50
- 51. プロダクトバックログ ユーザストーリを 集めたもの 優先順位を決める スプリントバックログ 一つのプロダクトバックログを スプリントに落とし込み スプリントバックログを作る スプリント 1 ～ 4 Week デイリー スクラム スプリントレビュー 動くソフトウェアで レビュー＋フィードバック スプリント レトロスペクティブ スプリントごとにふりかえり 開 発 チ ー ム プロダクト オーナー スクラム マスター 開発チームの作業と プロダクトの価値の 最大化に責任を持つ スクラムの理解と成立に 責任を持つ 51
- 53. 製品品質を継続的に確かめ、価値をあげる スプリントごとに価値をフィードバックするには？ 価値が確認できるレベルに動作していること シンプルに設計し、リファクタリングができること 今必要としていないものをムダに作りこまないこと デバイスドライバ ライブラリ アプリケーション レイア単位ではなく ファンクション単位で 53
- 54. Doneの定義 ストーリへの「完了条件を定義してない」 「共有していないこと」がズレの始まりに・・・ どんなテストを完了していますか？ レビューは完了していますか？ お客様視点で動作できますか？ 『Doneの定義』を明確に！ 54
- 55. 技術品質を継続的にキープする • コーディングミスが発生しにくい • コーディングでの誤り混入から 発見までの時間が短い （数分～数10分程度） • コードの可読性が向上する 55 スプリント デイリー スクラム テスト駆動開発 （Test Driven Development） ペアプログラミング • コードがきれいになる （レビュー率100％） • システムやコード、ツールなど の知識を共有できる • ペアの組み方によっては、 トレーニングの効果を得られる • コミュニケーションが活発になり 一体感を生み出す • 1人で悩んで停止しまうことが 少なくなり作業が着実に進む コードの共同所有 その他にもノウハウはたくさん 作るもの、プロジェクトに合わせ 自分たちでプラクティスを活用していく
- 56. ④自分たち自身の価値も向上させる ゴール • 価値をゴールにし、優先順位をコミットする • リズムとゴールをマッチングさせる リズム • プロジェクトを一定間隔のリズムで区切る • プロジェクトのベロシティを把握する 見える化 • 動くもの＋状況の可視化でリズムを伝播させる • フィードバックにより変化を取り込む 自律 • 自分たちでふりかえる • 自分たちで変えていく 56
- 57. プロダクトバックログ ユーザストーリを 集めたもの 優先順位を決める プロダクトバックログ 一つのプロダクトバックログを スプリントに落とし込み スプリントバックログを作る スプリント 1 ～ 4 Week デイリー スクラム スプリントレビュー 動くソフトウェアで レビュー＋フィードバック スプリント レトロスペクティブ スプリントごとにふりかえり 開 発 チ ー ム プロダクト オーナー スクラム マスター 開発チームの作業と プロダクトの価値の 最大化に責任を持つ スクラムの理解と成立に 責任を持つ 57
- 61. 人にフォーカスする What How Who Where ／ When 人にフォーカスしたアジャイルだからこそ 「ものづくり」から「ことづくり」アプローチに変えやすいはず 61
- 64. トップダウン or ボトムアップ？ トップダウン型マネジメント 経験・ノウハウが受け継がれる メンバがやるべきことがわかりやすい 経験がかえって邪魔になることも メンバが考えなくなってしまうリスク ボトムアップ型マネジメント メンバ自身が考えて・工夫する 知識の共有が実現しやすい クローズ化してしまうと逆効果 ビジョンの共有が不可欠 どちらも重要ですが、違いを使いこなしていますか？ 64
- 68. KPTは成長を促すツール Keepで、チームとしての共感を得る よかったことを褒めあうと、チームを信頼できる Problemを共有する 問題を誰かのせいにするのではなく、チームの問題であると認識する そして、みんなでTry! 誰かがやってくれる、のではなく、自分が、そして誰もがやる！ 68
- 69. プロジェクトのリズムを使った成長 ☞ 定期的に実施する – 続けるためには、習慣にしてしまう – 一定期間の短いリズムでふりかえる ☞ 「歩み」を実感しつづける – 成長していることは、自信につながる 69
- 76. Agility
- 78. 実践こそが アジャイル！ 価値について考える お客様はだれ？ ユーザーにとっての価値は？ 考える習慣、意識を継続 まずは簡単なことからでもOK とにかく実践してみる！
- 87. ソフトウェアかんばん ToDo 未実施 Doing 実施中 Done 完了 サザエ カツオ ワカメ 【使い方】 ① カードを未実施に貼る ② 実施する前に実施中にカードを移動する ③ タスクが完了したら完了に移動する ※ 貼りかえはリアルタイムに 87
- 88. KPTはプロセスを適応させるツール Keepで、チームとしての共感を得る よかったことを褒めあうと、チームを信頼できる Problemを共有する 問題を誰かのせいにするのではなく、チームの問題であると認識する そして、みんなでTry! 誰かがやってくれる、のではなく、自分が、そして誰もがやる！ 88
- 90. 『最高の飛行機」を 作ってください！ １０分×２回 1０分×2スプリント 朝会＋タスクの確認（1分） グループ作業（6分） KPT（3分） KPTの「ふりかえり」は２回目に反映！ かんばんも活用してください
- 91. ご完成 おめでとう ございます
- 95. 論文“The New New Product Development Game” （竹内弘高・野中郁次郎『ハーバード・ビジネス・レビュー』1986年） アジリティの考えは、従来の米国製造業が限界を認識し、それを越えようとしていた 時期に生まれてきました。つまり、製造業はもはやハードのみの生産者でなく、ソフ ト、サービスを融合した価値を提供する、あらたな存在を目指すべきである、と。そ うでない限りグローバルな競争環境において生存不能だ、という認識です。こうした 認識にもとづいて、ハード中心だったコンピュータ業界がソリューションなどのソフト、 サービス指向へと変身し、消費者向け製品でもマス・カスタム化（顧客の注文によ る生産。ワン・トゥ・ワン・マーケティングもこの一種）が重要な考え方となりました。 『知識経営のすすめ －ナレッジマネジメントとその時代』 野中 郁次郎／紺野 登 1999年12月20日 第1 版 スクラムが生まれたきっかけ 富士ゼロックス キャノン ホンダ NEC の事例から分析 95
- 98. 価値 ストーリー
- 100. ビジネスのためのアジャイルへ
- 102. Agility
- 104. 日本のソフトウェア業界の構図
- 105. 自分たちの考える価値を 思った通りに作ってくれる 高品質だけど、できれば安く （お客様の業績次第） 日本ではかかった時間にお金を 支払うことが多く、工数で見積 ごくまれに機能を提案してくれる 継続的に付き合ってくれる これまでのソフトウェア開発 受託 発注 何を作りたいかは お客様が決められる 狙ったものを狙った通りに 撃ち落とすことができる時代 受託 開発 Quality CostDelivery QCDを意識して 求められるものを作りだす 開発企業に求められるもの メーカー SIer ゼネコン etc. 組込み ソフトウェア ハウス 105
- 106. 自分たちが成功できる価値を 一緒に考え、作りだしてくれる いらないものをいらないと言ってく れる（価値の優先度判断） 高品質かつ、想定以上のものを 迅速に届けてくれる ビジネスで成功する価値に対す る対価として予算を決めてくれる 頼りになるビジネスパートナー これからのソフトウェア開発 協調 何を作りたいかを お客様も悩んでいる 狙うもの自体を 定めることが難しい時代 ソリュー ション Quality Cost Delivery Scope QCD＋Scopeを意識して お客様のビジネス価値を 最大限に引き出すことができる 開発企業に求められるもの IoTクラウド 組込み ソフトウェア ハウス メーカー SIer ゼネコン etc. 106 エコシステムズ
- 109. 価値をデザインする
- 112. 作り方をデザインする
- 117. チームをデザインする
- 120. 組織の壁を ストーリーで つなげていく
- 121. 品質をデザインする
- 122. 122 DevQA Agile RCA
- 126. Social Change starts with YOU!! あなたが動くと、チームが、組織が、そして社会が変わる ご清聴ありがとうございました