開発モデルの作り方(守破離の破)

81
1 2015228GMOインターネット株式会社 次世代システム研究室 藤村 開発モデルの作り方 ~守破離の!~ Regional Scrum Gathering Tokyo 2015

Transcript of 開発モデルの作り方(守破離の破)

1

2015年2月28日

GMOインターネット株式会社

次世代システム研究室

藤村 新

開発モデルの作り方

~守破離の破!~

Regional Scrum Gathering Tokyo 2015

藤村 新 ふじむら あらた

アジャイルPM研究会所属

3

• 守破離とは

• 俺の守破離

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

アジェンダ

4

守破離とは

5

CSM研修で学んだ守破離

• 守 - ルールに従え - どうやるかを見て練習を繰り返す

• 破 - 工夫してみる - 原因と結果をつなげる実験

• 離 - ルールを忘れろ - 新しい技術を一瞬で考えて使える段階

6

スクラムにおける守破離 • 息をするようにスクラムのルールを行えるようになるまでが守

• スクラムのルールに従った上でアレンジしてみるのが破

7

守破離の語源

8

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

9

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

10

• そして千利休の茶道の修行観を、後世の川上不白(かわかみふはく)が表現した • 「守ハマモル、破ハヤブル、 離ハはなると申候。弟子ニ敎ルハ此守 と申所計也。弟子守ヲ習盡し能成候へバ自然と自身よりヤブル。これ上手の段なり、さて、守るにても片輪、破るにても片輪、この二つを離れて名人なり、前の二つを合して離れてしかも二つを守ること也。 」 • 『不白筆記』

• 「守破離といふ事軍法用、尤用方違ひ候へ共、茶道に取て申候はば、守は下手〈略〉破は上手〈略〉離は名人」 • 横井淡所の『茶話抄』への添え書き

11

守破離とは 「道」

の指針

12

俺の守破離

13

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

14

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

15

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

16

プロセスの理解 ≠

スキル習得

17

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

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

19

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

20

CSPO研修受講

日時:2013年5月20日~21日

場所:株式会社ミクシィ

講師:ジェフ・パットン

21

プロダクトディスカバリを行なって、

プロダクトバックログを作るまでを

学んだ。

※スクラム開始前のフェーズ

※デザイン思考の話し

22

CSM研修受講

日時:2013年6月20日~21日

場所:ビジョンセンター日本橋

講師:江端一将、Sergey

23

スクラムの基礎を

座学とワークショップ

を通して学んだ。

24

• 勉強会、ワークショップ、イベントに参加

• アジャイルサムライ横浜道場

• POStudy

• レゴスクラム(見学)

• AEP読書会

• Scrum Masters Night

• Agile Japan 2014

• Regional Scrum Gathering Tokyo 2014

25

アウトプット! アウトプット! アウトプット!

26

• 担当プロジェクトへ各種プラクティス導入

• リーンカンバン、WIP

• 朝会、ふりかえり、計画MTG

• グループ会社への導入支援

• インセプションデッキ

• 導入事例を書く、話す

• 採用ブログに書く

• 自社、他社に話す

• 部署内での啓蒙活動

• アジャイルな見積もりと計画づくりまとめ

• アジャイル開発取り組み状況

27

第1回アジャイルミーティング主催

日時:2013年10月9日

場所:GMO Yours

内容

1. PMIアジャイルPM研究会立ち上げプロジェクトの紹介

2. 次世代システム研究室

3. GMOリサーチ

4. GMO ECラボ

5. GMOペパボ

6. 交流会

28

29

• 次世代システム研究室では GMOベトナムラボセン

ター(ベトナム/ハノイ)と密接に連携しながらGMO

インターネットグループのシステム開発(オフショア

開発)に取り組んでいたが、必ずしもうまくいってい

るとは言えない状況だった

• オフショア開発プロセス改善に取り組むことになっ

たため、国内プロジェクトで実践していた各種プラ

クティスを導入するも問題多発

30

• 1度のやり取りで完成しない

• オフショアチームの見積もり精度が低い

その結果

• 遅延を繰り返す

• モチベーションが下がる

• スケジュールが信頼できなくなる

• 相手を信頼できなくなる

31

• オフショアチームで品質を担保できない

その結果

• 日本側の発注者の負荷増大

• 明らかなバグから細かいバグまで全て確認し、

指摘する必要がある

32

• あとちょっとの修正も、修正を依頼するため

のコストが結構かかる

その結果

• 95%完了から完成まで時間がかかる

33

試行錯誤を重ね 辿り着いた

破 の境地

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

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

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

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

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

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

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

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

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

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

95%完了から先が長い

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

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

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

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

Rough Fill Closing

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

Rough Fill Closing

55

• ザックリ開発するフェーズ

• 7割程度の完成度を目指す

• 着手する前にザックリ開発工数を見積もっても

らう

Rough Fill Closing

57

• Roughフェーズでのアウトプットの完成度を上げ

るフェーズ

• 9割以上の完成度を目指す

Rough Fill Closing

59

• 完成させるフェーズ

• 日本側の発注者(エンジニア)が対応する

60

RFCモデルの詳細は

で、お話しさせて 頂く予定です。

61

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

62

開発モデルを作ること ≒

破のフェーズ

63

破>>>>>>> >超えられない壁> >>>>>>>> >>>>>自己流

64

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

65

• 十八代目 中村 勘三郎が19の時、唐十郎の巨大テントで「下町唐座」を見たときのこと

なんだこれは!? 自分がやっている歌舞伎座での落ち着いた空気とは全く違うじゃないか! でも待てよ、昔の歌舞伎はこうだったのでは?

66

• 早速親父(十七代目 中村 勘三郎)に直訴

これこそ歌舞伎の原点だ。 歌舞伎もこれに戻らなきゃいけない。 俺もあのような歌舞伎がしたい。

百年早い。 そんなことを考えてる間に百回稽古しろ。

67

• なんで親父は分かってくれないんだ! • そんなモヤモヤしてた折、たまたまラジオから流れてきた全国子供電話相談室での無着成恭(禅宗の僧侶、教育者)の回答を耳にする

型破りと形無しの違いはなんですか?

そりゃあんた、型がある人間が型を破ると『型破り』、型がない人間が型を破ったら『形無し』ですよ。

68

• 父の言う「百年早い」の意味が分かった

古典をしっかり学んで自分の形を作れ。 19や20の未熟者が土台もないのに新しいことをやるな。

• 2000年(45才)に平成中村座を上演

69

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

70

楽天 Tech Talkでの発表後、

71

72

• 同時に、あ、こういうモデルを考えだすのって、そんなご大層なも

のじゃないんだとか思った

• こんなん自分でも考えられるぜ!って言いたいのではなくて超

頭いい人が美しい理論のもとに弾きだした答えではなく、僕の

ような普通の人が苦しみ苦しみ抜いてその時々考えたことを

集めて体系化したという意味でなんだかすごい身近に感じた。

• というか、今自分のチームでも自分たちなりのKAIZENをいろ

いろしてるし、それをまとめればそれだけでひとつのモデルに

なるなー

http://daily.belltail.jp/?p=1880

73

そうなんです!

74

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

75

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

76

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

77

まとめ

78

• まずはしっかりと型を学ぼう(守)

• 型をしっかりと身に付けた上で、

現場の改善に取り組もう(破)

• 取り組んだ内容を体系化し、開発

モデルとしてアウトプットしよう

79

• 個人的には、試守破離がオススメ

• 試したからこそ守破離の大切さ

を痛感させられた

• 「型破りな開発モデル」を発表し合

えるような場を作っていきたい

次世代システム研究室では エンジニアを募集しています!

http://recruit.gmo.jp/engineer/jisedai/

81

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