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.

価値ある製品を生み出すためのアジャイル実践ポイント

6,726 views

Published on

SEA関西さんの2015/8/22に開催したプロセス分科会のセミナー+ワークショップ資料です

Published in: Software
  • Be the first to comment

価値ある製品を生み出すためのアジャイル実践ポイント

  1. 1. 価値ある製品を生み出すための アジャイル実践ポイント 22 August 2015 13:30~17:00 株式会社日新システムズ 陸野 礼子・前川 直也 第63回 SEA関西プロセス分科会
  2. 2. プロフィール 陸野 礼子(りくの れいこ) 株式会社日新システムズ 品質保証部 • 2004年より、パナソニック株式会社の組み込みソフトウェア開発 のプロセス改善業務に従事し、ホームエレクトロニクス/カーエレク トロニクス製品等の開発現場を舞台に、QMS、CMMI・PSP/TSP、 Automotive-SPICE、アジャイルを活用し、プロセスだけでなく チーム力アップをモットーに現場密着型の改善活動に奮闘。 • パナソニック研修所にて、TSP(Team Software Process)をベー スに『成功するチーム』の運営法、Redmine活用事例といった研修 講師を担当 • 2015年6月、日新システムズに転職 →“WakuWaku”をコンセプトに組織改革に取組み中!
  3. 3. HU-3 【ET West 10周年記念】組込み10年のチャレンジ!これからの10年は!? 3 『システム開発現場のファシリテーション』 (技術評論社) 『これだけは知っておきたい組込みシステムの設計手法』 (技術評論社) 『わかりやすいアジャイル開発の教科書』 (ソフトバンククリエイティブ 株式会社 日新システムズ 社長付主査 兼 事業戦略部 主査 1994 ~ 日本コンピューター・システム株式会社 1998 ~ パナソニック株式会社 2015 ~ 株式会社日新システムズ 組込みアジャイル プロジェクトファシリテーション プロセス改善 産業カウンセラー アジャイルでお困りの際は お気軽にメールください ET West 実行委員 @nao_maru http://www.facebook.com/NaoyaMaekawa
  4. 4. Agenda 1. 組込みソフトの課題 2. アジャイルのツボ 3. チームビルディング  ワークショップ 4. 品質アプローチ 5. 価値を描く 4
  5. 5. 今日のベースは これです! CM 5 http://www.sbcr.jp/products/4797371284.html
  6. 6. 6 -壱- 組込みソフトの課題
  7. 7. 以前は、狙っていけば的中する確率が高かった 今の組込み業界では、 環境の変化 ユーザニーズの多様化 競合他社との競争激化 などで、先の読めない状況・・・ 環境変化 競合 ソフト業界の変化 7 『要求される価値』から『創り出す価値』の時代に突入!
  8. 8. これまでのソフトウェア開発 設 計 テスト実 装 チェック チェック 要求 価値 インプット アウトプット 決められた機能を要件に落とし込み 計画をほぼ変えることなくものづくりができた時代から・・・ 8
  9. 9. 日程前倒し 課題/バグ 仕様変更 仕様追加 混沌とした組込み業界において、 ソフトウェアの変化が発生しないというのはありえない 変化を前向きに受け入れていく必要がある ソフトウェア開発に変化はつきもの 9
  10. 10. 開発開始段階の課題 10
  11. 11. 開発中の課題 コミュニケーションギャップ 設計・実装上の都合・納期、等 11
  12. 12. 納品時の結果 12
  13. 13. 規模が大きくなった弊害 営業→企画→開発→QA→製造などのバトンが複雑化し その分、ドキュメントによるバトンリレーが発生しやすくなる そこに「ギャップ」は発生していないだろうか? 13
  14. 14. ソフト業界 約60年の歴史 ソフトウェアが商業ベースになり それにつれて、工学的にアプローチ 『誰でも同じように作れるソフトウェア』 2000年頃から、もう一度初心に戻り 新たなアプローチが始まる 『ソフトウェアは人が作るものである』 14
  15. 15. 人にフォーカスする What How Who Where / When 15
  16. 16. どちらがエンジニアを活かせますか? 16
  17. 17. 短い『タイムボックス』で回しながら、 細かくフィードバックし、価値を膨らませていく開発スタイル 今求められているソフトウェア開発 17
  18. 18. 製品の価値の最大化を考える 18 製品の価値を決めている主要な部門はどこですか?
  19. 19. 企画部門 ニーズ エンドユーザ 開発部門 製品仕様 技術 販売 世界のTV市場 製品の価値の最大化を考える 19 製品の価値を最大化するために 作り手側に何が求められているのか?
  20. 20. 大規模メーカーにありがちな罠  一つの商品にかかわるステークホルダが多い  大人数の大規模開発になりがち (ソフトウェア子会社も巻き込んで)  ものづくりのステップ移行で重たくなる (必然的なウォーターフォールに?)  最終ユーザが見えない場合が多い  品質は重要だがQCDのQが大きくなりすぎる 価値のフローが流れにくくなる 20
  21. 21. 企画側(What) 製品企画段階で 価値ある要求が発見できない 開発側(How) 企画段階で 価値を高める提案ができていない 価値を共有できていないため、 開発に無駄が発生 21
  22. 22. 価値の最大化するためのプロセス 22 アジャイルは単に早い・高品質なだけではなく 価値を最大化していかなければ元の木阿弥
  23. 23. 変化を味方につけ お客様のビジネス価値を最大化する 23
  24. 24. -弐- アジャイルのツボ
  25. 25. ハード部門や工場など 関連部門とは どうしたらいいのか? 上司にどう説明すれば、 アジャイルを 導入できるのか? SQAはどこでステップ移行 監査や品質をチェック すればいいのか? 既存の組織プロセスが あるけど、 どうしたらいいの? ~組織編~ 組込み開発だと顧客 が明確でない場合 のフィードバックとは 誰がするのか? こんな不安、疑問を持たれてませんか? 25
  26. 26. 品質確保できるのか? 開発を委託している場合、 どうしたらいいのか? 委託元の役割とは? 要素開発で、ハード系 仕様がなかなか決まら ない、変更が激しい場 合はどんな形で導入し たらいいのか? アジャイルを熟知している 人がいないと、上手く いかないのでは? ~開発現場編~ こんな不安、疑問を持たれてませんか? 26
  27. 27. アジャイルを導入する前に・・・ [チェックポイント]  プロジェクトにエンジニアリング&プロセスの基本スキルはどのぐらい?  メンバが風土を変えるぐらいの改善意欲を持っていますか?  自分たちが作っているものに愛着を持っていますか? • お客様が何を求めているのか考えてる?  改善指標を数値だけで判断していませんか? • コミュニケーションは活発?  メンバとゴールを共有できていますか? 27
  28. 28. http://agilemanifesto.org/ 28 組込みでの開発の方がアジャイルは向いているといえます ただし、なぜアジャイルなのか?(目的) どんな価値を出すのか?(目標)をより明確にする必要があります
  29. 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. 30. プロダクトバックログ ユーザストーリを 集めたもの 優先順位を決める スプリントプランニング スプリントに落とし込み スプリントバックログを作る スプリント スプリントに落とし込み 1 ~ 4 Week デイリー スクラム スプリントレビュー 動くソフトウェアで レビュー+フィードバック スプリント レトロスペクティブ スプリントごとにふりかえり 開 発 チ ー ム プロダクト オーナー スクラム マスター 開発チームの作業と プロダクトの価値の 最大化に責任を持つ スクラムの理解と成立に 責任を持つ スクラムの流れ 30
  31. 31. 従来のプロセスとの違い 31
  32. 32. アジャイルソフトウェア宣言の背後にある原則 32 そんな時はもう一度『原則』に戻ってみる
  33. 33. アジャイルとは? アジャイルとは、 お客様のビジネス価値を最大化するための 「考え方」や「姿勢」のこと 33
  34. 34. ※ ご注意 ここからはとある大規模プロジェクトでの 事例を使いながら、ご説明いたします 決してパーフェクトな事例ではないかもしれませんが 組込みアジャイルのツボを実践するうえでヒントになるはずです
  35. 35. AV機器の組込み ソフトウェア開発 • 開発人員約100名 (社員4割、協力会社6割) • ソフト開発チームリーダー(TL) 以下フラットな体制 開発規模 約2,800kstep (約8~9割は流用) SPLグループ ソフト開発 チームTL ユニットA UL ユニットB UL ユニットC UL ユニットD UL ユニットE UL ユニットF UL 機種① SPL 機種② SPL ユニットはコンポーネント単位で分割され、 それぞれユニットリーダー(UL)を任命、 担当ユニットの開発日程と品質に責任を 担う 機種ごとにSPL(ソフトウェア プロジェクトリーダー)を任命、 機種のソフト開発の日程と 品質に責任を担う 事例:とある大規模ソフト開発現場 35 事例
  36. 36. 多機種・時間差・並行開発 による遅れの慢性化 年間20機種以上を開発 ハード構成の違い、機能差分に 対応しながらの開発 前機種の仕様変更や バグ収束遅れが 次々と連鎖! バグ対応/仕様検討/ 設計/実装のプロセスが 同時に進行 ユニットでスケジュールを 調整しながらの 四苦八苦の対応 多機種・時間差・並行開発  ソフト構造がムダに複雑化(スパゲッティ化)  全体設計を意識したソースコードになってない (意図のないコードが増えバグの温床) 36 事例
  37. 37. 従来の開発の流れ システムテスト 区切りがあるようでない/終盤は実装だけ? 設計着手 全機能実装版 仕様検討 要求分析 要求分析 要求分析 要求分析 ・・・・・ 設計 詳細設計 実装基本設計 テスト 詳細設計 実装 テスト 詳細設計 実装 詳細設計 実装基本設計 テスト ・・・・・ 検証 実装 テスト 実装 実装 実装 テスト設計 ここが 最初のゴール約3ヶ月 0次試作 1次試作 2次試作 ゴールまで 長いので ダラダラ… 37 事例
  38. 38. 自分たちで考え 成長を促すために 風土を進化 スムーズに流すため 体制と役割を進化 ゴールとリズムで 開発の流れを進化 メリハリつける! 協調する! 考える! 3つの改善ポイント 38 事例
  39. 39. わかりやすい アジャイルの『ツボ』 ゴール • 価値をゴールにし、優先順位をコミットする • リズムとゴールをマッチングさせる リズム • プロジェクトを一定間隔のリズムで区切る • プロジェクトのベロシティを把握する 見える化 • 状況を見えるようにしてリズムを伝播させる • 変化を受け入れる 自律 • 自分たちでふりかえる • 自分たちで変えていく 1 2 3 4 1 2 3 4
  40. 40. ①価値をゴールに設定し、コミットする ゴール • 価値をゴールにし、優先順位をコミットする • リズムとゴールをマッチングさせる リズム • プロジェクトを一定間隔のリズムで区切る • プロジェクトのベロシティを把握する 見える化 • 状況を見えるようにしてリズムを伝播させる • 変化を受け入れる 自律 • 自分たちでふりかえる • 自分たちで変えていく
  41. 41. ゴールとリズムをつくる 設計基本のV字モデルをキープしながら いつまでに、何を、どう作るのか ゴールを明確にして、一定期間のサイクルで回す ゴールを分割して、プロセスの流れを作る 41
  42. 42. 要求分析 詳細設計 実装 基本設計 結合・機能テスト 単体テスト システムテスト
  43. 43. 5W1Hで考えるのはアジャイルでも同じ スプリント #1 スプリント #2 スプリント #n スプリント #0 ・・・・ スプリント #3 仕様 一次Fix 全機能 実装版 Why なぜ作るのか? What 何を作るのか? How どうやって作るのか? When いつまでに作るのか? Who だれが作るのか? Who どこで作るのか?
  44. 44. 設計着手 仕様一次Fix スプリント #1 スプリント #2 スプリント #3 スプリント #4 機器仕様 検討 プロダクト 検討 関連部署とのコミットメント 設計者の概要見積りを ベースにリリース計画 (各スプリントの実装要件) <Output> • プロダクトバックログ (ストーリー実装リスト) • リリース計画/スプリント計画 • その他、関連ドキュメント ストーリーA:見積り 2ポイント ストーリーB:見積り 1ポイント ストーリーC:見積り 3ポイント ・・・ 44 スプリントのゴール設定 事例 どんな機能を、何のために作るのかを決めてリストアップ 荒い見積は実施するが、ここで確定させてしまうわけではない
  45. 45. プロジェクトのベロシティを把握する スプリント #1 スプリント #2 スプリント #3 スプリント #4 ・・・・ (画像提供:楽天株式会社 さま) 一つのスプリントで 実現できる作業量(ベロシティ)を 自分たちで把握することができる 一つのストーリ(要件でもあり、ファンクション でもある実現すべき価値)を日程や規模、 ページ数などではなく 設計、レビュー、テストなど 全ての作業を合わせた 『ストーリーポイント』として見積る ストーリーポイントは開発にかかわるチーム全員で見積る カードを使った「プランニングポーカー」を活用し 全員でコミュニケーションしながら見積を実施する場合もある
  46. 46. ②一定間隔をリズムを継続させる ゴール • 価値をゴールにし、優先順位をコミットする • リズムとゴールをマッチングさせる リズム • プロジェクトを一定間隔のリズムで区切る • プロジェクトのベロシティを把握する 見える化 • 状況を見えるようにしてリズムを伝播させる • 変化を受け入れる 自律 • 自分たちでふりかえる • 自分たちで変えていく
  47. 47. 価値を一緒に描き、共有していく 部門の壁を越えて、製品の価値を共有するには、 一緒に描き、一緒に作り、一緒に確認していく必要がある 47
  48. 48. 推進L こうなる機能 設定した値以上の白が表示されている部分が、ライブビュー出力中に白黒縞々のパターンで マーキングされる(LCD、LVF、HDMI、外部モニターなどすべて) 企画優先度 A 難易度 B どんな目的 (どんな気持ちで) 撮影対象の中に、白トビが発生していないかをリアルに確認する ライブビュー、撮影中も確認できる 再生中は表示されない主担当U REC ゼブラパターンを表示する リリース スプリント 要件番号 14A4079 どんな人が? プロの動画カメラマン(静止画カメラマンの一部も含む) ユニットCユニットB 設計着手 仕様一次Fix 機器仕様 検討 プロダクト 検討 関連部署とのコミットメント SPLとULでレビュー どんな手順で開発を 進めるのか双方の イメージ合わせ ユニットA UL ユニットごとに 要件別プロセス別 見積りを実施 UL 機種 SPL フィード バック 48 メンバー全員で ゴールへのコミットメント ゴールへのコミットメント形成  ゴールをシミュレーションし、自分たちがコミットする プロジェクトでのコミットメント 事例 プロダクト詳細シート
  49. 49. 【お客様は誰?】 ① フォーマットに合わせて、みんなで ディスカッションをしてみましょう ② 「お客様は誰ですか?」は、 名前など特定できればOK ③ 「どんな人ですか?」「求めているもの はどんなもの?」を具体化していきま しょう ④ 1人だけとは限りません いろいろなパターンを考えてみましょう ご参考 49
  50. 50. 【お客様のハッピー】 ① 「お客様は誰?」の結果を書きましょう ② お客様はどんなことをやってみたいと 思っていますか? 求めているものは? ③ みなさんがつくり出すもので、どんなこ とが実現できますか? ④ 実際にお客様が使ってみると、 どんな気持ちになりますか? ご参考 50
  51. 51. 【ストーリーテラー】 ① フォーマットに合わせて、 シンプルに書いてみましょう ② 結果をもとに具体的なディスカッション につなげてみましょう ご参考 51
  52. 52. 設計着手 全機能 実装版 仕様一次Fix スプリント #1 スプリント #2 スプリント #3 スプリント #4 1~2 week スプリント 計画 2日程度の粒度のタスクで 開発実施 成果レビュー ふりかえり 機能ごとに V字モデルを回す 52 一定間隔のリズムで区切る 事例 プロダクトバックログをスプリントバックログに細分化することは 基本的にWBSと似ているが、リズムが一定間隔なことが重要 <Output> • スプリントバックログ (作業タスク) • 作業成果物
  53. 53. ③常に状況を見えるようにして変化へ対応する ゴール • 価値をゴールにし、優先順位をコミットする • リズムとゴールをマッチングさせる リズム • プロジェクトを一定間隔のリズムで区切る • プロジェクトのベロシティを把握する 見える化 • 状況を見えるようにしてリズムを伝播させる • 変化を受け入れる 自律 • 自分たちでふりかえる • 自分たちで変えていく
  54. 54. 様々な見える化により透明性を実現する 54
  55. 55. Redmineでのチケット駆動開発 進捗確認 55 プロジェクトの見える化 ゴールごとのチケット 完了状況の確認 各チケットの状況で どの作業が残っている か簡単に把握できる リアルタイムにバーンダウンチャートを 見ることで進捗状況の共有化を図る 事例
  56. 56. スプリントにあわせたRedmineの活用 L開発プロジェクト ユニットA ユニットB ユニットCユニットCユニットC  親プロジェクトで全体計画 サブプロジェクトでユニット計画を管理し連携する  スプリントのゴール進捗をロードマップで管理 「ターゲットバージョン」で 全体計画と連携 ユニット単位の進捗は サブプロジェクトで設定 ロードマップにて、ゴール単位の 各ユニット進捗を週次で確認 Redmineデータを元に 進捗状況の可視化 事例
  57. 57. ターゲットバージョンの設定 ゴール名称を登録 →スプリントNo_機能名 期日を登録 (基本は週の最終稼動日) チケットごとにゴールを 設定する
  58. 58. プロダクト 検討#3 プロダクト 検討#4 プロダクト 検討#2 設計着手 仕様一次Fix スプリント #1 スプリント #2 スプリント #3 スプリント #4  プロダクトバックログはスプリントごとに変化がないか確認  リリースされ価値に変化が発生することもありえる  確認するためには品質の高いリリースが重要 Point プロダクト 検討#1 58 ゴールは固定されるのではなく継続的にふりかえる ふりかえり ふりかえり ふりかえり ふりかえり 事例
  59. 59. ④自分たち自身の価値も向上させる ゴール • 価値をゴールにし、優先順位をコミットする • リズムとゴールをマッチングさせる リズム • プロジェクトを一定間隔のリズムで区切る • プロジェクトのベロシティを把握する 見える化 • 状況を見えるようにしてリズムを伝播させる • 変化を受け入れる 自律 • 自分たちでふりかえる • 自分たちで変えていく 59
  60. 60. 平鍋さんブログ「An Agile Way」より http://blogs.itmedia.co.jp/hiranabe/2012/09/rightwing-and-leftwing-of-agile.html アジャイルのレフトウィング 60
  61. 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
  62. 62. プロジェクトファシリテーションの価値・原則 コミュニケーション 行動 気づき 信頼関係 笑顔 価値 見える化 リズム 名前付け 問題vs.私たち の構図 カイゼン 原則 朝会 かんばん KPT ペアボード ニコカレ アイスブレイク 偏愛マップ MindMap etc. プラクティス 62
  63. 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. 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
  65. 65. 【X理論】 人間は生来怠け者で、 できれば働きたくない 強制されたり命令されなければ 仕事をしない 【Y理論】 生まれながらに嫌いということはなく、 働くことは人間の本性 条件次第で責任を受け入れ、 自ら進んで責任を取ろうとする 問題解決のための創意工夫をこらす 能力は誰でも持っている ダグラス・マクレガーのX理論Y理論 人間観・動機づけにかかわる2つの対立的な理論 or 65
  66. 66. タイムボックスというリズムの効果 「変わらない時間の測定基準」を使って プロジェクトのパワーを測り引き出していく 66
  67. 67. ジャンプして届くゴールの繰り返し 67
  68. 68. -参- チームビルディング
  69. 69. ここで、みなさまに質問です 今まで、成功プロジェクトを 体験したことありますか? 69
  70. 70. 今まで参加したプロジェクトで こんな失敗の経験はないですか? 6ヶ月で完了する計画だったのに 気がつけば、2ヶ月遅れ、さらに2ヶ月遅れ やっとリリースした商品は欠陥が多く リワークで多額のロスコストが発生した この失敗の原因として 考えられることは何でしょうか? 70
  71. 71.  そもそもスケジュールが非現実的だった  適切な人員がそろえられなかった  仕様変更が多発した  進捗管理が不十分なため、 早い時期に遅れに気づくことができなかった  品質を保証できるテスト設計ができていなかった  火消し作業による不具合対策に追われ、 効率的な対策がうてなかった 一見、マネジメント(リーダー)の問題??? 実は、チームワークの問題である場合が多い 失敗の原因を考えてみると... 71
  72. 72. チームワークの問題=コミュニケーションの問題 リーダーとのコミュニケーション不足 リーダーから言われたスケジュールに対して、できないと知りつつ、 できないと言わない 課題があっても報告しない 開発者間のコミュニケーション不足 隣のメンバーが何をしているか知らない 自分の作業がどこに影響を与えるか知らない 外部(顧客や関連部門)とのコミュニケーション不足 仕様が決まらないか、決まった仕様に思い違いがあった プロジェクトが失敗する原因① 72
  73. 73. 厳しい開発スケジュールにあわせる 「プレッシャー」 途中のプロセスの実施を省略する 十分な検証をしないまま、新しい言語やツール、手法を利用する とりあえず手を動かすことを優先して、 計画的、効率的な取り組みが実施されない プロジェクトが失敗する原因② 73
  74. 74. 開発規模の増大と開発期間の短縮化 今日の開発プロジェクトは、一人ではできないほど規模が大きい 多くのビジネスにて、市場へ出すまでの時間を できるだけ短くする必要がある チームは幅広い才能と能力を提供する 一人で経験できることは、それほど多くはない メンバーの才能を最大限に活用する チームに参加する事で個人の仕事が改善する メンバーは補完しあうスキルをもち、お互いに学び助け合いサポート レビューや設計のブレーンストーミングなどの場を活用して、 より高度なアドバイスや支援を得て、 個々のスキルを伸ばしていくことができる 「TSPガイドブック:リーダー編」 より ワッツ・S・ハンフリー著 秋山義博監訳 JASPIC TSP研究会訳 チームが必要とされる理由 74
  75. 75. チームワークはスキルであり、高いパフォーマンスが要求される チームの真の力は、その合成された力から生じる 自律的なチームを目指す メンバーは言われなくても何が必要か感じ取って、 協力して助け合い、仕事を成し遂げるために 必要なことはなんでもやる 開発業務における自律的なチームの必要性 創造的な開発業務では、全員の心からの参画が必要 質の高い作業は、考え、気を遣い、動機づけられた人々が行う でも、動議づけってどうすればいいの?! 「TSPガイドブック:リーダー編」 より ワッツ・S・ハンフリー著 秋山義博監訳 JASPIC TSP研究会訳 チームに求められる力とは 75
  76. 76. モチベーション(Motivation)=動機づけ、やる気 モチベーションがないと、多くのことはうまくいかない 個人でもチームでも、特に創造的な仕事にはモチベーション が重要となる チームの動機づけ 「TSPガイドブック:リーダー編」 より ワッツ・S・ハンフリー著 秋山義博監訳 JASPIC TSP研究会訳 76
  77. 77. コミットメント 個人とチームが約束したことをやりたいと思う気持ち 動機づけの種類 恐怖 指示したとおりにタスクを完了しないと職を失うぞ! 思考停止反応を引き起こす 保身的な行動や非合理な行動さえ生じさせる 金銭欲 もっと稼げると思うやり方で仕事をする ノルマ分だけ働く 必要な努力を最小にして最大報酬を得ようとする 「TSPガイドブック:リーダー編」 より ワッツ・S・ハンフリー著 秋山義博監訳 JASPIC TSP研究会訳 77
  78. 78. どのように動機づけをするかが重要 ソフトウェア開発では予期せぬことがあるのが普通 予期せぬことには時間と工数がかかるというのが常識 いかに注意深くコミットメントを作っておいても、 最後は超人的な努力が必要となる場面もある では、開発者はどうしてそんな無理をしてくれるのか? コミットメントで動機づけされているから この動機づけがないと、開発者が燃え尽きてしまうこともある コミットメント チームのコミットメントの方が 個人のコミットメントより動機づける力が強い 「TSPガイドブック:リーダー編」 より ワッツ・S・ハンフリー著 秋山義博監訳 JASPIC TSP研究会訳 78
  79. 79. 個人の目的を、チームの目標達成に融合させて、 最大のパフォーマンスを発揮するためのもの チームのコミットメント メンバー全員が 共通のゴールに向けて、 仕事をしている 効果的な協同作業を行うための プロセスがあり、遵守している 成果物やプロセスは、 素早いフィードバックで、 常に改善されている 79
  80. 80. KPTは成長を促すツール  Keepで、チームとしての共感を得る よかったことを褒めあうと、チームを信頼できる  Problemを共有する 問題を誰かのせいにするのではなく、チームの問題であると認識する  そして、みんなでTry! 誰かがやってくれる、のではなく、自分が、そして誰もがやる! 80
  81. 81. プロジェクトのリズムを使った成長 ☞ 定期的に実施する – 続けるためには、習慣にしてしまう – 一定期間の短いリズムでふりかえる ☞ 「歩み」を実感しつづける – 成長していることは、自信につながる 81
  82. 82. 結合テストシート KPT みえる化 昼会 課題管理表 SPL朝会 改善プラン トップダウンか ボトムアップか? トップダウン ボトムアップ Redmine改良 エンジニアリング 82 事例
  83. 83. 座談会 課題などについて、ユニットL、有識者、 SPLとで意見交流をする「場」 83 ポイント:自由な雰囲気の中での、真剣な話し合い 就業時間内に開催、時間厳守 「会議」にならない配置、お菓子も用意した方がベター SPLは進行係として「和気あいあい」を徹底、 全員が意見を自由に発言できるようにふるまう どんな意見が出ても「否定しない」 いい意見が出たら「褒める」 いい案がまとまったら、実行計画をすぐにまとめて、 アクションプランを作成してしまう。 時間内に何もまとまらなかったら、次の機会を作る トップダウンか ボトムアップか? 事例
  84. 84. 面談 個対個の面談で、 思いを引き出す「場」 84 ポイント プロセス改善担当者が開発メンバー全員と面談 目的:組織方針について、どんな考えを持ってるのか、 仕事に何を期待しているのか、正直な意見を引き出す。 聴き手(プロセス改善担当者)のスタンス: 相手に関心を持つ どんな意見でも受け入れて、さらに引き出す 褒める メンバーの様々な想いを引き出し、まとめて、 組織改善プランにフィードバックする 全員に自分たちの「改善計画」だと認識してもらう 事例トップダウンか ボトムアップか?
  85. 85. 85 最初は個人ごとに様々な目標を持っている チームは偶然にできあがるものではない チームを作り上げるには時間がかかる プロジェクトを推進しながら、チームの成長を促す仕組みを取り 込むことが重要 朝会(スタンダップミーティング) チームの評価 チーム全員が「メンター」になり、お互いのスキルアップを促す役割を担う 事例チームの成長を促す
  86. 86. 定常的なFace to Faceのコミュニケーション チーム全員が集まって情報を交換する効果的な方法 立ったままで短時間で済ませる(目安15分) 主に確認事項は3つ 昨日やったことは? 今日やることは? 進捗が遅れている問題点は何? 検討が必要な課題は別途、打合せの場を設定 問題を抱えている場合は、積極的に助力を求める チーム全員が他のメンバーが何をしているか知ることができる 86 事例チームの成長を促す ~朝会~
  87. 87. Keep Problem Try 87 KPTの時にメンバーに確認してみる 新しいチームほど定期的に評価 フィードバックと改善を継続 チームの評価ポイント 全員、チームのメンバーだと共通の意識がある? 全員が共通のゴールに対してコミットしてるか? チームの中で発生した問題を自分たちで解決してる か? 信頼関係が築かれているか? 正直であること(知らないことは聞く) ありのままであること(誰でもミスはするもの) チームのアイデアや意見が尊重されていること 事例チームの成長を促す ~チームの評価~
  88. 88. 88 チームで効果的な協同作業をする 効果的な協同作業のために個々のスキルを高める 初心者でも「メンター」になれる エキスパートに質問することで、彼らを刺激し動機づけられる エキスパートは他のメンバーに教えることで、 逆に自分も知識を深めることができる 問題に対して、解決のために全員で惜しみなく 知識を分け合うことは、メンバーだけでなく チームワークのスキルアップにつながる 最初はスクラムマスターが「メンター」を担い、いずれは全員が! 事例チームの成長を促す ~チーム全員が「メンター」~
  89. 89. ワークショップ 89 レゴスプリント ここで一度
  90. 90. 90 やってみないとアジャイルはわからない!
  91. 91. メンバーで 最終ゴールをイメージする
  92. 92. レゴスプリント レゴを使ったグループワーク 『最高の飛行機を作ってください!』 92
  93. 93. このグループで・・・ どんな 最高の飛行機 つくる? 5分 『Smiling Adventure』を使ってみましょう! 93
  94. 94. 【お客様は誰?】 ① フォーマットに合わせて、みんなで ディスカッションをしてみましょう ② 「お客様は誰ですか?」は、 名前など特定できればOK ③ 「どんな人ですか?」「求めているもの はどんなもの?」を具体化していきま しょう ④ 1人だけとは限りません いろいろなパターンを考えてみましょう ご参考 94
  95. 95. 【お客様のハッピー】 ① 「お客様は誰?」の結果を書きましょう ② お客様はどんなことをやってみたいと 思っていますか? 求めているものは? ③ みなさんがつくり出すもので、どんなこ とが実現できますか? ④ 実際にお客様が使ってみると、 どんな気持ちになりますか? ご参考 95
  96. 96. 【ストーリーテラー】 ① フォーマットに合わせて、 シンプルに書いてみましょう ② 結果をもとに具体的なディスカッション につなげてみましょう ご参考 96
  97. 97. ビジネスゴールを常に意識した開発 プロジェクトメンバーと 最終形態を一緒に描くことで、 プロジェクトの基礎固めができる ゴールを共有できてるかどうかは プロジェクトに大きく影響する グループワークからのポイント 97
  98. 98. みんなで描いたゴールをもとに 「タスクをピックアップ」 5分 レゴ飛行機は 約10分×2回で開発します! 2回とも(完成)させます 98
  99. 99. グループワークからのポイント みんなで考えること みんなの得意分野は何? 計画段階はイメージ力が重要 短いサイクルでの繰り返し開発には工夫が必要 99
  100. 100. ソフトウェアかんばん ToDo 未実施 Doing 実施中 Done 完了 サザエ カツオ ワカメ 【使い方】 ① カードを未実施に貼る ② 実施する前に実施中にカードを移動する ③ タスクが完了したら完了に移動する ※ 貼りかえはリアルタイムに 100
  101. 101. KPTはプロセスを適応させるツール  Keepで、チームとしての共感を得る よかったことを褒めあうと、チームを信頼できる  Problemを共有する 問題を誰かのせいにするのではなく、チームの問題であると認識する  そして、みんなでTry! 誰かがやってくれる、のではなく、自分が、そして誰もがやる! 101
  102. 102. グループワークからのポイント ほめると伸びる+欠点も認める 行動(スイッチ)につながる 「人」に視点を置くからこそ「成長」もできる 102
  103. 103. 『最高の飛行機」を 作ってください! 10分×2回  10分×2イテレーション  朝会+タスクの確認(1分)  グループ作業(6分)  KPT(3分)  KPTの「ふりかえり」は2回目に反映!  かんばんも活用してください
  104. 104. ご完成 おめでとう ございます
  105. 105. -四- 品質アプローチ
  106. 106. 平鍋さんブログ「An Agile Way」より http://blogs.itmedia.co.jp/hiranabe/2012/09/rightwing-and-leftwing-of-agile.html アジャイルのライトウィング 106
  107. 107. 技術品質を継続的にキープする • コーディングミスが発生しにくい • コーディングでの誤り混入から 発見までの時間が短い (数分~数10分程度) • コードの可読性が向上する 107 スプリント デイリー スクラム テスト駆動開発 (Test Driven Development) ペアプログラミング • コードがきれいになる (レビュー率100%) • システムやコード、ツールなど の知識を共有できる • ペアの組み方によっては、 トレーニングの効果を得られる • コミュニケーションが活発になり 一体感を生み出す • 1人で悩んで停止しまうことが 少なくなり作業が着実に進む コードの共同所有 その他にもノウハウはたくさん 作るもの、プロジェクトに合わせ 自分たちでプラクティスを活用していく
  108. 108. Doneの定義  ストーリへの「完了条件を定義してない」 「共有していないこと」がズレの始まりに・・・  どんなテストを完了していますか?  レビューは完了していますか?  お客様視点で動作できますか? 『Doneの定義』を明確に!
  109. 109. 対立構図から「問題対私たち」へ 109
  110. 110. 製品品質を継続的に確かめ、価値をあげる  スプリントごとに価値をフィードバックするには?  価値が確認できるレベルに動作していること  シンプルに設計し、リファクタリングができること  今必要としていないものをムダに作りこまないこと デバイスドライバ ライブラリ アプリケーション レイア単位ではなく ファンクション単位で
  111. 111. -五- 価値を描く
  112. 112. もちろんメーカーとしてのメリットもある!  ブランドの力はやっぱりすごい!  技術力は世界トップレベル!  ターゲットに応じて 組織体制を変えることができる!  マーケティングの4Pは手の内に!  お金ありまっせ! 112
  113. 113. 最も強い者が生き残るのではなく、 最も賢い者が生き延びるのでもない。 唯一生き残ることが出来るのは、 変化できる者である。 チャールズ・ダーウィン しかも、自分たちだけでなく、まきこめるかどうかも重要
  114. 114. ものづくり日本
  115. 115. みなさんがつくっているものの価値はなに?
  116. 116. システムの機能の利用度 全く使われない 45%ほとんど使われな い 19% たまに使う 16% いつも使う 7% よく使う 13% Standish group study report in 2000 chaos report システム開発と組込み開発の違い 116 「たまに使う」に意味があったりしませんか?
  117. 117. 117 これだとどう思いますか? 1.世界初 4Kミラーレス一眼 2.他社に負けないAFスピード 3.動画プロフェッショナル対応 ※実際のコンセプトとは違います
  118. 118. 製品の価値を最大化するには? 118
  119. 119. 変化を味方につける(価値の共有) お客様の価値の最大化を考える 変化は当然(必要)ととらえ、 すばやく変化を取り入れられるように進める 119
  120. 120. 変化を味方につける(開発側から) 120
  121. 121. 「Why」を考えてみる どうなりたいか(BE)がベースになる  Why なぜ作らなければ ならないのか? 企業・組織としての Why 個人としての Why – 利益をあげねば – 競合他社に勝つ – 生産性をあげる – 高品質な商品 – リーダとしての成功 – 新しい技術を得る – 自分の時間を作る – 残業しても高収入 いやなことはしたくない・・・ パワーを引き出す「素」は 結局のところ「欲求」につながる スポーツ ゲーム 趣味 家族 勉強 仕事 121
  122. 122. 「Why」の影響 Why?企業・組織としての Why 個人としての Why ビジネスで成功 自己成長 チーム成長 業績アップ 自分の時間 あせり・指示 やらされ感 Command Control 思考停止 成長停止 二つのプラスが マッチングしたとき 最高スペックに! 122
  123. 123. クレドを作ろう! みなさんとやりたいこと
  124. 124. 1.メンバを信頼し、リスペクトする Sample
  125. 125. 2.勇気をもってまわりを巻き込む Sample
  126. 126. 3.ビジネスとしての 成果を意識する Sample
  127. 127. 4.チームは1+1を2以上にしてくれる Sample
  128. 128. 5.チームの笑顔がお客様の笑顔につながる Sample
  129. 129. ハード部門や工場など 関連部門とは どうしたらいいのか? 上司にどう説明すれば、 アジャイルを 導入できるのか? SQAはどこでステップ移行 監査や品質をチェック すればいいのか? 既存の組織プロセスが あるけど、 どうしたらいいの? ~組織編~ 組込み開発だと顧客 が明確でない場合 のフィードバックとは 誰がするのか? こんな不安、疑問を持たれてませんか?(こたえ) 129 価値やゴールを もっと共有しませんか? フィードバックも重要です 上司が 目指すものは? あなたが目指すものは? ステップ移行も変化します タイムボックスを 有効に活用しましょう 大きく変える必要は ありません 何を変えるべきか ふりかえりましょう 顧客が明確でない 製品を作っているの? 価値判断できる人は?
  130. 130. 品質確保できるのか? 開発を委託している場合、 どうしたらいいのか? 委託元の役割とは? 要素開発で、ハード系 仕様がなかなか決まら ない、変更が激しい場 合はどんな形で導入し たらいいのか? アジャイルを熟知している 人がいないと、上手く いかないのでは? ~開発現場編~ こんな不安、疑問を持たれてませんか?(こたえ) 品質も含めて タイムボックスで フィードバックします 目指す価値は同じはず お互いの役割を明確にして リズムを共有しましょう 今必要としていることを 明確にして できるところからシンプルに! 何度か繰り返すと 形ができるはず 最後までそうではないです 一人ひとりがメンターを 目指しましょう! 130
  131. 131. 131 アジャイルとは、 お客様のビジネス価値を最大化するための 「考え方」や「姿勢」のこと
  132. 132. アジャイルは 現場駆動 人駆動 です
  133. 133. 変化を受け入れるのではなく 社会に対して変化を生み出していく 組込みだから、アジャイルっしょ。 133
  134. 134. 実践こそが アジャイル!  価値について考える  お客様はだれ?  ユーザーにとっての価値は?  考える習慣、意識を継続  まずは簡単なことからでもOK 実践してみる!  声のかけかた、会議のしかけな どでも現場は変わる  ボトムアップが組織を変える!
  135. 135. 13 5 Social Change starts with YOU!! 「未来」は自分たちで描き、自分たちの手で変化を生み出そう! 135 ご清聴ありがとうございました

×