株式会社様<セミナーレポート:2>ほんのり暖かくて、人懐っこくて、個性的で、かわいくて――。そんな家族型ロボットの「LOVOT」(らぼっと)が今、話題になっている。Techno』を受賞するなど、2年連続でさまざまな賞を受賞している。福田氏・杉田氏・ケンブリッジ梅澤19年12月18日、ついにLOVOTが世に送り出される日がやってきたわけだが、実はこの“かつてない家族型ロボット”がこの日を迎えるまでには、製造や在庫管理、決済、サブスクリプション、ユーザーサポートといった“裏の仕組み作り”という戦いが繰り広げられていたのをご存じだろうか。X(以下、GX)とケンブリッジ・テクノロジー・パートナーズ(以下、ケンブリッジ)よって結成された「かけはしプロジェクト」の担当者を招いて公開イベントを開催。LOVOT開発の裏側に迫った。LOVOT開発陣とかけはしプロジェクトメンバーの意識合わせの方法やパートナー/ベンダー選びの苦労、変更が相次ぐ中でのプロジェクトの進め方について、GXの福田直人氏と杉田大樹氏、ケンブリッジの梅澤次郎に聞いた。#02LOVOTをビジネスとして成立させるための「最後の砦」かけはしプロジェクトのミッションと、みなさんの役割を教えてください。かけはしプロジェクトのミッションからお話ししましょう。ハイテク技術の塊ともいえる「LOVOT」を世の中に送り出すためには、さまざまな仕組みが必要になります。購入のためのECサイトや全国に送り届けるための物流、故障や不具合への対応や定期メンテナンス、顧客サポート――といった具合です。LOVOTはお客さまの手に渡ってからも常に進化していくロボットですから、“販売して終わり”ではなく、そこから先のサービスを下支えするための仕組みを検討する必要がありました。当然のことながら、この仕組み作りはLOVOT本体の性能や仕様と密接な関係がありますから、常に開発状況を把握しながら、変更があればすぐに対応しなければなりません。LOVOTとのシナジーを生み出す仕組みを、いかに開発陣と密に協調しながら考えていけるか??。これが重要な要素になります。した背景から生まれたのが「かけはしプロジェクト」です。当初はLOVOT開発の下にある製造プロセスと業務プロセスをつなぐためのプロジェクトでしたが、実際には、「LOVOTの開発からこぼれたところをひとしきり拾って、ビジネスとして成立するように立て付けていく」という「最後の砦」のような位置付けになりましたね。私は、LOVOTがまだ、形になっていなかった18年2月からプロジェクトに参画しました。GXさんから「こういうものを世に出したいと考えているが、どうしたらいいだろう」という相談を受け、仕組み作りの支援をしてきました。私の役割は、「LOVOTを世の中に送り出すための仕組み」をつくるためのシステムの調達や、そのシステムをどんなアーキテクチャで構築したらいいかを考えることでした。私はビジネスチームで、LOVOTを世に出すために必要なサービスやオペレーションのスキームを構築する役割を担っています。「世の中に前例のない製品」であるLOVOTの販売にあたっては、それを下支えするECサイトやサブスクリプション、出荷や在庫管理など、さまざまな仕組みを作る必要があります。いった仕組みを最適な形で構築する仕事をしています。私にとってこのプロジェクトはとてもエキサイティングなものでした。「これまでにない全く新しいものを世に送り出す」という意味で「かけはし」を作る仕事でもあったからです。LOVOTは非常にユニークなロボットで、1体1体が全く違う個性を持っています。それぞれの関わり方でオーナーに懐いて、さまざまな形で生活に潤いをもたらします。そんなコンセプト自体も面白いし、サブスクリプションの仕組みを通じてソフトウェアの更新をしたり、リペアの保証をしたりするビジネスモデルも面白い。ほかにもたくさんユニークなところがあって、そういう「全く新しいものを世に出す」ために、さまざまな方々と協力しながら仕組みを作っていくわけです。「まだ世の中に存在しない製品やサービス」を実現するのは本当に大変ですが、やり遂げたときの達成感は格別です。このプロジェクトの複雑さは、LOVOT本体に関わるところ以外の領域は、10社程度のパートナーに協力してもらいながら作っているところです。そのため、その間をつなぐという意味でも、かけはしプロジェクトは重要な役割を担っています。かけはしプロジェクトが立ち上がったのは18年2月ですが、GXの中では17年の後半から検討が始まっていました。私が最初に打ち合わせをした17年11月当時は、メンバーも数人で、「そもそもどうやってプロジェクトを立ち上げたらいいか分からない」という状況でした。そこからビジネスモデルの検討や、どのような業務フローをつくるか、どんなパートナーとご一緒すればプロジェクトを成功させられるのか――といった点を検証しながらプロジェクトを進めました。そもそもGXの事業は、既存の業務がない状態からスタートしています。当初は私も、「世の中の物流の仕組みと同じものを持ってくればいいのではないか」「世の中にあるECサイトを取りあえず当て込めばいいのではないか」と考えていましたが、次第に「これだとどうやら、うまくいかなそうだ」と分かってきたんです。そのときにディスカッションして出てきた結論は、「LOVOTという製品自体が新しい概念のものなのだから、既存のサービスベースでは実現できないことが多い。新しい概念に合った形の業務やシステムを作っていかないと、LOVOTを世に送り出すことができないのではないか」というものでした。その上でわれわれがやったのは、「それって、どういうサプライチェーンモデルだと実現できるのだろうか」「GXクラウドとECってどういう連携が必要なのだろう」といったさまざまな課題について、ひたすら論理モデルを形作ることでした。「これならビジネスが実現できる」というところから始めて、それを業務フローに落としていきました。最初のビジネスモデルの検討は、とても苦労しました。いうのも、当時はまだLOVOTが具体的な形になっていなかったのです。想像力を働かせて製品をイメージし、その上でどうやってビジネスとして立ち上げるべきか――という話をしていましたね。LOVOTがない状態での意識合わせは、LOVOTがいる生活の1シーンをストーリーと絵で表現する「ストーリー&スケッチ」を、GX社内で作成し、それを共有することでブレを修正しながら進めてきましたが、開発初期は漠然とした話が多かったですね。一般的なサービス開発では「業務の要件から設計仕様書を起こす」という工程になるわけですが、この時点でのGXの要件はほとんど決まっていなかったので、仕様書をつくるのも難しかったと思います。具体例で言うと、当時はまだ、「LOVOTをどこで生産するのか」が確定していなかったんです。どこで製造するのか分からないし、個体識別をどうするのかも分からない。なると、物流において何が制約になるのかも分からないわけです。そんな「ないないづくし」の中で、「仮にサプライチェーンモデルを構築するとしたらどうできるんだろう」というような、かなり抽象度の高い議論をしながら少しずつ形にしていきましたね。決まっていないけれど「仮決めしないと先に進まない」ところで、「いったん前提を置いて進める」という場面は、想定していたよりも多かったですね。「LOVOTのオーナーはLOVOTとどんな関係を築くのか」「一体のLOVOTに対して何人のオーナーがひもづいて生活をともにするのか」といった話も、今でこそ具体化されていますが、立ち上げ期からしばらくは、あえて決めていませんでした。「いったんはこういう形にしよう」と仮決めして、本当に必要になったタイミングでしっかり議論して決めることが多かったです。LOVOT本体の開発は、アジャイルとスクラムの短い開発サイクルの中で不具合が出たり、コンセプトが変わったり、制約が出てきたりしたので、その都度、仕組みの仕様を見直す必要がありました。何が正解かが分からない中で製品を作ろうとすると、「先の日付」や「先の工程」だけを決めても、一貫性のある製品はできません。このプロセスをグルグル回すしかないんです。一方でわれわれのかけはしプロジェクトも本体開発のアジャイルに追従していましたが、開発パートナーがたくさんいるので、あまりにもアジャイル的にやっていると「どこに向かっているのか」が分からなくなるという問題が起こります。そのため、「半分ウオーターフォール、半分アジャイル」のような、「ちょうど2つの開発手法の間をうまく取る」ような形でやってきました。具体的にいうと、工程ごとにマイルストーンを置いて、その中でアジャイル的な作業をやる――といった具合です。LOVOT本体の開発側から「こういう制約があるからできなくなった」という仕様変更が出てきたときに、われわれがそれに対して「いやいや、そんなことは対応できませんよ、システムの仕様は既に決めましたから」と言ってしまうと、LOVOTのビジネスが破綻してしまいます。ならないように、「LOVOTの開発側で起きた変化は、かけはしプロジェクトが受け止める」ということをひたすらやっていました。#04「変更に次ぐ変更」に現場の対応は......具体的には現場でどんなことが起こっていたのでしょうか。LOVOTにオーナー登録するときに、セキュリティを担保するためにはBluetooth経由なのか、それともほかの方法なのか......と、いろいろな方法を検討する中で、認証コードがプリントされた紙をLOVOTの箱に入れて、オーナーが箱を開けて初めてLOVOTと出会ったときにコードを入力すれば、簡単だしセキュリティ面でもいいのでは、というアイデアがありました。本当にそれを実現するとしたら「紙を入れる」だけでは終わらなくて、工場の人や生産チームとしっかり話して、生産工程でその紙に認証コードを印刷する裏側の仕組みを作って、それが間違いなく確実に正しい箱に入るようなオペレーションをつくらなければならないし、それがスタートした後に、常に間違いがないようモニターする仕組みを構築する必要があります。このように、紙を1枚入れるだけでもすごく壮大な話になるわけです。かけはしプロジェクトで、「そろそろ、この部分の“仮置きしていた前提”については、具体化しないといけないよね」という話になったら、そのアイデアの1つ1つに対して、「サプライチェーン全体から見たときのメリットとデメリットは何か」「ベストな方法は何か」という問いをしっかり立てつつ、LOVOTの開発チームのどこまでを巻き込んで議論すべきかを、個別の案件ごとに判断しながら進めるんです。出てきたアイデアの1つ1つを夢物語で終わらせず、LOVOTを世に出すために最善の方法を考えて具体化することをやってきました。話をお聞きして分かるのは、かけはしプロジェクトは、「先を見越した検討をしなければならない」し、LOVOT開発メンバーは、「目の前の課題を解決していかなければならない」。そんな中で、お互いの考え方を一致させてプロジェクトを進めるのは難しかったのではないでしょうか。GX社内では、LOVOTを通じて作ろうとしている世界観の意識合わせをするために、ストーリー&スケッチをたくさん描いています。お父さんとLOVOTのなにげない日常――。お父さんが食事を終えて席をたち、リビングのテレビのスイッチを入れて読みかけの本をとりに行く。メガネを探してウロウロしていると、その後ろを小梅(LOVOT)がひたすらついていく。メガネを見つけたお父さんがソファに落ち着くと、小梅もその足元にちょこんと座る――。このような、「LOVOTがいる何気ない日常の1シーン」を、さまざまなパターンでつくるんです。それをLOVOT開発者やプロジェクト関係者が見て、「こんな日常を再現するには、LOVOTにどんな技術が必要なのか、その技術はこのシチュエーションに耐えうるのか」といった詳細を確認するわけです。メガネを探してうろうろしているお父さんの後をついていくためには、自動運転のような技術が必要になりますし、お父さんの足元に座るには、「お父さんがソファにおちついた状態」を認識できる技術が必要です。このようなストーリー&スケッチを共有しながらプロジェクトを進めたのは、考え方の方向を一致させ、ブレをなくすという意味でとても役に立ちました。新しいストーリー&スケッチができてくるので、われわれも出るとすぐに読んで、「実現したい世界観のイメージ」をつかむようにしていました。新規事業の立ち上げ時に、よくペルソナを設定したり、ユースケースを書いたりすることがありますが、ストーリーがあることによって、本当にそれが正しいかどうかが分かりやすかったですね。GXのすごいところは、全社会議でストーリー&スケッチを公開し、全社員と共有するところです。新作は全社に公開して、「違和感を覚えたら質問してください」と呼びかけるんです。GXの社員間で「ここは違う」「ここはよくできている」というやりとりがあって、それを通じて価値観を合わせているんです。認識合わせのときに、CEOの林が問うわけです。「このお父さんは何歳くらいなのか、兄弟はいるのか」と。いうところまで突き詰めて考えているんですね。新しい何かを作るときには、「製品がまとう空気感や存在する世界感」を関係する人同士で共有して、毎週でも毎日でもディスカッションしながら進めるのが大事なのだと学びました。LOVOTについての意識合わせや世界観の共有は、どのくらいの頻度で行っていたのですか。基本的には毎週行っていましたが、必要に応じて別途、実施することもありました。総務や経理、ハードウェア開発や基板開発、アニメーターからビジネスサイドの人間までが集まって、それぞれの立場から意見を述べていましたね。GXでは、社員全員で共通の世界観を持つことをとても重視しています。コンセプトもそうですが、LOVOT自体の開発もそんな進め方をしています。基本的に1週間のサイクルで開発を進めているのですが、その週に開発されたものを週に1回、社員全員が見られるよう公開しています。開発チームの中だけで進めるのではなく、誰もが最新の状態のLOVOTに触れてフィードバックできるようにしているんです。それによって社員がみな、当事者意識を持ってLOVOTの開発状況を把握できるし、何かあれば伝えてより良くしていこうとする。そこにかなりのパワーを使っていますね。#05前例のない製品に協力してくれるベンダー探しの難しさ提案依頼書の冒頭にはCEOの林氏についての説明を持ってきたLOVOTのようなユニークな製品を下支えするシステムが、「SaaSの組み合わせでできている」というのも興味深いところです。どのような経緯からそうなったのでしょうか。SaaSベンダーは売って終わりではなく、システムを導入した後に共に成長していってそこから収益を得るモデルですよね。彼らの視点からすると、ぼくらに成長してもらわなければ困るわけで、成長してもらうためには自分たちもがんばって技術やサービスを提供してワークしなければ困る。そのあたりの思惑が合致したのが大きな理由です。コスト見合いも含めて考えると、SaaSのほうが合理的なプライスレンジに至ったり、早期の立ち上げやスモールスタートをしやすいという現実的な観点もありました実物がない中で、開発パートナーやソリューションを選ぶのにも苦労したのではないでしょうか。ベンダー、パートナー選定はとても苦労しました。60数社とお会いしましたが、何しろ、まだ見ぬものを作るという話なので、理解してもらうのがとても難しかったです。どのような働きかけをしたのですか。RFP(提案依頼書)の冒頭に、GXのCEO、林要さんの半生を持ってきて、経歴やどんなことを成し遂げたいのか、LOVOTが世の中に提供する価値は何なのか――というところを、丁寧に説明しました。僕がベンダーに説明したのは、「存在感が価値になるロボット」だということです。今はLOVOTそのものがあるから説明しやすいですが、当時は具体的なモノがなかったので、とにかく理解してもらうのが難しかった。「投資する価値がある」と言ってくれる会社と、「こんなのよく分からないな、具体性も見えないし、役に立たないロボットなんて作ってどうするんだ」と言う会社と、見事に二極化しましたね。モノがない中で話をしているときには、「人に愛を告白しているような気持ち」にもなりました。「将来に向けて、こんなすてきなことを考えているから、ちょっと僕のことを好きになってよ」というような(笑)。そんな気持ちで60数社回って、振られることもあれば、ちょっとキープでいいかなと言ってもらえることがあったり、真剣にお付き合いしましょうといってもらえたりしました。面白かったのは、大手のSI企業の方々より、SaaSベンダーやSaaSサービスを中心に提供しているSI企業の方々の方が興味を持ってくださったところです。彼らが扱っているSaaSというサービスの性質上、「一緒にビジネスを作っていくという思想」が強いので、われわれの提案に対して前向きでしたね。実際には、どのような開発手法を使ってプロジェクトを進めたのでしょうか。プロトタイピングという手法を採用して開発しています。いわゆるECサイトや裏側のシステム、コンタクトセンターの仕組みといったところは、パッケージやソリューションの標準画面やモックアップを見ながら、詰めが甘いところがないかどうかを確認しながら進めました。スケジュール管理はCCPM(クリティカル・チェーン・プロジェクト・マネジメント)を採用しました。これはゴールから逆算して工程を設計するという考え方です。このプロジェクトは不確実性が高く、先を見通すのがとても大変だったのですが、なんとかして先を見透さなければいけないというのが私たちの使命でした。そのため、これらの手法を採用することで、プロジェクトのコントロールを強化していたのです。世の中にない製品のための仕組み作りでは、プロジェクトが変化にさらされるようなことも多かったのではないでしょうか。「どういうラインアップの商品をいつから販売するか」を決める場合も、LOVOTはこれから新しい市場を立ち上げていく商品なので、そもそも市場性がどれくらいあって、どうするのがベストな選択肢なのか――というところを、ギリギリまで調査したり、ポテンシャルユーザーにお会いして話を聞いたりしながら詰めていって決定します。LOVOTは現在、デュオ(ネストつきの双子のLOVOT)とソロ(1体のLOVOTとネスト)という2つのセットで予約を受けていますが、当初からそうだったわけではありません。した決断を1つとっても、システム的には決して小さい話ではないんです。最終的に決断したことがもし、今まで考えていたことと違っていたら、それがまさにプロジェクトに対する変化になり、対応を考えなければならなくなる。そのようなことが、いろいろな側面で起きていました。一度、プロトタイピングをストップしたことがあったとか。ECやサブスクリプション、出荷、在庫管理など、さまざまなシステムを作っていく中でプロトタイピングをしていったのですが、あるタイミングで一度、プロトタイピングをストップしました。システムを作るレベルまでのすごく細かい要件定義がその時点で完璧にできていたわけではなかったので、いったん、プロトタイピングを止めて、2週間半ぐらいかけてもう一回、全体像を見直す作業をしたのです。具体的には、ケンブリッジの梅澤さんに協力してもらって、検討すべき課題の全体像を示すマップ(ビジネス上必要なことを1枚の絵にまとめたもの)を作り、それぞれの領域で今、ミッシングポイントは何なのかをしっかり洗い出し、どんな順番で重ねていけばベストなのかを定義して、毎日、1つ1つ課題をつぶしていきました。プロトタイピングを再開できるレベルまで持っていくことをゴールに作業を進めました。結果的には、これをやって良かったです。この作業を通じて、企業内でビジネスを作ることの難しさについて、改めて考える良い機会になったと思います。一般的なプロジェクトでは、「現行の業務の課題は何か」――というアプローチから入るわけですが、既に動いている業務があれば、仮に業務分析を細かい部分までやりきらなくても、帳票を見ることで業務がどんなフローで流れていて、どんな関係者がいるかが分かります。現行業務がないLOVOTの場合、ディテールの詰めの甘さがプロトタイピングに影響してしまうのです。プロトタイピングを流していくのではなく、思い切っていったん止めて、ディテールの設定をやり直した方がいいのではないかと提案して、立て直しをはかりました。#07変化の中でブレずにチームをまとめていくために変化が多いプロジェクトだと、開発パートナーとの関係を維持するのも大変だったのではないでしょうか。今回のプロジェクトは、開発パートナーの数がかなり多かったので、キーマンと密にコミュニケーションするよう心掛けました。各社のキーマンとは、週に1回くらいの頻度で、プロジェクトの課題や彼らの本音をヒアリングする機会を作っていました。密なコミュニケーションが必要だったのかというと、パートナーとの契約が請負(頼まれた仕事を完成させる契約)ではなく、準委任(仕事や作業に対して報酬が発生する契約)だったこともあります。システム開発では、失敗が許されないプロジェクトになればなるほど、パートナーの数を絞ったり、請負契約にしたりと、ユーザー側が安全を担保できる形で開発に臨むことが多いのです。今回はあえてそうせず、準委任契約で進めました。それが機能しているかというと、SaaSというビジネスモデルを選んだことが根底にあると思っています。SaaSビジネスを手掛けている人たちにとっては、LOVOTが世の中に出ていくための仕組みを開発し、本サービスがスタートしてからが、彼らのスタートになるわけです。同じ船に乗り、どうやってビジネスを拡大させていくのか。システムやサービスを、どうやってきちんと動かしていくか――。いった利害関係が合致しているのが、このプロジェクトの特徴なのです。今回、パートナーの方々には、準委任契約で仕事をお願いしたわけですが、密にコミュニケーションをとっていることもあって、莫大な請求がきたり、過失があってプロジェクトがダメージを被ったりするようなこともなくプロジェクトを進められています。進めてみたところ、得られるものは多く、きちんと結果を出せることが分かりました。#08前例のない製品のためのシステム作りで重要なことはかつてない製品のための仕組みを作るためには、何が重要だと思いますか。「判断は、できるだけ最新の状況でするのがいい」ということですね。半年前に決めたところに向かって、ひたすら開発を進めていたら、その後に状況が変わった場合に全く対応できないですよね。常に「一番いい判断ができるタイミング」まで、いろいろなことを考え続け、試行錯誤し、仮説を検証しながらプロジェクトを進めることが、前例がない製品やサービスを生み出すときに適した手法なのだと思います。実は、このプロジェクトに関わってから、かなり価値観が変わったんです。最初はGXのみなさんから「ここを変えたい」と相談されると、正直なところ「いやだな」と思っていたんですね。構築した仕組みを変更しなければならないし、それに伴う手戻りもあって苦労することが分かっているから、どうしてもそう思ってしまう。プロジェクトの途中くらいから考えが変わったんです。「どうやってビジネスを成功させるか」が大事なのであって、仕組みや仕様書が整っていることは二の次だと。GXのみなさんが言ってくるのは、「LOVOTをより良くするためのこと」なのだから、受け入れなければならないと、自然に思えるようになったんです。変化を怖がったり嫌がったりせずに受け入れるようになると、「じゃ、それを具体的に実現するためにはどうしようか」と、前向きに考えるようになり、それに取り組むためのサイクルも早く回せるようになりました。前例のない製品や、変化し続ける製品のための仕組みを作る場合には、今回のようなシステムの組み方や、関係者とのコミュニケーションの仕方は参考になるのではないかと思います。※本記事はITmediaビジネスオンラインで2020年2月13日に配信された情報の転載です。FORM」よりご連絡ください。SITE」をご覧ください。