星野リゾートがこだわった「内製化」－現場出身メンバーが躍進するプロダクトオーナーチーム｜SEカレッジ ウェビナーレポート

コロナ禍で、やはり観光業には非常に大きな打撃がありました。特に一番大きな打撃だったのは、 2020 年 4 月、 5 月です。その時は、売上げが 9 割減となり、さすがにこのままでは会社がもたないということで、代表である星野佳路が、 18 ヵ月間非常事態宣言というものを策定しました。

とにかく 18 ヵ月間生き残ろう、 18 ヵ月間がんばっていれば、きっとワクチンが出来て需要が回復するに違いないと。

そこで全社で対策にいろいろ乗り出していたんですけど、ひとつ、大きかったのが、マイクロツーリズム市場です。それまでそういう言葉はなかったんですが、いわゆる近隣への旅行ですね。近隣への旅行の市場を創造して、今は近隣のお客様に来ていただいて、ギリギリの稼働で支えられています。

このコロナ禍で、私たち情報システムグループが対応できたことは、もちろんコストもたくさん削減したのですが、緊急対応でいくつかのプロダクトを素早く作ってリリースしています。振り返ると、非常に短期間で開発することができたなと思います。

ひとつは、 IoT を活用した大浴場の混雑可視化をするアプリです。これはアプリだけでなく、オリジナルのデバイスも設計・開発しているのですが、全国の 15 施設に現場導入するまで 6 週間でできました。

また、 GoTo トラベルキャンペーン対応機能の開発で、当初、国からなかなか仕様が出てこなくて、夏ぐらいにはやるんじゃないかという噂だけはありました。そこで仕様を想像して、見切り発車で開発を進めていたところ、国から仕様が出たかと思うと、さらに 2 週間後に販売開始だ、という話でした。

そこから都合 1 か月で、発表された仕様に合わせて、すべての機能をリリースしています。その時、プロダクトオーナーとして担当したのが、ここにいる眞鍋、米田の二人です。かなり大変だったんだろうなあと思います（笑）。

あとはその他にふるさと納税のシステムやオンラインのサービスなども始めることも出来ました。

コロナ禍で、矢継ぎ早に、しかも速くシステムを作ってリリースできたというのが、私たちの自信につながりました。それを実現できたのは、私たちに「内製する力」があったからかなと思っています。

私たちの内製体制には大きく 4 つのジャンルと役割を持ったチームがあるんですね。

1 つめがプロダクトオーナー。 2 つめは実際にコーディングをする IT エンジニアです。このプロダクトオーナーと IT エンジニアが組んで、オリジナルのシステムを開発しています。 3 つめがノーコードツールによるアプリ開発で、かなり積極的に行っています。最後がインフラの内製化や IoT のエッジ端末などを作るチームです。

これらのチームがどうやって内製化してきたのかというところは、私の星野リゾート人生の歴史と一緒なんですが ……（笑）。

私は 2003 年に入社しているのですが、当時はまだ田舎の小さな会社だったので、機械化するだけで評価してもらえました。この頃は、担当は私ひとりで、いわゆる「ひとり情シス」で、システムを作っていたのは基本、パートナーさんでした。パートナーメインの時代ですね。

ただ、星野リゾートは、自社独自のシステムを作ることに結構こだわっていまして、もともと星野リゾートは独自の運営を競争力としていたので、市場に既にあるシステムはなかなか使えなかったんですね。

例えば、自社宿泊サイトの予約システムですとか、顧客満足度調査を可視化する仕組みですとか、リピーターのお客様からの評価システムだとか。

また、お客様向けシステムだけでなく、内部スタッフ向けについても、労働タスクもしっかり記録してモニタリングするシステムを作りたかったので、勤怠システムもゼロから自分たちで作っています。

自社独自のシステムなので要件をまとめるのは社内人材なのですが、詳細設計、実装、デプロイ、運用はパートナーメインでやっていました。

このため、実際のプログラムや設計を把握していなかったので、私の設計の想像と実装がずれることが多々あって、工数のギャップがありました。例えば、私が 1 ヵ月でできると思ったのが、パートナーさんから見積もりでは 3 カ月かかると言われたり。

最初の潮目は、長年一緒にシステムを作ってきたベンダーの保守契約打ち切り宣言というのがありました。 2010 年ぐらいのことです。

実は一度そのタイミングで内製化にチャレンジしようとしまして、私は内製化 1.0 と呼んでいますが、パートナーの開発チームをまるごと社員にしようと経営陣に提案したんです。当然、経営陣からは反対されまして、「餅は餅屋なんじゃない？」と。その時、さらに言われたことは「時代はインドなんじゃない？」と（笑）。

当時、インドとかベトナムとか、オフショアで開発するのが流行っていたので、コストも安いし、 IT 大国に出したほうがいいんじゃないかと。それでインドに行く羽目になってしまいました（笑）。

いいから 1 回インドに行ってこいと言われて、まあ、それで 1 回インドにいやいや行ったんですけど、思いのほか楽しくてですね。この時に、星野リゾートの情報システム部門をインドに作ったらいいんじゃないかと、と思ったんですね。これは、自分の中では内製化 2.0 のつもりでいました。

そこで作業の指示だけでなく、星野リゾートの情報システム部員と同じように、インドの IT エンジニアたちにも自分で考えてプロダクトを作ってもらいたいなと考えて取り組んでいました。

ただオフショア開発というのはなかなか難しくて、 3 年頑張ったんですけど、うまく成果が出ず、撤収するという残念な結果になってしまいました。

インドで停滞している間に会社はどんどん成長していってしまったので、「情報システム部門は、成長の足かせじゃない？」なんて、若干、陰口をたたかれるようになってまして（笑）。この失敗を掘り下げたところ、やはり社内にシステムをドライブする知見や、知識やスキルがないことが原因だなと大きく反省したんですね。

これがキッカケで 2014 年に「久本学ぶ期」があり、最新の企業システムの知識や UML やモデリング技術とか要求開発を学ぶようになりました。

そのときは再び日本のベンダーをパートナーにして体制を仕切り直したのですが、ただ気持ちは、パートナーであるシステム会社に自分事として考えてシステムを作ってもらいたかったんですね。なので気持ちは「内製化 2.1 」くらいの感じでした。

ちょうど、そのとき SoE とか SoR を学習していて、優れた SoE を手にするためには、 SoR が足かせになってはだめだと、強く思うようになり、そこで基幹システムを作り直していかなければいけない、デザインを根底から変えていかなければいけないと考えました。

そこで「自分事として考えて欲しい」と IT コンサルタントの方などにお題を出したりもしたんですけど、なかなか取り合ってもらえませんでした。実際、 IT コンサルタントの方に、「考えられた戦略を実行することはできるけど、戦略自体を考えるのはあなたの仕事でしょ」と、面と向かって言われたんです。それもそうだなと思いまして。

そこで考えたのが、現場をよく知り、会社の戦略に 100 % コミットできる現場のプロパー社員を、日本で最高のモデラー ^＊ の下で修業させ、高度なモデリング技術とプロジェクトマネジメントスキルを備えたメンバーを育成すれば、うまくいくんじゃないかと考えたんですね。

そこで、現場出身者のプロダクトオーナーチームを少しずつ増やしていきました。これが 2016 年くらいの出来事です。

^＊ モデラーの第一人者 株式会社情報システム総研 児玉 公信 氏

ちょうどその頃、 DevOps やアジャイル開発手法が広く周知されるようになって、プロダクトオーナーチームが担うシステムデザインと、アジャイル開発手法を組み合わせるのが最適解だなと強く思い始めました。

そのときはめちゃくちゃ形から入りました。 「クラウドシフトが DevOps の基本だ」といったら一気にクラウドシフトにしたり、「マイクロサービスがこれから来る」っていったらいきなりやってみたり。

そういったことをやって、先端の概念をどんどん取り入れようとしていました。実はこれは社内にはダマテンでやってまして（笑）。勝手に社内のスキルを上げようとやっていた形です。

ただ、この活動にも限界を感じ始めたのが 2017 年くらいです。

SIer の皆さんも今日参加されているのでちょっと言いにくいのですが、新規開発というのは最も利益が出るし、 IT エンジニアにとっても面白い案件だと思うんですね。ただ、そのあと保守フェーズに移ると、担当する IT エンジニアが 2 番手、 3 番手の人に代わっていったんです。

そうすると、スピードは鈍るし、見積もりは逆に高くなっていくし。で、以前起こっていたことが再び起こってきたんですね。ビジネスの戦略やビジョンを理解していれば、組み込んでいたであろう設計が、実装優先で考慮されていない上に、この改善に想像以上の工数もかかるとわかりました。

これはやはり、モデリング技術と同様に、内部人材じゃないとカバーできないなと思ってきたんです。これが 2018 年くらいで、ここから「内製化 3.0 」のフェーズに入ります。

そこで IT エンジニアを採用しようとしたのですが、また「餅は餅屋」って、代表の星野に言われまして（笑）。「うちは IT エンジニアの会社じゃないから」って、 IT エンジニアの採用には後ろ向きだったんですね。

そこでマインドを変えるには既成事実しかないと思い、既成事実戦略を発動しました（笑）。「 1 人だけでいいです」って言って、最初のひとりを採用しました。

その 1 人がどんどん実績を出していたときに、ちょうど並行していたパートナーメインのプロジェクトがうまくいっていなかったので、その原因を「内部に IT エンジニアがいないから」という理由にして（笑）、経営陣を説得して IT エンジニア採用に積極的に舵を切ることができました。

今は、本質的にデザインする力を備えたプロダクトオーナーチームと内製の IT エンジニアチームを掛け合わせることで、ベストなチームが作れるんじゃないかなと思ってやっています。

私は、新卒で星野リゾートに入り、色々な部署でオペレーションを設計して、開業して、また次の施設へ行って …… と、年間 7 割くらい出張するような仕事をずっと続けていました。そろそろ他のことをやろうと見渡したところ、社内 IT にはもともと興味があり、前の部署で IT の手伝いをしたこともあって情報システム部門に異動しました。

そのときは今のプロダクトオーナーチームという名前ではなく、プロジェクト推進のような名前がついていました。

異動後、プロダクトオーナーのようなポジションで仕事を始めたのですが、当時の自分が大きく誤解していたのが、「それまで私は現場を転々としてきたから、だいたい現場の業務はわかっている。それをシステムに落とし込むのが仕事だ」と思っていたことです。

今の業務を IT 化するのではなく、デジタル化することを前提に、業務そのもの、仕事のあり方、組織から変えないとダメで、そのために情報システムを使う、ということだったんです。結局今ある業務をシステムに落とし込んでも、出来上がった時にはもう古いんですよね。

作る時間がかかるのであれば、未来のことから考えなければいけないと、いろいろ失敗してようやく気付きました。

では、この未来を考えるときに指針となるのは何か、それが「本質」と「思想」です。

まず、業務の本質とは何か、例えば、売掛や在庫のカウントとか棚卸などは、会社や時代が変わって、やり方は変わっても、考え方自体は変わらない。これが本質です。

もう 1 つは思想。

これは組織にとって何が大事か、その考え方や戦略です。組織の競争力そのものなので、理解しないといけませんが、本質と違って、企業の成長ステージにより数年くらいでちょっとずつ変わります。

「変化しない本質と、数年で変化する思想をもとに、未来の業務の体験や、顧客の体験をデザインして実現するチーム」と掲げて、プロダクトオーナーチームという組織が生まれたました。

モデリングは久本が連れてきてくれた日本で一番詳しい方に学びました（笑）。あとは UX デザインも必要なので、私たちが Web デザインをお願いしている会社さんのすごい人にお声がけして、週に 1 回教えを乞う「 UX 道場」で学んでいます。今でも道場に通っていて、毎週フィードバックをいただきながら勉強しています。

いえ、眞鍋から「これからは UX だから、このスキルも上げたい」と提案してくれました。

デザインはそのコンセプトや基礎知識、法則があって決まっているにも関わらず、私たちはそれを知らず、自分たちの好き嫌いでデザインを決めていたかも知れません。

そこで、眞鍋さんの提案をもとに、デザイン会社のアートディレクターの方に「一緒にデザインを考えられるスキルを持ちたい」と相談しにいくと、快諾していただいて始まりました。

いやあ、全然（笑）

複数のプロダクトが同時に進行しているんですけど、今も実際大変なんです（笑）。

一方で、私から見ても、ものすごくうまくいっているなというチームがあるんですよ。それが今日来ている米田のチームです。

なので、ここからは、うまくいっているチームは何でうまくいっているのか？ これを、紐解いていきたいなと思っています。

米田が担当しているのが「たぶいん」プロジェクトです。

先に用語説明すると、「タブレット・チェックイン」を略してタブ・イン。ひらがなでかわいく「たぶいん」というプロジェクトです。

これは「たぶいん」のトップに表示しているものです。自動チェックイン機は、施設の顔ですよね。施設個々でいろいろな世界観を表現しようと、様々なトップ画面を作っています。

「たぶいん」の ver.1 は外注中心で、 ver.2 で少し設計を内製化して、 ver.3 で外部に助けてもらいながら、内部の IT エンジニアも一緒にやり、自前の AWS で動かしています。

2021 年の 4 月 ver.2.5 で 1 年近くで決裁端末をガラッと変えるなど、大きな変更と追加をしていますので、これはこれで頑張っているのですが、 ver.2.5 → ver.3 が信じられない成果でした

ver.3 では、たった 5 ヶ月で 、鍵の仕組みを 2 つ追加して、インフラは全面更新して置き換えて、今まで委託して外部で開発していたのを全部自前で作り直して、それとともにデザインも新しいデザインに変えるっていうのをやっているんですね。

しかもリリース時に全部、開業が並んでいるんですけど、開業ってどうしてもスケジュールの制約が強いのですが、この中でもリリース出来ています。

「何で出来てたのだろう？」と疑問に思い、「たぶいん」チームの皆さん、社内だけじゃなく外部パートナーの方にも事前にヒアリングしてきました。

結果、だいたい同じようなことを言っていたので、簡単にまとめました。

2021 年 4 月のちょっと前に社内の IT エンジニアがジョインしていたのをキッカケに、徐々にインフラ更新などで増えて。今トータルでは、 5 ～ 6 人です。

まず 1 つ目は「立場を超えてなんでも言い合えるチーム」です。

ヒアリングすると、外部のパートナーさんも含めてすごく雰囲気が良くて、いいことも悪いこともミスの情報も、抵抗なくどんどん言えるんですと。何か秘訣があるのでしょうか？

正直に言うと ver.2 までのパートナーさんとだけで開発していた時は、決して風通しがよくなく、うまくやっていたとは言えなかったんです。

ただ今年 2021 年の初めに社内の IT エンジニアが 1 人加わったのがターニングポイントになりました。

それから開発の進め方や、 GitHub などの共有ツール、会議体も整えて、開発スタイルがどんどん変わっていく中で、風通しがよくなっていったと思っています。

私も少しでも迷ったり、機能追加で疑問があると、チームに確認しますし、毎日の朝会の中で、みんなが質問してくれるような雰囲気になってきた感じですね。

もともとはユーザーストーリーだけお伝えして、あとはパートナーさんにお任せ、という開発スタイルでした。

それが 1 週間でイテレーションを区切って、チームで開発タスクを細かく決めてやるようになりました。それと並行して、メンバーみんなでどれぐらい期間がかかるかプランニングポーカーもやって、その 1 週間で出来るポイント数を把握しながら、見積もり精度を上げました。

そうすると、開業までに鍵システムも 2 つ追加できそうなど、見通しがとてもよくなりましたね。

はい。その社内 IT エンジニアが技術などをかみ砕いて説明してくれるし、どのように共有すればプロダクトオーナーチームと IT エンジニアがうまいように開発を進められるか、スタイルを検討しながら決めていってくれたのが大きかったですね。

加えて、ミスの報告も抵抗がないとみんな言ってましたが、何か気を付けているところはありますか？

ミスを憎んで人を憎まず、という文化ができたと思います。「じゃあ、次どうしましょうか」って、再発しないように考えようよというスタンスなので、責める雰囲気もありませんでした。

これは難しいことで、雰囲気づくりが上手かったのでしょうね。

では、 2 つ目の「目標が常に明確でブレないんです」にいきましょう。

これは、すごく短い期間でたくさん開発しているので、目が回るような状況かなと思って聞いてみたんですが、いつも明確だし、ブレないので、混乱は全くないですと。

これは開発に着手する際、私から「この機能のユースケースとして、どういう風にゲストの体験が変わるとか、スタッフの体験が変わるか」というのを、まず最初に説明していました。

それで仕様を全員が納得した上で進められたのが効いたのかも知れません。

そうですね。開発チームとのディスカッションの中で一つひとつ決めていました。

その目標に関連して、「ステークホルダーを代表するプロダクトオーナー」という 3 つ目の言葉も出てきました。

米田さんに仕様とか業務を聞いたときに、とてもわかりやすいんです、と。すぐ答えてくれるし、説明してくれますと。

はじめはステークホルダーが誰なのかもわかっていませんでした。

そこで、最初の土浦の開業のときに、関わっている人を思い切って全員呼んでみたら、たくさんのメンバーが参加してくれました。それで、ここはこうしたほうがいいんじゃないかとか、ゲストの体験をこうしたほうがいいんじゃないかといった意見をたくさんもらえて、「たぶいん」の UX の元になりました。

あとは、自分もフロント業務をわかっているので、ここまで出来ていれば、自分がフロントに立っても回るだろうという最低ラインの感覚もありましたね。

そのラインをもとに、日々の進捗で予定のタスクが完了しないときは、この仕様は落とす、といった判断もスグに出来ていました。

続いて、 4 つ目、「失敗を恐れずチャレンジできるんです」という声ですね。

全面インフラ更新みたいなこともやっている中で、プロジェクトメンバーから「普通の開発チームだったらこのタイミングでこれは怖いからとなるんだけど、このチームだとなんかやれちゃうんですよね」という話がありました。

どんどんチャレンジする姿勢ができる秘訣は何でしょう？

ver.2 ができた時から、テストケースを更新して精度を上げていたので、ここからここまでのテストケースが全部通っていれば、問題なくリリースしていいよねっていう自信ができたことですね。この自信があるので、テストケースが通るのであれば、やってしまえ、という気持ちになります。

テストが開発チームの “心理的安全性” を担保しているのか、なるほど！

では最後に、印象的だったのが外部のパートナーさんがポロっと言っていた「 “たぶいん” をとにかくよくしたいんです」という一言。

すべてに通ずる、シンプルで大事なことだと思うんですけど、こういうチームを作るのに気を付けていることはありますか？

開業が多かったので、プロダクトオーナーだけでなく IT エンジニアや新しく参加したメンバーも含めて現地に行って、ゲストの方が「たぶいん」を触っている場面を見て、細かく観察しているんですね。

新しい鍵システムだったり、決済端末だったり、周辺機器も多いので、現地に行ってみないとわからないことも多々ありまして、そこで何かしらトラブル対応をしています。

それを現地で全員であーでもないこーでもないと頭を悩ませながら解決してきたので、「たぶいん」のプロダクト自体が身近になっているように思います。

あとは最初の土浦から、小さく作って、どんどん機能を更新してきたので、「みんなで育てている」という感覚もありますね。

いくつか目標があるのですが、ここではそのうちの一つ「全スタッフ IT 人材化」をお話します。

これは社内で使っている、ノーコードツール kintone で全スタッフが Web アプリを作れるようになる、というものです。シャドー IT が増えても、誰もが改修できれば OK ですよね、というのが目的です。いま情報システム部門全員が出来るようになったので、情報システム部門が教師になって進めています。

こういったことも含めて、会社全体が一緒に IT をやろうという雰囲気になっています。

そういった雰囲気も、現場出身のメンバーを集めてプロダクトオーナーチームを作って、実現力のある IT エンジニアと一緒になったことで、開発のスピードがブーストしたことが背景にあります。

今日紹介した「たぶいん」はお客様の顧客体験の一つなので、「たぶいん」チームの成功を、他のチームが作っているプロダクトにも拡げ、お客様や社内スタッフのひとつらなりの体験の価値を高めたいと思っています。しかも、より速く、よりよく作っていきたいですね。