Download as PDF, PPTX
![[ITビジネスセミナー] 現役プロダクトマネージャーが語る、日本企業におけるプロダクトマネージャーの課題と今後の展望 #postudy](https://cdn.slidesharecdn.com/ss_thumbnails/20150906postudyit-150908095915-lva1-app6891-thumbnail.jpg?width=640&height=640&fit=bounds)
![個人と組織からもう一度考えるプロダクトマネジャー - [ITビジネスセミナー] 現役プロダクトマネージャーが語る、日本企業におけるプロダクトマネージャーの...](https://cdn.slidesharecdn.com/ss_thumbnails/150906postudy-150908091355-lva1-app6891-thumbnail.jpg?width=640&height=640&fit=bounds)
認定スクラムマスター研修に行ってきました
- 1. 認定スクラムマスター研修 京都 に行ってきました 1 / 99
- 2. 認定スクラムマスター研修 (CSM研修) に参加してきました。 2 / 99
- 3. 個人的に、印象深かった トピックをお話します。 3 / 99
- 4. 本日の、私の目標 スクラムに 興味を持ってもらえること です 細かい説明はしませんので、 Scrum自体の概要 をしっかり知りたいという方は、あとで資料をご紹介します。 4 / 99
- 5.
- 6.
- 7. 日時 : 2014年8月 7日 (木) - 8月 8日 (金) 場所 : 京都烏丸コンベンションホール 京都烏丸コンベンションホール Webページ 名前からの先入観で、すごく大きいところを想像していたのですが、 以外にコンパクトでした。 （駅員さんに訊いても知りませんでした） 先入観で決めつけるのはいけないという教訓になりました。 参加者 半分が関東の方、半分が関西の方 7 / 99
- 8. トレーナー : 江端一将 さん 日本人で唯一のアジャイルトレーナー かつて大規模プロジェクトのプロダクトオーナーを 経験された プロダクトオーナー ・・・ Scrumの役割の一つ ROI最大化するために、プロダクト方向性を決める人 チーム ・・・ Scrumの役割の一つ 開発を進める主体である、人々。 コストを安価に開発する責任が課せられてい る スクラムマスター ・・・ Scrumの役割の一つ 開発が Scrum と呼べる状態にする人。 8 / 99
- 9. 「体験する」「考える」ことを重視してい る内容でした 内容の例 本日の参加者で Scrum をどのぐらい知っているかについて、順番を付けてください 研修中のルールを皆さんで決めてください ゲームやロールプレイ 現場で起こそうな雰囲気 色々『気づき』があり、刺激的でした (私個人の感想です) 9 / 99
- 10. Scrum をやる機会がなかったとしても 新鮮な考え方が 得られて有意義な研修だったと感じました。 10 / 99
- 11.
- 12. おわり 12 /99
- 13.
- 14.
- 15. Scrum は何を解決するためのフレ ームワークか？ 15 / 99
- 16. Scrum は何を解決するためのフレ ームワークか？ 失敗を減らしたり、 開発の効率を上げたり、 素早く開発できたり、 簡単に開発できたり、 品質を向上が期待できたり、 16 / 99
- 17. そういうことを 解決する フレームワークでは ありません 誤解していました。。。 17 / 99
- 18. Scrum の重要なキー (Keys) Scrumを理解する上での重要なキーワード。 19個(2014年8月現在)。 全部遵守する必要あり。 18 / 99
- 19. Scrum の重要なキー (Keys) Scrumを理解する上での重要なキーワード。 19個(2014年8月現在)。 全部遵守する必要あり。 * Three Keys (Scrum のキーポイント。三本柱) 19 / 99
- 20. Scrum の重要なキー (Keys) Scrumを理解する上での重要なキーワード。 19個(2014年8月現在)。 全部遵守する必要あり。 * Three Keys (Scrum のキーポイント。三本柱) * 透明性 -- Transparency * 検証 -- Inspect * 適合 (検証に基づいた適合) -- Adapt 20 / 99
- 21. Scrum の重要なキー (Keys) Scrumを理解する上での重要なキーワード。 19個(2014年8月現在)。 全部遵守する必要あり。 * Three Keys (Scrum のキーポイント。三本柱) * 透明性 -- Transparency * 検証 -- Inspect * 適合 (検証に基づいた適合) -- Adapt * Scrum Roles -- 役割 * Product Owner -- プロダクトオーナー * ScrumMaster -- スクラムマスター * The Team -- チーム * Artifact アーチファクト (参考:日本語訳)人工物、工芸品＾、芸術品 * Product Backlog -- プロダクトバックログ * Sprint Backlog -- スプリントバックログ * Impediment List -- インピディメントリスト * Ceremonies -- セレモニー * Sprint Planning -- スプリントプランニング * Daily Scrum -- デイリースクラム * Product Backlog Refinement -- プロダクトバックログリファインメント * Sprint Review -- スプリントレビュー * Sprint retrospective -- スプリントレトロスペクション * Sprint -- スプリント * Stop -- 製品開発と途中でやめる * Acceptance Criteria -- 受け入れ基準 * Done -- 製品が完了する * Potentially shippable product increment -- 出荷可能な製品をリリースする 21 / 99
- 22. 「透明性 -- Transparency」 22 / 99
- 23. 三本柱の中の「透明性 -- Transparency」を 最も重要視しています 「say "It's done."」 を撲滅する 「もう、ほとんどできてます。」 「90%できた (?) 」 っていうのはなくす ガントチャートに、こういう状況、よく出てきませんか？ 23 / 99
- 24. Ken Schwaber氏が Scrumについて象徴的な説明をして いる動画を見せてもらいました。 24 / 99
- 25. Ken Schwaber氏の談話の動画 スクラムは誰でも始められる・・・ 1回目のスプリント結果が、チームの実力を教えて くれる 25 / 99
- 26. Ken Schwaber氏の談話の動画 スクラムは誰でも始められる・・・ 1回目のスプリント結果が、チームの実力を教えて くれる チームが、「優秀」か、「靴紐が結べないほどの間 抜け」か 26 / 99
- 27. Ken Schwaber氏の談話の動画 スクラムは誰でも始められる・・・ 1回目のスプリント結果が、チームの実力を教えて くれる チームが、「優秀」か、「靴紐が結べないほどの間 抜け」か Scrum の特徴は 「軽量」、 「理解が容易」、、、 27 / 99
- 28. Ken Schwaber氏の談話の動画 スクラムは誰でも始められる・・・ 1回目のスプリント結果が、チームの実力を教えて くれる チームが、「優秀」か、「靴紐が結べないほどの間 抜け」か Scrum の特徴は 「軽量」、 「理解が容易」、、、 「 習得は非常に困難」 28 / 99
- 29. Scrum は何を解決するためのフレ ームワークか？ 29 / 99
- 30. Scrum は何を解決するためのフレ ームワークか？ 現状をあぶりだすフレームワーク 問題をあぶりだすフレームワーク 30 / 99
- 31. Scrum は何を解決するためのフレ ームワークか？ 素晴らしいチームはより素晴らしく、 そうでないチームはそれなりに、 (Fフイルム風。 知っている人は、かなりご年配。 文責：柳川。) 31 / 99
- 32. Scrum は何を解決するためのフレ ームワークか？ 良いところも、悪いところも、明らかにし て 状況に適応していくことで チームの力を、発揮させようとします 32 / 99
- 33. ＞＞ 33 /99
- 34.
- 35. 自律的なチーム チームがチームを管理する スクラムマスターは管理者ではない チーム ・・・ Scrumの役割の一つ 開発を進める主体である、人々。 コストを安価に開発する責任が課せられてい る スクラムマスター ・・・ Scrumの役割の一つ 開発が Scrum と呼べる状態にする人。 プロダクトオーナー ・・・ Scrumの役割の一つ ROI最大化するために、プロダクト方向性を決める人 35 / 99
- 36. 自律的なチーム チームで方針を相談する チームの進捗は、チームが管理する チームの方針に沿い、 個人が判断して作業する。 (0.1秒以内で判断して) 個人は、チームに結果をフィードバックする 36 / 99
- 37. 自律的なチーム スクラムマスターは 管理したり、直接手伝ったりしてはいけない チームが困っているときに助言する チームの邪魔をしそうな「人」「もの」「イベント」「人と人とのトラブル」などの あらゆる障害を取り除く 37 / 99
- 38. 自律的なチーム チームがチームを管理することにより チームは成長していきます。 チームのメンバーも成長していきます。 38 / 99
- 39. 自律的なチーム チームがチームを管理することにより チームは成長していきます。 チームのメンバーも成長していきます。 なんか、いいと思いませんか？ 39 / 99
- 40. ＞＞ 40 /99
- 41.
- 42. ソフトウエア開発に抽象的な解 決方法はない 実際の経験と 既知に基づく判断によって知識が 獲得できる 経験的プロセス制御の理論（経験主義） (注: 哲学、心理学の文脈ででてくる「経験主義」とは異なる模様) 42 / 99
- 43. 具体的な例 (既知に基づく判断) 人間は将来を予測するのが下手 人間は絶対値の見積もりが下手 . では、上から順に。。。 43 / 99
- 44.
- 45. 人間は将来を予測するのが下手 こんな感じです。たぶん。。 ↑予測はずれ率 │ | │ / │ | │ / │ / │ _/ │ __/ │ ___/ │ _____/ │ ______/ │ _______/ │ ________/ │ _________/ │ __________/ │/ 未来 ＋----------------------------------------------------------> 45 / 99
- 46. 人間は将来を予測するのが下手 このため、 ＝＝＞次のスプリントしか詳細に見積もりしない 反復的で漸進的な手法を用いて、予測可能性の最適化とリスクの管理を行う スプリント Scrumでは、1週間、や、2週間、など、期間を区切って開発する。 スプリントはその、１つの期間のこと。 46 / 99
- 47.
- 48. 人間は絶対値の見積もりが下手 どちらが当てやすいか？ (誤差が小さいか?) このペットボトルの 黒い部分は何セン チですか このペットボトルの黒い 部分は白い部分の何 倍ですか この紙は、何平方 センチですか この紙は、あの紙の何 倍(何分の何)ですか 48 / 99
- 49. 人間は絶対値の見積もりが下手 このため、 ＝＝＞ 相対的に見積る 相対的に見積もったほうが、誤差が小さい 見積もりの基準になる、項目を決めて、 「何倍か？」という風に見積もる。 「プランニングポーカー」という手法が研修で紹介されました (研修でカードももらいました。) 紹介しているサイトの一例(検索するといっぱい引っかかります) プランニングポーカー簡単ガイド作りました -- http://d.hatena.ne.jp/wayaguchi/20120218/1329524230 49 / 99
- 50. ＞＞ 50 /99
- 51.
- 52. Scrumに適するプロジェクトは 要件が不明確 ↑└+ │ ｜ カオス │ └+ │ ｜ │ └---+ │--┐ ｜ │ +---┐ └+----------------+ │ │ ｜ │ 複雑 +┐ └--------- │ +┐ │ │ 複合的に複雑 │ ┐ │ │ │ │ │--┐ │ │ +---┐ │ │ +--┐----------------┐ │ +-┐ ┐ │ 単純 │ 複雑 │ │ +┐ +┐ │ │ │ ＋----------------------------------------------------------> 技術が難しい・新しい52 / 99
- 53. Scrumに適するプロジェクトは 適するのは、単純なプロジェクト以外 単純なプロジェクトは不得意 実現する内容が単純明快 やりたいこと(要件)が明らか やりたいこと(要件)が変更されない 実現方法が分かっている。もしくは、決まっていて、失敗する可能性が小さい。 単純なプロジェクトであればあるほとは、「ウォータフォール」&「一括契約」 がおすすめです。（なぜなら、変更されないことが「ウォータフォールの前提」だから） 53 / 99
- 54. Scrumに適するプロジェクトは 採用例 ユーザー企業の内製プロジェクトに、採用例が多 い模様。 内製プロダクトの場合、公表するメリットがなく公表されないことが多いとのこと。 メディアには露出しにくい模様。 54 / 99
- 55.
- 56. 感想 56 /99
- 57.
- 58. ルールに厳格だけど、自由にル ールを決められる Scrum自体のルールは、全部守る必要あり Scrum のキーワード 19個 ... (2014年8月現在) 一部だけ適用することは可能だが、それは、Scrum ではない別の何か Scrumの要素を一部だけ適用して「Scrumうまくいかない」というのは的外れ 一方、チームが独自で決めるルールは。。。 制約少ない。柔軟 開発コストを下げるためなら、あらゆる発送を駆使して、何を試みてもよい 「チームが決めた」ことは守らないといけない 58 / 99
- 59.
- 60.
- 61. 役割ごとの責任に厳しい 責任を果たしていない場合は追及する 責任を奪ってはならない では、順に。。。 61 / 99
- 62. 役割ごとの責任に厳しい プロダクトオーナーも、スクラムマスターも、管理者では ない。 チームとは 対等。 責任範囲を越境してはいけない チームは「コストを最小にする」代案 があれば、プロ ダクトマスターが選択できるようにしなくてはならない。 プロダクトオーナーはビジョンを示さなければいけない。 スクラムマスターは、チームが開発に専念できるようにし なければいけない。 プロダクトオーナーは 優先順位 を決定しなければいけ ない。(優先度ではない) 「チーム」に指示したり、命令したり、 高圧的に選択を強 いたりして、委縮させるのはもっともダメ など。。。 62 / 99
- 63. 役割ごとの責任に厳しい ゴチャゴチャし過ぎました。 すいません 63 / 99
- 64. ＞＞ 64 /99
- 65. 最後に 65 /99
- 66. 私が考える SIer の Agile や Scrumに対するお奨め戦 略は 66 / 99
- 67. 私が考える SIer の Agile や Scrumに対するお奨め戦 略は 『Scrum なんて知らない』ふりをする 67 / 99
- 68. 私が考える SIer の Agile や Scrumに対するお奨め戦 略は 『Scrum なんて知らない』ふりをする 『Scrum が優秀』と思った顧客は内製開発してしまう 一括契約で Scrum を採用すのはイバラの道 68 / 99
- 69. でも、 Agile とかScrum とか言うキーワードで仕事の お話がある場合は 69 / 99
- 70. でも、 Agile とかScrum とか言うキーワードで仕事の お話がある場合は せっかくですから 開発しましょう (あるいは、する方向で前向きに) 70 / 99
- 71. 注意点 契約形態は、工数型で お客様いうAgile と Scrum の意味を確認しておく 本来の意味かもしれないし ユニークな発想によるものかもしれません。 どんな意図であったとしても、少なくとも、心構えができます。 71 / 99
- 72. 社内開発に ぜひ一度、 72/ 99
- 73. 社内開発に ぜひ一度、 採用おねがいします 73 / 99
- 74. 社内開発に 自律的なチーム 『人、と、組織、を成長させる』 魅力的じゃないですか？ 74 / 99
- 75. 社内開発に Scrum を使いこなすのは、容易ではないかもしれませんが、 有効なフレームワークだと思います。 75 / 99
- 76. 社内開発に Scrum を使いこなすのは、容易ではないかもしれませんが、 有効なフレームワークだと思います。 76 / 99
- 77. おわり 77 /99
- 78. もっとスクラムについて知りたい かたは スクラムガイド http://www.scrumguides.org/download.html Scrum Primer(日本語版) http://assets.scrumfoundation.com/downloads/5/THESCRUMPRIMER_ja.pdf 78 / 99
- 79. おまけ 79 /99
- 80.
- 81. その１ 81 /99
- 82. Scrum のほうが Agileより歴史が古 い Scrumは、 1993年 アジャイルソフトウェア開発宣言 (Manifesto for Agile Software Development) 2001年 17名の共通認識を宣言として発表。 82 / 99
- 83. その２ 83 /99
- 84.
- 85. Agile アジャイルは状態 アジャイルは状態を表す言葉 Be Agile. Not Do Agile. 85 / 99
- 86. Agile という単語を、間違って使っ た会話の例 開発 Aさん このプロジェクトは 「アジャイルプロジェクトマネジメン ト」します。 顧客担当 Bさん そうですね。 「アジャイル開発」のほうがリスクが低そうですしね。 顧客課長 Cさん A さん、しっかり チームを管理お願いしますね 86 / 99
- 87. Agile アジャイルは状態 アジャイルプロジェクトマネジメント 87 / 99
- 88. Agile アジャイルは状態 アジャイルプロジェクトマネジメント というものはありません。 『出版時に、キャッチコピーとして、使っちゃったんですが、。。。 失敗でした 』 ほんとは、「 Bussiness Fucilitation 」って呼ぼうと思ったんですが Agile のほうが、「キ ャッチ―でしょう。」って出版社がいうので。。。 とのこと 88 / 99
- 89. なので 89 /99
- 90. Agile アジャイルは状態 アジャイル開発する 90 / 99
- 91. Agile アジャイルは状態 アジャイル開発する できません。 Be Agile. Not Do Agile. Agile は状態なので「する」ことはできません 「Scrumで開発したら、アジャイルな状態になれた。」 という感じが、意図する意味合い 91 / 99
- 92. Agile アジャイルは状態 『Agileという単語は、「青春」という単語 と同じような使い方をするとイメージす るとよい』 (トレーナーの江端さん 談) 92 / 99
- 93. 「Agile」 と 「青春」の用例 あの時は、 Agile だったなー あの時は、青春だったなー こんな風に、Agile という単語は 青春 という単語使い方が似ています。 93 / 99
- 94. 「Agile」 と 「青春」の用例 Agile する 青春する するものじゃないので、両方変な感じになります。。。 「青春する」はコントのセリフならギリギリセーフです。。。 94 / 99
- 95. おまけ (その3) 95/ 99
- 96. アジャイルソフトウェア開発宣言 で一番大事なこと 参考：アジャイルソフトウェア開発宣言の序文 「4つの価値」 プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 96 / 99
- 97. アジャイルソフトウェア開発宣言 で一番大事なこと 参考：アジャイルソフトウェア開発宣言の序文 一番、重要なのは「4つの価値」だと思 ってましたが、 もっと大事なものがありました。 97 / 99
- 98. アジャイルソフトウェア開発宣言 で一番大事なこと 最初に書かれている序文が重要 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて。。。 最も重要なこと 始めること 助けること 98 / 99
- 99. おまけ おわり 99/ 99