かつてないロボット「LOVOT」が世に送り出されるまでの舞台裏 （2/6 ページ）

[後藤祥子，ITmedia]

「世の中にない商品」のための仕組みを作る難しさ

司会　世の中にない商品のための仕組み作りをどうやって進めていったのですか。

梅澤　このプロジェクトの複雑さは、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の開発側で起きた変化は、かけはしプロジェクトが受け止める」ということをひたすらやっていました。