エンジニア組織を作るには“ファーストペンギン”が大事　星野リゾートとパーソルが語る社内DX環境の整え方

リモートワークは始まってからが大変

関野瞬氏（以下、関野）：ここからのパネルディスカッションでは、既存環境のデジタル化について、以下の3人でお話ししていきます。よろしくお願いします。

まず、フルリモートにするにあたって、一番苦労したというか、ここが大変だったみたいなところを、お二人で何かあれば。それは経営者の説得だったのか、環境面の用意だったのか、社員のマインドだったのか、みたいなところを教えていただければなと思います。まず朝比奈さんいかがでしょうか？

朝比奈ゆり子氏（以下、朝比奈）：はい。フルリモートの環境を作るところにおいて、隣のグループITという部門のみんなが、一気にVPN環境を広げたりなどがんばってくれたおかげで、フルリモートに突入するところまでは、比較的問題なくいきました。業務委託のみなさんとか、あとは派遣で来ていただいている方々の許可の取り方とか、そこが最後バタつきましたが、まずリモート環境にはスッと行けたと思います。

始まってからのほうが大変でした。まず私たちは、4月に新しいチームで迎えたので、初めましての人がチームの中にたくさんいたんですよね。要はうちの会社の文化、風土、企業観みたいなものをまったくわからない人が複数いる状況でフルリモートに突入してしまったんです。また、当時フルリモートが始まった時は、回線のキャパシティやネットワークの問題で、最初はカメラオフが推奨だったんです（現在は増強してカメラオンになっている）。

そうすると、よく知った人たちについては声の雰囲気でなんとなく状況判断できるのでリモートでもよかったのですが、チームビルディングのような初めましてをどうやるのか、みたいなのがやっぱり最初は大変だったかと思います。その各チームなりに工夫をして、たぶんいろいろなトライ＆エラーもありました。始めはたぶんすごく気にして、チーム間をつなぐためのティータイムとか、リモート飲み会とかをしていました。

関野：ティータイムなんかあったんですか!?

朝比奈：ティータイムもやりました！

関野：そうなんですね。なるほど。

朝比奈：飲み会に加えて、夜の部だと出にくい家庭の方もいるし、ちょっとハードルが高いようだったら「3時ぐらいに茶飲み話をしましょうか」とか。その辺りの仕掛けを4月、5月、6月ぐらいまでで一生懸命仕掛けていた記憶があります。

あとは、あとから振り返ってチームのメンバーに聞くと、もちろんチームのメンバー自身でちょっと孤独感があったりとかそういったところで不安になっている人はいるんですが、不安度が高いのはマネージャーのほうなんですよね。久本さんもすごい強烈に頷かれていますが、要は顔が見えないから、本当に元気だろうかとか、「大丈夫」と言っているけど本当に大丈夫なのかな、とかですね。

本当に元気か、本当に問題ないか？　というところをマネージャー陣のほうがヤキモキしまして。そんなこともあるので、我々は各スクラムチームでデイリーの朝会とかはあったんですが、それ以外にTeamsの中でコンディション共有などをやったりしていました。

関野：ありましたね、確かに。

朝比奈：そこを少し共有しますと、例えばこんなことをやっていまして、ちょっと画面が小さいですがリアルを貼り付けてみました。要は、実際に仕事の内容の共有じゃなくて、本当に元気かい？　とか、本当にコンディションどうだい？　とか、あとはこれをきっかけに雑談が生まれればいいなみたいなことを意識して、業務開始と業務終了のコメントをしてもらったりはしていました。なのですみません、ダラダラしてしまいましたが、まとめますと、フルリモートに突入すること自体は、さほど負荷なくいけたかなと思っています。

もともとチームの拠点が分散していたので大きな変化はない

関野：ありがとうございます。久本さんはいかがですか？　もともとチームの拠点が軽井沢と東京で分かれていた部分もあって、遠隔でコミュニケーションをすることに、もしかしたらもともと慣れていた部分もあったかもしれませんが、今度はコロナになって何か変わったこととか、苦労されたところとか。

久本英司氏（以下、久本）：そうですね。やはりちょっとそこは前提から共有したほうがいいかなと思っています。

関野：お願いします。

久本：2つお話できるかなと思っていまして。まずは情報システムユニット全体の話と、エンジニアの開発チームがどうだったかなという話があると思っているんですね。

まずは30人のユニット全体からいうと、今言っていただいたように、私たちはもともと軽井沢と東京と京都に拠点が分かれていたので、ユニットの仕事を進める上で、コロナ禍前でオフィスに出社していた頃からリモートと言えばリモートなんですね。

なのでもともと、毎日朝メール、夜メールというタイトルを付けたチャットのルームを作っていて、そこで各メンバーが今日何するみたいな一言を共有していました。なので、コロナになってもあまりそこは変わらずで。

軽井沢のメンバーからしたら東京の出社状況とかわからないため、出社したらユニット全体にシェアするということをもともとやっていたんですね。そこはコロナのあともそのまま普通に継続してやっていました。当然軽井沢のチームと東京のチーム、あとは京都のチームが一緒に進めるプロジェクトもたくさんあったので、そういったプロジェクトを進めるときは、もともとオンラインのコミュニケーションだったんですね。チャットだったりテレビ会議だったりしていたので、直接的にこのコロナですごくガラッと変わって困ったかというと、コミュニケーションにおいてはそんなに実は困っていないです。

もう1つの開発チームのほうも困っていなくて。開発チームが困らなかった理由は、もともとリモート開発がスタートだったからという点があります。そこをちょっとだけ補足しておきます。

関野：そこの内製化のところに質問が来ていまして、そこも含めて教えていただけると。

開発チームがどう大きくなってきたか

久本：はい。まずは開発チームがどう大きくなってきたかというところを共有します。もともと内製化の取り組みのきっかけは、開発能力のアジリティを組織につけたかったからなんですね。

当時2015年に、私が開発のアジリティをつけたいと思った時、当時DevOpsがはやり始めていた頃だったのでDevOpsをやりたかったのですが、当時情報システムユニットの社員は4人しかいなかったので、開発はパートナーメインでDevOpsを目指し始めました。要は開発者というかシステム会社に発注している状況で、DevOpsを実践できないか模索し始めました。

DevOpsはいろいろな文脈があるかと思います。組織的なところもあれば、アプリケーションの作り方、インフラ的な話でもありますよね。以前、オンプレミスでやっていたアプリケーションがクラウドに変わって、インフラ面でもどんどんアジリティの高いアプリケーションを作ろうというのを、2016年代当時はけっこう言われていた話なので、私たちも、まずはアプリケーション環境をDevOpsに対応できるようにインフラを置き換えることを進めていました。

AWSに置き換えた後にサーバーレス環境に移行したり、いろいろなPaaSやSaaSをシステムの部品として組み合わせて使ってみたり、ということをやり始めたのがこの辺りです。環境から少しずつ対応していって、2017年は本格的にDevOpsを開発チームとしてやっていこうとなって、まずは外部のコンサルと検討を始めちゃったんですね。それはあまりいい筋じゃなかったなと思っているんですが。

DevOpsで開発するというのはこういうことだよ、というプロセスを学んだり、ツールはこういうツールを使ったほうがいいよとか。あとは実際にDevOpsプロジェクトみたいなものを計画してみたんですけど、ぜんぜんできなかったんですね。ぜんぜんできない、まったくできないというのが2017年に続いていまして。できない理由は、開発者が外注だと無理という、今だと当たり前じゃんということも、当時は気づかずいろい模索していました。

ようやく外注だと無理なんだということに気づきまして、当然私たちは星野リゾートの中に開発チームを作っていこうと思ったんですけど、当時代表の星野に相談しても、「餅は餅屋だろ！」と。ITの専門は外の専門会社に頼めばいいんじゃないか、という話をされて、なかなか内製化の道筋は見出せませんでした。

“ファーストペンギン”がすごく大事

まずは実績を作るしかないなと思いまして、最初の1人を採用できたのが2018年です。これはよく最近、アジャイル開発のイベントなどで登壇している藤井（崇介）に来てもらったわけです。やっぱりファーストペンギンってすごく大事なんですよね。

その人の成果によって、そのあとエンジニアをたくさん会社に入れようという気運が高まるか高まらないかが決まるので。必ず星野リゾートの文化に合って、星野リゾートの今の課題を解決できる人じゃないとダメだと思いまして、1年ぐらいかけてずっと人を探して、たまたま一緒に仕事をしていた彼が、事情があって前の会社を辞めなきゃいけなかったので、それで星野リゾートに来ていただいたのが2018年です。

ただ採用できたのは1人なんですね。なので、彼を中心にもう一度システム開発体制を全部作り直したのが2018年です。2017年までパートナーメインで全部開発していたそのパートナーを1回全切りしまして、最初の1人である藤井とともに、もう一度開発チームを作り直す。だけど急にはエンジニアをたくさん増やせないので、まずはまたパートナーメインで、開発チームを作り直していったんですね。

前回の失敗と同じことをやってはいけないと思いまして、この時に目標としたのは外部のパートナー主体であっても開発の仕方は自前化組織と同じように作ることでした。なので、最初に選んだパートナーは全員準委任契約でスタートしまして、その中で開発チームを育てていこうとしました。

途中で、私たちもスクラムを導入して開発者が自律的にチームで成長していけるように進めていきました。そこで成果が大きく出始めたのですが、ある時点からの詰めの一歩が出せないんですね。詰めの一歩は何かというと、やはりパートナーの目標と私たち社員の目標が、どうしても最後はズレてきてしまうんですよね。

パートナーはやっぱり契約の範囲内でパフォーマンスを出して、対価を得ることが目標になります。これが請負だったら、納品が目標ですよね。

私たち社員はそのシステムを納品することが目標じゃなくて、納品された後に運用し、維持管理・進化させて、そこでビジネス上の価値を生み出すことが目的になってきます。開発チームが対象とするシステムの範囲が大きくなる中で、外部パートナー依存だと難しくなってきたんですね。それまで藤井が、1人でスクラムチームを率いていたんですけど、藤井が見れる範囲でしかチームを大きくできないので、藤井と同じ立場で開発していく人を増やすしかないと思いました。

藤井が生み出した新しい開発体制をスケールさせていくには、やっぱり社員を増やすしかない、と言って社内を説得しまして、エンジニア内製化に大きくシフトしたのが2019年です。なので、内製化と言ってもそんなに古いという話じゃないんですね。代表からも「エンジニアを積極的に採用していこう」というジャッジが出たのが、2019年の頭ぐらいですかね。そこから少しずつエンジニアを増やしてきまして、当時2018年宿泊予約チームに1人しかいなかったのが、1人ずつ採用していって2019年には6人に増えまして、現在は8人体制になっていますね。

もともとコロナでストップする前は、もっと倍増させる予定で、採用計画を立てていたんですが、コロナでいったん採用を中断していて、今ようやく再開できるようになったので、また予定どおりエンジニアを増やしていくという流れで始めています。

すでにお伝えしたように、藤井は実は京都にいるんですが、今の開発体制は京都の藤井が外部のパートナーと一緒に取り組んだところがスタートだったんですね。最初の外部パートナーはどこにいたかというと、東京に2人、島根に2人、大阪に1人で、そもそも全員リモートだったんですね。現在の開発チームを作ったスタートの段階がリモートだったので、元々リモートで開発する工夫をせざるを得なかったというのが実情です。

そのあと2018年の末には、開発チームがまた少しずつ大きくなって、東京と福岡が足されたり、結局ここでもリモート前提で大きくするしかなくて。組織を大きくしたら、スクラムを入れて効率よく開発するしかなくなったので、そこでオンラインのツールをたくさん入れて、かんばんはGitHubでやったり、スプリントボードはスプレッドシートで作ったり、振り返りは付箋のアプリを使ってオンラインでしていきました。

私たちの場合は、そもそも開発スタイルがリモートからスタートしていて、そこに社員のエンジニアが追加されていった感じなので、リモート開発環境の中にオフィスにいるエンジニアが入った感じだったんですね。だから同じオフィスにいても、結局全部リモートで開発していたところはコロナ前から変わらない状況でして、それがコロナになっても実は何も変わらなかったというのが、開発チームの状況になっています。

当然対面じゃないとできないこと、例えば雑談ができなくなったとか、顔色がわからなくなったとか、そういう課題はたくさん出てきたんですが、開発作業という面においては、リモート体制ができていたので、ここは困らなかったのが実際の私たちになります。ちょっと長くなりましたが、以上です。

スクラム開発でよかったこと・イマイチだったこと

関野：ありがとうございます。朝比奈さん、「スクラム」というキーワードが出てきましたが、朝比奈さんが来られて、またコロナの影響でみんなが会えないという状況も含めて、いろいろマネジメントを変えてきたと思います。その中でスクラムを導入してみて、スクラム自体がすべてにおいて万能ではない部分もあると思うので、よかったなと思うところと、ここはちょっとスクラムが向いていなかったなみたいなところがあれば、教えていただければと思うのですが。

朝比奈：まずよかったことで言うと、私がスクラムのフレームで一番いいなと個人的に思っているのは、アジリティとかではなくて結局自分たちの働き方を見直し、顧客やマーケットから学び続けるということがすばらしいと思っているんですね。それぞれが意思をもって何を作っていくか、どう作っていくか。

それはうちのグループにとって必要なんだっけ？　ということをそのチームのメンバーが全員で検討して、自分たちの仕事の仕方を常に見直ししていく。それで、顧客やそのマーケットから答えを得ていく。そんな繰り返しをしているチームはすばらしいと思っています。今それに近づけていると思います。

これまでは、各チームに聞くと、マネージャーがリクエスト部門からの依頼をまとめて「今月はこれとこれをやってください。お願いします」と、ドーンと渡してベンダーやグループ会社のSIerが、一緒にやってくれていたんです。

ですが、それを各チームで、「これ本当にやる意味あるんだっけ？」とか「どうやるんだっけ？」ということを話をして、そのチームの中の発言がどんどん活性化されていき、在り方を見直されているチームがたくさんある部門になっているので、まずその点が何よりもよかったかなと思います。

わかりやすく効果が出るのが開発チームなんですよね。そのスクラッチで開発をしていくチームが、現実に生産性4倍以上は叩き出せていると思うんです。ベンダーさんが見積もった場合の期間半分、コスト半分ぐらいでリリースしています。アジャイルで作ったので機能は正確な比較ではないですが。

また我々の部門は保守が多いんですよね。パッケージの保守とか、あとはホールディングスという組織上、M＆AやPMIが突然来るんですね。「MAだー！」とか「グループアウトさせる！」とか、そういう常に割り込みが多い中で、やっぱりウォーターフォールで立ち行かないですし、そういった中で保守系が多いパッケージとはいえ、この順番でちゃんと価値を作っていくのがいいんだよねということがやれているので、すごく素敵だなと思っています。

例えばシステムを作る上でも、人事とか会計のチームとかホールディングス内にも色んな協業組織があるんですけど、「こうしたい」はあっても「絶対こうしてほしい」とは言うのが難しかったり、「事業会社の言うとおりに作ってほしい」みたいなリクエストもあって、それはあまり良くないなと思いまして。

我々が、やはり従業員向けのサービスをきちんと作っていくという、要はそこの意思決定を他人任せにしないぞと。我々がちゃんとプロダクトオーナーとしてこのサービスを作り続けるという部門にしたくて、今はそこでスクラムを採用して、なんかどんどんそう動いていっているかなと思っています。

スクラムでハマらなかったことは、今はあまりまだ起きていないんですが、ちょっと1つ。観点が違うんですが、私が読み外したことがありまして、本当はオフィスに場所を広く取ったので、わかりやすくかんばんをバンバン上げて、朝会とかもやってみんなでスタンドアップとかしていると、他の部門から目立つと思ったんですよね。

なので他の部門に対し、こういう仕事の仕方がいいんだよということをわかりやすくプレゼンしたくて、場所を取り、がんばってモニターをたくさん買ってもらったりしたんですけど、リモートになってしまい（笑）。

そういうわかりやすいアピールが、会社の中でしにくくなってしまいまして、そうすると、次の課題は我々自身を磨くのもあるんですが、いかにカウンター部門をしっかりと巻き込んで進めていくかの取っ掛かりができているチームと、まだあまり出来ていないチームがあって、そこが次の課題かなと思っている感じです。

（次回につづく）