見出し画像

事業成長の足枷から脱却するには変化前提のIT組織戦略しかなかった

星野リゾートで情報システム部門の責任者をしている久本です。数あるnoteの中で、本記事をご覧いただきありがとうございます。

本記事では、急成長した企業を支えるべく私自身どのようにIT組織運営を考え・実践をしてきたかを、これまでの歴史を紐解きながら説明していこうと思います。そしてそれを踏まえて、今後どのように組織を発展させて行きたいか、どのようにエンジニアの方々に活躍いただきたいかもお伝えしていこうと思います。

■ 変化についていけず、「成長の足枷」と言われてしまう

話は2013年末、事業の拡大について行けず、IT部門が「成長の足枷」と呼ばれるまでになってしまった頃に遡ります。

ホテル・旅館の運営を行う事業会社ということもあり、「本業を圧迫せずにいかに低コストで本業を支援するか」に注力し、その柱として当時ブームでもあった「インドでのオフショア開発」にチャレンジしていました。事業会社がSIerを介さずに直接オフショア開発を進める事例は珍しく、登壇も経験させて頂きました。

しかし、上記の取り組みでは、変化の激しい外部環境、および星野リゾートの成長スピードに対応することができず、むしろ「成長の足枷」となってしまい、開発の遅延が常態化し、2013年にはオフショア開発は失敗だったと経営判断せざるを得ない状況に追い込まれました。


■ 足枷脱却に向けて、中期計画を策定するも・・・

翌年、私は足枷からの脱却を目指して様々な勉強会やセミナーに参加してIT戦略の立て方を学ぶ中で、近い将来デジタル社会が到来し、ビジネスだけでなくあらゆる社会活動がデジタル化するという未来が予測されていることを知りました。今でいうDXの概念と同じだと思いますが、すべての企業はそれに備えろという議論が活発に行われていました。

私はIT部門の立て直しのゴールとしてデジタルビジネスの担い手になりたいと思ったものの、当時はまだ足枷状態だったので担える能力は全くない状態でした。

まずは足枷状態を脱却するためにIT戦略の策定に着手しました。当時のIT戦略は中期計画を作るのがセオリーとされていたので、その通りに進めていこうと考えました。

中期計画を立てるためにはまずは事業戦略が重要ですが、星野リゾートはそもそもちゃんとした事業計画がなかったため、他部署の責任者と共に事業計画を考える勉強会を開催。しかし、議論を進める中で、星野リゾートにとっては中期計画はなんの意味もないと参加者全員で悟ることになりました。

■ 中期計画ではなく、「変化」を前提とした組織づくりに注力

当時、星野リゾートは運営会社としてまだまだ実力がなく、良い話は待っていても来てくれませんでした。時にはリスクを取ってでもチャンスを取りに行く必要があり、そのような状況ではいつ何をするか計画しても意味がなかったのです。チャンスとリスクに向き合い、学びながら成長する以外の道はない。そのこと自体を楽しみ、対応できる能力を備えたチームを作り、能力を発揮できる場を用意すればよい。

これが、情報システム部門に限らず、星野リゾート全体の組織作りのテーマになりました。これが2014年頃で、結果としてこの考えで作ってきた組織にコロナ禍では大きく助けられることになりました。

■ 目指す先に到達するための、組織の能力とは

目指す先は、変化前提の企業活動を支える仕組みです。将来的に手に入れるビジネスモデルを探索し、深化し続けるプロダクトとオペレーション、業務の基盤、システムの基盤、そして開発基盤です。これらを整えるために必要な力として、私は

  • 抽象化力、モデリング力、現場感覚などは、作りたいものを間違わない能力

  • 経営判断プロセスや改善プロセスは、作るものを間違わない能力

  • アジャイル開発、スクラム、モデリング技術、UX設計技術、ノーコードローコードの活用等は作り方を大きく間違えない能力

  • それらの実現可能なチームの能力が、変化前提のシステム基盤でブーストし、企業活動を支える仕組みになる

が必要な組織の能力だと考えました。

■ 虎視眈々と力を蓄え、経営陣の信頼を勝ち得る

2015年、このような経緯でIT戦略を策定しましたが、前述の通り経営陣から当時全く信頼されていなかったため、デジタルビジネスの担い手になるためのオフィシャルな投資計画として彼らを説得することはできませんでした。そこで彼らから依頼されたプロジェクトにこっそり能力を備える活動も混ぜて進めていき、少しずつ力を備えていきました。

一つひとつリリースを積み重ね、アジャイル開発の導入によりそれらを一層加速することで徐々に信頼を回復し、情報システムグループのプレゼンスを獲得していきました。

2019年12月には、代表の星野佳路(以下、「星野」)より「ITがなければ作れないありたい世界を提案、実装して欲しい」と言われ、取り組みを始めてちょうど5年で資格を得ることができました。その後コロナ禍が直撃するという大きなリスクに直面しましたが、ITでやるべきことはすべて行うことができ、資格は証明できたかなと思っています。

その後もコロナ禍等で継続が難しくなった施設の運営依頼が多く舞い込み、計画外の開業も続々と続いていますが、大きなビジネスチャンスをITのせいで取り逃すこともなく対応できています。

■ 「変化前提の IT 戦略」と当時のギャップ

ここからは、変化前提のIT戦略の取り組みと現在地に関して少し詳しくお話します。
能力を手に入れるためのステップに対して、当時(2015年)のギャップは全部で5つありました。

① 経営陣・現場から信頼を得ておらず連携も少ないため、経営判断プロセスをゼロから構築する必要がありました

②信頼が得られない理由の一つは相対的に劣化するシステムへの予算確保がないことで、維持改善予算を継続的に確保し、アジリティの仕組みを導入する必要がありました

③アジリティを高めるにはデリバリ能力を高める必要がありますが、デリバリの仕組みは旧態依然で非常にスピードが鈍く、まずはSoE (System of Engagement )のデリバリ能力を整える必要がありました

④SoEデリバリ能力をきちんと担保するには、エンジニアも含めた十分な社内人材を組織化する必要がありました。実は2015年当初はアウトソースで行けると踏んでいましたが、取組の途中で無理ということを思い知り方針転換しています

⑤そして設計思想が古い基幹システムが足を引っ張っていることがないか、SoEの要求に応えられるSoR (System of Record)か注視することも重要だと考えました。

他にもブランド認知の高まりにつれ重要度が高まってきたセキュリティリスクへの対応、オフショア時に運用を分離してしまった部署の機能再統合など、ギャップ解消に少しずつ努めてきました。

■ 経営判断プロセスの構築

まず最初に取り組んだのは、経営判断プロセス構築です。

きっかけは2017年の炎上案件でした。

マーケティング部門との納期に関する認識のズレが原因で、「この機能追加はどれくらいかかるか」と質問されたので、私は工数を答え、質問した側は納期を回答されたと思ってしまったという、「あるある」ですが、全社的な最重要案件だったこともあり社内で大きな問題になりました。

情報システムが多くの案件を抱えていて優先順位をつけるのが困難だった状況もあり、代表の星野自ら課題解決に乗り出すことになりました。
まず最初に手を付けたのは、運用リソースを確保し、新規案件に取り組むメンバーが運用トラブルに巻き込まれて開発作業がスタックする事態を防ぐことでした。

次に開発と改善プロセスを整備し、システム投資の有無を判断する会議体の整備も進めました。これらの仕組みは星野と私と、もう一人の情報システム部門メンバーの三人で作りました。

投資判断の有無は星野が案件の全てを理解して判断するというもので、たった10万円しかかからない機能追加でも、その業務は「そもそも何を価値としているのか、本当に必要な業務なのか、本当に必要な改修なのか」を理解して判断するため最初は時間がとてもかかりました。星野も実際は各部署の業務を細部まで把握しているわけではないので、まずはそこからということも多かったです。

しかし徐々に見通しがつき、予定通りにリリースできる機能が増えてきたことで、星野以外の経営陣も招いた会議体とし、星野リゾート全体のシステム投資・改善・運用の方針を決め、優先順位を付ける会議として、今も毎月行うシステム投資判断会議として継続しています。

投資判断会議を通じて、経営陣との合意のもと継続的な予算を確保
ディスカッションを通じて、維持改善に関するコストへの理解も獲得する

システム投資判断会議は星野リゾートが大事にしている「フラットな組織文化」そのままに、経営陣や現場を交えて侃々諤々ディスカッションを行った上で、情報システム部門が最終的に決断する場となっています。コロナ禍で様々な案件がスピーディーにリリースできた背景には、ほぼ1日で意思決定していたこの会議体の存在は大きかったと思います。

経営判断の合意プロセスをわかりやすくする工夫として、私たちはポイント制を導入しました。

内製化に舵を切る途端に見通しが悪くなるのが案件ごとの投資金額です。エンジニア組織の内製化に舵を切ろうとした際、内製化するとコストは下がると説明したものの、これまで特段見ていなかった社内人件費が大きな金額になるため、
「あれも必要これも必要と人ばっかり雇っていたら競合に対して競争力があるIT投資ができているかどうか判断できなくなる」

と財務の責任者から指摘が入り、内製化の効果がきちんとわかるまでは開発能力を一定とした上で、当面外注人員・社内人員どちらにもかかった総和の推移で評価しようという話になりました。

開発力を一定の指標として把握するには、人件費や生み出された業務上の価値で図るのは難しいという判断になりました。例えばエンジニアが半日で作業した機能追加が莫大なコストダウンにつながる事もあれば、3ヶ月かけた機能追加が全く効果がないということもあり得るわけです。そこで、マルクス主義で言うところの「労働価値説」のような概念で、投入した労働量によっておおよそものの価値が決まるという概念を取り入れた独自のポイントを使うことにしました。

最初に合流してくれたエンジニアの名前を取ってFポイントと名付けられたそのポイントは、彼が独自のルールで決めており、私も一切ポイント付与にはノータッチです。当初は改善項目から利用し始めたFポイントは、今では全体の開発案件の判断に利用しており、Fポイント予算=チームの人員が年間の予算となり、案件ごとのお金による予算管理は不要になりました。

こうなってくると限りある人的資源をどう配置するかという判断になるので、スケジュールは守らなければいけない期限から、状況を見える化してくれて判断する上での助っ人になり、システム投資判断会議でお金の話は一切しなくなりました。

■ アジリティを見通したデリバリ能力の確保

次はデリバリ能力獲得に向けてです。私達は2つの活動「内製エンジニアチームの確立」「ノーコードツールの活用」に注力しました。

アジリティを担保するデリバリ能力を整える ← エンジニアの内製化が不可欠

まずは内製エンジニアチームについてお話をします。
IT能力獲得の際に最初に取り組んだのがデリバリ能力の向上でしたが、道程は平坦ではありませんでした。パートナーメインでDevOpsの実践ができるよう取り組んだものの、最初は少しずつ対応するしかない状態でした。
また外部のコンサルと共に、プロセスを学び、ツールを学び、計画をしてみましたが全く成果がでませんでした。

開発者が外注、しかも請負契約だと無理という自明の結論に気づくのに1年かかり、アジリティの高いデリバリ能力には十分な社内人材が必要と思い、まずは最初のひとりを採用しました。

ファーストペンギンはとても重要なので、必ず成果を出してくれると信じられる人材を探し、全てを彼に任せて再スタートしました。それまで付き合いがあったパートナーとの契約を見直し、ゼロからパートナーを探し、準委任契約としてスタートしました。

スクラムの導入も行い、「1年間毎週機能リリース」というお願いを見事やり切り、1年後には当初「餅は餅屋」と言ってエンジニア採用に後ろ向きだった星野も意見を180度逆転させ、エンジニア採用を積極的に進めることを決定するまでに至りました。

エンジニア採用戦略も私たちが自ら考え、実行に移しています。情報システム部門内に採用チームを立ち上げ、組織文化と事業内容にコミットするエンジニアを、人事部門に頼らず採用することにこだわっています。

見よう見まねで始めたスクラムも、2021年には長くアジャイル開発の経験があるスクラムマスターの加入をきっかけに、ちゃんとしたスクラムを実践するチームが増えてきました。各チームの特色に合わせて様々な開発スタイルを模索していますが、中には全員エンジニアになって3年以内のメンバーで構成されるチームもあります。

次に、ノーコードツールについての取り組みを説明します。
アジリティを高めるためのノーコードツールの導入は、後述する「全社員IT人材化」の思い付きから始まりました。

星野リゾートは就業規則の前文に、

イノベーションを通じて企業の持続性を確保しようとしており、イノベーションは顧客に近いスタッフが、日々の地道な作業に熟練した上で、変化を恐れず挑戦する活動から生まれる。そのためにフラットな組織文化を重視している

というメッセージがあります。

私たちIT部門が競合のグローバルチェーンに比べて劣る要素は、予算規模が限られていること、そして大きく出遅れていることでした。この状況を打破するのは、星野リゾートのフラットな組織文化を背景とした、魅力作りもなんでも自分たちでやってしまうサービスチームの力を、IT化でも活用することではないかと考えました。現場スタッフ全員がIT人材になれれば、グローバルチェーンにIT人材数で優位に立てると思ったのです。

そのための仕組として、最初に kintone というサイボウズのノーコードツールを導入しました。アプリケーション基盤の一部として、プロダクトの総量を増やしていくための仕掛けになると考え、スクラッチで作ったプロダクトとの組み合わせでも活用することを視野に入れていました。

2019年に現場出身者のメンバーを担当者としてアサインし本格始動しました。担当メンバーは課題を可視化し、コミュニティに積極的に参加して知見を吸収、他社の活用事例の発表にも積極的に参加。時には直接声を掛けヒアリングさせてもらいながら活用事例を学び、社内ルールを再設計していきました。行きついたコンセプトは「ガードレールくらいがちょうどいい」。星野リゾートが大事にしている、イノベーションを促進させるためのフラットな組織文化と同じ価値観で運用するのが良いという考えでした。

結果、今では、社内勉強会の開催、伴走型のアプリ開発サービスを社内に対して開始、他社と共同でツール運用のガバナンス設計を進めるなど、多くの活動を進めることができています。

■ SoEを支える SoR を考える

SoEの要求に対応できるSoRかどうか注視する必要があると思ったきっかけは、現在世界の多くのホテルが利用している基幹システムは1950年代に設計された航空機発券システムの設計をベースにデザインされている、という事実からでした。

ビジネスの要求に応えたくても、古い設計思想(SoR)が足枷になっていた

飛行機の座席を取り置きのできない在庫とした概念はホテルの客室にも展開できるものであり、導入された当初、不動産としてのホテルの収益管理が最重要視されていた背景からパッケージシステムはプロパティマネジメントシステム、不動産管理システムと呼ばれています。しかしホテルのコモディティ化が進んだ今、顧客体験価値の最大化を目指さなければ、結果として収益の最大化も難しくなっています。

チャネルも大きく変容し、実績を正しく把握すること以上に、不確実な未来を少しでも理解できるよう、ゲストのオンライン・オフラインの行動から推察される未来の予測も重視されています。レガシーシステムへの対応方法としてリフォームや石棺方式も提案されていましたが、これらはシステムが提供する価値が変わらないことから一時しのぎに過ぎず、SoE/SoR一体となったビジネスイベントの進化を目指すには、価値が変わらないことが足枷になると私は考えました。

この課題感を長く持っており、システムエンジニア、ITコンサルタントに相談をしてきましたが、誰もピンとくる答えを提示してくれませんでした。

そこで私が考えたのが、日本で一番の専門家の元で現場出身のプロパー社員を育成することでした。たくさん本を出されている、情報システム総研の児玉さんにコンタクトしてみて相談したところ、興味を持っていただきサポートを快諾いただけ、長く現場で業務を経験してきた社員のドメイン知識と、業務を通して価値を作り出したい想いやこだわりを重視したメンバーたちと、プロダクトマネージャー組織を立ち上げていくことができました。

メンバーはシステム開発未経験で情報システム部門に異動してきますが、全員UMLを使いこなしてシステム設計を行い、Figmaというツールを使ってUX設計も自ら行い、開発作業の一部を担っています。

現場出身のプロダクトマネージャーたちは、いわゆるシステムの要件を取りまとめ、ステークホルダーと調整を行い、エンジニアと共に個別プロダクトをデリバリーするだけではなく、星野リゾート全体としてのシステムの在り方、ビジョン、ロードマップをどのようにしていくべきか、ディスカバリーすなわち探索も重視し、チームの活動の在り方も自ら模索し、確立してきました。

時間をかけて人材を育成し、あるべきシステムのディスカバリーを続けてきた結果、私たちは、星野リゾートが、というよりは、ホテル業界全体が長年大事にしてきたシステム構成が、「ありたい世界」を描く上で大きな足枷になっていると感じるようになってきました。

ディスカバリーの成果をシステム投資判断会議で定期的に共有しディスカッションを続けてきた結果、星野も正しく理解し、企業のビジョンとしてオフィシャルに提示してくれるようになりました。

私たちがエンジニア採用向けに公式に運用している note に対し、代表にエンジニア向けのエールを依頼した際に寄稿していただいた文章です。

頼んでもいないにもかかわらず、星野はこのnoteの中で、ホテル運営企業の課題は予約システムと施設運営システム、すなわちプロパティマネジメントシステムの分断により、顧客体験がぶつ切りとなり、情報を活用できていないことが大きな課題と示しており、「旅を楽しくする」という星野リゾートの使命に本気で向き合うには、一連の顧客体験・スタッフ体験のイノベーションに本気で取り組む必要がある、すなわち基幹システムを自ら再構築する以外ないと宣言しています。

(後編に続く)


本記事では、 「変化前提の IT 戦略」に至った経緯とそれを目指す過程についてお話をしました。後半ではより具体的に「全社員IT人材化」についてお話をしていこうと思います(近日公開予定)

応募についてはこちらまで↓↓


この記事が気に入ったらサポートをしてみませんか?