創業105年の星野リゾートでは、他社と差別化を図るために、多くのシステムを独自に作っていたが、旅館運営企業を生業であったため、ほぼ全てのシステムを外部に発注していました。 そのため、近年の技術の進化やビジネスの展開にシステムが追いつかず、システムが企業のボトルネックになっていました。 本セッションでは、非IT企業である星野リゾートが、システム開発の内製化を目指し、どのように毎週リリースするチームを一から構築したのかお話いたします。

1. 【13-D-4】創業105年の旅館運営企業が実現した
毎週リリースするチームの作り方
（ Developers Summit 2020）
2020/02/13 藤井 崇介
1

2. 自己紹介
名前・所属：
星野リゾート 情報システムグループ
藤井 崇介（２０１８年入社、京都勤務）
資格：
Scrum Inc. 認定スクラムマスター(LSM)
家族：
双子の父親、育児にも奮闘中。
趣味：
カプセルホテル巡り？？
2
@ZooBonta

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

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

5. 5

6. 6
サーフジャック ハワイ

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

8. 星野リゾートの組織文化
◼ 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. （今から3か月でできる…）
はい、（開発工数は）3か月くらいです。
（いつから着手できるか分かりませんが…）
予約サイトに銀行振込決済機能
を入れられますか？
情シス担当者
販売チーム担当者
販売チーム担当者
工数を答えたのにスケジュールだと思われる。
情シスあるある
15

16. 事件2 絶対に予約ができない広告
（２０１７年）
16

17. 広告出しているのに、予約ができないです！！
（リリース予定してたっけ？）
ありがとうございます！
（完成したからリリースしよう）
お待たせしていた機能を本日リリースしました。
情シス担当者
開発会社
17
※広告については、後日、情シス費用で出し直させていただきました。
販売チーム担当者

18. 広告出しているのに、予約ができないです！！
（リリース予定してたっけ？）
ありがとうございます！
（完成したからリリースしよう）
お待たせしていた機能を本日リリースしました。
情シス担当者
開発会社
18
※広告については、後日、情シス費用で出し直させていただきました。
販売チーム担当者
肝心な日にリリースが行われ、失敗する。
外部委託あるある

19. エンジニア組織の内製化には消極的だった
19
◼ 消極的な理由
◼ 企業の母体はリゾートの運営会社である
◼ よってエンジニアが自社の中にいるイメージが経営陣にはない
◼ 餅は餅屋的な考え方があった
システムは外部ベンダーに発注した方がよいのでは？

20. 既成事実を作ろう
20
考えた作戦

21. 21
既成事実とは？
◼ 外部に依存した体制を脱却したい。
◼ 一方で、いきなり内製化は、社内で合意できない。
まずは１人増やして、成果を出す。

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

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

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

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

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

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

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

29. ミーティング
部署を越えて話し合う
29

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

31. 合意形成フローの整理
情報システムコールセンター
販売チームA
販売チームB
販売チームC
・・・
海外販売
販売統括
オペレーション
31

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

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

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

35. Fポイントの仕組み
溜まったFポイントで何しようかな♪
販売チームの皆さん
35
※星野リゾート社内の共通基準単位です

36. 開発体制の構築
36

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

38. 体制構築当初の状況
1. 動いているシステムを知っているのは自分一人だけである。
2. フルリモートで初めて仕事をする人ばかりなので、お互いが分
からない
3. 物理的にも文化的にも会社がバラバラである。
38
効率だけを重視した開発を進める

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

40. これ以上、無理・・・
自分
もっと改善していきたい♪
販売チームの皆さん
40

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

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

43. そんなときに出会った１冊の本
43
著者：市谷 聡啓
(ISBN-13: 978-4798153346)
目の前に起きている現実がそこにあった。

44. スクラム導入
44

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

46. 3つのロール
3つのアーティファクト
5つのセレモニー
46
スクラムを導入した理由

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

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

49. スクラムで良かったこと
1. 機能横断でチームを作る
2. 改善に時間を使う
3. 生の声を聴いてもらう
49

50. 機能横断でチームを作る
フロントエンド
（東京）
自分
（京都）
サーバサイド①
（島根）
サーバサイド②
（東京）
サーバサイド③
（福岡）
インフラ
（大阪）
50

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

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

53. 改善にも時間を使う
フロントの標準をNuxt + Vue.JSにしたい
Dockerで開発環境作れば、構築楽になるのでは？
プルリクの承認でビルド・デプロイできるようにしたい
53

54. 改善にも時間を使う
フロントの標準をNuxt + Vue.JSにしたい
Dockerで開発環境作れば、構築楽になるのでは？
プルリクの承認でビルド・デプロイできるようにしたい
時間があれば、改善したいことがたくさんあった
54

55. 生の声を聴いてもらう
55
開発者 情シス担当者
販売チーム担当者
要件/受入
質問/納品
◼ 以前の体制
要望
報告
コールセンタースタッフ

56. 生の声を聴いてもらう
56
開発者
情シス担当者 販売チーム担当者
◼ 現在の体制
コールセンタースタッフスプリント
レビュー

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

58. Ganhoな組織とScrumの関係
58
◼ フラットな組織
◼ 組織を横断した体制
◼ 全員で合意形成
◼ 全員が同じ情報を持つ
◼ ３つのロール
◼ 機能横断チーム
◼ プロダクトバックログリファインメ
ント、スプリントプランニング
◼ 朝会の実施、スプリントボード
考え方 実践
ScrumはGanhoな組織文化とマッチ度が高かった。

59. 改善が進めば内製化も進む
ミーティング
59

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

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

62. 成果が出れば経営者も言うことが変わる
62
https://tech.nikkeibp.co.jp/atcl/nxt/column/18/00677/120400034/ より抜粋

63. エンジニアは何の価値をもたらした？
63

64. 意志決定の速さ
1. 世の中のあらゆる仕組みにシステムが関わっている。
2. 意志決定には、システムの知識も必要である。
3. エンジニアが入ることで、意思決定しやすくなる。
64
意志決定の速さ ＝ ビジネスの進化

65. 意志決定者
旅館運営企業だからこそ生み出したエンジニアの価値
65
販売チーム担当者
コールセンタースタッフ
現場スタッフ
要求者
経営者

66. 意志決定者
投資価値は？
実現時期は？
投資額は？
旅館運営企業だからこそ生み出したエンジニアの価値
66
販売チーム担当者
コールセンタースタッフ
現場スタッフ
要求者
お客様の利便性を
向上したい
魅力的な売り方をしたい
お客様を喜ばせたい
経営者

67. 意志決定者
投資価値は？
実現時期は？
投資額は？
旅館運営企業だからこそ生み出したエンジニアの価値
67
販売チーム担当者
コールセンタースタッフ
現場スタッフ
要求者
お客様の利便性を
向上したい
魅力的な売り方をしたい
お客様を喜ばせたい
経営者 エンジニア
実現者
実現方法
時期
金額

68. 意志決定者
投資価値は？
実現時期は？
投資額は？
旅館運営企業だからこそ生み出したエンジニアの価値
68
販売チーム担当者
コールセンタースタッフ
現場スタッフ
要求者
お客様の利便性を
向上したい
魅力的な売り方をしたい
お客様を喜ばせたい
経営者 エンジニア
実現者
実現方法
時期
金額
経営者の意志決定速度が上がった

69. まだ、改善は始まったばかり
69

70. 越境を乗り越えるのはこれから
1. スクラムを取り入れられていない開発は多い。
2. 大きな新規案件が増えた分、複数のチームが連携して、
スクラムを回す必要が出てきた。
3. 情シス以外の社内へのスクラムの認知度は低い。
70

71. 現在の活動
71
全ての案件を（F）ポイントで管理

72. 現在の活動
72
スクラム共有会 ストーリーボード

73. 現在の活動
73
スクラム共有会 ストーリーボード
スプリントボード

74. 現在の活動
74
スクラム共有会 ストーリーボード
スプリントボード
よりよいプロセスを日々、研究中。

75. お伝えしたかったこと
1. 外部に依存した体制からの脱却が大事である
2. 改善には支えとなる組織文化と、マッチするスクラムがあった。
3. 非IT企業だからこそ、エンジニアがビジネスを大きく進化させ
る価値を生み出せた。
4. 価値を続けていけば、経営陣も変わる。
75

76. ともにつくる
非エンジニア×エンジニアで
新しい価値を提供したいと思います！
76