close
プログラミング クラウド Microsoft Azure 情報処理資格 基本情報技術者 IT基礎 応用情報技術者 開発・設計方法 オブジェクト指向 内定者・新人研修 プログラミング基礎 アルゴリズム コンピュータ数学 内定者研修 新人研修 ヒューマンスキル プロジェクトマネジメント プレゼンテーション リーダーシップ 組織マネジメント ネゴシエーション ロジカルシンキング Java UI/UX HTTP JavaScript基礎 情報処理資格 ネットワークスペシャリスト ネットワーク インターネットルーティング応用 IPアドレス データベース応用 SQL応用 パフォーマンスチューニング データベース設計 ER図 概念設計(データベース) 論理設計(データベース) IT資格 Linux基礎 OS・システム基盤 セキュリティ TCP/IP OSI参照モデル データベースセキュリティ ファイアウォール 標的型攻撃 SQLインジェクション ネットワーク基本設計 CCNA Cisco プロジェクトマネジメント資格 情報処理資格プロジェクトマネージャ 情報処理安全確保支援士 人事給与 財務会計 管理会計 簿記 生産管理 在庫管理 ERP バランススコアカード 情報処理資格 ITアーキテクト 情報処理資格 ITストラテジスト 情報処理資格 ITサービスマネジメント 情報処理資格 システム監査 PMBOK® PMP® プロジェクト計画 WBS リスクコントロール ITIL ITサービスマネジメント 要求定義 要件定義 見積手法 ビジネスインダストリ 業種・業界知識 業務知識 提案力 ソフトウェアテスト基礎 情報処理資格 データベーススペシャリスト ハードウェア基礎 外部設計(基本設計) 内部設計(詳細設計) データベース基礎 SQL基礎 RDBMS 物理設計(データベース) C++ Ruby MVC基礎 Webアプリケーション開発 JavaEE Javaプログラミング応用 フレームワーク MVC応用 Spring フレームワーク ソフトウェアテスト応用 テスト手法 JUnit スマートフォンアプリ開発 Androidアプリ開発 C# 基礎 C# 応用 負荷テスト Javaプログラミング基礎 ソフトウェアテスト コーチング メンタリング HTML/CSS サーバー構築 仮想化技術 KVS (NoSQL) アジャイル スクラム ファシリテーション C言語 ITパスポート JSTQB データサイエンス 単体テスト ユニットテスト キャリアアップ インターネットルーティング基礎 パケット解析 LAN構築 データベース データサイエンティスト トレンド 障害対応 インフラ監視 HTTP/2.0 コンピュータサイエンス VPN ネットワーク物理設計 データベース障害 JavaScript モダンJS (Modern JavaScript) 応用 MVS応用 バックアップ/リカバリ 分散処理 Hadoop Hive Python AI 深層学習(DeepLearning) CentOS Linux応用 Zabbix シェルスクリプト Infrastructure as Code Windowsサーバー基礎 内部設計 Docker DevOps Windowsサーバー応用 NginX chef Ainsible ロジカルライティング R テスト自動化 Jenkins Git 継続的インテグレーション (CI) バージョン管理 Vagrant 要求分析 Redmine 継続的インテグレーション(CI) 継続的デリバリー (CD) ヒューマンリソース管理 Web API マイクロサービス コミュニケーション 業務知識/業界知識 マーケティング 語学 AWS 法務 IoT ビジネスマナー OJT 業務効率化 表計算ソフト オフィスソフト コンプライアンス フロントエンド Subversion PHP 関数型プログラミング Laravel モダンJS (Modern JavaScript) 基礎 Android Studio 機械学習 iOSアプリ開発 ぷプログラミング React 次世代高度IT人材 共創 IPA Raspberry Pi Xamarin スクリプト言語 GoF CUI VBA 資格 ビジネス文書 jQuery 研修参加レポート マネジメント OSPF テーブル設計 アンガーマネジメント クリティカル・シンキング PDU 経営改善 Pマーク 問題解決技法 サイバー攻撃 エンジニア 参加してみた エンゲージメントマネジメント 労働関連法 新人育成 ネットワーク構築 情報セキュリティマネジメント デザインパターン リファクタリング マルチスレッドプログラミング ベンダーコントロール Modern JavaScript 冗長化 VLAN インフラエンジニア チームビルディング テストケース リーダブルコード セキュリティ入門 ネットワーク入門 Node.js npm gulp ビルドツール Python入門 冗長化入門 インフラ実機演習 プロジェクト管理 Active Directory ネットワーク管理 コンテナ 正規化理論 Haskell 品質管理 OpenStack シンギュラリティ DBA中級 プロトコル UX 基本設計 FinTech トラブルシューティング 並列処理 見える化 PMO ロジカルコミュニケーション Deep Learning インデックス設計 超上流工程 BGP Excel C-CENT Selenide プライベートクラウド アセンブラ コンピュータ基礎 工数見積 CCENT 法律知識 失敗から学ぶ プロジェクト失敗事例 PDCA プログラミング入門 非エンジニア向け 4Biz DNS セルフマネジメント 片付け術 サーバーダウン サーバー タイムマネジメント GO言語 プロダクトマネジメント プロダクトマネージャ LVS ロードバランサー 負荷分散 仮想通過 犯罪心理学 情報漏えい SEカレッジ導入事例 IT研修制度を聞いてみた CentOS7 開発環境構築 数字力 財務 IT人材 UI Machine Learning Go言語 (golang) データマイニング 統計学 新人教育 やり直し数学 RDB つながる工場 モチベーション WebSocket WebWorker HTML5 CSS3 Bootstrap 微分・積分 システム設計 決断力 LAMP環境 教育研修担当者向け ルーティング Linux入門 図解術 目標設定 試験対策 インタビュー技法 Vue.js ブロックチェーン DHCP 仕掛け学 BSC 財務諸表 自己分析 RIP スタティックルート バッファオーバーフロー DoS攻撃 システム開発 Wireshark パケットキャプチャ 管理職研修 部下育成 文章力 情報システム部門向け プロジェクトリーダー プロジェクトマネージャ 塗り絵 リスク管理 法改定 会社の仕組み Chainer AI人材 会話術 テスト技法 会社規模199名まで 会社規模49名まで 会社規模99名まで アプリ開発 サーバサイドJava 営業知識 Cloud 栄養学 基本コマンド ウォーターフォールモデル ヘルスケア 論理設計 ニューラルネットワーク ハンズオン UML 顧客ヒアリング マウスで学ぶ Apache EC2 Lightsail M5Stack DevSecOps プロジェクト成果 画像認識 チャットポット コマンド レビュー 基本用語 自動構築 LPIC-1 サーバーサイドJavascript キャリア形成 ワークライフバランス インバスケット テック用語 GitHub Windows エディタ 教養 令和時代 RESTful API 物理設計 会社規模300名以上 データモデリング サーバーサイドJava Webサーバー基礎 Webサーバー応用 Watson IBMWatson Learning Topics OS モバイル コンテスト トレーニング手法 アーキテクチャ 人材モデル インフラ CI/CD Infrastructure as a Code チーム開発 制度づくり Special_Intro AI市場分析 研修ロードマップ 仕事術 デジタルトランスフォーメーション 財務分析手法 情報整理 PowerPoint 新しい研修 オンライン研修 見どころ紹介 統計分析 ディープラーニング G検定 情報処理技術者試験 販売管理 C# テスト計画 Linuxサーバー WEBサーバ構築 http/2 Postfix イーサリアム プロジェクト・メンバ 正規化 パケット実験 作業分解 トラブル調査 ネットワーク設計 Windows server 2016 ネットワーク機器 DX 管理職 最新動向 ポストコロナ時代 IoTデバイス マイコンボード センサ サーバー仮想化 仮想ルータ WAN インターネットVPN 若手エンジニア ITプロジェクト 人事面談 DX人材育成 Java基礎 ZAP 脆弱性診断 NWサービス構築 イノベーション・マネジメント ネットワークセキュリティ ストレッチ Google Cloud Platform 不動産業界 テレワーク(WFH) ドリル GCP ( Google Cloud Platform ) システム業界 PMS テレワーク ビッグデータ NoSQL OWASP CentOS8 ネットワーク技術 データ分析 デザインシンキング 保険業界 会議リーダー システムエンジニア 段取り術 プロジェクト原論 文章書き換え術 ノーコード No Code MongoDB Redis Cassandra 運用管理 Windows10 仮想マシン リモートワーク 働き方 生産性 IPSec Office セキュリティマナー ソフトウェア・レビュー ライフハック 新しい働き方 エクササイズ ビジネスモデルキャンバス 状況認識 ストレス 必須コマンド Web 今日わかる きほん 状況把握 意思決定 心の健康 IT書籍 書籍紹介 営業マン 類推法 クラス プロセス指向 PdM 共用 ウェビナーレポート 地方創生 GraphQL CSS OWASP ZAP セキュリティマネジメント 問題解決 ソフトウェア 新技術 雑談力 テスト見積もり Scala Go Rust Relay Cloud AI Kaggle ITエンジニア フレッシャーズ 経営戦略 事業戦略 マインドフルネス 基本情報技術者試験 ニューノーマル プロジェクト会議 メソドロジ 講師インタビュー システム障害 販売管理システム VMware セキュリティ事例 ケーススタディ インターネット通信 ビジネスマン 品質向上 提案 ロジック図解術 バーチャルマシン 対策事例 アスリート 国の動向 アンチパターン リモートアクセス 脳ヨガ 自律神経 整え方 組み立て方 コミュニケーション術 リーダー 新人 知っておきたいこと 対人能力 洞察力 一文作成 サッカー業界 グループワーク マネジメント手法 IT業界 Octave セキュリティ管理 IT ネットワーク機器の特徴 ネットワーク機器の仕組み 基本のキ プレゼンテーションの組み立て方 伝え力 試験合格後 時短術 作成のコツ 導入事例 メンタルマネジメント メンタルヘルスケア DXプロジェクト プログラミング教育 プログラミング的思考 子供向けプログラミング データ定義言語 DDL モダンWebアプリケーション ドキュメント作成 Docker Compose Docker Hub AR VBAエキスパート試験 Azure メディア掲載 サーバーアーキテクチャ データ操作言語 DML NewSQL ソフトウェアセキュリティ 数学 VR アパレル業界 Kubernetes Power BI Android プロダクトオーナーシップ プロダクトオーナー 内製化 情報システム部門 Z世代 クラウドネイティブ 技術教育 Windows server 2019 XSS CSRF クリックジャッキング ビジネスパーソン VPC IAM AWS Fargete ECS 問題発見力 問題分析力編 Access 流通業界 金融業界 ネットワーク設定 トラブル対応 評価 ソフトウェア品質 クレーム対応 呼吸法 戦国武将 エンジニアリング 組織論 SpreadSheet GAS ゼロトラスト Express 3D Arduino

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


2021-10-25 更新

SE カレッジでは旬のテーマをもとに、 1 時間のウェビナーを毎月 1 回以上、開催しています。

今回のテーマは、 「星野リゾートがこだわった『内製化』-現場出身メンバーが躍進するプロダクトオーナーチーム」です。

DX が求められる中、開発のスピードと柔軟性を求めて IT の内製化が話題に挙がることが増えています。その「内製化」で成功している星野リゾートの情報システムグループから 久本 英司 さん、 眞鍋 悠 さん、 米田 真優 の 3 名をお招きし、外からは想像できない内製化挫折の歴史、それの乗り越え方、内製するポイントを伺いました。

パネリスト紹介
久本 英司
株式会社星野リゾート 情報システムグループ グループディレクター

軽井沢移住をきっかけに星野リゾートに入社。田舎の温泉旅館のひとり情シスとしてのんびりリゾートライフを送る予定だったものの、現在は海外 3 拠点を含む、全国 50 拠点に急拡大。既存のホテル運営の枠にとらわれない戦略を実現するために、独自のシステム構築の必要に迫られ、施設の予約システム、御客システム、現地運営システム、管理系システム、インフラ、セキュリティ、 IoT など、全てを内製化するための体制を現在も模索している。現在は 35 名のメンバーとともに、星野リゾートの IT 化を進めている。

眞鍋 悠
株式会社星野リゾート 情報システムグループ プロダクトオーナー

2009 年新卒で星野リゾートに入社。星野リゾートのユニークな競争力であるフロント、料飲サービス、客室清掃、調理業務をマルチタスクで行う仕組をグループ施設に導入する部署に所属したのち、 IT に関しては未経験ながら情報システム部門に異動。モデリング技術を学び、現在は次世代の基幹システムの設計をリードする。

米田 真優
株式会社星野リゾート 情報システムグループ プロダクトオーナー

2016 年、新卒で星野リゾートに入社。星のや京都でサービチームスタッフとして勤務し、フロント業務から客室清掃、夕食サービスなど、マルチタスクで業務を行う。 2018 年に情報システムグループに異動。現在は、現地で利用するゲスト、スタッフ向けシステムのプロダクトオーナーを担当している。

コロナ禍で圧倒的な成果を出せた理由が「内製化」

―― まず初めに、星野リゾートのコロナ禍にどう向き合ってきたかについて、うかがえますか

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

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

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

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


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

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

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

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

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

「内製化」紆余曲折の軌跡

―― コロナ禍以前より行ってきた「内製化」がコロナ禍において大きな助けとなったわけですね。
引き続き、星野リゾートの内製化がどのように進められてきたか、お聞きかせいただけますか

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

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

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


―― そうなんですか。ぜひ、お聞きしたいです(笑)

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

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

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

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

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

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

内製化 1.0 ~パートナーを社員に


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

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

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

内製化 2.0 ~インドで内製化!?

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

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

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

「久本学ぶ期」から内製化 2.1 へ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

「既成事実化」で経営陣を動かし、内製化 3.0 へ

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

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

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

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

プロダクトオーナーチームの誕生と育成

―― では、そのプロダクトオーナーとして活躍される眞鍋さんに、立ち上がりのことからお話いただけますか

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

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

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

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

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

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

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

もう 1 つは思想。

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

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

―― そういう役割なんですね。眞鍋さんは未経験でチームに入られたとのことですが、どのように技術を学んだのですか?

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

―― 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 人です。

―― 5 ~ 6 人で! これはますます出来た理由を伺いたいですね

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

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

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

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

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

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

―― どのように開発スタイルが変化したのでしょうか?

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

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

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

―― 完全なアジャイルへの移行ですね。それも社内 IT エンジニアの影響ですか?

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

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

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

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

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

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

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

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

―― なるほど、こういうのを作って!という What のオーダーではなく Why を伝えるようにしたと

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

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

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

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

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

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

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

―― 現場での経験があるので、 “must have” と “nice to have” の切り分けができるんですね

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

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

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

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

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

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

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

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

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

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

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

―― とってもいい勉強になります!さらに聞きたいところですが、そろそろ時間が迫ってきました。
最後に、今後の目標について、久本さんからお聞きしたいと思います

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

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

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

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

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

―― 今日は貴重なお話、ありがとうございました!

(一同) ありがとうございました。

まとめ

今回は、星野リゾートさんの内製化のキーになっている、プロダクトオーナーチームがどのように開発を進めているのか伺い、内製化がうまくいく秘訣を探りました。

個人的には、 “プロダクトオーナーになれる人” として、外部ではなく社内から育成した、というのが非常に興味深く、やはりドメイン知識は外部人材では得難く、その深いドメイン知識が遺憾なく「たぶいん」プロジェクトの開発仕様の決めや調整で証明されていましたね。

またプロダクトオーナーに必要なスキルが Biz / UX / Dev の 3 つ全てに通じていることがマストで、例えば Dev の知識がないと、プロダクトが回らないことがわかったことも、とても貴重でした。話に挙がりませんでしたが、恐らく UX についてもスキルが無いと回らないのでしょう。

もちろんプロダクトオーナーの力だけでなく、関連して、アジャイルをうまく IT エンジニア側から注入したのは見逃せないポイントでした。

以上のように、ユーザ企業が DX プロジェクトを進める上で、非常に内容の詰まった内容で、とても学びが多く、楽しいウェビナーでした!

 

SE カレッジ ウェビナーは旬のテーマをもとに継続して開催しています。ぜひご参加下さいませ!

 


SEカレッジについて

label SEカレッジを詳しく知りたいという方はこちらから !!

SEcollege logo
SEカレッジ
IT専門の定額制研修 月額28,000円 ~/ 1社 で IT研修 制度を導入できます。
年間 670 講座をほぼ毎日開催中!!

午前免除 FAQ

タグ一覧