Developpers Summit 2019 KANSAIの登壇資料になります。 ホテル・旅館運営企業が、外部委託で全くうまくいかなかったシステム開発を、 どのように改善していったのか、これからどこに向かっているのかを説明した資料になります。 今後、システムを内製化したい人、開発プロセスを改善したい人の参考になれば幸いです。

1. 【A-5】ホテル・旅館運営企業が
毎週リリースするDevOpsサイクルを作るまでの道のり
（ Developer Summit 2019 KANSAI）
2019/09/27 藤井 崇介
1

2. 自己紹介
名前：
藤井 崇介（入社２年目、京都勤務）
資格：
Scrum Inc. 認定スクラムマスター(LSM)
家族：
双子の父親、育児にも奮闘中。
趣味：
カプセルホテル巡り？？
2
@ZooBonta フォローよろしくお願いします。

3. 星野リゾートのご紹介
3

4. 1914 長野県軽井沢に星野温泉旅館が開業。
1990
「リゾート運営の達人」を企業ビジョンとして掲げ、
ホテルを所有するのではなく、運営のみを担うビジネスモデルへと転換
山梨県のリゾナーレ八ヶ岳の再生事業を皮切りに
福島・北海道・青森と大型リゾートの再生案件、日本各地の旅館再生を担う。
星野温泉旅館を改築、「星のや軽井沢」が開業
マスターブランド戦略を展開
「星のや」「界」「リゾナーレ」の3つのサブブランドを展開。
星野リゾートREITを上場
個人投資家が観光産業に投資できる環境を誕生させる。
2001
2005
2009
2013
2014 海外施設の運営開始
4

5. 5

6. ルーズなホテル - BEB
6

7. 情報システム（情シス）の構成
7
情報システムの皆さん

8. 星野リゾートの組織文化
 Ganhoな組織（Ganho = 頑張れ星野）
 フラットな組織
 みんなで意見を出し合う
 誰でも対等に意見交換する
 チームワークによる解決
 部署の枠を超えて、問題を解決する
 一人一人が判断する
 失敗を許容する
著者：Ken Blanchard
(ISBN: 0-688-15428-X)
8

9. 星野リゾートの
システム開発について
9

10. 独自システムが多い
予約システム
販売管理システム
マーケ支援システ
ム
予約管理
kintone G Suite
独自システム
財務管理
勤怠管理 カード決済
外部サービス
外部チャネル連携 ・・・
予約システム・販売管理システムは、
利用者が多いため、特に改善の要望も
多い。
星野リゾートでは、長年、自社の独自システムと外部サービスを併
用することで、企業の運営・施設の運営を行ってきた。
10

11. 自社
HP
予約システム・販売管理システム
星野リゾート
運営施設
¥
宿泊客
非日常な体験
オーナー
運営ノウハウ
スタッフ
¥
¥
売上
¥
運営費
所有
予約チャネル
施設の情報を閲覧
予約する
予約サイトの開発
運用
送客
旅行
サイト
6割超え
・
・
・
11

12. 外部に依存した開発体制
 2016年、情報システムはわずか5名
 システムの導入からPCのキッティング、ネットワークの管理
までやっていた。
 内製するだけの余力はほぼなく、開発は外部委託に頼らざる
を得ない状況だった。
人手不足と外部依存の体制で、度々事件が発生
12

13. 事件1 やるやる詐欺事件
（2016年）
13

14. （今から3か月でできる…）
はい、（開発工数は）3か月くらいです。
（いつから着手できるか分かりませんが…）
予約サイトに銀行振込決済機能
を入れられますか？
情シス担当者
販売チーム担当者
販売チーム担当者
工数を答えたのにスケジュールだと思われる。
情シスあるある
14

15. 事件2 完成したはずが動かな
い
（２０１７年）
15

16. （本番で動くようになって良かった。）
今、忙しいので、使うときになったら確認し
ますね。
（テスト環境で）動作しているので、
受入お願いします。
DM配信システムですが、今月完成します
か？
情シス担当者
情シス担当者
開発会社
システム完成の定義が違う。
外部委託あるある
16

17. そんな状況の中
2018年に入社
17

18. CIO
毎週リリースするくらいの勢いで改善し
て！
予算は確保するから。
自分
やりましょう
。
内製化のスタートラインに立った
18

19. そもそもの問題はどこにある
か？
19

20. 社内の問題点
1. スケジュールの合意形成フローがなかった
1. 依頼者は要望だけ伝えて終わる
2. 優先度が決まらない
1. 各部署から要望が来るため、ステークホルダーが多すぎる。
20

21. ステークホルダーが多い理由
情報システムコールセンタ
ー
販売チームA
販売チームB
販売チームC
・・・
顧客問い合わせ関連
海外販売
販売関連
開発会社
オペレーショ
ン
サービス現場
21

22. 情シス
ステークホルダーが多い弊害
色々言われるんだけど、
どれが優先なの？
販売担当
優先度を付けろって言っても、
ちょっとしかお願いしていないのに・・
・
22

23. Ganhoな組織を活かして
問題を解決
23

24. ミーティン
グ
部署を越えて話し合う
どこにリソースを割
くべき（情シス）
開業の予定は変えら
れない（販売チーム
A）
海外展開が優先で
は？
（海外販売）
販売関連はとりまとめ
ます
（販売統括）
もちろん協力します
（情シス）
24

25. 合意形成フローの整理
情報システムコールセンタ
ー
販売チームA
販売チームB
販売チームC
・・・
海外販売
販売統括
要望を取りまとめる場を設け
た開発まで分かるエンジニアが
入り、合意形成の体制を強化
。
オペレーショ
ン
25

26. 工数をポイント制に変更
 人日/人月の見積もりを辞めた理由
 人日/人月で見積もりは、人に依存するので、あてにならない。
 ポイント(※)の方が、みんなにとって作業量をイメージしやす
い。
※Fポイントと呼ばれてい
ます
26

27. Fポイントの仕組み
依頼者
開発依頼
フォーム
登録
自動連係
登録
自分
ポイント設
定
優先度決定
全体会議
藤井さんのポイントだか
ら、
Fポイントと呼ぼう
開発着手
27

28. Fポイントの仕組み
溜まったFポイントで何しよう
かな♪
販売チームの皆さ
ん
28
ポイントにしただけで、みんながHappyになれ
る！

29. 開発体制の構築
29

30. 2018年入社当初の体制
フロントエ
ンド
（東京）
自分
（京都）
サーバサイド
（島根）
バラバラの拠点で開発を開始
1人
2～3
人
2人
社内
社外
インフラ
（大阪）
1人
30

31. QCDのコントロール
品質
Q（Quality)
納期
D(Delivaly)
コスト
C(Cost)
CI/CD環境の構築
ソースコードのレビュ
ー
試験項目のレビュー
仕様のコントロール
ボトルネックの改善
朝会の実施
アサインの調整
31

32. 改善当初の状況
1. 改善が進みだし、社内からは好評だった。
→2週間に1度はリリースできる体制になった。
2. 自分１人負荷が高かった。
→仕様の指示から修正箇所の指示まですべて１人でやってい
た。
→改善結果の受入がボトルネックだった。
32

33. これ以上、無理・・・
自分
もっと改善していきたい♪
販売チームの皆さ
ん
開始3ヶ月で限界を迎える
33

34. 案件の増加に伴い、体制は強化
フロントエ
ンド
（東京）
自分
（京都）
サーバサイド
①
（島根）
やり方を変えるしかなくなった。
1人
2～3
人
2人
サーバサイド
②
（東京）
2人
サーバサイド
③
（福岡）
3人
インフラ
（大阪）
34

35. ふと気づく違和感
開発がGanhoな組織文化通りになっていないので
は？
スクラムを導入して良いですか？
自分
もちろんです！
CIO
35

36. スクラム導入
36

37. スクラムを導入した理由
1. コミュニケーション機会を増やす
1. 状況は常に把握したい。
2. チーム間で説明内容や議論を共有したい。
2. フォロー体制の強化
1. 溢れそうな場合に、チーム内の判断でヘルプに入って
もらう。
3. 開発効率の改善
1. 一人で指示を出すのが限界だったため、開発メンバー
間で協力してもらいたかった。
37

38. スクラムチームを作成
フロントエ
ンド
（東京）
自分
（京都）
サーバサイド
①
（島根）
1人
2～3
人
2人
サーバサイド
②
（東京）
2人
サーバサイド
③
（福岡）
3人
インフラ
（大阪）
チーム1 チーム２
38

39. スクラムとは？ 3つのロール
3つのアーティファク
ト
5つのセレモニー
39

40. 取り入れたツール
アーティファクト ツール
プロダクトバックログ Backlog
スプリントバックログ Trello / Googleスプレッドシート
インクリメント Jenkins / Circle CI
40

41. スクラムのやり方
セレモニー タイミング
スプリントプランニング 毎週木曜日
デイリースクラム 毎朝
スプリントレビュー 毎週月曜日
スプリントレトロスペク
ティブ
毎週金曜日
バックログリファインメ
ント
第一火曜日（月一回→週一回）
スプリントを期間を１週間とし、ひたすらリリースを繰り返
す。
41

42. スクラムを取り入れて学んだこと
1. 機能横断でチームを作ることが重要である
2. 1つの課題をチームでこなす
3. スクラムチーム自体の改善に時間を使う
42

43. 機能横断でチームを作る
フロントエ
ンド
（東京）
自分
（京都）
サーバサイド
①
（島根）
サーバサイド
②
（東京）
サーバサイド
③
（福岡）
インフラ
（大阪）
チーム1 チーム２
チームを分断すると、
どちらかがボトルネックになる
43

44. 機能横断でチームを作る
フロントエ
ンド
（東京）
自分
（京都）
サーバサイド
①
（島根）
サーバサイド
②
（東京）
サーバサイド
③
（福岡）
インフラ
（大阪）
チーム1 チーム２
同じ機能を改修する人は、
同じチームとする。
44

45.  スウォーミング
 １つのタスクを、みんなで集中して終わらせること。
1つの課題をチームでこなす
45

46.  当初の進め方
スウォーミング
改修１ 改修2 改修３ 改修4 改修5
各自ができる改修に着手する
改修３
終わったら、対応できる次の改修に
入る
46

47.  スウォーミングを使った進め方
スウォーミング
改修１ 改修2 改修３ 改修4 改修5
みんなで同じ改修を協力して対応す
る
改修1
分割するほどの作業でない場合は、１人
で終わらせることもある
改修2
終わったら、次の改修を協力して対応す
る
47

48.  スウォーミング導入によるメリット
 協力することで、小さな成果物を早く提供できる。
 お互いに協力することで、自分ができなかった作業のやり方が分
かる。
 複数人でチェックしながら進められるので、成果物が個人に依存
しない。
スウォーミング
48

49. 改善にも時間を使う
JSPだと触れる人少ないから、Vue.js に変えた
い
Dockerで開発環境作れば、構築楽になるので
は？
プルリクの承認でビルド・デプロイできるよ
うにしたい
時間があれば、改善したいことがたくさんあった
49

50. スクラムを導入した結果
1. 毎週リリースができ、継続可能なDevOpsサイクルが
できた。
2. 改善が進んだことで、問い合わせの件数も半減した。
3. 会社・働き場所を越えて、改善できる体制を構築で
きた。
組織文化を活かすことで、DevOpsサイクルが構築で
きた
50

51. 改善が進めば内製化も進む
ミーティン
グ
未来を見据えて、シ
ステムを再構築した
い
今のシステムだと、
海外に展開しても厳
しい
エンジニアを増やし
て
内製化をもっと進め
よう
ビジネス展開をするために
は、エンジニアを増やすべ
き
改善してほしいこと
が他にもある内製化を始めたことで改善が進み、
経営方針まで変わった
51

52. 現在の体制
サーバサイド
②
（東京）
2人
フロントエン
ド
（東京）
2人
社員
（東京）
1人
フロントエン
ド
（東京）
社員
（東京）
サーバサイド
①
（島根）
2人
1人
1人
自分
（京都）
フロントエン
ド
（東京）
1人
会社のビジネス展開を支えるためには、チームを増やすことが
課題
52

53. お伝えしたかったこと
1. 外部に依存した体制から、内製化に方向転換することで、
改善できる。
2. 改善するためには、組織文化の支えが重要である。
3. 内製化する立場だからこそ、スクラム開発を取り入れら
れる。
4. エンジニアが成果を出すと、経営の方向も変わる。
53

54. Far Together！
今後もGanhoな組織文化を
開発にも活かていきたいと思います！
54