Osaka-No001-01-suc3rum-20100616

1,374 views
1,310 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,374
On SlideShare
0
From Embeds
0
Number of Embeds
23
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Osaka-No001-01-suc3rum-20100616

  1. 1. 大阪すくすく・スクラム 第1回ワークショップ セントラルソフト株式会社 公開用資料 事業推進部 林 栄一 すくすく・スクラム スタッフ 名付け親2010年6月22日火曜日
  2. 2. クリエイティブな仕事したい人?2010年6月22日火曜日
  3. 3. 自己紹介2010年6月22日火曜日
  4. 4. 自己紹介 楽器メーカーで開発業務 4年半ほど 陶磁器の卸 父の会社を継ぐ 2年ぐらい JR関係の研究開発 2年ぐらい シンセサイザーオペレータ 1年ほど ネットワーク保守業務 1年ほど 現職 ただいま12年目2010年6月22日火曜日
  5. 5. やってきたもの(開発)2010年6月22日火曜日
  6. 6. やってきたもの(開発) • 電子楽器の開発 • ドラムマシン、エフェクター、カラオケアンプ • JR関連 • デジタルATS、リニアモーターカー運行システム →OMTで 設計 • フレームワークの開発 • 10年ほどまえ、IOCコンテナをベースとしたJavaとVBを シームレスにつなくコンポーネントフレームワーク • 業務アプリ • 大規模基幹業務開発、標準化 • 大規模基幹業務向けEJBフレームワークの開発 • 物流系、薬局関連、製造業関係 • 音響制御系 •2010年6月22日火曜日 サラウンドミキサー装置 →愛地球博NHKパビリオンで上映
  7. 7. 2010年6月22日火曜日
  8. 8. 現在 セントラルソフト株式会社 事業推進部 課長 ★ワンポイント・ストレスケア!(ミニセミナー5分) ストレスと疲労の違いって?ストレスの発散法?などストレスケアの方法や すくすく・スクラム スタッフ(月1で勉強会) ドラムサークル α プラス 理学などを知って、仕事や生活をエンジョイしましょう。心の専門家の秘伝 目からうろこの実践ポイントを伝授します! シリーズ化決定! 参加者が輪になってパーカッションのアンサンブルを即興的に作り上げます。打楽器などの経験は全く必要ありません。誰でも安心し て楽しめるようにファシリテーターがガイドいたします。一体感を感じながら共に楽しみ、打ち解けることができます。そして心の扉を開 DCFA認定ドラムサークルファシリテーター き、コミュニケーションを促進していくことに喜びを感じます。 ●こんな人集まれ! 運動不足の方、ストレスがた ご案内 まっている方、音楽が好きな 方、仕事で嫌なことがあった方 NLP認定プラクティショナー リング効果、仲間づくりによ ≪新宿≫ る一体感、孤独感の解消、リ ラックス効果、運動不足解消、 ●日 時 : 2010年 1 月 31 日 日曜日 抗うつ対策、肩こり軽減・改善 などの効果が期待できます。 16:15 開場 16:30 スタート 18:00 終了 認定スクラムマスター ●場 所 : スタジオノード新宿店5F 東京都新宿区西新宿7-16-7 http://www.studio-node.com/ 西武新宿線西武新宿:220m 都営大江戸線新宿西口:380m JR 総武線大久保:480m ●定 員 : 25名様限定!※定員になり次第締め切らせていただきます。申込順(基本、メールにてお申し込みください) 要求開発アライアンスコアメンバー ●参加費 : 3,000円/人 2回目以降参加者 2,500円/人 ※当日集金 ♪ストレスケア・ドラムサークルのファシリテーター紹介♪・・・その② 申込・お問い合わせ 尾崎 !"#"$$元章 %&($)*$+,--&.. BOSサポートメンバー(トレーニングビート) ファシリテーター トレーニング・ビート メイントレーナー %&($)*$+,--&.. !"#"$"%ドラムスクール主宰。多くのドラマーを育てるとともに、ド ラムサークルの普及にも努め、神奈川の地域誌にも紹介される。現 &()**+++",-./"-01 在までに小中学校・相模原市大田区・目黒区・世田谷美術館・神奈 川県立藤野芸術の家等のイベントでもドラムサークルを行う。 【基本はメールにてお申込くださ 教育とか開発とかスクラムとか、スクラム導入コーチ info@bos1.org TEL:03‐3516‐841 〒103-0022 東京都中央区日本橋 1-6-13 井上第二ビル6F とかもろもろやってます。2010年6月22日火曜日
  9. 9. トロントAGILE 2008 EM ZERO VOL.2 XP祭り 2008 XP祭り 2009 Thanks チームの皆へ 送り出してくれた人達へ 今日聞いてくれた人達へ (撮影KKD) 要求開発アライアンス DEVLOVE 2008 TFPモデリングスペキュレーション 2007年 人とのつながりの奇跡に感謝(LT) 要求開発マスター認定制度への提案 2008年 オブラブ すくすく・スクラム スクラム基礎+朝会ワークショップ ドラムサークルとプロジェクトファシリテーション(2007/06LT) 自己組織化ワークショップ 短期に低価格で持ち家建設を行うためのパターンランゲージ ウォーターフォールとアジャイル (2009/01 LT)2010年6月22日火曜日
  10. 10. もくじ なぜ?すくすくスクラム スクラム基礎理論 朝会ワークショップ2010年6月22日火曜日
  11. 11. EM ZERO VOL22010年6月22日火曜日
  12. 12. EM ZERO VOL2新しい手法を試し、検証し、適用する姿勢はとても大切ですが、それを一発で解決する「銀の弾丸」と思うのは望ましくありません。いつでも一番大切なのは、今目の前にいるチームメンバーと何をするのかということだと思うのです。2010年6月22日火曜日
  13. 13. 特定のやりかたが どんな場合でも うまくいくとは かぎりません。2010年6月22日火曜日
  14. 14. 自分の頭で考えよう!2010年6月22日火曜日
  15. 15. 同じプロジェクトは 一生に1回だけ 何をどう使うか! どうやって 適応させるか!2010年6月22日火曜日
  16. 16. そのためには、 なぜそうなのかを 「理解」 することが重要。2010年6月22日火曜日
  17. 17. それが!2010年6月22日火曜日
  18. 18. すくすく スクラム2010年6月22日火曜日
  19. 19. ツールとスキル 2009 XP祭り LT資料 より 林栄一2010年6月22日火曜日
  20. 20. ツール?2010年6月22日火曜日
  21. 21. スパナ2010年6月22日火曜日
  22. 22. スパナ2010年6月22日火曜日
  23. 23. ねじまわし2010年6月22日火曜日
  24. 24. ねじまわし2010年6月22日火曜日
  25. 25. 方法論2010年6月22日火曜日
  26. 26. 指向2010年6月22日火曜日
  27. 27. 駆動開発2010年6月22日火曜日
  28. 28. 工学2010年6月22日火曜日
  29. 29. How To2010年6月22日火曜日
  30. 30. すべて広義の ツールの一種2010年6月22日火曜日
  31. 31. すべて広義の ツールの一種2010年6月22日火曜日
  32. 32. どんなに良い道具でも 体で理解しないと 得られない領域がある。 おな じくらい 大事 ツール スキル 技2010年6月22日火曜日
  33. 33. だから!2010年6月22日火曜日
  34. 34. すくすく スクラム2010年6月22日火曜日
  35. 35. グループワーク1 プロジェクトの課題、悩み 模造紙 プロジェクトの課題、悩み ココに書く2010年6月22日火曜日
  36. 36. 第1部 スクラム基礎2010年6月22日火曜日
  37. 37. スクラム2010年6月22日火曜日
  38. 38. スクラムとは  アジャイルプロセスの一つ  日本の製造業の製品開発手法をソフトウエア開発に応用した方 法論   竹内弘高・野中郁次郎 The New New Product Development Game 1988  Jeff Sutherland と Ken Schwaber がOOPSLA 1995 に て発表  プロジェクトをチームで進めるためのシンプルなマネジメント フレームワーク  ビジネスの変化、今ある状況に対応する2010年6月22日火曜日
  39. 39. http://www.versionone.com/pdf/2009_State_of_Agile_Development_Survey_Results.pdf VersionOne2009 資料2010年6月22日火曜日
  40. 40. スクラムの基礎となる 価値2010年6月22日火曜日
  41. 41. スクラムの基礎となる 価値 •自己組織化、自発的決定2010年6月22日火曜日
  42. 42. スクラムの基礎となる 価値 •自己組織化、自発的決定 •予測型   実測駆動2010年6月22日火曜日
  43. 43. スクラムの基礎となる 価値 •自己組織化、自発的決定 •予測型   実測駆動 •そのときどきの状況にあわせて計画し つづける2010年6月22日火曜日
  44. 44. スクラムの基礎となる 価値 •自己組織化、自発的決定 •予測型   実測駆動 •そのときどきの状況にあわせて計画し つづける •問題の原因はプロセスや技術ではなく人 間に依存する2010年6月22日火曜日
  45. 45. スクラムの3つの柱2010年6月22日火曜日
  46. 46. スクラムの3つの柱 •透明性2010年6月22日火曜日
  47. 47. スクラムの3つの柱 •透明性 •プロセスを見える化2010年6月22日火曜日
  48. 48. スクラムの3つの柱 •透明性 •プロセスを見える化 •一定していて明確な完了の定義2010年6月22日火曜日
  49. 49. スクラムの3つの柱 •透明性 •プロセスを見える化 •一定していて明確な完了の定義 •検査2010年6月22日火曜日
  50. 50. スクラムの3つの柱 •透明性 •プロセスを見える化 •一定していて明確な完了の定義 •検査 •頻繁に検査2010年6月22日火曜日
  51. 51. スクラムの3つの柱 •透明性 •プロセスを見える化 •一定していて明確な完了の定義 •検査 •頻繁に検査 •うけいれ難い変化をすぐに検知2010年6月22日火曜日
  52. 52. スクラムの3つの柱 •透明性 •プロセスを見える化 •一定していて明確な完了の定義 •検査 •頻繁に検査 •うけいれ難い変化をすぐに検知 •適応2010年6月22日火曜日
  53. 53. スクラムの3つの柱 •透明性 •プロセスを見える化 •一定していて明確な完了の定義 •検査 •頻繁に検査 •うけいれ難い変化をすぐに検知 •適応 •プロセスをすぐに調整2010年6月22日火曜日
  54. 54. スクラムの プロセス概要 実測駆動管理ー今ある正直な状況から次! ROIからみた優先順位で小出しリリース 振り返りと調整、改善の繰り返し 2∼4週間ごとの納品 管理しない管理、自発性、チーム主体 チームの責任と権限2010年6月22日火曜日
  55. 55. スクラムのプロセス2010年6月22日火曜日
  56. 56. 皿に取っ  スクラムの流れを大まかに示すと図1 いつでも納品可能な状態を維持する理がない、つい和 スクラムのプロセス ■図1 スクラムの流れのお皿を ※認定スクラムマスター のテキストを元に筆者が 作成。 デイリー手法を適 スクラム (24時間ごと)います。しい手法紹介され スプリント スプリントバックログのお皿に (4週間) スプリントのようとし 終わりに 新しい機能を。 デモ 選択されたラクティ プロダクトバックログカスタマ。いわゆです。ほ同じ難し プロダクト バックログを組むこしかない対処して EM ZERO Vol.2 より引用 2010年6月22日火曜日
  57. 57. スクラムのロール ユーザー プロダクト オーナー スクラム 開発チーム マスター2010年6月22日火曜日
  58. 58. スクラムのロール • スクラムマスター  スクラム推進のキーパーソン • プロダクトオーナー  成果物の責任者 • スクラムチーム  開発を行う主役2010年6月22日火曜日
  59. 59. スクラムマスター  プロジェクト管理者ではい − チームによる自己管理 − 内部調整 − 他の人や他のチームとの調整  権限無い⇒チームが決める  指示型⇒促進型  組織変革の主役2010年6月22日火曜日
  60. 60. プロダクトオーナー •スプリントごとに機能と優先順位を変える権限 を持つ •完成イメージと方向性を把握している •プロダクトの収益性に関する(ROI)責任者 •リリースの内容と日付を決める2010年6月22日火曜日
  61. 61. ミーティングフロー スプリントプランニング デイリースクラム (朝会) スプリントレビュー スプリントレトロスペクティブ (反省会)2010年6月22日火曜日
  62. 62. プロダクトバックログ  高い バックログ項目 バックログ項目 バックログ項目 優 バックログ項目 先 バックログ項目 順 位 バックログ項目 バックログ項目 バックログ項目 バックログ項目 低い ...2010年6月22日火曜日
  63. 63. プロダクトバックログ  高い バックログ項目 バックログ項目 バックログ項目 優 バックログ項目 先 バックログ項目 順 位 バックログ項目 バックログ項目 バックログ項目 バックログ項目 プロダクト 低いオーナーが決 める ...2010年6月22日火曜日
  64. 64. プロダクトバックログ  スプリントプラ 高い バックログ項目 ンニングミーティン グで、チームが項目 バックログ項目 ごとの「規模」を見 バックログ項目 優 積もって、そのスプ バックログ項目 先 リントの範囲を決め バックログ項目 る 順 位 バックログ項目 バックログ項目 バックログ項目 バックログ項目 プロダクト 低いオーナーが決 める ...2010年6月22日火曜日
  65. 65. プロダクトバックログ  スプリントプラ 高い バックログ項目 ンニングミーティン グで、チームが項目 バックログ項目 ごとの「規模」を見 バックログ項目 優 積もって、そのスプ バックログ項目 先 リントの範囲を決め バックログ項目 る 順 位 バックログ項目 バックログ項目 アジャイルよく使わ バックログ項目 れる見積もり手法: バックログ項目 ・相対規模見積もり プロダクト 低い ・プランニングポーカーオーナーが決 める ... ・理想時間見積もり2010年6月22日火曜日
  66. 66. プロダクトバックログ  「スクラム入門」川口泰伸 より引用2010年6月22日火曜日
  67. 67. プロダクトバックログ • 機能、問題点の一覧表 • プロダクトオーナーが優先順位を決める • だれでも追加できる • 常時更新され、目に入るところに提示 • ビジネスプランまたは事業方向性をもとに 作られる2010年6月22日火曜日
  68. 68. スプリントバックログ  バックログ項目 バックログ項目 バックログ項目 バックログ項目 バックログ項目 バックログ項目 バックログ項目 バックログ項目 バックログ項目 ...2010年6月22日火曜日
  69. 69. スプリントバックログ  タスク バックログ項目 タスク バックログ項目 タスク バックログ項目 バックログ項目 タスク バックログ項目 タスク バックログ項目 タスク バックログ項目 タスク バックログ項目 タスク バックログ項目 タスク ... タスク2010年6月22日火曜日
  70. 70. TODO DOING DONE タスク タスク タスク タスク タスク タスク タスク タスク タスク タスク2010年6月22日火曜日
  71. 71. kkd さんの資料より2010年6月22日火曜日
  72. 72. スプリントバックログ プロダクトバック ログ項目 タスク その時点の残2010年6月22日火曜日
  73. 73. バーンダウンチャート  スプリントバーンダウン 3 42010年6月22日火曜日
  74. 74. バーンダウンチャート  毎日その時点の残(※規模)を 合計してプロットする。 スプリントバーンダウン 全体の割合の変化ではなくて、 その時点時点の残工数を見る点 が実測駆動。 タスクの残ではなくタスクの完 了でプロット 完了の定義重要。 3 42010年6月22日火曜日
  75. 75. バーンダウンチャート  毎日その時点の残(※規模)を 合計してプロットする。 スプリントバーンダウン 全体の割合の変化ではなくて、 その時点時点の残工数を見る点 が実測駆動。 タスクの残ではなくタスクの完 了でプロット 完了の定義重要。 ※規模 ・規模を抽象化した「ポイン ト」の合計をプロットする。 具象時間、工数でプロットしな い方がよい。 3 42010年6月22日火曜日
  76. 76. デイリースクラム(朝会)  毎日の15分だけの状況報告ミーティング • 同じ場所、同じ時間 • 3つの質問  ‒ 前回からなにをしたか  ‒ 次回まで何をするか  ‒ 課題になっていること2010年6月22日火曜日
  77. 77. スプリントレビュー  •ユーザーにスプリントで作ったものをデモする • 開発者とユーザーが直接話しをする2010年6月22日火曜日
  78. 78. スプリント レトロスペクティブ • スプリントが終わる度によりよいプロセスへ • スクラムマスターがファシリテートする • 良い点と改良できる点を洗い出す2010年6月22日火曜日
  79. 79. ミーティングフロー スプリントプランニング デイリースクラム (朝会) スプリントレビュー スプリントレトロスペクティブ (反省会)2010年6月22日火曜日
  80. 80. ミーティングフロー プロダクトバックログ スプリントプランニング スプリントバックログ デイリースクラム (朝会) TODO DOING DONE スプリントレビュー スプリントレトロスペクティブ (反省会) アプリケーション2010年6月22日火曜日
  81. 81. プランニングオニオン 必要な期間を必要な精度で計画し続ける。 フューチャーの セットを1 2週間単 位で計画 2∼3時間 精度のタスクを1 日の初めに計画 EM ZERO Vol3.1より引用2010年6月22日火曜日
  82. 82. 目的 目的 目標2010年6月22日火曜日
  83. 83. 目的 目的 ∼のために 目標2010年6月22日火曜日
  84. 84. 目的 目的 ∼のために 目標 ∼までにこの目標を達成する2010年6月22日火曜日
  85. 85. 要求の基本 戦略 オペレーション ビ ジ ネ ス シ ス テ ム 要求開発 資料より2010年6月22日火曜日
  86. 86. 要求の基本 戦略 オペレーション ビ ジ ビジネス戦略 ネ ス シ ス テ ム 要求開発 資料より2010年6月22日火曜日
  87. 87. 要求の基本 戦略 オペレーション ビ ジ ビジネス戦略 ビジネスオペレーション ネ ス シ ス テ ム 要求開発 資料より2010年6月22日火曜日
  88. 88. 要求の基本 戦略 オペレーション ビ ジ ビジネス戦略 ビジネスオペレーション ネ 表(価値) What  How 裏(実現) ス シ ス テ ム 要求開発 資料より2010年6月22日火曜日
  89. 89. 要求の基本 戦略 オペレーション ビ ジ ビジネス戦略 ビジネスオペレーション ネ 表(価値) What  How 裏(実現) ス シ ス システム要求 テ ム 要求開発 資料より2010年6月22日火曜日
  90. 90. 要求の基本 戦略 オペレーション ビ ジ ビジネス戦略 ビジネスオペレーション ネ 表(価値) What  How 裏(実現) ス What 表(価値)   裏(実現) How シ ス システム要求 テ ム 要求開発 資料より2010年6月22日火曜日
  91. 91. 要求の基本 戦略 オペレーション ビ ジ ビジネス戦略 ビジネスオペレーション ネ 表(価値) What  How 裏(実現) ス What 表(価値)   裏(実現) How シ ス システム要求 システム設計 テ ム 要求開発 資料より2010年6月22日火曜日
  92. 92. 要求の基本 戦略 オペレーション ビ ジ ビジネス戦略 ビジネスオペレーション ネ 表(価値) What  How 裏(実現) ス What 表(価値)   裏(実現) How シ ス システム要求 システム設計 テ ム 表(価値) What  How 裏(実現) 要求開発 資料より2010年6月22日火曜日
  93. 93. スクラムでは 戦略 オペレーション ビ ジ ビジネス戦略 ビジネスオペレーション ネ 表(価値) What  How 裏(実現) ス What 表(価値)   裏(実現) How シ ス 機能など タスク テ (バックログ項目) ム 表(価値) What  How 裏(実現)2010年6月22日火曜日
  94. 94. チーム2010年6月22日火曜日
  95. 95. 自己組織化2010年6月22日火曜日
  96. 96. 通常の開発体制 PM 長期にわたる 指示 報告 だれが、何を、いつ 詳細な計画と指示 開発メンバー プロパー 協力会社 メンバー間のコミュニケーション2010年6月22日火曜日
  97. 97. スクラム スクラムマスター スプリントごとの タスクカンバン バックログから 日々タスクを選択 開発チーム プロパー 協力会社 メンバー間のコミュニケーション2010年6月22日火曜日
  98. 98. スクラム2010年6月22日火曜日
  99. 99. 主な責任部分 戦略 オペレーション ビ ジ ネ ス 表(価値) What  How 裏(実現) What 表(価値)   シ 裏(実現) How ス テ ム 表(価値) What  How 裏(実現)2010年6月22日火曜日
  100. 100. 主な責任部分 戦略 オペレーション ビ ジ ネ 経営層 業務担当 ス 表(価値) What  How 裏(実現) What 表(価値)   シ 裏(実現) How ス テ プロダクトオーナー 開発チーム ム 表(価値) What  How 裏(実現)2010年6月22日火曜日
  101. 101. 主な責任部分 戦略 オペレーション POの 調整範囲 ビ ジ ネ 経営層 業務担当 ス 表(価値) What  How 裏(実現) What 表(価値)   シ 裏(実現) How ス テ プロダクトオーナー 開発チーム ム 表(価値) What  How 裏(実現)2010年6月22日火曜日
  102. 102. 主な責任部分 戦略 オペレーション POの 調整範囲 ビ ジ ネ 経営層 業務担当 ス 表(価値) What  How 裏(実現) What 表(価値)   シ 裏(実現) How ス テ SMの プロダクトオーナー 開発チーム ム 表(価値) What  調整範囲 How 裏(実現) スクラムマスター2010年6月22日火曜日
  103. 103. 顧客潜在 主な責任部分 ニーズ 表(価値) What  戦略 オペレーション POの 調整範囲 ビ ジ How 裏(実現) ネ 経営層 業務担当 ス 表(価値) What  How 裏(実現) What 表(価値)   シ 裏(実現) How イノベーション    ス テ SMの プロダクトオーナー 開発チーム ム 表(価値) What  調整範囲 How 裏(実現) スクラムマスター2010年6月22日火曜日
  104. 104. オブラブ2010アレグザンダー祭りの懇親会でスクラム トレーナーのジム・コプリンエン氏から聞いた言葉 それだけ、組織にインパクト がある変革が必要な場合があ るという意味です。 真に受けてやりすぎないよう に!w2010年6月22日火曜日
  105. 105. 権限2010年6月22日火曜日
  106. 106. 権限の逆転? • スクラムでは、チームに権限があってス クラムマスターにはない。 • これって通常組織で可能なの? ここらへんからは私個人の私 見です。 みなさんの状況であうかどう かは各自でご判断を。2010年6月22日火曜日
  107. 107. 通常の開発体制 権限 組織の 指示、発注 PM(課長) 上下関係 契約関係 開発メンバー プロパー 協力会社2010年6月22日火曜日
  108. 108. スクラム 権限なし スクラムマスタ(課長) スクラムチーム 権限あり プロパー 協力会社2010年6月22日火曜日
  109. 109. スクラム 権限なし 組織の スクラムマスタ(課長) 上下関係 契約関係 スクラムチーム 権限あり プロパー 協力会社2010年6月22日火曜日
  110. 110. たとえスクラム スクラム でもこの関係は変 えられない 権限なし 組織の スクラムマスタ(課長) 上下関係 契約関係 スクラムチーム 権限あり プロパー 協力会社2010年6月22日火曜日
  111. 111. こういうこと? 権限なし スクラムマスタ(平社員、契約社員) 組織の 上下関係 契約関係 スクラムチーム 権限あり 部長 課長 社長 次長2010年6月22日火曜日
  112. 112. 矛盾2010年6月22日火曜日
  113. 113. スクラム 権限なし (本当はある) スクラムマスタ(課長) スクラムチーム 権限あり (本当はない) プロパー 協力会社2010年6月22日火曜日
  114. 114. スクラム 権限なし (本当はある) スクラムマスタ(課長) 指示 スクラムチーム 権限あり (本当はない) プロパー 協力会社2010年6月22日火曜日
  115. 115. スクラム 権限なし (本当はある) スクラムマスタ(課長) 指示 スクラムチーム 権限あり (本当はない) プロパー 協力会社2010年6月22日火曜日
  116. 116. スクラム 権限なし (本当はある) スクラムマスタ(課長) 質問、 指示 促し スクラムチーム 権限あり (本当はない) プロパー 協力会社2010年6月22日火曜日
  117. 117. スクラム 権限なし (本当はある) スクラムマスタ(課長) 質問、 回答、 指示 促し 提案 スクラムチーム 権限あり (本当はない) プロパー 協力会社2010年6月22日火曜日
  118. 118. あれ?2010年6月22日火曜日
  119. 119. これってうまく いってる普通の 組織じゃん ただし、このよう に、うまく行ってい る組織はあまり多く ないのが現状?2010年6月22日火曜日
  120. 120. スクラムは組織マ 現実のスクラムネージメントがうまくいくための矯正ギ 権限なしブスとして機能する かも。 (本当はある) チームに対する スクラムマスタ(課長) 責任があることには 質問、促し、 変わりない 回答、提案 期待、モチベート 信頼に応える外部の雑音から守る スクラムチーム 権限あり (本当はない) プロパー 協力会社2010年6月22日火曜日
  121. 121. スクラムに 親和性のあるスキル • ファシリテーション • コーチング スクラム認定セミナーでも ファシリテーションについ て触れられている • グループコーチング • アサーション2010年6月22日火曜日
  122. 122. 「リーン開発の本質」 監訳者、平鍋氏の後書き多くの間違った標準化が、「人は本来怠け者でありしっかり働かせるために規則をつくらなければならない」とか「人は交換可能である」というメンタリティーから発している。2010年6月22日火曜日
  123. 123. 「リーン開発の本質」 監訳者、平鍋氏の後書き もし、組織の文化や方針の中心にこの ような考え方があると、 もしくは多くの管理者がこのように考 えている組織では、 リーン活動は決して成功しない。2010年6月22日火曜日
  124. 124. 「リーン開発の本質」 監訳者、平鍋氏の後書きそうではなく、「人の持つ工夫のモチベーションを活かす」こと、「一人ひとりの人を育てる」ことこそ、マネジメントの中心となるべきだ。「人」の要素はプロセスの中心である。2010年6月22日火曜日
  125. 125. なぜアジャイルか2010年6月22日火曜日
  126. 126. なぜアジャイル じゃないのか2010年6月22日火曜日
  127. 127. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年以上前の「ソフトウェア開発環境」(某IT企業) Copyright © 2010, Agile Process Association, All rights reserved. 852010年6月22日火曜日
  128. 128. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年以上前の「ソフトウェア開発環境」(某IT企業) 開発事務所 Copyright © 2010, Agile Process Association, All rights reserved. 852010年6月22日火曜日
  129. 129. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年以上前の「ソフトウェア開発環境」(某IT企業) 開発事務所 開発計算センタ Copyright © 2010, Agile Process Association, All rights reserved. 852010年6月22日火曜日
  130. 130. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年以上前の「ソフトウェア開発環境」(某IT企業) 開発事務所 開発計算センタ Copyright © 2010, Agile Process Association, All rights reserved. 852010年6月22日火曜日
  131. 131. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年以上前の「ソフトウェア開発環境」(某IT企業) 開発事務所 開発計算センタ パンチカード Copyright © 2010, Agile Process Association, All rights reserved. 852010年6月22日火曜日
  132. 132. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年以上前の「ソフトウェア開発環境」(某IT企業) 開発事務所 開発計算センタ パンチカード パンチカード Copyright © 2010, Agile Process Association, All rights reserved. 852010年6月22日火曜日
  133. 133. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年以上前の「ソフトウェア開発環境」(某IT企業) 開発事務所 おかしいなぁ 開発計算センタ パンチカード パンチカード Copyright © 2010, Agile Process Association, All rights reserved. 852010年6月22日火曜日
  134. 134. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年以上前の「ソフトウェア開発環境」(某IT企業) 開発事務所 わかった! 開発計算センタ パンチカード パンチカード Copyright © 2010, Agile Process Association, All rights reserved. 852010年6月22日火曜日
  135. 135. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年以上前の「ソフトウェア開発環境」(某IT企業) 開発事務所 わかった! デバッグ完了! 開発計算センタ パンチカード パンチカード Copyright © 2010, Agile Process Association, All rights reserved. 852010年6月22日火曜日
  136. 136. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年以上前の「ソフトウェア開発環境」(某IT企業) グーッ! 開発事務所 わかった! デバッグ完了! 開発計算センタ パンチカード パンチカード Copyright © 2010, Agile Process Association, All rights reserved. 852010年6月22日火曜日
  137. 137. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年以上前の「ソフトウェア開発環境」(某IT企業) グーッ! 開発事務所 わかった! デバッグ完了! 開発計算センタ パンチカード データ処理 パンチカード の主体 Copyright © 2010, Agile Process Association, All rights reserved. 852010年6月22日火曜日
  138. 138. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年以上前の「ソフトウェア開発環境」(某IT企業) グーッ! 開発事務所 わかった! デバッグ完了! 1日単位での作業周期 開発計算センタ パンチカード データ処理 パンチカード の主体 Copyright © 2010, Agile Process Association, All rights reserved. 852010年6月22日火曜日
  139. 139. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年以上前の「ソフトウェア開発環境」での1日(某IT企業) 始業時刻↓ ↓終業時刻 就業時間帯 Copyright © 2010, Agile Process Association, All rights reserved. 862010年6月22日火曜日
  140. 140. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年以上前の「ソフトウェア開発環境」での1日(某IT企業) 始業時刻↓ ↓終業時刻 就業時間帯 就業時間帯 Copyright © 2010, Agile Process Association, All rights reserved. 862010年6月22日火曜日
  141. 141. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年以上前の「ソフトウェア開発環境」での1日(某IT企業) 始業時刻↓ ↓終業時刻 就業時間帯 就業時間帯 開発作業 Copyright © 2010, Agile Process Association, All rights reserved. 862010年6月22日火曜日
  142. 142. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年以上前の「ソフトウェア開発環境」での1日(某IT企業) 始業時刻↓ ↓終業時刻 就業時間帯 就業時間帯 計算センタに依頼↓ ↓依頼結果の受取 開発作業 Copyright © 2010, Agile Process Association, All rights reserved. 862010年6月22日火曜日
  143. 143. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年以上前の「ソフトウェア開発環境」での1日(某IT企業) 始業時刻↓ ↓終業時刻 就業時間帯 就業時間帯 計算センタに依頼↓ ↓依頼結果の受取 開発作業 開発作業 Copyright © 2010, Agile Process Association, All rights reserved. 862010年6月22日火曜日
  144. 144. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年以上前の「ソフトウェア開発環境」での1日(某IT企業) 始業時刻↓ ↓終業時刻 就業時間帯 就業時間帯 計算センタに依頼↓ ↓依頼結果の受取 開発作業 待ち時間 開発作業 Copyright © 2010, Agile Process Association, All rights reserved. 862010年6月22日火曜日
  145. 145. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年以上前の「ソフトウェア開発環境」での1日(某IT企業) 始業時刻↓ ↓終業時刻 就業時間帯 就業時間帯 計算センタに依頼↓ ↓依頼結果の受取 開発作業 待ち時間 開発作業 デバッグ(コンパイルリスト上) コーディング(カードパンチ) 先輩に質問 後輩の指導 仕様書の修正 息抜き Copyright © 2010, Agile Process Association, All rights reserved. 862010年6月22日火曜日
  146. 146. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年以上前の「ソフトウェア開発環境」での1日(某IT企業) 始業時刻↓ ↓終業時刻 就業時間帯 就業時間帯 計算センタに依頼↓ ↓依頼結果の受取 開発作業 待ち時間 開発作業 デバッグ(コンパイルリスト上) コーディング(カードパンチ) 先輩に質問 ペアプロで、 後輩の指導 やられていること 仕様書の修正 が意外と多い 息抜き Copyright © 2010, Agile Process Association, All rights reserved. 862010年6月22日火曜日
  147. 147. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年以上前の「ソフトウェア開発環境」での1日(某IT企業) 始業時刻↓ ↓終業時刻 就業時間帯 就業時間帯 計算センタに依頼↓ ↓依頼結果の受取 開発作業 待ち時間 開発作業 デバッグ(コンパイルリスト上) 時間との戦い コーディング(カードパンチ) 先輩に質問 ペアプロで、 後輩の指導 やられていること 仕様書の修正 が意外と多い 息抜き Copyright © 2010, Agile Process Association, All rights reserved. 862010年6月22日火曜日
  148. 148. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 「ソフトウェア開発環境」の変遷(某IT企業) 開発リソースの 開発作業の 時 期 開発の進め方 価格 サイクル 非常に高価 1コンパイル 計算センタでの実行結果 30年以上前 待ちの間に、いろいろな (大型計算機使用) /1日 作業実施 同上 かなり高価 1コンパイル 30年前 (確認待ち時間は、「時 (ワークステーション使用) /1∼2時間 間単位」に短縮された) 安 価 1コンパイル 即座に実行結果を確認 現 在 (パソコン使用) /数分 可能になった Copyright © 2010, Agile Process Association, All rights reserved. 872010年6月22日火曜日
  149. 149. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 「ソフトウェア開発環境」の変遷(某IT企業) 1日にやり直せる回数 開発設備の価格 1970年 1980年 1990年 2000年 2010年 Copyright © 2010, Agile Process Association, All rights reserved. 882010年6月22日火曜日
  150. 150. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 「ソフトウェア開発環境」の変遷(某IT企業) 1日にやり直せる回数 開発設備の価格 結果の確認に  結果の確認に  1日必要  数分必要   (1回/日) (数100回/日) 1970年 1980年 1990年 2000年 2010年 Copyright © 2010, Agile Process Association, All rights reserved. 882010年6月22日火曜日
  151. 151. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年くらい前の「開発対象物件」(回顧) Copyright © 2010, Agile Process Association, All rights reserved. 892010年6月22日火曜日
  152. 152. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年くらい前の「開発対象物件」(回顧) 業務の電算化が盛んに行われていた(と思う) Copyright © 2010, Agile Process Association, All rights reserved. 892010年6月22日火曜日
  153. 153. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年くらい前の「開発対象物件」(回顧) 業務の電算化が盛んに行われていた(と思う) 【業務の電算化の進め方】 Copyright © 2010, Agile Process Association, All rights reserved. 892010年6月22日火曜日
  154. 154. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年くらい前の「開発対象物件」(回顧) 業務の電算化が盛んに行われていた(と思う) 【業務の電算化の進め方】 現状の業務手続の記載(明記) Copyright © 2010, Agile Process Association, All rights reserved. 892010年6月22日火曜日
  155. 155. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年くらい前の「開発対象物件」(回顧) 業務の電算化が盛んに行われていた(と思う) 【業務の電算化の進め方】 現状の業務手続の記載(明記) 記載(明記)された業務手続を実装 Copyright © 2010, Agile Process Association, All rights reserved. 892010年6月22日火曜日
  156. 156. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年くらい前の「開発対象物件」(回顧) 業務の電算化が盛んに行われていた(と思う) 【業務の電算化の進め方】 現状の業務手続の記載(明記) 記載(明記)された業務手続を実装 すべての業務手続を実装完了 Copyright © 2010, Agile Process Association, All rights reserved. 892010年6月22日火曜日
  157. 157. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年くらい前の「開発対象物件」(回顧) 業務の電算化が盛んに行われていた(と思う) 【業務の電算化の進め方】 現状の業務手続の記載(明記) 記載(明記)された業務手続を実装 すべての業務手続を実装完了 実装完了したソフトウェアのテスト Copyright © 2010, Agile Process Association, All rights reserved. 892010年6月22日火曜日
  158. 158. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年くらい前の「開発対象物件」(回顧) 業務の電算化が盛んに行われていた(と思う) 【業務の電算化の進め方】 現状の業務手続の記載(明記) 記載(明記)された業務手続を実装 すべての業務手続を実装完了 実装完了したソフトウェアのテスト テスト完了 Copyright © 2010, Agile Process Association, All rights reserved. 892010年6月22日火曜日
  159. 159. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年くらい前の「開発対象物件」(回顧) 業務の電算化が盛んに行われていた(と思う) 【業務の電算化の進め方】 現状の業務手続の記載(明記) 記載(明記)された業務手続を実装 すべての業務手続を実装完了 実装完了したソフトウェアのテスト テスト完了 ソフトウェアの納品 Copyright © 2010, Agile Process Association, All rights reserved. 892010年6月22日火曜日
  160. 160. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年くらい前の「開発対象物件」(回顧) 業務の電算化が盛んに行われていた(と思う) 【業務の電算化の進め方】 現状の業務手続の記載(明記) 開発途中での 仕様変更なし 記載(明記)された業務手続を実装 すべての業務手続を実装完了 実装完了したソフトウェアのテスト テスト完了 ソフトウェアの納品 Copyright © 2010, Agile Process Association, All rights reserved. 892010年6月22日火曜日
  161. 161. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年くらい前の「開発対象物件」(回顧) 業務の電算化が盛んに行われていた(と思う) 【業務の電算化の進め方】 現状の業務手続の記載(明記) 開発途中での 仕様変更なし 記載(明記)された業務手続を実装 開発可能 WF型で すべての業務手続を実装完了 実装完了したソフトウェアのテスト テスト完了 ソフトウェアの納品 Copyright © 2010, Agile Process Association, All rights reserved. 892010年6月22日火曜日
  162. 162. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年以上前の契約における手続きのながれ ユーザ ベンダ 契約前 Copyright © 2010, Agile Process Association, All rights reserved. 902010年6月22日火曜日
  163. 163. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年以上前の契約における手続きのながれ ユーザ ベンダ 業務の電算化をし たいんだけど 契約前 Copyright © 2010, Agile Process Association, All rights reserved. 902010年6月22日火曜日
  164. 164. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年以上前の契約における手続きのながれ ユーザ ベンダ 業務の電算化をし 電算化できるのは たいんだけど ○○○業務ですね 契約前 Copyright © 2010, Agile Process Association, All rights reserved. 902010年6月22日火曜日
  165. 165. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年以上前の契約における手続きのながれ ユーザ ベンダ 業務の電算化をし 電算化できるのは たいんだけど ○○○業務ですね 契約前 どのくらいで電算化 できるのかなぁ Copyright © 2010, Agile Process Association, All rights reserved. 902010年6月22日火曜日
  166. 166. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年以上前の契約における手続きのながれ ユーザ ベンダ 業務の電算化をし 電算化できるのは たいんだけど ○○○業務ですね 契約前 どのくらいで電算化 ○○○円で できるのかなぁ できますよ Copyright © 2010, Agile Process Association, All rights reserved. 902010年6月22日火曜日
  167. 167. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年以上前の契約における手続きのながれ ユーザ ベンダ 業務の電算化をし 電算化できるのは たいんだけど ○○○業務ですね 契約前 どのくらいで電算化 ○○○円で できるのかなぁ できますよ 契約締 結 合意 合意 Copyright © 2010, Agile Process Association, All rights reserved. 902010年6月22日火曜日
  168. 168. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年以上前の契約における手続きのながれ ユーザ ベンダ 業務の電算化をし 電算化できるのは たいんだけど ○○○業務ですね 契約前 どのくらいで電算化 ○○○円で できるのかなぁ できますよ 契約締 結 合意 合意 契約締結後 システム設計書、 ソフトウェアなど Copyright © 2010, Agile Process Association, All rights reserved. 902010年6月22日火曜日
  169. 169. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年以上前の契約における手続きのながれ ユーザ ベンダ 業務の電算化をし 電算化できるのは たいんだけど ○○○業務ですね 契約前 どのくらいで電算化 ○○○円で できるのかなぁ できますよ 契約締 結 合意 合意 契約締結後 システム設計書、 承認(検収) ソフトウェアなど Copyright © 2010, Agile Process Association, All rights reserved. 902010年6月22日火曜日
  170. 170. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年以上前の契約における手続きのながれ ユーザ ベンダ (逆戻りの必要なし) 業務の電算化をし 電算化できるのは 時間の流れ たいんだけど ○○○業務ですね 契約前 どのくらいで電算化 ○○○円で できるのかなぁ できますよ 契約締 結 合意 合意 契約締結後 システム設計書、 承認(検収) ソフトウェアなど Copyright © 2010, Agile Process Association, All rights reserved. 902010年6月22日火曜日
  171. 171. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 30年以上前の契約における手続きのながれ ユーザ ベンダ 業務の電算化をし 電算化できるのは たいんだけど ○○○業務ですね 契約前 どのくらいで電算化 ○○○円で できるのかなぁ できますよ 要求仕様、要求開発 などの概念が、 契約締 結 合意 合意 存在しない取引 契約締結後 システム設計書、 承認(検収) ソフトウェアなど Copyright © 2010, Agile Process Association, All rights reserved. 902010年6月22日火曜日
  172. 172. 「アジャイルプロセスで開発しやすい契約書」 アジャイルプロセス協議会、契約と見積WG より 3.ソフトウェア開発環境の変化 「ソフトウェア開発環境」と「契約」での変遷の比較 開発環境の変化 時 期 開発リソースの 開発作業の 契約での変化 価格 サイクル 非常に高価 1コンパイル 30年以上前 (大型計算機使用) /1日 かなり高価 1コンパイル 30年前 請負契約書ベース (ワークステーション使用) /1∼2時間 安 価 1コンパイル 現 在 (パソコン使用) /数秒 Copyright © 2010, Agile Process Association, All rights reserved. 912010年6月22日火曜日
  173. 173. 産業の歴史 • 産業革命 1760-1830 • 豊田織機製作所 1867 • トヨタ自動車 1937 • 第2位時世界大戦 1939-1945 • 商用汎用機 1950 • トヨタ生産方式-カイゼン 19502010年6月22日火曜日
  174. 174. ソフトウエアの歴史 • 商用汎用機 1950  • ソフトウエア工学 1968 • ウォーターフォール 1970 • Machintosh 1984 • Windows95 19952010年6月22日火曜日
  175. 175. アジャイルの歴史 • トヨタ生産方式ーカイゼン 1950 • 建築のデザインパターン 197* • Machintosh 1984 • 野中,竹内論文(The new new development game) 1986 • スクラム 1993 • 組織・プロセスパターン Jams coplien1994 • Windows95 1995 • GoF デザインパターン 1995 • XP Kent Beck 1999 • アジャイルアライアンス 20012010年6月22日火曜日
  176. 176. 開発 と 製造 開発 製造 レシピを作る 料理を作る 実践利用に 要求に 適しているか? 合っているか? バリエーションOK バリエーションNG 反復は価値を生む 反復はムダを生む 「リーンソフトウェア開発」メタボリックス 山田正樹 より引用 http://www.metabolics.co.jp/SoftwareProcess/SRC040903/LSD02.pdf2010年6月22日火曜日
  177. 177. 歴史整理 現在(2010) 産業(1760) 産業革命(1837) ・1950 ・1960 ・1970 ・1980 ・1990 ・2000 デザインパターン アレグザンダー(1970代) 日本の製造業の台頭 カイゼン、JIT トヨタ(1950) PC-10 Canon(1982) City ホンダ(1981) ワイガヤ ホンダ(1946) 野中、竹中論文(1986) 「開発」としての SCRUM (1995) ソフトウェア 第2次 世界大 デザインパターンGof (1995) 戦 組織パターン coplien(1994) (1939- 1945) Plop (1993) XP (1999) リーンソフトウェア開発 商用汎用機 UNIVAC(1950) リーン MIT(1980代) Poppendieck(2003) オブジェクト指向(1972) Agile Aglience (2001) ソフトウェア産業 Java 1.0 (1995) ソフトウェア工学(1968) ビジネス変化のスピード拡大 ウォーターフォール(W.W.ロイス1970) 新規技術の増大 工場ラインの製造としてのソフトウェア 複雑化 コンパイル時間目安 数週∼数日に1回 1日に数回 1日に数百∼数千回 eiichi hayashi (cc)2010年6月22日火曜日
  178. 178. なぜアジャイルか2010年6月22日火曜日
  179. 179. 2010年6月22日火曜日
  180. 180. 2010年6月22日火曜日
  181. 181. Agileの価値観 私たちは, プロセスとツールよりも     ……… 個人と対話に 包括的なドキュメントよりも    ……… 動くソフトウェアに 契約交渉よりも     ……… 顧客との協調に 計画に沿うことよりも    ……… 変化に対応することに 価値をおく. アジャイル宣言(http://agilemanifesto.org/iso/ja/) 原則(http://agilemanifesto.org/iso/ja/principle.html)2010年6月22日火曜日
  182. 182. 第2部 朝会ワーク2010年6月22日火曜日
  183. 183. クリエイティブな仕事したい人?2010年6月22日火曜日
  184. 184. 朝会 (デイリースクラム)‫‏‬2010年6月22日火曜日
  185. 185. 朝会 (デイリースクラム)‫‏‬ 毎日の15分だけの状況報告ミーティング • 毎回同じ場所、同じ時間 • 3つの質問  ‒ 昨日はなにをしたか  ‒ 今日は何をするか  ‒ そのタスクの障害になることはなにか2010年6月22日火曜日
  186. 186. 朝会 (デイリースクラム)‫‏‬ 目的 1. チーム全体が,必要な情報を短い時間で共有すること。 2. 昨日やったことを振り返り,今日やることを各自が   認識しコミットすること。 3. 朝,気持ちよく仕事のスタートを切ること。2010年6月22日火曜日
  187. 187. 朝会 (デイリースクラム)‫‏‬ グランドルール  他人を非難しない  悪いニュースは良いニュース  部外者に発言権はない(鶏と豚)  その場で解決しない   (その場で解決したほうがいいか判断すること)2010年6月22日火曜日
  188. 188. 朝会 (デイリースクラム)‫‏‬2010年6月22日火曜日
  189. 189. 朝会 (デイリースクラム)‫‏‬ 朝会のポイント  司会者に報告するのではなく、全員に報告する。    司会者は微妙にアイコンタクトをはずす。  硬さとやわらかさのバランス。    適度なアイスブレークを。  ルール違反はその場で軽く指摘。  正直に話せる雰囲気  自己組織的   2010年6月22日火曜日
  190. 190. クリエイティブな仕事したい人?2010年6月22日火曜日
  191. 191. クリエイティビティースコア • 幼稚園児 • 小学生 • 中・高校生 • 大学生 • 大人 トニーブザン 講演より2010年6月22日火曜日
  192. 192. クリエイティビティースコア • 幼稚園児 95% • 小学生 75% • 中・高校生 50% • 大学生 25% • 大人 10%以下 トニーブザン 講演より2010年6月22日火曜日
  193. 193. クリエイティビティースコア • 幼稚園児 95% • 小学生 75% • 中・高校生 50% • 大学生 25% • 大人 10%以下 これは「普通」のことだけど、 「自然」なことではない トニーブザン 講演より2010年6月22日火曜日
  194. 194. グループワーク 朝会をやってみよう2010年6月22日火曜日
  195. 195. 普通の朝会 • 3つの質問を順番に • 前回からやったことは? • 今日やることはなんですか? • 問題になっていることはありますか?2010年6月22日火曜日
  196. 196. だめだめな朝会 • みなさんの課題や問題になっていることを 朝会でやってみよう •例 • やる気が無い人 • 報告がながい • 険悪モード(仲悪い人がいる)2010年6月22日火曜日
  197. 197. すごい朝会 理想の朝会をやってみよう2010年6月22日火曜日
  198. 198. グループワーク 気付いたこと2010年6月22日火曜日
  199. 199. グループワーク 模造紙 課題 ココ に書く 他のメンバーの人は、共感 できることがあったらその横に★印を書 気付き いてください2010年6月22日火曜日
  200. 200. ご参考。 グループコーチング 「グループ・コーチング入門 」本間 正人 (著) より一部引用2010年6月22日火曜日
  201. 201. グループコーチング • 他の部下に同時に意識を向ける • メンバーに目配りする • うなづく • 一人だけではなく周辺の人の動きを目の端で同 時に感じる • 場の空気をよむ • 自分への報告ではなく、全体への報告になるよ うに促す2010年6月22日火曜日
  202. 202. グループコーチング • 承認メッセージ重要 • 相手の可能性を引き出すことができる • 相手の名前をちゃんと呼ぶ • 「∼さん、どうですか。」 • 意見が尊重されている体験が重要2010年6月22日火曜日
  203. 203. グループコーチング • コーチングのGROWモデル • GOALS 目標の明確化 • REALITY 現状の把握 • RESOURCE 資源の発見 • OPTIONS 選択枝の創造 • WILL 意志の確認、計画の策定2010年6月22日火曜日
  204. 204. グループコーチング • コーチングのGROWモデル 朝会 ではココまで • GOALS 目標の明確化 • REALITY 現状の把握 • RESOURCE 資源の発見 • OPTIONS 選択枝の創造 • WILL 意志の確認、計画の策定2010年6月22日火曜日
  205. 205. グループコーチング 質問のテクニック • 課題に関する思いや観点を持っていそうな人から聞く • 状況により指名型と公募型を使いわける 「∼さんどう?」と「意見ある人いる?」 • 問いかけ方で行動の変化を促す 楽しかった? → どこが面白かった? 寂しいですか → どんな楽しいことがありました? • なぜの扱いに注意!  対象を物にする「何がそうさせるのですか?」2010年6月22日火曜日
  206. 206. グループコーチング 質問のテクニック これらを状況によってくみあわせる • 自由回答で意見をもとめる質問 • 自由回答で事実をもとめる質問 • YES,NOで答えられる質問 • 選択枝を選ばせる質問2010年6月22日火曜日

×