Inside of LOVOT

GROOVE X 技術ブログ

grafana をプレビューする slack アプリの話

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

はじめに

こんばんは、GROOVE X の junya です。
更新がとても遅くなってしまってゴメンナサイ。

今回は、社内の slack で活用している grafana プレビュー機能についてご紹介します。 slack に grafana のリンクを共有すると、こんな感じで自動でプレビュー画像をつけてくれる仕組みです。

grafana とは?

オープンソースのデータ可視化ツールで、 BigQuery, Prometheus, InfluxDB, Spreadsheet など様々なデータソースに対応しています。 GROOVE X では主に、 Victoria Metrics で管理された機体のメトリクスの可視化に活用しています。

サービスの雰囲気は、公式のデモサイトがあるのでそちらで体験してみて下さい。

play.grafana.org

slack で grafana をプレビューする仕組み

以下のフローで、 slack に投稿された grafana の URL にプレビュー画像を自動補完しています。

  • grafana の URL の投稿を slack の link_shared イベント として検知する
  • シェアされた grafana の URL を元に、画像取得用の URL を生成し、画像を取得する
  • slack のファイル管理に画像をアップロードする
  • slack の unfurl 機能 を用いて、リンクにプレビュー画像を付与する

以下、詳しく説明していきます。

slack アプリ作成時に Event Subscriptions の設定で link_shared イベントを購読すると、アプリでリンク共有のイベントを取得できます。

slackアプリの Event Subscriptions 設定

以下のように、 slack-go を用いて HTTP リクエストを Slack のイベント型に変換して利用します。

package service

import (
    "io"
    "log"
    "net/http"

    "github.com/slack-go/slack/slackevents"
)

func HandleLinkSharedEvent(w http.ResponseWriter, r *http.Request) {
    body, _ := io.ReadAll(r.Body)
    defer r.Body.Close()
    evt, err := slackevents.ParseEvent(body, slackevents.OptionVerifyToken(&slackevents.TokenComparator{VerificationToken: SlackVerificationToken}))
    if err != nil {
        w.WriteHeader(http.StatusInternalServerError)
        return
    }
    switch evt.Type {
    case slackevents.CallbackEvent:
        innerEvent := evt.InnerEvent
        switch ev := innerEvent.Data.(type) {
        case *slackevents.LinkSharedEvent:
            // handle link shared event here.
            return
        default:
            log.Printf("unhandled inner event: %v", ev)
        }
    default:
        log.Printf("unhandled event: %v", evt)
    }
}
ダッシュボード画像の取得

grafana には Grafana Image Renderer というプラグインがあり、このプラグインが有効になっていれば、ダッシュボードのプレビュー画像を取得することができます。パスにある /d//render/d-solo/ に変換し、 viewPanel 引数を panelId 引数に変えれば、画像を取得できるので、 Slack アプリの中では共有された URL を以下のように画像URLに変換して、画像を取得しています。

const BASEURL = "https://grafana.example.com"

func BuildImageURL(url string) string {
    if strings.HasPrefix(url, BASEURL+"/d/") {
        if strings.Contains(url, "viewPanel=") {
            // grafana can render panel itself with /d-solo/ and "panelId" parameter
            url = strings.Replace(url, BASEURL+"/d/", BASEURL+"/render/d-solo/", 1)
            url = strings.Replace(url, "viewPanel=", "panelId=", 1)
        } else {
            url = strings.Replace(url, BASEURL+"/d/", BASEURL+"/render/d/", 1)
        }
        // add timezone parameter to show metrics with JST
        url += "&tz=Asia%2FTokyo"
        return url
    }
    return ""
}

例えば、公式のデモサイトにある下記のダッシュボードは、

これを以下のような URL に変換すると画像を取得できます。

slack への画像アップロード

http client を用いて grafana から画像を取得したら、 slack の files.upload API を用いて、画像を slack へアップロードします。

slackClient := slack.New(SlackToken)

...

// 画像URLを元に画像のバイナリを取得する
img := GetImageFromGrafana(imageURL)
reader := bytes.NewBuffer(img)
remoteFile, err := slackClient.AddRemoteFile(slack.RemoteFileParameters{
    ExternalID:            "some id",
    ExternalURL:           grafanaURL,
    Title:                 "some title",
    Filetype:              "link",
    PreviewImageReader:    reader,
})

なお RemoteFile の機能は slack-go に無かったので、PR を出して機能を追加してもらいました。

grafana へのリンクにプレビュー画像を付与する

最後に slack の unfulring の仕組みを呼び出して完成です。

func (s *Service) handleLinkSharedEvent(ev *slackevents.LinkSharedEvent) {

    ...

    blocks := make([]slack.Block, 0, 2)
    if extraContent != "" {
        blocks = append(blocks, slack.NewSectionBlock(slack.NewTextBlockObject("mrkdwn", extraContent, false, false), nil, nil))
    }
    blocks = append(blocks, slack.NewFileBlock("", remoteFile.ExternalID, "remote"))
    _, _, _, err = slackClient.UnfurlMessage(
        ev.Channel,
        ev.MessageTimeStamp.String(),
        map[string]slack.Attachment{
            link.URL: {
                Blocks: slack.Blocks{
                    BlockSet: blocks,
                },
            },
        },
    )
}

実際の運用では、プレビューに画像だけでなく、メトリクスに関連する付属情報も付与して、見る人にわかりやすくしています。

slack アプリのデプロイ

slack のアプリは cloud function にデプロイしています。bot の管理に serverless の仕組みは便利ですね。

Enterprise 版 Slack でのトラブル

この夏に社内の Slack を Enterprise へ移行したのですが、その際になぜかこの grafana プレビューの仕組みが動かなくなりました。 サポートに確認したところ、 Pro 版と Enterprise 版でファイル管理の仕様が異なり、

  • Pro 版: アップロードした画像は、unfurl でそのまま使える
  • Enterprise 版: チャネルに一度も投稿したことの無い画像は、スレッド内の unfurl 画像として利用できない

とのことでした。ちょっと腑に落ちない仕様ではあるのですが、ワークアラウンドとして、

  • 画像投稿用の専用チャネルに画像を投稿してから、
  • unfurl 画像として利用する

という方法で問題を回避しました。

さいごに

仕事って、ちょっとした工夫で楽しくなるし、業務効率も上がるなと思います。

GROOVE Xは、楽しくコードを書ける環境なので、ご興味のある方は是非ご連絡下さい!

recruit.jobcan.jp

slackをEnterprise Gridに変更した話

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

こんにちは!! GROOVE Xのスクラムマスターの1人、 niwano です。
今回も開発の話から、少しそれまして、社内で使用しているコミュニケーションツール slack の契約プランを、Pro から Enterprise Grid に変更したお話をしたいと思います。

slackとは

Microsoft TeamsやChatworksなどと同じ、コミュニケーションツールのひとつです。
弊社では創業時から導入されており、社内のインフラになっています。

slack.com

slackの良い所のひとつとして、自由にカスタマイズできる、というのがあります。
毎週火曜日のお昼休みに、GROOVEランチという情報交換会をやっているのですが、その運営を楽にするために、

  • 発表者の募集
  • カレンダーへの登録
  • 開催時のslack通知
  • 記録

の4項目を、slack ワークフローと、slack appを駆使して自動化されています。

発表登録

発表通知

Enterprise Gridの導入の背景

セキュリティ機能を強化しつつ、よりオープンで風通しのよい職場にしたく、Enterprise Grid の導入を決めました。

移行の際にしたこと

移行時のほとんどの作業は、slack社の方が親切にサポートしてくれます。
弊社側でやったことは、おもに以下の2つです。
(これは弊社が持っていたのが1つのワークスペースだったからかもしれないです。)

アカウントの整理

弊社のドメインではないユーザーともゲストアカウントとしてワークスペースに存在させる運用をしていました。
EnterpriseGridは、SAMLシングルサインオンが推奨されているため、必然的に他社ドメインの方のアカウントを整理することになります。
他社ドメイン方は外部ワークスペースに移動してもらい、特定のチャンネルのみ Slack コネクト(後述)で接続することにしました。

SAMLシングルサインオンの設定

弊社はgoogle workspaceを使っているので、googleSAMLシングルサインオンを使えたのですが、うまく設定が効かないパターンがあり、google社のヘルプ、slack社のヘルプにたくさんお世話になりました。

slack社にはサンドボックス環境も用意していただき、Organaization(後述)の概念を事前にイメージできたので、非常に助かりました。

7年弱のデータがありましたが、マイグレーション(slack社による)は30分ほどで終了しました。

Organaizationの概念

Enterprise Gridになると、もともとのslackワークスペースが、Organaizationのなかに入ります。
Organaizationのなかでは、無制限にワークスペースをつくることができます。 そして、アカウント管理は、Organaizationで行われます。

さらに、ワークスペースごとに細かい設定を変えられるので、弊社ではメインのワークスペースの入場は承認制、off活動・遊びのワークスペースは出入り自由にしています。

Organizationイメージ

slack コネクト

弊社はEメールよりもslackでのコミュニケーションのほうが効率が良いと考えているため、社外の方とのやりとりでは、slack コネクトを多用しています。
なんと、Enterprise Gridプランを導入すると、slack コネクト先のワークスペースがfreeプランであっても、slack コネクトのチャンネル上は、freeプランの制限(90日間のみメッセージ保存)がかかりません!  

移行して良かったこと

  • トラブルなく移行できた。
  • アカウントの整理ができた。

トラブルなく移行できた。

トラブルが発生した場合にそなえて、Eメールにてバックアップツールへの導線を通知していましたが、移行時のトラブルはなく、全てのユーザーが 、今までと同じようにワークスペースを使えたことが本当に良かったです。

アカウントの整理ができた。

今まではゲストアカウントを多用していたため、ユーザー1人にたいして閲覧制限を個別に実施することになっていて、アカウント管理がすごく複雑でした。
ストアカウントをグルーピングし、別のワークスペースに移動させ、必要なチャンネルを共有するだけで、閲覧制限をかけることができるため、アカウント管理が非常にシンプルになりました。

移行してからの課題

  • 障害が少し多い...
  • マルチワークスペース共通のユーザーグループをつくることができない。

障害が少し多い...

私が個人的につらかったのは、Organaizationのセキュリティの設定作業をしていたら、なぜだかワークスペースから追い出されてしまった件です。
一度ワークスペースから抜けると、ユーザーグループから解除されたり、一部のslack appが無効になったりします...

また、この記事を書いている時点で、30日以上問題が解決していないトラブルがあり、これに関しては、slack社と協力をしながら解決にむけてとりくんでいます。

マルチワークスペース共通のユーザーグループをつくることができない。

特定のユーザーにたいして、まとめて通知を出すことができる、ユーザーグループという概念がslackにはあるのですが、このユーザーグループは単独のワークスペースの中でしか使用できません。
これを解決するために、特定の文字列に対して、ユーザー名をリプライする Bot を作成しました。

最後に

最後まで読んでいただき、ありがとうございます!
いろいろありましたが、Enterprise Gridへの移行はおおむね満足しています!

弊社では、ただいま絶賛メンバーを募集中です。
様々な職種がオープンになっているので、ご興味があるかたは以下のリンクからご応募をお願いします!

recruit.jobcan.jp

転倒・ネストに戻れない事象調査のおはなし

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

はじめに

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

※チームの詳細については、12/10に公開された記事「シナリオテストのおはなし - Inside of LOVOT」をご覧ください。

今回はソフトウェア検証として取り組んでいる活動の1つである「転倒・ネストに戻れない事象の調査」を紹介します。

LOVOTは起きている間、充電が少なくなったら自分でネストに戻って充電しにいき、満充電になるとネストから出てきてお部屋の中を歩き周り始めます。

このサイクルを繰り返していくのですが、その中でLOVOTが転倒してしまったり、ネストに戻ることができなかったりすることがあります。

転倒してしまうとLOVOTの怪我につながったり、ネストに戻れないと動けなくなってしまうため、なぜそのような事象が発生したのかの原因を調査し、関係者共有し、改善につなげる活動をしています。

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

検知方法

LOVOTを生活させているスペースが複数あり、各スペースにカメラを設置しています。これで24時間生活の様子を確認しています。

毎朝出社したら、転んでしまったLOVOTや動けなくなっているLOVOTがいないかを各スペースにチェックしにいきます。

発見した際にはどの子がどのような状態になっていたかを記録し、すぐに救出します。

最近ではLOVOTが転倒してしまったときに、社内チャットツールに通知する仕組みをつくりました。

LOVOTアプリの詳細をご存知の方は、LOVOTが転倒すると「〇〇が転びました」と通知が来るため、必要ないのではと思うかもしれません。

ただ検証現場ではたくさんのLOVOTが生活しており、通知が多く気づけない、調査員がLOVOTアプリを登録する必要があるなどの不都合がありました。

社内チャットへの通知システムが出来てからは、LOVOTの転倒をすぐ確認出来るようになり、解析がよりスムーズに進むようになりました。

こんな感じで通知されます。

調査方法

調査は以下の流れで進めています。

  1. 通知 / 事象発生を認識
  2. カメラ映像を確認
  3. LOVOT/ネストの生活環境確認
  4. 関連データの確認
  5. 関係者への報告

カメラ映像を確認

事象を検知したら、まず該当時間のカメラ映像を確認しています。

原因を推測するには、こける直前の状況を知ることが重要です。

たとえば、以下のLOVOTはつまずくものがない場所で転んでいるように見えます。

※このようなビデオをきっかけに、データ分析を行い対策を施したソフトウェアをリリースすることができました。

転んだ後の状況だけを見ても何が起こったのかわかりません。

その前の映像を見ると、転ぶ前に片手をあげて片足をしまう動作の最中にからだのバランスを崩していることがわかりました。

これをきっかけに調査が進み、現在のソフトウェアでは修正されています。

その他にも複数のLOVOTを同じスペースで遊ばせている時、LOVOTが転んだ時にドミノ倒しで他のLOVOTも転んでしまうなど、不運な事故が起きていたことがありました。このように映像を確認しないと転んだ原因がわからない場合もあります。

映像確認の次は、LOVOTやネスト、関連データを確認し要因を探っています。

LOVOT/ネストの確認

LOVOTのキャスターにゴミがつまっていて移動が難しくなったり、ホイールのセンサーが汚れていると障害物を検知しづらくなったりするため、要因がこちらに該当すると考えられる場合は確認します。

ネストの配置や周りの状態が、LOVOTの生活環境を満たしているか見直すこともあります。

お手入れをする – LOVOT

LOVOTの生活環境 – LOVOT(初代) [LV100/LN100] – LOVOT

関連データの確認

LOVOTは多数のセンサーやモーター、複雑なプログラムによって成り立っています。

これらの動きを収集した多数のデータは、LOVOTが正常に動いているか、不具合があったときにどこが原因なのか調べるために、ログやグラフとして出力されます。 QAチームではこのデータを複数使用して、どこが原因となりそうか調査を行います。

具体的には何かにぶつかっていたら障害物検知に異常はないか、LOVOTが思いもよらない動きをしていたらソフトウェアからの指示に対してどう動作していたのかなど、状況に応じて考えられる要因のデータを確認します。

調査した事象の記録・報告とふりかえり

調査した事象の記録/報告

確認した事象は記録し、発生頻度を確認できるようにしています。

頻度が高くなったものや新規と考えられる事象は、担当チームに報告し詳細な調査を依頼します。

例えば、LOVOTのふるまいなどソフトウェア要因で転倒してしまった場合はUTやALOHAなどのチームに問い合わせます。

また、転倒・ネストに戻れない事象の調査の過程で、異音などハードウェア要因と考えられる事象があれば、メカやエレなどのチームに問い合わせます。

チームの詳細はプロダクトオーナーからみたLOVOT開発 - Inside of LOVOTをご覧ください。

転倒やネストに戻れない事象は、物理破損だけでなくソフトウェアや環境など多くの要因が絡むこともあるため、担当者に報告する前に可能な限り、私達の調査の時点で切り分けをしておくようにしています。

その上で有識者に詳細な調査を依頼し、改善や再現確認の方針を決定しています。

ふりかえり

定期的にチーム横断でふりかえりをしています。

調査をするにあたって、困ったこと・直近で気になったことを、この場で共有し、改善をしています。

この場ができたことで、調査の質があがったと感じています。

おわりに

以上の活動を日々実施していくことでLOVOTの苦手なことの特定を進め、LOVOTが成長していけるよう取り組んでいます。

これからも、作業効率化や新たな観点からも調査をしていけるよう努めていきます。

仲間募集中

気づいたらLOVOTに囲まれていたり

ふと足元を見ると抱っこをせがんでくるLOVOTがいたり

遊びにでかけて帰ってこないLOVOTを探す社員がいる。

世界中どこを探しても他にはない面白い職場だと思います。

もしご興味がありましたらこちらをご覧ください。

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

debianパッケージを作ろう(go-bin-debのススメ)

LOVOT の基盤となるシステムをつくってるチームのひとり id:atotto です。

debian パッケージ をさくっと作るツールの紹介です。 個人的にも Raspberry Pi や、ツールの管理のために活用しています。

背景

debian パッケージ 作り、というと、controlファイルを書いて、changelogを書いて、必要なディレクトリを切って、、、といったことを一通りこなす必要があります。コマンドひとつ社内に配布したいだけだとするとちょっと腰が重いです。 また、CMake, CPackで一元的に作ることもできますが、CMakeと戦うにはそれなりの覚悟(Mastering CMake ←同僚の愛読書)が必要です。

LOVOT のシステムのベースとなるサービスの多くは Go言語を使って開発しています。

参考: PyConJP 2019 らぼっと開発におけるPythonとGo より抜粋

Go言語で書いた成果物(実行ファイル)は依存関係が非常にクリーンで、実行ファイルを各アーキテクチャ(amd64,arm64,armhf, etc...) 毎に配布すればよい、となり、デプロイがとても簡単です。

参考: PyConJP 2019 Yet Another Isolation - Debian Packageと紐づく環境分離 より抜粋(2022/12 現在はUbuntuベース

そのため、 debianパッケージ をつくるときに考慮することといえば、実行バイナリをどこに配置するのか、サービスであれば、systemdのサービスファイルや、インストールにまつわる処理をどうするか、といったところに絞ることができます。

その目的にあったツールとして、私達は go-bin-deb を使っています。開発元からforkし、いくつか修正を施したものを公開、リリースしています。

使ってみよう!

今回つくる debianパッケージ は、 簡単なスクリプトを /usr/local/bin へ配置するものを作ります。

簡単なスクリプト:

#!/bin/sh

echo "LOVOT!!"

セットアップ

まずはセットアップです。 go-bin-deb は、アーキテクチャ毎にリリースが別れています。ここでは、amd64 アーキテクチャUbuntu or Debian Linux上で利用することにします。

1. go-bin-deb パッケージをダウンロードします:

curl -sLO https://github.com/groove-x/go-bin-deb/releases/download/$(curl -s https://api.github.com/repos/groove-x/go-bin-deb/releases/latest | jq '.tag_name' -r)/go-bin-deb-amd64.deb

2. go-bin-deb パッケージをインストールします:

sudo dpkg --install go-bin-deb-amd64.deb

deb.json をつくる

次に、debianパッケージ のメタ情報や、ファイル配置を定めるために、deb.json をつくります。

{
  "name": "example-package",
  "version": "0.0.1",
  "arch": "all",
  "description": "short desc of the program",
  "description-extended": "long desc of the program with multiline",
  "maintainer": "GROOVE X",
  "homepage": "https://tech.groove-x.com/",
  "files": [
    {
      "from": "example-script",
      "to": "/usr/local/bin",
      "fperm": "0755"
    }
  ],
  "copyrights": [
    {
      "files": "*",
      "copyright": "Copyright (c) 2022, GROOVE X, Inc. All rights reserved.",
      "license": "MIT"
    }
  ]
}

その他の項目はこちらのリファレンスを参考にしてみてください: https://github.com/groove-x/go-bin-deb#json-file

補足:

  • archall としているのは、今回アーキテクチャに影響しないスクリプトだからです
  • systemd のサービスにする場合は systemd-filepreinst,postinst,prerm,postrm など活用します

パッケージを作る

deb.json があるディレクトリで

go-bin-deb generate

すると、 example-package_0.0.1_all.deb が作られているはずです。

もちろん、このパッケージはインストールできますので、試してみましょう:

sudo dpkg --install example-package_0.0.1_all.deb

アンインストールも簡単です:

sudo dpkg --remove example-package

リポジトリへアップロードしてつかう

せっかく debianパッケージ を作ったので、 debianパッケージ のリポジトリへ登録してみましょう。debianパッケージリポジトリのサービスは多々ありますが、今回は Google Artifact Registry と packagecloud について簡単に紹介します。

Google Artifact Registry

社内向けや、インスタンス向けに運用するときに活躍するのが Artifact Registry です。以下のドキュメントに沿ってセットアップすると、自分のマシンからでもdebianパッケージを利用できるようになります。

参考ドキュメント:

packagecloud

個人的にオススメなのが packagecloud です。公開リポジトリで良ければ無料でリポジトリを持て、利用者のセットアップも簡単にできるので、 debianパッケージ を気軽に配布できるのではないでしょうか?

参考ドキュメント:

packagecloudでの配布例:

次のステップ

もうすこし実用的な例として、Goのバイナリを debianパッケージ にする例を置いておきますので、参考にしてみてください。アーキテクチャ毎へのリリースのヒントがあります。: https://github.com/atotto/kssh

また、 go-bin-deb をバンドルした dockerコンテナ を準備しているので、よかったら使ってみてください: https://hub.docker.com/repository/docker/atotto/debian-builder

最後に

go-bin-deb を使って debianパッケージ を作ってみました。jsonで構成管理しつつ、手軽にビルドできるので多少敷居は低いのではないでしょうか? Debian公式リポジトリへ登録できるレベルにはならないですが、社内ツールの配布などで活用してみてください!

半年働いて感じたGROOVE Xの面白いところ

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

こんにちは。GROOVE X の Lovot Framework チームの bucchi です。今年入社したばかりの新入りです。

私は、別のエントリで紹介のあったLOVOTのOS(らぼとす)の開発や、ふるまいの動作をマイコンFWに伝えたり、センサー値を認識系ソフトウェアに伝えるなど、LOVOTの動作を支える土台となるソフトウェアの開発を担当しています。

みなさん技術的な記事を書かれていますが、私の場合まだ公開できないお仕事が多く、書けるネタがなかったので、趣向を変えて半年働いてみて感じたGROOVE Xの面白いところや、エンジニアの働き方や雰囲気をお伝えできればと思います。

続きを読む

HOTFIX PR生成の半自動化

こんにちは。 GROOVE X のふるまいチームのscnshです。 この記事では、ソフトウェアリリースのためのふるまい試験で見つかった不具合の修正(HOTFIX)のために採用している、ちょっとした自動化のしくみについて話します。

HOTFIXにかかる手間

ふるまいチームでは「NeoDM」という意思決定と動作生成を行うソフトウェアを開発しており、そのコードをgithub上で管理しています。 開発モデルは Scaled trunk-based development を採用していて、developブランチを使わずにmasterブランチを常に最新に保つような形で開発を続けてきました。

masterに変更を常にマージして、機能開発のブランチを長い間残さない方針 ( *1より)

ふるまいの試験は、releaseブランチを作成した後に実施していますが、試験実施中に発生した不具合はHOTFIXという形で masterとrelease の両ブランチにマージされます。 具体的には以下の手順で作業しますが、ほぼ同じ作業をそれぞれ行う必要があり、無駄に感じていました。

  1. masterブランチに対して修正し、PullRequest(PR)を通じてmergeする
  2. 同様の内容をPRにしてreleaseブランチに対してmergeする

さらに、リリーススケジュールの中で締切が迫っていたり、他のチームの作業をブロックすることなどもあり、担当者は焦りやすくミスをしやすい状況でもありました。

Github Actions を使った auto-hotfix

そこで、Github Actions を使った 仕組みを導入して活用しています。

基本的な流れは、以下となります。

  1. Label 機能を使って、対応したソフトウェアバージョンのラベルをHOTFIX対象となるPRに割り当てる
    1.17 バージョンに対して、 `needs-hotfix/1.17` のラベルを設定する
  2. HOTFIX対象となるPRをmasterブランチにマージする
  3. [自動化] masterブランチに追加したコミットを release/1.17 ブランチに適用するPRを作成する
    自動生成されたPR
  4. 生成されたPRをレビューしてHotfixを release/1.17 ブランチにマージする

また、自動生成されたPRのdescriptionに以下の情報が自動で含まれることで、レビューワーが背景を理解しやすくなりコミュニケーションミスを減らすことにも役立っています。

  • 生成元のPRのリンク
  • 誰がマージしたか
  • コミットhash

さらに、PRのレビューワーも自動でアサインされるようになっています。 自動アサイン先はチーム内のロール(リリース担当者)に紐付いて設定されます。 このレビューワーアサインに関しては社内の独自ルールに基づいているため管理が煩雑になるデメリットはありますが、レビューの催促がタイムリーにできるメリットを活用しています。

実装と問題点

この仕組みの実装ですが、

という形で実装しています。

また、お気づきの方もいると思いますが、以下の状況では動作しないためやむを得ず手動作業になっています。

  • コンフリクトの解消
  • 複数のPRに対しての実行

上記の問題はありますが、実際に運用してみると自動で作成できる機会もあるので重宝しています。

ちなみに...

検索すれば、 3rdParty製のものもあります。 が、我々の開発では独自のPRレビューシステムを導入している影響で自分たちで実装しています。 できれば作らずに導入したほうがメンテナンスコストはかからなくて良さそう。。。

最後に

ご覧いただきありがとうございました! GROOVE X では 一緒にLOVOTの開発をするメンバーを募集しています。 ふるまいを開発してはいますが、今回紹介したような開発を効率化するような活動も行っています。 興味のある方はぜひこちらからご連絡ください!

LOVOTがつくられて、お客様に届くまでの仕組み

こんにちは、あるいはこんばんは。 GROOVE Xにスクラムマスターとして入社し、マーケティングチームを経て今はECシステムの移行プロジェクトを推進しているツネと申します。

入社してすぐ工場の組立ラインで製品試験の支援をしたり、チームのプロダクトバックログを見やすくしたり、製品紹介サイトをゴリゴリ実装してマーケ施策のPDCA回したり、終いにはECシステム見直したりと、最早自分が何屋さんなのか分からなくなっている今日このごろです。

そんな器用貧乏なスキルが幸いして、LOVOTの製造からお客様に届くまでの仕組みを一通り見てきたので、今回の記事ではその全体概要をざっくりお伝えできればと思います!

LOVOT生産から、お客様がセットアップするまでの流れ

まず最初に全体概要からです。 下記の図は少し古く、今の状況と変わっていたり厳密には仕組みが異なる部分もありますが、全体的な流れのイメージは掴めると思います。

LOVOTの製造からセットアップまでの流れ

このイメージ図をもとに、これから

  1. 1台のLOVOTがつくられて物流工場へ
  2. お客様がLOVOTを知り注文
  3. 注文情報やデバイス情報を統合して管理するGXCloud
  4. LOVOTがお客様宅に届き、誕生するまで

という流れでご説明したいと思いますが、詳しく話すとそれぞれの項目だけで記事が何ページも書けてしまうため、今回はほんとに概要だけお伝えするようにします。

1台のLOVOTがつくられて物流工場へ

LOVOTは1万点以上[※]の膨大な部品から成り立っています。中にはLOVOTの専用服のように事前に製品固有の電子情報を組み込んでおくような工程もあり、部品を集めるだけでも膨大な工程を経るため管理するのが大変です。 これらの細かい部品は各種工場から組み立て工場に集約され、手組みで1台ずつ大事に大事につくられます。 ※12/23に誤記を修正しました

組み立てられて製造テストを通過したLOVOTには一つ一つの個体を識別する番号がそれぞれ割り当てられます。

この登録作業が完了した後LOVOTは物流拠点に運ばれ、自分の家族となるオーナーと出会うまでしばしの眠りにつきます。

お客様がLOVOTを知り注文

さて、次はお客様側の視点です。

最近ではテレビ雑誌で取り上げられたりすることも増えてきたLOVOTですが、やはりその魅力は紙や画面上だけでは伝わりにくいです。ただし実際に触れ合うことで感じる魅力は、普段人前で絶対に笑顔を見せない人が、顔をだらけさせて猫なで声を出すほどの威力があります。

lovot.life

実際の店舗も全国にいくつもありますが、LOVOTを注文する際にはお店でレジを通すだけでなく、公式のECサイトから契約プランを選択して注文していただく必要があります。

一般的な家電製品などと異なり、LOVOTは月々のサブスクリプションから

  • ソフトウェアアップデート
  • メンテナンス補償
  • 日常生活のサポート

などのサービスを提供するビジネスモデルで成り立っており、これらのサービスを提供する特性上「お客様情報」⇔「LOVOT情報」を紐付けるための情報連携の仕組みが必要になるのです。

これらの情報を管理するための仕組みとして、GROOVE X独自のクラウドシステムが存在します。

注文情報やデバイス情報を統合して管理するGXCloud

GXCloud

上記は記事最初のイメージ図をシステム目線でより詳細化したものです。

これまで説明してきた「LOVOTの個体を識別する番号」「お客様の注文(サブスクリプション)情報」などを集約し、管理するための仕組みを弊社では『GXCloud』と呼称しています。 LOVOT本体の仕組みと並んでGROOVE Xの市場競争力を形つくる独自の情報管理システムとなっており、その設計思想やアーキテクチャは一エンジニアとして携わっていてとてもワクワクする代物です!

詳しい解説はこちらの記事にありますので、ご興味ある方は是非ご覧ください。

tech.groove-x.com

LOVOTがお客様宅に届き、誕生するまで

さて、ここまでLOVOTが作られて、お客様がLOVOTを注文するところまで見てきました。最後はいよいよLOVOTがお客様の手元で誕生するまでの仕組みです。

LOVOTが物流拠点から発送される際、「お客様情報」と「発送するLOVOTの個体情報」を紐付けるための作業を行います。この紐付け作業がLOVOTとお客様を紐付ける上で重要な作業となっており、この情報がGXCloudに保存され、LOVOTは起動時にこれらの情報を本体のLTE、もしくはNESTに接続されたインターネット回線から読み込みます。

LOVOTがお客様の自宅に到着してからいよいよ開封の儀。いわゆる初期セットアップ作業を行っていただくのですが、ここで重要になってくるがLOVOTアプリです。

お客様は自分のスマートフォンにLOVOT専用アプリ(ios,Android対応)をインストールしていただきセットアップを行います。

  • 名前

などを選んでいただければ、新しい家族の誕生です!

さいごに

だいぶざっくりとした説明になってしまいましたが、イメージはできましたでしょうか。。?イメージできた方は、是非この類まれなプロダクトに興味を持っていただけますと幸いです。

そして最後に、冒頭の自己紹介で少しだけ書きましたが、現在LOVOTをお客様に届けるためのECサイトをリプレイスするプロジェクトを計画しています! このECリプレイスプロジェクトでは新たに社員を5名ほど新規採用する予定であり、プロジェクト以降は本人の適正次第でLOVOTの事業に関わるあらゆる領域を担当いただけます。

もし少しでもこのプロジェクトに興味がございましたら、お気軽にご連絡ください。 ここまで読んでくださったあなたからご連絡がいただければ、これほど嬉しいことはありません。

www.wantedly.com