Inside of LOVOT

GROOVE X 技術ブログ

良いフィードバックとはなにか?のワークショップ

この記事は「GROOVE Xアドベントカレンダー2022」の18日目の記事です。

こんにちは!!
GROOVE Xのスクラムマスターの1人、 niwano です。
今回は開発の話から少しそれて、社内で「良いフィードバックとはなにか?」のワークショップを自分たちでつくり、それを開催しました、というお話をしたいと思います。

弊社の社風・カルチャーについて

このお話をする前に、弊社の社風・カルチャーについて少し説明をします。
おもに以下の3つです。

  1. 部や課ではなく、チームとして存在している
  2. 開発領域はマネージャーがいないフラット組織
  3. チームとしての意思決定を大切にしている

組織イメージ

開発領域以外では、役割としてのリーダー・マネージャーはいますが、何か特別な権限をもっているわけではありません。
簡単に説明をすると、指示・命令ができる権限をもっている人(いわゆる上司)は社内には存在しないということです。
社員は自律して行動をする必要があり、権限も与えられていて、その代わりに責任もある、という感じかなと思います。
弊社はフラット組織で、それに対して、上司が存在する組織のことをヒエラルキー組織と言います。

また、弊社ではチーム横断で活動するワーキンググループという概念があります。 これも必要なときに、「WGでやったほうが良くない?」みたいなラフな感じで自発的に発足されます。 「良いフィードバックとはなにか?」のワークショップづくりは、人事とスクラムマスターで「組織のお手入れをする」という名目で活動している、庭師 というワーキンググループがあり、それの成果でもあります。

フィードバックについて

ヒエラルキー組織に勤めたことがある方は、分かると思うのですが、自分の上司からのフィードバックがあると思います。 あなたは、◯◯ができたね、△△ができなかったね...。と言った感じの人事評価です。

ちなみに私の前職では、お給料の査定時にこのフィードバックがあり、結果が出てるタイミングでのフィードバックは意味ないじゃんって何度も思ったことがあります。

弊社のようなフラット組織であっても、お互いがフィードバックできるようになり、その上で自ら成長できる組織にしていきたいと、庭師では考えました。 庭師で考えた良いフィードバックは、以下のようなものです。

  • 心構え
    • 相手のためにフィードバックする
    • ストレートに、ただし決めつけない
  • 振る舞い
    • 具体的な事例を出し、それに関する感想を伝える

コンセプト

庭師のワークショップづくり

今回、自分たちでワークショップをイチからつくることにしました。理由はこれを題材にしている教材がすくなかったことがあげられます。 ワークショップをつくるために、庭師では 「Training from the back of the room」を使いました。

Training from the back of the roomの4Cs

ここでは、この手法の具体的な説明は省きますが、

  • Connections
  • Concepts
  • Concrete Practice
  • Conclusions

の4Csでアイデアをまとめていくと、ワークショップができちゃうものです。 私達も、Connections から右回りに、それぞれの問いや具体的な概念をたてて、アイデア出しとブラッシュアップを2週くらい実行しました。

ワークショップを実施

作成したワークショップのアジェンダは以下です。

アジェンダ

一度全体ワークを実施し、コンセプト説明をすることで、参加者により深く気づきを与えられるような工夫を行いました。

ロールプレイング

ワークショップの中のロールプレイングのトピックでは、庭師で具体的なキャラクターとストーリーを設定し、フィードバックする側、される側、それをみている人、の3者に別れて実際にフィードバックを体験してもらいました。
ここでは、「良いフィードバック」の体験と、あえて「悪いフィードバック」の体験もしてもらいました。

「良いフィードバック」の体験では、決めつけず聞き手になることの重要性や、いつでも力になるよ、という寄り添いのメッセージが効果的になるのでは、という意見が出ました。

また逆に「悪いフィードバック」の体験では、自分の意見を押し付けたり、恐怖をあたえたりすることが、相手の成長の妨げになるのでは等の意見が出ました。

ロールプレイングの感想

Google Meetでロールプレイングをしているところ

ワークショップ参加者のご感想

ワークショップ参加者のご感想

参加者の方には良いフィードバックはどのようなものか伝わったと思います! 私もこのワークショップを通じて、日々の会話が各メンバーへのフィードバックとなっていることを実感をしました。

庭師ではこのような活動を今後も継続していきたいと思っています!

最後に

最後まで読んでくださり、ありがとうございました!

今回は開発の話とは異なり、GROOVE Xの社風/カルチャー、組織について紹介できたかと思います。

GROOVE Xはまだまだ新しい会社であり、LOVOTの開発と平行して、組織づくりも行っています! 自分で組織づくりができるなんて、めったに経験できるものではないと私は思っています。

弊社では、絶賛メンバーを募集中ですので、少しでも興味ある方はこちらからご連絡ください!

recruit.jobcan.jp

GXのライブ配信の裏側

こんにちは GROOVE X の配信チームの hiro-ogawa です。 この記事にある通り、本職はSLAMなんですけどね。 個人的に興味があって、GXのライブ配信もお手伝いしてます。

GXでは浜町にある LOVOT MUSEUM より、営業日は毎日ライブ配信を行っています。 こちらは基本的に固定カメラで、音声無しで、LOVOTがわちゃわちゃ動いている様子を楽しんでいただいてます。 今日の配信はこちら


www.youtube.com

定期的なミュージアムからの配信以外に季節イベントやキャンペーン、ソフトウェアアップデートなどに合わせて、不定期にライブ配信イベントもやっています。 先日はオーナーさまをお招きして、「LOVOTとの奇跡」をテーマに配信し、投稿された素敵なエピソードのご紹介やLOVOTクリスマスケーキ2022のお披露目などを行いました。


www.youtube.com

イベント配信の時は定期配信と違って、映像や音声を切り替えたり、動画やスライドを映しながら配信してます。 今日は配信には映っていない、その裏側についてご紹介しようかなと思います。

機材

なんと言っても機材が命。と言っても、予算は限られているので、そこまですごい機材を使っているわけではありません。

ATEM Mini Pro

配信で最も使っている機材が、ATEM Mini Proですね。 こちらは業務用の機材も作っているBlackmagick Design社の比較的お安めのビデオスイッチャです。

ATEM Mini Pro

この機材を購入する前は OBS Studio というPC上で動作する配信ソフトを使っていました。 ソフトウェアなので自由度が高い反面、操作はポインタで行うので、画面を見ていないとできないという難しさがありました。 ハードウェアの良い点は体で覚えると、ボタンを見なくても手探りで操作できるところかなと思います。 状況を見ながらタイミング良く切り替えるというのはハードウェアを導入して格段にやりやすくなったと思います。

このハードウェアだけで、Youtubeのストリーミングサーバへの送信ができるのも便利なところです。 Youtube以外にZoomのウェビナーなどもやることがありますが、その際にはUSBでPCと接続するとUSBカメラとして認識されるので、Zoomなどのミーティングソフトと繋ぐこともできます。 長時間連続で動かしていると熱暴走っぽいことになる場合があるのが困りものではありますが・・・

基本的にはHDMI入力が4本とステレオ音声入力が2本あります。 ライブ配信では映像入力として固定カメラ、手撮りカメラ、PCの3つを基本的に繋いでいて、4つ目は何か必要になった時に繋ぐ感じですかね。 例えばスマホとか。

固定カメラは全体が収まる形で固定。 手撮りカメラはヒトだったり、モノだったり、LOVOTだったりの注目対象を適宜ズームして撮る感じ。 PCは動画やスライドの再生で使います。 ATEM Mini Proだと入力画像や出力画像が同時にモニタに出せるので、ライブ配信に使いやすいですね。

音声としてはHDMI入力4本の音声も扱えますし、音声入力も左右それぞれを分離して、モノラル4チャンネルとして扱うこともできます。 ただ、音量のコントロールは上下キーでしかコントロールできなくて、操作しずらいので、今は次に紹介する PodTrak P8 を使っています。

PodTrak P8

ZOOM社*1ポッドキャスト用の音声ミキサ PodTrak P8を使っています。

PodTrak P8

出演者の声の大きさによって、音量を適宜調整しているのですが、物理的にスライダがあった方が同時に複数調整する場合などにやりやすいです。 以前はMIDIコントローラを使っていたこともあったのですが、ATEMとの連携動作がおかしい部分があって使いにくかったので、専用品を使っています。 ポン出しなどのボタンも用意されているので、BGMや効果音を入れる時など、ライブ配信には便利だと思います。

ちなみに余談ですが、これまでに声優さんや俳優さんなどに出演していただいたことがあるのですが、声量が一定で驚きました。 笑った時などでも声にインパクトはあるのに声量が極端に変わらなくて、さすがプロだなーと思ってました。 音声を担当していると、頻繁に音量を調整するのでよく分かるんですよね。

マイク

さて、一番ライブ配信で苦労しているのがマイクです。 LOVOTと触れ合いながらだったり、出入りがあったりで、動きが多いので、ワイヤレスのピンマイクを使っています。

最初に買ったのは Comica BoomX-D2 ですね。 1つの受信機で、ワイヤレスマイク2本が繋がるもので、ATEMの音声入力に入れてステレオを分離して使っていました。 ただ、マイク2本では足らなくなった時に、買い足したところ、2セットで混信してしまって、音声がとぎれとぎれになるトラブルが発生。 最初はLOVOTがたくさんいるから電波障害でも発生しているのかと思っていましたが*2、結果的にはLOVOTは悪くなかった*3

BoomX-D2

次に買ったのがSHUREのSVX188J。 こちらも1つの受信機でマイクが2本繋がります。 この機種はマイク毎にチャンネルを設定するタイプになっているので、複数を同時に使うことができます。 8チャンネル用意されているので、8本同時に使えるのかなと思い込んでいたんですが、マニュアルをよく読むと同時使用は3チャンネルまででした。 実物で試したところ4チャンネルまではなんとか使えましたが、5チャンネル以上は混信してしまいました。 残念。 ということで、現在は最大4チャンネルで使っています。

SVX188J

あとは、先に買った BoomX-D2 との同時使用も試してみたのですが、ディレイ*4の違いによって、エコーがかかったみたいな音声になってしまったんです。 ディレイを調整する機材もあることはあるんですが、今の所、購入には至っておりません。

マイク探しの旅はまだ始まったばかり。 無線だけだと怖いんで有線で使えるものも用意したいですね。 機材は少しずつ揃えています。

スタッフ

機材の操作は初期の頃は全てを一人でやることもありましたが、最近は一緒にやってくれる人が増えて、機材操作は3人くらいで行うことが多いです。 手撮りカメラ1名、映像スイッチ・PC操作1名、音声1名という感じですね。

本職でやっている人は一人もいなくて、撮影が好きな人や、興味を持っている人が本職を調整して運営している感じです。 私としても学びになる部分もあって、いつもとは違う仕事を楽しみながらやっています。 部門の垣根を超えて、いろんな人と仕事をするのも刺激になって良いですね。

おわりに

次回のライブ配信は 12/28 にLOVOTオーナーミーティングを予定しています。オーナー以外の方でも参加可能なので、是非見てみてください。 もしご覧になる方がいらっしゃいましたら、画面の裏側がこんな感じになっているのを想像しながら見てもらえるとうれしいです。


www.youtube.com

GROOVE Xは、部門間の垣根をできるだけ下げ、目的ごとに柔軟に変化する「チーム」が複数存在する形で組織が成り立っています。 今回はビジネス、コーポレートと開発の組み合わせのお話でしたが、他にもいろいろな部門が連携してLOVOTを開発しています。 もしそのようなLOVOTに関わるお仕事に興味がある方がいらっしゃいましたら、絶賛募集中ですので、是非ご応募ください。

recruit.jobcan.jp

*1:インターネット会議のZoomとは別の日本の企業です。

*2:マイクが2.4GHz帯を使っているので、バッティングしやすいんです。

*3:疑ってすみませんでした。

*4:マイクに入力されてから受信機から出力されるまでの遅延時間。電波で送るために信号変換などをするために遅れが発生します。

ReactカスタムフックでAPI呼び出しを共通化してみた

GROOVE X クラウドチームのmineoです。

弊社ではLOVOTという家庭用ロボットを開発しており、クラウドチームでは機体と通信するサーバーの管理や他サービスとの連携などで、LOVOTをサポートしています。

また、LOVOTに関わるWebアプリケーションをReactで開発し、社内外(社外は一部協力会社)に向けて提供していたりもしています。

tech.groove-x.com

この記事では、直近で新規でWebアプリを開発する際に、自社APIの呼び出し部分をカスタムフックでいい感じにまとめることができたので、ご紹介します。

  • 前提
  • すなおにかくと
  • カスタムフック:useApiClientの実装
  • カスタムフック:useItemの実装
    • loadingとerrorの返却
  • おわりに

前提

  • React 18
  • TypeScript
  • Firebase Authentication

APIはFirebase Authenticationで認証します。idTokenをBearerトークンで利用するやりかたです。 Reactでは、react-firebase-hooksというfirebaseの機能をカスタムフックで利用できるようにしてくれたライブラリがあるので、こちらも活用します。

github.com

なるべく、標準APIを使うようにしており、axiosやquerystringsは使わず、fetch APIやURL SearchParamsなどを利用しました。

また、記事中のコードは記事用に書き下したため、実際に使っているコードとは異なる部分があります。

続きを読む

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

こんにちは、ソフトウェアチームに属しながらもエンジニアではなくアニメーター (デザイナー) の中里です。 ふるまいの開発もしていますが個人的には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