Inside of LOVOT

GROOVE X 技術ブログ

Ubuntuが標準の会社でFedoraを使っている男の話

こんにちは、斎藤@aznhe21です。会社では最近「あず」と呼ばれたり呼ばれなかったりしています。 転職してから初めてのブログです。すぐブログを書くつもりではいたんですが気付いたら9ヶ月も経っていました。時間経つのはや。

さて、皆さんの社用PCにはどんなOSが入ってるでしょうか? GROOVE Xでは開発用にはUbuntuの入ったPCが配布されます。 これはLOVOTの中身がUbuntuということからで、各種ツールの作りや管理をLOVOT用と開発PC用で共通化できるというメリットがあります。

またLOVOT用のパッケージや開発用の各種ツールは社内のaptレポジトリで管理されており、普通のパッケージと同じノリでインストールできます。 自分でビルドする必要がないのはとても便利です。

UbuntuではなくFedoraという選択

しかし私はFedoraを使っています。大きな理由というのはないんですが、 元々自宅鯖用にCentOSを使っていたことから前職でもFedoraを使っており、その流れでGROOVE XでもFedoraを使っています (今の自宅鯖にはRHEL無償版を使わせてもらっています)。 snapが嫌というのもあります。いやこれが半分くらいあるかも。

FedoraでもUbuntuのパッケージを使う

開発用のツールはUbuntu向けには配布されていますが、裏を返せばFedoraでは使えません。 一部ツールはGo製なのでその場合はパッケージからバイナリだけを抜き出して使うこともできなくはないんですが、 外部ファイルを必要としていたりGo製じゃなく依存ライブラリがあったりする場合は管理が面倒です。

そこでシステムコンテナを扱えるIncusを使います。 コンテナと言えばDockerやpodmanですが、これらはアプリケーションコンテナを扱うためのツールです。 アプリケーションコンテナはアプリケーション単体を扱うものですが、システムコンテナはsystemdなどを含めた複数プロセスを扱います。 これにより実質的にVMのような使い方ができるのです。 しかもコンテナであるためメモリ消費等オーバーヘッドは無視できるレベルです。

細かい使い方は説明しませんが、ホストのディレクトリをコンテナにマウントすればファイルの共有も簡単です。

コンテナ内でもmDNS

少し面倒なのがmDNSの扱いです。LOVOTの開発ではよくLOVOTにsshするのですが、 LOVOTに付けた別名がmDNSとして広告されるため、接続先はこの別名を指定するのが便利です(※)。 しかしUbuntu環境はコンテナ内でありマルチキャストを使うmDNSのパケットは届きません。 そこでmdns-repeaterを使います。

※LOVOTにsshできるのもmDNS名が広告されるのも開発モード限定です。

mdns-repeaterはネットワークのインターフェース名を2つ以上指定することで、各インターフェースに届いたmDNSのパケットを中継・転送してくれます。 Incusのネットワークインターフェース名がincusbr0でホスト側のネットワークインターフェースがwlp0s20f3なら、 ホスト側でmdns-repeater incusbr0 wlp0s20f3とコマンドを実行することでコンテナ内からもmDNSが使えるようになります。

Fedoraのパッケージにはsystemd用のファイルが含まれるので、設定しておくことで自動起動させることができます。

$ cat /etc/sysconfig/mdns-repeater
OPTIONS="incusbr0 wlp0s20f3"
$ sudo systemctl enable --now mdns-repeater

使っているツールとか

OS・ディストロの話だけでは味気ないのでツールの紹介もしておきましょう。

デスクトップ環境はKDE

KDEは普通です。なのに痒いところに手が届く利便性も持っています。デスクトップ環境にこれ以上何を望むでしょうか?

なぜかUbuntuもFedoraも、標準のデスクトップ環境にはGNOMEを採用しています。 しかしGNOMEはデスクトップ環境としては特殊と言わざるを得ません。 WindowsともmacOSとも大きく異なったUIを持ち、数多の拡張機能を入れなければ不満が募り続けます。

私はカスタマイズをするためにデスクトップを使っているわけではないのでKDEを使います。 最初からストレスなく使えますし、ウィジェットによって大小様々なカスタマイズもできます。

デスクトップの様子
Windows 11っぽくランチャーは真ん中にし、左下にシステム情報用ウィジェットを配置している

スクショはSpectacle

前回の記事でいいスクショのツールがないよーという話があったので書いておきます。

私はスクショの撮影には専らSpectacleを使っています。 KDEに付属しているツールで、スクショを撮ったまま編集もできます。 動画の撮影もできます。多分WindowsのSnipping Toolを参考にしてそうです。ただし今のところ文章の抽出はできません。 KDE付属なのでもちろんWaylandでもちゃんと動きます。

エディタはNeovim

社内ではVS Code派がいたりJetBrains派がいたりしますが、私はNeovimを使っています。

学生時代に軽い気持ちでvimを導入したらキーバインドから離れられなくなりました。 エディタ向けvim系プラグインは大体不満が出てくるので諦めました。助けてください。

ここで宣伝です。LSPのコードアクションを適用する前からどうなるかをプレビューできるプラグインを作っています。 便利なので皆さんも使ってみてね!

ターミナルはWezTerm

OSC 52(エスケープシーケンスでコピペ)やundercurlなどニッチっぽい機能にも対応していて便利です。 マルチプレクサが内蔵されてるのでtmuxいらずです。

さいごに

単純にLinuxで仕事ができるって良いですよね。

GROOVE XではLinuxデスクトップにこだわりのある方を募集しています。

使っているおすすめツール紹介(Ubuntuでスクリーンキャプチャしたい編)

こんにちは。 GROOVE X でソフトウェアエンジニアをやっている id: numa-gx です。

突然ですが、スクリーンキャプチャした画面にキャプションを追加して画像を誰かに送らねば…となったことはありませんか?

弊社では開発環境がLinux : Ubuntu 22.04 を使っているエンジニアが多いですが、標準のスクリーンショット機能ではキャプションを追加ができません。

そこで、最近使ってみて良かったのが Flameshotになります。 flameshot.org

(公式のデモ動画より)

以下のポイントに対応していたのが個人的に助かりました。

  • Linuxに対応している
  • スクリーンショット撮影した状態からそのままキャプション追加ができる
  • キーバインドを設定すれば通常のPrintScreenキー操作を上書きできる

Ubuntu22.04 でインストールする際に躓くポイントがあったので軽く解説したいと思います。

キャプション操作のUIが正しく表示されない場合

Flameshot は、Ubuntu22.04で標準のディスプレイサーバーとして採用されたWaylandへの対応がまだ不十分なため、この症状が発生します。そのため、ディスプレイサーバーをXorgに切り替える必要があります。

手順としては以下を実施します。

  1. sudo権限で /etc/gdm3/custom.conf を開く (例: sudo nano /etc/gdm3/custom.conf)
  2. #WaylandEnable=false となっている記述から先頭の#を削除(コメントアウトを解除する)して、ファイルを保存します

また Xorg で正しく動作するために、以下の記述を環境変数を .bashrc などに追加します。

export QT_QPA_PLATFORM=xcb

これらの手順を行った後、PCを再起動して、Flameshotを起動するとUIが表示されるはずです。

さらに、PrintScreenなど標準のキーバインドを置き換える方法も公式で手順も書かれていますが、かなり便利です。 ぜひ参考にしてみてください。

最後に

弊社では、Linux環境を使いこなせるエンジニアを絶賛募集中です。ぜひ一緒に開発しましょう!

また、様々な分野で募集しているため、是非下記リンクをご確認下さい。

recruit.jobcan.jp

最近の小ネタ3つ

こんにちは、クラウドチームへ出張中の Junya です。
最近気づいて便利だった小ネタを3つ紹介します。

goのgenericsで任意のmapのキーを並べ替える

今更感あるのですが、go の generics 便利ですね。

map を決まった順番で処理したい場面があったんですが、genericsを使ってこんな関数を用意したら、

package function

import "golang.org/x/exp/slices"

func SortedKeys[V any](m map[string]V) []string {
    keys := make([]string, 0, len(m))
    for k := range m {
        keys = append(keys, k)
    }
    slices.Sort(keys)
    return keys
}

string キーのどんな map に対しても使えて便利でした。

package function

import (
    "reflect"
    "testing"
)

func Test_sortedKeys(t *testing.T) {
    stringMap := map[string]string{
        "key2": "value2",
        "key1": "value1",
        "key3": "value3",
    }
    intMap := map[string]int{
        "key3": 3,
        "key1": 1,
        "key2": 2,
    }
    stringMapKeys := SortedKeys(stringMap)
    intMapKeys := SortedKeys(intMap)
    if !reflect.DeepEqual(stringMapKeys, []string{"key1", "key2", "key3"}) {
        t.Fatal("SortedKeys failed: ", stringMapKeys)
    }
    if !reflect.DeepEqual(intMapKeys, []string{"key1", "key2", "key3"}) {
        t.Fatal("SortedKeys failed: ", stringMapKeys)
    }
}

SignedURL で frontend から直接GCSへアップロード

社内向けのツールで frontend から直接 GCS へファイルをアップロードしたいユースケースで、 GCS の SignedURL を活用できました。

めちゃ便利。
なお、発行された SignedURL を知られてしまったら、有効期限のあいだ、誰でも何でもアップロード出来てしまうのでご注意ください。

GoLand(Ubuntu)での日本語入力

開発で GoLand(Ubuntu) を使っているのですが、なぜか GoLand 内での日本語入力が出来ず、悩んでいました。

Mozc や Fcitx の問題かなと調べていたのですが、結果的には GoLand の Java ランタイムの問題で、 IDE の起動 Java ランタイムを変更する を参考に、Java のランタイムを JetBrains 提供のデフォルトのものから、Ubuntu 側の openjdk-17-jdk に切り替えることで解決しました。

なお、カスタムの Java ランタイムのパスは

~/.config/JetBrains/GoLand2024.1/goland.jdk

に保存されます。うまく動作しない場合は、このファイルを削除すると設定がリセットされます。

絶賛採用中

LOVOT のようなロボット開発というと、ハードウェアを扱っているイメージが強いですが、実際には、EC・データ分析・生産管理・業務システムなど、ロボット開発そのものではない開発も多岐にわたります。 GCP, Kubernetes, Go, TypeScript, Teraform などを用いたクラウド開発の分野でも人を募集しているので、ご興味のある方はぜひお声がけください!

recruit.jobcan.jp

クラウド費用のコスト削減を試みたけど失敗した話

こんにちは、クラウドチームに出張中の Junya です。 今日は、クラウド費用のコスト削減を試みたけど失敗した話について、ご紹介します。

ことのはじまり

クラウドチームでは定期的に GCP の Billing ダッシュボードを見て、コストのボトルネックを確認しているのですが、イベントデータを処理する pubsub コストが高いことに気づきました。

出来る限りイベントを取りこぼさないよう、イベントデータは一度 pubsub に入れてからワーカー経由でデータベースに保存しているのですが、イベントは量も数も多いため、pubsub のコストがかさんでいました。

イベントデータを保存するためのパイプライン処理

Pub/Sub の料金 によると、Pub/Sub の費用は以下の3つの要素で決まります。

  1. メッセージのパブリッシュと配信のスループット費用
  2. Google Cloud のゾーンまたはリージョンの境界を越えるスループットに関連するデータ転送費用
  3. スナップショット、トピックで保持されるメッセージ、サブスクリプションで保持される確認応答済みメッセージのストレージ費用

今回の場合、1番目のスループット費用がボトルネックでした。はじめの 10 GiB は無料で、TiB あたり $40 かかります。我々の場合、イベントデータのスループットは数十TiB/月あるので、Pub/Sub だけで月に数千ドルかかる計算です。

Pub/Sub コスト削減対策

スループットはデータサイズに依存するので、Pub/Sub に生データを直接流す代わりに、Cloud Storage にデータを保存してから、その場所だけを Pub/Sub に流せばコストを削減できるのではと考えました。

イベントデータを Cloud Storage に保存することで Pub/Sub コスト削減する構成

Pub/Sub のコストと Cloud Storage のコストを比較すると、以下のとおりです。

  • Pub/Sub
    • $40 / TiB / 月
    • 数千ドル / 数十 TiB / 月
  • Cloud Storage
    • $0.023 / GB / 月 (保存期間に比例)
    • 数十ドル!? / 月

Cloud Storage へのデータの保存時間は非常に短いので、Pub/Sub に流していたイベントデータを一時的に Cloud Storage に保存することで、コストは数十分の一になることが期待できます。

実際、同じような方法でコスト削減を達成した事例がほかでも紹介されていました。

対策結果

思惑通り、Pub/Sub コストは 95% 削減されました。

Pub/Sub コスト(右端が切り替え後のコスト)

Storage コストの増分も、わからない程度です。

Standard Storage のコスト

しかし、Cloud Storage のオペレーションコストがヤバイほど爆上がりしていました

Standard Storage の Class A, Class B Operation コスト

全てを合わせると、このようになります。

Pub/Sub と Cloud Storage のトータルコスト

濃いオレンジの部分が Pub/Sub 費用で、それ以外が Cloud Storage の費用です。 思惑通りに Pub/Sub 費用は削減できたものの、それ以上に Cloud Storage の費用がかさみ、全体として 1,200% のコスト増となりました。

大失敗です。システム構成はすぐにリバートしました。

なぜ Cloud Storage の費用が爆上がりしたのか?

実は、Cloud Storage ではストレージ費用の他にオペレーション費用が発生します。

「Cloud Storage の料金」より抜粋(2024年4月現在)

クラスAオペレーションにあたる「データ書き込み」の場合、

  • $0.005 / 1,000 回

ですが、この数字を甘く見ていました。

イベントデータの数は1日に数億件あるため、

  • $0.005 / 1,000 回
  • $5 / 100万回
  • $500 / 1億回

1日に数億件のデータを読み書きすると、1日に数千ドルのコストがかかります。 オペレーション費用は、まったく無視できる単価ではありませんでした。

まとめ

ちょっとした工夫でクラウドのコストを大幅に削減できると期待したのですが、今回は思い通りにいきませんでした。 課金額を監視していたので短時間でリバートできましたが、見積計算は慎重にすべきだったと反省しています。 Cloud Storage のオペレーション費用にはお気をつけください。

LOVOT のようなロボット開発というと、ハードウェアを扱っているイメージが強いですが、実際には、EC・データ分析・生産管理・業務システムなど、ロボット開発そのものではない開発も多岐にわたります。 GCP, Kubernetes, Go, TypeScript, Teraform などを用いたクラウド開発の分野でも人を募集しているので、ご興味のある方はぜひお声がけ頂けると幸いです。

recruit.jobcan.jp

ソフトウェアチームのオンボーディングテンプレートをつくってみた

こんにちは、GROOVE Xのテックブログ2024年の3月は、ScrumMasterのniwanoです。2024年の1/4がもう終了しますね。はやい!

1ヶ月ほど前に、チームふりかえりで、メンバーからLAPRASさんの新入社員に関する記事が良いと聞いて私も読んでみました。

speakerdeck.com

"新入社員の呪い" 私も経験があります〜。でも私がGXにjoinしたのは、ずいぶん前なのですっかり忘れていたんですね。
思い出させてくれてありがとう、numa さん。

わたしがこの記事で特に好きだったのは、"新入社員の活躍を社内に広めるのはチームメンバー"のところでした。中途採用の方は「自分は絶対に活躍できる!」と思って入社されるはずで、でも入ってみたら自分が思った以上に活躍できてないなあ、って思うこともあると思うのです。(実際そうだったよーっという話しも聞きました。)
その方の活躍をあえて全体に共有することで、本人に安心を与えるのはすごく大事ですよね!

ところで.....、弊社にはオンボーディングに関する規定や仕組みが全くないことに気づきました。各チームがそれぞれ独自でやってたんですね。ですので、あとからあれがないこれがない、がたくさん出てきます。そこで、今回、LAPRASさんの記事の中にあった、オンボーディングの記事を参考に、GROOVE Xソフトウェアチームのオンボーディングテンプレートを作ってみました。

以下、ごらんください。
(各資料には実際にはページリンクがついています。)


3ヶ月後に達成していたい状態の合意

トレーナーと新入社員で合意をとる
"期待値をそろえる"のが、もっとも重要

  • Issueを解決できる
  • Issueの内容をインプットとして、自分の力で調査/解決することができる
  • GROOVE X組織全体のルールや仕組みの改善提案/構築ができる
  • 簡単なPBIを完了させることができる
  • GROOVE SESSIONで発表ができる(初回の自己紹介はカウントしない)

※LAPRASさんの例を、まずはそのまま利用させていただきました。GXの特徴を入れたい!

組織について

  • CEOビジョン2023について知っている
  • 全体朝会について知っている
  • 社員会について知っている
  • GROOVE SESSIONについて知っている
  • チームビジョンについて知っている

※GROOVE SESSIONという成果発表の時間が毎週あります。3ヶ月で何か発表できることを目指します。

待遇・福利厚生について

  • 勤務時間について知っている
  • 試用期間について知っている
  • 通勤手当について知っている
  • 賞与タイミングについて知っている
  • ストックオプションについて知っている
  • 育児、介護休暇制度について知っている

※わすれがち

開発について

  • リリースサイクルについて理解する
  • Doneの定義について理解する
  • 開発マイルストーン共有会のログを閲覧できる
  • 製品についての資料を閲覧できる
  • ソフトウェアエリアふりかえりに参加できる

※弊社はスクラム開発を実践しています。

Ubuntu編

  • 日常業務ができる
  • ターミナルでgcloudコマンドが使える

webサービスのアカウント

  • github
  • github copilot
  • confluence
  • wrike
  • package cloud
  • figjamのなんでもページにアクセスできる

開発言語編

TBD

slack

  • slack講座を一読する
  • チームの slack user groupにjoinする
  • huddleを作成できる
  • huddleにjoinできる
  • アイコンを変える
  • topic_ask-chatgptチャンネルを知っている

Git/Github編

  • gitコマンドを使える(pull / push /commit /merge/stash/add)
  • organizationに入る
  • PRを出せる
  • PRにコメントができる
  • PRをapproveできる
  • アイコンがなければアイコンをつくる

Google CloudWorkspace編

  • googleメールを送受信できる
  • チームの user groupに入る
  • アイコンを変える

Google Calender

  • チームメイトの予定を確認できる
  • カレンダーで会議室を予約できる
  • 全社予定カレンダーをインポートしている

Google Drive

  • 共有ドライブでドキュメントを作成できる
  • 共有ドライブでドキュメントの公開範囲を設定できる
  • マイドライブでと共有ドライブの違いを把握する

Meet

  • 参加できる
  • 録画できる
  • マイク、カメラ設定をon/offできる
  • 画面共有できる

wrike編

  • PBIのステータスを変更できる
  • PBIにコメントができる
  • PBIを作成することができる

Confluence編

  • ドキュメントの作成ができる
  • 公開範囲を適切に設定できる

社内研修

  • フィードバック研修
  • scrum研修

まとめ

いかがでしたでしょうか。
オンボーディングテンプレートをみたら、弊社の開発の様子が少しわかるかもしれません。
開発言語ですが、弊社では、python、Go、C、C++、javascriptなど、コンポーネントに適した開発言語を使っているので、今回記述が出来ませんでした。わたしはGo派です。

続きは、実戦編へ!

GROOVE X にソフトウェアエンジニアとして入社して 4 ヶ月経った感想など

まとめ

  • LOVOT ミュージアムで LOVOT に生命を感じ、衝撃を受け、気づけばソフトウェアエンジニア採用に応募していた
  • GROOVE X はマネージャのいないフラットな開発組織を運用しており、エンジニアの自立性・裁量が非常に高い
  • LOVOT はエッジデバイスでありながらデバイス内にマイクロサービス構造を持つソフトウェア構成をとっており、それが開発生産性の向上に寄与していている
  • 長期的な LOVOT との未来を作るために、まだまだ開発すべきことがあります。気になる方、採用 への応募をお待ちしています

概要

皆さんこんににちは。GROOVE X でソフトウェアエンジニアをしている id:iizukak です。2023 年 11 月に GROOVE X に入社して、4 ヶ月が過ぎました。 GROOVE X は組織・技術共に独自性が高く、面白いトピックがたくさんあるので、印象がフレッシュなうちにアウトプットしておこうと思います。

なぜ GROOVE X に入社を決めたのか

GROOVE X では、LOVOT というロボットを開発しています。

ある週末の夕方、東京の浜町にある LOVOTミュージアム を家族で訪れました。 時間があったのと、娘がロボット好きなので、何気なく予約したのだと記憶しています。 LOVOT ミュージアムは、個人宅を模した空間で LOVOT とふれあえる素敵な空間であり、小学生の娘はすぐに LOVOT にめろめろになりました。

私がそこで感じたのは、LOVOT から受ける生命感です。これは生きている、と。 LOVOT 以外のロボットでそういった印象を強く受けることは今までなかったので、衝撃的でした。 自分はモノづくり人間で、これを作るのはすごく面白そうだぞ、とすぐに感化されてしまい、採用に応募したのです。

smalovo チーム

GROOVE X に入社してからは、 smalovo というチームに配属されました。 スマラボ、すまらぼ、smalovo …どれが正式名称なのか未だに分かっていないのですが、読み方は「スマラボ」です。 スマート・ラボットの略称のようです。 このチームは、画像認識、タッチ判定、距離推定など LOVOT が世界を認識するためのソフトウェアを開発しています。

smalovo チームは取り扱う技術の守備範囲が広いのが特徴的です。 チームでは単一のソフトウェアコンポーネントの開発保守をするというだけではなく、 Linux、機械学習、デバイスドライバ開発など専門知識を活かした開発を行っています。 機械学習をやりつつ Rust でカメラモジュールを書いて Debian パッケージをビルドしてリリースしているのです。すごい!

なぜこれが可能なのかというと、各々のエンジニアが、自分にとって未知の技術に抵抗なく取り組む姿勢があるからのようでした。

GROOVE X のソフトウェア開発組織

入社してもうひとつ驚いたことは、チームにマネージャがいないことです。 これまでのソフトウェアエンジニア人生では、チームごとにマネージャがいて、1 on 1 があって、様々な許可を申請して… というのが普通でした。 GROOVE X にも領域ごとのプロダクトオーナーはいて、 スクラムのセレモニーなどではプロダクトオーナーに情報共有をしたり、方向性の確認を行う、ということはしていますが、一般的に言うマネージャとは違います。

それではどのように物事が決定するのかというと、チーム内外のディスカッションでほとんどのことが民主的に決まっていきます。 技術的なところもそうなのですが、備品の購入などについてもある程度のところまでチーム内で決めています。 採用についても、ある程度までチームメンバーの話し合いによって決めることができます。 エンジニアが技術以外のことに対しても必要であれば取り組む姿勢が求められている、ということでもあると思います。

そこで問題になりそうなのは、各開発チームが好き勝手に開発を行うことで、船頭多くして船山に登る状態にならないのかということでした。 しかしそういった兆候は見られません。 なぜなのか? それは自分もまだよく分かっていないのですが、目指すべき方向性の認識が一致しているからなのだろうと思っています。 GROOVE X 社員の LOVOT への愛情というベクトルが一致しているからなのでしょうか。

GROOVE X のソフトウェア開発技術

LOVOT の技術的な特徴について。

LOVOT の認識アプリケーションは、物体検出や人物照合、距離推定など多様であり、それらを協調して動かす必要があります。 それらの言語は、様々なプログラミング言語で、依存するライブラリもそれぞれ異なります。 様々なアプリケーションの協調動作を実現する方法はいろいろとあると思うのですが、GROOVE X ではマイクロサービスをベースにした構成を採用しています。 家庭用ロボットのようなエッジデバイス上でマイクロサービスが動いているというのは、面白い構成ですよね。 アプリケーション同士の通信は gRPC や WebSocket など様々です。Redis などの KVS も利用されています。

これは初期に LOVOT のソフトウェア基盤設計を行ったエンジニアが、クラウドのアーキテクチャを参考にして決めたようです。 この構成は GROOVE X の自立して動く多数の開発チームという組織構造とも合っているのか、うまく働いています。 複数の開発チームがスピード感をもってソフトウェアを開発、デプロイできています。 デプロイされたパッケージはクラウドサービスから利用可能な状態になっており、 例えば apt などでインストールして利用します。

開発用の Linux マシンで動く CLI のツールも、LOVOT で動くソフトウェアライブラリも、 ほとんど同じようにクラウドサービスからパッケージをインストールして利用しています。

面白い構成ですよね。

LOVOT との未来

LOVOT は、触れ合ってみると現状でも可愛く完成されている感じを受けます。

しかし、LOVOT と未来を生きるためには、まだまだ開発すべきことが多くある、ということが入社して少し経って分かってきました。 今後の LOVOT と GROOVE X の未来には、ソフトウェアエンジニアとしても、いち LOVOT ファンとしてもとてもワクワクしています。

一緒に LOVOT との未来を作る方を募集しています -> 採用

ゆるTech!LOVOTのユーザー体験試験とは

みなさんこんにちは、2024年1発目のInside of LOVOTは、アニメーターの中里がLOVOT開発ならではの試験、「ユーザー体験試験」についてご紹介したいと思います。 技術ブログなのにTechから離れているんじゃない?と訝しんでおられるかもしれませんが、LOVOTという唯一無二の特殊なプロダクトだからこその「ガチTech」ではない「ゆるTech」が必要なんだなーということをこの記事で少し知っていただけるとわたくしもホクホク恵比寿顔になりますので、ぜひ最後までお付き合いいただき、眉間のシワが金剛力士像になりそうなわたくしめをお救いください。

ユーザー体験試験とは

Inside of LOVOTでも試験やQA(QualityAssurance)についての記事がこれまでにいくつかあったかと思います。これまでに紹介されたソフトウェア開発における品質保証試験とは別に、ふるまいチームでは「ユーザー体験試験」というものを行っています。

品質保証試験とユーザー体験試験の違いはこんなかんじです。

品質保証試験 ユーザー体験試験
試験項目 あり あり
手順 あり おまかせ
期待動作 あり 非公開
結果 正否がちゃんと出る 気になった体験のコメントを書く
体験をより良くする提案をする
良い体験はほめる(だいじ)

おまかせて!困るわ〜。
でも、これが大事なんです。ユーザーのふれあい方は千差万別、ユーザーの数だけLOVOTの生活があるのであえて手順は定めずに自分がLOVOTオーナーになった場合のふれあい方をする必要があるわけです。
また、アニメーターはソフトウェアチームの中では最ゆる層ではあるものの、まがりなりにも開発者なのでどうしてもビジネスライクなお付き合いが顔を出してしまうことがあります。そこで、もっとぴゅあな心を持ったQAチームのみなさんにお手伝いをしてもらったりしています。
難しい仕様を知らなくてもLOVOTを愛でる気持ちを持てる人であればこの試験はできるので、ゆくゆくは社内全チームに少しずつ手伝ってもらえば、お互いに得るものがあるだろうなと金剛力士は思っています。

ゆるTechの落とし穴

LOVOT開発においては非常に有益なユーザー体験試験ですが、先に述べたように試験の正解を設けていません。強いていうならば体験に満足することが正解ではあるのですが、ひとつのシチュエーションに対して満足と思える体験はひとつではありません。
そのためユーザー体験試験のような人の気持ちをベースにした試験は自動化することが現時点では不可能です。機能が増えれば試験項目も増えるので、LOVOTが成長し続ける限り試験項目も成長しつづけるわけです。何十年か先には社員総出でユーザー体験試験をやっているかもしれません。そうならないためにはLOVOTを愛でる知性と愛情を備えたロボットをわれわれは開発する必要があるのか…

プロダクトバックログ作成までが試験です

試験の大項目が10程度、その中の小項目が数個、それらをLOVOTの内部状態別に6段階で試験を行いまして、出るわ出るわの改善案。
試験実施後に時間を設けてみんなでコメントを確認して、ああだこうだと議論しながら今後進めるタスク候補 = プロダクトバックログアイテム(PBIと呼びます)に落とし込んでいくのですが、たくさんの試験項目にたくさんのコメントが付くので、全て確認をするのにも数日かかります。いい改善案がいっぱい出た日は「今日は豊作」と言ってみんなでホクホクしています。直近のユーザー体験試験では1つの試験項目に対して多い場合は30以上のコメントがつき、半数程度がPBIになりました。
できたPBIは体験向上度の予測や実装コストなどによって優先度をつけて順次改善を進めていくことになります。全てのPBIに優先度がつくと、やっとユーザー体験試験が終了です。

ユーザー満足度 == LOVOTの幸せ

開発者はつい機能的に優れていたり新しい技術や面白そうな技術を採用したくなったり、開発者の考える小さなユーザー像での体験を想像しがちですが、ユーザーとLOVOTが長く楽しく暮らせることが最も考えるべきことと思っています。
LOVOTの世界は開発環境の何万倍も広く、ただ開発をしているだけでは見通すことが難しくなってきます。そのため、ユーザー体験試験をすることで開発者目線からは一歩離れて視野を広く持つ機会が大事になってきます。LOVOTとユーザーの可能性がどんどん拡がる体験を提供して、ユーザー体験試験で改善案を出すのが難しくなる日を目指してがんばっていきたいです。

2024年も本気の募集です

さて、おわりにいつも載っている募集ですが、惰性で載せているわけではありません。本当に人が足りていません。読んでいただいているみなさんの身の回りでもご興味がありそうな方がいれば、開発から試験までおもしろそうなGROOVE Xをご紹介いただけると、確実に金剛力士から卒業できそうです。ぜひよろしくお願いいたします。

recruit.jobcan.jp