こんにちは。セーフィー株式会社 エンジニア 谷口、江守です。 今回、セーフィーで初めての 社内ハッカソン を開催しました！ 所属部門内に閉じた形ではありますが、事業成長とともに組織が変わっていく中で、組織活性化の手段として、また単純にハッカソンをやりたい！という個人的な思いを掛け合わせて実現させました。 その過程と実際に開催した内容をご紹介したいと思います。 ハッカソンをやりたいと思った理由 実施の承認を得る どのような形で開催するか 社内ハッカソン実施要項 目的 期間 参加者、チーム分け、作るもの 進め方 成果発表 その他 チーム分けと企画内容 途中経過 発表会 最後に ハッカソンをやりたいと思った理由 最近の組織変更で、所属部門に営業-企画-エンジニアといった複数の職能が集まる部門となり、同じ目標を共有するメンバーとして 一体感を醸成したい 思いがありました。 また、弊社は技術領域が広く、様々な職種のエンジニアがいます。 （詳細はこちら→ セーフィーにはどんな種類のエンジニアがいるの？職種別にエンジニアを紹介！ - Safie Engineers' Blog! ） 私自身はフロントエンドですが、組織変更で組み込みやAIなどのエンジニアとも同じチームになったことで、それらについても知りたいと思うようになりました。 ただ、全く知識がない中でいきなり業務となるとハードルが高いので、まずは軽く触ってみる程度で知ることができる手段を考えたときに、ハッカソンを思いつきました。 実施の承認を得る これらの思いを上長との1 on 1で会話する中で快く賛同して頂き、社内ハッカソン開催に向けて準備することになりました。 どのような形で開催するか 私自身の経験としては、外部のハッカソンイベントに2回参加したことがあります。 しかし、いずれもエンジニアのみの参加で数日間で企画〜デモまで行うもので、大体の流れは把握していましたが、社内ハッカソンは初めてでした。 そこで社内ハッカソンを行った他社のブログをいくつか参考にさせて頂きつつ、実施要項を決めました。 決めるにあたって意識したことは以下です。 スモールスタートでやってみようということで、 所属部門内での開催 とすること。 営業や企画も参加しやすいように、普段の業務でこんなのできないかな？といった アイデア出しだけでもOK とすること。 デモをゴールとせず、競争要素も排除し、 コミュニケーション活性化 を目的とすること。 エンジニアは、一人で進めてしまうといったことがないように（目的であるコミュニケーション活性化につながらないため）、 担当技術領域以外にチャレンジ すること。 初めての開催でいきなり数日間業務を止めるのは難しそうなので、 薄く長く開催する こと。 忙しくて時間がとれなかった...がなるべく発生しないように、業務時間内に、 業務の一環として行う こと。 業務として行うので目標/評価に連動できるような開催期間とし、 目標に入れる こと。 モチベーションの維持のため挙手制とし、 モチベーションの高いメンバーのみで行う こと。 活動費用は会社負担 とすること。 社内ハッカソン実施要項 営業、企画、エンジニアでやりたい人が集まってアイデア出して何か作ってみよう アイデア出しだけでも参加OK、もちろん経験がないけど作ってみたいもOK 目的 営業含めたプチ案件や便利ツールを開発することによるコミュニケーション活性化 自分の保有していない技術領域に関して知見を得る場 期間 3ヶ月 参加者、チーム分け、作るもの 挙手制、参加者でやりたいことを持ち寄りチーム分け 進め方 例えば、チームごとに隔週2時間、スケジュールを先に抑えてその時間内で行う、など、業務時間内に、かつ忙しくて時間がとれなかった...がなるべく発生しないような仕組みにする 成果発表 所属部門内で発表会（デモ）を行う 順位付けなど競う要素はなし その他 必要な機材費等の費用は会社負担で購入 エンジニアは担当技術領域以外の開発にチャレンジすること チーム分けと企画内容 募集をかけ、参加者が確定したところで、まずはテーマ等を設定せず各人がやりたいことを持ち寄ってもらいました。 いくつか同じような内容があったのでマージしつつ、どのテーマに取り組みたいか記名してもらい、営業-企画-エンジニアのバランスをとりつつ、以下4チームになりました。 ラズパイとセンサーを組み合わせて、イベント検知とセーフィー映像の連携 Hey Siri, Safie Pocket2 でスナップショット撮って 宇宙 x Safie GO - 衛星通信対応SIMでの、どこでも繋がるGO センサー等連携ハブとしてのカメラ 営業、企画が参加してくれたことにより、顧客ニーズから自社サービスとしてこんなことできたらいいよね、といった 具体的でかつ色々な技術領域にチャンレジ できるとてもよい企画内容が出来上がりました。 途中経過 ハッカソン実施要項の「エンジニアは担当技術領域以外の開発にチャレンジすること」が意外によく効いていて、例えばフロントエンドエンジニアがラズパイとセンサーの組み合わせに取り組んだとき、そもそも、ラズパイとセンサーってどうやって繋げるの？ブレッドボードってなに？A/Dコンバーター？？抵抗って...大きさは適当でOK？？など、デバイス部分が全く分からず、ソフトウェアだけの、なんて狭い世界で生きてきたんだ...と打ちのめされていました。 ラズパイとセンサーの配線 接続した感圧センサー、センサー小さすぎ！こんな接続でよいのか謎 配線を終えようやくソフトウェアまで辿り着き、Pythonでロジック調整中 発表会 広めの会議室をとり、ハッカソン参加者と一部の出社していたメンバーは会議室で、他はオンラインで、といった形で発表会を実施しました。 発表にあたって決めたことは、1チームあたりの発表時間と発表順だけで、どのように見せるかや発表用の資料を作成するか、などは各チームに任せました。 デバイスをどう接続したのかなど、オンライン参加のメンバーにも伝わるように、事前に同じ会議室でリハーサルをしたり、意図が伝わるようにスライドを作成したりなど、自チームにとって今までの活動と成果が一番伝わる形を考え準備してくれました。 ハッカソンあるあるかもしれないですが、発表本番のデモで動かないといったことがままある中で、無事デモも見せることができ、大成功だったと思います。 発表内容を一部ご紹介します。 ラズパイとセンサーを組み合わせて、イベント検知とセーフィー映像の連携 荷受け場に、感圧センサー＋ラズパイとSafieカメラを設置 荷物の重量変化を感圧センサー＋ラズパイで検知する 「荷物が置かれた」「持って行った」をラズパイ上のPythonで判定し、Safie Viewerにイベントフラグを立て、Slack通知する Hey Siri, Safie Pocket2でスナップショット撮って 最後に ハッカソンが初めてのメンバーもいて、エンジニア以外の職種でも参加しやすい形や、参加は挙手制、デモすることを目的にしない、など、 とにかくゆるく、ただ何かしら発表はできるように 、を意識して運営しました。 一部のチームはデモまで辿り着けなかったのですが、今回の目的はそこではなくコミュニケーション活性化なので、一定程度達成できたのかなと思います。 やりたいことを快く賛同して後押ししてくれた上長、挙手制でしたが盛り上げるために目的を理解し参加してくれたメンバー、発表会に来てくれた事業部のみんな、何かの取り組みを皆で応援できることは素晴らしいことだと思います。 社内ハッカソンや何か社内での取り組みを考えられている方の参考になれば幸いです。 ありがとうございました！

こんにちは。セーフィー株式会社 バックエンドエンジニアの河津です。 セーフィーにはクラウドカメラやユーザーアカウントを一括管理できる統合環境である「 Safie Manager 」というサービスがあり、主にエンタープライズのお客様にご活用いただいています。 safie.link 7/7(木)には SSO(シングルサインオン)の機能をリリース しました！ 今回はそのリリースされたばかりの新機能「シングルサインオン(以下SSO)」と、それを実現させる仕組み「SAML認証」について解説させていただきます。 SSOについて 1. 利便性が上がる 2. セキュリティリスクが下がる 3. IT部門での管理が容易になる SAML認証に関わる用語解説 SAML認証について 1: ユーザーがアプリケーションにアクセス 2: SAML認証要求を生成 3,4: IdPへのリダイレクト 5: SAML認証要求を受け取り、認証を試みる 6,7,8: ユーザー認証 9: SAML認証応答を作成 10: SPへの302 HTTP POST Binding 11,12,13: SAML認証応答を検証し、ユーザーログインを許可 14: ログイン成功 Safie ManagerとSSO まとめ SSOについて SSOとは、1度システム利用開始のユーザー認証 (ログイン) を行うと、複数のシステムを利用開始する際に、都度認証を行う必要がない仕組みのことです。 基本的に一つのWebサービスで使われるID・パスワードなどの認証情報はそれぞれ独立しており、Aのサービスを使用するにはAの認証情報、Bのサービスを使用するにはBの認証情報が必要です。 SSOを使用すると、この各サービスで分かれてしまう認証情報を統一して使用することができるようになります。 例えばAzure Active Directoryのような認証基盤を利用している場合、その認証基盤とWebサービスを連携させることで、認証基盤の方にログインするだけで様々なWebサービスを使うことができるようになります。 SSOのメリットは大きく3つあるかと思っています。 1. 利便性が上がる 認証基盤にログインさえしていれば、各WebサービスでIDやパスワードなどの情報を入力する必要がなくなるため、Webサービスの利便性が上がります。 2. セキュリティリスクが下がる 本当はあるべきではないですが、各WebサービスでIDやパスワードを使い回してしまうユーザーは一定数いるのではないかと思います。ただ、同じID・パスワードを各Webサービスで使い回すと、その分だけ流出する可能性を増やすことになります。 認証基盤を経由するSSOであれば、流出する可能性のあるサービスは認証基盤のみに絞られることになります。 この場合、認証基盤のID/Passwordが漏れた場合は全てのサービスにアクセス可能なリスクが残るものの、認証基盤には2要素認証機能やクライアント証明書の検証機能が含まれていることが多いため、それらの機能を併用する前提であればSSOを使用する方がセキュリティリスクが下がるのではないかと思います。 3. IT部門での管理が容易になる 各Webサービスの認証情報が認証基盤に集約されると、アカウントの停止やパスワードの変更などを行う際は認証基盤を操作するのみでよくなるため、とても楽になります。 SAML認証に関わる用語解説 SSOを実現するための認証手法はいくつかありますが、セーフィーから提供しているSafie ManagerではSAML認証をサポートしております。 これからSAML認証の解説をさせていただきたいと思っていますが、その前に解説に必要となる用語の説明をさせていただきます。 IdP(Identity Provider) : 認証情報を提供する側のシステムです。上の説明で出てきた「認証基盤」がこちらになります。 SP(Service Provider) : 認証情報を利用する側のシステムです。 Safie ManagerではSSO機能をサポートしていますが、本記事が公開された段階では認証基盤についてAzure Active Directoryを推奨とさせていただいております。上の用語に当てはめると、Safie ManagerはAzure Active Directoryを認証基盤として使用しSAML認証を行うことになるので、この場合はIdP=Azure Active Directory、SP=Safie Manager となります。 以降ではIdP・SPという用語を用いて解説をさせていただきます。 SAML認証について ここから本格的にSAML認証の話をしていきますが、SAML認証はそのフローの複雑さから初見で理解するのはかなり難しい処理だと(個人的に)思っています。 この記事を一度読むだけですと、もしかすると不明点だらけになってしまう恐れがあるため、2度・3度ほど読み返していただくことをおすすめします。 まずSAMLとは、Security Assertion Markup Languageの略称です。インターネットドメイン間でユーザー認証を行なうためのXML（マークアップ言語）をベースにした標準規格のことを指すのですが、「インターネットドメイン間でユーザー認証を行う」という点がまさしくSSOでやりたいことになります。SSOでは、IdPとSPという異なるドメイン同士で認証を確立させる必要があるためです。 SAML認証ではどのようなシーケンスで処理が行われるのでしょうか？シーケンス図を起こしてみました。 様々な処理が入り乱れていますね。 一つ一つ処理の内容を取り上げていきたいと思いますが、その前にSAML認証の事前準備の話をさせてください。 シーケンスを見ていただければ分かるとおり、SPからIdPにリダイレクトしたり、IdPからSPに戻ってきたりしているようです。このリダイレクト先は、事前にわかっていないとリダイレクトすることができません。SAML認証の事前準備として、SP・IdPそれぞれの認証エンドポイント情報を登録しあう必要があります。 また後に触れますが、IdPから送られてきた情報が正しいものであるのか検証するフローがあり、IdPより発行した公開鍵をSPに登録することも必要となります。それらの事前準備を経ることで、SAML認証が可能となります。 それでは、割り振った番号それぞれで行われている処理について解説します。 1: ユーザーがアプリケーションにアクセス ここでは、SAML認証を行うためのログインボタン押下などのアクションをイメージしていただけたらと思います。 2: SAML認証要求を生成 ユーザーがアプリケーションにアクセスした際に最初に行われるのは、SP側で SAML認証要求 が生成される処理です。 SAML認証要求 とはSPからIdPに「今からこのユーザーでSAML認証したいので許可をください」とIdPに要求するためのデータです。 フォーマットとしてはbase64エンコードされたXML形式のデータとなります。 < md : EntityDescriptor xmlns : md = "urn:oasis:names:tc:SAML:2.0:metadata" validUntil = "2022-02-10T08:51:19Z" cacheDuration = "PT604800S" entityID = "{SPのEntityID}" > < md : SPSSODescriptor AuthnRequestsSigned = "false" WantAssertionsSigned = "false" protocolSupportEnumeration = "urn:oasis:names:tc:SAML:2.0:protocol" > < md : SingleLogoutService Binding = "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location = "{IdPの認証エンドポイント}" /> < md : NameIDFormat> urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified </ md : NameIDFormat> < md : AssertionConsumerService Binding = "urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location = "{SPの認証エンドポイント}" index = "1" /> </ md : SPSSODescriptor> </ md : EntityDescriptor> 上記の中には、SSOを行いたいSPに対する固有のIDや、IdP側の情報などが含まれており、この情報をIdPに渡します。IdPではこれらの情報が想定する情報かどうかを検証することになります。 SAML認証要求をIdPに渡すやり方は単純で、下記のようにIdPの認証エンドポイントに対して「 SAMLRequest 」というキー名のクエリパラメータをつけてリダイレクトすればOKです。 https://{idp_host}/{path}?SAMLRequest=xxxxxxxxxxxxx 3,4: IdPへのリダイレクト 上記にて発行されたURLにリダイレクトします。リダイレクトすると、次はIdP側での処理が始まります。 5: SAML認証要求を受け取り、認証を試みる IdP側では最初にSAML認証要求を受け取り、想定しているSPからのリクエストかどうかを検証します。 検証といっても、ここではXML内のEntityIDなどを突合するくらいの内容になります。 その後もしIdPにログインしていなければログイン画面を表示し、ユーザーにIdPへのログインを促します。 6,7,8: ユーザー認証 もしIdPにログインしていなければ、このタイミングでログインを行います。 ID・パスワードを入力しつつ、IdPによっては2要素認証が導入されていたり、クライアント証明書の有無によるIdPへのアクセス制御などの機能もあるかと思います。 9: SAML認証応答を作成 IdPにて認証が済んでいることが確認できると、IdPでは SAML認証応答 を生成します。 SAML認証応答 とは、IdPからSPに「IdP側の認証はOKなので、その証明を送るよ」といった形で、SP側で認証情報として取り扱える情報です。 こちらもSAML認証要求と同様、base64エンコードされたXML形式のデータです。 < samlp : Response ID = "{SessionIndex}" Version = "2.0" IssueInstant = "2022-07-14T08:50:33Z" Destination = "{SPの認証エンドポイント}" Consent = "urn:oasis:names:tc:SAML:2.0:consent:unspecified" InResponseTo = "xxx" xmlns : samlp = "urn:oasis:names:tc:SAML:2.0:protocol" > <Issuer xmlns = "urn:oasis:names:tc:SAML:2.0:assertion" > {Issuer} </Issuer> < samlp : Status> < samlp : StatusCode Value = "urn:oasis:names:tc:SAML:2.0:status:Success" /> </ samlp : Status> <Assertion xmlns = "urn:oasis:names:tc:SAML:2.0:assertion" ID = "{SessionIndex}" IssueInstant = "2022-07-14T08:50:33Z" Version = "2.0" > <Issuer> {Issuer} </Issuer> < ds : Signature xmlns : ds = "http://www.w3.org/2000/09/xmldsig#" > {署名の内容} </ ds : Signature> <Subject> <NameID Format = "urn:oasis:names:tc:SAML:1.1:nameid-format:xxx" > {NameID} </NameID> <SubjectConfirmation Method = "urn:oasis:names:tc:SAML:2.0:cm:bearer" > <SubjectConfirmationData InResponseTo = "xxx" NotOnOrAfter = "2022-07-14T08:53:33Z" Recipient = "{SPの認証エンドポイント}" ></SubjectConfirmationData> </SubjectConfirmation> </Subject> <Conditions NotBefore = "2022-07-14T08:50:28Z" NotOnOrAfter = "2022-07-14T09:50:33Z" > <AudienceRestriction> <Audience> {SPのEntityID} </Audience> </AudienceRestriction> </Conditions> <AttributeStatement> {IdPから取得できる属性情報} </AttributeStatement> <AuthnStatement AuthnInstant = "2022-07-14T08:50:33Z" SessionIndex = "{SessionIndex}" > <AuthnContext> <AuthnContextClassRef> urn:federation:authentication:windows </AuthnContextClassRef> </AuthnContext> </AuthnStatement> </Assertion> </ samlp : Response> 10: SPへの302 HTTP POST Binding IdPからSPにSAML応答の情報を渡すには、SP側で用意している認証エンドポイントに対しHTTP POST Bindingし、そのリクエストボディに SAMLResponse というキー名で指定し送信します。 ちなみにこの時HTTP POST BindingとなるかはSPから送るSAML認証要求の内容によって決定されます。 # この辺り <md:AssertionConsumerService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" Location= Safie Managerは執筆時点ではHTTP POST Bindingのみ対応しています。 11,12,13: SAML認証応答を検証し、ユーザーログインを許可 SPには上記フォーマットのSAML認証応答が送られ、メールアドレスやユーザー名などの属性情報も含まれていますが、これらの情報をそのまま使用するわけにはいきません。 不正に変更されたSAML認証応答が送られてくる場合も考えられるためです。 SAML認証応答の中には署名の情報があるのですが、この署名情報を検証することで意図したIdPからの認証応答かどうかを確かめます。 検証するには事前にIdPよりダウンロードできる公開鍵が必要になりますので、この公開鍵をSPにあらかじめ登録しておくことが必要です。 14: ログイン成功 検証が成功すると晴れてSAML認証成功となります！ この後は、SAML認証応答から取得できる情報を元に、SPにログインするための処理へと続いていくこととなります。 元々あるSPの認証基盤に合わせてSAML認証を組み込んでいくことになり、各SPによってIdPから取得しなければいけない属性情報に違いが出てくるため、SPごとに実装内容は分かれてくるところになるかと思います。 Safie ManagerとSSO SAML認証を行うには事前にSP・IdPそれぞれに認証エンドポイントや公開鍵などを登録し合うことが必要と書きましたが、私たちが提供しているサービス「Safie Manager」ではどのような画面になっているのでしょうか。 見てみたいと思います。 ほとんど黒で塗りつぶしてしまっていてすみません。 「IdPへの登録情報」という欄に書かれている情報を、IdPに登録するための情報として表示してあります。 逆に、IdP側の情報をSafieManagerに登録する欄として「IdP情報」という項目を設けてありますので、「ログインページのURL」「識別子のURL」「証明書」を登録することで、SafieManager(SP)側の準備は完了です。 今度はIdP側の情報を登録する箇所を見てみましょう。 ここでは例としてAzure Active Directoryを取り扱います。 基本的なSAML構成という箇所にSPの情報を入力し、 {アプリ名}のセットアップ(ここではsafie-manager-sso-testという名前)にSP側に登録する情報が乗っており、証明書もダウンロードできます。 まとめ 今回はSAML認証についての解説をさせていただきました。 SAML認証はかなり複雑な内容で、実装する際にはまず概念の理解に時間がかかってしまうため、この記事が理解の助けになれば幸いです。 サービスにSSO機能を組み込む際は、SAML認証を経た後、SP側のユーザーデータに対して新規登録や認証を行う処理につながってきます。その辺りはSPの既存の認証基盤の仕様によって実装の勘所が分かれる箇所だと思っています。その辺りにも試行錯誤ポイントがあるため、SSO機能の実装を予定されている方は、基本設計・詳細設計の時間を長めに取られることをおすすめします。 ここまで読んでいただきありがとうございました！

プロダクト基盤開発グループデバイスコアチーム、 組み込みエンジニア の楊（よう）です。 セーフィーのプロダクトというと、「 カメラ 」というイメージを持つ方も多いかもしれません。 そんなカメラを始めとしたデバイスの開発は、組み込みエンジニアが担当しています。 今回は 組み込みエンジニアの業務内容やカメラ開発の中身 をご紹介したいと思います。 セーフィー組み込みエンジニアの業務 Safieカメラ・デバイスの構成 Safie Client SDKの開発 カメラ・デバイスの開発 自社カメラの開発 他社市販カメラのSafie化開発 Safie Client SDKを外部へ提供 Safieエッジアプリやそのプラットフォームの開発 最後に セーフィー組み込みエンジニアの業務 以前、「 商品開発の歴史 」の記事でもご紹介したように、セーフィーでは創業以来さまざまなカメラとデバイスを開発してきました。 デバイス開発をメインで担当する組み込みエンジニアの業務・開発内容は、採用サイトにも記載があるように、主にこちらの6つになります。 カメラ・デバイス開発 Safie Client SDKの開発 エッジアプリプラットフォームの開発 CI/CD環境や開発環境の整備と改善 カメラ設定用各種ツール開発 カメラユーザーの問い合わせ・障害対応 今回は、上記のうち「 カメラ・デバイス開発 」、「 Safie Client SDKの開発 」、「 エッジアプリプラットフォームの開発 」にフォーカスし、Safieカメラの構成と併せて説明します。 Safieカメラ・デバイスの構成 セーフィーでは SafieClient という実行ファイルを各カメラ/デバイス向けにビルドして搭載しています。 当初、SafieClientはカメラの制御/映像の送信を担うだけでしたが、現在ではSafieエッジアプリを管理する機能も実装され、Safieプラットフォームの一部としての機能を日々進化させています。 SafieClientは大まかに下記三つのモジュールによって構成されています。 Safie Client SDK ：サーバへの映像/音声の送信、サーバからの命令処理などSafieClientのコア機能がここに集約されています。 Camera I/F ：各カメラ/デバイスの固有実装への対応を担います。映像/音声データを取得してSafie Client SDKに渡したり、Safie Client SDKからの命令に応じてカメラ/デバイスの制御を行ったりします。 SafieエッジアプリやEdgeAppFramework ：Safieエッジアプリがセーフィー対応のカメラ/デバイスに配布可能なエッジアプリになります。EdgeAppFrameworkがSafieエッジアプリの動作管理を担っており、必要な一連の開発環境も含まれています。現在開発中のAIカメラ用のエッジアプリもこちらの仕組みを利用して開発しています。（厳密にはSafieClientとは別のプログラムですが、SafieClientによって制御される付随したモジュールになります。） Safie Client SDKの開発 Safie Client SDK の基本的な役割は、Safieクラウドとの接続管理と各カメラ/デバイス全体の管理です。そして、通信状態が悪くても映像を視聴できるように、また通信状態が復帰した時に映像をリカバーできるように色々工夫しています。また、Safie Client SDKはSafieが対応する全てのカメラに共通で使われているので、どのカメラでも動くよう汎用性のある設計・実装にする必要があります。 Safie Client SDKの機能を項目としてまとめると以下の通りです。 詳細の説明は割愛しますが、イメージをつかんでいただければ幸いです。 ・デバイスのクラウド接続時の自動認証 ・Safieクラウドとの安全・安定な接続・再接続 ・カメラの制御、カメラの状態管理 ・カメラの動画ストリームやイベント、通知のアップロード ・通信状態が悪い時のビットレート調整 ・通信切断状態の映像のバックアップと後のリカバリ ・LogやDebug情報のアップロード ・SafieClientまたは各カメラ/デバイスのシステムFW更新 ・WebRTCのシグナリング ・Safieエッジアプリの管理 また、カメラの数やユースケースの増加と共に、以下のような機能追加・改善を検討しています。 ・よりスマートなビットレート調整 ・通信状態によらず録画欠損の無いバックアップと後のリカバリ ・設置環境やニーズに合わせたハイブリッド映像配信（デバイス配信/サーバー配信） ・プラットフォーム化に伴うセキュリティ対策 ・Androidなど汎用プラットフォームへの対応 そして、今まではプロダクトを市場に出すことを優先してきたため、技術負債が溜まっています。 今後の市場拡大を考慮すると、より品質を担保するためにも負債を解消しなければなりません。 現在は、CI/CD環境の整備やエミュレーション環境の構築などを通して、負債の解消を目指しています。 カメラ・デバイスの開発 Safie Client SDKがSafieの共通機能をまとめて対応しているので、新規カメラ・デバイスの開発・対応が基本 Camera I/F でカメラ固有機能の開発になります。基本的に以下3つのパターンに分類されます。 自社製カメラの開発 他社市販カメラのSafie化開発 Safie Client SDKを外部へ提供 自社カメラの開発 自社製の代表的なカメラと言えば、 CC-2シリーズ 、 Safie Pocket2 、現在開発中のエッジAIカメラになります。 自社製と言ってもセーフィーでは、ハードウェアも含めて完全に社内で開発する訳ではなく、カメラ製品開発能力があるハードウェアベンダーとの協力開発になります。ハードウェアおよびOSなどのシステム周りの開発と製造を先方にしてもらって、セーフィーがその上位にあたるカメラ全体の制御や通信部分の開発を行うのが一般的です。 ただ、製品の開発元として全体を見通した工程管理を行う必要があるので、場合によってドライバレベルのデバッグや試作もハードウェアベンダーと一緒にやる必要があります。また、新しいハードウェアベンダーにもセーフィーにもノウハウがない技術の開発をする際は、我々組み込みエンジニアが先陣を切って勉強するところから始めなければなりません。これからは新しいカメラを開発する機会も増えてくるので、5G、手ぶれ補正、位置推測など技術的な挑戦をする機会がたくさんあります。 また、これからは事業の拡大とともに、理想的な製品や機能の開発、より安くて高い品質を保つためにも、当社の組み込みエンジニアがソフトウェア開発だけではなく、ハードウェアを設計する技術や生産管理のノウハウも積極的に貯めて守備範囲を拡げていく必要があります。 他社市販カメラのSafie化開発 「 商品開発の歴史 」の記事でもご紹介したように、セーフィーではユーザーぞれぞれの利用用途、設置環境のご要望に応えるため、またより多くの販路やパートナーを巻き込むため、自社製のカメラだけではなくトップメーカーであるAxis Communications社やVivotek社を始めとした、他社製市販のセキュリティカメラのSafie対応を行っています。 他社市販カメラはRTSPやONVIFといった映像を取得したり制御したりするために規格化されたインターフェースを持っていることが多く、さらにAxis Communications社のACAPやVivotek社のVADPのようなアプリケーションプラットフォーム機能を持っているカメラもあります。他社市販カメラのSafie対応は基本はRTSP /ONVIFあるいはそのカメラ特有のアプリケーションプラットフォーム機能を使うCameraI/F開発になります。 そして、各種他社市販カメラは基本的にはLinuxベースのデバイスになりますが、ToolchainやSDKがそれぞれ異なっているので、ビルド環境の整備や再現が大変です。今はDockerでカメラToolchainを管理するなど色々工夫をしています。 Safie化している他社市販カメラは、AXIS社とVivotek社のカメラだけで200機種以上、機能や仕様も様々です。多くの機種に対応することによって、Safieがカバーできる利用用途や設置環境はかなり増えますが、その分サポート対応が煩雑になります。 Safie Client SDKを外部へ提供 Safie対応のカメラはすべて自社で開発したわけではありません。条件次第で、積極的に Safie Client SDK を開発パートナーへ提供して共同開発をしています。当然、技術的なサポートは組み込みエンジニアから行います。 Safie対応カメラを増やしていく為には、様々な開発パートナーにより広くカメラ開発を行って頂くのが理想的ですが、今はまだSafie Client SDKが使いにくいなどの課題があるので、偶に密なコミュニケションしないと開発が進まないケースや自社で開発した方が早いケースがあります。なので、これからはSafie Client SDKをより使いやすくし、今後いずれオープンソース化などしてより誰でも使えるようにしていきたいと思います。 Safieエッジアプリやそのプラットフォームの開発 昨今ではカメラ(エッジ側)で処理できることが増えています。そのため多くのカメラをSafie化したとしても、機能追加できるのが自社のエンジニアだけになってしまうのはとてももったいないと考えています。 そのため、セーフィーではテックパートナーと協創できるプラットフォームの実現を目指しており、その一環として SafieEdgeAppFramework を開発。現在はエッジAIカメラ用のAIエッジアプリやWebRTC音声通話機能の開発環境として使っています。 SafieEdgeAppFrameworkは、SafieデバイスにデプロイできるSafieエッジアプリを動かす・開発するためのフレームワークになります。Safieエッジアプリを開発するためのツールとしては、以下の一連機能を提供しています。 ・アプリの自動生成 ・アプリのビルド・構築 ・単体テスト環境 ・実機デバッグ環境 ・アプリの登録・デプロイ そして、Safieエッジアプリの実装に関しては、以下の機能・ライブラリーを用意。カメラから映像などの情報を取得して解析をしたり SafieクラウドとRPC通信で連携するエッジアプリを作ることができます （現状Safieエッジアプリの実装は C++ だけサポートしています）。 ・アプリのリモート更新 ・アプリのリソース（推論モデルなど）のリモート更新 ・Safieクラウドからのアプリ設定 ・RPC通信（Safieクラウドから、他のSafieエッジアプリから、WebRTCなどのP2P通信から） ・イベントをSafieクラウドに送信・記録 ・カメラの映像・イベントを購読 ・カメラ制御・Overlay設定など ・3rd Party Libs（TensorflowLite、OpenCV、Dlibなど）、デバイス固有のSDK（SNPEなど） Safieエッジアプリの構成概要とSafieクラウド/カメラとの動作概要の全体像については、下図になります。 基本アプリのライフサイクルコールバックI/Fを実装し、上記機能・ライブラリーを使ってアプリの機能を実装すればアプリが出来上がるイメージです。 現状SafieEdgeAppFrameworkは社内のみの利用で、まだまだブラッシュアップ中です。完成度が上がり対応するカメラなどの条件が揃い次第、テックパートナーに公開していきたいと考えています。 ちなみに、SafieエッジアプリはWebRTC経由や Safie API 経由でも通信できる構想（妄想？）があります。例えば、顔検出のSafieエッジアプリを作って、Web側で下記のようなjavascriptコードで顔の検出通知をsubscribeしたり、検出したい顔の特徴をSafieエッジアプリに設定したりすることもできるかもしれません。 そうなると、Safie開発アカウントを持っていれば、Safieカメラと連携するフルスタック開発ができるので、面白いかもしれません。 // この顔見つけたら教えてね camera. edgeapp ( "FaceDetector" ) . subscribe (“FaceDetectedEvent”, (event) => { console. log ( "people in:" , event.face_name) }) camera. edgeapp ( "FaceDetector" ) . request (“StartFaceDetected”, face_data) 最後に ここまでで、多少理想語りも含めたセーフィーの組み込みエンジニアの業務・開発内容を紹介をしてみましたが、イメージは少し湧きましたでしょうか。 組み込みエンジニアの全ての努力は、Safieのカメラ・デバイスや開発環境を、より安全・安定でより手軽にインフラのように、顧客や共に開発するパートナーの身近に届けるためです。 そして、理想を語りながら、顧客ニーズや現実を見て調整し、確実に泥臭い現実課題を解決していくのがセーフィーの組み込みエンジニアの姿になると思います。 現在、一緒に働く組み込みエンジニアを募集しています。セーフィーのビジョンや組み込み、エンジニアの開発内容に共感・興味を持って頂けるようであれば、是非ともご連絡ください！ 募集職種一覧/セーフィー株式会社

初めまして。セーフィーの伊原と申します。 今年で社会人3年目で、セーフィーには2021年11月に入社いたしました。 現在はビジネスユニット1にてフロントエンド開発を主に担当しています。 ビジネスユニット1は主に飲食・小売業のDX実現を目的とした部署で、多店舗経営者向けのクラウドカメラ管理アプリケーションや、店舗内の人を検知するAIを搭載したクラウドカメラの開発を行っています。 今回は私が所属しているフロントエンドチームにて実施しているスクラム開発についてご紹介いたします。 私にとってスクラム開発はセーフィーが初めての経験で、当初は慣れない事も多かったですがとても良い取り組みだと感じています。 本記事では初めにスクラムの簡単な説明をした後、開発現場で実践している開発フローについてご紹介いたします。その後、私が考えるスクラムの良さについて所感を述べます。 スクラム開発の概要 Safieのフロントエンドの開発フロー スクラム開発のメリット 最後に スクラム開発の概要 まず初めに、スクラム開発を知らない方に向けて簡単にスクラム開発の説明をいたします。 スクラム開発とは、スクラムと呼ばれるフレームワークを活用したソフトウェア開発のことです。チーム毎にスプリントと呼ばれる一定の期間を指定し、次の図の流れを繰り返すことでプロダクトのゴールを目指していきます。 ①バックログリファインメント プロダクトに必要なものを洗い出し、プロダクトバックログと呼ぶ一覧にします。新規機能の追加、機能改修など様々なものをまとめるため、抽象的な内容も含みます。 これはスプリント初めに行うのみでなく、適宜開催することもあります。 ②スプリントプランニング プロダクトバックログの内容をタスクレベルまで落とし込み、1スプリントの間に実施するタスク一覧に抽出します。ここで抽出されたものをスプリントバックログと呼びます。 選定の際には、チーム全員でタスクの作業量を見積もり、スプリント内で終わる現実的な量を抽出します。 ③スプリント期間 各メンバーにタスクを割り振り、開発を進めます。 タスクは最初に全て割り振ってしまうのではなく、メンバーが自主的にスプリントバックログから取得します。タスクが完了次第、新しいタスクを取っていく形です。 期間内はタスクの遂行を円滑にするためにデイリースクラムと呼ばれる集まりを毎日実施します。 スプリントの終了まで③を繰り返します。 ④スプリントレビュー 開発期間の終了時に、以下の2点を評価します。 期間内で完了したタスク量の算出：チームの生産性の計算 良かった点・改善点の洗い出し 評価の内容を踏まえ、再び②に戻ってサイクルを回します。 一連のスプリントを繰り返すことで徐々にプロダクトと開発フローを発展・洗練させていくのがスクラム開発です。 Safieのフロントエンドの開発フロー 私のチームにて実際に取り組んでいる開発フローを前述した図の①〜④に当てはめてご紹介します。 チームでは1スプリントを2週間として設定しています。 ①バックログリファインメント スプリントの初めに1度実施しており、本イベント後の同日に②のスプリントプランニングも実施しています。 ここでは開発チームメンバーで集まり、プロダクトに必要な機能を一覧化します。 タスクの進捗管理にはWrikeというツールを使っており、タスクを次の段階に分け、ボードで管理しています。 Backlog: プロダクトバックログ ToDo: スプリントバックログ Doing: 遂行中 Dev Review: レビュー中 QA Review: QAチーム確認中 Done: 完了したタスク Closed: スプリント中に完了したタスクの一覧 それぞれのリストにあるタスクは移動させられるようになっており、各自が自分の持っているタスクを段階に応じて移動させます。Doneまで移動させたらタスクは完了となります。 DoneからClosedへの移動は後述するデイリースクラムにて実施します。 ②スプリントプランニング 前回のスプリントにて完了したタスク量を目安に、スプリントバックログを作成します。 必要があれば、機能をタスクの粒度まで落とし込みます。例えばユーザ登録機能が必要な場合、「ユーザ登録」という機能単位ではなく、「画面開発」・「API連携」という単位に分割するような形です。 ここでは機能の優先度のみでなく、企画やサーバサイドの進捗状況に合わせて柔軟にタスクを選定するようにしています。 スプリントバックログの作成後、積んだタスクの見積もりをチーム全員で行います。見積もりはストーリーポイントで数値付けをしています。 ストーリーポイントとは相対見積の指標で、「このタスクだったらどれぐらいかかりそうか」の規模感をこれまでのタスクから考慮して設定します。ここで重要なのは、何人日・人月といった絶対値で見積もりをしないことです。 ストーリーポイントの決定にはプランニングポーカーという方法を採用しており、これは各メンバーの見積もった数値を一斉に開示するやり方です。 見積もりの数値はフィボナッチ数列から選択します。開示した際にメンバー間で見積もりが一致しなかった際には、互いに想定した理由を伝え合って議論します。ここで重要なのは、見積もり内容にメンバー全員が納得する事です。 見積もった結果として想定のタスク量との差が大きかった場合には、プロダクトバックログを再度見直してタスク量を調整します。 ③スプリント期間 スプリント期間内は毎朝15分程度のデイリースクラムを実施し、以下の3点をチームで共有しています。 前日にやったこと 本日やること 困っていること 報告の際にはWrikeのボードを画面共有し、各自が持っているタスクの総量を全員が把握できるように進めます。「本日やること」の報告の際に新しいタスクをスプリントバックログから取っていくのですが、この際にもタスク内容を宣言しておく事で、今後どういったタスクに取り組む予定かをチーム全員が知っているようにします。 また、WrikeにてDoneとなっているタスクを確認し、本当に完了で問題ないかをチームメンバー全員で確認するようにしています。これによって、本人が気付かないタスク漏れ等を防止しています。 ④スプリントレビュー スプリント中に完了したチケットを整理し、チームのベロシティを算出します。 また、以下4点に関してスプリント区間内の振り返りを行い、次のスプリントの改善を目指します。 Good: 良かった点 Problem: 課題点 Try: 改善策 Keep: 次回以降も続ける試み スクラム開発のメリット ここで、私がスクラム開発を実際に体験して良かったことを3つに分けて説明いたします。 1. 属人化の軽減 1つ目は、属人化（ノウハウが共有されない状態）を防ぐことができる点です。 スクラムではチームメンバー間でやっていることが共有されるため、各メンバーのタスクの全容が透明化されます。Aさんでないと/Bさんでないと分からない、というような事がなくなると共に、メンバー間での質問やアドバイス等が行いやすい環境が促進されます。 スクラム開発における最大のメリットはこの点であると私は考えています。 設計方針や実装方針の良し悪しを開発者間で積極的に話し合う事ができ、技術者として成長できる環境が整っていると感じました。 2. メンバーの負荷状況の可視化 「属人化の軽減」の項で透明化について述べましたが、透明化によってチーム内の負荷がかかっているポイントが明確になること、それが2つ目の良い点です。 デイリースクラムで困りごとを共有する機会を作ることで、課題に個人ではなくチームとして取り組む流れを自然に作り出す事ができます。また、手が空いている人が他の人のタスクを巻き取るなどの融通も効きやすいです。 3. 見積もり能力の向上 全てのタスクに見積もりが行われるため、実際に業務を遂行する中で予想より短い・多かったという事が必ず発生します。そこで「なぜ想定と異なったのか？」を考えて共有することで、チーム全体でタスクに対する見積もりの感覚が向上していきます。 ストーリーポイントを付ける際に他の方の意見を聞く機会も多く、見識が広まりやすいのも利点です。 また、チームがどの程度のタスク量をこなすことができるかも明確になるため、開発スケジュールに無理が無いかを早めに判断することができます。 最後に セーフィーでスクラム開発を経験してみて、開発を健全に進める上でチームに必要な要素を自然に促してくれるような、良い開発体制であると感じています。 各メンバーの自主性は求められますが、自主的に動く事の重要性はかなり大きいので、それも含めて成長する必要があると思っています。 セーフィーは厳格な上下関係が無い事もスクラム開発との相性がよく、開発として社内のコミュニケーションを取りやすく、開発していてとても楽しいです。 本記事で少しでもセーフィーの開発フローの良さがお伝えできていれば幸いです。 読んで頂きありがとうございました🙇‍♂️ 本記事の執筆に当たり、次のスクラムの解説記事を参考にさせていただきました。 詳細を理解する上で非常に勉強になる内容でした。 qiita.com

こんにちは！ セーフィー株式会社 業務システム部でエンジニアをしている大林と申します。 業務システム部とは、その名の通り 業務系システムの開発・運用 を行なっている部署です。 以前の 職種別エンジニア紹介の記事 における「業務システムエンジニア」が所属しています。 ということで今回は、セーフィーのサービスそのものについてのお話ではなく、セーフィーのサービスを支える業務システムのお話です。 業務システムの全体像 業務フローに沿って紹介 1. 商談作成 2. 出荷 3. 売上作成 4. 請求書発行 DataSpider Cloud これから 業務システムの全体像 セーフィーはSaaSビジネスですが、 単純なサブスクリプション契約だけではなく、カメラや付属品などの「モノ」も取り扱う ことが業務システムにおける特徴です。 今回の記事では、セーフィーのカメラ・サービスをお客様に使っていただくまで・使っていただいている間、どのように業務システムが関わっているかの全体像についてご紹介します。 簡単にまとめた全体像が以下の図です。 セーフィーでは、2019年に、クラウド型のSFA(営業管理)・CRM(顧客管理)のプラットフォームであるSalesforceを導入して以降、現在は Salesforceを中心として各種システムと連携 しています。 数字は以下で説明する業務フローの流れと対応しています 業務フローに沿って紹介 ここからは実際にセーフィー社内のオペレーションがどのような流れで行われているかを、業務フローに沿ってご紹介します。 実際はマーケティング活動にもSalesforce等のシステムが使われているのですが、そちらはマーケティング部が主に管轄しているので今回の記事では割愛します。 以下が業務フローの大きな流れです。ここではカメラの販売商流の例でご紹介します。 Salesforceの商談を作成し注文情報を入力する 商談情報を元にカメラを出荷・キッティングする 出荷(もしくは工事)完了後に売上データを作成する 売上データを元に請求書を発行する 1つずつもう少し詳細に見ていきましょう。 1. 商談作成 お客様がセーフィーのカメラを購入するには、 ECサイト からの直接購入や、お問い合わせフォームからご連絡いただくなどしてセーフィーの営業担当者とやりとりの上でご購入いただくなど複数の経路がありますが、 注文情報はすべてSalesforceの商談で管理 されています。 ECサイトから購入する場合は、見積情報や受注情報がSalesforceの商談に自動連携されるようになっており、その連携部分はEAIツールであるDataSpider Cloud(詳しくは後述)を用いています。 営業担当者を通して購入する場合は、まず営業担当者がSalesforceで商談を作成します。そこから必要に応じて見積書を作成し、受注の運びとなった際には申込フォームを発行します。そしてお客様が申込フォームに入力し提出いただいた内容が、商談に自動で反映されるようになっています。 この段階で、 カメラの機種と録画プランの組み合わせや、カメラにひもづくオーナーアカウント、納品希望日・送付先などが管理 されます。 カメラとプランやオプションの組み合わせを登録する画面 2. 出荷 作成した商談情報を元に、出荷に必要な情報を作成します。 Salesforceのレポート機能を用いて、納品希望日やカメラの機種・台数・送付先などを倉庫での出荷担当者と連携しています。 出荷した後には、倉庫の出荷担当者が、出荷したカメラのシリアルナンバーをSalesforceに連携し、 どのカメラにどのプランやオプションが紐づいているか(キッティング情報)を管理 します。 カメラのキッティング情報の一例 この段階で、 Salesforceに格納されたキッティング情報をセーフィーのPlatformサーバーにもAPI連携 します。ここでいうPlatformサーバーとは、セーフィーのサービスやユーザー情報を管理しているサーバーです。 この連携を行うことで、お客様の元にカメラが届いた時点でスムーズに利用開始できるようにしています。 また、当日出荷した商談について、出荷のお知らせメールをお客様へ自動配信したりもしています。 Salesforce画面のボタンからキッティング情報を連携します (AgencyTool=Platformサーバーを利用した社内アプリケーションです) 3. 売上作成 出荷(工事を伴う商談の場合は工事)が完了すると、商談をクローズします。 この段階で、出荷や工事完了日に合わせた課金日が確定し、商談に設定された期間分の売上データが作成されます。 ここで作成された売上データを元に、経理などの経営管理部門が会社としての売上管理をしています。 ちなみに、現在ECサイトから購入した場合はクレジットカード決済が可能です。クレジットカードの決済情報は、月末時点の決済データを元にDataSpider Cloudを介してSalesforceに売上データを作成しています。 4. 請求書発行 毎月やお客様に合わせた請求書発行のタイミングで、売上データを元に請求データを作成します。 ここで作成された請求データを、セーフィーで利用している 請求管理ロボ というシステムに連携 し、請求書発行をします。 その後は請求管理ロボ上で入金消込をしたり、最終的に会計システムへ連携して会計処理をしたりします。 請求管理ロボ for Salesforceを利用しており、Salesforceで対象データを取得して連携します ここまでがカメラの販売商流のざっくりとした一連の流れの紹介でした。 今回紹介した内容以外にも、レンタル商流では、2020年に 従来のスプレッドシート管理からSalesforceでのシステム管理に移行 し、カメラの在庫管理なども行っています。 システム化以前は、いくつものファイルやシートに分かれ数式が絡み合っていたため、スプレッドシートがとてつもなく重くなっていたり、作業が属人化したりしていました。システム化によってオペレーションフローが整い、急速に成長するレンタル商流の管理にも対応できるようになりました。 DataSpider Cloud 大筋とは外れますが、せっかくの機会なので、1や3で出てきたDataSpider Cloudについて、もう少しだけご紹介します。 DataSpider Cloudは、種類の異なるシステムやアプリケーション間でデータのやり取りを行う際に、通常はプログラム開発、もしくは手作業でデータの移行や入力作業を行う処理を、GUIベースで作成することができるデータ連携サービスです。 (参考： ヘルプページ ) セーフィーでは、ECサイトからの連携以外にも複数箇所で利用しています。 例えば、 Webサイトのお問い合わせフォームからSalesforceへ連携しデータ作成 Excel形式の申込書を取り込んで商談を作成 AWSのS3に格納されているクレジットカード決済による入金データ(CSVファイル)を月次で取得して加工処理 などなどです。 GUIでの操作となるので、上記のような処理をノーコードで実現することができます。 このようなシステム連携を実現することによって、今までExcelファイルなどからシステムへ一つ一つ転記していた作業がなくなったり、Excel等での属人化した加工処理がなくなったりするなど、 オペレーションを効率化して手作業によるミスもなくす ことができるようになりました。 DataSpider 画面サンプル これから ここまででSalesforceを中心とした現在の業務フローをご紹介しましたが、現在の運用にも「不」があります。 キャンペーン施策などのたびにプログラム修正が必要となりSE対応 契約変更や契約更新が手作業 便宜上未来の売上データも作成しているため扱うデータが必要以上に多くなる などです。 今年は業務システム部総動員で、契約・請求管理システムの導入に取り組んでいます。 現在はSalesforceが中心となり業務システムの全体を担っていますが、今後はSalesforceはSFA(営業管理)の機能に寄った形にし、契約管理や売上・請求管理は新システムに移行したいと考えています。 柔軟なプライシング戦略や請求の自動化など、上記で挙げた不の解消に向けてプロジェクトが進行中です。 セーフィーのビジネスが拡大するにつれ、管理するデータ(顧客・カメラ・請求など)は膨大になっていきます。 社員が効率よくオペレーションができ、そしてお客様の満足度向上につながるように、 セーフィーの業務システムはこれからも進化していきます！

はじめに MDMとは 新３大 MDMを使ったiOSアプリの配布術 1. AppleID無しでアプリを配布できるMDM　【Safie事例】 2. 端末毎に異なる設定をしてアプリを配布できるMDM　【仮説】 3. iOSのバージョン更新を抑制できるMDM　【Safie事例】 最後に はじめに こんにちは。2021年5月に入社し、モバイルグループでiOSアプリ開発を担当している太田です。 好きなiOS SDKはExtensionsです👍 今回は、2021.9.17-19に開催されたiOSDCセッションの中から興味深かったテーマを当社サービスの事例を交えて簡単にご紹介します。 イベント開催から半年以上経ち今さらなによと思われた方もいると思います。 しかし、知っていましたか？iOSDCのセッション動画は1ヶ月経つと Youtubeに無料で公開 されるのです！ イベントに参加した人もしていない人もこの機会にぜひぜひ本ブログと一緒に見て頂ければと思います。 ということで取り上げるテーマはこちらです！MDM！ 参考にしたiOSDCのセッションは 「MDMを使って業務用アプリの初期設定を自動化する」 です。 取り上げた理由は、 以前の記事 「画像認識技術、サービスの自社利用」 で紹介した当社 SafieEntranceサービス を利用して頂いているお客様の環境でも導入していること 「MDM テックブログ」でググったところ、記事が少なかったこと なにより、開発者として SafieViewerアプリ や SafieEntranceアプリ をただ単に作るだけでなく 導入・運用するときの課題や苦労といった 現場の不 も認識しておきたかったこと です。 MDMとは ちなみに、MDMとは Mobile Device Management の略で、多数のモバイル端末を管理する仕組み、あるいはクラウドサービスのことを言います。iOSの場合はAppleが定めた MDM Protocol に従い、アプリの配布・端末OSの設定・遠隔操作などが実現できるものになっています。MDMが活躍する対象領域は図１のアプリを「導入する」「つかう」となっています。 図１. MDMの対象領域 余談ですが、MDMを使うにあたりAPNs（Apple Push Notification service）・ABM（Apple Business Manager）というサービスも重要になってきます。今回は、 現場の不 と それを解決できるMDM という内容をお伝えしたいと思うのでMDM-APNs-ABM連携の仕組みに関する説明は割愛致します。 それでは、SafieEntranceの事例も交えながらMDMで実現できる３つのことを紹介します！ 新３大 MDMを使ったiOSアプリの配布術 1. AppleID無しでアプリを配布できるMDM　【Safie事例】 まず初めに開発者のみなさまにお伝えしたいことはAppleIDがないとiPad端末にアプリをインストールできないということ。 当たり前だよ！というツッコミ、ありがとうございます。 しかし待ってください！アプリをインストールするために、AppleIDを200台の端末に設定することを考えてみると、 AppleIDの登録作業が面倒 200台毎にAppleIDを作ると管理するのが面倒 AppleIDを使い回すにも端末上限は１０台、しかもアカウントを共有するとある端末で出たアラート等が共有した他の端末でも表示されてしまうのが面倒 といった面倒に出くわすのであります。 そこで登場するのがMDM。 MDMを使えばAppleIDなしでも指定したiPadに一括でアプリを配布することができるのです。 正確にはAppleのVPP（Volume Purchase Program）とMDMの合わせ技。 VPP StoreからApp Storeに公開されているアプリを一括購入してMDMを使って配信するという流れになります。 2. 端末毎に異なる設定をしてアプリを配布できるMDM　【仮説】 続きまして、SafieEntranceの事例ではないのですが、iOSDCセッションを聞いて実現できそうだなと思った妄想事例を紹介したいと思います。 それはアプリの初回ログイン作業の手間を省くこと。 SafieEntranceアプリの場合、ログインした後は基本的にログアウトすることなくログイン後の顔認証画面を常時開いた状態にしてiPadを常設しておくという特徴があります。 つまり、基本的にログインする処理は導入時の１回のみ。 驚くことにiOSDCでは Managed App Configuration という機能を使いMDM上で { key : value } を設定するだけでその情報をアプリに設定した状態で端末毎にアプリを配布できるという事例が紹介されていました。 { key : value } の取得方法はiOS SDKの UserDefaults を使って取得できるとのこと。 もしかして、下記のように実装すればログイン作業も省けるのでは？と筆者は考えたのであります。 図２. Managed App Configurationを使った自動ログイン実装例 これにより、例えばiPadの設置工事の際にアプリを起動してもらえればログイン情報の入力が省けるという算段です。 3. iOSのバージョン更新を抑制できるMDM　【Safie事例】 無事に導入できたのも束の間、不穏な空気を感じている開発者もいると思います。 そう、iOSのバージョン更新であります。 iOS Developerであればこのバージョン更新に血と汗と涙を大量に流した方も多いことでしょう。 しかし、MDMはOSのバージョン更新をも抑制してアプリを配布することができる強者でもあったのです！ iOSではアクセスポイントへのSSIDやパスワードなどの端末に必要な情報をXML形式で記述した 構成プロファイル というものを使って設定できるようになっています。 この構成プロファイルにOSのバージョンが自動で更新されないような記述をし、MDMからiPadに設定を流し込むということになります！ 余談ですが、Siriを無効化させるということも構成プロファイルで設定できそうです... 図３. Apple Configurator 2 を使った構成プロファイルの設定 以上、新３大 MDMを使ったiOSアプリの配布術 の紹介でした。 正直に申しますと入社した時点では私自身がMDMのことを知りませんでした。今回、MDMの配布術を整理することで 現場の不 を考えながらモノづくりをすることが重要だということを改めて考えさせられた次第です。 アプリを導入する際の困りごとに関しては現場でその作業を聞いたり実際にやってみないと分からないことも多いと思います。紹介した事例は聞けば当たり前のことかもしれませんが意識しないと気づかないこととも思えます。 上記で紹介させて頂いた現場の事例以外でも、 常設して24時間動かしているiPadを定期的に拭き掃除してくれる業者さんがアプリを閉じないようにするためにアクセスガイド設定が必要。アクセスガイドを設定してアプリを起動させている場合、 SFSafariViewController を使ってWebブラウザを開くことはできるのか？ということも開発者は検討しなければいけないということもありました 😥 ソフトウェアエンジニアでも 現地・現物・現認という教えは大事だな と感じたところです。 最後に さて、ここまで読んで頂いてMDMを使ってみたいと思われた開発者のみなさまに残念なお知らせがあります。 それは、個人で利用できるMDMベンダーさんが調べた限り無いということ！（基本は法人契約） 安心してください。 それでもMDMを使った開発の一端に触れてみたいというエンジニアの方のために 入口 を用意してあります。詳しくは 👇 を覗いてみてください。 open.talentio.com これを機にあなたのDevelopmentの世界をExtensionしてみてはいかがでしょうか。 読んで頂きありがとうございました🙇‍♂️

初めまして。セーフィーの柏木です。 AI/画像処理エンジニアで、テックブログ運営チームにも所属しています。 今回は、セーフィーにおけるメイン事業であるクラウド録画サービスと各職種のエンジニアの業務について紹介します。 クラウド録画サービスシステムの全体像と、それぞれのエンジニアが一体何をやっているのか、わかりやすくお伝えできればと思います。 セーフィーのクラウド録画サービスシステム クラウド録画サービスの流れと、担当エンジニアの紹介 組み込みソフトウェアエンジニア サーバーサイドエンジニア/インフラ・SREエンジニア AI/画像処理 エンジニア フロントエンドエンジニア iOS/Androidエンジニア 業務システムエンジニア QAエンジニア データエンジニア 最後に セーフィーのクラウド録画サービスシステム セーフィーのクラウド録画サービスは、カメラで撮影した映像データがクラウドにアップロードされ、必要に応じてクライアントアプリケーション（フロントエンド、モバイル）に配信されており、幅広い領域の技術が組み合わさって構成されています。こういった領域に馴染みがないとなかなか複雑に感じるサービスかもしれません。 そこで今回はそのサービスの流れにそって、各領域のエンジニア業務を紹介していきます。 こちらがサービスの全体像に職種別のエンジニアを当てはめた図になります。 一つのサービスに対して非常に幅広い分野のエンジニアが関わっていることがわかりますね。それでは一つずつ紹介していきます。 クラウド録画サービスの流れと、担当エンジニアの紹介 組み込みソフトウェアエンジニア セーフィーではクラウドカメラを扱っています。 カメラがないとまず映像が撮れません。セーフィーで扱っているカメラの数は非常に多く、またメーカーも様々です。 これら幅広いカメラ機種に対応し、使いこなすためのファームウェア開発を行っているのが、「組み込みソフトウェアエンジニア」です。 使いこなすための機能として一例を挙げると、決められた時間にスナップショットの撮影を行いサーバーに保存を行うスナップショットスケジュール機能や、サーバーとの通信接続が切れたときに録画欠損を防ぐための本体録画バックアップ機能があります。また、撮影した映像をサーバーに送信する機能も画一化し実装しています。 新しいカメラを販売する際は真っ先に対応し最前線に立って実装するエンジニアです。 使用言語はC++。ライブラリではBoostも使用しています。 サーバーサイドエンジニア/インフラ・SREエンジニア カメラで撮影された映像はサーバーに送られ、録画されます。 ここでサーバーで行われる処理を実装するのが、「サーバーサイドエンジニア」です。 サーバーで録画される期間はプランによって異なるので、サーバーサイドエンジニアはプランに応じた録画データの保存処理を行っています。その後PC等フロント側に映像を送るための前処理も行っています。 また、 セーフィーで使用されるAPI全般の開発も行っており、フロントからの制御の大部分はサーバーを経由するため、サーバー側のAPIの開発が必須となります。 映像視聴アプリケーション向けの機能を実現するためのAPIのほか、各種管理アプリケーション向けのAPIの開発も行っています。合わせて保守・運用・改善も継続的に実施しています。 使用言語は主にPython。一部Go、Javaも使っています。 サーバーサイドエンジニアが利用している膨大な数のサーバーを構築・管理・運用するのが、「インフラ・SREエンジニア」です。 インフラ・SREエンジニアの役割は主に4つあります。 　１．新しいシステムに対するインフラの設計 　２．コードによるインフラ管理 　３．システム・サーバーのアプリケーションに対する監視 　４．デプロイの改善 セーフィーではインフラの規模が非常に大きく、1000台を超えるサーバーを扱っています。 今後も新しいプロダクト・アプリケーションが増えてくるため、これらの管理・改善は必須の作業です。 使用ツールはTerraform、Ansible。監視にはPrometheus, Grafana, Amazon CloudWatch, StatusCakeなどを使います。デプロイではGitHub Actionsを使うこともあります。 AI/画像処理 エンジニア 撮影された映像はAI機能を用いて解析することができます。 例えば映像内の人数を数えるオプションサービス「Safie AI People Count」がそれにあたります。解析はカメラのエッジデバイス内で行うこともあれば、サーバー内で行うこともあります。 それぞれのタスクに対して効率的な処理のパイプラインを作成し、 最適なアルゴリズムの調査・実装・改善を行うのが「AI/画像処理エンジニア」です。 アルゴリズムでは、Deep Learningを使用することもあれば、ルールベースの画像処理を扱うこともあります。 Deep Learningを使用する際は、データの収集やアノテーションなども担当します。 使用言語はPythonまたはC++。ライブラリはOpenCVやPytorchを使うことが多いです。 フロントエンドエンジニア 撮影された映像はWebブラウザで見ることができます。この 映像視聴アプリケーションの開発は「フロントエンドエンジニア」の担当です。 映像はカメラの状態によって、Live配信が切れたり、録画映像が存在しない可能性があり、快適な視聴のために複雑なエラーハンドリングを行っています。 従来の非クラウド型VMS（Video Management System）で一般的なマルチビューアー（複数台のカメラ映像同時視聴）や、高解像度・大型モニターでの視聴に対応しており、多くのカメラを扱えます。大量な情報を処理しつつ、ユーザーの使い勝手を向上する工夫を随所に凝らしています。 このアプリケーションの他に、企業・販売代理店向け管理アプリケーションの開発もしています。 使用言語はTypeScriptで、利用しているフレームワークはAngular、Vue.jsです。 iOS/Androidエンジニア 映像データはモバイル端末（スマートフォン、タブレット）からも見ることができます。 このモバイルアプリの開発を担当しているのが、「iOS/Androidエンジニア」です。 モバイル端末向けアプリにおけるUIの構築や画面の遷移、動画ストリーミングの制御、SafieのサーバーAPIとの通信や、カメラとのBluetooth通信制御などを行っています。 近年はモバイル端末用アプリを使用するユーザーが増え、一日に数万人が利用しており、Webアプリの利用ユーザーを超える人数となっています。 アプリのデザインについては、基本的にデザイン担当の部署から仕様を受け取りますが、UI/UXの改善案をエンジニア側から提案することもあります。 開発言語はiOSがSwift、AndroidはKotlinを使用しています。 業務システムエンジニア 顧客管理や受注〜出荷〜請求という一連のオペレーションに用いる社内システムを開発・運用しているのが、「業務システムエンジニア」です。 現在セーフィーではSalesforceをメインのシステムに据え、他システムと連携しています。 ECサイトからの注文情報をSalesforceに連携したり、お客様に出荷するカメラと録画プランを紐付けた上でセーフィーの基幹システムと連携したり、売上の情報を請求管理システムに連携したりなど、サービスをより円滑にお客様のもとへ届けるための仕組みづくりをしています。 クラウドカメラサービスの開発とは直接関わりませんが、今後のセーフィーの成長を下支えするために必須のエンジニアとなっています。 QAエンジニア ここまでご紹介したとおり、セーフィーの製品はフロントからデバイス、サーバーなど非常に幅広い分野にまたがっております。 これらの製品を出すためには、品質の保証を行うエンジニアが必要です。セーフィーでは QCDMT（Quality（品質）、Cost（費用）Delivery（納期）Managment Team)チームを作り、QAエンジニアが役割を担っています。 QAエンジニアは、開発した製品全般に対してテストを行っており、開発とのテスト内容のすり合わせ、テストスケジュールの調整など、品質のチェックにあたって様々な対応を行っています。 セーフィーのQAはデバイス・フロントアプリ・サーバーAPI・サービス(商品) など、広範囲にわたって仕様を理解する必要があるため非常に難しいQAとなります。しかし開発メンバーと距離が近いので、テスト時実施方法の相談や、実施結果についての不明点などを迅速に話し合える環境があります。 また、現在は効率のよいテストの実行に向けて、一部テストケースの自動化進めるなどの仕組みの効率化を進めるなどの取り組みも行っています。 個人の裁量で必要に応じてJavaScriptやSQLを利用するなど、幅広いスキルを活かした働き方も可能です。 データエンジニア セーフィーのサービスレベルを向上させて行くためには、感覚だけに頼るのではなく各種リアルな情報に基づいた分析が必要です。 必要な各種データを分析し様々な活動に活かすためのシステム基盤を開発しているのが「データエンジニア」になります。 例えばユーザーの契約、解約状況やサービスの利用動向などの集計、分析を行っています。 現在はAmazon RedShiftを利用しており、アナリストと連携しこれらの業務にあたっています。使用言語はPython、SQLです。 最後に 今回は、セーフィーのクラウド録画サービスのシステムの全体像と、各領域のエンジニアの役割について紹介しました。 今後、本ブログでも自分の領域とは馴染みのないエンジニアの記事が出てくることがあるかと思いますが、この記事をふり返ることで「あ～こんな仕事をしているんだな～」と思いながら読んでいただければ嬉しいです。 採用も積極的に行っておりますので、セーフィーに興味を持っていただいた方はぜひご応募ください。 article.safie.link

こんにちは。 セーフィー株式会社 バックエンドエンジニアの河津です。 先日ご縁あって、Node-REDをテーマにしたミートアップで簡単なLT(ライトニングトーク)をさせていただく機会がありました。 Node-REDというのはフローベースのビジュアルプログラミングツールでして、ノーコード/ローコードなアプリケーションの開発を行うことができるツールです。(詳しくは後述します。) どのような登壇内容にするか迷っていたのですが、当社で提供しているサービス「Safie API」とNode-REDが、ノーコード/ローコード開発の観点から相性いいのではなかろうかと思い立ち、これらを連携して会議室の空き状況を確認するシステムのプロトタイプを作りました。 今回はその内容に触れつつ、Safie APIとNode-REDの連携活用例について紹介させていただきます。 今回作るもの Safie APIとは？ Node-REDとは？ Safie APIの使用準備 Node-REDでのシステム構築 1.Slack in ノード 2.Switch ノード 3.functionノード 4.http requestノード 5.functionノード 6.Slack outノード やってみた感想 ちなみに、こちらの記事は enebular Advent Calendar 2021 に、24日目の記事として参加させていただいています。 また、こちらの内容は上述のミートアップコミュニティにてアーカイブされています。詳細な部分など口頭での説明もありますので、良ければ合わせてご覧ください。 www.youtube.com 今回作るもの Slackで「会議室の空き状況を教えて」などのようにコメントすると、現在の混雑状況を教えてくれるBotを作成したいと思います。 上記のコメントをSlackのWebhookで受け取った際に、Safie APIにて現在会議室にどれだけ人がいるかの情報を取得し、その情報をベースに「現在〇〇人が会議室を使っています」といった情報をSlack Botが答えてくれる、というようなシステムを作ってみることを目指します。 SlackのWebhook先を設定するには、本来何かしらAPIを実装してそれを設定する必要があるのと、APIを動作させるためのサーバも構築しなければなりませんが、この中継地点となるサーバおよびエンドポイントの役割を、今回はNode-REDに担ってもらいます。 下記のようなシーケンスで作成していきます。 Safie APIとは？ Safie APIは、セーフィーのカメラから得られる情報を取得・更新することができるAPIです。 セーフィーではSafieViewerという、カメラに映った映像などの情報を見ることができるアプリケーションを提供しているのですが、アプリケーションとしてだけではなく、ユーザーが普段使っている業務システムにも組み込めるように、SafieViewerで提供している各機能をAPIとして提供しています。 developers.safie.link 例えば、ストリーミング映像データを取得することができたり、静止画の取得、動画のダウンロードなどを行うことができます。 テックブログ内に、「Safie APIの始め方と動作方法の紹介」というSafie APIについて解説された記事がありますので、こちらも合わせて読んでいただければと思います！ engineers.safie.link Node-REDとは？ Node-REDは元々IBMにて開発されたIoT向けのフローベースドプログラミングツールです。 現在はOSSとして寄贈されているため、インストールすれば誰でも使うことができます。 インストールの手順などは公式のこちらのページなどが参考になります。 nodered.org ちなみに今回僕はenebularというサービスを使い、クラウド上のNode-RED環境を使いました。 www.enebular.com Node-REDは、「ノード」という機能単位の箱(例えば、Webhookを受け取る、外部APIと通信する、Slackにメッセージを送る、など)を、「フロー」という線で組み合わせることで、いわゆるビジュアルプログラミングのような形でシステムを組むことができます。 また、細かな処理を追加したい場合はその部分だけコードを書くことができるので、ノーコード・ローコードで作りたい機能を実現することができます。 Node-REDはIoTアプリケーション開発に使われるケースが多いですが、サーバサイドの処理を任せる使い方もできます。 このNode-REDを利用して、会議室の空き状況を教えてくれるBotの作成をしていきます。 Safie APIの使用準備 前述した「 Safie APIの始め方と動作方法の紹介 」の記事内にて、Safie APIを使用するための手順が記載されていますので、良ければこちらをご覧ください。 ※2021/12/17現在、Safie APIは一部のユーザーにのみ利用を開放しており、申し込みいただいても全員が使用できるわけでないためご注意ください。 記事内の手順からアクセストークンを取得して、準備完了です。 Node-REDでのシステム構築 繰り返しですが、今回は「Slackで会議室の空き状況を聞くと、空き状況を答えてくれる」機能を作成します。そのために、Saife APIの「人物検出結果一覧API」を使用します。 今回使用するカメラにはこのような会議室が映っています。 「人物検出結果一覧API」は、このカメラに映った映像から人物を検出し、「一定期間の間に映った人の数」をカウントすることができます。 この「人物検出結果一覧API」を使用することで、直近1分間に会議室を使っていた人の数(のべ人数)を出しつつ、それをSlackで返答するようにします。 Node-REDのフローを、こんな風に組んでみました。 処理の流れとして、 Slackへのメッセージ送信検知(Slack inノード) 特定のワードのみ反応するようにする(「振り分け」という名前のSwitchノード) Safie APIにリクエストするためのパラメータ作成(「Safie人物検知API送信準備」という名前のfunctionノード) Safie APIへのリクエスト(「Safie人物検知API疎通」という名前のhttp requestノード) レスポンス内容を整形して現在会議室にいる人を算出(「返信文」という名前のfunctionノード) Slackにメッセージを送る(Slack outノード) という流れになります。 一つ一つ、どのような処理になっているかを解説します。 1.Slack in ノード Slackにメッセージが送られたことをhookしてくれる機能です。 Slack Bot作成の際に作られるAPI Tokenと、投稿されたら発火するチャンネル名を設定することができます。 2.Switch ノード 「会議室の利用状況を教えて」などの、特殊なメッセージにのみ反応してほしいため、このSwitchノードで処理の分岐を行っています。 メッセージの内容が「会議室の利用状況を教えて」だった場合に、次のノード処理に移ります。 3.functionノード Safie APIで人物検出結果を取得するためのリクエストパラメータを作成します。 functionノードではNode.jsでコードを書くことができ、今回は、会議室を映すカメラ固有のID「device_id」を設定しつつ、直近1分間に映った人の数をカウントするようにパラメータを作成します。 4.http requestノード Safie APIへのリクエストを行います。 このノードにAPIのエンドポイントやアクセストークンを設定して、認証を通るようにします。 5.functionノード Safie APIからのレスポンスをこのノードで整形します。 データには1分間に映った人数データが入っているので、それを集計しのべ人数としています。 当然この中には同じ人がカウントされているデータもまとめて集計しているのですが、今回はプロトタイプということで許容しています。 またこの処理の中で、次のノードであるSlackに送るメッセージを組み立てます。 6.Slack outノード Slackにメッセージを送るノードです。 こちらにもSlack inノードと同様、BotのAPI Tokenと、通知するチャンネルを設定することで、下記のようなメッセージを飛ばすことができます。 やってみた感想 ここまでご紹介したようにNode-REDを使うことで、少しコードを書くだけでここまでの仕組みを構築することができました。 本来はSlackとの連携や、Safie APIとの連携を行うためには中継の役割となるサーバが必要になりますが、Node-REDがそこを代替しているためかなり作成工数は抑えられています。 一方で、Node-REDにはアクセストークンをベタ書きにしており、そこをどう自動で更新していくかという点や、APIから取得したデータのうまい使い方を模索する必要があるなと感じました。 ノーコード・ローコードの仕組みは開発箇所を絞れて工数を抑えられる反面、ツールを使う上で出てくる仕様上の縛りとうまく向き合う必要があります。 クオリティ向上のためにコードを書いて追加開発を行うにも限界があるため、ノーコード・ローコードのままいかに機能を組み合わせ拡充していくかという考え方・工夫が必要になってきそうだなと感じました。

こんにちは！ このたびセーフィー株式会社でインターンをさせていただきました、吉田と申します。 この記事を通して、インターンで得た学びや、会社の雰囲気などが伝われば嬉しいです。 インターンをした経緯・目的 セーフィーのどこに興味をもったのか 選考 インターンの概要 やったこと 行動認識の既存モデルの検証 機械学習モデルの量子化 学んだこと・感想 インターンをした経緯・目的 私は就職活動において、大企業よりもベンチャー企業に魅力を感じていました。 ベンチャー企業のほうが、お客さんとも関われるし、事業全体に幅広く関わったり、新しいことにチャレンジできたりしそうだと思ったからです。 ただ、実際にベンチャー企業で働いてみた経験はなかったので、職場の雰囲気や業務内容がどうなのか体験してみたく、インターンをすることしました。 セーフィーは現在の研究テーマにあっていて、かつベンチャー企業ということで、大学の就職担当の方を通して紹介していただきました。 セーフィーのどこに興味をもったのか 私は、機械学習や神経科学を使って人間の知能について研究している研究室に所属しており、そのあたりの分野に関わりのある企業を探して就活をしていました。 セーフィーは、単に映像を扱っているだけでなく、将来的に「映像プラットフォーム」を作ろうとしています。 これは、複数のカメラの映像を一元管理し、膨大な映像を言語で検索したり、様々なアプリを使って解析したりできる場を作ろうというものです。 連続的な映像データから、起きたイベントなどの抽象的な情報を取り出して言語で検索できるようにするというのは、人間が見たものの意味を理解するということと共通する点が多いと感じ、興味を持ちました。 また、映像プラットフォームでは、他社製を含む映像解析アプリのプラットフォームを作り、そこから自由に選んで自社のデータに使えるようにするという構想があり、ビジネスの発展性という点からも面白い企業だなと思いました。 選考 インターンにあたり、面談とコーディングテストを受けました。 面談は会社説明を兼ねたカジュアルなもので、給与面や、私個人の将来についてのことも含め、いろいろ相談させていただきました。 コーディングテストは初めてだったので緊張していましたが、思ったよりも軽めのもので、ゆるく競技プログラミングに触れていたこともあり通過することができました。 インターンの概要 プロダクト開発部のイメージングチームに加えていただき、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