「餅は餅屋、開発は開発会社」を覆した星野リゾートの“Ganhoな組織”とは何か：DXを成功させるための組織論（4）（1/2 ページ）

「エンジニアを雇うといってもどう評価すればいいか分からない」「餅は餅屋」――かつてはそんな考え方が根付いていた星野リゾートだが、今やトップが「社内に優秀なエンジニアを抱えることが極めて重要」と発信するまでになった。この変化は一体どのように起こったのだろうか。

[高橋睦美，＠IT]

　リゾートの運営に特化し、ただ宿泊するだけでなく、さまざまなコンセプトに基づいた新たな体験を提供している星野リゾートは、主力の高級ブランド「星のや」の他、「界」「リゾナーレ」といった新たなブランドの立ち上げや海外展開も開始している。

　一方、一連の事業を支えるITシステムに関しては、外注から内製化へのシフトが進行中だという。星野リゾートの藤井崇介氏（情報システムグループ　シニアアーキテクト）は、2020年2月13〜14日にホテル雅叙園東京で開催された「Developers Summit 2020」の講演「創業105年の旅館運営企業が実現した毎週リリースするチームの作り方」で、その狙いと試行錯誤の道のりを紹介した。

「Ganhoな組織文化」をベースにする星野リゾート

　星野リゾートは、予約システムや販売管理システム、財務、勤怠管理システムに至るまで、パッケージではなく独自システムを用いている。「差別化を図り、他社との競争に勝ち抜くには、独自のシステムを作り上げなければいけない」という考え方に基づくものだ。

星野リゾートの藤井崇介氏

　これを支えている情報システムグループのメンバーは現在約30人。東京と軽井沢、そして藤井氏のいる京都という3つの拠点を結び、システム開発やサポート、問い合わせ対応といった業務を担っている。改良プロジェクトや新規業務を設計する「APMチーム」に所属するメンバーもいるが、必ずしもエンジニア経験者ばかりというわけではない。ホテルのフロントや調理の経験者も含まれているそうだ。

　そんなさまざまなメンバーをつないでいるのが「Ganhoな組織文化」だと藤井氏は説明した。Ken Blanchard著の書籍『Gung Ho！』からとった言葉だが、「頑張れ星野」の略でもある。「みんなで意見を出し合えるフラットな組織」「全員が同じ情報を共有する」「チームワークによる解決」という3つのコンセプトを包含した考え方で、これを全ての社員が共有しているという。

外部委託に頼る開発体制が招いた、本当にあった怖い話

　とはいえ、情報システムグループがはじめからこうした体制だったわけではない。

　星野リゾートのビジネスモデルは、自社で宿泊施設を保有するのではなく、オーナーが所有するホテルの運営を担い、集客して売り上げを計上するものだ。このため、予約システムや販売システム、Webサイトの開発には力を入れており、顧客の6割が自社Webページから流入しているという。

　だが2016年まで、情報システムグループのメンバーはたった5人だった。この5人でシステムの導入からPCのキッティング、ネットワーク管理に至るまで全てを担っていたという。「当然、内製するような余力はない。だから、こちらが要件だけ出して、開発は外部委託に頼る状況になっていた」（藤井氏）

　その結果、さまざまな問題が起こった。

やるやる詐欺事件

　例えば、販売チームから「予約サイトに銀行決済機能を追加できないか」と尋ねられ、「開発工数は3カ月くらい」と答えた結果、情報システムグループ以外の皆が「3カ月後には新機能が追加される」と期待してしまった。そして3カ月後、何もできていない状況に対し、「一体どうなっているのか」と責められる――情報システムグループとしては工数を答えたつもりがスケジュールと思われ、「やるやる詐欺」になってしまうケースがしょっちゅう起きたそうだ。

合意形成フローもなければ優先順位付けもない、過去のプロセスの課題

　こうした苦い経験を経ても、リゾート運営をなりわいとする星野リゾート社内には「餅は餅屋。システム開発は社外に発注した方がいい」という考え方が根強かった。仮にエンジニア組織を内製化したとしても「どう使い、どう評価し、どう成長していってもらうかイメージできない」という理由もあった。

　しかし、前述のような問題を解決するには、やはり外部依存体制からの脱却が必要だと考えた情報システムグループは、まず1人増やして成果を出し、また1人増やしていく……という具合に、既成事実を作りながら少しずつ進めていく作戦を立てた。

　これまでのやり方には、2つの問題点があった。1つ目は合意形成フローがなかったこと。「依頼する側は要望を伝えるだけで終わり、情報システムグループ側は可能なリソースの中でスケジュールを見積もるだけで終わるため、いつリリースされるかも、社内からいつのリリースが期待されているかも分からない状況だった」（藤井氏）

　2つ目は、優先度を決められなかったこと。星野リゾートが展開する各ブランドや海外の販売担当者に加え、現場でサービスを提供しているオペレーションサイド、さらに顧客からの電話を受け付ける予約担当など、複数のステークホルダーからばらばらに情報システムグループに要望が寄せられる状態で、全体としてどう優先順位を付けるかが不明瞭だった。

　藤井氏らはまず、「Ganhoな組織として問題を解決しようと考えてプロジェクトを立ち上げ、最初に部署を超えた話し合いを実施した」という。

　当初はどの部署も譲らない状況だったが、販売統括担当の協力を得てようやく要件の取りまとめが進み始めた。ただ、スケジュールへの落とし込みの段階で手が止まってしまった。販売統括だけでは答えを出せないからだ。そこで各案件の問題点を整理し、回答できるエンジニアを加えた。合意形成プロセスの強化が目的だ。

　「合意形成を強化する中で分かったのは、人日や人月で工数を見積もるのは難しいことだ。例えば『3人月』といっても、『1人で3カ月』なのか『3人で1カ月』なのかで違うし、どんなスキルセットの人かによっても変わる。そのため、人日での見積もりをやめ、作業量をイメージするために独自に『Fポイント』という制度を作った」（藤井氏）

Fポイントの仕組み

　Fポイントは「藤井ポイント」の略だ。Kintoneと連携した開発依頼フォームに入力したデータに基づいて算出される。全体会議では、Fポイントという共通の指標を見ながら開発の優先順位を付けられるようになった。

やりたかったのはこれだ！　と「カイゼン・ジャーニー」で直感

　次に取り組んだのは開発体制の整備だった。

　それまで依頼していた開発会社はいったんリセットし、自社で人を集めた。そこまではよかったが、東京、大阪、京都、島根といった具合に、全員がばらばらの拠点にいる状態で開発を始めることになった。星野リゾートの既存システムについて知っているのは藤井氏一人だけ。しかも、これまで面識がなかったそれぞれのメンバーがフルリモートで開発に取り組むことになり、「お見合いじゃないが、互いに何を言えばいいか、何を期待したらいいか、手探りしながら始まった」と藤井氏は振り返る。

　当初は、改善への強いプレッシャーを感じていたこともあり、効率重視で開発を進めていた。具体的には「『ソースコードのここがおかしいからこう直してほしい』というレベルに至るまで、全て私が指示を出していた」（藤井氏）という。

　すぐに頓挫するかと思いきや、それなりに成果は生まれ、2週間に1回程度の頻度でリリースできるようになった。周囲からも歓迎されたが、長続きする体制ではなかった。当然だが、藤井氏に負荷が集中してボトルネックになってしまったのだ。

　そこで出会った本が市谷聡啓氏の著書、『カイゼン・ジャーニー』だった。「私はこれがやりたかったんだ」と感じた藤井氏は3日ほどで読破し、その後の3日間で一通りスクラムの仕組みを作り上げた。

　カイゼン・ジャーニーを読み、スクラム導入を通じて実現したかったことは3つあったそうだ。1つ目はコミュニケーションの機会を増やし、全員で同じ情報を共有すること。これにより、誰か1人が判断を迫られるのではなく、チーム内で議論や説明を共有し、皆の組み合わせでチームを良くしていきたいと考えた。2つ目は、状況に応じてチーム内で判断してヘルプできるようなフォロー体制を強化すること。そして3つ目は要件の取りまとめと実際の開発作業を分けることで、開発効率を高めることだ。

スクラム導入を通じて実現したかったこと

　こうした狙いを実現するため、ロールを決め、スプリントを定め、「バックログリファインメント」や「スプリントプランニング」、レビューといったセレモニー（イベント）を導入し、さらに「Backlog」や「Stories on Board」「Trello」「Google Spreadsheet」「Zenhub」といったさまざまなツールを取り入れ、調整していった。

　「スプリントの期間は1週間に決めたが、やってみたところこの『1週間のスプリント』はだいぶハードだ。気が付いたら半分終わってしまっている。だが、1週間で成果を出す必要があるので『この1週間でどういう成果を出すか』を皆で真剣に話し合うようになり、コミュニケーションの機会が増えた」（藤井氏）