価値ある製品を生み出すためのアジャイル実践ポイント
•
22 recomendaciones•8,918 vistas
SEA関西さんの2015/8/22に開催したプロセス分科会のセミナー＋ワークショップ資料です
Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Destacado
Destacado (20)
Similar a 価値ある製品を生み出すためのアジャイル実践ポイント
Similar a 価値ある製品を生み出すためのアジャイル実践ポイント (20)
Más de Naoya Maekawa
Más de Naoya Maekawa (12)
価値ある製品を生み出すためのアジャイル実践ポイント
- 1. 価値ある製品を生み出すための アジャイル実践ポイント 22 August 2015 13:30～17:00 株式会社日新システムズ 陸野 礼子・前川 直也 第63回 SEA関西プロセス分科会
- 2. プロフィール 陸野 礼子（りくの れいこ） 株式会社日新システムズ 品質保証部 • 2004年より、パナソニック株式会社の組み込みソフトウェア開発 のプロセス改善業務に従事し、ホームエレクトロニクス/カーエレク トロニクス製品等の開発現場を舞台に、QMS、CMMI・PSP/TSP、 Automotive-SPICE、アジャイルを活用し、プロセスだけでなく チーム力アップをモットーに現場密着型の改善活動に奮闘。 • パナソニック研修所にて、TSP(Team Software Process)をベー スに『成功するチーム』の運営法、Redmine活用事例といった研修 講師を担当 • 2015年6月、日新システムズに転職 →“WakuWaku”をコンセプトに組織改革に取組み中！
- 3. HU-3 【ET West 10周年記念】組込み10年のチャレンジ！これからの10年は!? 3 『システム開発現場のファシリテーション』 （技術評論社） 『これだけは知っておきたい組込みシステムの設計手法』 （技術評論社） 『わかりやすいアジャイル開発の教科書』 （ソフトバンククリエイティブ 株式会社 日新システムズ 社長付主査 兼 事業戦略部 主査 1994 ～ 日本コンピューター・システム株式会社 1998 ～ パナソニック株式会社 2015 ～ 株式会社日新システムズ 組込みアジャイル プロジェクトファシリテーション プロセス改善 産業カウンセラー アジャイルでお困りの際は お気軽にメールください ET West 実行委員 @nao_maru http://www.facebook.com/NaoyaMaekawa
- 4. Agenda 1. 組込みソフトの課題 2. アジャイルのツボ 3. チームビルディング ワークショップ 4. 品質アプローチ 5. 価値を描く 4
- 8. これまでのソフトウェア開発 設 計 テスト実 装 チェック チェック 要求 価値 インプット アウトプット 決められた機能を要件に落とし込み 計画をほぼ変えることなくものづくりができた時代から・・・ 8
- 10. 開発開始段階の課題 10
- 12. 納品時の結果 12
- 15. 人にフォーカスする What How Who Where ／ When 15
- 20. 大規模メーカーにありがちな罠 一つの商品にかかわるステークホルダが多い 大人数の大規模開発になりがち （ソフトウェア子会社も巻き込んで） ものづくりのステップ移行で重たくなる （必然的なウォーターフォールに？） 最終ユーザが見えない場合が多い 品質は重要だがQCDのQが大きくなりすぎる 価値のフローが流れにくくなる 20
- 24. －弐－ アジャイルのツボ
- 27. アジャイルを導入する前に・・・ [チェックポイント] プロジェクトにエンジニアリング＆プロセスの基本スキルはどのぐらい？ メンバが風土を変えるぐらいの改善意欲を持っていますか？ 自分たちが作っているものに愛着を持っていますか？ • お客様が何を求めているのか考えてる？ 改善指標を数値だけで判断していませんか？ • コミュニケーションは活発？ メンバとゴールを共有できていますか？ 27
- 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 29
- 30. プロダクトバックログ ユーザストーリを 集めたもの 優先順位を決める スプリントプランニング スプリントに落とし込み スプリントバックログを作る スプリント スプリントに落とし込み 1 ～ 4 Week デイリー スクラム スプリントレビュー 動くソフトウェアで レビュー＋フィードバック スプリント レトロスペクティブ スプリントごとにふりかえり 開 発 チ ー ム プロダクト オーナー スクラム マスター 開発チームの作業と プロダクトの価値の 最大化に責任を持つ スクラムの理解と成立に 責任を持つ スクラムの流れ 30
- 31. 従来のプロセスとの違い 31
- 34. ※ ご注意 ここからはとある大規模プロジェクトでの 事例を使いながら、ご説明いたします 決してパーフェクトな事例ではないかもしれませんが 組込みアジャイルのツボを実践するうえでヒントになるはずです
- 37. 従来の開発の流れ システムテスト 区切りがあるようでない／終盤は実装だけ？ 設計着手 全機能実装版 仕様検討 要求分析 要求分析 要求分析 要求分析 ・・・・・ 設計 詳細設計 実装基本設計 テスト 詳細設計 実装 テスト 詳細設計 実装 詳細設計 実装基本設計 テスト ・・・・・ 検証 実装 テスト 実装 実装 実装 テスト設計 ここが 最初のゴール約３ヶ月 0次試作 1次試作 2次試作 ゴールまで 長いので ダラダラ… 37 事例
- 39. わかりやすい アジャイルの『ツボ』 ゴール • 価値をゴールにし、優先順位をコミットする • リズムとゴールをマッチングさせる リズム • プロジェクトを一定間隔のリズムで区切る • プロジェクトのベロシティを把握する 見える化 • 状況を見えるようにしてリズムを伝播させる • 変化を受け入れる 自律 • 自分たちでふりかえる • 自分たちで変えていく 1 2 3 4 1 2 3 4
- 40. ①価値をゴールに設定し、コミットする ゴール • 価値をゴールにし、優先順位をコミットする • リズムとゴールをマッチングさせる リズム • プロジェクトを一定間隔のリズムで区切る • プロジェクトのベロシティを把握する 見える化 • 状況を見えるようにしてリズムを伝播させる • 変化を受け入れる 自律 • 自分たちでふりかえる • 自分たちで変えていく
- 43. 5W1Hで考えるのはアジャイルでも同じ スプリント #1 スプリント #2 スプリント #n スプリント #0 ・・・・ スプリント #3 仕様 一次Fix 全機能 実装版 Why なぜ作るのか？ What 何を作るのか？ How どうやって作るのか？ When いつまでに作るのか？ Who だれが作るのか？ Who どこで作るのか？
- 44. 設計着手 仕様一次Fix スプリント #1 スプリント #2 スプリント #3 スプリント #4 機器仕様 検討 プロダクト 検討 関連部署とのコミットメント 設計者の概要見積りを ベースにリリース計画 （各スプリントの実装要件） ＜Output＞ • プロダクトバックログ （ストーリー実装リスト） • リリース計画／スプリント計画 • その他、関連ドキュメント ストーリーA：見積り ２ポイント ストーリーB：見積り 1ポイント ストーリーC：見積り 3ポイント ・・・ 44 スプリントのゴール設定 事例 どんな機能を、何のために作るのかを決めてリストアップ 荒い見積は実施するが、ここで確定させてしまうわけではない
- 46. ②一定間隔をリズムを継続させる ゴール • 価値をゴールにし、優先順位をコミットする • リズムとゴールをマッチングさせる リズム • プロジェクトを一定間隔のリズムで区切る • プロジェクトのベロシティを把握する 見える化 • 状況を見えるようにしてリズムを伝播させる • 変化を受け入れる 自律 • 自分たちでふりかえる • 自分たちで変えていく
- 48. 推進L こうなる機能 設定した値以上の白が表示されている部分が、ライブビュー出力中に白黒縞々のパターンで マーキングされる（LCD、LVF、HDMI、外部モニターなどすべて） 企画優先度 A 難易度 B どんな目的 （どんな気持ちで） 撮影対象の中に、白トビが発生していないかをリアルに確認する ライブビュー、撮影中も確認できる 再生中は表示されない主担当U REC ゼブラパターンを表示する リリース スプリント 要件番号 14A4079 どんな人が？ プロの動画カメラマン（静止画カメラマンの一部も含む） ユニットCユニットB 設計着手 仕様一次Fix 機器仕様 検討 プロダクト 検討 関連部署とのコミットメント SPLとULでレビュー どんな手順で開発を 進めるのか双方の イメージ合わせ ユニットA UL ユニットごとに 要件別プロセス別 見積りを実施 UL 機種 SPL フィード バック 48 メンバー全員で ゴールへのコミットメント ゴールへのコミットメント形成 ゴールをシミュレーションし、自分たちがコミットする プロジェクトでのコミットメント 事例 プロダクト詳細シート
- 49. 【お客様は誰？】 ① フォーマットに合わせて、みんなで ディスカッションをしてみましょう ② 「お客様は誰ですか？」は、 名前など特定できればOK ③ 「どんな人ですか？」「求めているもの はどんなもの？」を具体化していきま しょう ④ １人だけとは限りません いろいろなパターンを考えてみましょう ご参考 49
- 50. 【お客様のハッピー】 ① 「お客様は誰？」の結果を書きましょう ② お客様はどんなことをやってみたいと 思っていますか？ 求めているものは？ ③ みなさんがつくり出すもので、どんなこ とが実現できますか？ ④ 実際にお客様が使ってみると、 どんな気持ちになりますか？ ご参考 50
- 52. 設計着手 全機能 実装版 仕様一次Fix スプリント #1 スプリント #2 スプリント #3 スプリント #4 1～2 week スプリント 計画 2日程度の粒度のタスクで 開発実施 成果レビュー ふりかえり 機能ごとに V字モデルを回す 52 一定間隔のリズムで区切る 事例 プロダクトバックログをスプリントバックログに細分化することは 基本的にWBSと似ているが、リズムが一定間隔なことが重要 ＜Output＞ • スプリントバックログ （作業タスク） • 作業成果物
- 53. ③常に状況を見えるようにして変化へ対応する ゴール • 価値をゴールにし、優先順位をコミットする • リズムとゴールをマッチングさせる リズム • プロジェクトを一定間隔のリズムで区切る • プロジェクトのベロシティを把握する 見える化 • 状況を見えるようにしてリズムを伝播させる • 変化を受け入れる 自律 • 自分たちでふりかえる • 自分たちで変えていく
- 56. スプリントにあわせたRedmineの活用 L開発プロジェクト ユニットA ユニットB ユニットCユニットCユニットC 親プロジェクトで全体計画 サブプロジェクトでユニット計画を管理し連携する スプリントのゴール進捗をロードマップで管理 「ターゲットバージョン」で 全体計画と連携 ユニット単位の進捗は サブプロジェクトで設定 ロードマップにて、ゴール単位の 各ユニット進捗を週次で確認 Redmineデータを元に 進捗状況の可視化 事例
- 58. プロダクト 検討#3 プロダクト 検討#4 プロダクト 検討#2 設計着手 仕様一次Fix スプリント #1 スプリント #2 スプリント #3 スプリント #4 プロダクトバックログはスプリントごとに変化がないか確認 リリースされ価値に変化が発生することもありえる 確認するためには品質の高いリリースが重要 Point プロダクト 検討#1 58 ゴールは固定されるのではなく継続的にふりかえる ふりかえり ふりかえり ふりかえり ふりかえり 事例
- 59. ④自分たち自身の価値も向上させる ゴール • 価値をゴールにし、優先順位をコミットする • リズムとゴールをマッチングさせる リズム • プロジェクトを一定間隔のリズムで区切る • プロジェクトのベロシティを把握する 見える化 • 状況を見えるようにしてリズムを伝播させる • 変化を受け入れる 自律 • 自分たちでふりかえる • 自分たちで変えていく 59
- 61. Agile 【1990年代】 オブジェクト指向 モデリング 設計技術を どう回す？ 時代にどう合 わす？ 【2000～02】 ペアプロ TDD 反復特有の技術アップ 【2002～】 コーチング ファシリテーション 人に向き合う！ 【2005～】 プロジェクトファシリテーション TPS／SECIモデル チームビルディング PM 【2007～】 要求開発 ビジネスアジャイル ビジネスとして とらえる 【2000】 アジャイル宣言 ファシリテーション トヨタ生産方式 アジャイル開発 プロジェクト ファシリテーション 【プロジェクトファシリテーション】とは？ プロジェクトマネジメント（PM）が重要であることは昨今強く言われて います。 PMが「計画達成のマネジメント」に重点を置くのに対してPF は「参加者の協調の場作り」に重点を置いています。PMは、計画の 立案と実行、差異に注目し た管理が中心で、どちらかと言うと「コマ ンド･コントロール型」のマネジメントスタイルが背後にあります。これ に対してPFは、その場その場の変化に対応 し、チームが協力し合っ て創発的に成果を出していく、「リーダーシップ･コラボレーション型」 の新しいチーム作りの形です。 （オブラブ公式Webサイトより http://www.objectclub.jp/community/pf/） アジャイルの変遷とプロジェクトファシリテーション プロジェクトファシリテーションとは？ 61
- 63. スクラムは、経験的プロセス制御の 理論（経験主義）を基本にしている。 経験主義とは、実際の経験や既知に 基づく判断によって知識が獲得でき るというものである。スクラムでは、 反復的で漸進的な手法を用いて、予 測可能性の最適化とリスクの管理を 行う。 「スクラムガイド」より © 1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide- JA.pdf 63 スクラムの理論 63
- 64. スクラムチームの特徴 スクラムチーム スクラムチームは、プロダクトオーナー・開発チー ム・スクラムマスターで構成される。スクラムチー ムは自己組織化されており、機能横断的である。自 己組織化チームは、作業を成し遂げるための最善の 策を、チーム外からの指示ではなく、自らが選択す る。機能横断的チームは、チーム外に頼らずに作業 を成し遂げる能力を持っている。スクラムにおける チームのモデルは、柔軟性・創造性・生産性に最適 化されたものとなっている。 「スクラムガイド」より © 1991-2013 Ken Schwaber and Jeff Sutherland, All Rights Reserved https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide-JA.pdf 64
- 68. －参－ チームビルディング
- 71. そもそもスケジュールが非現実的だった 適切な人員がそろえられなかった 仕様変更が多発した 進捗管理が不十分なため、 早い時期に遅れに気づくことができなかった 品質を保証できるテスト設計ができていなかった 火消し作業による不具合対策に追われ、 効率的な対策がうてなかった 一見、マネジメント（リーダー）の問題？？？ 実は、チームワークの問題である場合が多い 失敗の原因を考えてみると．．． 71
- 74. 開発規模の増大と開発期間の短縮化 今日の開発プロジェクトは、一人ではできないほど規模が大きい 多くのビジネスにて、市場へ出すまでの時間を できるだけ短くする必要がある チームは幅広い才能と能力を提供する 一人で経験できることは、それほど多くはない メンバーの才能を最大限に活用する チームに参加する事で個人の仕事が改善する メンバーは補完しあうスキルをもち、お互いに学び助け合いサポート レビューや設計のブレーンストーミングなどの場を活用して、 より高度なアドバイスや支援を得て、 個々のスキルを伸ばしていくことができる 「TSPガイドブック：リーダー編」 より ワッツ・S・ハンフリー著 秋山義博監訳 JASPIC TSP研究会訳 チームが必要とされる理由 74
- 75. チームワークはスキルであり、高いパフォーマンスが要求される チームの真の力は、その合成された力から生じる 自律的なチームを目指す メンバーは言われなくても何が必要か感じ取って、 協力して助け合い、仕事を成し遂げるために 必要なことはなんでもやる 開発業務における自律的なチームの必要性 創造的な開発業務では、全員の心からの参画が必要 質の高い作業は、考え、気を遣い、動機づけられた人々が行う でも、動議づけってどうすればいいの？！ 「TSPガイドブック：リーダー編」 より ワッツ・S・ハンフリー著 秋山義博監訳 JASPIC TSP研究会訳 チームに求められる力とは 75
- 76. モチベーション（Motivation）＝動機づけ、やる気 モチベーションがないと、多くのことはうまくいかない 個人でもチームでも、特に創造的な仕事にはモチベーション が重要となる チームの動機づけ 「TSPガイドブック：リーダー編」 より ワッツ・S・ハンフリー著 秋山義博監訳 JASPIC TSP研究会訳 76
- 77. コミットメント 個人とチームが約束したことをやりたいと思う気持ち 動機づけの種類 恐怖 指示したとおりにタスクを完了しないと職を失うぞ！ 思考停止反応を引き起こす 保身的な行動や非合理な行動さえ生じさせる 金銭欲 もっと稼げると思うやり方で仕事をする ノルマ分だけ働く 必要な努力を最小にして最大報酬を得ようとする 「TSPガイドブック：リーダー編」 より ワッツ・S・ハンフリー著 秋山義博監訳 JASPIC TSP研究会訳 77
- 80. KPTは成長を促すツール Keepで、チームとしての共感を得る よかったことを褒めあうと、チームを信頼できる Problemを共有する 問題を誰かのせいにするのではなく、チームの問題であると認識する そして、みんなでTry! 誰かがやってくれる、のではなく、自分が、そして誰もがやる！ 80
- 81. プロジェクトのリズムを使った成長 ☞ 定期的に実施する – 続けるためには、習慣にしてしまう – 一定期間の短いリズムでふりかえる ☞ 「歩み」を実感しつづける – 成長していることは、自信につながる 81
- 94. 【お客様は誰？】 ① フォーマットに合わせて、みんなで ディスカッションをしてみましょう ② 「お客様は誰ですか？」は、 名前など特定できればOK ③ 「どんな人ですか？」「求めているもの はどんなもの？」を具体化していきま しょう ④ １人だけとは限りません いろいろなパターンを考えてみましょう ご参考 94
- 95. 【お客様のハッピー】 ① 「お客様は誰？」の結果を書きましょう ② お客様はどんなことをやってみたいと 思っていますか？ 求めているものは？ ③ みなさんがつくり出すもので、どんなこ とが実現できますか？ ④ 実際にお客様が使ってみると、 どんな気持ちになりますか？ ご参考 95
- 100. ソフトウェアかんばん ToDo 未実施 Doing 実施中 Done 完了 サザエ カツオ ワカメ 【使い方】 ① カードを未実施に貼る ② 実施する前に実施中にカードを移動する ③ タスクが完了したら完了に移動する ※ 貼りかえはリアルタイムに 100
- 101. KPTはプロセスを適応させるツール Keepで、チームとしての共感を得る よかったことを褒めあうと、チームを信頼できる Problemを共有する 問題を誰かのせいにするのではなく、チームの問題であると認識する そして、みんなでTry! 誰かがやってくれる、のではなく、自分が、そして誰もがやる！ 101
- 103. 『最高の飛行機」を 作ってください！ １０分×２回 1０分×2イテレーション 朝会＋タスクの確認（1分） グループ作業（6分） KPT（3分） KPTの「ふりかえり」は２回目に反映！ かんばんも活用してください
- 104. ご完成 おめでとう ございます
- 105. －四－ 品質アプローチ
- 107. 技術品質を継続的にキープする • コーディングミスが発生しにくい • コーディングでの誤り混入から 発見までの時間が短い （数分～数10分程度） • コードの可読性が向上する 107 スプリント デイリー スクラム テスト駆動開発 （Test Driven Development） ペアプログラミング • コードがきれいになる （レビュー率100％） • システムやコード、ツールなど の知識を共有できる • ペアの組み方によっては、 トレーニングの効果を得られる • コミュニケーションが活発になり 一体感を生み出す • 1人で悩んで停止しまうことが 少なくなり作業が着実に進む コードの共同所有 その他にもノウハウはたくさん 作るもの、プロジェクトに合わせ 自分たちでプラクティスを活用していく
- 108. Doneの定義 ストーリへの「完了条件を定義してない」 「共有していないこと」がズレの始まりに・・・ どんなテストを完了していますか？ レビューは完了していますか？ お客様視点で動作できますか？ 『Doneの定義』を明確に！
- 109. 対立構図から「問題対私たち」へ 109
- 110. 製品品質を継続的に確かめ、価値をあげる スプリントごとに価値をフィードバックするには？ 価値が確認できるレベルに動作していること シンプルに設計し、リファクタリングができること 今必要としていないものをムダに作りこまないこと デバイスドライバ ライブラリ アプリケーション レイア単位ではなく ファンクション単位で
- 111. －五－ 価値を描く
- 112. もちろんメーカーとしてのメリットもある！ ブランドの力はやっぱりすごい！ 技術力は世界トップレベル！ ターゲットに応じて 組織体制を変えることができる！ マーケティングの4Pは手の内に！ お金ありまっせ！ 112
- 113. 最も強い者が生き残るのではなく、 最も賢い者が生き延びるのでもない。 唯一生き残ることが出来るのは、 変化できる者である。 チャールズ・ダーウィン しかも、自分たちだけでなく、まきこめるかどうかも重要
- 114. ものづくり日本
- 115. みなさんがつくっているものの価値はなに？
- 116. システムの機能の利用度 全く使われない 45%ほとんど使われな い 19% たまに使う 16% いつも使う 7% よく使う 13% Standish group study report in 2000 chaos report システム開発と組込み開発の違い 116 「たまに使う」に意味があったりしませんか？
- 118. 製品の価値を最大化するには？ 118
- 120. 変化を味方につける（開発側から） 120
- 121. 「Why」を考えてみる どうなりたいか（BE）がベースになる Why なぜ作らなければ ならないのか？ 企業・組織としての Why 個人としての Why – 利益をあげねば – 競合他社に勝つ – 生産性をあげる – 高品質な商品 – リーダとしての成功 – 新しい技術を得る – 自分の時間を作る – 残業しても高収入 いやなことはしたくない・・・ パワーを引き出す「素」は 結局のところ「欲求」につながる スポーツ ゲーム 趣味 家族 勉強 仕事 121
- 122. 「Why」の影響 Why?企業・組織としての Why 個人としての Why ビジネスで成功 自己成長 チーム成長 業績アップ 自分の時間 あせり・指示 やらされ感 Command Control 思考停止 成長停止 二つのプラスが マッチングしたとき 最高スペックに！ 122
- 123. クレドを作ろう！ みなさんとやりたいこと
- 132. アジャイルは 現場駆動 人駆動 です
- 134. 実践こそが アジャイル！ 価値について考える お客様はだれ？ ユーザーにとっての価値は？ 考える習慣、意識を継続 まずは簡単なことからでもOK 実践してみる！ 声のかけかた、会議のしかけな どでも現場は変わる ボトムアップが組織を変える！
- 135. 13 5 Social Change starts with YOU!! 「未来」は自分たちで描き、自分たちの手で変化を生み出そう！ 135 ご清聴ありがとうございました