Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

技術とサービスをつなぎ価値ある製品をつくるための組込みアジャイル

1,319 views

Published on

PM創生研さまディスカッション資料

Published in: Software
  • Be the first to comment

技術とサービスをつなぎ価値ある製品をつくるための組込みアジャイル

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

×