1. 1
2015年2月28日
ＧＭＯインターネット株式会社
次世代システム研究室
藤村 新
開発モデルの作り方
～守破離の破！～
Regional Scrum Gathering Tokyo 2015

2. 藤村 新
ふじむら あらた
アジャイルPM研究会所属

3. 3
• 守破離とは
• 俺の守破離
• 開発モデルを作るということ
アジェンダ

4. 4
守破離とは

5. 5
CSM研修で学んだ守破離
• 守
- ルールに従え
- どうやるかを見て練習を繰り返す
• 破
- 工夫してみる
- 原因と結果をつなげる実験
• 離
- ルールを忘れろ
- 新しい技術を一瞬で考えて使える段階

6. 6
スクラムにおける守破離
• 息をするようにスクラムのルールを行えるようにな
るまでが守
• スクラムのルールに従った上でアレンジしてみるの
が破

7. 7
守破離の語源

8. 8
• 元々は武田信玄に仕えた武将、高坂昌
信(こうさかまさのぶ)の『甲陽軍鑑(こう
ようぐんかん) 』に記された兵法用語

9. 9
• その後千利休が詠んだ(らしい)
• 「規矩(きく)作法 守りつくして 破ると
も 離るるとても 本(もと)を忘るな」
• 『利休百首』

10. 10
• そして千利休の茶道の修行観
を、後世の川上不白(かわか
みふはく)が表現した
• 「守ハマモル、破ハヤブル、 離ハはなると申候。
弟子ニ敎ルハ此守 と申所計也。弟子守ヲ習盡
し能成候へバ自然と自身よりヤブル。これ上手
の段なり、さて、守るにても片輪、破るにても片
輪、この二つを離れて名人なり、前の二つを合
して離れてしかも二つを守ること也。 」
• 『不白筆記』
• 「守破離といふ事軍法用、尤用方違ひ候へ共、
茶道に取て申候はば、守は下手〈略〉破は上手
〈略〉離は名人」
• 横井淡所の『茶話抄』への添え書き

11. 11
守破離とは
「道」
の指針

12. 12
俺の守破離

13. 13
とりあえずやってみた
(お試しフェーズ)

14. 14
• 「アジャイルサムライ」と「アジャイルな見積りと計画
づくり」を読んだだけで、ソシャゲプロジェクトへア
ジャイル開発初導入！
- アジャイル開発を体感できた
- 自分が分かっていないということが分かった

15. 15
• 「スクラムガイド」と「塹壕よりScrumとXP」を読んだ
だけで、ECツール開発プロジェクトへスクラム"風"
初導入！
- スクラムを体感できた
- プラクティス厨じゃダメだということが分かった

16. 16
プロセスの理解
≠
スキル習得

17. 17
本格的に学びたい
(守フェーズ)

18. PMIアジャイルPM研究会立ち上げプロジェクト参画

19. 19
マスター・
センセイ
との
出会い

20. 20
CSPO研修受講
 日時：2013年5月20日～21日
 場所：株式会社ミクシィ
 講師：ジェフ・パットン

21. 21
プロダクトディスカバリを行なって、
プロダクトバックログを作るまでを
学んだ。
※スクラム開始前のフェーズ
※デザイン思考の話し

22. 22
CSM研修受講
 日時：2013年6月20日～21日
 場所：ビジョンセンター日本橋
 講師：江端一将、Sergey

23. 23
スクラムの基礎を
座学とワークショップ
を通して学んだ。

24. 24
• 勉強会、ワークショップ、イベントに参加
• アジャイルサムライ横浜道場
• POStudy
• レゴスクラム(見学)
• AEP読書会
• Scrum Masters Night
• Agile Japan 2014
• Regional Scrum Gathering Tokyo 2014

25. 25
アウトプット！
アウトプット！
アウトプット！

26. 26
• 担当プロジェクトへ各種プラクティス導入
• リーンカンバン、WIP
• 朝会、ふりかえり、計画MTG
• グループ会社への導入支援
• インセプションデッキ
• 導入事例を書く、話す
• 採用ブログに書く
• 自社、他社に話す
• 部署内での啓蒙活動
• アジャイルな見積もりと計画づくりまとめ
• アジャイル開発取り組み状況

27. 27
第1回アジャイルミーティング主催
 日時：2013年10月9日
 場所：GMO Yours
 内容
1. PMIアジャイルPM研究会立ち上げプロジェクトの紹介
2. 次世代システム研究室
3. GMOリサーチ
4. GMO ECラボ
5. GMOペパボ
6. 交流会

28. 28

29. 29
• 次世代システム研究室では GMOベトナムラボセン
ター(ベトナム/ハノイ)と密接に連携しながらGMO
インターネットグループのシステム開発(オフショア
開発)に取り組んでいたが、必ずしもうまくいってい
るとは言えない状況だった
• オフショア開発プロセス改善に取り組むことになっ
たため、国内プロジェクトで実践していた各種プラ
クティスを導入するも問題多発

30. 30
• 1度のやり取りで完成しない
• オフショアチームの見積もり精度が低い
その結果
• 遅延を繰り返す
• モチベーションが下がる
• スケジュールが信頼できなくなる
• 相手を信頼できなくなる

31. 31
• オフショアチームで品質を担保できない
その結果
• 日本側の発注者の負荷増大
• 明らかなバグから細かいバグまで全て確認し、
指摘する必要がある

32. 32
• あとちょっとの修正も、修正を依頼するため
のコストが結構かかる
その結果
• 95%完了から完成まで時間がかかる

33. 33
試行錯誤を重ね
辿り着いた
破
の境地

34. 頑張っても
効果が薄い事を
諦めてみた

35. 一度のやり取りで期待通
りのアウトプットが出て
こない

36. 一度のやり取りで期待通
りのアウトプットが出て
こない
時間をかけてもっと詳細
な仕様書を準備する

37. 一度のやり取りで期待通
りのアウトプットが出て
こない
時間をかけてもっと詳細
な仕様書を準備する

38. 一度のやり取りで期待通
りのアウトプットが出て
こない
1度のやり取りでの完成を
諦めた初回ザックリ開発

39. 見積もりの精度が低く、
完了予定が見えない

40. 見積もりの精度が低く、
完了予定が見えない
時間をかけて見積もりの
精度を上げてもらう

41. 見積もりの精度が低く、
完了予定が見えない
時間をかけて見積もりの
精度を上げてもらう

42. 見積もりの精度が低く、
完了予定が見えない
ザックリ開発工数だけ見積
もってもらい、実見積もりは
完了係数を使って算出

43. ※完了係数とは、
(サイクルタイム/ザックリ開発
工数)
の平均で求める係数。
ザックリ開発工数の見積もり日
数に完了係数を掛けることで、
予想完了日が算出できる。

44. 95%完了から先が長い

45. 95%完了から先が長い
再度指示書を書いて、完
成してもらう

46. 95%完了から先が長い
再度指示書を書いて、完
成してもらう

47. 95%完了から先が長い
最後の5%は日本側で完成
させる

48. これら改善施策を
盛り込んだ
開発モデルを
考えてみた。

50. Rough
Fill
Closing

51. ベースは
リーン開発の
カンバン

54. Rough
Fill
Closing

55. 55
• ザックリ開発するフェーズ
• 7割程度の完成度を目指す
• 着手する前にザックリ開発工数を見積もっても
らう

56. Rough
Fill
Closing

57. 57
• Roughフェーズでのアウトプットの完成度を上げ
るフェーズ
• 9割以上の完成度を目指す

58. Rough
Fill
Closing

59. 59
• 完成させるフェーズ
• 日本側の発注者(エンジニア)が対応する

60. 60
RFCモデルの詳細は
で、お話しさせて
頂く予定です。

61. 61
開発モデルを作るということ

62. 62
開発モデルを作ること
≒
破のフェーズ

63. 63
破＞＞＞＞＞＞＞
＞超えられない壁＞
＞＞＞＞＞＞＞＞
＞＞＞＞＞自己流

64. 64
形を持つ人
だけが、
形を破れる

65. 65
• 十八代目 中村 勘三郎が19の時、唐十郎の巨
大テントで「下町唐座」を見たときのこと
なんだこれは！？
自分がやっている歌舞伎座での
落ち着いた空気とは全く違うじゃ
ないか！
でも待てよ、昔の歌舞伎はこう
だったのでは？

66. 66
• 早速親父(十七代目 中村 勘三郎)に直訴
これこそ歌舞伎の原点だ。
歌舞伎もこれに戻らなきゃいけない。
俺もあのような歌舞伎がしたい。
百年早い。
そんなことを考えてる間に百回稽古
しろ。

67. 67
• なんで親父は分かってくれないんだ！
• そんなモヤモヤしてた折、たまたまラジオから流
れてきた全国子供電話相談室での無着成恭(禅
宗の僧侶、教育者)の回答を耳にする
型破りと形無しの違いはなんですか？
そりゃあんた、型がある人間が型を
破ると『型破り』、型がない人間が型
を破ったら『形無し』ですよ。

68. 68
• 父の言う「百年早い」の意味が分かった
古典をしっかり学んで自分の形を作
れ。
19や20の未熟者が土台もないのに
新しいことをやるな。
• 2000年(45才)に平成中村座を上演

69. 69
形無し開発モデルは
百害あって一利なし。
型破り開発モデルを
編み出そう！

70. 70
楽天 Tech Talkでの発表後、

71. 71

72. 72
• 同時に、あ、こういうモデルを考えだすのって、そんなご大層なも
のじゃないんだとか思った
• こんなん自分でも考えられるぜ！って言いたいのではなくて超
頭いい人が美しい理論のもとに弾きだした答えではなく、僕の
ような普通の人が苦しみ苦しみ抜いてその時々考えたことを
集めて体系化したという意味でなんだかすごい身近に感じた。
• というか、今自分のチームでも自分たちなりのKAIZENをいろ
いろしてるし、それをまとめればそれだけでひとつのモデルに
なるなー
http://daily.belltail.jp/?p=1880

73. 73
そうなんです！

74. 74
新しい開発モデル
を考えるなんて
大層なものじゃない
んです！
(※ただし守済に限る)

75. 75
現場のカイゼンを
体系化して言語化
すれば、それも立派
な開発モデル。
(※ただし守済に限る)

76. 76
ぜひこの事を話したいと思い
今回の公募セッションに
応募しました。
おさかなさんありがとう。
※新卒1年目の方でした…

77. 77
まとめ

78. 78
• まずはしっかりと型を学ぼう(守)
• 型をしっかりと身に付けた上で、
現場の改善に取り組もう(破)
• 取り組んだ内容を体系化し、開発
モデルとしてアウトプットしよう

79. 79
• 個人的には、試守破離がオススメ
• 試したからこそ守破離の大切さ
を痛感させられた
• 「型破りな開発モデル」を発表し合
えるような場を作っていきたい

80. 次世代システム研究室では
エンジニアを募集しています！
http://recruit.gmo.jp/engineer/jisedai/

81. 81
ご清聴、ありがとうございました