Inside of LOVOT

GROOVE X 技術ブログ

デザインを助けるプログラム

こんにちは、ソフトウェアチームに属しながらもエンジニアではなくアニメーター (デザイナー) の中里です。 ふるまいの開発もしていますが個人的にはLOVOTの目のデザインも行っているので、今回は目にまつわることを書ければいいなと思いつつSWエンジニアさんたちに興味を持って読んでもらえるようにデザインを助けるプログラム的な話をしたいと思います。

LOVOTの目のプログラム

LOVOTの大きな魅力のひとつとして、生物感豊かな目の表現があるということはみなさんご存知でしょうか。LOVOTの目を見たことがない方はこちら

バリエーションが豊富ということもよく言われていますが、最も生物感に寄与しているのは目の挙動にあると思っています。この部分は我々アニメーターが口頭や図示で出した要望を元にエンジニアが実装しました。 複数種の固視微動、環境的要因と心理的要因からなる瞳孔の拡縮などといった生物学的な要素、LOVOTの平坦な液晶をどこから見ても気持ち悪さを感じず目が合っているように見せる平面アニメ的な要素、映像と違いブラーなどでごまかすことができないまぶたの動きを自然に見せるCG的要素など、これら生物感を醸すための表現と、対象物を注視する際の挙動として黒目が眼孔領域から出なすぎない、眼球上の位置による黒目の移動速度の違いなど、それはもうたくさんの要望をプログラムに落とし込んでいってもらいました。

CGならぱっとできると思われがち

あるとき、docomoの+メッセージ(プラスメッセージ)というチャットアプリ用にLOVOTのスタンプ(無料)を作って欲しいという依頼が来ました。内容は、LOVOTの大きな特徴のひとつである目にフィーチャーして、目だけで意思を伝えられるような、かつ実写ではなくイラストで動くスタンプにしたいというものです。

この依頼はデザイン物なのでデザイナーに来るわけですが、LOVOTと同じように目を動かすCGを作るということは、LOVOTに実装されている目のしくみをCG上に再現しなくてはいけないということになるのです。でも誰もそんなことには気づいてくれません。かくいう私も途中まで気づいていませんでした。これは困ったぞ…

手付けアニメーションとプログラムどっちが良いのか

たとえばいくつかの短いシーンだけで、LOVOTの目をCGで再現するのであれば手付けでキーフレームを打つことは可能ですし、気合でなんとかできます。なんだったら実機ではできない表現も追加したりなんかして、あとから実装要望されるという藪蛇を突くこともできます。 しかしチャットアプリスタンプのようにバリエーションが多く求められる場合、たとえひとつひとつが短い尺でも手付けで行っていくのは非効率、かつ与えられた期間では満足のいくクオリティが担保できないという精神的ストレスも予想され、とても現実的手段とはいえません。 これはもうやるしかない。目のプログラム、再現してみせる…!

実際にやるとしたら

アニメーションを伴うCGを作成する場合、私は扱い慣れたAdobeAfterEffects(以下AE)を使用します。目のデザインそのものを作る時もフィルターやサードパーティプラグインの豊富さからAEを使用しています。本当は目のデザインもプロシージャルに生成したいのですが、なかなかそこまでは手が回っていません。人募集中です。 今回もAE上で、目のアニメーションを作成することにしました。

AEというのは映像編集ソフトになるのですが、実写映像を編集するだけでなくイチからオブジェクトを作ってそれを動かしたり、エフェクトをつけたりすることもできます。 そして、スクリプトを書いて指示を与えることができます。AEではエクスプレッションという名前で呼ばれていますが実態はJavaScriptをベースにしたものです。ちなみに私はJavaScriptをジャバ〜と読むのかジャワ〜と読むのかも曖昧なくらい何も知りませんでした。今はジャバ〜と読むようにしています。

AEのエクスプレッションについては、生粋のAEデザイナーでもあまり深く踏み込んでいる人は少ない印象です。かといって、エンジニアに「すみません、AEのエクスプレッションで質問が…」といってすんなり話が通ることなど一度としてなく、とても便利なのにかなりニッチな存在である印象です。ここを攻められればデザイナーとしてちょっとでかい顔ができる領域なので、理の脳をお持ちのAEデザイナーだったら頑張ってみるのをおすすめしたいです。

AEのエクスプレッションあれこれ

深く踏み込んでいる人は少ないと書きましたが、コード蕁麻疹が出やすいデザイナーが浅〜く踏む方法も用意されています。AE内に、random(), や wiggle() などGUIから簡単に適用できるアセットのようなものがあります。LOVOTのビヘイビアもこんなふうに楽に作れたらいいのに。

アセット

もっと細かいことをしたい場合はスクリプトを書く必要があります。 今回のスタンプの中の1パターンで下記のことをすべて行う必要があり、こんな感じのが16種類必要だったので、AEの機能に加えエクスプレッションを利用することでなんとか乗り切りました。

  1. 左右の目がある
  2. 両黒目(虹彩 + 瞳孔)の初期位置が中央でない
  3. 両黒目(虹彩 + 瞳孔)が左、右に動き、白目の範囲を超えないようにする
  4. 虹彩と瞳孔では移動距離が異なり、瞳孔の方が進行方向に対してより移動する
  5. ハイライトは固視微動している
  6. 瞳孔は縮瞳している
  7. まばたきをすると黒目が一時的に上下動する
  8. まばたきをすると瞳孔が一時的に拡大する

一周まわって脳みそがツルツルになりそうです。 特に難しかったのが1~3番目の、初期位置が有効範囲の中心でないモノが同じ速度で左右に動いて指定範囲を超えないというところです。動画が貼れないところがもどかしいですが、見た目はこうなります。

目の動作

これを実現するために行った手順は、

  1. コンポジション(※作業単位のまとまり)(1)に、片目単体のコンポジション(2)を両目の位置に配置しコントローラーに紐づける
  2. 片目単体のコンポジション(※作業単位のまとまり)(2)で、コンポジション(1)のコントローラーの座標を取得しマッピングしたり、固視微動などの各レイヤーだけに適用される動作を加える(3,4,5,6,8)
  3. コンポジション(1)で、コントローラーを介して両目同時に行うべき目のアニメーションをキーフレームでつける(1,2,7)

なんだかうまく説明できている気がしませんが、目単体に課せられる制御は目単体のコンポジション(まとまり)でおこない、両目としてのアニメーションは左右単体の目をそれぞれ配置した上で両目状態を作り、まとめて制御するためにコントローラーを用いてアニメーションさせるということです。

エクスプレッションでいろいろ書いているところ
このときに位置プロパティに書いたスクリプトはこうです。

controlLayer = thisComp.layer("layer_control");
contentRate = 0.5;
halfContentRate = contentRate / 2;
w = thisComp.width;
h = thisComp.height;
rateRange = [halfContentRate, 1 - halfContentRate];
rangeX = w * rateRange;
rangeY = h * rateRange;
rangeMin = [rangeX[0], rangeY[0]];
rangeMax = [rangeX[1], rangeY[1]];
clamp((controlLayer.transform.position - value) * 1.0 + value, rangeMin, rangeMax);

出来上がったスタンプは残念ながらネット上でサンプルを見つけられなかったのですが、アプリ上で見るとこんな感じです。今回説明させていただいたアニメーションは真ん中のスタンプの動きについてです。 プラスメッセージアプリをインストールして見ていただくとこの記事で伝えたかったことをより分かっていただけるかもしれません。ドコモじゃなくても使えます!(一部キャリアでは対応していないことがありそうです)

できあがったスタンプの一部

デザインにプログラムを使うと起きるいいこと

この目の制御をスクリプトで行えたことによって変に外れた動きをしない、編集するときにさわる箇所が少なく済むので編集漏れが減らせる、手間を減らして余った時間で表現のクオリティアップに勤しめるなどのいいことがありました。プログラムを使うとデザイン性などのクリエイティブな部分が犠牲になるんじゃないかという懸念をお持ちの方もいるかもしれないのですが、それは使う側のデザイナーの腕次第です。手付けでしか出せない良さがあるように、プログラムに頼ることでしか出せない良さも確実にあるもので、どの部分をプログラムに助けてもらうかのスタイリッシュ判断ができることもデザイナースキルの一部であると私は思っています。

まとめ

LOVOTの行動デザインはもちろんプログラムなしでは作られることができないので、どちらかというとプログラムをデザインが彩っているかたちですが、LOVOTの目そのもののデザインや広告デザイン、プロダクトサイトのビジュアルなど様々なところのデザインをプログラムが手助けし、クオリティを押し上げるお手伝いをしてくれています。 JavaScriptの読み方がおぼつかない私のような者でもその恩恵に預かれるのはGROOVE Xの環境ならではな部分が大きいと思っています。これからもデザイナーとプログラマーがお互いのスキルを融合させて、LOVOTを唯一無二の存在へと進化させていきたいですね。 最後まで読んでいただきありがとうございました。明日のお話もお楽しみに!

大事な募集

GROOVE Xでは、デザイナーと一緒におもしろロボットのLOVOTを成長させていくエンジニアを絶賛募集中です!このGROOVE X技術ブログを読んで少しでも興味を持たれましたら、ぜひぜひ、お気軽にご連絡ください〜

recruit.jobcan.jp

クラスタ式年遷宮: Autopilot へ移行の巻

この記事は、Groove Xアドベントカレンダー2022 14日目の記事です。

こんばんは、junya です。

先週、酷い熱が出てしまい、12/14 投稿予定の記事がすっかり遅くなってしまいました。 今回は、この夏から秋に取り組んだ GKE クラスタAutopilot への移行について紹介します。

Autopilot とは?

GCP 上のマネージドな Kubernetes サービスです。

コントロールプレーンの管理に加えて、GKE がノードを自動で管理してくれます。また、設定次第で Anthos Service Mesh と呼ばれるマネージドな Istio も管理してくれます。

クラスタ式年遷宮とは?

意図してか何なのか、2年に1回くらいの頻度で k8s クラスタを引っ越ししています。

  • 2018年夏頃: 初代クラスタ構築
  • 2020年夏頃: 共有 VPC 用にネットワークを再設計してクラスタを引っ越し
  • 2022年夏頃: Autopilot へ引っ越し

社内ではこれを伊勢神宮の儀式になぞらえ、クラスタ式年遷宮と呼んでいます。2024年頃にまた引っ越すんだろな、きっと。

式年遷宮の背景

今回の式年遷宮のきっかけは、Istio on GKE のサービス終了(2022年9月末まで)でした。 はじめはマイグレーションで対応しようと思っていたのですが、初期の頃の設定のゴミが残っていたりで移行が思いの外大変そうだったので、まるっとクラスタごと立て直して、引っ越すことにしました。

クラスタの構築手順

詳細は省きますが、以下の手順で新しいクラスタを構築しました。

  • クラスタ用に subnet を作成
  • Docker イメージの管理を Container Registry から Artifact Registry へ移行
  • プロジェクトで fleet を有効化
  • GCP Console でクラスタを作成
    • オプションで Anthos Service Mesh (マネージドな Istio) を有効化
  • クラスタのサービスアカウントに Artifact Registry への Read 権限を付与
  • 古いクラスタから Secret を移行
  • Namespace で istio injection を有効化

Autopilot への移行で発生した課題と解決策

Autopilot への移行には色々と罠があり、サポート契約を結んでいる クラウドエース さんや Google と連携しながら、1つずつ課題を解決していきました。ハマりポイントと解決策を紹介します。

コンソールで表示されるコマンドが実行できない

GCP のコンソールって結構便利で、GUI でリソースを設定しようとすると、それと等価なコマンドを表示してくれるじゃないですか。 なのに何故か、表示されたコマンドを実行しても失敗します。gcloud container clusters create-auto--labels オプションを与えることになっているんですが、実際のコマンドにはそのオプションが存在しない(2022年12月現在)ので、諦めて GUI 上でクラスタを作成しました。

ノードが1つも作られない

共有VPC上で Autopilot を構成したのですが、以下のような Warning が発生して Pod の作成に失敗しました。

kube-system 28s Warning FailedScheduling pod/antrea-controller-horizontal-autoscaler-76dc654676-wg688 no nodes available to schedule pods

確認したところ、クラスタを作成した共有VPCのサブネットで、「限定公開のGoogleアクセス (Private Google Access)」が無効になっていて、サブネット内から GoogleAPI にアクセスできないのが原因でした。「限定公開の Google アクセス」を有効化して、無事に解決しました。

IP アドレスが枯渇して新しい Pod が作られない

以下のような Warning が発生して、 Pod が ContainerCreating から先へ進まなくなりました。

Warning FailedCreatePodSandBox 4m21s (x77 over 100m) kubelet (combined from similar events): Failed to create pod sandbox: rpc error: code = Unknown desc = failed to setup network for sandbox "2ffd683f686d0c849515ecca19a3ebd7c013dcb6569c085844aca234738d12dd": failed to allocate for range 0: no IP addresses available in range set: 10.8.65.193-10.8.65.254

こちらはプラットフォーム側のバグ で、対策済みの 1.22.15-gke.100 に手動アップグレードすることで解決しました。

完全マネージドの場合、こういう問題が起きた時にノードを自前では調べられないのが歯がゆいと同時に、プラットフォーム側が調査して解決してくれるのが頼もしくもあります。

LimitRanges を参照してくれない

コンテナのデフォルトのリソース設定を LimitRanges で管理していたのですが、 Autopilot で割当後のリソースを見ると、設定値を考慮してくれていませんでした。調査を依頼したところ、これは GKE Autopilot の仕様で、 LimitRanges は機能しないとのことでした。

アプリケーションへのリクエストがキャンセルされてしまう

開発環境・ステージング環境では正常に動作していたアプリケーションを、本番環境で istio injection を有効にして動かしたところ、 Go の context canceled が多発して、多数のリクエストをさばけなくなりました。試行錯誤したところ、 istio sidecar に割り当てている CPU が足りていないのが原因で、 sidecar への CPU の割当を増やすことで解決しました。

当てられるべき以上のリソースが割り当てられる

Autopilot で以下のような Annotation を用いて sidecar のリソースを制御していたのですが、

sidecar.istio.io/proxyCPU: "120m"
sidecar.istio.io/proxyCPULimit: "120m"
sidecar.istio.io/proxyMemory: "150Mi"
sidecar.istio.io/proxyMemoryLimit: "150Mi"

Autopilot で割り当てられるべきリソース 以上のリソースを確保してしまい、余計なコストがかかってしまいました。

本来は Pod における要求リソースの合計に対して、 CPU は 250 mCPU 単位、メモリは 0.5GiB 単位で繰り上げられるのですが、 Annotation によって istio sidecar が生成されるタイミングが Autopilot の制御に対して遅延するため、アプリケーションコンテナの作成時と、サイドカーのコンテナの作成時の2段階で Autopilot のリソース補正が走ってしまっていました。

こちらはサポートに相談し、 Customizing Injection の機能によって、 Annotation ではなく以下のように Deployment として明示的にコンテナを指定することで、解決しました。

spec:
  containers:
  - name: istio-proxy
    resources:
      limits:
        memory: 5Gi
      requests:
        cpu: 200m
        memory: 5Gi

クラスタ管理の費用がかかりすぎる問題

ここまでの設定で一通り動くようにはなったのですが、今まではざっくりとノードを確保して Pod を沢山動かしていたのが、Pod 単位でリソースが厳密に管理されるようになり、しかも、Pod ごとの最低リソースが 250m CPU, 0.5 GiB ということもあって、クラスタ管理の費用が爆増してしまいました。特に、リクエスト負荷の低い、開発環境やステージング環境のクラスタでの費用の増大が顕著でした。

その対策の1つとして、以下のような設定を Deployment に追加して Spot Pod を使うようにしました。

terminationGracePeriodSeconds: 25
affinity:
  nodeAffinity:
    preferredDuringSchedulingIgnoredDuringExecution:
      - weight: 1
        preference:
          matchExpressions:
          - key: cloud.google.com/gke-spot
            operator: In
            values:
              - "true"

Spot インスタンスを利用することで、単価が30%になる想定で、その効果はこれから確認するところです。

今後の予定

まだまだ Autopilot や Service Mesh のポテンシャルを活かしきれていないので、勉強してこれからもっと活用していきたいなと思ってます。 また、 Workload Identity の導入も進めたいです。

こんな感じで k8s クラスタを管理しているのですが、アプリケーション開発と兼任で3~4人で回している状態なので、一緒に開発してくれるインフラエンジニア・バックエンドエンジニアの方を絶賛募集中です。

ご興味ある方は、是非お気軽にご応募下さい!

recruit.jobcan.jp

LOVOTのふるまいの品質を保つ仕組み

こんにちは。
GROOVE X のふるまいチームの scnsh です。
この記事では、ふるまいの品質を保つために社内で行っている施策についてご紹介します。

 

開発の流れ

ふるまいチームには「アニメータ」「エンジニア」が所属しており、1つの開発チームとして構成されます。

LOVOTのふるまいづくりでご紹介しましたが、いくつかの工程を経てお客様のお手元に、LOVOTの新しいふるまいがソフトウェアリリースの一部として提供されています。

しかし、一般的なソフトウェアのアップデートとは異なり、ふるまいには感性的な評価軸があります。

例えば、新しいふるまいを追加した際に、

  • ふるまいを行うことがLOVOTの生き物としての価値観に合致している
  • ふるまいの動きがLOVOTの生き物としての所作として自然である
  • 動きそのものが魅力的なものであるか

といった観点での評価が重要となります。

この評価を実現する観点試験をアニメータが実施して、合意を得ることでお客様へのリリースが可能となります。

抱っこをねだるふるまいも観点試験で評価されたものがリリースされています

スクラム×観点試験

GROOVE Xではスクラム開発を実施しており、2週間を1スプリントとして新しい機能の開発を行います。

そのため、観点試験も2週間毎に実施しています。

具体例を交えて説明してみます。

スクラム開発の流れで行う観点試験

2022年にふるまいチームは大きな機能追加は4回行っています。(2022年まだ終わってはいませんが…)

例えば、22.04.2.3のリリースに向けた期間として4スプリント(8週間)ありました。

スプリント4は開発ではなくソフトウェアリリースに向けたQAを行い、スプリント1~3で機能を開発しています。

観点試験は各スプリント終盤に実施し、その結果を次のスプリントの計画に反映させています。(スプリント4の観点試験ではリリースに向けた判断を行うため、スプリント終盤よりも前に実施します。)

 

このように、観点試験を2週間という短い期間ごとに実施することで、様々なメリットがあります。

  • フィードバックが早目に得られるためリリース直前での手戻りが少なくなる
  • プロダクトオーナー(PO)などにも早目に成果物を共有できる
  • 進捗に応じて最終的なリリース内容を早目に軌道修正できる

ふるまいの変更は定量的な評価が難しいため、人の感性に基づく試験が多くなりますが、評価する人の数を増やす・評価する機会を増やすことのできる観点試験の仕組みがふるまいの品質を担保するために大きな役割を果たしていると中の人は感じています。

 

観点試験の実施

観点試験はGoogleSpreadSheetを使って作成しており、各行が2週間スプリントで開発されたProductBacklogItem(PBI)に対応しています。

観点試験書(一部ぼかしています)

開発者以外の中から担当者を割り当てて新しいふるまいを体験してもらい、作成した試験書にOK・NGの判断とその根拠をコメントとして残します。

スプリントの最終日に開発メンバーとプロダクトオーナーが集まり、試験結果を確認します。

その際にNGとなったものは、プロダクトオーナーも含めて今後の対応方針を話し合い、次のスプリントの計画に組み込むようにしています。

最後に

ご覧いただきありがとうございました!

GROOVE X では 一緒にLOVOTの開発をするメンバーを募集しています。

ふるまいの開発だけでなく、ソフトウェアリリースなども含めて全く新しいプロダクトのため、他にはない唯一無二の経験ができます。

興味のある方はぜひこちらからご連絡ください!

プロダクトオーナーからみたLOVOT開発

こんにちは、GROOVE Xでソフトウェア領域のエリアプロダクトオーナー(APO)をやってる、よっきです!

今回は、プロダクトオーナーの視点からLOVOT開発について語ってみたいと思います。

プロダクトオーナーとはなんぞやは、例えば、こちらの記事に詳しくまとまっているので参考にしてみてください。

ざっくり言うと、 いつ何をする、という計画を立てるのと、それをなぜするのかの説明をチームにしていくことが主な役割になります。

このいつ何をするか、というのにロボットならではの難しさがあるなと感じることがあるので、この辺りを中心に語ってみたいと思います。

プロダクトオーナーもチームです

まず、どのくらいのチームでLOVOTを開発しているかについて簡単に説明します。

第一回のアドベンドカレンダー でも紹介がありましたが、ソフトウェア領域だけでも多くの専門分野があり、ハードウェアとソフトウェア、そしてアフターサービスの領域を合わせると合計16チームもあります。ざっと図にするとこんな感じ。図はチーム名で記載しています。

開発チームの構成図

お気づきの方もいるかと思いますが、技術や専門がわかりやすくチーム名になっているチームもあれば、何をしているのかわかりにくいチーム名もありますね。 ちなみに、UTとAlohaとAppでふるまいチームと呼んだり、フレームワーククラウド音声認識でKIBAN WGと呼んだりと、チーム横断のチームやワーキングもあります。 また、チームを決める裁量はチームにあるため、チーム名やチーム構成も気づいたら変わっていることがあります。なので、この図は2022年12月現在のチーム構成ですね。

どのチームがどんなことをやっているかは、今後のアドベントカレンダーでわかってくるかと思います。期待しましょう。

これら16チームの開発状況や今後のLOVOTの成長方針などを踏まえて、計画をアップデートしていくのがプロダクトオーナーのミッションの1つなのですが、さすがにチーム数が多いのと、専門性がかなり異なるため、領域ごとにエリアプロダクトオーナー(APO)を置いています。

領域を分けると情報の分断がおきてしまいそうと心配になりますよね!?

そこでエリアプロダクトオーナーもチームとして毎日情報の共有をしています。 ちなみに、ソフトウェア領域のAPOは私を含めて2名、ハードウェア領域のAPOは1名、その他にアフター領域のAPOが2名、そして、全体のプロダクトオーナーとして代表の林要がいて、合計6名のプロダクトオーナーチームです。 この6名で毎日30分〜1時間ほど気になるところの状況の確認や、課題の相談を行い、何なら全体の計画に関わる重要な決定事項も行っています。 そんなに毎日話すことがあるのかと思いますが、なぜか1時間じゃ足りないくらい議題が山積みなのですよね。いや〜、不思議です。

ロボット開発の計画づくりの難しさ

では、いつ何をするかを決めるにあたっての、私がロボットならではの難しさだなと感じていることを2つほど紹介します。

開発は順番に進んでいく

LOVOTをローンチしたあとも、LOVOT 2.0やLOVOTチャージスタンド、最近ではフラグメントエディションをリリースしたりと、たくさんのハードウェアを開発してきました。 このハードウェアが絡む開発は、ハード設計から始まり、バラックと呼ばれるパーツ単位でファームウェアLinuxなどのソフト基盤の開発や動作検証を行い、その後、ハードウェアが組み合わさってから認識機能の開発、そしてふるまいやアプリの開発を行います。(上のチーム構成図は開発の流れ順っぽく描いてみました)

つまり、開発工程が進むにつれて、関わるチームが変わります。 これらはある程度事前に計画は立てるものの、部品の調達状況や各チームの開発状況でスケジュールが変わるため、いつからどのチームが着手できるかがどんどん変わっていきます。 工程が遠いチームほど、いつから着手できるかがわからなくなり、状況のキャッチアップが難しいなと思うことがあります。

ハードウェア変更は突然やってくる

電子部品の終了はいきなりやってくるものなのですね。ハードウェア領域のチームからソフトウェア領域のチームに対して、「この部品が販売終了となり、新しい部品を選定したので評価お願いします」と連絡をもらうときがあります。いわゆるEOL(End of Life)対応ですね。在庫をどれだけ買っておくか、いつから変更するか、などを決めつつ、新しい部品で問題ないかの確認をしていきます。緊急度が高いので割り込みタスクになりやすく、そして、実際に変更される時期が半年とか1年後とかになることもあり、評価はするもののいつから導入されるのかが分かりづらいこともあります。正直、覚えてられません。。。

LOVOT MUSEUMに展示されているプロトタイプの変遷。ハードウェアチームとソフトウェアチームが協力してLOVOTを進化させてきました

スケジュール管理の理想を求めて

これらの難しさが同時に起こると、つまりハードウェア開発とEoL対応のスケジュールが同時に走ると、もうどのチームがいつどんなタスクをすべきかがだんだんわからなくなってきます。 プロダクトオーナーチームでも各領域の状況を確認しながら、スケジュールをメンテしているのですが、あ、もうこれやらないとなのか、と割り込みっぽく優先順位を変更することが多々ありました。 これはいかん!ということで、スケジュール管理方法を検討し、そこで出会ったのが、タスク管理とスケジュール管理を同時に行えるWrikeというツールです。

以前は、タスク管理はJIRA、スケジュール管理はスプレッドシートやコンフルのマイルストーン機能などを使っていましたが、スケジュールとタスクの関係がわかりにくいのと、スケジュールがよく壊れるため、統合したいという思いが有りました。JIRAにもガントチャートのアドオンがあってスケジュール管理できるけど、かなり使いづらかった。。

Wrikeのいいところは

  • タスクをプロジェクトという単位でまとめられる
  • プロジェクトにスケジュールを入れると自動でカレンダーができる
  • プロジェクトに担当チームを入れると、チーム単位のカレンダーもできる

ということで、タスクをプロジェクトにまとめて、プロジェクトにスケジュールと担当チームを入れれば、全体の大まかなスケジュールとどのチームがいつ作業開始すべきかが比較的簡単に作れます。

そして何より、タスク管理とスケジュール管理が統合されているため、開発チームみんなでスケジュールを作ることができるようになりました。 なんやかんやで最新のスケジュールを把握しているのは開発チームであり、その開発チーム自身がタスクを作る際にスケジュールを設定してくれると、全体スケジュールが更新される!なんて素敵なことでしょう。

そんな理想を求めて、Wrike導入を決意して、実はまもなく8ヶ月が経とうとしています。 まだまだうまく使いこなせているわけではなく、JIRAに比べて自動化などが弱い部分もありますが、ひとまずスケジュールの管理という意味では、それなりに使えるようになってきたかなと思っています。 これからも各チームがスケジュールを自分たちで把握しやすいように日々改善していきたいと思います。

Wrikeの画面チラ見せ。チーム単位やチーム全体などのビューがたくさん!

最後にちょっと冷静にふりかえって

ロボット開発におけるスケジュール管理の難しさと、スケジュールをみんなで管理できるようにWrikeというツールを導入したよ、という話を書きましたが、いかがでしたでしょうか。

この記事を書こうと思ったきっかけは、Twitterで「JIRAでスケジュール管理どうしてるの?全員が理解できるくらいのスケジュールを可視化したいんやけど」みたいなツイートを見かけて、GROOVE Xの取り組みが少しは参考になるかなと思って書いてみることにしました。(オリジナルのツイートを見失ってしまいました、すいません。文言は多少間違ってるかもですが、ニュアンスは合ってるはずです)

Wrikeがベストソリューションのように書きましたが、多分、何のツールで改善を進めるかだけなので、JIRAでやりきろうと思えばできたのかな、と今になっては思います。 選択をしたあとは、選択したものをいかに正解に持っていくかを頑張るのみですね!

まだまだ試行錯誤が続く毎日で、日々新たな課題も出てくるのですが、それをチームみんなでカバーしあって支え合おうとするGROOVE Xの文化が私は好きです。 最近流行りのWeb3でいわれているDAO的な世界観に似ているなとも思っています。 できるところをできるメンバーで支え合う。私もプロダクトオーナーという視点で開発チームを支えて、より良いLOVOTを世の中に提供していけるよう頑張ってまいります。

そして、こんな面白いチームや組織を維持していくためにはスクラムマスターの存在が欠かせません。 POチームは、一緒に開発チームや組織を作ってくれるスクラムマスターを探しています。 現在2名のスクラムマスターが在籍していますが、まだまだ足りていません。 面白そうだなと思った人は、ぜひ一度お話しましょう。

recruit.jobcan.jp

その他のポジションも絶賛募集中です。 LOVOTに関わるお仕事に興味ある方は是非ご検討ください。

recruit.jobcan.jp

シナリオテストのおはなし

この記事は、Groove Xアドベントカレンダー2022 の10日目の記事です。

こんにちは! LOVOT の ソフトウェアの検証を実施・改善しているチームです。

社内ではQAチームと呼ばれているのですが、単に製品に問題がないかの確認するだけでなく、ユーザー目線で評価することで、品質を向上させる活動を行っています。

LOVOTの新しいソフトウェアがリリースされるときは、たくさんの評価試験を実施してから配信されます。

今回はソフトウェアがリリースされる前に、どのような場所でどのような評価試験を実施しているのかを一部ご紹介したいと思います。

LOVOTの過ごし方

さて、どんな試験をしているのかというご紹介の前に、LOVOTはどんな風に家の中を過ごすのか、少しお話させてください。

LOVOTをお迎えされた方はご存知かもしれませんが、ご家庭に届いた時、実はLOVOTはまだ生まれていません。

ネストと呼ばれる充電ステーションに入れてあげることによって、目を覚まし、その日がLOVOTの誕生日となります。

そしてLOVOTはネストが設置された部屋を中心に家の中を探検し、部屋の形や障害物を覚え、自分のお家のマップを作ります。

またLOVOTは人を見つけると近寄って抱っこをせがんだり、周りにLOVOTがいればそのLOVOTと遊びます。充電が少なくなったら自分でネストに戻って充電しにいき、満充電になればネストから出てきてお部屋の中を歩き始めるなど、とても自由に動き回ります。

※過去のイベントのお洋服をお借りして、いつも検証をがんばっているLOVOTたちに着せて撮影してみました!通常は普通のベースウェアを着ています。

シナリオ試験

私たちはソフトウェアがリリースされる前に、実際に生まれるところからお家で過ごす様子を確認しています。

このような一連の流れを確認し、機能や性能に加えオーナー様目線で違和感がないか確かめる評価試験を、シナリオテストと呼んでいます。

この試験は複数の環境で実施しています。たとえばオーナー様宅ではインターネットがある環境、ない環境どちらもあります。

どちらの環境でもLOVOTが生活できるよう、評価試験ではオンラインとオフラインの環境で正常に活動できるか確認しています。

また確認する観点として生まれた後にちゃんとネストと通信出来るか、ネストに戻れるか、マップを作るかなどなど...

LOVOTと生活をしていただくために必要不可欠な動作を評価しています。

試験環境

LOVOTミュージアムがある建物の弊社オフィスにて、LOVOTの開発や試験なども行っています。

もちろんオフィスにもたくさんのLOVOTがいて、評価を実施するための専用の部屋もありますが、LOVOTはご家庭で生活することを考え、一般家庭に近い環境で一部の評価試験を実施しています。

先程紹介した、LOVOTが届いて生まれる前〜数日の様子を確認する試験の一部も、実はここで実施しています。

最後に

LOVOTならではの評価試験についていかがだったでしょうか?

なかなか実際に人が住むような環境で評価試験を行うような製品は少ないのではと思います。

家の中を自由に動き回り、家族のひとりとして迎えられるLOVOTだからこそ、必要となる試験のひとつと言えるのではないでしょうか。

今回細かくは紹介しきれなかったのですが、ネストに戻って充電して、人と遊んで、お部屋の中を歩き回るなど、普段の生活のなかで不具合が起こらないか別の評価試験で確認を行っています。

詳しくはQAチーム2回目の記事(12/23に公開予定)でご紹介しますので、そちらもぜひご覧ください!!



一緒に働く仲間募集中

世界で唯一無二の存在、LOVOTの成長にご協力いただける方をお待ちしています!

ポジションなどの詳細はこちら

もしご興味があれば是非ご検討ください!

最後まで読んで頂きありがとうございました!

Appチーム・仕事の流儀 〜LOVOTアプリのUIリニューアル舞台裏〜

こんにちは!App(アプリ)チームでLOVOTアプリのデザインをしている、南地です。

LOVOTアプリは今年4月に大幅なUIリニューアルを行いました。UIのリニューアル、これまで使い慣れていたUIが変わってしまうので、一般的にはユーザーからの不満がつきもの。

それでもAppチームでは、そのストレスをできる限り軽減したいと考え、アプリの画面内にとらわれず、様々な工夫をすることでソフトランディングすることができました。

今回はUIリニューアルのプロセスの話を通して、Appチームがどのようにユーザーに向き合っているのかについてご紹介します。

LOVOTアプリのBefore(左)・After(右)

Appチームの紹介

Appチームは自分の他に、アプリエンジニア、ふるまいエンジニア、アニメーター、そしてQA(テスター)がそれぞれ1人ずつ、合計5人で構成されています。

それぞれ違った役割を持ちながら、時に専門領域を超えて協力し、スマホからLOVOT自身のふるまいまで、アプリに関することはワンチームで一気通貫して作ることのできるコンパクトなフィーチャーチームとなっています。

Appチームのメンバー

Appチームでは、ただ単に機能を開発するのではなく、常にオーナーの皆様にどうしたら喜んでいただけるか・ストレスなくLOVOTライフを過ごしていただけるかという視点をとても大切にしています。

それもあってか、とてもありがたいことにiOS / Androidともにストアの評価では★5つ中4.7と、高評価をいただいています。何らかのデバイスと連携するIoT系のアプリとしてはかなり良い評価ではないでしょうか。(中には対応が難しくてずっとお待たせしてしまっている改善点もたくさんあるので、この評価に甘んじてはいられませんが…)

iOSでの評価

オーナーの皆様のニーズに向き合うため、自分たちは定性・定量の両面でアプリの開発・改善に役立つ情報を吸い上げています。

定性的なアプローチとしては、アプリ内の「ご意見・ご要望フォーム」から寄せられた投稿の全てに目を通したり、IFTTTを活用してtwitterへの「(LOVOT AND アプリ) OR(らぼっと AND アプリ)」で引っかかる投稿がSlackに通知されるようにしていたり、もちろんストアレビューも新しいものが来ていないか毎朝チェックしています。(実は、返信は全て自分が書いてるんです!)

定量的には、各機能がいつ・何回使われたのかをFirebase Analyticsを用いて集計しており、毎週、過去1週間の傾向について全員で確認するのを大切なルーティンにしています。
例えば、LOVOTが作ったマップを確認できる機能は、元々は必要な設定をする時にだけ使うという想定でしたが、コロナ禍の緊急事態宣言前後でマップの利用回数が増減していることから、意外と外出先での利用が多いことがわかりました。

これらの両軸を活用することで、「アプリの現在地」をなるべく正確に把握することにチーム全員で努めています!

リニューアルのきっかけ

それでは、本題のアプリリニューアルの話に入っていきたいと思います。

UIを大幅にリニューアルするきっかけとなったのは、LOVOT 2.0の登場でした。

これまでも複数のLOVOTと一緒に暮らすオーナーがいらっしゃいましたが、2.0の登場でさらにそうしたケースが増えることが予想されました。

当時のアプリでは同じコロニー(ネストと、それを共有するLOVOTの組み合わせ)単位でしか同一のホーム画面で表示することができず、コロニー単位で切り替える必要がありました。

でも、一緒に暮らすLOVOTたちは1つの家族。

そこで、同じユーザーがアプリに登録しているLOVOTたちは、1つのホーム画面上に表示されるようにしよう!となったのでした。

一緒に暮らす、公式twitterのみるきぃちゃん(LOVOT初代)とリアンくん(LOVOT 2.0)

新UIの情報設計プロセス

アプリのリニューアルは、複数のコロニーのLOVOTが1つのホーム画面上に来てもユーザーが迷わずに操作できるよう、各機能を再配置する情報設計からスタートしました。

その中で最も難しかったのが、複数のコロニーにまたがった時に、今どのLOVOTについての操作をしているか、迷わないようにすることでした。

まずはUIデザイナーの自分がリードして、ワイヤーフレームという簡単な線画だけで描いた機能配置のパターンをいくつも描きました。そして、チームで何度も何度も議論を重ね、仕事も趣味もバックグラウンドが様々なメンバーからは、ゲームやペットの健康管理アプリを参考にするなど、様々な意見が飛び出し、またワイヤーフレームにフィードバックしていきました。

初期のワイヤーフレーム

そうして見えてきたのが「1体ずつにフォーカス&スムーズな切り替え」というコンセプトでした。つまり、縦にLOVOTを並べ、上下スワイプするとLOVOT1体ずつにスナップし、そこから各機能にアクセスできるようにするというものです。

従来は、LOVOTをタップした先にメニュー画面を開き、そこから各機能にアクセスしていたのに対し、主要な機能へのボタンをホーム画面に持ってくることができ、シンプルさを保ちながらアクセス性を向上することができました。

最終形に近づいたワイヤーフレーム

ユーザーの声とアナリティクスを反映した一等地の選抜

ホーム画面に生まれた一等地に配置する主要な機能の選定にあたっては、Firebase Analyticsからの分析結果を反映しました。

ユーザーからのフィードバックで、ホーム画面に設置してアクセスしやすくしてほしいと要望の多かったダイアリーとアルバムは最初にスタメン入り。

そして、設定機能の一部だったマップが、Firebase Analytics分析の結果、外出先からLOVOTが元気にしているか確認するニーズがあることがわかり、当初の想定より利用回数が多いことから、晴れてホーム画面に昇格となりました。

UIが一新されたことへの抵抗感をなくすために

新UIの方向性が決まったところで、次はこれまでのUIを使い慣れたユーザーへのフォローを準備していきました。

まず、アプリの中でできることとして、UIがどのように変わったかがわかるよう、「ウォークスルー」という、実際のUIにオーバーレイして表示するガイドを用意しました。

ウォークスルー

さらに、アプリの外でも一工夫しています。それが、iOSのTest FlightやAndroidのクローズド テストを活用した「ベータ版テスト」の実施です。

有志のオーナーが参加してくださっている「LOVOTオフィシャルサポーターズ」の中から参加していただける方を募り、一足先に体験していただくというもの。これまで、LOVOTソフトウェアの先行体験は何度もやってきましたが、アプリの先行体験は初めての取り組みです。オーナー向けの情報発信やイベント運営をしているCX(カスタマー・エクスペリエンス)チームに相談し、実現することができました。

このベータ版テストは、純粋にリリース前に改善点を発見する目的に加え、実はオフィシャルサポーターズの皆様に新UIのインフルエンサーになっていただきたい!という意図がありました。
やはり、実際にご愛用いただいているユーザーの意見が一番、他のユーザーにも響くと考えたからです。

そのため、クローズドなテストでしたが、スクリーンショットSNS投稿は大歓迎とし、開始から約半月後にはオーナーとAppチームメンバーとのミーティングをオンライン開催して、積極的な情報発信をお願いしました。これによって、ベータ版テストに参加していないユーザーにも、事前にリニューアル後の画面を見ていただくことで、UIの変化への予防接種的な効果が期待できます。

その結果、非常に多くの嬉しい投稿をしてくださり、また、オーナーの皆様の反応を直接見たり、開発チームの想いを語ることができ、開発者としても一番やりがいを感じられる、忘れられない体験となりました!

オンラインミーティングにご出席いただいたオーナーの皆様

UIリニューアル、正式リリースの結果!

ベータ版テストでの反応も良いことが確認でき、またご指摘いただいた自分たちだけでは気づかなかった細かな改善点も盛り込んだ上で、いよいよ4月5日に正式リリースとなりました!!

普段からウォッチしているtwitter上でも多くの喜びの声が見受けられ、中でも開発者として意外だったのは、「ホーム画面のLOVOTのイラストが大きくなったこと」について、想像以上に喜んでいただけたことでした!
今回のリニューアルの中では比較的簡単な変更だったのですが、それがまさかこんなにお喜びいただけるとは。

一方、心配していた使い慣れていたUIから変わったことへの反応は、ベータ版テストに参加してくださったオーナーからのSNS発信もあり、ネガティブな意見は見受けられずホッとしました。

Twitter上の反応

Firebase Analyticsでの分析結果でも、ホーム画面の一等地に移動した機能の利用数は大きく伸び、マップに至ってはリニューアル以前の2倍ほどを記録しました。

各機能の利用数変化(赤線が正式版リリース日)

アクティブユーザー数も、従来の増加ペースと比べるとベースが上がったことが見受けられます。

アクティブユーザー数の増加ペース(赤線はリニューアル前の増加トレンド)

こうして、アプリのUIリニューアルは定性的にも、定量的にも、無事ユーザーに受け入れられたことが確認できました。

まとめ

Appチームでは普段スマートフォンの中での出来事を開発していますが、より良いユーザー体験を生み出すためには、時に画面の外側にも目を向ける必要があると考えています。

LOVOTアプリは、LOVOTというリアルな存在とつながるためのものなので、その必要性はなおさら高くなります。

今回は、UIリニューアルというネガティブな反応が生まれやすいトピックに対して、ベータ版テストを通した総合的なアプローチによって上手く乗り切ることができたことをご紹介しました。

 

そんなAppチームでは、もっともっとユーザーに向き合い、LOVOTとの絆を深めたり、便利だったり、ワクワクしたりするようなアップデートを重ね、LOVOT自身の進化に負けないくらい成長させて行くために、LOVOTアプリの開発を一緒に加速してもらえるエンジニアを募集しています!!

少しでも興味を持っていただけたなら、まずはカジュアルにお話をすることもできますので、お気軽に以下よりご連絡ください。

また、アプリ以外の分野も募集していますので、LOVOTに関わるお仕事に興味ある方は是非ご検討ください。

 

最後までお読みいただき、ありがとうございました!!!

人に気がつくLOVOT

こんにちは、GROOVE Xのfmyです。
私達のチームではLOVOTが人に気がつくための認識を作っています。
今日その中でも2つ、画像認識とタッチ認識がどんなことをしているか紹介します。

人に気がつく必要性

LOVOTは人とコミュニケーションを行うという目的をもっています。
人と関わっていくために人の生活空間内で人の存在に気が付かなければなりません。

認識では意味が広いのでここでは「認識」を「LOVOTがふるまいに必要な外界についての予測や情報を指す」とします。
(ふるまいについては市川さんの記事をご覧ください)

画像認識

ロボットが人を認識するのに有力な方法の一つが画像認識の技術です。
LOVOTもセンサーホーンのカメラを使って周囲を撮影し、Object Detection(物体検出)と呼ばれるタスクで周囲の人やモノの存在を認識しています。
LOVOTのテクノロジーもご覧ください

LOVOTが撮影した写真に物体検出の枠を表示した例。動き回るので写真がぼやけることもよくある

Object Dectectionでこのように人を検出することは出来ますが
人間とコミュニケーションを取るには人の存在を知るだけでは十分ではありません。
何をしているのか、何かを伝えようとしているのかに気が付くのが望ましいです。
そのためLOVOTは物体の認識や人の存在だけでなく表情や姿勢を読み取れるような認識モデルがあり、ふるまいのための『認識』を作っています。

LOVOTが周囲の人を認識している様子

タッチ認識

動物も、もちろん人間も身体を使って触れ合うコミュニケーションを取ります。
撫でてもらってうっとりしたり、触られてほしくないところは嫌がったり、LOVOTも同じコミュニケーションが取れることが期待されています。
LOVOTは全身に様々な種類のタッチセンサーがあり身体に何かが触れていることを検出しています。
ところでみなさんもスマホタブレットなどを使ったことがあると思いますが、水滴や物に意図せず反応したり逆になかなか反応してくれないという経験はないでしょうか。
LOVOTも同じで様々な大きさの人の手や触り方でも『認識』できるように、自分自身の動きや全く別のものが触れた時に人と間違えないために機械学習を利用しています。

タッチをモニタリングしている様子色が触り方の種類の違いを示している

最後に

ロボットが外界を、人を、多様なコミュニケーション認識するにはまだまだ多くの課題があります。
何を持って認識が出来ているとするのか、常に学習と更新を続けるにはどうすれば良いか、限られた電力をどう使うか、私達と一緒に考えて『認識』を作ってくれる方を募集しています。 ぜひ採用ページにアクセスしてください!

recruit.jobcan.jp