Safie Engineers' Blog!

Safieのエンジニアが書くブログです

タイムゾーンと、Pythonでのその扱い方の注意点

サーバーサイドエンジニアの三村です。

弊社では2024年の初めから国外へサービス展開をする準備として、一年ほど前からシステムの国際化対応を行ってきました。 この準備には、サービスの多言語対応や日本標準時以外のタイムゾーンでサービスが利用できるようにする改修などが含まれますが、サーバーチームでは特に後者に苦労しました。

そこでこの改修で得たPythonでタイムゾーンを扱う際の知見の一部を、このブログ記事にまとめます。

続きを読む

Androidチームにおける品質改善③ 〜2023年のまとめ〜

はじめに

リリースから3年以上経過しようやくモダンな開発環境に近づけていく活動ができるようになるくらい体制が整って来ました。

今回はAndroid版Safie Viewer for Mobileが2023年に行った改善活動の振り返りの話をしたいと思います。

ユニットテストの導入

改善活動の一歩としてユニットテストを導入しました。

ここまでの間テストがないという状況が続いており機能追加やライブラリのアップデートをした時手動でのテストが欠かせない状態でした。

今年からユニットテストを導入したので手動での検証作業が少し緩和されたという状態になりました。

カバレッジ率はまだ約12%というのが現実ですが、来年以降もカバレッジ率を高めていくような活動を続けていきます。

ビジュアルリグレッションテストの導入

ユニットテストに加えRoborazziを使用したビジュアルリグレッションテスト(以下VRT)も合わせて導入しました。

RoborazziはnowinandroidDoroidKaigi2023でも採用されているライブラリで、JVM上でスクリーンショットを撮影し差分比較することのできるライブラリです。

Safie Viewer for Mobileではサンプルを参考にGithubActionsのワークフローを作成し、プルリクエスト上でVRTを実行し差分比較を行えるような環境を用意しました。

プルリクエスト上で差分の確認ができる

Safie Viewer for Mobileは多言語化対応をしており動作確認のため端末の言語設定を切り替えてから対象の画面を表示しレイアウトに問題がないかを確認しておりましたがRoborazzi導入後は自動で言語毎のスクリーンショットを撮って確認する事ができるので、かなりの作業時間の削減に繋がりました。

多言語化対応しているようなアプリであれば非常に強力なライブラリになるかと思います。

github.com

Jetpack Composeの導入

今年からXMLからJetpack Composeにレイアウトの作りを置き換えるという事を始めました。

移行率は10%程度とまだ殆どがXMLでの構成となっておりますが、小さい画面から順にJetpack Composeに置き換えるといった活動をしています。

Jetpack Composeに置き換えて一番大きく感じた利点はテストの書きやすさにあると感じました。

これまで、Activity/FragmentのUI周りのテストを書くのは敷居が高いと感じ実機で手動確認で済ませる事が多かったのですがJetpack Composeであれば

  • 表示のテスト
  • 状態変化のテスト

がかなり簡単に書けるようになったと思います。

developer.android.com

Detektの導入

静的コード解析として、Detektを導入しました。

GitHubActionsで実行したDetektの結果をalaegin/Detekt-Actionを使用して通知する仕組みで運用しています。

目的としては、これまで目視で確認していた「コーディングルールに則って書かれているかどうか」を自動で確認するためです。

その他にDetektの便利なところは、メソッド毎に複雑度の数値「CyclomaticComplexMethod」と「CognitiveComplexMethod」が測れることにあると思います。

今まで感覚的に「このメソッドなんか複雑に感じる」というのを数値で見る事ができるのでレビューの際に指摘しやすくなるといった効果があります。

detekt.dev

Dependabotの導入

今まで手作業で確認していたライブラリのアップデートをDependabotを導入して自動化しました。 手作業で確認していた分の時間がかなり削減されたので開発者体験の向上に繋がりました。

docs.github.com

ビルドスクリプト周りの見直し

ビルドスクリプト周りの改善として以下の事を行いました

  • Groovy から KTSに移行
  • Android Gradle Pluginを7系から8系にアップデート
  • Version Catalogの導入

Androidは今後KTSでビルドスクリプトを書くのが標準なので、それに合わせてSafie Viewer for Mobileも全てKTSに置き換えました。

ついでにライブラリのバージョンもVersion Catalogで管理するようにしましたが今のところ大きな恩恵は受けておらず、これは将来的にマルチモジュール対応などを行った時に効果を発揮することになると思います。

developer.android.com

developer.android.com

便利だったGithubActionsのAction

  • r0adkll/upload-google-play

    GithubActonsからアプリのリリースファイルを作成しGooglePlayConsoleへ自動アップロードする為のActionです。 このActionを導入してアプリのリリース作業を半自動化する事ができました。

  • AlexSim93/pull-request-analytics-action

    PullRequestを解析し

    • オープンしたプルリクエストの数
    • マージしたプルリクエストの数
    • プルリクエストを承認した回数
    • マージまでに掛かった時間

    などのレポートを出力できるActionで、取り急ぎこれまでのプルリクエストの状況を確認したかった事があったので便利でした。

    執筆時のバージョンは1.8.4ですが、頻繁に更新されているライブラリで日に日に新機能が追加されて行っているのが特徴的です。

github.com

github.com

最後に

2023年は改善活動に力を入れた1年でした。

1年かけて様々なものを導入して来ましたが、まだまだ改善していきたい箇所が多く継続的に改善活動を続けていく必要があります。 日々の改善活動を通して、チームとして力を伸ばしていきたいと思います。

また、セーフィーではエンジニアの採用を積極的に行っております。もし興味が出てきた際はぜひご応募いただけたらと思います。

safie.co.jp

SOTAセグメンテーションモデル PP-MobileSeg をSNPEで動かす

はじめに

セーフィー株式会社の AI Vision グループでテックリードを務めます橋本貴博です。セーフィーの一部のAIネットワークカメラは、Snapdragon Neural Processing Engine(SNPE)をランタイムに使ってエッジ推論を行っています。この記事では、SOTA セグメンテーションモデル PP-MobileSeg を SNPEで動かす方法を解説したいと思います。

PP-MobileSegとは?

PP-MobileSeg は、2023年4月に発表された、モバイル向けセマンティックセグメンテーションのSOTAモデルです。ADE20Kデータセットで学習がなされており、既存モデルと比較して低レイテンシ、かつ、認識性能(mIoU)が高いことが分かります。論文は こちら (arXiv) から読めます。

引用元: [PaddlePaddle/PaddleSeg (GitHub)](https://github.com/PaddlePaddle/PaddleSeg) / Apache License 2.0

引用元: PaddlePaddle/PaddleSeg (GitHub) / Apache License 2.0

モデル変換

大まかな流れ

PP-MobileSegのPyTorchモデルをONNXモデルに変換します。ONNXモデルで移植性向上のためのノード編集を行なった後、ONNXモデルからSNPEのネイティブフォーマット(DLC形式)に変換します。

PyTorch から ONNX への変換

mmsegmentation リポジトリ v1.1.2 で 公開(2023年9月)されている PP-MobileSeg-Tiny の PyTorchモデルを利用します。はじめに、Get started: Install and Run MMSeg を参考に環境構築を済ませておきます。 公式マニュアル に記載の手順にしたがって作業すれば、PyTorchモデルからONNXモデルに変換できます。

ONNX モデルの修正

ONNXモデルで使われている HardSigmoid オペレータ は、SNPEでサポートされないため、単純なオペレータの組み合わせに変換します。SNPEでサポートされるオペレータは 公式リファレンス から確認できます。 活性化関数に HardSigmoid が使われている。https://netron.app/ で可視化。

まず、今回のノード編集で利用する ONNX の opset バージョンを確認しておきます。opset versionによってオペレータの定義が異なるため、入力モデルの opset バージョンに揃えることにします。以下のスクリプトはモデルを読み込み opset バージョンを表示します。

import onnx

model = onnx.load(input_path)
for opset in model.opset_import:
    print(f"Model opset version: {opset.version}")

今回使用するモデルの opset バージョンは 11 ということが分かります。

model opset version: 11

次に、HardSigmoid オペレータを変換します。HardSigmoid の定義は、入力を x、出力を y として、

y = max(0, min(1, alpha * x + beta)) # alpha, beta はパラメータ

なので、ONNXの Mul、Add、Clip オペレータ を用いて分解できます。

x1 = Mul(alpha, x)
x2 = Add(x1, beta)
y = Clip(x2, 0, 1)

以下のスクリプトは、Mul、Add、Clip を用いて、ONNXモデルのすべての HardSigmoid を消去します。13か所で HardSigmoid が使われていることが分かります。

from onnx import TensorProto, defs, helper

count = 0
for pos, node in enumerate(model.graph.node):
    if node.op_type == "HardSigmoid":
    count += 1 # Count HardSigmoid operator

    # Create Mul node and insert
    n0_name = node.name
    x0_name = node.input[0]
    alpha = node.attribute[0].f
    alpha_name = n0_name + "_alpha"
    alpha_tensor = helper.make_tensor(alpha_name, TensorProto.FLOAT, [1], [alpha])
    y0_name = n0_name + "_mul"
    multiply_node = helper.make_node("Mul", [x0_name, alpha_name], [y0_name])
    model.graph.node.insert(pos, multiply_node)

    # Create Add node and insert
    y1_name = n0_name + "_add"
    beta_name = n0_name + "_beta"
    beta_tensor = helper.make_tensor(beta_name, TensorProto.FLOAT, [1], [0.5])
    add_node = helper.make_node("Add", [y0_name, beta_name], [y1_name])
    model.graph.node.insert(pos + 1, add_node)

    # Create Clip node and insert
    y2_name = node.output[0]
    min_name = n0_name + "_min"
    max_name = n0_name + "_max"
    min_tensor = helper.make_tensor(min_name, TensorProto.FLOAT, [1], [0.0])
    max_tensor = helper.make_tensor(max_name, TensorProto.FLOAT, [1], [1.0])
    clip_node = helper.make_node("Clip", [y1_name, min_name, max_name], [y2_name])
    model.graph.node.insert(pos + 2, clip_node)

    model.graph.node.remove(node) # Remove HardSigmoid node    
    model.graph.initializer.extend([alpha_tensor, beta_tensor, min_tensor, max_tensor])

print(f"# hardsigmoid nodes: {count}") # Outputs 13

作成されたモデルを検証して保存します。

onnx.checker.check_model(model) # Validation
onnx.save(model, output_path) # Save

変換後のONNXモデルを見ると、HardSigmoid オペレータが、Mul、Add、Clip オペレータに置き換わっていることが確認できます。

HardSigmoid が Mul/Add/Clip に変換されている。https://netron.app/ で可視化。

ONNX から DLC への変換

SNPE SDKに含まれるツール を使って、ONNXモデルからDLCモデルに変換が可能です。モデル実行時の入力テンソルのサイズを固定します。

snpe-onnx-to-dlc --input_network model.onnx --input_dim "input" 1,3,512,512

推論結果

当社のAIネットワークカメラ(Safie One)にモデルをインストールし、推論を行います。クラウド経由でモデルをアップロードできます。

SafieOne

推論が動作する様子をWebアプリ(Safie Viewer)から確認します。ここでは人物クラスを水色で表示しています。人物の輪郭が抽出されていることが分かります。

人物が水色でセグメンテーションされている

むすび

セマンティックセグメンテーションのSOTAモデル PP-MobileSeg をAI ネットワークカメラで動かしました。ONNXモデルからHardSigmoid オペレータを除去し、DLCモデルに変換する方法を詳しく解説しました。最後に、AIネットワークカメラ上の推論結果をWebアプリから確認しました。

セーフィーではエッジAIを用いたプロダクトの開発を行っています!

Androidチームにおける品質改善②〜アプリサイズの計測〜

Androidチームの品質改善の取り組みとして、今回はアプリサイズを計測した話をしたいと思います。

  • はじめに
  • 動作環境
  • rulerとは
  • rulerの導入方法
    • settings.gradleの編集
    • app/build.gradleの編集
  • analyzeタスクの実行
  • 継続的に計測する
    • ワークフロー
  • 最後に
続きを読む

Androidチームにおける品質改善①〜ユニットテストの導入〜

今回は直近のAndroidチームの品質改善の取り組みとして、ユニットテストを導入した件についてお話したいと思います。

  • はじめに
  • 実際にやった事
    • ユニットテストを書く
      • どこからユニットテストを書くか
      • 技術スタック
      • JUnit4 + Mockito-Kotlin + Truthを使用したテストコード
    • カバレッジ率の可視化
      • Jacocoの設定
      • Jacocoの出力
    • CIで自動でテストが実行される環境
      • 導入したアクション
      • ワークフロー
  • 最後に
続きを読む

セーフィーはPyCon APAC 2023に出展しました!

こちらはSafie Engineers' Blog! Advent Calendarの18日目の記事です。

こんにちは。セーフィー株式会社でバックエンドエンジニアをしている河津です。

私たちの会社は2023年10月27-28日に、PyCon APAC 2023への出展を行いました。この記事では、出展までの準備や当日の様子について紹介したいと思います!

  • PyConとは
  • 用意したデザインアイテム
  • 当日の様子
  • 出展デモ
    • Safie One
    • Safie Pocket2 Plus
    • Safie Connect
  • 撤収と振り返り
続きを読む

セーフィーの開発組織振り返り @2023

メリー・クリスマス、セーフィーCTOの森本です。
こちらはSafie Engineers' Blog! Advent Calendarの25日目のエントリーです。

時間の経つのは早いもので、当社も少し前まで数十人でバタバタやっていたように感じていますが、それが今では400人を超え、いよいよ創業10年目に突入しました。
まだまだやりたいこと、やらなければならない事が山積みでそのために更に大きく成長していく必要も感じていますが、現在の姿も過去からの積み重ねですので、今後を考える上でもまずは年末のこのタイミングで今までの歴史を振り返ってみたいと思います。

  • はじめに
  • 暗黒時代 エンジニア数〜10名
    • 2014年〜2016年
    • 2017年〜2018年
  • 闇からの夜明け エンジニア数〜30名
    • 2018年〜2020年
  • 未来への飛躍 エンジニア数30〜100名
    • 2021年、2022年
    • 2023年
  • 今後に向けて
  • まとめ
  • 最後に
続きを読む

セーフィーで取り組むマイクロサービス化について

はじめに

セーフィー株式会社でバックエンド開発のテックリードをしております鈴木敦志と申します。セーフィー株式会社は創業から9年経過し、サービスの拡大と開発者の増加に伴う開発生産性の問題に直面しています。この問題の解消のため、職能横断型チームの再編成とコードベースの分割によるマイクロサービス化を進めています。

セーフィーのサービス・チーム構成

セーフィーのクラウドサービスはカメラ管理および映像閲覧のほか、業務システム、AI応用サービス、開発者向け機能および入退館管理システムなどで構成されており、サーバー/Webの開発者のほかモバイル/組み込み/QAエンジニアなど様々な職種が関わっています。チームは職能別に分かれており、チームごとに複数のプロジェクト (開発案件) に参加します。

開発チーム構成

開発組織の規模が増えるにつれ、様々な問題が明らかになってきました。

  • 機能追加・改修にはたいていWeb・サーバーなど複数職種が関わってくるため、開発に伴い複数チーム間の調整が頻繁に発生します。各チームは複数プロジェクトを並列で掛け持ちすることになり、開発リードタイムの増加と認知的負荷の増加に繋がっていました。
  • 特にバックエンド開発において、モノリシックなサーバーコンポーネントを複数チームで共有しているためコード変更やデプロイ作業の競合が頻繁に発生していました。こういった状況に対処するためにコードベースの分割が進められていましたが、各コンポーネントのオーナーシップが不明確であるためにいわゆる分散モノリスの状態になり改善には繋がりませんでした。

これらの問題を抜本的に解消するため、職能横断型チームの再編成とマイクロサービス化に取り組んでいます。

マイクロサービス

マイクロサービスとは、個別にデプロイ可能なサービスの集合体としてシステムを構成することで多人数による並列開発を効率化する手法です。今回は下記方針でマイクロサービス化およびチーム再編成を進めていきます。

  • マイクロサービス境界を決定: マイクロサービスの導入にはどのようにサービス境界を定めるかが重要になりますが、今回はビジネス機能により分割し、必要以上に細かく分割しないようにしています

チームおよびサービス境界の分割

  • チームの再編成: 各チーム内で開発業務が遂行できるよう企画・QA含め機能を集約し機能横断チームを編成します
  • コンポーネントの分割と内部APIの整備: ソフトウェアコンポーネントの機能がマイクロサービス境界をまたいでいる場合、コードベース・デプロイ単位・DBを分割します。境界をまたいで機能提供を行う場合、gRPC等で内部APIを整備します。

モジュラーモノリスの検討

マイクロサービスに関連する手法としてコードベースおよびデプロイ単位は単一のままモジュールのオーナーシップを明確化するモジュラーモノリスも知られており、マイクロサービス移行の前段階として、あるいはマイクロサービスの複雑さを回避しつつ大規模開発を行うために用いられます。弊社においてはモジュール間参照の規律を保つのが難しいと判断したため、マイクロサービスを選択しました。

既存コードベースのマイクロサービス化

既存コードベースのうち特にバックエンドのソフトウェアはAPIサーバー、デバイス接続サーバー、タスクキュー、バッチサーバー等多数のサーバーで構成され、いわゆるモノリスあるいは分散モノリスとなっています。これらのソフトウェアの機能を保ったままマイクロサービス化を進めるため、以下の手順を取ります。

  1. 既存コードベースのうちマイクロサービス境界をまたぐものをチームごとにフォーク
  2. 自チームの担当範囲外の実装範囲外を削除またはプロキシに置き換え
  3. DBへの接続権限を変更し担当範囲外のテーブルへの書き込みを禁止
  4. マイクロサービス境界をまたぐ機能提供をAPIプロキシまたはDBの参照からgRPC等の内部APIに置き換える
  5. DBサーバーを分割

例: カメラ管理と契約・決済情報の分離

場合によっては単純なAPI分割だけではサービスの分割ができず、再設計が必要な箇所があります。

例として、セーフィーではカメラごとに顧客とSaaS契約が締結され、契約プランにより使用できる機能が異なります。契約プランはフロントエンドチームの内製する管理ツールにより操作され、また社内の業務システム (Salesforce, Zuora等) と同期されています。チームをまたいだ複雑なデータの同期が行われ、またどこの情報が元データなのかがわかりづらくなっていました。

現在サーバー内では契約情報とそれにより有効化される機能が単一のRDBテーブルで表現されていますがこれを分離し、カメラの機能有効化API/ライフサイクル管理APIを業務システムチームに提供する形で連携することで、契約情報の一元管理を実現します。

まとめ

セーフィーにおけるサービス規模・開発組織規模の増大に伴う開発生産性の問題に対応するため、既存システムのマイクロサービス移行を進めています。

現在セーフィー株式会社ではソフトウェアエンジニアを採用中です。マイクロサービスアーキテクチャや開発生産性の向上についてご興味のある方はぜひともご応募ください。

https://safie.co.jp/teams/

Safieプロダクト開発の歴史 Part2

この記事は Safie Engineers' Blog! Advent Calendar 23日目の記事です。

企画本部のマネジメントをしております植松です。

本テックブログももうすぐ丸4年を迎えます(祝!)。テックブログのごく初期にプロダクト(商品)開発の歴史 を投稿してからもSafieは様々なプロダクトを世に出してきました。

そこで、本記事ではこの4年間でリリースしてきたプロダクト群の一部紹介と、今後の展望について書いてみたいと思います。

プロダクト年表 (2020~)

Safie API / Safie Developers

2020年迄はエンドユーザーやパートナーの方向けの製品を作っていましたが、開発者向けの初のプロダクトとして2021年2月に Safie API をリリースしました。 これにより、お客様の既存の業務ツールに我々の映像を組み込んでいただいたり、画像解析をお客様側で行っていただく、など、お客様側の使い方の幅が格段に広がりました。

元々の企画の始まりはパートナー様向けの案件があり、それは画像取得しViewerへのイベント登録をパートナー様側で画像解析して登録する、というものでしたが、我々のサービスとしては汎用化を見据え同時にストリーミングAPIを準備しました。かなりタイトなスケジュールでしたがなんとかリリースにこぎつける事ができました。このパートナー様向け機能については継続的に多くの台数使っていただいて売上高も順調に伸ばしており、今後のAPI利用の足がかりにもなったと思っています。

当初はβ版として限られたユーザにのみ使っていただいてましたが、今年頭から晴れてDeveloper(Safie API v2) として生まれ変わり、登録したユーザは誰でも使っていただけるようになっています。このブログではAPIの使い方 や、APIの便利なユースケース も紹介していますので、そちらもぜひご覧いただければと思います。

Safie Developers Topページ

Safie Pocket2 / Pocket2 Plus

ウェアラブルカメラPocketシリーズは2020年にリリースしたPocket2 , 2023年にリリースした Pocket2 Plus と着実な進化を遂げていますので、その歴史について簡単に記したいと思います。

2020年一番の出来事は何と言っても新型コロナウイルスでした。弊社のサービスもコロナウイルス対策最前線の病院などで活用され、その事例は英国のBBCニュースでも取り上げられました。 そこに遠隔業務の切り札として満を持して2020年7月に登場したのが「Safie Pocket2」です。

初代Pocketは、所謂MVP(Minimum Value Product)と呼ばれる仮説検証のため、市販のウェアラブルカメラのソフトウェアをカスタマイズしたものです。静止画スナップショット機能やWebRTCによるリアルタイム双方向音声通話の実現といった新開発機能を盛り込んだ、新しいサービスでした。 私が入社した頃には既に初代Pocketは開発が終わっていましたので、伝え聞くところにはなりますが、カメラ本体に加えて無線LANルーターやモバイルバッテリーが別途必要で、ご利用いただいたユーザー様からもやはり、重い、持ち運びしにくい、というフィードバックを数多くいただいていたようです。そこで、エンジニアが、インターネットで見つけた世界中のウェアラブルカメラメーカー(英語では "body worn camera" と呼ばれます)に手当たり次第問い合わせをし、国内外のこれといった展示会を巡った末に実現したのが「Safie Pocket2」でした。

当初は3月に製造して4月販売開始の予定でした。新型コロナウィルスの脅威が日に日に高まり、外出自粛やリモート勤務が行われる中で、Pocket2をご活用いただけるはず、だったのですが、なんとPocket2の工場まで閉鎖されてしまったのです。メーカーさんが何とか頑張って工場を再開したのに部材も人も揃わない。組立が完成しても、物流が混乱しているので発送したカメラが届かない。お待ちいただいていた皆様にようやくお届けすることができたのは、3カ月遅れの7月になってしまいました。予定よりも遅れてしまいましたが、ユーザー様にはご満足いただき、さらにはテレビ東京 WBSで取り上げていただくなど、社会的にも注目される商品となっていきました。

ここで歩みをとめたわけではなく、使っていただいている中で様々な品質課題や改善要望が上がってきておりそれらを解消すべく、今年の5月に新たにPocket2 Plus をリリース。ウェアラブルならではの「手ぶれ補正」や、音声品質改善のための「スピーカー通話」、ウェアラブルといいながらも実際には固定して長時間利用されている方も多いため「モバイル給電」などの機能を搭載。より痒いところに手が届く、使い勝手の良さを追求したプロダクトとなっています。来年は海外にも羽ばたく予定です。

Safie One / SPDP

弊社CEOの佐渡島が創業当時から何度も語っていた「かしこくなるカメラ」の実現。Safie初のエッジAIカメラである Safie One は2022年9月にリリースされましたが、このリリースも苦難の連続でした。

CC2 / CC2Lという主力プロダクトの製造会社に開発依頼し、商品コンセプト、ハードウェアデザインについてデザイナーの方とコンセプト固めをして何度もやり取りを行い、試行錯誤を行いながらデザインを決めていきました。その後試作機が届いたのですが、SoCから発生する熱問題(AIを定常的に使っていると熱暴走して停止してしまう)・カチカチ音問題(カメラ内部で音が定常的に鳴る)・IrLED反射問題(レンズの下部に反射して映像にゴーストが発生してしまう)... などなど、大きな課題から小さな課題まで膨大な件数を、1つ1つ潰していきながらプロダクトリリース。

当初の構想から足掛け2年。やっとの思いでリリースした後も安定して量産にこぎつけるまでに様々な苦労がありましたが、現在はぽん置き出来る手頃なAIカメラとしてセーフィーの主力商品となっています。

当然ながら、エッジAIカメラというからには同時並行でAIアプリも開発が必要です。SPDP という主に店舗で使っていただくための立ち入り検知・通過人数カウント・立ち入りカウントがパッケージされたAIアプリを同時リリースしているのですが、これも途中で1度UI部分の仕様変更に伴った作り直しが入り、今の形となりました。もちろんViewerからスムーズに使える使い勝手の良さは他のアプリと同じ思想で作られています。

vimeo.com

今後の展望

まだまだ書きたいプロダクトは色々あるのですが、長くなってしまうので改めての機会とさせていただき、ここでは今後の展望を記したいと思います。 セーフィーでは「映像から未来をつくる」をビジョンに掲げ、ユーザーの課題を解決するプロダクトを創業当初から作り続けて来ました。今後は、

  • パートナーであるカメラメーカーをユースケースに合わせて増やしていき、カメラ、特にエッジAIカメラのラインアップや、カメラを使える環境(ネットワーク機器、SIMなど)の提供
  • よりユーザーの課題に寄り添ったソリューションの提供
  • 映像プラットフォーマーとして技術をさらに活用してもらう方法をAPIやSDKで提供

といったあたりを中心に、セーフィーを使ってくださる方を増やし、セーフィーの映像を使って課題解決出来ることをどんどん増やしていきたいと考えています。

最後に、セーフィーでは新しいプロダクト、サービス、ソリューションを一緒につくっていただけるエンジニアやプロダクトマネージャーを大募集しています。面白そうだな、と思った方はカジュアルに話してみたい、で結構ですので是非コンタクトいただけると幸いです!

open.talentio.com

© Safie Inc.