グロービス学び放題

人材育成スキームを変革するグロービス・デジタル・プラットフォーム（GDP）

GDPとはどのようなことを目指したプロジェクトですか？

鳥潟：グロービス・デジタル・プラットフォーム（GDP）は、2016年4月に社内ベンチャーとして立ち上げられた部門であり、サービスです。ここでは、ビジネスパーソンを対象としたマネジメントやリーダーシップ教育において、さらなる新しい領域の開拓を目指しています。

具体的には、「教えるプロセス」や「教え方」、「教育をお届けする方法」をテクノロジーで解決しよう、というものです。法人に向けてリアルな環境で行っている研修をどんどんテクノロジーにシフトしていこう、ということで、一気に浸透していきました。

鳥潟 幸志氏

埼玉大学教育学部卒業 グロービス経営大学院経営研究科経営専攻修了 サイバーエージェントでインターネットマーケティングのコンサルタントとして、金融・旅行・サービス業のネットマーケティングを支援。その後、デジタル・PR会社のビルコム株式会社を共同創業。取締役COOとして、新規事業開発、海外支社マネジメント、営業、人事、オペレーション等、経営全般に10年間携わる。グロービスに参画後は小売・グローバルチームに所属し、コンサルタントとして国内外での研修設計支援を行う。現在は、Globis Digital Platformのプロダクト責任者として従事。

GDPが提供する「定額型グロービス学び放題サービス」は、画期的なサービスだと感じます。

鳥潟：25年以上にわたってマネジメント教育に携わってきたグロービスには、法人の研修事業の中で、eラーニングのコンテンツや小規模な講義動画コンテンツなど、さまざまなデジタルプロダクトがありました。また、研修そのものを効率化するラーニング・マネジメント・システムのようなものも存在していました。しかし、これらはすべて断片的なプロジェクトになっているというのが実情でした。これをアーカイブされた良質なコンテンツとしてしっかりとお届けしていくために考え出されたのが、「グロービス学び放題」というサービスです。

従来の集合型研修では、参加できる人数に制限が出てしまうため、多くのビジネスパーソンに提供することができませんでした。しかし「グロービス学び放題」なら、人数の制限はもちろん、今まで遠隔地にいらっしゃるため受講できなかった方にも、幅広く良質なコンテンツに触れる機会を創出し提供することができるようになります。

「グロービス学び放題」が目指しているサービスの方向観や世界観について教えてください

鳥潟： まず我々としては、さまざまなテクノロジーを使ってビジネスリーダーの育成にどんどん寄与していきたいと考えています。

革新的な仕組みづくりでイノベーションを起こす

グロービスほどの実績をもつ企業の場合、既存のビジネスとの調整を必要とすることもあったのではないでしょうか？

鳥潟：いくつかありますが、代表の堀が明確なメッセージを出してくれているので大きな障壁はありません。

たとえば、「GDPのこのプロダクトは投資フェーズで積極的にやっていくぞ」といった言葉を事あるごとに発信してくれているので、全体的な雰囲気としてやりやすいと感じます。私自身も今でも2週間に1回、堀と定例のミーティングを入れて、その中でしっかりと報告し、アドバイスをもらっています。そうしたこともあり、グロービスが実現させるべき理念や今後の方針と非常にフィットした状態で事業を進められていると感じています。

もうひとつは、手前味噌になるかもしれませんが、グロービスには本当にいい人が集っていると感じており、個人的な感情や、過去にこうだったから嫌だということでのコンフリクトはあまりないと思います。

どういう時間軸で見るか、どういう組織のレンジで見るかによって見方は変わるものです。そのため、配慮は必要ですが、きちんと合理的に説明すれば提案や新しい取り組みも進められる風土があります。

また、「デジタルが普及することでメリットも当然ある。我々がそういうディスラプトなイノベーションをしないと他社がやってくる。もう黙っていても（変化は）やってくるわけだから、そうなってから手を付けたのでは完全に出遅れる。だから自分たちでやっていくんだ」という堀からの強いメッセージは社内でもしっかり浸透しています。

これに沿ったことであれば、当然、進め方や伝え方、相手がどういったことを懸念しているかなどの機微をうまく察知して気を配る必要はありますが、大体なんでもうまく通せると思います。

エンジニア０人体制の中に新メンバーが参画！一転、オフショア開発を行うことに

社内の開発体制について教えてください。

末永：実は、サービス開発に関わるエンジニアはひとりもおらず、プロジェクトが始まったころに入った私がひとり、という状態でした（笑）そのため、オフショア開発を考えた、という側面もあります。実は「グロ放題」の開発会社は別の会社にすでに決まっていたのです。

鳥潟：3社コンペをして1社に絞って、予算も決まって、印鑑を押す直前という段階でした。そこに末永さんが入社されたのです。

末永：開発のプロジェクトにかかる予算やスケジュールを見て、「あまりスピード感を持ってやれるところではなさそうだ」と感じ、同じくらいの予算をかけるのであればオフショアがいいし、以前一緒に仕事をしたことがあるSun*なら安心できると思い、鳥潟さんに相談しました。

末永 昌也氏

東京工業大学大学院情報理工学研究科修了 HRtech系スタートアップのアトラエに新卒で入社後、転職サービスGreenなど複数のプロダクトの開発責任者を経験。Startup Weekend Tokyoで優勝、グローバルバトルにて世界112チーム中8位入賞。その後株式会社LOUPEを立ち上げCTO就任。グロービスのwebエンジニア第1号として入社し、現在はグロービス学び放題のリードエンジニアとして従事。

もう印鑑を押す直前で、しかも入社直後の末永さんの提案……。かなり強引ともとれる変更を行うにあたって、問題はなかったのでしょうか？

鳥潟：そこはもう平謝りですよ（笑）　全体として平謝りではありましたが、理由をきちんと合理的に説明しました。最終的には、直前のお断りするリスクは当然あるけれども、「グロ放題の成功のためにはオフショア開発の方がいいね」と、特に社内からの反対は起こりませんでした。

それというのも、事前に決まっていた会社はかなり特殊なコードを使うということだったためです。もともと自社のエンジニアがいなかったので、問題なかったのですが、末永さんが入社したことや、これから社内で開発チームを作っていこうとしていたこともあり、「やはり末永さんが一番やりやすいチームを作ってもらった方がいい」という判断になりました。関係者に説明に行くと、やはり向こうは「ええーっ」って感じでしたね（笑）でも、最終的にグロービスの判断にご理解をいただいたパートナー候補の経営者には今でも感謝をしています。

オフショア開発に対する心配事は、現地に行って解消

御社としては、初めてのオフショア開発になりますが、オフショアに対してネガティブなイメージはありませんでしたか？

鳥潟：あまりなかったですね。友人の中には、オフショア開発をやっているという話も当然聞いたことがあり、うまくいく例もうまくいかない例もあるというのは知っていました。

エンジニア一人の体制でオフショアをはじめられましたが、他の会社でもそのようなことはできると思いますか？

鳥潟：社内にきちんと開発のことが分かるエンジニアがいて、オフショアがしっかりとできる体制が整っていれば多分うまくいくのではないか、と思います。

ただ、その考えがすべてではなく、残りの半分ぐらいは「ちょっと（良し悪しが）分からないので、もう末永さんが言うのだったら信頼してやってみよう！」という感覚でした。

正直なところ、Sun*がどんな会社で、ベトナムでの開発はどんなものなのか、ホームページを見てもよく分からなかったのです（笑）　ただ、最初の打ち合わせの際にデザイナーの方が来てくださって、話しているうちに「こちらの意図をしっかりとくみ取ってくれそうだな」とは思いました。

その後、1週間ぐらいベトナムのハノイにあるSun*ベトナムのオフィスにも行きました。ベトナムでは、こちらが何を実現したいのか、そもそもまず「グロービス学び放題」でどういう世界観を作りたいのか、ということを私からきちんとご説明させていただきました。

その後、細かいトンマナやこういった場合はどうするのか、といった詳細な部分をその場でアサインされたメンバー全員と一緒に議論して「こんな感じかな」という風に進めていきました。

オフショアのメリットはコストの安さではなく数のパワー

実際にベトナムにも行かれて、チームを組んで一緒にやってみて、どんなふうに思われましたか？

末永：Sun*でオフショア開発を始める際に感じたことは、まず、立ち上がりのスピードが早い、ということです。開発案件をお願いする場合、そのプレイヤーは、正社員、業務委託、オフショアという風に選択肢があると思いますが、立ち上がりが早いのは圧倒的にオフショアでありSun*だと思います。

私は、オフショアで開発を進めるメリットは、コストが安いというよりも、同じコストでスタッフが増やせる、ということの方が大きいと思っています。日本だと5人規模のチームしかできないところを、Sun*なら十何人アサインできる。そうすると、数のパワーでぐわーっと作ることができるようになります。そのスピード感は本当にすごいな、と思います。この点がSun*にお願いする際に一番メリットとして感じているところです。

ただ、グロースフェーズになってきたときにはコミュニケーションのコストがかかってくるケースもあります。細かい調整の段階では、ニュアンスをくみ取りつつ調整していく必要があるわけですが、そのフェーズになると、業務委託や正社員など内部のメンバーで対応できる方が対応は早くなると思います。そういう役割分担ができると、すごくいい気がします。

成功の秘訣はメンバー編成とコミュニケーションの密度

最初は何人チームでしたか？

末永：デザイナーが1人、サーバサイドエンジニアが4人、フロントエンジニアが2人。それに、QA（Quality Assurance）とブリッジSEが1人ずつと、というチームで、スタートとしては比較的人数の多い構成でした。

クライアントによっては最初の立ち上がりに時間がかかったという場合や、うまく回るまで数か月かかった、というケースも聞かれます。スムーズに立ち上がるように工夫をされたことはありますか？

鳥潟：やはりベトナムに1週間、お邪魔したことは大きかったのでしょう。そこで、アサインされたスタッフたちと一緒に過ごしたことで、実際に仕事を進めている際にも「どんなふうに働いてくれているのか」がイメージしやすくなりました。
そのため、「これってどうやって、だれが動いているんだっけ？」といった、余計な確認や心配は不要だったように思います。

通常は3〜4人規模のコアなチームで立ち上げてみて、2〜3か月ぐらいに本来思っていたスケールにするという流れが一般的です。こうしたチーム編成はどのように決められたのでしょうか？

末永：最初に提案があったと思います。

技術顧問：経験上、キックオフの段階で何人をアサインするかは重要なことだと考えています。なぜかというと、途中でスピードが欲しいと思ったタイミングで人を増やしてもこれまでの流れを把握するまでにやはり時間がかかってしまうためです。そのため、キックオフにある程度の人数を確保しておくのは成功パターンだと思っています。ただ、そうした思い切ったやり方はなかなか難しいものだと思います。今回、それができたことがプロジェクトを成功に導くきっかけになったのだろうと思います。

立ち上がりの際に、サービスや仕様を理解してもらうのにコミュニケーションの齟齬はありませんでしたか？

技術顧問：キックオフ以降、クライアントとオフショア開発側の双方でサービスや仕様の理解を進めていく必要があるわけですが、この段階でつまづくケースが多々あるようです。そうなると自然とコミュニケーションが多くなるものですが、理解度に差があるため、言ったことが10のうち3ぐらいしか伝わらない、ということになってしまいます。しかし、ベトナムの国民性なのか、彼らはすぐに「イエス！」と言って開発を進めてしまい、結果としてレベルが低いものがあがってきてしまい、「そうじゃない」という悪循環に陥ってしまうことも残念ながらあり得るようです。

末永：立ち上がりのときはそうしたことはほとんどありませんでした。それは、実際に鳥潟さんがベトナムに行って、サービスを考えた理由などのすごくコアな背景から伝えていたことが大きいのかもしれないですね。その中で、鳥潟さんをすごく気に入ってくれた子が1人いましたね。

鳥潟：ああ、Tuanさんですね。背が高い人で「Brother!」とか「俺んち来て」と言ってくれました（笑）。面白かったです。

コミュニケーションの齟齬が起こらなかった理由はいくつかあるかもしれませんが、その中でも「これが功を奏した」ということはありますか？

末永：基本的なモックまでは全部私の方で作成し、それと画面遷移とデータベース設計のコアな部分を作って「これでお願いします」という流れで始めました。
デザイナーさんから成果物が上がってくるたびに「InVision」というツールで修正のやりとりをして、修正が必要な部分に関しては全部フィードバックに入れながら進めていきました。

逆に、オフショアに関しての失敗談、ここがうまくいかなかった、大変だったというところはありましたか？

末永：細かい意思疎通ですね。そこがやはり難しいな、と思うところはありました。今回のリニューアルについても、最後に細かい調整をお願いすると、やはり少し違うものが上がってくることがありました。10のうち3まではいきませんが、7ぐらいで「ちょっと違うんだけどな」というものが上がってくるイメージです。それならこっちでやった方が速い、という感じにはなっていました。

ただ、11月にプロジェクトが始まって、1月の頭ぐらいまでは本当にスムーズで、ガリガリと進んでいました。そのため、そうしたことは全く問題だとは思っていません。

また、リリース以降も細かい改善をしていく必要がある際に、各案件の優先順位の付け方に齟齬が見られることはありました。「それは優先度が高くないのに」という案件が進んでしまっていたり、国内のプロジェクトチームとベトナムのプロジェクトチームがうまく意思疎通ができていなくて問題が発生したり、ということもありました。

それはどんな方法で改善していったのでしょうか？

末永：細かなコミュニケーションです。「これいつ終わりますか」「優先度、いま何をやっているか挙げてください」など、こちらから状況把握をしっかりやると向こうもやはり分かってくれるものです。そうしたことがいちばん重要だと思います。

そのやりとりはブリッジSEを通して日本語で行っていますか？

末永：はい。ただ本当に急いでいるときは英語で直接現場のエンジニアの人たちとコミュニケーションしていますね。

スピード以外に印象に残っていることはありますか？

末永：プロジェクトが始まって初期のころの話ですが、完全な仕様ではなくラフな画面モックぐらいしか渡していなかった部分がありました。しかし、その中から“よしなに”くみ取って対応してくれたことがあり、大変助かりました。「この辺はこういうことですよね」という風にきちんとデザインに落とし込まれて上がってきたのを見て、このスタッフたちはすごく信頼できるなと思いました。

Sun*側から仕様に関して提案を受けたことはありましたか？

末永：ありました。ベトナムのスタッフから提案され、それを採用した部分も結構あると思います。提案されたことのなかには、開発が間に合わなくて「そこはいったんごめんなさい！」とペンディングにしたものもあります（笑）

今回、グロービス学び放題の開発のあとに、Sun*に技術顧問を拝命いただきましたが、経緯について教えてください。また、実際に依頼してみていかがでしたでしょうか。

末永：グロービスのエンジニア組織はできてまだ1年ですが、今では2022年までに100名規模のエンジニア組織を作っていこうというムーブメントが起きています。そこに至るにはチームや技術の問題などいろいろと発生してくると思います。たった数年で1000名規模のエンジニア組織をベトナムに作られたSun*の本間さんだからこそ、グロービスのエンジニア組織の拡大を支えてくれると感じ技術顧問に就任いただきました。

技術顧問の方に明確に入っていただいたことで、技術選定、コミュニケーションや体制のあ在り方、エンジニアの採用、育成に向けた動きがこれまで以上に加速しています。エンジニア向けの評価制度もこれまでなかったのですが、エンジニアが主体的に動け、技術を強化し、成長できるための評価制度の刷新も一緒に進めています。

ベトナムでのオフショア開発についての評価は？

国籍などの違いを度外視してエンジニアとしての実力で見たとき、Sun*のスタッフたちにはどんな印象をいだきましたか？

末永：まだ若いのかな、という気がします。技術力は、国内のフリーランスで活躍されている人の方がやはり高いな、と思います。

しかし、成長意欲が高いのはすごく感じます。レビューなどでたくさんの指摘をするのですが、その内容を学習しようとする姿勢が伝わってきますね。

では、国としてのベトナムに対する印象はいかがでしょうか？

鳥潟：やはり経済成長している勢いを感じました。特に、Sun*にいらっしゃる方々はもちろん、ハノイにはかなり学歴が高い方々が集っていらっしゃるのだと思います。とても若いのにすごくしっかりしていて、優秀だし、物事を前向きに捉えているように感じられました。

きっと、高度経済成長時代の日本の若者もこうだったのだろうなと思いつつ、逆に言うとこれからの日本は経済が右肩上がりにならない中でどうやってそういう状態を取り戻すのか？　というようなことをすごく考えました。とてもいい刺激になりましたね。

今後オフショアを検討しているクライアントさんとかがいたらどのようなアドバイスをしたいと思いますか？

末永：私は紹介したいな、と思いますし、何回か紹介したことある気がします。実際にやったことがない人だと「本当に大丈夫なの？」という心配はあると思います。また、やはり社内に案件をマネージできる方がいたほうがいいとは思います。

GDPの今後の展望とオフショアチームとの関係性について

では、ビジネスサイドの方から見てGDPの開発チームをどういう体制にしていきたいと考えていらっしゃいますか？

鳥潟：グロービスのように創業以来ずっと教育に携わってきた組織の中にエンジニアチームが誕生する、というケースはおそらく稀なことだと思います。また、トップもアントレプレナー（リスクをとってチャレンジするひと）であり、いわゆる学校の中の組織とは全然違った環境だと言えるでしょう。そうした、かなりオンリーワンな環境の中にできたエンジニアチームがGDP開発チームだと考えています。

そのため、「人が成長したいと思うその瞬間に寄り添うプロダクトとは何なのだろう？」ということを徹底的に考え続けて、ユーザーがなぜこのプロダクトを使うのか、このプロダクトを使うに至ったプロセスはどのようなものか？　といったバックグラウンドをしっかりと理解して考えた上でプロダクトに落とし込むようことができるチームになってほしいと考えています。

マーケットリサーチを、とまでは言いませんが、そういう視点もしっかりと押さえてビジネス側とお互いに意思疎通しながらプロダクトを作っていくチームにしていきたいな、と思っています。

それを実現する上で、Sun*のようなオフショアのチームやグローバル開発チームをどんな風に活用されたいと考えていらっしゃいますか？

末永：たとえば「グロービス学び放題」のチームは一区切りついたところで一旦解散をします。そしてもうひとつのプラットフォームのビジネスの方に着手するので、そこの立ち上がりはまたSun*の皆さんにお願いをしてします。

国内できちんと社内の開発体制を作ったうえで、それでは補えないようなところをうまくお願いするという関係性はすごくいいと思っていて、立ち上がって組織ができてきて、ガリガリと進め、あとは国内で本当に意思疎通がやりやすい中でビジネスとして成長させていく、という流れを今は考えています。

開発を振り返って

受発注の関係を越えた信頼関係

Ho Viet Tuan-エンジニア

グロービス学び放題はシステム保守のプロジェクトと違い、サービスを1から作り直すプロジェクトで、事前に定義された仕様はなく、開発をしながら仕様を詰めていくアジャイル型でした。理想的なサービスにするために、クライアントと一緒に機能を考えたり、こちらからも提案をしました。

サービスリリースの日には朝4時まで対応いたしました。どうしても参加できないメンバーの代わりにプロジェクトマネージャーや他のプロジェクトのグループリーダーもサポートしてくれました。23時に晩御飯を食べ、「絶対に成し遂げてやろう」とみんなで決心をしてなんとかリリースに間に合うよう一晩中取り組みました。

メンバーの努力も報われ、サービスがリリースされてから2ヶ月で、旧サービスのユーザー数を10倍に増やすことができ、クライアントから「グロービス学び放題は大成功だ」とお言葉をいただきました。またNHKや新聞などで取り上げてもらったと聞いたときには本当に嬉しかったです。

プロジェクトが終わったあと、グロービスさんが成功をお祝いするためにハノイオフィスに訪問いただきみんなで食事会を行いました。グロービスさん側でプロジェクトに関わった方々はトップマネージャーたちでしたが、近寄りやすく、受発注という関係を忘れるような本当に楽しい食事会でした。

現在グロービスさんとは次のプロジェクトを進めています。 Sun*のスローガン “WE MAKE IT AWESOME!” に従って行動し、文化や言語の壁を乗り越えてグロービスさんとの信頼関係をつくることができたかと思います。これからもより良いサービスを作っていける土台を作れたことこそが、このプロジェクトに携わったメンバーの最も大きな成果じゃないかと思っています。

BrSE頼りにせず、自分たちからも積極的にコミュニケーションをした

Nguyen Van Long-エンジニア

グロービス学び放題は私がSun*に入社して初めてのプロジェクトでした。本プロジェクトはパイロット版で、今後のプロジェクト推進を左右するものでした。大きな期待をかけられ、早く能力を証明して信頼を勝ち取りたいという気持ちで臨みました。

プロジェクトが始まると、予期せぬ問題や障害も発生しました。グロービスさんの担当の方は技術力がとても高く、特にRubyにおいてはプロフェッショナルです。優秀な方々と一緒に仕事をさせていただいたので、自分たちもきちんと開発をこなさないといけないという緊張感が強くありました。

クライアントからはコードレビューで多くのためになるコメントや指摘をいただき大変勉強になりました。クライアントとのコミュニケーションはBrSE頼りにせず、自分たちからも積極的にアプローチをしました。認識の違いが起きないように可能な限り情報確認を行うことで、プロジェクトを早められることを学びました。

グロービスさんはテストプロセスがとても厳格で、それを把握するのに時間を要しましたが、優秀な技術者の方と一緒にプロジェクトを進めることができ、多くのことを学べたことを感謝しております。

世界中のサービスや日本人の習慣や心理を調査したうえで提案をした

Le Quang Hieu-デザイナー

今回のプロジェクトが日本で有名な企業のEラーニングプロジェクトであると知り、プレッシャーを感じましたが、大きな仕事ができることに期待を感じました。
アメリカやヨーロッパでのEラーニングを受講したことはありましたが、それらとは異なるところもあり、学べることが多いと感じました。

今回のプロジェクトでは徹底的にアジャイル手法を活用しています。プロジェクトの開始時には仕様の多くは決まっておらず、またこれまで携わってきたプロジェクトとやり方が異なり最初は困惑しました。しかしアジャイル経験豊富なメンバーの助けを借り、短期間で他のメンバーと足並みをそろえることができ、多くの作業プロセスを学びました。

まず私や他のメンバーは世界中のオンライントレーニングサービスを調査しました。サービスのQ&Aでなにが書かれているか、そして日本で働いている友達から日本人の習慣や心理などをヒアリングして、よりよいUXを提供するために日本のマーケットにあったソリューションやサービスの調査をし、クライアントに機能の提案をしました。

このプロジェクトでは継続的に変更が発生します。機能の変更の1つ1つは非常に小さなものですが、開発チームのメンバーが追いつけないほどUIがアップデートされます。この問題を解決するために、私は毎日これらの変更をプロトタイピングツールなどに徹底的に書き留めて、他のメンバーがフォローアップできるように気をつけました。

クライアントにアイディアを提案するとき、入念に準備をしたにもかかわらず納得いただけるかどうか不安がありました。しかし私はサービスをよくするために、常に努力し続け提案するべきだと考えました。末永さんはこちらの提案を歓迎し、よいアイディアについては評価してくれました。グロービスさんは私たちをチームの一員として見てくれたことがとても嬉しかったです。サービスのことを本気で考える機会をいただけて、私も成長を実感することができて非常に感謝しています。