Developers summit 2015 kansaiにてスクラム道関西の講演スライドです http://event.shoeisha.jp/devsumi/20150904/session/887/

1. 開発現場を
盛り上げる技術と
チームを支え続ける
原動力
スクラム道関西
https://www.facebook.com/ScrumDoKansai

2. 注意事項
このセッションでの
発言は個人の見解で
あり、所属する組織
の公式見解ではあり
ません

3. Ｗｅ are
スクラム道関西
https://www.facebook.com/ScrumDoKansai

4. 本セッションでは
開発現場をもっと良くして
いくための技術を中心に、
どのような想いを持って
チームを支え続けてきたの
かをお話します

5. 自己紹介
• 宇野 泰三
• SIerに所属
業務改善／改革
IT戦略立案
業務系システム導入
など、ご支援しています
• 受託開発のコンテキストで
しゃべります
taizo.uno.7
モリモリ

6. 盛り上がるとは？
モリモリ

7. モリモリ

8. 現場が「盛り上がる」とは？
楽しい
集中している
成長が体感できる
誰かの役に立っている
成果が見える
一体感がある
・・・
モリモリ

9. 10秒間、黙祷
盛り上がらない
プロジェクト大杉

10. 盛り上がりに欠かせないこと
①目的が共有できている
②（制約の中において）自由がある
③活動に価値を見いだせている
モリモリ

11. 盛り上がりに欠かせないこと
①目的が共有できている
②（制約の中において）自由がある
③活動に価値を見いだせている
モリモリ

12. モリモリ
みんな大好き、
ガントチャート

13. 目的を達成するための、
ストーリーは共有できているか？
モリモリ

14. ゴール
スタート
成果
時間軸
いつまでに、何を、どんなストーリー（戦略）で
実現しようとしているのか、語られているか？
モリモリ

15. ストーリー（戦略）を語ろう！
モリモリ

16. 盛り上がりに欠かせないこと
①目的が共有できている
②（制約の中において）自由がある
③活動に価値を見いだせている
モリモリ

17. モリモリ
みんな大好き、
ガントチャート

18. モリモリ
成
果
期日

19. 類似案件から過去の見積を参照できる
１ 2 3 4 5 6 7 8 9 10 11 12
見積の実績を登録できる
分析
UI実装
サーバーサイド実装
試験
分析
UI実装
サーバーサイド実装
試験
モリモリ

20. 類似案件から過去の見積を参照できる
１ 2 3 4 5 6 7 8 9 10 11 12
見積の実績を登録できる
分析
UI実装
サーバーサイド実装
試験
分析
UI実装
サーバーサイド実装
試験
モリモリ
成果
作業
期日
作業（成果に至る手段）に
関与しすぎ。。

21. モリモリ
成
果
期日
もっと裁量の余地を！

22. 盛り上がりに欠かせないこと
①目的が共有できている
②（制約の中において）自由がある
③活動に価値を見いだせている
モリモリ

23. ①，②が出来ていれば
大丈夫（なはず）
モリモリ

24. 与えられるものではなく、
自分達で見つけるもの
なんじゃね？
モリモリ

25.  1995年にゲームプログラマとして就職
 2002年ぐらいからアジャイル開発に興味を持ち始める
 2004年に実際にアジャイル開発をやってみる
 2010年に認定スクラムマスター所得
 得意分野
アジャイル開発：『スクラム』『XP』『Kanban』
 『開発者に笑顔を！』をモットーに
アジャイルやゲーム界隈で講演活動
田口 昌宏
 株式会社スクウェア・エニックス
 CEDEC 2013～2015 運営委員
 メタスラとかスト４とか作ってた
 スクラム道 スクラム道関西 スタッフ
 認定スクラムマスター

26. 面白いゲームを
お客様に届ける

27. ゲーム業界の
特徴

28. 西村直人氏
『ゲーム業界ほど
自分たちのプロダ
クトを愛している
業界は無い』

29. ゲーム開発

30. ＝

32. 愛の表現方法
残業 徹夜
休日出勤

33. 愛がゆえに
廊下で殴り合い

34. こっちの方が
面白いんじゃ！

35. 今日のタイトル
開発現場を盛り上げ
る技術とチームを支
え続ける原動力

36. 現場は勝手
に盛り上が
ってますｗ

37. でももう少
し上手に作
りたいです

38. 愛たっぷりの
開発チームに
必要なもの

39. （殴り合わずに）
価値を
話し合える場

40. レビュー

41. もっとうまく作れ
ることで、もっと
うまく価値を届け
ることができる

42. つくる練習

43. プランニングポーカー
 開発チームで協調して見積もるためのツール

44. 楽しく作る
楽しいプロダクト

46. タ
ス
ク
が
活
き
活
き
と

47. 私のチームを支え
続ける原動力

48. チームみんなの
愛の力を価値に
換えてお客様に
届けたい

49. 自己紹介
• 開原隆弘(40)
• とある企業のIT子会社
のサラリーマン
• Web業務系アプリ開発
チームのマネージャー
• 主にとある企業グループ
向けの仕事
• そんなコンテキストで
話します

50. 盛り上がるってなーに？
たんに盛り上がっても、
意味ないんじゃね？

51. 盛り下げる方法だったら、
いくらでも知ってるわ！

52. チーム殺し７つの秘訣
• 自己防衛的な管理
• 官僚主義
• 作業場所の分散
• 時間の分断
• 品質低減製品
• さばを読んだ納期
• チーム解体の方針

53. マネージャーはなにができるのか？
• 環境づくり
• 突き抜ける
• あとは待つだけ！

54. 環境づくり
• チームが主役！バックアップ！
– 出しゃばらない！
– サーバントリーダーシップ
• HRT(謙虚・尊敬・信頼)
– 人とどう付き合うか
– by 『Team Geek』

55. そして…

56. 金が全てじゃねぇが、
全てに金が必要だ

58. 金金金
お金があればチートができるヨ！
• 性能の良いマシンを買ってあげよう
• 研修とか勉強会にいかせてあげよう
• 本なんて、たくさん買っちゃえ
• 開発コーチにしごいてもらえ！
• スーパープログラマーよんで、
マサカリ投げてもらっちゃお☆

59. 突き抜ける
あたりまえなこと、習慣をやめる、みんなが
言わなかったこと、言いにくいことを言う、
リスクをとる
そのためには、チームメンバーの常識を少し
だけ修正してあげると良いかもしれない
率先してお手本を見せよう！

60. あとは待つだけ！
•学習、成長には時間がかかる
•失敗を許容する
- わざと失敗する人なんていない
- 失敗は、なんらかの事情がある(たぶん)
•成功したら、チームの手柄
失敗したらあなたのせい！

61. デマルコ
正しい管理の４つの本質
適切な人材を雇用する
その人材を適所にあてはめる
人びとの士気を保つ
チームの結束を強め、維持する

62. チームはなにができるだろう？
• 自信と信頼をキープ！
– 目の前のミッションを確実に遂行
– 自分たちの自由にできる領域を広げる
– 信頼貯金…信頼を意識する
– 後手に回らない。信頼が下がると自分たちの
自由が制限されるから
• 『結果にコミットする！』のは難しいけど、
期待を上回る結果を出す覚悟

63. でもね

64. 大事なのは成果
• 成果を上げる人間関係に必要なもの
– コミュニケーション
– チームワーク
– 自己啓発
– 人材育成

65. 結論！

66. いろいろやったら
ええんちゃう？

67. まだだ
まだ終わらんよ！

68. いろいろやると問題も起きます！

69. それは不運ではなく必然…

70. それはチームが
成長したあかしなので、
くじけずに頑張ってください！

71. わたしの原動力

72. 意味のない仕事に人生を費やす人がいてはいけない。
ビジネスとして無駄なだけでなく、
その人の心をだめにしてしまう
『スクラム 仕事が４倍速くなる“世界標準”のチーム戦術』 Jeff Sutherland

73. 開発の世界に人の心の光を！

74. ありがとうございました！

75. 自己紹介
アジャイルコーチやってます
主にスクラム導入の支援
開発戦略の策定を支援
チームの育成を支援
山本 雄一郎
スクラム導入コーチ
開発チームの構築・開発戦略コンサルタント
u1r.yamamoto

76. 全員参加の開発
76

77. 77
トップエンジニアでなくても
貢献できるヨ！

78. 78ワークショップで気づく、楽しく考える
業務の窮屈さから離れる
問題解決を楽しく経験する
開発を違う角度で見れるようになる

79. 79建設的な目的共有・問題認識
共感できるゴールを描く
ビジョンを共同所有する
やれる感覚と参加意思の確認

80. 80組織的な学習の場をつくる
処刑のない “ふりかえり”
試せて検査できる環境
視点や価値観の多様性を尊重する

81. 理解共有と洗練のループ 81
Sprint
コンセプトと
プロダクトの検証・洗練
ゴールと手段の
共有と洗練
実装による検査と適応
開発業務の改善
“Paper Prototyping”
“Vision Board”
(Roman Pichler)
“Lean Canvas”
”Business Model Canvas”
開発についての
課題認識
気づきの
ワークショップ
“User Story Mapping”

82. 82
みんなが
チームの一員になる
上意下達よりも相互作用を
能力ヒエラルキーでなく補完関係に

83. 83
和気あいあいとやる
それでいい…のか？

84. 現実はとても厳しい
84
進捗が不透明
納期に間に合うのか
改善が見えない
必死さが足りない
ただの馴れあいに違いない

85. 自主的な開発活動とは、
開発者の好き勝手にやること
ではない
85

86. できる人になるまで、
１万時間
86
K・アンダース・エリクソン調べ
Photo by 膀胱眼球胎
https://commons.wikimedia.org/wiki/File:Taki-gyo_8118084.jpg

87. 87やらない理由を探し始める
認知的不協和の解消
↓やるほうがよさそう、そうしたい
↓やってみたが結果が伴わなかった
↓これまでやらなくても良かった
↓つまり、やらないのが普通
→忙しくて時間が無い
→私は仕事だと割り切っている
→一部のハイレベルな人の話だ
→馬鹿げた活動だ
→私には他にやるべきことがある
Illustration by Milo Winter.
http://commons.wikimedia.org/wiki/File:The_Fox_and_the_Grapes_-_Project_Gutenberg_etext_19994.jpg

88. 88まずは、できないことを思い知ることから
技術知識は足りているか？
要求を理解できているか？
自分で設計できるか？検査できるか？
本当にこなせる量のタスクか？
「努力する」以外に答えは？

89. 89
仕事は
自分ひとりでやるものではない

90. 90誰かを頼りにする
出来ないことは仲間に頼む
危ないところは助けてもらう
仲間を手伝って貢献する
頼りにすることで技術が習得できる
相互の依存から生まれる相乗効果

91. 上意下達よりも、相互作用を
能力ヒエラルキーでなく、補完関係に

92. 92

93. 上意下達よりも、相互作用を
能力ヒエラルキーでなく、補完関係に
みんなが
チームの一員になる

95. 最後に私から
偉人の言葉を
お借りして締め
たいと思います

96. ごめんよ、まだ僕には帰れるところがあるんだ。
こんな嬉しいことはない。
アムロ・レイ

99. 99
SCRUM BOOTCAMP
OSAKA
Photo by
https://www.flickr.com/photos/parrisisland/14866403579/

100. 100100
SCRUM
BOOTCAMP
OSAKA
S
B

101. みなさんがもっ
とうまく開発が
できますように