こんにちは！ このたびセーフィー株式会社でインターンをさせていただきました、吉田と申します。 この記事を通して、インターンで得た学びや、会社の雰囲気などが伝われば嬉しいです。 インターンをした経緯・目的 セーフィーのどこに興味をもったのか 選考 インターンの概要 やったこと 行動認識の既存モデルの検証 機械学習モデルの量子化 学んだこと・感想 インターンをした経緯・目的 私は就職活動において、大企業よりもベンチャー企業に魅力を感じていました。 ベンチャー企業のほうが、お客さんとも関われるし、事業全体に幅広く関わったり、新しいことにチャレンジできたりしそうだと思ったからです。 ただ、実際にベンチャー企業で働いてみた経験はなかったので、職場の雰囲気や業務内容がどうなのか体験してみたく、インターンをすることしました。 セーフィーは現在の研究テーマにあっていて、かつベンチャー企業ということで、大学の就職担当の方を通して紹介していただきました。 セーフィーのどこに興味をもったのか 私は、機械学習や神経科学を使って人間の知能について研究している研究室に所属しており、そのあたりの分野に関わりのある企業を探して就活をしていました。 セーフィーは、単に映像を扱っているだけでなく、将来的に「映像プラットフォーム」を作ろうとしています。 これは、複数のカメラの映像を一元管理し、膨大な映像を言語で検索したり、様々なアプリを使って解析したりできる場を作ろうというものです。 連続的な映像データから、起きたイベントなどの抽象的な情報を取り出して言語で検索できるようにするというのは、人間が見たものの意味を理解するということと共通する点が多いと感じ、興味を持ちました。 また、映像プラットフォームでは、他社製を含む映像解析アプリのプラットフォームを作り、そこから自由に選んで自社のデータに使えるようにするという構想があり、ビジネスの発展性という点からも面白い企業だなと思いました。 選考 インターンにあたり、面談とコーディングテストを受けました。 面談は会社説明を兼ねたカジュアルなもので、給与面や、私個人の将来についてのことも含め、いろいろ相談させていただきました。 コーディングテストは初めてだったので緊張していましたが、思ったよりも軽めのもので、ゆるく競技プログラミングに触れていたこともあり通過することができました。 インターンの概要 プロダクト開発部のイメージングチームに加えていただき、10月から12月にかけて週に2日、計16日間の日程でインターンを行いました。 出社するかリモート勤務にするかは自分で決めることができ、今回はどちらも経験してみようということで、リモートと出社を半分ずつで行いました。 業務は会社から貸与されたラップトップで行いました。 チームのエンジニアの方にメンターとしてついてもらい、課題に取り組みました。 業務中は基本的にSlackでコミュニケーションをとりながら作業しました。 勤務時間の終わりにはミーティングを行い、作業ログを見ながらその日の振り返りをしつつ、次回以降の方針を決めました。このように毎回密にフィードバックを貰えたのは心強かったです。 また、Googleドキュメントにレポートの雛型を作っておき、それを埋めていくというドキュメントベースの形で作業を進めました。こうすることで、あとどのくらいで終わりそうかという見通しが立ち、短い期間の中でも安心感がありました。 レポートは最後に共有会を行い、エンジニアチームのほか、企画や営業の方からもフィードバックをいただきました。 出社した日には毎回いろんな部署の方とランチの予定が組まれていて、緊張もしましたが、どの方も気さくに話しかけてくれたので楽しかったです。 やったこと 私の興味がある分野と、社内の課題とを照らし合わせ、事前にいくつかタスクを準備していただいていました。 面談の際に、将来やってみたいこととして、映像解析の技術を応用してライフログの解析をしてみたいと伝えていたので、関係しそうなものとして、行動認識アルゴリズムの実用性を評価するというタスクをすることになりました。 行動認識の既存モデルの検証 行動認識とは、映像中に映っている人を検知し、その人が何をしているのかラベル付けするというタスクです。 店内に設置したカメラで顧客の行動から興味があるか判別してマーケティングに活かしたり、社員の姿勢や動きを認識してより働きやすいオフィスづくりに活かしたりするなどのニーズが考えられます。 今回は、PoseC3D、SlowFast Networksという2つの既存モデルに対して、社内カメラのデータを使って評価しました。 PoseC3Dは、人物の骨格を検出するスケルトンベースの行動認識アルゴリズムです。人物ごとのスケルトンと、映像全体がどんなシーンかというラベルを出力します。 github.com PoseC3Dの出力結果 SlowFast Networksは、2段階の時間解像度で映像を認識することでより正確に・効率的に認識をするという行動認識アルゴリズムです。人物ごとに行動のラベルを出力します。 github.com SlowFast Networksの出力結果 個人ごとに行動を認識できるSlowFast Networksについて、より詳しく評価を行うと以下のような結果となりました。 被写体の距離 距離が遠かったり、画面の端のほうにいたりすると人物検知されにくく、行動認識の精度も低下した。 遮蔽物がなく全身が映っていればある程度認識できた。 被写体の行動 立ち上がる、座るなどの姿勢が大きく変化する動作だと行動認識の精度が低下した。 映像の画質 画質(圧縮方式)を変更することで、同時に検知される人数が増加した。 映像の画角 急な角度で見下ろすような画角の場合、人物検知、行動認識の精度がともに低下した。 被写体と水平になるようにカメラを設置することで改善した。 今後より実用的な状況で使うためには、以下のような工夫が考えられます。 対象の全身が大きく映るようカメラ位置を調節する。 特殊な画角の場合はファインチューニング*を行う。 認識したい行動に絞って再学習する。 *ファインチューニング: 学習済みモデルの一部を再利用してネットワークを再構築する方法。 ユースケースを想定しながら実サービスとしてサーバーで運用する場合のコストの試算を複数のパターン行いました。行動認識における推論処理を定常的に行い続けるとコストが高くなるため、動体検知と組み合わせてイベントが起こったタイミングの映像でだけ推論を行うことで、コストパフォーマンスを上げるアプローチも考えました。 機械学習モデルの量子化 時間が余ったため、ほかに提案していただいていたタスクである、機械学習モデルの量子化の実験も行いました。 量子化とは、ネットワークのパラメータをより少ないビット数で表現することでモデルの軽量化を行う技術です。 通常は32bitの浮動小数点数として扱う数値を、もう少し粗くして、8bitや16bitなどの固定小数点数で表現することで、機械学習のモデルサイズを抑えることができます。結果としてメモリ消費量を軽減できたり、計算を高速化したりできる利点があります。 サーバーではなくカメラ側で画像認識を行う「エッジAI」で特に重要な技術です。 今回は、PyTorchで実装された物体検知モデルを、エッジデバイス向けの推論ライブラリであるTensorflow Liteのモデルに変換して量子化し、量子化による計算時間や推論性能の変化を調べました。 苦労した点としては、Tensorflow Liteはエッジデバイスで使われるARMプロセッサ向けに最適化されていて、intelプロセッサのPCで実行すると遅くなってしまうという落とし穴がありました。これは、Tensorflow Liteをintelプロセッサ向けのオプションをつけてビルドすることである程度緩和されました。 機械学習モデル自体の研究ではなかなか量子化やエッジAIの技術に触れることがなかったので、勉強になりました。 そのほかにも、セーフィー製品を使っている企業の見学に同行したり、協業企業とのミーティングに参加したり、社内の勉強会に参加したりと、貴重な体験をいくつもさせていただきました。 社内で定期的に開かれている勉強会では、メンバーが自分の専門分野や最近触っている技術について気軽に共有していて、とても良い文化だと感じました。 学んだこと・感想 今まで企業でしっかり実務に携わった経験がなかったこともあり、新鮮な経験ばかりで、あっという間に終わってしまったなという感じでした。 特に、実サービスを想定したサーバー運用コストの試算や削減については、研究ではほとんど意識しないことだったので新鮮でした。研究も、実用的に使われてこそ意味があるものなので、このあたりの感覚を持っていることは大事な気がしました。 また、会議やミーティングでは、大人数が参加する場であっても立場の上下なく若い人が積極的に発言していて、フランクで働きやすい雰囲気だなと感じました。 インターン期間を通して、いろいろな方が進路の相談に乗ってくださって、大変励みになりました。みなさんキャリア設計をきちんと考えていて、私ももっと自分の将来を具体的に考えなければと思わされました。 最後になりますが、メンターの方をはじめ、面倒を見ていただいたイメージングチームの皆様、そのほかお世話になった社員の皆様、本当にありがとうございました！

企画部 商品企画 今野です。Safie APIのプロジェクトの企画を担当しています。 Safie APIは現在β版として公開していますが、それを正式版にすることが近々の私の業務目標となっています。私の業務区分は、企画立案・プロジェクトマネージメントですので、バリバリの技術屋の方々に比べるとテックブログを書くには力不足感が正直否めませんが、今回、Safie APIの紹介の場を頂けるとのことで、こうして筆を取らせて頂くことになりました。 本投稿では、Safie APIの概要と簡単な動作お試し方法をご紹介します。よろしくお願いいたします。 2023.11.6 追記: 最新のSafie APIの紹介として「 Safie API v2(正式版)の始め方とトライアル方法の紹介 」を投稿しています。この記事の内容は古いものになっていますので、最新の情報は上記記事を確認ください。 Safie APIとは？ Safie APIを利用するには？ Safie APIを動かしてみる ①カメラ所有者に接続許可をもらう ②Code情報を使ってTokenを取得する ③アクセスできるデバイス一覧を取得する 最後に Safie APIとは？ Safie APIは、セーフィーが提供するクラウド録画サービスのデータを、外部のサーバから取得したり、情報を書き足したりする機能を提供するものです。詳細な情報を知りたい方は、 Safie Develpersサイト にある APIドキュメント を参照ください。大まかには、以下の２つのことができるものと理解して頂ければ、概ね誤りはないかと思います。 カメラから動画や静止画、検知したイベント（音や動体検知、など）を取得する 動画にイベント（何かが起こった時間を記録するもの）を登録する 注意頂きたいこととして、Safie APIは外部サーバからの呼び出しを原則としているため、ブラウザから呼び出すことはできないことがあります。ブラウザから呼び出したい場合は、Safie APIの利用プランに含まれている Safie web components をご利用ください。 Safie APIを利用するには？ Safie APIの新規利用をご希望の際は、 Developerサイト の「お問い合わせ>API導入前のお問い合せ」の項目よりフォームを開いて頂き、項目「API新規利用」を「希望する」にし、他、必要情報を入力の上、送信ください。情報を受けて弊社より案内を差し上げ、手続きが進みます。Safie APIの利用には以下の2つの前提条件がありますので、お問い合わせの際にはご注意ください。 クラウド録画プランを契約すること、既に契約していること Safie APIを利用するシステムがWebのページを持っていること 1は、Safie APIがカメラ毎に利用許可を管理しているために付いている条件です。利用者の方にカメラのシリアルナンバーを提供頂き、弊社側の管理システムにてそのカメラに権限付与を行います。 2は、認証に必要な情報をAPI利用者側のWebページに向けて送信しなくてはいけない手続きが、認証プロセス中にあるために付いている条件です。利用者の方より用意されたWebページのURIを提供頂き、弊社側の管理システムに事前に登録をします。 それぞれ事前に準備されていると手続きがスムーズに進みます。 手続きが完了すると、認証用のClient IDとClient Secretが記載された通知書が手元に届き、APIが使用できるようになります。 図１：Developerサイト お問い合わせ ここで大変申し訳ないお話をしなければなりません。現在、Safie APIは運用キャパシティの関係で、問い合わせを頂いた全ての方々に提供することができていません。また、法人向け公開に限定しており、個人のお問い合わせはお断りしております。β版が正式版となった際にはより多くの方々にご利用頂けるよう、現在プロジェクトを推進しております。現状はご了承頂ければと思います。 Safie APIを動かしてみる 具体的にどのように動作するのか、私の方で実際に動かしてみた手順を紹介させて頂きます。REST APIですので、呼び出し方は多種多様に可能な訳ですが、あまりこの分野に明るくない方もいらっしゃるかと思います。そのような方にとって、どのようなものなのかの感触を掴む一助になれれば幸いです。動作環境の影響はほぼないかとは思いますが、参考に実際に動作させた環境を以下に記載しておきます。 MacBook Pro (13-inch, M1, 2020) macOS Monterey version 12.0.1 Google Chrome version 95.0.4638.69 (Official Build) (arm64) Postman Version 9.0.3 (9.0.3) https://www.postman.com/ カメラにはトライアル用のSafie APIプランを付与 ①カメラ所有者に接続許可をもらう ※今回は許可を出すのは自分自身 最初にカメラ所有者から接続許可をもらう必要があります。以下のURLに指定のQuery Paramsを付与し、カメラ所有者よりカメラ所有者のSafie Viewerのメールアドレス, パスワードを入力してもらいます。 https://openapi.safie.link/v1/auth/authorize 私はPostmanを使用してQuery Paramsを設定することで、Query Paramsを含んだURLを作成しました（図2）。 図2：接続許可をもらうURLを生成（Postman） ※client_idとredirect_uriは利用者のものを使用すること そのURLをコピー＆ペーストでGoogle ChromeのURL欄に貼り付けることで、接続許可の画面が表示されます（図3）。 図3：接続許可をするための認証画面（Google Chrome） 今回はカメラ所有者が自分なので、自分のSafie Viewerのメールアドレス, パスワードを打ち込みました。カメラ所有者が別の人の場合は、URLを送付し、メールアドレス, パスワードを打ち込んで許可をもらう必要があります。図3の画面にて許可を行うと、redirect_uriで指定した画面に遷移します。遷移した先では、Query ParamsのKey: Codeの文字列が付与されます。以下のように「?code=」の後に16進数の羅列が付与されますので、「?code=」の後から「&status=」の前までの文字列を記録しました。 ~~~?code=XXXXXXXXXXXX（16進数の羅列）&status= ②Code情報を使ってTokenを取得する Postmanに下記URLを入力し、マニュアルに記載された指定の各パラメータを設定します。codeは記録したものを使用しました。 https://openapi.safie.link/v1/auth/token POSTメソッド、かつ、パラメータもBodyに設定することなど指定が多いので単純にブラウザでは実行できないため、Postman上から実行しています。私はBodyのデータ形式設定を誤り一度詰まりました。正確に「x-www-form-urlencoded」を指定します。 図4：Tokenを取得（Postman） ※各パラメータは利用者のものを使用すること 成功するとPostmanのResponseにaccess_tokenが表示されます。ここで、access_tokenの文字列を記録しました。 図5: Access token 正常系Response （Postman） ③アクセスできるデバイス一覧を取得する Tokenを無事に取得できたので、アクセス可能なデバイス一覧を取得します。デバイス一覧取得は特にパラメータ指定はないため、以下URLとToken設定のみを行います。 https://openapi.safie.link/v1/devices TokenはAuthorizationのタブを選択し、Access Tokenの枠に②で記録した文字列を記入しました。Header Prefixは②のResponseに従いBearerに設定しました。実行するとデバイス一覧がResponseに表示されます。表示された一覧から操作したいデバイスを探し、そのdevice_idの文字列を記録しました。 図6：Authorizationの設定（Postman） ④静止画像を撮影してみる デバイスを操作してみます。今回は静止画撮影を行っています。以下のURLの[device_id]の部分に先ほど記録したdevice_idの文字列を設定しました。 https://openapi.safie.link/v1/devices/[device_id]/image ③の操作同様、Authorizationのタブ下にTokenを設定しました（図7）。実行すると、Responseに撮影した画像が表示されます。実際に、図7のResponseで静止画像が表示されたことを確認できました。 図7：静止画の取得（Postman） 最後に いかがでしたでしょうか。β版では運用キャパシティに限界があり、あまり大々的な広報ができない状況ですが、今回、テックブログということで簡単に紹介をさせて頂きました。紹介が主な内容だったということで、技術者の方にとっては若干物足りなかったかもしれません。今後、弊社技術者より「Safie API使ってXXXしてみた」といったような内容の記事が投稿される予定となっていますので、より技術的な内容を知りたい方は、そちらの記事も是非閲覧頂ければと思います。β版が正式版になった際は、多くの人が利用できる環境を提供でき、情報展開も大きくしていける予定です。どうぞご期待ください。

セーフィーでCTOをさせて頂いている森本です。 なぜ顔認証で勤怠管理をすることに 実際のニーズ 実際にやってみた内容 1. 電子錠のリモート開閉 2.顔認証によるドアの解錠管理 1-1.セーフィー対応カメラによる解錠管理 1-2.タブレットによる解錠管理 1-3.細かなチューニング 3.顔認証による勤怠管理 最後に 久々の投稿となってしまいました。 先日の記事 で顔認証で勤怠管理の紹介をしましたが、今回はそのシステムの導入までの道筋も含めて紹介します。 実際に利用している様子はこちらです。 なぜ顔認証で勤怠管理をすることに 現在セーフィーでは SafieVisitors ※1、 SafieEntrance ※2という顔認証サービスを提供していますが、3年ほど前からこれらのサービスに利用する顔認証の仕組みを社内でも何かに活かせないかということで色々検討を行っていました。 顔認証に限りませんが、様々な技術や仕組みが実際にプロダクトとして使えるレベルのものなのかどうかという事を判断をする為にも、自分達でとことん使ってみるというのは非常に有効な手段だと思っています。 偶然にも、セーフィー社内では会社の成長に合わせて以下のようなニーズが発生していました。 顔認証技術とその応用はこれらの対策にマッチすることが期待できました。 実際のニーズ 社員数の増加に伴い引っ越しを行ったが、引越し先ビルはビル入口にオートロックが存在するのみでオフィスフロアにはオートロックが存在しなかった。 セーフィーとしてはオフィス入り口にもロックを設置することを必須としていたので、何らかの形でロックを設置する必要があった。 カード式のオートロックを設置する場合、ビル入口はビルが管理しているためオフィス入り口とは別管理となりカードの2枚持ちが必要となる。 当時流行り始めていたスマートロックを設置してみたが、Bluetoothの接続性含め安定性がいまいちでオフィスに入れない人が続出した。 安定して動作する電子錠の設置が望ましい。 上記を解決するため、実績のある一般的な電子錠を設置しカード無しで入退室出来る方法を顔認証で実現出来ないかというアプローチを取る事としました。 ※1：顔認証技術により、人数のカウントや属性（性別、年齢）推定を行い、その統計結果をユーザーに提供するサービス。 ※2：顔認証技術により、事前に登録したユーザーの入退室管理を提供するサービス。 実際にやってみた内容 1. 電子錠のリモート開閉 まずは一般的な電子錠を設置しそれを開閉出来る仕組みを検討しました。 たまたま、リモートから解錠できるプロダクトがあったので、まずはこちらを使ってみることとしました。 電子錠リモートコントローラー 2.顔認証によるドアの解錠管理 上記はカードでの運用もサポートしているのですが、当社としてはカードの二重持ちはとにかく避けたかったのと、せっかく顔認証技術の検討を進めていたので、顔認証でドアの解錠を行うことを決めました。 以下そのアプローチとなります。 1-1.セーフィー対応カメラによる解錠管理 セーフィーの録画サービスでは基本的にはIPカメラを利用しています。 まずはカメラをドアの前に設置し、認証できたらドアを開けるというシステムを設置しました。 セーフィー対応カメラによる解錠管理 これで一応は顔認証によってドアの解錠が出来るようになったのですが、IPカメラということで映像を取る事しかできず、ドアが開かなかった場合にその理由がよく分かりませんでした。 顔の写り方がおかしい、認証に失敗等が考えられますが、原因が分からないのでユーザーはどうすれば良いかと迷ってしまっていました。 1-2.タブレットによる解錠管理 そこで認証結果についてフィードバックを得る手段を提供する為、認証端末としてAndroidタブレットを利用する事としました。 タブレットによる解錠管理 タブレットでAndroidSDKの顔検知機能を利用し顔の切り出しを行い、切り出した顔の認証はSafieクラウドで実施するようになっています。 これで大幅にユーザビリティが上がり、ドアが開かない場合にその原因が明確に表示されどのように対応すればよいのか分かるようになりました。 1-3.細かなチューニング ただし、別の問題も発生しました。 AndroidSDKの顔検知機能では、実際の顔では無いものを検知してしまうという事象が多発しました。 例えば、背景の壁等を誤検知してしまうような事象があったのですが、一度誤検知をしてしまうと 背景は動くことが無いので、誤検知がひたすら継続してしまうという問題が発生してしまいました。 顔の誤検知 これを解決するために、外部の顔検知ライブラリを使用する事としました。 これにより誤検知がなくなり、劇的にユーザビリティが向上し、自分たちで使っていても最低限ストレス無く使えるレベルまでは品質を上げることができました。 ただし、まだまだ幾つか不満も残りました。 後ろを通りかかっただけでもドアがあいてしまう タブレットに写ってから認証が完了しドアがあくまで2〜3秒程度かかってしまう 画像データでも空いてしまう これらの不満を解決するため、以下のような対応を行いました。 検知最小サイズを設定できるようにし、必要な人の顔だけ検知するようにしました。 検知最小サイズの設定 ライブラリをチューニングし1秒以内でも解錠するようにしました。 当社オフィスのセキュリティレベルに関わるので詳細はここでは述べませんが、人間でない場合は解錠できないという対策を実施しました。 以上により全くストレス無くドアの解錠を行い自分たちのオフィスに入退室できるシステムが完成しました。 3.顔認証による勤怠管理 上記により顔認証によるオフィスへの入退室管理が実現できるようになりました。 ドアの解錠を行うことにより、誰が何時にオフィスに入ったか、出ていったかということも分かるようになったのですが、これを他にも利用できないかという話になりました。 当社は勤怠システムとしてKingOfTimeを利用していたのですが、いちいち打刻申請が必要で面倒だという話があったので、ドアの解錠履歴をKingOfTimeに連携する事によりわざわざ打刻処理をしなくとも勤怠登録ができるようにしようと考えました。 一日の認証履歴を確認し、最初の入室と最後の退室を勤怠時間としてAPI連携によりKingOfTimeに登録するようにしました。 勤怠管理との連携 ※残念ながら現在コロナの影響により大部分の社員さんがリモートとなってしまったので、リモート実施時には個別に打刻して頂いていますが、出社時には非常に使いやすいということで社内で絶賛されていました（笑） 最後に 今回は顔認証技術を自分たちで使い倒してみたところをご紹介しました。 これらの試行錯誤がSafieEntranceサービスやSafieVisitorsサービスに繋がっています。 これは一例ですが、実際のプロダクトを出していくにあたり、自分たちで商品を使ってみて、不満点を全て解消し満足いくまで作り上げていくことは非常に重要なプロセスだと感じています。 補足ですが、ここに記載した活動は2名のエンジニアが中心となり、3ヶ月ほど掛けて実現してくれました。 尚、弊社としてはメインの録画、配信、データ解析サービスの更なる強化を実現すべく開発業務に取り組んでいますが、まだまだエンジニアさんが足りていない状況です。ご興味がある方はお気軽にご連絡頂けますと幸いです。

こんにちは！イメージングシステムグループの二宮です。2020年2月に入社し、画像処理の基礎知識を日々学びながら、機械学習モデルのアルゴリズムを開発したり、デプロイメント方法を検討したりしてAIシステム開発に携わっています。「AIの仕事は実際何をやるの？」や、「実務未経験者でも大丈夫と言われてもどこまで信じればいいのか・・・」などと思われる方も多いと思いますので、入社した経緯と普段の業務の一部を紹介してまいります。 今までの経歴 AIの仕事って何をやるの？ データ集め アノテーション作業 アルゴリズムの調査 実装/実験/評価 POC そもそもなぜセーフィーに入社を決めたのか AIをやるにはある程度の余裕が必要 入社を決めるときの私の判断基準 最後に 今までの経歴 大学院卒業後、大手メーカーで組み込み系の製品開発（実装）（2年） 中小企業でIoT(環境の測定&制御)における組み込み系（設計・実装）＋ ウェブページの開発（実装・DB設計）（2年） これを見られて「なぜ最初からAIの仕事を選ばなかったの？」と突っ込まれることが多いので弁解させてください。 「同じ仕事を10年間続けて、時代が変わり自分の開発している製品も会社もなくなる。そうなると、それまでのスキルが活かせる次の仕事が中々見つからないから、転職しながらジェネラリストを目指すといいかもね。」と、大学院生時代に知り合いからいただいたアドバイスが心に響きました。続けて楽しくやれそうなのはAIだとしたら、まずはエッジ側、ウェブ開発の技術を身に着けてから最終的にAIの仕事に落ち着くキャリアにしようと決めました。そうしたら、その先もしものことが起きても、製品開発ができるための(最低限の)知恵はどこかで活かせると思いました。 案の定、最初に務めた製品開発は楽しく思えましたし、組み込み系の知識は貴重な知識だと思いましたが、ハードウェアの設計開発を含めて製品開発をやっている会社では、仕様・企画・開発・製造・品質管理・広告・営業の間で一つのモデルを通して市場に出すだけでも1年半はかかります。また、企業によっては仕組みも出来上がりすぎていて人も多いため、担当させてもらえる機能が限られてくることもあります。 「これなら10年間なんてあっという間に終わりそう・・・」 と思い、早いうちにAIに携われる仕事に変えてキャリアを磨きたい気持ちが強くなりました。 そこでセーフィーに出会い現在に至ります。 AIの仕事って何をやるの？ イメージングシステムグループの仕事は、学習アルゴリズムをコツコツと調べて、ネットワークをチューニングするだけではありません。学習モデルをシステム化できるまで幾つかのステップが必要なので紹介してまいります。 データ集め 恐らく、AIに取り組もうとしてこの段階で早速行き詰まる会社が多いのではないでしょうか。 我々も、カメラの映像をクラウドに貯めてお客様に閲覧できる環境を提供しているとはいえ、 お客様のデータを覗くことは一切許されませんし、当然勝手に機械学習に使うこともできません 。 そうすると、解決したい課題をお客様にヒアリングし、データを機械学習に使う許可を得て、初めてデータ選定に進むことができます。 アノテーション作業 画像だけを入力してモデルが勝手に賢くなっていく魔法のような学習の仕組みは中々ありません。 多くの課題を解決するには、手っ取り早いやり方として「正解とは何か」をモデルに学習させるという方法があります。 そうすると、「正解」というのは開発側で決めないといけませんし、自分達で画像一枚一枚に対し認識したいものに目印をつける(アノテーション)作業が必要です。 なので、画像にポチポチと点を付けてファイルに保存している間に一日が終わることもあります。 アルゴリズムの調査 「この課題に認識率と計算時間がピッタリのニューラルネットワーク構成を知っている！」という技術者であればこのステップは一瞬で終わるかもしれませんが、筆者を含める実務未経験者でも機械学習の上級者でも、多くの人は、最先端技術についていくために日々学習方法を調査しています（英語の文章が読めるといいことがあるかも・・・？）。 初心者は、「 そもそもCNNとは 」というところから勉強し始めるといいです！よく議論で出てくるネットワークの名前とその論文は以下です（筆者も最初は読んでいなくて会議についていくのに大変でした）。 YOLO (概要説明ページ；論文は「publications」にまとめてあります) VGG ResNet 実装/実験/評価 論文は、読むだけでは自分の課題に適したネットワーク構成かどうかが分からないことが多いです。そのときは自分なりに構成を調整してまず実装してみます！ 昔なら、この段階ではニューラルネットワークをゼロから自分でコーディングしていました。認識率以前の問題で、そもそも全レイヤーの計算が合っているかどうかをデバッグするだけで無駄に時間が取られて中々研究が進みませんでした。 今では、ちゃんとアルゴリズムの検討だけに没頭できるように、ニューラルネットワークが簡単に作れるフレームワークを提供してくださる会社がたくさんあります！我々のチームで使っているのは TensorFlow 2.0 + Keras です。 例えば、以下のネットワークの一層目だけを見てみましょう。 CNNに馴染みがない方は分からないかもしれないので、言葉にすると次のような計算になります。 入力画像から3x3の窓を切り取って、その入力に対して1個の出力を作ります。 入力画像から3x3の窓が切り取れる数だけ、1. を作ります。 さらに、チャンネルの数だけ（画像では32）、2. を作ります。 言ってしまえば「ただの掛け算と足し算」ですが、このような計算を全レイヤに対して楽しくハードコーディングできる人はいるのでしょうか。 TensorFlow 2.0 + Kerasなら一行です。 layer = tf.keras.layers.Convolution2D(32, (3,3), strides=(1, 1), padding='same', activation='relu')(input) こうやって一層一層を重ねれば、ニューラルネットワークの作成があっという間に終わります！ 因みに、筆者にとっては初めてのPython開発となりますが周りの方のご指導の下なんとかやっております！（どんどん新しいことにチャレンジさせてくれる会社に感謝） POC 実装したモデルを学習させ評価して、納得できる結果が得られたらプラットホームに載せるステップに進みます。リアルタイムで画像を取得しながら、以下について様子を見ながら開発の方向性を見ていきます。 モデルをさらに学習させるのか データを貯めてから学習させるか どこまでモデルに汎用性があるのか 処理時間はどれくらいかかるか / 同時アクセスの数に見合った処理時間なのか これらのステップを繰り返しながら課題解決に挑んでいます！ そもそもなぜセーフィーに入社を決めたのか AIをやるにはある程度の余裕が必要 これまで書いたように、モデルの学習からPOCができるまでのプロセスは簡単にできることではありません。 転職を考えるとき、自分に高い技術力を求められる分、会社側に開発の環境がちゃんと整っているかを厳しい目で見てもいいと思います。特にAIという分野は、一つひとつの実験には失敗の可能性が十分にあることを会社に理解してもらう必要があります。でないと、自分の成果物に満足できないのに、改善する余裕がないまま提出する非効率的な開発の日々が進んでいきます。「ちゃんと時間をかけていいものが作りたい」というのは転職活動当時の思いでした。 入社を決めるときの私の判断基準 開発は余裕を持ちながらもしっかりと進められそうだったので、セーフィの印象はとても良かったです。面接を終えて一つだけモヤモヤとする点が残っていました。 「技術力はもちろん求めていますが、AIに関しては実務未経験でも大丈夫ですよ」の一言は、筆者も素直に受け入れることはできませんでした。 開発経験が4年間しかなかった自分に、内定をいただいたなんてもちろん嬉しい限りでした。ですが、都合のよすぎる話をすぐ疑ってしまう自分は考え始めました。 「最初は未経験者でも大丈夫だと言われて、後から全部一人で勉強して、全部自己責任で成果をちゃんと出せとは言われないよね？」 「データってそもそも集まっているのかな？材料がないところからいきなりAIをやろうとしているんじゃないよね？」 頭の片隅に残っている疑問が解消できないまま入社するのも良くないと思い、最後に実際のチーム体制と会社のビジョンについて聞いてみました。 以下、後の上司となる二方よりの返信です。 「画像処理のスペシャリストとプラットホーム・開発のスペシャリストがいるのでプロジェクトに参加していただき教育を行う」 「データが集められる仕組みを作るのと、協力してくださる取引先と信頼関係を築くのが第一フェーズでした。そろそろ第二フェーズに進んでもいいと感じているのでAIエンジニア枠を設けています。」 一気に安心できました。 繰り返しになりますが、機械学習のモデルは実装してみないと課題に適したものかどうかが分かりません。評価してみた結果、理想の数値に至らずに作り直しになることだって当然あります。時間＝コストがかかるため、AIは「売り上げに困っているビジネスを救うもの」でもなければ、「教育できる先輩がいなくてもなんとなく始められるもの」でもありません。 なので、私がこの手の仕事に挑むなら、 知恵が貯まっており、教育していただける環境であること と 開発に協力していただけるお客様と組んで効率的な開発ができる環境であること の二条件はどうしても譲れませんでした。 いただいた返信を信じ入社を決めて、結果的にAIの知識をしっかり身に着けながら、エンジニアリングがより楽しく思える環境で働いています。 因みに、いいメンターに出会えると、一ヶ月ぐらいで以下の簡単な物体検出デモが作れるようになります： 最後に 以上、イメージングシステムグループの一部の業務と入社を決めた理由を紹介させていただきました。AIに携わりたいという気持ちになっていただけた方が一人でもいれば幸いです。 さらに多くのアルゴリズムを一緒に試してAIプラットホームを構築できる開発仲間をお待ちしております！ open.talentio.com

デザイナーの木下です。2020年5月から主に Safie Viewer［セーフィービューアー（Webアプリケーション）］ のユーザーインターフェイスデザインを担当しています。Safie Viewerのカメラ一覧画面の機能追加およびデザイン変更を機に、ユーザーインターフェイスデザインの改善を担当し始めました。 Safie Viewerのカメラ一覧画面の機能追加とデザイン変更にあたり、Safie Viewer全体のデザイン改善に向けて意識したことや良かったことを振り返ってみます。 デザインを担当する前の状況と前提 意識したこと それはなぜか プロジェクトを進めるうえで良かったこと 既存の仕様やUIデザインの経緯を知ってから進めることで、段階的な改善を進めやすくなった アップデートを続けやすい共有の仕様書（要件定義書）を用意してから進めた デザインガイドラインに沿って一般的なUIデザインに沿う表現に近づけた 事例：レイアウトを一般的な表現に変えた カメラ一覧画面：デザイン変更前 カメラ一覧画面（サムネイル表示）：デザイン変更後 カメラ一覧画面（リスト表示）：新規追加 カメラ一覧画面の動き デザインシステムを少しずつ導入 実装後の細かな調整によってUIデザイン品質を高められた 仕様書（要件定義書）に経緯を残した 状況に応じたちょうど良いバランスを意識した UIデザインの視覚的な品質を高めるために 今後改善したいこと さいごに デザインを担当する前の状況と前提 現在のSafie Viewer（Webアプリケーション）は2017年に開発が始まり、すでに約2年半サービスが稼働している（2020年5月時点）。 お使いいただいているカメラ台数はユーザーによって差があり、1台をお使いの方や1,000台以上をお使いの方など幅広い。 2020年5月まではSafie Viewerのユーザーインターフェイスは、エンジニアがデザインも実装も担当されていた。 デザイン変更前のSafie Viewerのカメラ一覧画面 Safie Viewerの全体的なデザイン改善を想定しつつ、直近の機能追加開発に向けたカメラ一覧画面のデザイン変更に着手しました。その際に意識したことや良かったことをまとめます。 意識したこと 以下はカメラ一覧の機能追加にあたり、デザインを整えるうえで主に意識したことです。 既存ユーザーの使い勝手に影響しすぎないように、元のUI（ユーザーインターフェイス）デザインから一気には変えない。 今のUIデザインや仕様がなぜこうなっているかの経緯や理由を知る。そのために実際にSafie Viewer（Webアプリケーション）を触りつつ、疑問に思ったことをエンジニアに聞いて仕様や仕組みを確認しながら進める。 今後の理想形とするユーザーインターフェイスをある程度イメージしたうえで、使いやすさ、実装工数、公開スケジュールなどのバランスを見て現時点に適したユーザーインターフェイスを設計する。 一般的なユーザーインターフェイスに沿った見た目や操作性に近づける。その際にAppleの Human Interface Guidelines （ヒューマンインターフェイスガイドライン）やGoogleの Material Design （マテリアルデザイン）などのデザインガイドラインを参考にする。 今後のSafie Viewer全体のデザインを統一しやすくするための仕組みをつくりはじめる。例えば配色、余白の大きさ、文字サイズ、UIパーツ表現などの各種ルールづくりなど。 ダークテーマのデザインルール設計のタイミング（ダークテーマの刷新は急ぎではないと判断した。一方でダークテーマの配色はあらかじめ検討材料とした）。 オブジェクト指向UIデザインの考え方に基づいた設計。 これらを段階的に進めやすくする。 それはなぜか 以下が主な理由です。 セーフィーは防犯目的以外にも、医療機関や工事現場で見守りや安全管理のためにも活用いただいている。ユーザーインターフェイスの変更で業務に支障が出てしまった際に、最悪の場合は 人命に関わる可能性があると考えた。よって急なユーザーインターフェイスの変更を避けて、段階的に改善していく 必要があると考えたため。 ビジネス要件、バックエンド要件、カスタマーサポート要件、API仕様、既存のフロントエンド実装ルール、既存のコンポーネント（共通要素）の管理体制など、様々な要件や制約のもとで最適なユーザーインターフェイスを設計するためには、まず 現状がどんな経緯で、なぜこうなっているのか、どんな仕様なのかを細かく知ることが重要だと判断した ため。 長期的な改善を続けやすいデザインの仕組みづくり（デザインシステム）が必要だと考えたため。 これらの理由から、UIデザインの改善はいきなり理想形と考える状態に変えるのではなく、複数の要件を総合的に判断しながら段階的に整えていくと決めました。 カメラ一覧画面のデザイン変更の検証用プロトタイプ 現状のユーザーインターフェイスに慣れている既存ユーザーの使い心地を考慮し、一気に理想とするUIデザインへつくり変えられない点がゼロからユーザーインターフェイスを設計するよりも難しいと感じます。その一方で、複数要件を組み合わせるバランス感が必要になるという意味での面白さがあるかもしれません。 プロジェクトを進めるうえで良かったこと 上記の意識したことを元に、実際に試してみて良かったと感じることを振り返ってみます。 既存の仕様やUIデザインの経緯を知ってから進めることで、段階的な改善を進めやすくなった Safie Viewerを実際に使ってみて、 ユーザーとして使ってみた感想や疑問点を書き出し、疑問点や細かい仕様について、主にプロジェクトチームのエンジニアに経緯を聞くことから始めました 。例えば次のようなことです。 どんな目的の機能か 。 どのような使われ方を想定した機能か。 どこに影響があるか（ありそうか）。 システム仕様がどのようになっていて、どこまで変更が許容できそうか （例えば、検索の絞り込み条件はどうなっているか、データは何件まで保存できるか、削除時の挙動はどうなるか、出力される画像の解像度はいくつか、状態によってどのような変化があるかなど）。 エンジニアに教えていただいたこれらの内容を、共有できる仕様書としてまとめていきました。その仕様書は要件定義やプロトタイプ制作において、検証材料として活用できています。ユーザーにとって使いやすいユーザインターフェイスに近づけるために、商品企画やエンジニアと一緒に議論を重ねて検証しています。 特に 「システム的にどこまで変更が許容できそうか」は、既存のシステムを活かして改善できる範囲なのか、システム仕様から見直したほうが良いかの判断にもつながる ため、ユーザーインターフェイスを設計するうえで重要な点だと考えています。 アップデートを続けやすい共有の仕様書（要件定義書）を用意してから進めた Adobe XD（UIデザイン・プロトタイピングアプリケーション）でデザインのプロトタイプを制作して共有し、チームから受けたフィードバック内容をプロトタイプに反映する過程で機能の仕様書をアップデートし、エンジニアや商品企画、関連するプロジェクトのデザイナーとも認識を合わせながら進められました。 仕様書の例（ブログ掲載用のため情報にはモザイクをかけています） 検索機能の仕様例 デザインガイドラインに沿って一般的なUIデザインに沿う表現に近づけた 使いやすさ向上のため、一般的に広く知られていて、ユーザーが使い慣れている可能性が高いユーザーインターフェイスの表現に近づくように設計したいと考えています。 AppleのHuman Interface Guidelines（ヒューマンインターフェイスガイドライン）やGoogleのMaterial Design（マテリアルデザイン）などのデザインガイドラインを参考にしつつ、 全体的な統一感や一貫性の維持を目指しています 。 事例：レイアウトを一般的な表現に変えた デザイン変更前のカメラ一覧では、カメラごとの情報として上から、タイトル、各種アイコン、サムネイル、タグの順番でレイアウトされており、一般的なカードレイアウトの並びとは異なっていることに違和感を感じていました。 カメラ一覧画面：デザイン変更前 既存のユーザーインターフェイスから比較的大きなレイアウト変更になるのですが、長期的には一般的なカードレイアウトに沿ったほうがカメラごとの情報のまとまりとして認識しやすくなると判断して、サムネイル、タイトル、各種アイコン、タグの順番に変更しました。以下がデザイン変更後の画面です。 カメラ一覧画面（サムネイル表示）：デザイン変更後 細かい変更点としては背景色や余白の大きさ、ボタンの配色なども改善しています カメラブロックの比較 ユーザーからいただいた「より多くのカメラを一覧で見たい」という要望に応えるため、リスト表示の画面も開発し、リスト表示とサムネイル表示を切り替え可能にしています。以下はリスト表示の画面です。 カメラ一覧画面（リスト表示）：新規追加 カメラ一覧のレイアウトは今後スナップショット（静止画）やムービークリップ（動画）など、他の機能の画面レイアウトにもコンポーネント（共通要素）として活用できると考え、エンジニアと議論を重ねながら他画面への統一化を見据えて設計しています。 カメラ一覧画面の動き 実際の画面は Safie Viewerのデモサイト で体験できます。 この記事を書いている時点ではスナップショット機能の画面デザイン変更をしているところなのですが、カメラ一覧と同様のコンポーネントを活かして、デザインの統一化を進めています。 デザインシステムを少しずつ導入 第1段階として次のことから始めました。 要素や余白の大きさは基本的に8pxの倍数で設計し、デザインとコーディングの秩序と開発効率を向上。 配色システムの設計（まずはプライマリーカラーとテキスト色の設計から）。 ボタン要素の優先度表現の整理（少しずつ反映中）。 自分がデザインを担当する時点で全体的な配色ルールはまだ定まっておらず、場所によって微妙に使われている色が異なっていたり、強弱が一般的なルールとは異なっていたりしました。 そこで長期的なデザイン改善に向けて、全体的な配色ルールを設計して統一化を図りたいと考えました。 すでに多くの箇所でUIパーツとして使われており影響範囲が広い状態のため、一気に全てを変えるのではなく、プロジェクトごとに段階的に整えていくことにしました。長期的に全体の統一感を維持できるように進めています。 構築中の配色システム（カラーコンポーネント） 例えば開発効率化のためにAdobe XDのデザインデータで使用する配色のコンポーネント名とSass（SCSS）の変数名をなるべく合わせたり、定義箇所を整理したりしてチームのエンジニアと相談しつつ開発を進めやすい仕組みづくりと効率化を図っています。 実装後の細かな調整によってUIデザイン品質を高められた オンスクリーンのUIデザイン品質を高めるためには、コーディングにおけるディテールの追求（細部のつくり込み）が求められます。 ディテール（Detail）の追求には意図したデザインを再現するための丁寧なコーディング調整、表示検証の繰り返し、インタラクションの心地良さの検証などが必要 です。 以上の工程には実装難易度や実装工数が増える課題があります。その課題への対策として、まずはデザインで特に改善したいポイントをエンジニアに伝え、 実装に対しての工数について相談させていただき、実装優先度を判断してUIデザイン品質と実装工数バランスの維持 を図りました。 チームのエンジニアに、要素によっては1px〜2px単位の位置・サイズ調整（※基本は8の倍数pxで設計しています）や50ms（ミリ秒）単位の細かなインタラクション調整相談をしています。これはデザイン品質向上のためです。粘り強く対応していただき、とても感謝しています。 実装していただいたのちのデバッグおよびレイアウト調整依頼時の画面キャプチャ例。赤い線に揃ったレイアウトへの調整をお願いしました。2pxの位置調整のため、拡大した状態で画面キャプチャを撮って伝えています Webサイトでビジュアルデザインを再現する実装について、大まかな流れを補足します。完成度を高めるためには、ブラウザによって表示結果が微妙に異なる挙動をHTMLやCSS、JavaScriptでコーディングによって制御しつつ、デザインデータに沿ったビジュアルデザインを再現し、心地良いインタラクションの実装などが必要です。 さらには各種フレームワークやライブラリを理解し、管理しやすい効率的なコンポーネント（共通要素）を設計するなど、 長期的にUIデザインやシステムを維持するためのコーディング（実装）は、デザインの知識や観点も必要 です。熟練度が必要で難易度が高いことです。相談に乗っていただき、丁寧に実装していただいているチームのエンジニアに感謝しています。 ではなぜそこまでやるのか？ それは ユーザーにとって使い心地の良いユーザーインターフェイスを提供し、サービス品質を高めるため です。細かい要素（Detail）の積み重ねがアプリケーションの使い心地の良さにつながると考えています。 仕様書（要件定義書）に経緯を残した 「経緯を残す」ことに注力しました。機能やデザインに対して、なぜこの機能が存在するのか、どういうときに使われるのか、仕様はどうなっているのか、なぜこのデザインにしたのかの経緯をなるべく資料として残すようにしています。 理由は、今後の改善に向けて 各メンバーが「なぜ今こうなっているのか」の経緯を把握しやすくするため です。仕様と経緯がわかりやすくまとまっていることで、「何をどこまで変えて良いのか」という点でUIデザインやシステム改善時の品質向上に役立ち、開発速度も上がるメリットがあると考えます。 これまでは現状の機能が詳しく明文化された仕様書が存在しなかったり、情報が不足していたりする課題がありました。その際には機能を試し、仕様をヒアリングして理解する工程が必要です。初動の調査（リサーチ）の時間が想定よりも長くかかる点が課題でした。 この課題を解決するため、 今進めているプロジェクトからは仕様書（要件定義書）の土台を最初に作成してから進めています 。最終的に確定したデザインや仕様に加えて、「なぜこうしたか」のデザインの意図や経緯、システム要件やビジネス要件の経緯、議事録の過程などに後からアクセスしやすい資料のまとめかたを意識しています。 状況に応じたちょうど良いバランスを意識した ビジネス要件、システム要件、ユーザーインターフェイスとしての使いやすさ、公開のタイミング（スケジュール）、今後の拡張性など、状況によっては相反する要素に対してちょうど良いバランスを維持できるように意識しました。これにより 「長期的に実現したいこと」と、「今求められていること」の優先順位付けがしやすくなった と感じます。 UIデザインの視覚的な品質を高めるために WebアプリケーションにおけるUIデザインの視覚的な品質を決める要因は、最終的なコーディング（実装）の品質であり、ブラウザのレンダリング結果（表示結果）の調整だと考えています。より具体的には次の点です。 ブラウザのレンダリング結果（表示結果）とデザインデータを見比べて、 コーディング後の細かな調整をどれだけおこなえるか 。 インタラクションをどれだけ心地良いものにできるか 。 なぜならブラウザのレンダリング結果がユーザーが触れるもの（ユーザーインターフェイス）であり、ユーザーにとってのUIデザインだと考えるためです。 オンスクリーンのUIデザインにおけるデザインデータやプロトタイプは、Adobe XDやIllustratorなどのデザインアプリケーションによって制作していますが、それはコーディングのためのデザイン見本と捉えています。ゆえに コーディング後のデザイン調整が重要 だと考えます。 今後改善したいこと スケジュールの明確化。スケジュールを明確化していない状態でプロジェクトが走り出してしまい、後工程で間に合わせるような形になってしまうことがあった。今後の改善として、プロジェクト開始時にスケジュールをより詳細化して進める（実践中）。 サービス全体のアイコンのデザイン統一化。影響範囲が広いため、徐々に改善を進める（長期的に改善中）。 全体的な配色設計と統一化。 余白（スペーシング）のルール化。 タイポグラフィシステムの構築。 ダークテーマの設計。 まだまだできていないことがあり、やりたいことや改善したいことはたくさんあります。統一感のあるデザインシステムを設計し、長期的な改善を続けやすい仕組みづくりのために少しずつ進んでいきたいと思います。 プロジェクトの進め方自体も見直し、要件定義書の作成・アップデートや共有方法など、 チームとして複数人で効率的に進めていけるプロジェクト体制づくり も進めています。プロジェクトの進め方で良い方法を他のチームにも共有し、相互に改善を繰り返していけるように仕組み化できたらと考えています。 さいごに 役職はデザイナーですが、実際にやってきたことを振り返ってみると、 課題解決のためにビジュアルデザイン以外にも挑戦することはたくさんありました 。例えば、要件定義、システム仕様策定、プロトタイプ制作、デザインカンプ制作、インタラクション設計、フロントエンド実装（別プロジェクトで）、デバッグ、サービスや機能の提案、ディレクションなどです。 セーフィーではデザイナーも募集しています。自分はセーフィーに所属してからまだ1年半ほどですが、タイポグラフィや配色などのデザインシステム構築、コーディング、システム仕様設計など、領域を制限せず多くのことに興味のあるUIデザイナーに向いている環境かと思います。 ご興味のある方、これから経験を積みたいと考えている方の連絡もお待ちしています。 open.talentio.com

こんにちは！セーフィー株式会社オペレーションシステム部の大林です。 私は2019年9月に実務未経験からエンジニアとしてセーフィーに入社しました。ちょうど1年が経った頃なので、この1年間でやってきたことや感じてきたことを紹介してみようと思います！ まずは自己紹介 オペレーションシステム部って？ 1ヶ月目 Vue.jsとにらめっこ 3ヶ月目 独り立ち！？ 辛い時期もあった 5ヶ月目 サーバーサイド 6ヶ月目 レンタルシステム化PJ Salesforceとの出会い そして今 さいごに まずは自己紹介 簡単に私の経歴をご紹介します。 大学（文学部）卒業後、大手証券会社に入社 地方総合職として、地元の支店で4年間個人向け営業 エンジニアになろうと決意し、退職して上京 プログラミングスクールで約3ヶ月間HTML/CSSやRuby on Railsを学習 そして転職活動を開始して初めて面接を受けたのがセーフィーでした。 CTOからの技術的な質問にまともに答えられず、帰り道「おわた……」と思ったのも今ではいい思い出です。 そんな中、面接の翌日に「まずはアルバイトで働きませんか」とオファーがありました。 当時は私のように実務未経験から入社したエンジニアがおらず、ポテンシャル枠の採用は初めてだからまずはアルバイトでお互いにミスマッチでないか様子を見ましょう、とのことでした。 その後2週間ほどして正式に内定をもらい、今に至ります。 オペレーションシステム部って？ 今まではサービス開発寄りの記事が多かったので、セーフィーのオペレーションシステム部についても簡単に紹介します。 オペレーションシステム部が関わる業務は、ものすごくざっくりですがこんな感じです。 フロントオフィス業務に関しては、マーケティングや営業支援、契約・請求・出荷管理などのシステムとしてSalesforceを利用しています。 またセーフィーでは多くのパートナー企業さまにサービスをOEMで提供しています。パートナー企業さま向けのエンドユーザー管理ツール（Agency Tool）や社内向けの管理ツール（Management Tool）は内製のシステムです。 これらのシステムの管理や運用、機能拡充を行いながら、スプレッドシード管理になっている業務のシステム化や各種連携などを進めています。 右下の Safie Entrance 管理ツールについては、厳密に言うとオペレーションシステム部の管轄ではないのですが、私がフロントエンド開発に携わっているので載せました。 では、私がこの一年で関わってきた順に紹介していきます！ 1ヶ月目 Vue.jsとにらめっこ 2019年9月にアルバイトとして入社し、まずはじめはフロントエンドエンジニアとしてAgency Tool・Management Toolの刷新プロジェクトに携わりました。そこから約半年間、メインの業務としていました。 言語はVue.js+TypeScriptです。これらの私の経験値はほぼ0でした。 Vue.jsについてはスクール在籍中に興味を持ち少しだけ独学していたもののVuexは使ったことがなく、TypeScriptに関しては恥ずかしながら名前だけは知っている程度でした…… 私が入るまでは、Agency Tool・Management Toolのフロントエンド開発は一人の先輩が担当していて、その先輩の下に付く形でスタートすることになりました。 今でも覚えているのは、アルバイト2日目に初めてプルリクを出したときのこと。 思い返すとタスクとしてはものすごく簡単で、今なら30分もあれば余裕で終わるようなものでしたが、当時は全然分からなくて先輩にほぼ半日つきっきりで一緒にやってもらいました…… でも、コードを書いて、それが動いて、人が使ってくれる、という実感がわいてとても嬉しかったです。 そういう嬉しさの反面、やはり大変なこともありました。 まずは、個人で開発するのとは全くスケールの違うコード量に圧倒されました。既存のコードのどこに何が書いてあるのか紐解くのに必死でした。 しかも周りにいるエンジニア達と自分のレベルの差があまりにも大きいことを勝手に感じすぎて、精神的にも縮こまってしまいました。 今思えば、そんなの分かりきっているんだからもっと割り切って過ごしても良かったですね。 CTOも先輩もよくこう言ってくれていました また、今は入社時の研修でカメラのことやサービスのこと、使うツールのことなどを知る機会があり仕様書もたくさんまとまっているのですが、当時はそこまで整備されておらず、私はただコードとしか向き合っていなかったのも良くなかったなと思います。木を見て森を見ず、ってやつです。 はじめにもっと会社全体のサービス概要や自分が開発しているものの目的を把握していれば……！と思うことがよくありました。なので今は教訓として 新しいことを始めるときはまず全体感を把握するようにしています。 ある時ふと、スクールで学習したこと何も使ってなくない……？と思いましたが、Slackでのコミュニケーションの取り方やGitHubの使い方などに慣れていたことなど、プログラミング以外の部分でも多いに役立っていました。 それに一番大きかったのは「未知のことに立ち向かうことが楽しいと思えるマインド」が育っていたことかもしれません。 当時Twitterで「未経験からエンジニアになった人のうち一定数は数ヶ月で消える」というのをよく目にしていて、消える人の気持ちもちょっぴりわかる……と思ってしまった時期もありました。 でも前職で培ったメンタルと、スクール時代に培ったマインドのおかげで、生き抜くことができました。 3ヶ月目 独り立ち！？ 3ヶ月目に、 Safie Entrance のお客様向け管理ツールのフロントエンド担当にアサインされました。今も継続して担当しています。 フロントエンドの担当は私だけだと知って、えっ！？不安……と思いましたが、Agency Tool・Management Toolと同じVue.js+TypeScriptでの開発で共通のコンポーネント使うこともできたので、それまでの経験を生かすことができました。 一方で、自分の理解が曖昧なまま進めてしまうと、何度もPMに仕様を確認したり、サーバーサイドに何度もAPIを改修してもらったり、と手戻りが発生してしまうということに気づき、これまでは先輩にタスクを振ってもらっている受け身にすぎなかったんだ……ということを痛感しました。 でも、他のチームの人とコミュニケーションを取りながら開発していくのは楽しく、私エンジニアになったんだな〜としみじみ感じることもできました。 辛い時期もあった このあたりの時期にはオペレーションシステム部の一員らしく、業務フロー全体を見直すようなミーティングにも参加するようになりました。 それは私にとって興味深くもあったけど辛い時間でもありました。 IT用語もカメラのことも分からない、ビジネス用語も分からない、業務フローも全然知らない……ただひたすら聞くだけで自分は何もできない時間がほとんどだったからです。 今はエンジニア含め他業界・他職種からの転職組も増えてきましたが、当時は会社全体を見てもそういう人は少なく、私からするとみんながスペシャリストに見えました。 ビジネスのことも知らない、エンジニアとしてもまだまだ、そんな私の存在価値って何なんだろう……と考えて無能感に苛まれたこともあります。 当時の私に言葉をかけることができるなら、「そんなこと分かり切ってるんだからうじうじ考えてる暇があれば勉強でも何でもして少しでも早くできるようになれ！」と言いたいです。 5ヶ月目 サーバーサイド 年明けあたりから数ヶ月、サーバーサイドにも携わり、Agency Tool・Management Toolで使っているAPIの作成や改修を行った時期がありました。 言語はPython、フレームワークはTornadoです。これらの私の経験値はほぼ0でした（2回目）。 PythonはProgateをやったことがあるだけで、Tornadoは存在すら知りませんでした。 既存のコードの見よう見まねでなんとか実装し、先輩方のレビューで無数の指摘をもらい、自分の知識の足りなさや考慮の浅さに向き合いながらもがいていました。 でも入社してVue.jsとにらめっこしている時よりは既存のコードの理解が早くできるようになっていて、言語が違っても一度できるようになったことは活かせるんだなーと思って嬉しかったです。 また、それまでのフロントエンド開発ではデータベース構成を意識することなくAPIのレスポンスだけを見ていたので、データベース構成について知ることができたのも良かったです。むしろもっと早く知るべきでした…… それに、自分がフロントから呼んでいるAPIのサーバーサイドの構成が把握できたことで、フロントの開発もしやすくなりました。 たとえサーバーサイドの開発にがっつり携わるわけでなくても、構成を把握してコードを読めるようになったり、簡単なタスクをやってみたりするのは非常に役立つことだなと思いました。 6ヶ月目 レンタルシステム化PJ 2月からの約半年間は、レンタル管理のシステム化プロジェクトがメインの業務となりました。 セーフィーではカメラのレンタルも行っているのですが、その管理はスプレッドシートで行われており、受注から請求に至るまで手作業が非常に多く、これからレンタル件数が増えるにあたりシステム化は急務でした。 最初は現在の業務のヒアリングから始まったのですが、またも同じ苦しみを味わうことになりました。 私、セーフィーの業務・カメラについて全然知らないじゃん……注文があって、カメラ・サービスをセットしてお客様に提供して、そして売上計上して請求する、という一連の流れについて何も分かってない…… このままで大丈夫なのかという不安でいっぱいでしたが、オペレーションシステム部からは頼れる先輩（前述の先輩とは別）との2名体制だったのでなんとか食らいついていくことができました。 ヒアリングと並行して複数のシステムを比較検討した結果、販売で既に利用しているSalesforceに機能を追加することに決定。 開発は外部へ委託し、紆余曲折ありましたが、計画通り7月にリリースすることができました。 開発委託会社や社内の業務サイドとのコミュニケーションが大切なのはもちろんのこと、特に業務サイドとは、業務フローにおける例外はないのか・今後可変にできるように考慮しておくべき事項はないかなどを丁寧にやりとりし、システム化の範囲と機能についてのコンセンサスをきちんと取っておく必要があるんだと学びました。 このプロジェクトにおいて、現場へのヒアリングから始まり、スケジュール立てや要件定義、開発委託会社との調整や進捗確認、そして受入テスト＆運用テストを経てリリース＆データ移行、という一連の流れを経験でき、私の中で大きな経験となりました。 Salesforceとの出会い レンタルシステム化においてSalesforceを採用することになりましたが、私の経験値はほぼ0でした（3回目）。 それまで名前は知っていたけど、顧客管理をするものだよね？程度の認識でした。 いざ触ってみると、機能もめちゃくちゃたくさんあるしすごい便利！と思うのと同時に、裏側の設定とか処理とかどこをどういじれば……？というブラックボックス感も感じて不安になったのを覚えています。 3月から4月にかけてオンライン研修を計9日間受講したり、テスト環境でいろいろ試したり、既存の販売管理での簡単な改修タスクを行ったりする中でだんだんとできることが増えてきました。知らないことが分かってできるようになるというのは本当にいつでも楽しいです。 今もスキマ時間に Trailhead での学習をしていて、そこでのTrailblazerランクを今期の自分の評価項目に加えています。 研修を受けたり学習を行ったりすることを支援してくれて評価にもつながる環境はありがたいなぁと思います。 またSalesforceはユーザーコミュニティが充実していることにも驚きました。 先月には全国の活用事例チャンピオン大会がオンライン開催され、Salesforceをフル活用している企業の事例を聞くことができたり、五反田の利用企業の方々ともオンラインで懇親会をしたりと、自社の事例以外をいろいろ知ることができてとても興味深かったです。 そして今 そんなこんなでフロント〜サーバー、サービス寄り〜社内向け、と広く浅くいろいろとやってきた一年間でした。 今は、Salesforceに関わる新たなシステム化に取り組みつつ、レンタル管理の対応やSafie Entrance管理ツールのエンハンスを行っているという状況です。 正直なところ、エンジニアになる前に想像していた仕事とは違う部分もあります。 今の自分が何者かと聞かれると、おそらく答えは「業務系エンジニア」です。 が、エンジニアになるまでは「エンジニア＝サービスを作る人」というイメージが強く、Web系・組み込み系しか知りませんでした（というか、このブログを書く過程で先輩に教えてもらうまで、自分は何者なんだ？と思っていました）。 それに、コードを書きまくってフルスタックになるんや！と思っていた時期もありましたが、今の仕事でコードを書いている時間は半分もありません。 でも、オペレーションシステム部での今の仕事は自分の性にすごく合っていると自信を持って言えます。 意識的に選択してきた道ではなく、流れに身を任せていたらいつの間にか走っていた道ではあるけれど、結果的に楽しく働けていて、今後も進んでいきたい道だなと思っています。 ↑みんなありがとう！これからもよろしくね！ さいごに アクセンチュアで提唱された「シックスバブルズ」という考え方があります。 内容を簡単にまとめると、 戦略策定・ビジネスプロセス改善・組織改革・人材育成はすべてBehavior（ふるまい）を変えるためである ITはBehaviorを直接変えることはできない。あくまでもビジネスプロセスや組織を通じてBehaviorを変える というものです。 オペレーションシステム部の部長からこのシックスバブルズの考え方を聞いたのですが、部の役割・ミッションについて「ITでビジネスの戦闘力をあげること」と言っていました。 その考えにとても納得して、いつも心に留めて仕事をしています。 セーフィーのサービスに興味がある方はもちろん、一緒にビジネスの戦闘力をあげてくださる方からのご連絡、お待ちしております！ open.talentio.com

セーフィー株式会社要素技術開発部のおにきです。 クラウドカメラを用いた画像解析の開発を担当しています。 AWSのMLOps環境である Sagemaker について調査しました。試しに物体検出アルゴリズムである YOLOv4 の学習環境を作ってみたので紹介します。今回学習環境としてYOLOv4の著者Alexey Bochkovskiy氏が公開している ソースコード を利用しています。これはYOLOv3までの著者であるJoseph Redmon氏の開発していたフレームワークである Darknet をブランチしたものになります。 今回作成したコードは Github にあげているのでご参照ください。 Amazon Sagemaker Sagemakerによる学習 学習の処理の流れ カスタムコンテナの仕様 エントリーポイント 入力 出力 YOLOv4用にSagemakerでカスタムコンテナを用いた学習環境の作成 Step1 エントリーポイントの作成 Step2 Dockerfileの作成 Step3 ECRの準備 Step4 S3に学習データをアップロード Step5 学習の実行 学習結果 さいごに Amazon Sagemaker Amazon Sagemakerは機械学習を用いたサービスを実現するために、データ作成、モデル開発、学習実行、サービス運用といういわゆるMLOpsと呼ばれる業務を実現する環境を提供するAWSのサービスです。AWSのサービスなのでもちろんクラウド環境であり、初期費用が必要なく物理サーバーの管理が不要などのメリットがあります。 SagemakerはMLOpsを実現するための多様なツール・環境を提供しています。代表的な機能を上げると以下になります。 学習データ作成 学習 デプロイ エンドポイント構築 今回の記事ではSagemakerの学習機能を利用しています。 Sagemakerによる学習 Sagemakerによる学習ではGPUインスタンスを必要な時に必要なだけ利用できる点がメリットとしてあげられます。機械学習の開発ではモデルの比較やハイパーパラメタ比較のためにある一時期だけGPUマシンが必要となる場合がありますが、その時に必要な分だけGPUインスタンスを確保できます。 Sagemakerによる学習は以下の3つのパターンに分けられます。 組み込みアルゴリズムの利用 Amazonがすでに用意したアルゴリズムを利用します。開発者は学習データを用意するだけすみます。画像認識ではイメージ分類、オブジェクト検出、セマンティックセグメンテーションが用意されています。 構築済みのコンテナイメージの利用 Pythonを用いてTensorFlow、PyTorch、Chainer、MXNetなどのフレームワークが動作する学習用Dockerコンテナが用意されており、Pythonでアルゴリズムを開発する場合にはJupyter Notebookから学習インスタンスにアルゴリズムを自動で転送しての実行ができるなどスムーズな開発ができます。 独自のカスタムコンテナイメージの利用 開発者が独自のDockerコンテナを作成して学習インスタンスで実行させることができます。Dockerコンテナとしての仕様に合わせていればPython以外の言語でも学習を行うことができます。YOLOv4の学習環境であるDarknetはC言語+CUDA Cで実装されているため、今回は独自のカスタムコンテナイメージを利用した学習を選択しました。Pythonベースのアルゴリズムであっても一部C/C++によるMakeが必要な場合などは独自のカスタムコンテナイメージの利用が選択肢になります。 学習の処理の流れ Sagemakerによる独自のカスタムコンテナイメージを利用した学習を図にすると以下になります。 開発者は①のJupyter Notebookから学習実行をするだけで ② ～ ⑤ の処理は自動で行われます。 カスタムコンテナの仕様 カスタムコンテナを作成するためには、処理のエントリーポイント・入力・出力の仕様を抑えることが重要となります。この仕様に合わせさえすれば、様々なケースに対応したカスタムコンテを作成する事が可能になります。 エントリーポイント 学習インスタンス内ではコンテナイメージがダウンロードされたあとに以下のコマンドが実行されます。 docker run <image> train 上記のコマンドが呼ばれた場合に実行したい学習処理が起動するコンテナイメージを作成するには以下の2つの方法があります。 (1)コンテナイメージ内にtrainというファイル名で実行可能なファイルを配置する (2)DockerfileでENTRYPOINTを定義する どちらも大きな差はないので、今回は(2)の方法を採用しました。 入力 トレーニングデータ /opt/ml/input/data/<channel> S3においた学習データは上記のディレクトリにダウンロードされます。チャネルを利用することでデータを学習、バリデーション、テストなどに分けて扱うことが可能です。チャネルの名前は開発者が自由に選択することができます。今回はtrainだけを利用することにしました。 ハイパーパラメタ /opt/ml/input/config/hyperparameters.json Jupyter Notebookから起動する際にハイパーパラメタを渡すことができます。注意点としてJupyter Notebook側から数値型で値を与えても文字列型に変換されたjsonがコンテナに設置されます。Jupyter Notebookで学習処理を起動する際にグリッドサーチを行うことも可能です。 入力データ設定 /opt/ml/input/config/inputdataconfig.json 起動したコンテナがどのチャネルを利用できるかの情報を得ることができますが、今回はtrainだけを使用するため使用していません。 Amazon SageMaker がトレーニング情報を提供する方法 - Amazon SageMaker #入力データ設定 出力 学習済みモデルデータ /opt/ml/model 学習処理が終了した時点で上記のディレクトリ内にあるファイルがアーカイブ化されてS3にアップロードされます。 Sagemakerについてのより詳しい情報は以下を参照ください。 Amazon SageMaker で独自のアルゴリズムやモデルを使用する - Amazon SageMaker YOLOv4用にSagemakerでカスタムコンテナを用いた学習環境の作成 ここまではSagemakerの一般的な説明してきましたが、ここからはYOLOv4を学習するための環境の作成について説明します。 Sagemakerで利用するS3、ECR、Sagemaker ノートブックインスタンスはすべて同じリージョンで作成しないと動作しないのでご注意ください。 Step1 エントリーポイントの作成 コンテナイメージのエントリーポイントとしてmain.pyというPython3スクリプトを作成しました。 機械学習における本来的な意味でのハイパーパラメタではないのですが、dataファイルとcfgファイルのファイル名を読み取って、Darknetの引数として起動しています。 Step2 Dockerfileの作成 コンテナイメージ作成用に以下のDockerfileを作成しました。 上記のDockerfileでは、DarknetがGPU、cuDNN、OpenCVを利用できるようMakefileを書き換えてビルドしています。 Step3 ECRの準備 ECRにレポジトリを作成します。dockerコマンドを用いてイメージを作成して、レポジトリにプッシュします。 $ aws ecr get-login-password --region us-west-2 | docker login --username AWS --password-stdin xxxx.dkr.ecr.us-west-2.amazonaws.com $ docker build -t darknet-yolov4 . $ docker tag darknet-yolov4:latest xxxx.dkr.ecr.us-west-2.amazonaws.com/darknet-yolov4:latest $ docker push xxxx.dkr.ecr.us-west-2.amazonaws.com/darknet-yolov4:latest Step4 S3に学習データをアップロード 学習データをS3にアップロードします。 $ aws s3 cp dataset/ s3://sagemaker-xxxx/dataset --recursive Darknetでは画像データのパスをdataファイルに記載する必要があるため、dataファイルにはSagemakerのコンテナイメージでの絶対パスとして記述しました。 Darknetではbackupがモデルファイルの出力先であるため、 /opt/ml/model/ に指定しています。 classes= 1 train = /opt/ml/input/data/train/train.txt valid = /opt/ml/input/data/train/test.txt names = /opt/ml/input/data/train/classes.txt backup = /opt/ml/model/ train.txtは同様に絶対パスで記述しています。 /opt/ml/input/data/train/camera/000.jpg /opt/ml/input/data/train/camera/001.jpg /opt/ml/input/data/train/camera/002.jpg ・・・ このあたりのファイルパスの扱いはmain.pyで自動生成するなど改善の余地はありそうです。 yolov4-custom.cfgは Github のファイルをもとに作成しました。 S3にアップロードしたファイルは以下の構造です。 s3://sagemaker-xxxx └── train ├── camera │ ├── 000.jpg │ ├── 000.txt │ ├── 001.jpg │ ├── 001.txt │ ・・・ │ ├── camera.data ├── classes.txt ├── test.txt ├── train.txt └── yolov4-custom.cfg Step5 学習の実行 AWSのコンソールでSagemaker > ノートブックインスタンスでノートブックインスタンスの作成を行います。ノートブックインスタンス自体は学習を行わないのでインスタンスのタイプは一番安いml.t2.mediumで十分です。Jupyter上にノートブック作成する際には「conda_python3」を選択しました。 Jupyter Notebook上から学習の実行を行います。以下のコードでは先ほど作成したエントリーポイント（main.py）に渡すハイパーパラメタとしてdataファイルとcfgファイルを設定しています。 estimator = Estimator( image_name= "xxxx.dkr.ecr.us-west-2.amazonaws.com/darknet-yolov4:latest" , role=role, train_instance_type= "ml.g4dn.xlarge" , train_instance_count= 1 , train_max_run = 3 * 60 * 60 , hyperparameters={ "data_file" : "camera.data" , "cfg_file" : "yolov4-custom.cfg" } ) estimator.fit({ "train" : "s3://sagemaker-xxxx/dataset/" }) ml.g4dn.xlargeはGPUが利用できるインスタンスタイプとしては最安（オレゴンで0.736$/時）ですが、16GBという大きなGPUメモリが利用できます。 学習中の状態はAWSのコンソールのSageMaker > トレーニングジョブで確認することもできます。 学習結果 学習処理が終了すると結果であるモデルファイルはS3にアップロードされます。 Sagemakerで学習したYOLOv4のモデルで推論してみた結果です。今回はお試しとして、弊社で扱っているセキュリティカメラの画像から学習データを作成し、学習処理を行ってみました。 さいごに 今回はクラウドのMLOps環境であるAWSのSagemakerを利用してYOLOv4の学習を行う環境を作成しました。クラウド環境を利用することで一時的に大量の学習インスタンスを確保するといった柔軟な開発が可能になるかと思います。今回は学習処理についてだけ扱いましたが、Sagemakerを適切に利用することで機械学習を用いた製品を効率よく開発・運用できるのではないかと考えています。 セーフィーでは現在数万台のセキュリティカメラが弊社システムに接続されており、これらのカメラから画像認識技術を用いて情報を抽出するサービスを開発しています。そのために一緒に開発を進めていくメンバーを募集しています。 open.talentio.com

初めまして、こんにちは。 セーフィー株式会社 プラットフォーム開発部の大友です。 サーバーサイド周りの開発を担当しています。 今回はユーザーより問い合わせを受け、システム内を調べなければならないとき、サーバーサイドはどのように対応しているのか！その一例を紹介したいと思います。 テーマはログ解析を用いた問い合わせ対応です。 Amazon Athena と お問い合わせ Athenaの注意点 セーフィーの構成 さいごに Amazon Athena と お問い合わせ 今回の主役となるサービスです。 セーフィーではログ解析の一つに Amazon Athena を使用しています。 Athenaについて簡単に説明しますと、S3 に保存したログデータに対して SQL を実行し、ログの解析が行えるというサービスになります。解析したいログの形式に合わせた Athenaのテーブルを作成しておき、テーブルに対して SQL を発行することで結果を得えることが出来ます。 セーフィーでは、サーバーログを S3 に保管しているので、Athenaは打ってつけでした。 例えば、 Safie Viewer を操作してカメラ映像の閲覧であったり、カメラ設定を変更したりすると、裏側ではRESTful APIが実行され、都度以下のようにJSON形式で実行ログが出力されています。 (重要なセキュリティ情報を含んだAPIパラメーターはマスキングを施してからログ出力しています。 マスキング されたデータはセーフィーでも確認できません。そして、以下のログは完全なダミーです。) {"timestamp": "2020-08-14T11:22:33+09:00", "camera_id": "camera1", "api": "/image", "method": "GET", "parameter": null, "user": "user1", "ua": "chrome"} {"timestamp": "2020-08-14T11:22:34+09:00", "camera_id": "camera2", "api": "/setting", "method": "POST" , "parameter": "name=hoge", "user": "share-user", "ua": "chrome"} {"timestamp": "2020-08-14T11:22:35+09:00", "camera_id": "camera3", "api": "/video", "method": "GET", "parameter": null, "user": "user2", "ua": "chrome"} (中略) {"timestamp": "2020-08-16T20:10:44+09:00", "camera_id": "camera1", "api": "/image", "method": "GET", "parameter": null, "user": "user1", "ua": "chrome"} {"timestamp": "2020-08-16T20:10:45+09:00", "camera_id": "camera2", "api": "/setting", "method": "POST" , "parameter": "name=camera2", "user": "owner-user", "ua": "chrome"} {"timestamp": "2020-08-16T20:10:46+09:00", "camera_id": "camera3", "api": "/video", "method": "GET", "parameter": null, "user": "user2", "ua": "chrome"} camera_idというのは、ユーザーが所持しているカメラの固有IDになります。 もし「気づいたらcamera2の名前が変わっていたので元に戻しました。7月は名前は変わってなかったです。いつ名前が変わったのか調べて欲しい。」という問い合わせが発生したらAthenaで以下のSQLを実行します。 SELECT * FROM safie.test_log WHERE dt >= '2020-08-01' AND camera_id='camera2' すると、camera2に対しての操作ログを取得できます。 (dt >= '2020-08-01'は 2020-08-01 以降に出力されたログから検索するという意味になります) 検索した結果以下のログが引っ掛かりました。 {"timestamp": "2020-08-14T11:22:34+09:00", "camera_id": "camera2", "api": "/setting", "method": "POST" , "parameter": "name=hoge", "user": "share-user", "ua": "chrome"} {"timestamp": "2020-08-16T20:10:45+09:00", "camera_id": "camera2", "api": "/setting", "method": "POST" , "parameter": "name=camera2", "user": "owner-user", "ua": "chrome"} ( ここで、/setting はカメラの名前を変更できるAPIだとします。) 名前が二回変更されていますね。ログを下から見ていきましょう。 名前を元に戻したとの事なので、二件目の 2020-08-16 20:10:45 の時間に記録されているログはカメラの名前を元に戻すために操作した履歴だと分かります。変更したユーザーは owner-user さんです。 次に一件目の 2020-08-14 11:22:34 の時間帯にも、カメラ名が変更されています。 名前を変更したのは share-user さんです。 セーフィーのカメラは シェア することができるため、今回の問い合わせではカメラをシェアされたshare-userさんがカメラ名を変更したことが分かりました (カメラをシェアする際には、シェアの権限が設定できます)。 セーフィーでのAthenaを使った解析はおおまかにこのような流れになります。 (実運用では毎回 SQL を書いて実行するのは面倒なので、調べたい箇所だけを入力したら 検索する別Toolがあり、SQLを直接書くことは滅多にありません。) 上記例ではログのサンプルが少ないため便利さに疑問符が残るかもしれません。 セーフィーではAthena解析に使うことになるログは、一日辺り圧縮して平均2GBほど溜まります。そんなログの塊をAthenaで一か月分解析を行ったとしても、解析時間は1分程度も掛かりませんし、一か月分のログから、調査のための有意義な情報を得られると考えれば、Athenaの強力さが伝わるのではないでしょうか。 Athenaの注意点 Athenaを沢山褒めてしまいましたが、使う上で気を付けることがあります。 それはコストです。 Athenaは使えば使うほどお金が取られる従量課金 なので、きちんと パーティション を設定し、パーティションに合わせてログを保存する必要があります。 パーティションの設定が無いと、Athenaでの検索は都度全てのログデータに対して行われるため 常に全検索 となります。それではコストが嵩んでしまいます。 パーティションを設定すると、いつから～いつまで と検索する範囲を絞り込むことができます。絞り込むことで発生するコストは最小限に抑えられます。 文章だけだと中々イメージが湧きませんね。パーティション無と有の比較図を用意しました。 パーティション設定の有無でS3に保存するパスが若干異なっていることが分かります。設定有にある、 dt=2020-08-01 は Apache Hive 形式と呼ばれ、パーティションを利用する時は、このHiveを用いてデータを保管していく必要があります。HiveのdtはSQLの条件式に書くことができるので、 dt>='2020-08-03’ AND dt <= ‘2020-08-04’ とすると、8/3と8/4分のログのみに絞って、解析することが可能になるわけです。 次の章では、セーフィーがどのようにログをS3まで運んでいるのかを紹介したいと思います。 セーフィーの構成 セーフィーのサーバーは全てAWS上に構築されていて優に三桁の数のEC2インスタンスが立ち上がっています。 サーバーにも沢山の種類があり、カメラの制御や映像を扱うCamサーバー APIを提供するAPIサーバー、動画の配信を司る配信サーバー等が存在します。 (まだまだサーバーは存在しますが、ここでは割愛します) ログを扱うのは、 logサーバーになります。 以下は構成図です。 構成図を見ると特に複雑なことはしていませんね。 logサーバーは全サーバーログのAggregatorです。ログを収集し、S3の保存からElastic searchへの転送を担っています。logサーバーが収集しているログは、Athenaで分析できるログのほかにも、各サーバーで動作している専用アプリケーションのログに監視ログなど、稼働ログ全般に渡ります。そして、ログ収集にはfluentdを利用しています。(一部 fluent bitも存在します) Athenaのログはパーティションが働く形(s3://athena/logs/dt=2020-08-14/app.log.tar.gz.1)で保存されていきます。新しいパーティションが増えたら(dt=2020-08-15)、Athenaテーブルのパーティション情報を更新する必要があるため、セーフィーではCIの定期実行にてこれを 行っています。(コマンドは MSCK REPAIR TABLE です) ここまでを行い、セーフィーでは日頃Athenaを問い合わせに活用しています。 パーティション更新はCIでなくても、AWS lambda や、最近ですと AWS Glueを利用した方法があります。いずれもコストが発生しますが、AWS Glueが良いようです。 さいごに Athenaを活用した問い合わせ対応については以上となります。 今回はAthenaを用いてAPIの実行ログを遡って検索し、カメラに対しての操作履歴を確認することが出来ました。いつどうなった系の問い合わせには無類の強さを発揮するAthenaですが、カメラ映像が起因した問い合わせ(映像が暗すぎる、明るすぎる等)には活用場面があまり無く、あくまで解決するための一種のツールとして利用しています。(カメラ映像に起因した問い合わせは、サポートチームに映像をシェアして頂き、実際に映像を拝見した上で対処方法を案内しています。) Athenaが便利でとても使えることが分かると、今ではAthenaで検索する前提で開発を行う場面もあり、まだまだ社内でも活躍の場は広がりそうです。 そして最後に。セーフィーは常により良いサービスにするべく、日々進化しています。セーフィーを更に良いサービスにしたい、自分のスキルで課題を解決したい。そんな意識をお持ちの方や、向上心が高い方を歓迎しています。ご興味のある方のご連絡をお待ちしてます。 ここまでお目通しいただき有難うございました。 open.talentio.com

こんにちは！セーフィー株式会社サービス開発部 きむらです。 セーフィーのECサイト 構築や、このブログの校正とか色々やっています。 今回は、普段の記事とはちょっと趣向を変えて、セーフィーの社内風景についてご紹介していこうと思います。どんな雰囲気なのか少しでも感じ取ってもらえれば幸いです。 クラウドカメラに囲まれた生活 ケースその１ ー 顔認証で勤怠管理 ケースその２ ー コロナ禍での電話会議 ケースその３ ー 備品を勝手に持ち出す社長 ケースその４ ー おかしを勝手に持ち出すCTO さいごに クラウドカメラに囲まれた生活 普通の会社ではなかなか体験できない環境として、セーフィーでは社内のいたるところに検証用のクラウドカメラがおいてあり、その映像は Safie Viewer で見ることができます。 冷静に考えたらものすごい監視体制なのですが、そういう雰囲気の会社では全くありません！日々の風景をいくつかご紹介します。 すごい監視体制 ケースその１ ー 顔認証で勤怠管理 セーフィーでは、出退勤/入退出の管理をICカードではなく顔認証で行っています。タブレット端末で顔認証を行い、入退出のデータを KING OF TIME と連携しています（以下の写真は別のカメラに写っていたものを使用しています）。 タブレット端末で顔認証 このシステムは、 Safie Entrance としてサービス提供もしており、多拠点での導入も行えます。 ケースその２ ー コロナ禍での電話会議 ある会議の風景。クラウドカメラの先にいるメンバーに向けて楽しそうに手を振っています（会議自体はGoogle Meetを使用しています）。 カメラには動体検知の機能があるため、そのときの録画を簡単に振り返ることができます（主な機能は こちら ）。 楽しそうに手を振っている様子をカメラが検知 ケースその３ ー 備品を勝手に持ち出す社長 以下は、ある日のSlack上でのやり取りです。 事件発生！ 犯行の様子 Safie Visitors を使えば、犯人が普段社内のどこにいるのか調べようと思えばいくらでも調べることができます（Safie Visitorsは、顔認証技術を利用してお客様の接遇改善やマーケティング、業務改善を実現するサービスです）。 犯人の動向 ケースその４ ー おかしを勝手に持ち出すCTO せっかくなので動画でご紹介。誰もいなくなったオフィスで人のお菓子をゲットするCTO。ちょっとうれしそう。 監視カメラはフレームレートが低いイメージがあると思うのですが、セーフィー対応カメラのフレームレートは30fpsなので、一般的な防犯カメラ・監視カメラ（3-5fps）に比べ綺麗な映像を提供することができます（デモは こちら ）。 さいごに ほんとに一部ですが、社内の風景を技術要素とあわせて紹介してみました。IoTの会社ならではの社内風景ではないかと思います。 社内には、クラウド技術からハードウェアまで様々なものが揃っています。幅広い技術領域でチャレンジしてみたい方、また他にも社内の様子をもっと知りたい方は、ぜひ一度遊びに来てください！ご連絡をお待ちしています！ open.talentio.com

こんにちは！セーフィー株式会社のサービス開発部 モバイルチームの北本です。 主にSafie ViewerのiOSアプリの開発を担当しています。 今回は、リーダブルコードを読んで、プルリクレビュー改善に活用する話をしたいと思います。 なぜリーダブルコードを読むのか リーダブルコードとは？ リーダブルコードに書かれていたこと 理解しやすいコードとは？ 表面上の改善（第Ⅰ部） 命名規則について コメントについて ループとロジックの単純化（第Ⅱ部） 関数から早く返す、ネストを浅くする 変数を用いて分割する 変数のスコープと変更 コードの再編成（第Ⅲ部） 無関係な下位問題を抽出する 一度にひとつのことを ロジックを明確に説明できるか？ 短いコードを書く さいごに なぜリーダブルコードを読むのか セーフィーモバイルチームは現在、チームビルディングを積極的に進めています。 ある日のミーティング時に、コードレビューに関して、以下のやりとりがありました。 シニアエンジニアが若手エンジニアのプルリクエスト（以下PR）にどの範囲まで指摘すればいいかわからない 若手エンジニアがシニアエンジニアのPRに何をレビューすればいいかわからない そこで、チーム開発において良いコードの書き方の基準を定めようということになり、 モバイルチーム全体でコードの理想状態を議論した結果、チームの生産性を高めるコード≒可読性の高いコードとして理想状態を定義し、リーダブルコードをPRのレビュー指針のベースとして取り入れようということを決めました。 今回の記事ではリーダブルコード（第22版）を「チームに取り入れられるレビュー指針はあるか」といった目線で読み返し、議論の叩きとして、レビュー観点をチェック項目形式でまとめた物を共有します！ www.oreilly.co.jp リーダブルコードとは？ 「エンジニアが読むべき本」「エンジニアが影響を受けた本」と検索すると必ずといっていいほどトップに出てくるのがこの本『リーダブルコード ――より良いコードを書くためのシンプルで実践的なテクニック』です。副題の通りより良いコード、読みやすいコードを書くための実践的なテクニックが変数の命名からロジック、テストまで章ごとに体系的に説明されています。皆さんのチームでも、エンジニア同士が可読性の高いコードを説明する上で共通言語として会話に登場することもあるのではないのでしょうか？ この記事では、現場での活用例の共有として、役立てていただければと思います。「なぜこのルールが読みやすいコードに繋がるのだろう？」と気になった方はぜひこの記事をきっかけにリーダブルコードをお読みいただければと思います。 リーダブルコードに書かれていたこと セーフィーのチーム開発で取り入れることができそうな記述を抜粋し、「 どういった観点でレビューすれば良いか 」といった視点でまとめます。この記事はあくまで「チームのカルチャーにフィットさせるための議論の叩き」という立場なので現実的なルールの粒度かどうかの観点は考慮していないことにご注意ください。 理解しやすいコードとは？ （1章 理解しやすいコード） リーダブルコードでは以下を著書の目的として定義しています。 （引用 まえがき） 本書の目的は、読みやすいコードを書くことである。その中心となるのは、コードは理解しやすくなければいけないという考えだ。具体的に言えば、誰かが君のコードを読んで理解する時間を最短にするということだ。 また、コーディングには、コードの効率化、設計、テスタブルといった様々な側面がありますが、この章では「コードを読みやすくするという視点はその他の目標と競合しない、高度に最適化されたコードであってももっと理解しやすくできる」といった点も言及されています。iOSの開発では、用いられているSwiftでは高機能なコンパイラによる最適化も施されるため、コードの可読性の追求という点においてトレードオフになる要素はゼロといって良さそうです。 ひとまずセーフィーモバイルチームでも、「レビュワーが理解しやすくするには？」といった視点に立ち、メンバーのコードを理解するまでにかかる時間を最短にすることで、チームの生産性の向上を目指していきたいと思います。 次章以降で具体的なテクニックに関して説明されています。 表面上の改善（第Ⅰ部） 命名規則について （2章 名前に情報を詰め込む、3章 誤解されない名前） （引用 p.10） 明確な単語を選ぶ 「名前に情報を詰め込む」には、明確な単語を選ばなければいけない。 getやsizeなどの汎用的な単語を変数名、関数名で避け、明確な単語を選ぶべき理由が説明されています。 変数名、関数名に汎用的な単語が使われてないか？明確な単語に置き換えることはできないか？ 役割が理解できない変数名はなかったか？ （引用 p.19） 名前に情報を追加する 名前は短いコメントのようなものだ。変数名に詰め込める情報はあまり多くない。だけど、名前につけた情報は変数を見るたびに目に入ってくる。 また、時間、サイズといった値の単位や、危険や注意喚起のための情報を変数名に追加するためのテクニックが説明されています。また、「変数のスコープが小さい場合は短い名前でも良いが、エディタには単語補完があるので避ける理由にはならない」といったことにも 触れています。 命名に利用されている単語は曖昧すぎないか？情報は十分か？ ここでは「命名のフォーマット規約」についても触れられていますが、iOSの開発に関して言えば、Swiftの公式ドキュメントにある API Design Guideline や、Apple公式のフレームワークがあるので、こちらに寄せていくことでより明瞭な命名ができそうです。 プログラミング言語の規約や、公式ライブラリの命名規則に乗っ取った命名ができているか？ コメントについて （5章 コメントすべきことを知る、6章 コメントは正確で簡潔に） （引用 p.69〜70） コメントすべきでは「ない」こと： ・コードからすぐに抽出できること。 ・ひどいコード（例えば、ひどい名前の関数）を補う「補助的なコメント」。 コメントを書くのではなくコードを修正する。 記録すべき自分の考え： ・なぜコードが他のやり方ではなくこうなっているのか（「監督コメンタリー」）。 ・コードの欠陥をTODO: やXXX: などの記法を使って示す。 ・定数の値にまつわる「背景」。 読み手の立場になって考える： ・コードを読んだ人が「えっ？」と思うところを予想してコメントをつける。 ・平均的な読み手が驚くような動作は文書化しておく。 ・ファイルやクラスには「全体像」のコメントを書く。 ・読み手が細部に捕われないように、コードブロックにコメントをつけて概要をまとめる。 この章で「価値のあるコメント」と呼ばれていた、「実装の背景、ToDo」を書く文化は既にあるので守っていきたいです。 ただ、複雑な処理を行う実装でも、レビュアーがコメントを読んでいて実装内容が明確にわかるか、びっくりしたことがないか、を意識する必要がありそうです。 また、読み手の立場になって考えることの重要性が書かれていましたが、コードレビューにおいては、明確に読み手視点でコメントの改善を促すことができます。本人では気付きづらい点をレビュワーが「コメントの内容が理解できたか」の観点で改善を促していくのは効果的だと感じました。 コードからすぐに抽出できること、命名で補えることをコメントしていないか？ コメント内容をコードの修正で補えないか？ なぜ他のやり方ではなくこうなっているのかわからない箇所はあるか？ TODO: やFIXME: , HACK: などの記法を使って示す箇所はあるか？ 「背景」がわからない、動かすことのできない定数の値はないか？ レビュワーが「びっくりしたこと」がなかったか？ 自明でない挙動、動作について記述したコードはないか？ ファイルやクラスに「全体像」に関するコメントが書かれているか？ コードブロックに概要がコメントによって整理されているか？ ループとロジックの単純化（第Ⅱ部） 関数から早く返す、ネストを浅くする （７章 制御フローを読みやすくする） （引用 p.97〜98 一部省略） 比較（while (bytes_expected > bytes_received)）を書くときには、変化する値を左に、より安定した値を右に配置する（while (bytes_received < bytes_expected)）。 if/else文のブロックは適切に並べ替える。一般的には、肯定系・単純・目立つものを先に処理する。 〔中略〕 ネストしているとコードを追うのに集中力が必要になる。ネストが増えるたびに「スタックにプッシュ」することが増える。深いネストを避けるには「直接的」なコードを選択する。 早めに返してあげると、ネストを削除したりコードをクリーンにしたりできる。特に「ガード節」（関数の上部で単純な条件を先に処理するもの）が便利だ。 私が普段使っているSwiftでは非同期な処理をクロージャを使ってネストして書くことが多いので、なるべくネストを浅くする工夫が必要になってくると感じました。 また、推奨されていたガード節に関して、言語仕様によってはguard文があり、returnを強制することができるので積極的に使っていく方針が取れそうです。 比較条件では、変化する値が左に来ているか？ if/else文のブロックは肯定系・単純・目立つものを先に処理されているか？ クロージャ、if文等のネストを浅くする手段はないか？ guard文を利用して改善できる箇所はないか？ 変数を用いて分割する （8章 巨大な式を分割する） （引用 p.108 一部省略） 最も簡単な方法は「説明変数」を導入することだ。大きな式の値を保持する説明変数には、３つの利点がある。 ・巨大な式を分割できる。 ・簡潔な名前で式を説明することで、コードを文書化できる。 ・コードの主要な「概念」を読み手が認識しやすくなる。 その他には、ド・モルガンの法則を使ってロジックを操作する手法がある。 〔中略〕 本章で取り上げた全ての改善コードには、if文の中身が２行以上含まれていない。これは理想的な状況だ。同じことが常にできるとは限らない。そんなときは、問題を「否定」したり、反対のことを考えてみたりすることが必要になる。 レビューにおいては、レビュワーが直感的に複雑な条件や、わからなかった計算があった場合にそれを指摘し、指摘があったレビュイーが「説明変数」、「要約変数」の概念を使って解決するといった方針が取れそうです。 「改善コードのif文の中身が２行以上含まれていない」といった状況を理想的と書かれていましたが、Swiftでは変数のオプショナルラップに利用されており、言語仕様によっては難しい場合もありそうです。 わからなかった計算はなかったか？ 複雑な式を説明変数を用いて分割できないか？ ド・モルガンの法則を利用して多重括弧を削ることができないか？ 複雑な文の条件を否定、「反対を考える」といった手法で単純化できないか？ 変数のスコープと変更 （ 9章 変数と読みやすさ） （引用 p.126） 変数を減らして、できるだけ「軽量」にすれば、コードは読みやすくなる。具体的には、 ・邪魔な変数を削除する。ーー本章では、結果をすぐに使って、「中間状態」の変数を削除する例を示した。 ・変数のスコープをできるだけ小さくする。ーー変数を数行のコードからしか見えない位置に移動する。 ・一度だけ書き込む変数を使う。ーー変数に一度だけ値を設定すれば（あるいは、constやfinalなどのイミュータブルにする方法を使えば）、コードが理解しやすくなる。 Swiftで利用するXcodeでは、利用されていない変数や、値の再代入のないvarの変数宣言などは警告をしてくれるのでありがたいです。 また、本書の例のようにロジックを整理することで変数そのものを消したり、varの宣言をletに変えられることもありそうです。 さらに「変数のスコープを小さくするために、コード行数をできるだけ減らす」という観点は比較的指摘がしやすく、実際のPRでも使っていきたいです。 外部から参照されていない変数、関数はprivateになっているか？ 継承されていないclassはfinalになっているか？ 宣言をイミュータブル（let）に変更できる変数はないか？ 変数は利用する直前で宣言され、利用できる範囲が最小化されているか？ コードの再編成（第Ⅲ部） 無関係な下位問題を抽出する （10章 無関係の下位問題を抽出する） （引用 p.130） 本性のアドバイスは、無関係の下位問題を積極的に見つけて抽出することだ。ぼくたちは以下のことを考えている。 1. 関数やコードブロックを見て「このコードの高レベルの目標は何か？」と自問する。 2. コードの各行に対して「高レベルの目標に直接的に効果があるのか？　あるいは、無関係の下位問題を解決しているのか？」と自問する。 3. 無関係の下位問題を解決しているコードが相当量あれば、それらを抽出して別の関数にする。 （引用 p.141） 本章を簡単にまとめると、プロジェクト固有のコードから汎用コードを分離するということだ。ほとんどのコードは汎用化できる。一般的な問題を解決するライブラリやヘルパー関数を作っていけば、プログラムに固有の小さな核だけが残る。 この章では、「プログラムに固有の小さな核」＝その関数、コードブロックの関心事のみを残し、それ以外は別の関数やクラスに切り出して汎用化すべきだということが書かれていました。 関数、コードブロックの核は明確化されているか？別の下位問題を扱ってないか？ 汎用コードとして切り出せるロジックはないか？ また、既存のインターフェース部分の「汎用コード」を自前のextensionを作って簡潔にすることも意識していきたいです。 ライブラリのインターフェースが複雑な部分から汎用的コードは作れないか？ 一度にひとつのことを （11章 一度にひとつのことを） （引用 p.155） 読みにくいコードがあれば、そこで行われているタスクを全て列挙する。そこは別の関数（やクラス）に分割できるタスクがあるだろう。それ以外は、関数の論理的な「段落」になる。タスクをどのように分割するかよりも、分割するということが大切なのだ。 この章を読んでPR内の実装が読みにくい場合、一度に複数のことを並行して行っている可能性が高いと感じました。 その場合、読みにくいことをレビュワーが伝え、レビュイーにタスクを全て列挙してもらう、別のクラス・関数に処理への分割を提案するといったアクションが取れそうです。 読みづらい関数やロジックがあった場合、別のクラス・関数に、分割できないか？ ロジックを明確に説明できるか？ （12章 コードに思いをこめる） （引用 p.165 一部省略） 本章では、プログラムのことを簡単な言葉で説明する技法について説明した。説明することでコードがより自然になっていく。この技法は思っているよりも簡単だが非常に強力だ。説明で使っている単語やフレーズをよく見れば、分割する下位問題がどこにあるかがわかる。 〔中略〕 問題や設計をうまく言葉で説明できないのであれば、何かを見落としているか、詳細が明確になってないということだ。 複雑な考えを伝える時に、自分よりも知識が少ない人に簡単な言葉で説明する能力が大事といった内容でした。 PRにおいては、概要や、解決する問題、解決手段をレビュアーに説明する必要があるため、「ロジックを明確に説明できるか？」という観点はそのまま利用できそうだと感じました。PRの内容を概要で説明できること、コミットメッセージが簡潔にまとまっていることへの意識は重要そうです。 PRの内容が概要に簡潔に説明されていて、レビュアーは意図がわかるか？ また、一度に複数の修正を含んでしまったPRは簡潔な説明にならないはずなので、レビュイーの意識として - PRのコミットを細かい目的ごとに分割する - リファクタリングと不具合修正のPRを分ける ということも必要になってくるはずです。 コミットの単位は適切か？ 一つのPRに関して目的が一つに定まっているか？ 短いコードを書く （13章 短いコードを書く） （引用 p.175） 本章では、できるだけコードを書かないことについて説明した。新しいコードには、テストや文書や保守が必要になる。また、コードが増えると「重く」なるし、開発も難しくなる。 新しいコードを書かないようにするには、 ・不必要な機能をプロダクトから削除する。過剰な機能は持たせない。 ・最も簡単に問題を解決できるような要求を考える。 ・定期的にすべてのAPIを読んで、標準ライブラリに慣れ親しんでおく。 短いコードを書くためのテクニック、意識が紹介されていました。 基本的に同意できる内容だったのでチェック項目だけまとめました。 必要のない、利用されていない過剰なロジック、コードがないか？ 変更・修正の方針が正しいか？ 問題をもっと簡単に解決できないか？ 今回使われなくなったコードはちゃんと削除しているか？ ライブラリ、既にあるロジックを使って解決できないか？（処理が重複してないか？） さいごに 本書の「読みやすさ」はチームにおいて、コードを分割すべきかどうかの判断基準としては良い共通言語になると思います。私自身も、この記事を書きつつ日々のコードの質や、レビューの観点、コーディングにおける価値観にどんどん影響を受けていくのを感じています。 また、この本の初版は2012年です。10年近く経っているにもかかわらず、現代のエンジニアからも変わらない評価を得続けていることからも「コードは理解しやすくなければならない」という価値観の正しさと汎用性を感じます。私たちセーフィーモバイルチームのように方針や、共通言語として本書を利用するという手法もぜひお勧めです。 一方で、チェック項目全てをPRのレビュー観点として運用することが適切だとは考えていません。記事にする都合上、チームやプロジェクトのカルチャーや温度感、既存のルールに合っているか？という観点を今回は考慮していないからです。既存のプロジェクト内でルールを統一、浸透させるコストや競合する文化などを鑑みて、項目数を増減させたり、表現を修正する必要があるでしょう。セーフィーモバイルチームでも、この運用は議論の叩きの段階なので、今後チームにフィットさせるために議論を重ねていきます。 また、リーダブルコードに書かれていた観点がレビューにおいて見るべき箇所を網羅できてはいません。本書の説明していたロジックの修正の観点に加え、関数の関心がどこに向いているべきなのか、どのクラスで処理すべきなのか、どのパターンを適応すべきなのかといった純粋な技術力に基づく判断は必要でしょう。今後、 SOLID原則 など基礎となる実装パターンも学んで力を付けたいと思います。 チーム開発において、チームメンバーでレビュー観点に共通認識があり、プロジェクトが読みやすいコードで記述されていることで、レビューの時間が短くなり、コードの理解が早くなり、実装方針に悩む時間が減り、コードメンテナンスがしやすくなります。 皆さんも名著から学んだ知識を現場でどう活用できるか、どんな課題を解決できそうかを考えることで、チームの生産性を大きく上げるきっかけを作れるかもしれません。また新しい発見や学びがあれば、ブログに投稿したいと思います。 セーフィーでは、チームで切磋琢磨し成長していける方を募集しています。ご興味のある方のご連絡をお待ちしています。 open.talentio.com

セーフィー株式会社 プラットフォーム開発部のソフトウェアエンジニア 斎藤です。 Safie サービスの安定運用に寄与するべく、インフラ周りの構築・運用を主に担当しています。 今回は複数人で開発していると起こりがちの不便さを GitHub Actions を活用し解消したお話です。 例えばこんな不便なことありませんか？ 不便をどのように解消したか 概要図 処理フロー 処理の詳細 GitHub Actions Python (boto3) 作った環境の自動廃棄 残課題 おわりに 例えばこんな不便なことありませんか？ ブランチを固定しておきたいとき 動作確認のために、とあるブランチをしばらく取り込んでおきたいとき テスト環境へブランチを適用したいが、ブランチ適用待ち渋滞の発生 (複数人で一つの環境を共有している場合に発生しがち) 不便をどのように解消したか 複数人で一つの環境を共有しているのが問題になっています。 ブランチ毎に確認環境があれば良さそうということで、事前確認出来る環境を自動構築 && 不要になったら自動破棄する仕組みを作りました。 概要図 今回作った仕組みの概要図になります。 GitHub Actions AWS SDK for Python (Boto3) を利用しています。 処理フロー ユーザーが git push します Pull Request 作成 && ラベル (deploy) 付与します ※ラベル名は何でも良いです ラベル付与方式にした理由は、事前確認するまでもない場合に発火させない為 ※ 例えば typo / ドキュメント修正など明らかに動作に影響しない修正とか ラベル付与イベントを検知して GitHub Actions が発火し、環境自動構築します docker build && ECR に push Python (boto3) kick タスク定義の登録 target group と forward rule 新規追加 タスク定義と target group を紐付けた service を新規追加 最後に CNAME のレコード登録をして完了 https://prXXX.example.com XXX はプルリク番号が入ります https://pr82.example.com みたいにプルリク毎に環境が出来ます 処理の詳細 GitHub Actions と Python (boto3) の処理をそれぞれコードベースでかいつまんで説明します。 GitHub Actions Python (boto3) 作った環境の自動廃棄 作った環境の自動廃棄については、以下の条件で行っています。 プルリクエストがマージされた時 destroy する GitHub Actions 発火 ↓ python kick python destroy_dev.py ${{ github.event.pull_request.number }} route 53) DELETE resource_record_sets ECS) タスク停止 && deregister_task_definition ECS) delete_service ALB) delete_rule && delete_target_group 残課題 一度確認した後、再修正が必要で再 push したときの待ち時間(約1分)をもう少し短く出来れば良いなと思っています。 おわりに 以上、複数人で開発していると起こりがちの不便さを GitHub Actions を活用し解消したというお話でした。 日々の開発業務を進めていく上で、小さな不便を自ら拾いに行き、自分ごととして改善するチャンスが沢山あります。 改善を繰り返すことで自分自身の成長、やがてはチーム、組織へも貢献出来るかと思います。 セーフィーでは、迷った時はやってみて成長機会を求める意識の高い方を歓迎します。 ご興味のある方のご連絡をお待ちしています。 open.talentio.com

セーフィー株式会社 プラットフォーム開発部のソフトウェアエンジニア 鈴木敦志です。 セーフィーでは動画データの利活用を進めるため 顔認識来店分析サービス Safie Visitors などAI技術を活用したサービスの開発を行っております。 画像認識AI応用サービスを開発するには、一般的な用途 (顔認識や物体検知など) に対応する学習済みのAIモデルを使用するか、あるいは特定の用途 (不良品検知など) のために自前でAIモデルの構築・運用を行う必要があります。 一方で、「ドアが開いているか知りたい」「商品が陳列されているかを知りたい」などの簡単なタスクについては、既存の学習済みディープラーニングモデルを利用した転移学習とk近傍法などの単純な分類アルゴリズムを用いることで、数枚の教師画像を選択するだけで非常に簡単にAIによる画像分析を利用することができます。 参考: 20190928 M5StickVではじめる軽量モデルの実世界への応用 #TFUG - ミクミンP (@ksasao) 様 本記事ではSafieカメラのライブストリーミング映像を用いてAIモデル作成、リアルタイム画像分類を行うWebアプリケーションを実装しました。 Safie AI画像分類 [alpha] について 使い方 システム構成 推論アルゴリズム 今後の展望 Safie AI画像分類 [alpha] について 使い方 Webブラウザで「Safie AI画像分類 [alpha]」にアクセスし、Safieのユーザーアカウントでログインします。 一覧からカメラを選択、 画像のクラス（「ドアが合いている」「閉じている」等）を作成し、「例を追加」ボタンで現在のカメラ画像を教師データとして追加します。 現在のカメラ画像がどのクラスに分類されるかをAIがリアルタイムで判定し、該当するクラスがハイライト表示されます。 システム構成 Safie AI画像分類 [alpha] は Nuxt.js で実装されたWebアプリケーションです。 Safieクラウド に接続されたカメラ映像をHLSでストリーミング再生し、 TensorFlow.js で各フレームの推論をWebGL経由でGPUを駆動して行います。 分類アルゴリズムにk近傍法を用いており、教師データの学習は指定されたフレームの画像データを追加するだけで完了します。今回は人がいる場合といない場合の3枚ずつ、計6枚を使用したのみとなっています。 推論アルゴリズム 推論アルゴリズムには画像からの特徴抽出にMobileNetV1を使用し、特徴量からの分類をk近傍法を使用します。 MobileNetはディープラーニングによる画像の分類・オブジェクト検出などに使用されるモデルで、モバイル端末などでの用途のため計算負荷が小さいのが特徴です。 今回は転移学習を用い、1,000クラスの分類タスクを行う学習済みMobileNet V1モデルの畳み込み層を特徴抽出器として利用し、得られた特徴ベクトルをk近傍法の入力とします。 k近傍法は基本的な機械学習アルゴリズムで、入力ベクトルに最も近い (ユークリッド距離) k個の教師データを探索し、そのうち最も数が多いクラスに入力を分類します。 k近傍法ではより複雑なアルゴリズムに比べ精度は劣りますが、少ない教師データで動作し (k=1のとき各クラスごと画像一枚から) 教師データの追加が簡単になります。 参考: 画像分類器の転移学習 | TensorFlow.js 今後の展望   今回は技術デモとして、ブラウザ上でのみ動作する非常に単純な構成で実装を行いました。 この構成は簡単な認識タスクを行うことを前提にしているためブラウザ上だけの実行のみでは実用的ではないのですが、Safieクラウド上でのモデルの共有・認識のスケジュール実行・通知などを組み合わせることで非常に簡単にAIシステムを構築することができるようになるのではないかと思います。 セーフィーでは先述の顔認識来店分析サービスなどのほかにもいくつかのAI関連のサービスを開発しており、カメラの接続および動画の収集・保管といったAI画像解析系サービスの開発時に手間のかかる部分にSafieクラウドのインフラを使用することができます。 また、外部の開発者がSafieクラウド上にこういった分析サービス等を開発できるような仕組みを整備していく予定です。 弊社ではこれらの技術に関心があり、新しいサービスを一緒につくっていただけるエンジニアを募集しています。 open.talentio.com

フロントエンドエンジニアの近藤です。 Web版のカメラ録画映像ビューアー（Safie Viewer）開発 を主に担当しています。 セーフィーにはエンジニアの成長機会について、希望すれば柔軟に対応できる体制があります。その一つとして今年1月から部署内で ソフトウェアアーキテクト勉強会 を隔週ペースで開催しています。今回はこの取組みについての紹介です。 勉強会発足の経緯 ソフトウェアアーキテクト（アーキテクチャ）とは ソフトウェアアーキテクトになるためには 勉強会の様子 ステークホルダーマップ作成 品質特性ウェブ リモート勉強会 参加者の声 まとめ 勉強会発足の経緯 以前のセーフィーの開発部門は、フロントやサーバー、インフラなどの職能ごとに部署が別れていました。長らく続いていたこの体制ですが、部署の組み替えによる最適な組織構成を模索する中で、昨年末にクライアントとサーバーの両担当エンジニアが所属する新しい部署が誕生しました。これまで個々のサービス開発でコミュニケーションを取っていたエンジニアが一同に介したこの機会に、現状ソフトウェアの課題点を洗い出すブレインストーミングを開催したのが背景にあります。 ▲ KJ法を用いたブレインストーミングを実施（ビール🍻を飲みながら、最後は参加者でピザ🍕を食べました） ブレインストーミングで出てきた課題は、弊社のビジネスの複雑さ、開発部門外とのコミュニケーション、属人化やドキュメント不足と様々です。結果としては、参加者それぞれがこれらの課題を自分ごと化し、自分に出来る改善に取り組むことになりました。私はこれらの課題の長期的な解決策として、 ソフトウェアアーキテクト技術の学習 を挙げ、これが勉強会発足の経緯となります。 ソフトウェアアーキテクト（アーキテクチャ）とは ソフトウェアアーキテクチャと聞いて何を思い浮かべるでしょうか。弊社でヒアリングしたところ、マイクロサービスやUML、ドメイン駆動設計、クリーンアーキテクチャ、CQRSなどを提示した方が多くいました。これはまさしくソフトウェアアーキテクチャで、ソフトウェアを構成する重要な要素です。ではソフトウェアアーキテクチャを設計する ソフトウェアアーキテクトとは、どのような職能なのでしょうか 。 これは私の考えですが、ソフトウェアには「解決したい課題」があり、その課題を「解決する手段」がソフトウェアアーキテクチャだと考えています。ソフトウェアアーキテクトは 「解決したい課題」に向き合い、適切なソフトウェアアーキテクチャを選定して「課題を解決する」職能を持った人物 です。 「解決したい課題」に向き合うためには、考慮すべきことが数多くあります。ソフトウェアに関わるステークホルダーへの理解、ステークホルダーごとのビジネス目標の分析、リスクや技術負債の管理などです。開発した後も継続した改善が必要になるため、教育も含めた開発チームの運営も必要になってきます。 ソフトウェアアーキテクトになるためには ではソフトウェアアーキテクトのスキルを高めるにはどうすれば良いのでしょうか。このスキルの経験値を上げるには、ソフトウェアアーキテクチャを設計する立場として開発に携わることが重要です。さらに、そこから改善を繰り返した「良いソフトウェア開発」を継続することで育まれるものだと考えます。 この勉強会では「課題を解決する、良いソフトウェア開発」について深堀りすることにしました 。 勉強会では、昨年11月にO'Reilly社から出版された「Design It!」を教科書として使用しています。 Design It! ―プログラマーのためのアーキテクティング入門 作者: Michael Keeling オライリージャパン Amazon ▲ 実際に勉強会で利用したスライド この本では、ソフトウェアアーキテクトが行うこととして以下があると説明しています。 エンジニアリングの観点から 問題（品質特性）を定義する システムを分割し、 責務を割り当てる 品質特性間の トレードオフを決定する 技術的負債を管理する チームのアーキテクチャスキルを高める ▲ 実際に勉強会で利用したスライド、いらすとやを多用しています。 上記の内容について工学的なアプローチを行い、「良いソフトウェア開発」を達成する方法が説明されているのがこの本です。ソフトウェア工学の論文を引用し、ソフトウェア開発のベストプラクティスが数多く掲載されています。加えて、このベストプラクティスを実践するための「アクティビティ」と呼ばれる多数のワークショップが紹介されているのがとても良いです。 勉強会では、まずは本の内容を理解することを目指しています。その後、自身がソフトウェアアーキテクトとなり、業務に活かすことが最終的な目標です。 勉強会の様子 では、具体的にどのような勉強会を運営しているかについて少し説明します。勉強会では座学だけでは無く、教科書で紹介されているアクティビティを実践しています。「 ステークホルダーマップ作成 」や、「 品質特性ウェブ 」などを実践し、自らが開発に関わっているサービスについて深堀りしていきました。 ▲ すべての勉強会の様子は録画していて、弊社のサービス上でアーカイブされています。 ステークホルダーマップ作成 「ステークホルダー」は利害関係者と訳されます。このアクティビティの目的はソフトウェアに関わる人物を分析し、その関心事を理解することです。いざワークショップを行ってみると実に様々な関心事を持った関係者がいることがわかります。社内だけでも我々開発を行うエンジニアの他に、営業やカスタマーサポート、工事調整部署などがあり、それぞれ別の関心事を持っています。また、社外におけるステークホルダーはサービスを利用しているエンドユーザーだけではありません。弊社は出資関係にある企業がサービスの代理店である場合もあり、その他にも複数のカメラベンダーとの関係があります。エンドユーザーに関しても、大企業や中小で防犯カメラを導入する目的は変わってきます。 ステークホルダーの関心事を整理することはソフトウェア開発おける非常に重要な要素です 。参加者の中にはエンドユーザーのことしか意識に無かった方もいて、新たな視点を持つことが出来たのではと思いました。 ▲ ステークホルダーマップ作成の様子 品質特性ウェブ ステークホルダーの関心事を分析した後は、品質特性の重要度を可視化する「品質特性ウェブ（Quality Attribute Web）」のアクティビティを行いました。関心事やそこから想定した品質特性シナリオを付箋に書き出し、品質特性のレーダーチャート上に貼っていきます。このアクティビティは、作成したチャートを使って ステークホルダーの関心事から品質特性の中でも何が重要なのかを考えることが目的です 。 ▲ 品質特性ウェブのアクティビティの様子 リモート勉強会 新型コロナウィルス感染拡大の影響でリモートワークとなったため暫くの間勉強会を休止していましたが、先日リモート開催しました。社内勉強会のリモート開催に課題は多いですが、意識高いエンジニアのスキルアップの機会を減らすことの無いよう工夫をして継続していきたいと考えています。 ▲ リモート開催の様子、新規の勉強会参加者のためにこれまでの振り返りを実施 参加者の声 勉強会では、実際に自分たちで開発運用しているサービスを用いてアクティビティを実施しています。「 どのようなステークホルダーが存在するか 」といった話題や、「 紹介されているソフトウェアアーキテクチャが既存のシステムのどこで利用されているか 」などの話題になることもあり、入社から日が浅い参加者にとってはサービスの全体像を理解するのに一役買っています。 また、セーフィーには経験豊富なエンジニアも多く、この教科書で紹介されている内容を感覚的に実践している方もいます。ただ、そういった方々からも、体系的にまとめられ、手法として実践的に学ぶことには価値があると評価を得ています。 まとめ ソフトウェアアーキテクト勉強会の紹介でした。この他にもいくつかの勉強会が開催されています。ネットワークカメラのプラットフォームサービスは、IoT、AI、動画配信など多数の技術に触れることができ、エンジニアリングとしても高い品質を要求されるサービスです。このようなサービスの特性上、弊社のエンジニアは多様な専門性と興味関心を持っている方が多い気がしていて、日常の業務でも勉強になることが多い職場です。 弊社ではこれらの技術に関心があり、成長機会を求める意識の高い方を歓迎します。ご興味のある方のご連絡をお待ちしてます。 open.talentio.com

企画本部の下崎です。 セーフィーはカメラというイメージを持つ方が多いかもしれませんが、カメラ以外にもいろいろなサービスを作って提供しています。本記事では、商品・サービスの紹介もかねて、これまでの商品開発の歴史を書きたいと思います。 クラウドカメラ1号 初めてのカメラ開発 「どこでも簡単」とはいかないビューアー開発 サービス開発 みる、をもっと便利に ユーザーの課題を解決する「Safie Apps」 コンシューマーからエンタープライズへ 1台から数万台まで より多くのカメラを より多くの販路を どこでも簡単 モバイルカメラとの出会い モバイルカメラの商品化 エコシステム 最後に   クラウドカメラ1号 初めてのカメラ開発 2015年5月、クラウドファンディングMakuakeを利用して最初に販売したカメラが、書画カメラで有名なELMO社と共同開発した、QBiC Cloud CC-1です。 このカメラは、ハードウェアおよびOSなどのシステム周りの開発と製造をELMO社、カメラ制御や通信まわりのソフトウェア（デバイスSDK）をセーフィーが提供して作りました。2014年11月に本格的な開発が開始してから約6カ月でサービスインするという大急ぎのスケジュールです。それまでにカメラだけではなく、映像を見るためのアプリやサーバーシステムも準備しなければなりません。 ELMO社との共同開発が決まるまでには、いくつかのカメラメーカーだけではなく、自社ブランドで設計と製造ができるODM企業とも話をしましたが、通常のIoTベンチャーとは異なり、カメラ自体の自社開発・ブランドにはそれほどこだわりませんでした。セーフィーではユーザーの不を解消するサービスの提供を第一に考えているからです。ネットで探せば安いものは数千円の「ハイスペック」なカメラが山のように見つかりますし、メールやテレカンでやり取りをして開発費さえ支払えばカメラを作ってくれる海外のODMメーカーも数多くあります。ただし、自分も電機メーカーにいたから言えるのですが、単にスペックを満たしたものを作ることと高品質な優れた製品を作ることは同じではありません。ソフトウェア開発はできるという（根拠のない）自信がありましたが、当時の私たちにはハードウェアを設計する技術も生産管理のノウハウも無かったので、それらを補い共に製品を作り上げてくれるパートナーを必要としていました。 クラウド技術を求めていたELMO社さんとは、お互いの技術を提供しあう対等な関係で開発をしていただきました。今考えれば社員3人の会社と、2014年の夏に最初に会った時にはまだ会社すらなかったのに、良く共同開発に踏み切ってくれたものです。この幸運に恵まれた出会いがなければセーフィーという会社は無かったかもしれません。 「どこでも簡単」とはいかないビューアー開発 カメラは作る当てがつきましたが、撮影した映像を見るためのビューアーも必要です。「どこでも簡単」を追求したサービスを作ろうと考えていましたので、選択肢はウェブかスマホアプリ。外出中でも簡単にみたいのでスマホの中でもシェアの大きいiOS用アプリをまずは作ることにしました。「どこでも簡単」のこだわりは今でも続いていて、カメラ映像の視聴や設定・操作を始め、画像解析サービスまで、ブラウザもしくはスマホアプリから煩雑なセットアップ無しで利用することができるようにしています。 現在はビジネス用途の割合が多くなりましたが、サービス開始時にはいわゆる見守り系でコンシューマー市場をターゲットにしていたので、マニュアル無しでも直感的に操作できるUIを目指して設計を行いました。そのUIを5年ほど引き継いで機能追加するにつれ、徐々に改良したい点がUI的にも内部実装的にも出てきました。そこで、操作性をさらに高めた新モバイルビューアーの開発に踏み切り、間もなく2020年5月に提供開始する予定です。 当時はエンジニアが3人しかいなかったので、機能仕様と主な画面のワイヤーフレームを作成したらアプリの実装はツテのあった開発会社さんの力も借りました。ただどうしても上手くいかなかったのがBluetoothの実装でした。BLEのアドバタイズメントを利用してカメラを検索して接続、アプリから設定するという設計はできたのに、肝心のデータのやり取りがどうしてもできない。あるのはBluetoothチップの仕様書だけ。しかもあまりメジャーなものでは無かったので、カメラメーカー含めて実際に使ったことのある人が誰もいないのには困りました。ネットのサンプルを参考にしても上手くいかないので、Bluetoothの電波をキャプチャして通信内容を表示できるプロトコルアナライザーまで使い、メーカーの人といろいろやってみるのですが、全然データのやり取りができないのです。CC-1はWi-Fiしか通信インターフェイスが無いので、その設定をしないと何もできません。最初はそのうちできるだろうと考えていたのですが、そうこうしているうちにデモを見せるプレス発表が翌週になってしまいました。そのギリギリの時に、同じBluetoothチップを使っている会社を何とか見つけ、頼み込んで使い方を教えてもらうことができました（ちなみにそういう時に限って新幹線を乗り過ごし、さらに乗ったタクシーが道を間違えて打ち合わせに遅刻しました...）。 トラブルもありましたが、クラウドファンディングではCC-1を500台以上を販売することができ、何とか満足のいくスタートを切ることができました。 サービス開発 みる、をもっと便利に iOSアプリが完成したので、直ぐにその設計を元にAndroidとウェブアプリに横展開しました。これで撮る、みる、ためるという基本的な機能は実現できましたが、「賢くなるカメラ」と銘打ってサービスを提供していることもあって、ユーザーからは様々な要望が寄せられて来ます。その中の一つが、映像を公開して大勢の人に見せたいというものでした。そこでカメラで撮影したライブ映像とYouTube Liveの連携サービスが生れました。最初はYouTubeやFacebookなどいくつかのライブ配信サービスとの連携を試してみて、技術的には実現可能なことが分かっていましたが、どれぐらいのビジネスになるかはっきりしないこともあって正式なサービス提供にまでは至っていませんでした。 そんな状況の転機になったのが、2016年8月に九州朝日放送と組んで実施した、KBCオーガスタゴルフトーナメントの定点カメラ映像のライブ配信でした。石川遼選手などが参戦するメジャーな大会なので当然テレビ中継されるですが、打撃練習場や選手がティーショットをするまでの準備など、ゴルフをやっている方にとってはテレビ放送されないシーンでも面白いところがいっぱいあるそうです。たまたまセーフィーのカメラでライブ配信もできるんですよ、と紹介したことがきっかけで、大きなイベントで利用していただき、その後はイベント配信だけではなく、河川監視など公共での利用にまで活用の幅が広がってきています。 Safie Culture の一つに「迷った時はやってみる」があるのですが、ユーザーの声に耳を傾けて技術の可能性にかけたエンジニアと、それを素早くかつタイムリーに届けて形にした営業の、まさにやってみたことでつかんだ成功例でした。この開発の姿勢は今でも大切にしていることの一つで、人数カウントやPOSレジ連携、Safie Visitorsなど顔認識サービス、といった新サービスを生み出す原動力にもなっています。 ユーザーの課題を解決する「Safie Apps」 セーフィーは多くの飲食・小売店でご利用いただいていますが、トラブルや不正が発生しやすいレジを撮影していることが多いです。カメラの設置が抑止力となって何も起きないのが一番ですが、トラブル発生時には映像を探して確認するために、店長さんは貴重な時間を使うことになります。セーフィーでは過去の映像を簡単に再生してみることができますが、正確な時間が分からない場合には特定のシーンを探すのは結構大変です。そのようなお悩みを解決するために生まれたのが「 POSレジ連携 」です。 POSレジの売上データ（ジャーナルと呼ばれます）と映像を結び付けることで、映像の検索性が飛躍的に高まります。POSシステムのインターフェースやジャーナルの仕様は規格化されていないため、連携させるためにどうしてもある程度の個別対応が発生してしまうのですが、対応するPOSシステムの数を少しづつ増やしていっています。 また、POSレジ連携以外にも、顔認識を利用した「 Safie Visitors 」のようなAIや画像解析の技術を活用し、映像の検索性を高めるサービスの開発を積極的に行っています。 サービスそのものではないのですが、ユーザーの細かいニーズにも応えると同時に、新サービスをより早く開発できるようにしたいという思いで開発したのが「ダッシュボード」です。法人向けのサービスを行っていて、ありがたいことに日常業務に組み込んでご利用いただいていると、業務に合わせてカスタマイズしたいという要望をお聞きすることがあります。例えば、エリアマネージャーが自分の担当店舗ごとに映像と人数カウントの入出店者数を確認するような場合です。もちろん、カメラ映像をひとつずつ確認することはできますが、それでは日常業務として作業効率がよくありません。「ダッシュボード」によって、ユーザー自身で店舗ごとの映像と人数カウントグラフをまとめた画面を作成する、といったことが可能になりました。 最初は映像をみる機能の拡張から始まったサービス開発ですが、現在ではもう一歩進んでユーザーの課題そのものを解決するソリューションを開発し「Safie Apps」として提供しています。 コンシューマーからエンタープライズへ 1台から数万台まで 2017年にCC-1の後継機種CC-2の提供開始に合わせて、自社ECサイトをオープンしました。それまでもAmazonなどでカメラを購入することはできたのですが、カメラが到着したら設定作業を行う必要がありました。自社ECサイト経由で購入していただくことで、出荷時に必要な設定を行ったうえでお届けすることができるようになり、さらに置くだけ簡単度合いが高くなりました。 このころになると、数十台～数百台以上のカメラを導入する所謂エンタープライズ領域のユーザーが出てきました。各ビューアーアプリはカメラが1台でも数百、数千台でも利用していただけますが、カメラだけではなく利用するユーザーや設置拠点数も多くなるため、どうしても管理の手間がかかります。例えば、カメラを新しい拠点に導入したら、アカウントの追加が必要になりますし、異動や退職が発生したらアカウントの変更をしなければなりません。このような管理作業をより便利にしていただくために開発したのが「Enterprise Tool」です。 最初はカメラ数が少なかったユーザーも、追加していくうちに気が付くと結構な数をお使いいただいていることがあります。エンタープライズと呼ばれるような大企業のみならず、より多くの方にお使いいただくためにも、エンタープライズツールを「Safie Manager」としてリニューアルし、更に使いやすくしています。 より多くのカメラを ユーザーが増えると、それに伴ってカメラの利用用途や設置環境も様々になります。Wi-Fi接続のCC-1カメラの後には有線LAN接続で屋外対応のCP-1を開発しましたが、全ての用途に対応するにはまだまだ機種が足りません。カメラといっても形状や機能で、ドーム型、バレット型、PTZ、パノラマなど様々な種類があるのですが、全部開発するほどのリソースはありません。そこで、既に販売されている汎用ネットワークカメラをセーフィーのサービスで使えるようにするために「ゲートウェイ」を作りました。ネットワークカメラは映像を取得したり制御したりするためにRTSPやONVIFといった規格化されたインターフェースを持っていることが多いです。通常はカメラと一緒に設置したレコーダーやサーバーがこのインターフェースを使って映像を取得して保存するのですが、ゲートウェイは取得映像をセーフィーのサーバーに暗号化して転送します。セーフィーカメラと同様にサーバーから制御することもできるので、ユーザーからみると同じように使うことができます。これによって、カメラの種類が増えたのみならず、既に設置してあるカメラを利用することもできるようになりました。 このゲートウェイですが、最初は製造委託するほどのボリュームが無かったので、自分たちで作っていました。 シングルボードコンピュータを仕入れてファームウェアを焼き込みます。丁度いいケースがなかったので、町工場の板金屋さんに手書きの図面を持ち込んで作ってもらい、その中にボードを組み込みました。販売数が増えて、性能向上もかねた新モデルを製造を委託するようになるまでは、大口の発注が入ると、嬉しい反面で納期に間に合わせるための製造作業が忙しくなっていました。 より多くの販路を ゲートウェイで利用できるカメラは増えたのですが、汎用のインターフェースを使うので、設定の簡単さや機能の追加には限界があることも分かってきました。その時に見つけたのが、ネットワークカメラメーカーの Axis Communications 社のACAPやVivotek社のVADPといったアプリケーションプラットフォーム機能でした。それらを利用すると様々なモデルのカメラに自分で開発したアプリケーションをインストールして動かすことができるので、対応機種を大幅に増やすことができそうです。狙いは当たり、現在ではセーフィーに対応したカメラは数百機種にまで増えました。 実は Axis Communications 社のカメラに対応したのにはもう一つの理由がありました。販路を増やしたかったのです。新規創業からしばらくは知名度も自社の販売力も低く、カメラを作って一緒にビジネスをやろうというメーカーも、知らないスタートアップが作ったカメラを扱おうという販売会社もほとんどありませんでした。その点、カメラのアプリケーションプラットフォームを利用すると市販のカメラが使えるのでスモールスタートが可能です。またマーケットシェアもあるのですでに販売している会社も多いです。最初はカメラを仕入れるためのアカウントをディストリビューターに作ることができず、出資を受けていたソネット（現在のソニーネットワークコミュニケーションズ）さんに紹介をお願いして何とかなったぐらいでしたが、現在では Axis Communications と同じグループ会社（2015年に当時世界最大手だった Axis Communications をキヤノンが買収しました）のキヤノンマーケティングジャパンさんを含め、100社以上の販売パートナーにセーフィーを扱っていただけるようになりました。 どこでも簡単 モバイルカメラとの出会い 「どこでも簡単」を商品開発ではひとつのキーワードにしています。スマホやタブレットを使えばどこでも見るのは簡単ですが、撮影はやはり固定したカメラで行うしかありませんでした。そんな時に偶然出会ったのが、お客さんが自作したモバイルカメラ、「 ボックス型CC-1カメラ 」です。 きっかけはCC-1の映像が途切れるという問い合わせでした。場所は工事現場だということなのできっとWi-Fi環境が良くないのだろうと行ってみると、小さな箱にカメラとモバイルWi-Fiか何かのルーターが詰め込んであります。お客さん自らがこんなソリューションを作っていたということは大きな衝撃でした。不具合の原因は通信容量の上限に達して帯域制限がかかったことだとすぐに分かったのですが、帯域制限という問題自体の解決は簡単ではありません。映像撮影時のビットレートは通信状況に合わせて自動制御されるので、通信状態が悪くても映像を視聴することはできるのですが、どうしても画質はいまいちになります。根本原因そのものを解決するしかありません。代表の佐渡島はインターネットプロバイダーの ソニーネットワークコミュニケーションズ出身だったこともあって、カメラが主に使うインターネットのアップストリーム帯域には空きがありそうだと思っていました。そこでソニーネットワークコミュニケーションズと交渉し、アップストリームだけを帯域制限なく利用できるカメラ専用のLTE通信契約を作ってもらったのです。 モバイルカメラの商品化 通信帯域の問題が解決したので、「ボックス型CC-1カメラ」を組み立てているところを紹介してもらい、セーフィーでも商品として扱うことにしました。インターネット回線のない工事現場や駐車場を始め、災害発生時には電源にさすだけで動作するという特徴を活かし、状況を素早くかつ継続的に把握するために利用されました。ただ、使っていたカメラのCC-1は屋外向けではないうえに、小さな箱に詰め込んであるので、夏場に温度が高くなると動かなくなることがあるという悩みがあったのです。 そんな時に、夜間でも撮影したものが欲しいという依頼が来ました。丁度 Axis Communications 製カメラ向けファームウェアのプロトタイプが出来上がっていたので、屋外用で暗所撮影に強いモデルを選び、LTEルーターと組み合わせたものを使ってもらうことにしました。稼働直後に発生した不具合をリモートから解析してソフトウェアアップデートすると、安定して動きます。晴れた日もこれで怖くなくなりましたw。画質についても評判は上々で、追加発注ももらったので、これを新ボックス型カメラにすることを考え始めていました。そんなところにあったのが、サカキコーポレーションさんからのお声がけでした。お話を聞くと、太陽光発電所向けにセンサーとそのデータをモバイル回線経由で収集する機材を売っているとのこと。カメラも設置したいという要望が多いので、ボックス型CC-1カメラみたいなものを何か一緒に作れないか、というご相談でした。 新ボックス型カメラにもルーターのリモート制御ができないという課題がありました。セーフィー対応のデバイスはリモートから状態の取得や制御、ソフトウェアアップデートを行うことができるようになっています。それによって、安定した運用や機能追加による「賢くなるカメラ」を実現しているのですが、それが市販のルーターではできません。それらの機能に加えて、屋外対応やPoE(Power over Ethernet)といったカメラ設置のための機能も兼ね備えたものがサカキコーポレーションの全天候型防水カメラルーター「SCR1800」とそれを利用したLTE搭載クラウド型防犯カメラ「 Safie Go 」シリーズです。 固定インターネット回線がないところでも電源さえあれば簡単に設置してセーフィーを利用できることによって、工事現場など数多くの場所に設置いただき、防犯や現場を遠隔地から確認することによる業務効率化などに活用いただいています。Safie Goに続いては、小型化とバッテリー駆動により身につけて持ち歩くことができ、見る・聞くに加えてWebRTCによる双方向のコミュニケーションも兼ね備えた「 Safie Pocket 」シリーズへと、さらなるどこでも簡単を追求をした開発を続けています。 また最近では、業務効率化に加えて、 新型コロナウィルス対策のために現場での対面検査を避ける必要がでてきました 。リモートから映像を用いてリアルタイムに工事の状況確認と承認を行う「遠隔臨場」が要請されるにつれて、「Safie Go」「Safie Pocket」共に改めて注目されています。 エコシステム セーフィーでは「映像から未来をつくる」をビジョンに掲げ、ユーザーの課題を解決する商品を作り続けて来ました。カメラの映像を見るという基本的なサービスから始まって、ユーザーが見る必要を無くす画像解析やAIの技術を取り入れたサービス、時間と場所の制約を超えたコミュニケーションを可能にするサービスへと幅を広げています。我々は最新の技術を取り入れたサービスを開発して提供するのはもちろんのこと、映像のプラットフォーマーとして自分たちの技術をさらに活用してもらう方法を提供していきたいと考えています。ご紹介したカメラの共同開発に加えて、テックパートナーへのAPI公開やアプリケーションSDKの提供により、セーフィーの映像プラットフォームとテックパートナーの技術の相乗効果による新サービスが生み出され、より多くのユーザーの課題を解決する。それによって強化されたプラットフォームがさらなる新サービス開発の原動力になる。そのようなセーフィーを中心としたエコシステムを構築していくための活動も開始しています。 もっと手軽で便利に防犯カメラを使えるようにしたい、という小さな思いから3人で始めたセーフィーのサービスは、ユーザー様やパートナー企業様を始めとした多くの方々に支えられて、プラットフォームに発展し、さらに多くの人や技術を巻き込んで成長しています。 これからも歩みを止めることなく新しい商品をどんどん提供していきますので、お楽しみに！ 最後に セーフィーでは新しい商品を一緒につくっていただけるエンジニアを募集しています！   open.talentio.com  

AWS IoT@Loftイベントでセーフィー の動画制御システムについて登壇しました。 ※セーフィーはクラウド録画サービス「Safie（セーフィー）」を運営しています。   セーフィーでCTOをさせて頂いている森本です。   先日、AWSさん主催の IoT@Loftイベント第9回 にて登壇させて頂きました。 イベントテーマが「IoTにおけるカメラ・動画の扱い方」だったので、まさに弊社サービスにピッタリのテーマという事でありがたく参加いたしました。     当日は残念ながら昨今の情勢を踏まえオンライン配信での開催でしたが、150名を超える方々にご参加頂き、IoT@Loftイベントでも最大規模になったいう事でありがたい限りでした。 尚、イベントで配信に利用されたシステムはもちろんAmazon Chimeでした。利用させて頂くのは初めてだったのですが、特に問題なくスムーズに利用する事が出来たとの所感です。   当日のスピーカーは私含め計2名で、ソラコムさん、セーフィーと登壇させて頂いた後、AWSさんよりIoTシステムを容易に構築可能なマネージドサービスについてのご紹介がありました。 AWSさんが当日のレポートを以下のブログにて公開されていますので、こちらをご覧頂ければそれぞれの発表内容が良く分かります（AWSさん、ありがとうございます）。 https://aws.amazon.com/jp/blogs/news/event-report-iot-at-loft-9/   上記ブログでもご紹介頂いていますが、セーフィーの発表では実際にSafieサービスで利用されている動画制御システムについてお話いたしました。   今でこそAWSさんのAmazon Kinesis Video Streamsがリリースされていますが、6年程以前にそういったサービスが存在しないなか、どういったビジネス要求がありそれに対応するためにどのようなシステムを作り上げてきたかについて記載しています。ご興味がある方は是非目を通して頂けますと幸いです。   Safie動画制御システム全体構成 尚、上記が弊社の動画制御システムの全体構成図となります。 以下のような柔軟な機能をサポートする事により、Amazon Kinesis Video Streamsと比べても遜色ないシステムを構築し、それを実サービスに利用できていると自負しております。 HLS/WebRTCのハイブリッドサーバー配信により1秒以内の遅延を実現すると共に、環境要因などでWebRTCが利用できない場合はHLSでの自動フォールバック配信をサポート YouTube Liveと言った大規模配信システムへのRTMPパブリッシング、画像解析系サービスへのRTP/JPEGでの送信など、柔軟な配信制御が可能 上記全てをできる限りトランスコードを行わず、低コンピューティングリソースで実現   2020年3月時点で8万台を超えるカメラが出荷されており、上記動画制御システムを通して約6PB（ペタバイト）のデータが弊社システム上に保管され、配信や解析に利用されています。   最後に 今回はAWSイベント登壇レポートを公開させて頂きました。 尚、弊社としては今後画像解析システムとの連携を更に強化していくべく開発業務に取り組んでいますが、まだまだエンジニアさんが足りていない状況です。ご興味がある方はお気軽にご連絡頂けますと幸いです。   open.talentio.com

今回はSafie（セーフィー）サービスのシステム構成について概要説明させて頂きます。 ※セーフィーはクラウド録画サービス「Safie」を運営しています。 セーフィーでCTOをさせて頂いている森本です。 前回はSafieサービスのシステム構成について簡単に説明しましたが、今回はその構成要素である Safie対応カメラについて少し踏み込んで説明いたします。 Safie対応カメラ セーフィーは現時点では自社でカメラの開発は行なっていません。 理由は大きく2点あります。 ベンチャーにとってハードウェアを自前で開発する事は極めてハイリスクである。 私は過去複数のハードウェアプロダクト開発に関わってきました。 その中で何度も体験して来た事ですが、ソフトウェアであれば問題があった場合にはアップデートという手段が取れます（リモートアップデートに対応していなければ、ハードウェアが設置されている場所まで行かないといけないなど、対応状況により手間は大きく異なりますが）。 一方ハードウェアの場合は簡単に解決出来ず作り直しが必要になってしまう事も多々あります。 作り直しには時間も、お金もかかりますので体力がないベンチャーにとっては大きなダメージとなってしまう事もあり得ます。 高品質なIPカメラが既に数多く存在する。 世界中はもとより日本にも一定レベルの品質のハードウェアを開発している会社が多数存在します。 それらをSafieサービスで利用できるのであれば、わざわざリスクを犯す必要はありません。 以上よりセーフィーではできる限り自社でハードウェアを開発せず既存商品を使用するというスタンスを取っています。 ただし、一般的なIPカメラをそのまま使った場合以下のようなセキュリティ上の問題が存在する事がよく知られています。 パスワードがデフォルト設定のままとなっている事がある。 一般的なIPカメラは出荷時にデフォルトパスワードが設定されており、IDやパスワード変更がエンドユーザーの手に委ねられています。その為適切に設定されていない場合には誰でもアクセス可能となっている事があります。 実際に数年前には適切にパスワードが設定されていない世界中のカメラがインターネット上に晒されて誰でも見れる状態となっていました。 外部向けにポートが開放されており、攻撃される可能性がある。 一般的なIPカメラはエンドユーザーが直接アクセスするような仕組みとなっており、その為のポートが開放されています。 適切にパスワードが設定されていた場合でも開放されたポートは攻撃対象となり得、例えばIPカメラのソフトウェアに脆弱性が潜んでいた場合に、内部に侵入されるリスクへと繋がります。 前述の通りセーフィーではハードウェアの開発は行なっていませんが、一般的なIPカメラを自社サービスに対応させる為、専用のファームウェアを開発しハードウェアベンダーに公開しています。 専用ファームウェアには同時に上記の問題を解決する為、独自の仕組みを搭載しています。 Safie ファームウェア Safieファームウェアを組み込む事により一般的なIPカメラがSafieサービスで利用可能となります。 このカメラは一般的なIPカメラとは異なる以下のような特徴を有します。 ※Safieファームウェアを搭載したカメラを「Safie対応カメラ」と称します。   ネットワークのクライアントデバイスとして駆動する。 一般的なIPカメラと異なり、Safie対応カメラではユーザーからの直接アクセスは基本的に受け付けません。 ユーザーはクラウドサーバーを経由してアクセスする事のみが可能となります。 このため、Safie対応カメラでは外部に対しポートを開放してアクセスを受け入れる必要がありません。 エンドユーザーによる設定不要。 ID/パスワードもSafieファームウェアが独自に設定する為、デフォルト設定からの変更漏れも一切発生しません。 合わせて通信経路も確実に暗号化を実施する為、通信を傍受された場合にもデータを盗み見られる事はありません。 この為、Safie対応カメラは一般的なIPカメラと比較し、セキュリティ面のアドバンテージも大きくなっています。   また、Safieファームウェアはカメラメーカーが組み込みやすいよう共通レイヤとポーティングレイヤを分離して提供しています。異なるハードウェア上でもインターフェースを適切につなぎ合わせれば容易にSafie対応カメラを開発することができ、幅広いタイプのIPカメラで利用する事が可能となっています。 ※IPカメラによっては対応不可なものも存在いたします。   これにより、現状では数100種類を超えるIPカメラをSafieサービスで利用する事が出来ます。 現在広く使われるようになったSafieサービスですが、その広がりの 一端を担う 重要な構成要素となっています。 最後に 第3回目という事で、Safieサービスの構成要素について説明させて頂きました。 引き続きサーバーシステムなど他の要素についても説明していく予定ですので、よろしくお願いいたします。        セーフィーでは一緒に働いてくれるエンジニアを募集しています！   open.talentio.com

今回はSafie（セーフィー）サービスのシステム構成について概要説明させて頂きます。 ※セーフィーはクラウド録画サービス「Safie」を運営しています。 セーフィーでCTOをさせて頂いている森本です。 前回は会社の説明などご挨拶的な内容で終わってしまいましたので、今回はSafie（セーフィー）サービスのシステム構成について少し説明をさせて頂きたいと思います。 Safieのサービスは、ざっくり言うとSafie対応カメラ、Safieクラウドサーバー、Safieアプリケーションから構成されています。 それぞれについては以降で少しだけ詳しく説明しますが、技術領域としてはハードウェア、サーバー、インフラ、アプリケーション、動画配信、データ解析といった要素を全て含みます。この為一般的なWebサービスに比べて関わる技術要素のレンジが極めて広くなっているのが大きな特徴だと思っています。 当然ですがそれらの開発、運用を行う為様々な技術バックグラウンドのエンジニアが在籍し、お互いに意見を交換しながら日々の開発活動を行なっています。 また、プラットフォームと称している理由にも繋がりますが、他社サービスとの連携も行う事を前提としてシステムの開発を行なっています。 セーフィー対応カメラ   Safieクラウドサーバーに接続可能なカメラの事を指します。 弊社では基本的には自社でカメラは開発をしていません。 その代わりカメラ内で駆動するソフトウェアモジュールを開発し、カメラベンダーに配布しています。 このソフトウェアモジュールはネットワーク制御、セキュリティ管理、動画制御、カメラ制御などSafieサービスに必要とされる全ての要素を備えており、当該モジュールを組み込むだけでSafieサービスにサービスインする事が可能となっています。 主としてC、C++が利用されており、一部Pythonなどが使用されることもあります。 セーフィークラウドサーバー   ここでは詳細は省きますが、PaaS上に構築され、全カメラの制御、ユーザー管理、動画配信、画像解析、データ連携などを行なっています。 一般的なメディア系ライブラリ、画像解析系ライブラリがネイティブである事が多いため、親和性も考慮し大部分にPythonを採用しています。 特性上24時間365日サービスを止める事は出来ないので、無停止でのメンテナンス、機能追加にも対応しています。   執筆時点で7万台を超えるカメラを出荷、500台を超えるサーバーが常時稼働しており、約6PB（ペタバイト）のデータが弊社プラットフォーム上に保管されています。 セーフィービューアー セーフィー デモ画面（PCのみ） iOS App Store Android Google Play Safieのサービスが利用できるエンドユーザー向けのアプリケーションです。 WebアプリケーションはAngularを、MobileアプリケーションはSwift、Kotlinを採用（開発中含めて）しています。 今の所、カメラの制御、閲覧などの基本機能が利用できる標準アプリケーションに加え、例えば顔認証サービス専用アプリケーションなどを提供しています。 今後は各種サービスの追加に合わせて専用アプリケーションやセーフィー 以外の開発者がアプリケーションを開発できるようなSDKも拡充して行きます。 最後に 第二回と言うことでSafieサービスの全体像について説明させて頂きました。 次回からは各要素の詳細なお話、個別の技術的なお話など中心にご紹介させて頂こうと考えていますので、引き続きよろしくお願いいたします。 セーフィーでは一緒に働いてくれるエンジニアを募集しています！ open.talentio.com

こんにちは、セーフィーでCTOをさせて頂いている森本です。 2014年に3人で創業したセーフィーもお陰様でビジネス的にも会社的にも成長が実感できるようになってきた今日この頃ですが、今更ながら技術ブログを始めていきたいと思っています。 何をやっている会社か？ 上記のように書き出しましたが、そもそもどういった事をやっている会社か説明が必要ですよね。 一言で言うと動画のクラウド録画、配信プラットフォームを開発・提供している会社です。 といってもよく分からないと思いますので、詳細情報は以下のリンクをご覧ください。 safie.link カメラの録画、配信だけでなく、動画とメタ情報の紐付けや、例えば人数カウント、顔認証など画像解析関連のサービスを展開しています。 何を目指しているのか？ 弊社は「映像から未来をつくる」をビジョンとして掲げています。 この「未来をつくる」には色々な意味を込めています。例えば分かり易いところでは多くの人が見たいことや知りたいことを簡単に分かるようにする事です。それによって多くの人が抱える課題を解決する事を目指しています。 我々は全社員一丸となって、ビジョンの実現に向けて日々活動を行なっています。 なぜ技術ブログを始めるか？ 繰り返しになりますが、我々は全社として上記に取り組んでおり、弊社の技術、エンジニアリングチームはその実現のための最重要要素の一つとなります。 そんな中、エンジニアさんの数が足りていない事、及びその要因の一つでもありますがセーフィーの知名度が低い事に課題を感じています。 弊社サービスは当然のことながら防犯用途でも広く使って頂いていており、ホームページにもその事は大々的に記載しています。 ただ、実態としてはそれ以外の用途でも幅広く使われており、関わる技術領域的にも極めて広いのですが、外部のエンジニアさん目線から見ると「防犯カメラサービスをやっている会社」と言うところで終わってしまっているのかな、と感じる事が多々あります。 ブログを書く目的は、広くみなさんに弊社がどういった事をやっているか知っていただく事と、あわよくばそれが先々の採用に繋がる事にあります。 最後に まずは初回という事もありますが、技術ブログと言う割には会社説明といった内容で終わってしまいましたので、次回からは各要素の詳細なお話、個別の技術的なお話など中心にご紹介させて頂こうと考えています。 引き続きよろしくお願いいたします。     セーフィーでは一緒に働いてくれるエンジニアを募集しています！   open.talentio.com