こんにちは。セーフィーで画像認識エンジニアをやっている木村Y（緑コーダー）です。 セーフィーには競技プログラミング愛好者が複数在籍しており、社内勉強会の一つとして競技プログラミングの勉強会が開催されています！ 競技プログラミングとは？ 概要 会の内容 最後に 競技プログラミングとは？ 競技プログラミングについて簡単に触れておきます。 競技プログラミングとは、決められた時間内で、出題中の与えられた要求を解決するコードを記述する競技です。問題は通常、アルゴリズムやデータ構造の知識をテストするために、数学、グラフ理論、文字列処理、動的計画法などの分野から選ばれます。 競技プログラミングのコンテストの代表的なものとして AtCoder 社が主催するものがあります。この勉強会では、このAtCoderのコンテストの過去問を中心に扱っています。 概要 毎週火曜日の業務終了後に勉強会を行っています。会議室を借りて行っていますが、リモート参加ももちろんOK。 青色コーダーの現主催者から、最近興味を持ち競プロを始めたばかりの方まで、さまざまな習熟度の方たちが参加しております。 また、今年からセーフィーには新卒の1期生が入社しましたが、すでにさっそく何人かの方に参加してもらっています（競プロ文化の浸透を感じます）。去年と比較して参加者が続々と増えてきており、盛り上がりが増してきている実感があります。 回によってまちまちですが、毎回3〜6名の参加者がおり、その内訳もデバイスやフロント、自分のような画像認識エンジニアまで、様々な分野のエンジニアが参加しています（過去には経理部の競プロerの方にも参加していただきました）。 このように競プロの問題を解いてみたい！という方なら、熟練者や初心者に関わらず、またエンジニア・非エンジニアに関わらず、誰でもウェルカムとなっています。 会の内容 基本的な会の流れとしては、AtCoderの過去のBeginer Contestから選んだ1つの回をA問題から順番に解いていくことが多いです（A問題が最も簡単で、B問題、C問題・・と徐々に難しくなってゆくのがAtCoderコンテストの特徴です)。 A問題 D問題 解いている問題について語りながら、雑談もしながら、時には無言で集中モードになりながら、ゆるく解いてゆきます。 参加者の習熟度によって解くスピードはまちまちになりますが、初学者が悩んでいる部分に、熟練者がヒントを出しながら進んでいく光景がよく見られます。さまざまなレベルの参加者で、一緒に考えて楽しんでいこうというスタンスが強いと思います。 このようにして問題を解いてゆき、ちょうど良い頃合い（疲れ具合）を見て、ホワイトボードなどを使って1~2問解説を行って終了となる流れが多いです。「自分はこうやって解いた」という議論も盛り上がりを見せます。 初心者の方にとっては新しい問題にチャレンジする機会や熟練者から教えてもらう良い機会になりますし、すでに問題を解いたことのある熟練者にとっても、（なかなかやる気の起きない）復習の良い機会になり、新しい言語でチャレンジしてみることもできます。問題の解説をすることでアルゴリズムへの理解が改めて深まったり、初心者の解き方を見て新しい視点が得られることもあるかもしれません。 毎回解く問題については決まっているわけではないので、この問題を解いてみたい！という希望に応じてフレキシブルに変更して行っています。また「動的計画法」など、テーマを絞って問題を解いてゆくこともあります。 最後に 様々な種類が存在するエンジニアの中で、競技プログラミングというのは共通言語になりうる数少ない題材の一つだと思っており、他部署のエンジニアとの交流を深めるとても良い機会にもなっていると思います。 おかげさまで参加者が徐々に増えてきており、さらに会を盛り上げるためにも、今後はテーマ別の強化週間を増やしたり、Heuristic Contestも取り上げてみたりなど、新しい試みを取り入れていければと思ったりしています。 熟練度によって非常に差がつきやすいという性質を持つ競技なので、初心者が参加しやすく、かつ熟練者にとって有意義なものにするために工夫してゆきたいです。 競プロ経験者の方を心待ちにしておりますので、興味のある方は採用ページをぜひチェックしてみてください！ safie.co.jp

こんにちは。セーフィー株式会社に所属するサーバサイドエンジニアの河津です。 セーフィーにはクラウドカメラやユーザーアカウントを一括管理できる統合環境である「 Safie Manager 」というサービスがあり、主にエンタープライズのお客様にご活用いただいています。 safie.jp エンタープライズ企業のお客様に対してもっと使いやすく、もっと効率的な管理ができるよう日々開発をしており、2023年2月には「効率的な管理」を実現させるための機能として、 ディレクトリ連携機能のリリース を行いました。 今回は、ディレクトリ連携機能をどのように開発していったか、またそれを実現させる「SCIM」というものについての記事を執筆してみました。 ディレクトリ連携とは Safie Managerのディレクトリ連携 SCIMについて シーケンス エンドポイント設定 インターフェース例 負荷対策について まとめ ディレクトリ連携とは 昨今様々な企業で、社員情報を管理するためにActive Directoryのような仕組みを用いているケースが多くなってきていると思います。 Active Directory (アクティブディレクトリ) とはマイクロソフトによって開発されたオンプレミスにおけるディレクトリ・サービス・システムのことです。2013年にはそのクラウドコンピューティング版である Azure Active Directory が誕生しましたが、こちらを導入されている企業様は多いのではないでしょうか。 azure.microsoft.com Active Directory(以下AD)で主に行えることとしてはユーザー認証とアクセス制御ですが、ADで構築した制御設定(誰がどの機能を触れるか)を他サービスにも反映させたい(=管理の手間をAD上の設定だけにしたい)という需要が生まれました。 ADの設定をそのまま他サービスに連携する、というのがディレクトリ連携のざっくりした説明になります。 Safie Managerのディレクトリ連携 Safie Managerとは、「誰が」「どのカメラを」見ることができるかを統合管理するためのアプリケーションです。 ユーザーとカメラそれぞれを管理する際、一人一人に対してカメラの視聴権限を割り振っていくのは手間になってしまうため、ユーザーとカメラそれぞれをグループごとにまとめて、グループ同士を紐づけることで「Aユーザーグループに所属しているユーザーは、A'デバイスグループ所属のカメラ全てが見れる」といった権限制御を行うことができます。 このグループの中に別のグループを作ることができ、まるでディレクトリ階層のような構造で管理を行うことができるのですが、Azure ADなども同様な階層構造でユーザー管理を行えるものであり、おそらくですがユーザーの所属部署情報や担当現場店舗ごとにグループを切る使い方が多いのではないかと思っています。 Azure ADでのグループ情報およびそこに所属しているユーザーを、Safie Managerにグループ情報ごと同期(プロビジョニング)できますというのが、Safie Managerのディレクトリ連携機能の概要になります。 ※Safie Managerの階層構造権限などの詳細な仕様については割愛させていただきますが、もし興味ある方はまずはぜひ 資料のご請求 からお願いいたします。 SCIMについて いざディレクトリ連携を行うとなった場合、システム管理者の立場から見ると、どのような設定を行えば良いのでしょうか。ここで使用されるのが SCIM というものになります。 SCIMとは、Identity情報(ユーザーの認証情報や権限)を自動プロビジョニングするためのプロトコルです。プロトコルと言うとHTTPのような通信規則が真っ先に思いつくかと思いますが、SCIMは通信規則ではなく標準規格です。「こういったインターフェースでやりとりしてくださいね」という取り決めのことです。 以前 SAML認証を用いたSSO(シングルサインオン)を実装する記事 を書きました。 SSO(シングルサインオン)機能を実装するための取り決めとしてSAMLを使用する ディレクトリ連携機能を実装するための取り決めとしてSCIMを使用する 上記のような関係性となります。 SCIMはRFCにも仕様が定義されているため、SCIMを用いたディレクトリ連携の機能を開発していく上で困った時はこちらを確認すると良いと思います。 tex2e.github.io 詳細な仕様は上記RFCをご確認いただくとして、この記事では私たちセーフィーがSCIMを取り扱った際にやったことや感じたことなどについて記載させていただこうと思います。 シーケンス セーフィーがディレクトリ連携機能のサポートをしているIdP(Identify Provider)は、執筆時点ではAzure Active Directory(以下AzureAD)のみとなります。他IdPの場合では差異があるかもしれませんが、AzureADからセーフィーにプロビジョニングされるシーケンスを記載します。 上記シーケンスは Microsoft公式のドキュメント から抜粋させていただいております。 SP(Service Provider)側はユーザー情報の追加や更新・削除ができるCRUDのAPIを用意しておき、IdP側で情報の更新が起きた際に随時APIを叩くようなシーケンスとなります。 SCIMでのプロビジョニング実行が行われる際、一番初めにGETのAPIが実行されます。このGET APIの実行結果により、 IdP側で持っている情報と違いがないため何もしない IdP側には情報があるがSP側には無いため、POST APIを実行しSPに情報を作る IdP側とSP側で情報が異なる(例: 名前が違う)ため、PATCH APIを実行し情報を更新する IdP側には情報がないがSP側には情報があるため、DELETE APIを実行し情報を削除する 上記のような処理に分岐していきます。 エンドポイント設定 SCIMで同期可能な情報は、ユーザー情報とグループ情報です。(他の情報もありますがここでの説明は割愛します) SPで実装したSCIM用のエンドポイントをIdPに登録することで、IdPから一定のタイミングで同期のリクエストが送られてきます。 情報登録を行える画面はこのようになっています。 登録できるエンドポイントは1つです。このエンドポイントを起点に、 /Users とリソース名が指定されたエンドポイントがユーザー操作の、 /Groups と指定されたエンドポイントがグループを操作するエンドポイントになります。 また、認証時のトークンを指定することができるため、SP側で用意するエンドポイントではトークン認証の仕組みを用意する必要があります。 トークンは Authorization: Bearer xxx 形式で送られてきます。また、Content-typeヘッダが Content-Type: application/scim+json となってリクエストが来るのも特徴です。 インターフェース例 SP側で用意したエンドポイントに対して、IdP側の情報変更があった際に都度SPにAPIリクエストが送られるというのがSCIMの概要ですが、SCIMはこのAPIリクエストの形式およびレスポンス形式についても取り決めがあります。 SCIMを行う上でのリクエスト・レスポンス形式(インターフェース)例はRFCに記載されているのと、IdPの仕様ドキュメントとしても記載されている場合が多いと思います。AzureADの場合は下記のドキュメントをもとにインターフェースの設計と実装を行いました。 learn.microsoft.com ここからはインターフェースの例をいくつか紹介します。 まずPOST /Usersのケースの例を記載します。ユーザーを同期するために必要となる情報は、 AzureAD上のユニークID ユーザー名 メールアドレス などを必須項目としており、下記のようなリクエストを受け付けられるようにしています。 { "externalId": "1234-5678-90ab-cdef", "emails": [{"primary": True, "type": "work", "value": "test@user.com"}], "displayName": "test user", } ちなみに externalId などのキー名については別の名前を使用することもできます。 AzureADには属性情報のマッピングを行う機能があり、この画面にて「Azure AD内のどの情報が」「どのキー名でやりとりされるか」を定義することが可能です。この画面からユーザー情報とSCIMのキーを紐付けます。 この辺りの設定は、IdPを操作できるお客様自身に設定いただくことになるため、基本的にはデフォルトとして設定されている内容を利用しつつ、どうしても設定いただく必要がある箇所についてはマニュアルに記載しつつお渡しするようにしています。 また、SCIMでプロビジョニングできる情報はユーザー情報だけではなく、グループの情報もプロビジョニングすることができます。グループが登録される際は、POST /Groupsに下記のようなリクエストが送られます。 { "schemas": [ "urn:ietf:params:scim:schemas:core:2.0:Group", "http://schemas.microsoft.com/2006/11/ResourceManagement/ADSCIM/2.0/Group", ], "externalId": "1234-5678-90ab-cdef", "displayName": "test group name", "meta": { "resourceType": "Group", }, } グループ自体の登録だけでなく、グループの階層配下にユーザーやグループを追加することもでき、その場合はPATCH /Groupsに下記のようなリクエストが送られます。 { "schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"], "Operations": [ { "op": "Add", "path": "members", "value": [{"$ref": None, "value": "1234-5678-90ab-cdef"}], } ], } valueの中のIDがユーザーIDの場合はユーザーの追加、グループIDの場合はグループの追加となります。 負荷対策について 例えばIdPに10万件のユーザーを一度に登録した際、ディレクトリ連携されているとその10万件はSPに同期されます。 一気に10万件のリクエストが来るとなると負荷対策的に少し不安になりますが、その辺りはどうなっているのでしょうか。 Azure ADについては、送られるリクエストの間隔が仕様として決められています。 learn.microsoft.com 正常系についてはこの仕様通りの間隔でリクエストが来るはずです。後はそれ以上のリクエストが来る場合(誰かが悪意を持って実行しまくること)を考慮し、例えばリクエスト状況をサーバキャッシュで保持しつつ処理毎に判断し、上記仕様より高い頻度でリクエストが来ている場合は処理前段でエラーとするようにしておけば、少なくともDB負荷については対策の一つとなりそうです。 まとめ ここまでSCIMやディレクトリ連携について記載しましたが、試行錯誤しながら進めていった上で感じたことなどを記載します。 インターフェース仕様はRFCなどで定められているものの、開発を進める上ではIdPにエンドポイントを設定しつつ、どのようなリクエストが来るかログを見ながら仕様を固めていく方が間違いない。 実際のリクエストで判別がつきづらいケース(エラーの場合など)は、RFCの仕様に則って実装すると良い。 IdP側の仕様や挙動によって想定外の工数が発生する恐れがあるため、余裕を持った開発およびQAスケジュールが取れると安心だと思います。 SCIMについてはドキュメントも少ないと思われますので、この記事がどなたかの役に立てば幸いです。 セーフィーではエンジニアの採用を積極的に行っております。もし興味が出てきた際はぜひご応募いただけたらと思います。 safie.co.jp

こんにちは、セーフィー株式会社でサーバサイドのエンジニアをしている河津です。同時に、このSafie Engineers' Blog!の運営も行っています。 2022年12月にセーフィー株式会社初のアドベントカレンダーを実施し、大盛況のまま終わりました。 (だいぶ遅くなってしまいましたが、)この記事では、その様子について振り返りを行いたいと思います！ 実施したアドベントカレンダーの基本概要は以前記事にしてまとめましたので、もし良ければこちらもご覧ください！ engineers.safie.link 基本情報 モチベーション 運営側で意識したこと 執筆記事のピックアップ ピックアップその１：画像認識コンペについて(CTO森本のフリー素材化) ピックアップその２：PoC系の記事 ピックアップその３：サーバ・インフラに関わる記事 ピックアップその４：開発マネジメント系の記事 ピックアップその５：インターンシップについて 振り返り 基本情報 アドベントカレンダーはQiitaの機能を用いて行いました。 qiita.com 開催前から25枠全てが埋まり、一つの欠けもなく全ての記事が執筆・公開されました！改めて執筆いただいた方々には感謝しております。 モチベーション テックブログの更新などは少しずつ進めていたものの、アドベントカレンダーの開催は今回初となります。 他のテックカンパニーでは当たり前のように開催されており、アドベントカレンダーを開催しないこと自体がセーフィーにとってマイナスになると感じていました。 2022年度になってテックブログ運営チームの体制がようやく整ってきたため、満を持して開催することができました。 運営側で意識したこと まずは「開催して運営する」ことを目標とし、25枠埋めることは目標としませんでした。どちらかというと開催すること自体が最重要と思っていたのと、運営する上での課題は走ってみてフィードバックを集め来年に改善していくことを意識しました。(その上で25枠埋まったのはかなり嬉しいことでした) なるべく運営側の負荷がかかりすぎないよう、あえてレビューフローを短縮しリスクチェックのみとし、運営側が走りきれる体制を心がけました。(後の振り返りで、記事のクオリティアップのためにレビューは厚めにした方が良いかもというフィードバックを得ています。このフィードバックも、まずは実験的にやってみたことで得られたものだと思っています) 執筆記事のピックアップ ここからは、実際にアドベントカレンダーに寄せられたいくつかの記事についてピックアップしたいと思います。 ピックアップその１：画像認識コンペについて(CTO森本のフリー素材化) 執筆いただいた記事の中で、セーフィー社内で行った画像認識コンペをテーマに取り扱った記事が3記事ほど集まりました。 コンペの内容は、オフィス内に設置されているカメラにCTO森本が映ったらそれを検知し、メールやSlackなどに通知するまでを目標に開発を行う、というものです。 いずれも解析モデル構築について試行錯誤している記事になっています。 engineers.safie.link qiita.com qiita.com CTOの顔画像を自由に使って進めている雰囲気がとても良いと思い一番最初にピックアップさせていただきました。 ※アドベントカレンダーの記事ではないですが、最近も顔はめパネル作成をテーマにした記事内でCTOの画像を使用しつつ技術解説しています。 engineers.safie.link ピックアップその２：PoC系の記事 アドベントカレンダーに限らず、セーフィーのテックブログ内にはサービス内で使用されている技術や導入検討している技術の話などが多く集まる傾向にありますが、今回のアドベントカレンダーではそれに限らない様々な角度からの記事が集まりました。 そのうちの一つがPoC系の記事であり、「 whisper 」を用いた文字起こしや、今話題の「 ChatGPT 」について「やってみた/触ってみた」系の記事が集まりました。 いずれも多くの方に読まれた記事となりました。 qiita.com engineers.safie.link ピックアップその３：サーバ・インフラに関わる記事 AWSに関するインフラ周りをテーマにした記事が多く集まる傾向にありました。その中で特にAmazon Aurora MySQLのバージョンアップの話、AWSのコスト集計作業を効率化する話がぞれぞれ多く読まれた記事となったため、ピックアップさせていただきます。 engineers.safie.link engineers.safie.link ピックアップその４：開発マネジメント系の記事 テックブログには技術的な内容をテーマにしたものが集まる傾向にありますが、今回は開発マネジメント系の記事もいくつか集まりました。 マネジメント系と一括りに話しましたが、「スクラム開発」「プロダクトマネジメント」「エンジニアリングマネジメント」「新規事業開発」など様々な観点にフォーカスされた記事が集まりました。 engineers.safie.link engineers.safie.link qiita.com qiita.com ピックアップその５：インターンシップについて 2023年新卒入社予定でインターンシップに参加いただいた学生の方に、インターンシップの内容について記事にしていただきました。 志望理由やインターンシップで行ったこと・試行錯誤したポイント、学んだことなどを執筆しており、セーフィーへの新卒採用エントリーを検討している学生の方々には参考になる内容なのではないかと思っています。 engineers.safie.link 振り返り 初回での開催であり、運営側もノウハウがない中実施したため、いくつか運営側の課題が出てきました。一部を抜粋すると、 Qiitaのカレンダーを使用したが、Qiitaアカウントを持たない人に対して代理でURL登録を行う運用が手間になったため、 Adventar などの使用を検討する 参加ガイドラインの存在が伝わりきらず、ガイドラインの内容が長く分かりにくいからではないかという意見が挙がったためガイドラインの見直しを行う 告知と執筆者募集については早めに(10月初旬ごろには)行った方が良い などの意見が上がったため、改善につなげていきたいと思っています。 また、2023年度も実施を検討していますため、ぜひ楽しみにお待ちいただけたらと思います！ セーフィーではエンジニアの採用を積極的に行っております。もし興味が出てきた際はぜひご応募いただけたらと思います。 safie.co.jp

こんにちは、セーフィー　フロントエンドエンジニアの沖です。 こちらの記事でも紹介されてますが、セーフィーには様々な種類のエンジニアが在籍しています。 engineers.safie.link 組み込みソフトウェアエンジニア サーバーサイド / インフラ・SREエンジニア AI / 画像処理 エンジニア フロントエンドエンジニア iOS / Androidエンジニア 業務システムエンジニア QAエンジニア データエンジニア 各エンジニアは個人での技術研鑽はもちろんのことチームによっては定期的に勉強会を開いてその知見を共有しています。 チーム毎に勉強会の特色や目的が異なっていたりするので今回はその違いやどんな勉強会があるかについてお話したいと思います。 サーバーチームの勉強会 イメージングチームの勉強会 開発関連の勉強会 論文調査共有会 Webフロントエンドチームの勉強会 モバイルチームの勉強会 まとめ サーバーチームの勉強会 サーバーチームはサーバーサイド / インフラ・SREエンジニアが所属しているチームです。 サーバーチームでは、メンバー各々が持つ開発知見を共有しチーム全体の技術力を底上げすることを目的として隔週で勉強会が開かれています。 2名ずつ発表担当者を決めて、当日までにスライドを作成し約30分の持ち時間の中で発表と質疑応答をします。発表自体は20分で終了し、残り10分で質疑応答とすることが多いです。 こちらが勉強会の1例です。 「WebRTCについて」 内容：WebRTCの概要や通信の仕組み（シーケンス）などの解説。セーフィーの中でWebRTCは、カメラからのライブ映像を低遅延に閲覧するためや、セーフィーで提供しているウェアラブルクラウドカメラ「Pocket2」で使用できるグループ通話機能で使用されています。 開発に携わっている人以外のメンバーへの知見共有の意図もあり実施されました。 「Rustについて」 内容：Rust言語の概要やHello Worldまでの流れ、Rustの特徴である所有権についての解説。 セーフィーでは現状Rustでの開発はありませんが、新しい技術のキャッチアップの意図で開催されました。 「ディレクトリ連携について」 内容：Safie Managerというプロダクトに追加されたディレクトリ連携機能についての共有と、SCIMというものを用いて実装をした話をしました。 勉強会の様子 「Open Policy Agentについて」 内容：Open Policy Agentというポリシーエンジンを実験的に触ってみて、特徴や使用感などをデモと一緒に解説しました。 勉強会の様子 サーバーチームの勉強会では、実際に利用している技術の共有はもちろん、プロダクトには利用していない技術も勉強会のネタとして上がることが多いです。 イメージングチームの勉強会 イメージングチームは画像認識エンジニアが所属しているチームです。 イメージングチームで実施されている勉強会は2つあります。 1つは開発関連の勉強会、もう1つは論文調査共有会です。 開発関連の勉強会 開発関連の勉強会は、2週間に1回の頻度で開催されています。 テーマは、実際に開発しているプロダクトの内容や、各種ツールの紹介等が多くなっています。 例えば、以下のような勉強会が行われています。 「Yoloxの量子化とsnpeの使い方」 内容：SafieOne、AI-App: Store People Detection Pack(以降SPDP)で検討したネットワークであるyoloxの量子化技術、そしてSPDPで利用されるSNPE SDKの利用方法についての紹介 論文調査共有会 論文調査共有会も2週間に1回の頻度で開催されています。 画像認識エンジニアとして論文を読む習慣をつけることで最新の技術動向にキャッチアップすることを目的としています。 忙しい通常業務の中でも読む習慣をつけることが目的のため、共有のための資料を作るというようなことはしません。 紹介後には質疑応答があり、紹介者が分からなかった場合には皆で読みながら解決していきます。 以下が勉強会の1例です。 論文タイトル：「Rethinking Atrous Convolution for Semantic Image Segmentation」 内容：CVPR2022の2017年のセマンティックセグメンテーションの論文で、DeepLabV3として知られています。 こちらは業務でセマンティックセグメンテーションを扱う機会があり、その一環として扱いました。 イメージングチームの勉強会には論文調査共有会というアカデミックな内容が含まれているのが特徴です。 勉強会のネタだし会の様子 Webフロントエンドチームの勉強会 Webフロントエンドチームは、フロントエンドエンジニアが所属しているチームです。 既に実装されている機能の共有やチーム内のコミュニケーションの活性化を目的に毎週開催されています。 所属メンバーが順番に発表者となり話したいテーマを話していく形で進めています。内容の難易度は基本的に不問で発表すること自体を重要視しています。 スライドに関しては、発表者が要否を判断して発表を行いますが、スライドよりは実際のコードを見ながら議論するケースが多いです。 こちらが勉強会の1例です。 「認証の仕組み」 内容：フロントエンドで認証情報をどのように扱っているかの解説。 実際の実装を見ながらCORSやCSPなどの周辺知識を共有しながらディスカッションを実施しました。 「セーフィー独自で作成されたライブラリの説明」 内容：実装を簡略化するためにセーフィー内で実装されているライブラリの中身に関する説明。 利用する時の考慮点はもちろん内部実装を深堀ってディスカッションを行いました。 コードを映しながらディスカッション Webフロントエンドチームの勉強会では、実装している社員が変わっていくということを前提に既存のコードの深掘りを行うことが多いです。 メンバーによっては知っていることの復習になるケースもありますが、それは許容し発表することのハードルを下げるようにしています。 テーマは業務外の内容になることもありますが、比較的業務で利用している技術になることが多いです。 モバイルチームの勉強会 モバイルチームは、iOS / Androidエンジニアが所属しているチームです。 業務内外問わず個人が得た技術的知見をチームに共有することを目的に隔週で開催されています。 所属メンバーが順番に発表者となりテーマを決めてスライドを作成し20～30分で発表します。 その後質疑応答が10分～20分ほどあることが多いです。 どのようなテーマを取り上げるかはメンバーに任されています。 こちらが勉強会の1例です。 「RxSwiftについて」 内容：プロジェクトにRxSwiftを取り入れたタイミングで、実装者による初学者向けの解説を行いました。 「KMM(Kotlin Multiplatform Mobile)について」 内容：KMM自体を知らないメンバーにも分かりやすく概要から説明。 実際にチーム内で活用するならどうするか、どういったメリットがあるのか等を交えたディスカッションも行いました。 モバイルチームにはiOSエンジニアとAndroidエンジニアがいますが、勉強会は自分の担当しているOS以外の知見を広げられるいい機会となっています。 まとめ セーフィーの社内では数多くの勉強会が開かれていますが、チーム毎に課題と思っていることや求められているものが異なるため、勉強会の目的ややり方にも特徴が出ています。 また、勉強会自体も昔からあるものから新しく始まったものまで様々です。 セーフィーには、技術的にモチベーションが高いエンジニアが数多く在籍しているので、もし記事を読んでセーフィーに興味を持っていただいた方はぜひご応募ください。 article.safie.link

こんにちは。「 Safie Pocket2 」のプロダクトマネージャーをしている坂元です。 本記事では2022年11月に全てのSafieカメラで利用可能となった位置情報連携機能について紹介したいと思います。 位置情報連携機能とは 据え置きカメラにまで機能を拡大する理由 直感的なUI リリース後の反響 最後に 位置情報連携機能とは 位置情報連携機能は、2020年10月にGPSを搭載するウェアラブルカメラ「Safie Pocket2」に搭載された機能です。 Safie Pocket2が取得した位置情報をマップビューアー（Safie Viewerの地図アプリ）上に表示して、映像データと紐づけて表示することができます。 移動による位置情報の変遷を移動軌跡として表示が可能なため、Safie Pocket2の軌跡を追いながら映像を確認することが可能となりました。 この位置情報連携機能により、ユーザーはこれまでの時間軸による映像管理だけでなく、位置情報による映像管理が可能となり、映像データの利活用の幅を広げられます。 Safie Pocket2と位置情報連携機能は多くの現場で活用いただいています。 ある現場では、現場従事者の移動軌跡と映像データを、効率的な導線を定着させるための新人教育に活用されています。また、遠隔パトロール中のトラブル発生時には、管理者が位置情報を即座に共有し、応援を現場に向かわせるといったユースケースで採用されています。 Safie Pocket2の位置情報連携機能（イメージ） 据え置きカメラにまで機能を拡大する理由 Safie Pocket2のようにウェアラブルカメラは移動を伴うので、変化する位置情報と映像データの紐づけが、いかに有用かは想像しやすいと思います。 今回、移動することがほぼない「据え置きカメラ」になぜ位置情報連携機能を開発したかの背景を説明します。　 映像データ＋位置情報による映像データの活用を広げる Safie Pocket2で映像データに位置情報を紐づけることで、映像データの利活用の幅が大きく広がりました。据え置きカメラでも同じことを再現できると考えています。 管理者は据え置きカメラの位置情報と映像を基に、現場従事者にこれまで以上に適切な指示を出すことが可能になります。 例えば、河川管理の監視カメラ映像に位置情報と画角情報を紐づけるとします。すると災害発生時に、設置位置や、上流から見た映像か・下流から見た映像かを瞬時に判断して、適切な意思決定ができるようになります。 カメラの複数台管理を効率化させる Safie Viewerではカメラの映像を見たいときにはカメラ一覧からデバイスを選択する必要があります。 ユーザーはデバイス名を任意で付けることができるので、そのカメラを特定しやすいデバイス名を付けています。 複数のカメラを管理する場合、デバイス名で管理されている しかし、複数台のカメラを導入している場合、デバイス名は「〇〇工事現場南門（ 北西側 から撮影）」「△△ビル カメラ 5号機 」のように、方角やナンバリング等でカメラを管理していることが分かりました。 カメラ設置した本人であればこれらのデバイス名でカメラを容易に特定できますが、現場を知らない場合、どこに設置され、どの画角で撮影しているカメラかを特定することが難しく、コミュニケーションコストが発生していたと推察しています。 こうしたカメラの複数台管理のコストを軽減させるために、地図上にカメラ設置位置の表示、画角の情報を表示させる手法は有効だと考えました。 直感的なUI Safie Pocket2と異なり、据え置きカメラの多くにはGPS機能が搭載されていない為、自動的に位置情報を取得することができません。 ユーザーが手動で位置情報を設定する必要がある為、カメラの位置情報をいかに簡単に設置させることに拘りました。 話はそれますが、Safieを選んでいただく理由でプロダクトの直感的な操作がよかったと言う声を多くいただきます。今回も多分に漏れず直感的に操作できるUIを目指しました。 カメラの位置と向きを設定する管理画面 マップビューアー（Safie Viewerの地図アプリ）の画面（イメージ） 管理画面の地図上にて、クリック＆ドラックでカメラの位置を設定 カメラの位置は地図上をクリックすると表示されるカメラアイコンを 地図上でドラックするだけで容易に設定できます。 カメラの向きの簡単設定が可能 カメラ向きはマーカーをクリックして円周上で動かすと、マップ上にあるカメラの向きが連動して変わります。 マップビューアー内のカメラの視認性向上 機能の適用拡大により表示されるカメラの数が増えることから、地図上のカメラアイコンの表示内容やデザインを見直し、視認性を向上させました。 　 リリース後の反響 2022年11月のリリース後の1か月間で、位置情報連携機能の利用者は前月より 約60％ 増えており（※）、据え置きカメラでの利用が進んでいます。 特に、建設現場等の屋外現場向けのSafie GOシリーズのユーザーの利用が多い傾向にあります。これは、広域の屋外現場に複数台のカメラを設置している建設業や土木業のニーズにマッチしている結果であると推察しています。 （※2022年10月と12月のマップビューアー利用者数の実績より） 最後に 2023年1月にSafie GOシリーズにGPS機能を持つ据え置きカメラ Safie GO PTZ Plus が追加されました。 これにより自動でカメラの設置位置を取得しマップビューアー上に表示することが可能となりました。（23年1月時点でSafie GO PTZ Plus以外の据え置きカメラは手動設定による位置情報設定が必要です） 「映像から未来をつくる」がセーフィーのビジョンです。 映像データの価値を上げるために、映像デバイスやAI解析技術の開発が進んでいます。今回の映像データ＋位置情報もまた映像データの価値を上げ、ユーザーが映像データの利活用の幅を広げる一手であると思います。 今後もさらなる提供価値を高めていくため、映像データ＋位置情報のブラッシュアップを継続していきます。

こんにちは！エンジニアの大林です。 先日セーフィーのエンジニアにアンケートを取ったので、今回はその内容をお届けします。 アンケートのテーマは「新卒エンジニアにおすすめの〇〇は？」ということで、以下の3つについて聞いてみました！ 技術本 技術以外の本 本以外の学習媒体 新卒エンジニアにおすすめの技術本は？ 新卒エンジニアにおすすめの技術以外の本は？ 新卒エンジニアにおすすめの本以外の学習媒体は？ 最後に 新卒エンジニアにおすすめの技術本は？ たくさんの意見が寄せられましたが、中でも多かったのが以下の2冊でした。 1. リーダブルコード / Dustin Boswell、Trevor Foucher リーダブルコード ―より良いコードを書くためのシンプルで実践的なテクニック (Theory in practice) 作者: Dustin Boswell , Trevor Foucher オライリージャパン Amazon 美しいコードを見ると感動する。優れたコードは見た瞬間に何をしているかが伝わってくる。そういうコードは使うのが楽しいし、自分のコードもそうあるべきだと思わせてくれる。本書の目的は、君のコードを良くすることだ。（本書「はじめに」より） ＼エンジニアからのおすすめの声／ 仕事で書くコードは自分以外の人も読めて保守性が高いことは非常に重要です。 この本を読むことで他人が読めるコードを書くための書き方を理解できます。 読みやすいコードの何たるかを学べる。どんなエンジニアでも役に立つ！ 最低限のコードルールを知っておいてほしいから。 コーディングする上でのTIPSが豊富！ 私もエンジニアとして仕事を始める前にこの本を読みました。当たり前ですが、仕事でコードを書いていると、自分が書いたコードをチームのメンバーや未来の自分が読んだり、そのプログラムに改修を加えたりするので、コードの読みやすさがいかに大切かを実感します。読み物としてもとても読みやすい本だと思います！ 2. Webを支える技術 / 山本陽平 Webを支える技術 ―― HTTP，URI，HTML，そしてREST WEB+DB PRESS plus 作者: 山本 陽平 技術評論社 Amazon 本書のテーマは,Webサービスの実践的な設計です。まずHTTPやURI,HTMLなどの仕様を歴史や設計思想を織り交ぜて解説します。そしてWebサービスにおける設計課題,たとえば望ましいURI,HTTPメソッドの使い分け,クライアントとサーバの役割分担,設計プロセスなどについて,現時点のベストプラクティスを紹介します。 ＼エンジニアからのおすすめの声／ Webの基礎が理解できるから。 開発全般で意識すること、周辺知識を理解できる！ CSの基本的な内容。 この本を挫折しそうになった人には「プロになるためのWeb技術入門」がおすすめ！ こちらの本もエンジニアとして仕事を始める前に読みましたが、文系出身でコンピュータサイエンスを全く学んでこなかった私には難しいと感じる部分もありました。ただ、業務をしていく中で「あ、これってあの本で言ってたアレのことか！」という風に点と点がつながる瞬間があったりして、たくさんインプットすることの大事さを感じていました。 また、この2冊ともをおすすめしたエンジニアからは「初学者であれば、平易で広い概念から入って、その後さらに専門領域の書籍に移っていくのが良さそう」という意見が出ていました！ そのほかにもたくさんの技術本が挙がったのでジャンルごとにご紹介します。 様々なエンジニアが集まるセーフィーらしく、幅広いジャンルがおすすめとして挙がりました。 サーバー Amazon Web Services 基礎からのネットワーク＆サーバー構築 Linuxとpthreadsによるマルチスレッドプログラミング入門 Linuxのしくみ SQL 第2版 ゼロからはじめるデータベース操作 SQLアンチパターン SREの探求 新しいLinuxの教科書 *達人に学ぶDB設計徹底指南書 言語・コーディング C++のためのAPIデザイン CODE COMPLETE 完全なプログラミングを目指して EffectivePython コーディングを支える技術 プログラミングTypeScript 実践ソフトウェアエンジニアリング 設計 Clean Architecture UNIXという考え方 オブジェクト指向でなぜつくるのか オブジェクト指向のこころ テスト駆動設計 データ指向アプリケーションデザイン ―信頼性、拡張性、保守性の高い分散システム設計の原理 コンピュータサイエンス CPUの創りかた RISC-VとChiselで学ぶはじめてのCPU自作 コンピュータシステムの理論と実装 プロセッサを支える技術 Web・ネットワーク Real World HTTP プロになるためのWeb技術入門 その他 JSTQB（資格） Team Geek ゼロからつくるDeepLearning ビッグデータを支える技術 達人プログラマー 新卒エンジニアにおすすめの技術以外の本は？ こちらもかなり幅広く集まったので、一部ピックアップしてご紹介します。 ユニコーン企業のひみつ 起業のファイナンス 経営に終わりはない 武器としての決断思考 伝え方が9割 失敗の科学 失敗の本質 イシューからはじめよ イノベーションのジレンマ amazonのすごい会議 問いかけの作法 予想通りに不合理 若手育成の教科書 起業や経営に関わる内容のものが多くてベンチャーらしいなと思いました。また、急速に組織が大きくなっていることや、新卒採用を始めたばかり(23卒から)なことなどが影響していそうな本が多かったのもセーフィーらしいのかなと感じました！ 新卒エンジニアにおすすめの本以外の学習媒体は？ 本以外で学習するための媒体として何を活用しているかを聞きました。 podcast rebuild.fm fukabori.fm Udemy のような音声や動画で利用するものから、 プロコン(チーム形式) ハッカソン Atcoder 人！ など、エンジニア同士のコミュニケーションを重視する声もありました。 最後に 新卒エンジニアに向けてのメッセージも募集しました！ 技術本を読み漁ることも大切ですが、仕事に慣れない内はIPAの資格や業務関連資格を取得し、知識の体系化に努めると良いと思います。仕事に少し慣れてきたら、テック系の勉強会やイベントに参加すると良いと思います。社外の優秀なエンジニアから刺激を受け、勉強や仕事のモチベーションに繋がります。 誰でも初めは若葉マークと思っていますので失敗したことに対して落ち込みすぎないようにすると気が楽ですよ。挑戦してみての失敗は致し方なしですし、ボスが大体責任取ってくれますので今のうちに失敗をいっぱいしましょ！ 数多ある企業の中で、せっかくできたご縁ですので一緒にいい仕事をしましょう！ わからないことがあればなんでも聞いてください！技術トークしましょう！ 周囲の常識や固定観念にとらわれずに、自分らしく伸び伸びとやってください！ セーフィーではいろいろな技術領域を学ぶことのできるエンジニアとして成長できる環境です。ぜひセーフィーで成長し、新しい価値を社会にどんどん提供していきましょう。 セーフィーでは新卒エンジニアを募集しています！ 興味を持っていただけたらぜひ採用サイトも覗いてみてください。 safie.co.jp

こんにちは。セーフィーで画像認識エンジニアをやっている柏木です。 今回はセーフィーで行った PoC (Proof of Concept) の一つである、商品棚の Semantic Segmentation について紹介いたします！ 背景と課題 Semantic Segmentation DeepLabV3 データセットとアノテーション MMSegmentationを使った学習 データセットClassの作成 データセットConfigの作成 学習・テストConfigの作成 環境 学習 評価結果 終わりに 背景と課題 大手スーパーマーケット様より、商品棚の欠品状況を解析したいとのお話がありました。欠品の状況が解析できれば、品出しのタイミングを最適化し、機会損失を削減することができます。イメージングチームではこれらの課題を解決すべく、PoCを行ってみることとしました！ こちらが実際の商品棚の写真になります。 Semantic Segmentation 欠品状況を解析するためのアルゴリズムとして、 Semantic Segmentation を選定しました。Semantic Segmentationとは、画素ごとにカテゴリ付けを行うニューラルネットワークのアルゴリズムです。自動運転や、医療用途で利用されています。 Semantic Segmentationは 境界をはっきり出すことができる 重なりがある物体や不定形の物体に強い ことが特徴のアルゴリズムになります。 別のアルゴリズム案として物体検出も考えましたが、重なった商品や小さな商品を検出するのが難しいことから、今回はSemantic Segmentationを採用しました。 DeepLabV3 DeepLabV3 はGoogleが2017年に発表したSemantic Segmentationアルゴリズムです。Atrous畳み込みを直列に何層も重ね、またAtrous rateを変えて並列に繋げたことが新規性のネットワークとなっています。論文は『 Rethinking Atrous Convolution for Semantic Image Segmentation 』です。 セーフィーではエッジAI機能を搭載したカメラである『 Safie One 』を提供しています。そこで、Safie Oneでも動作可能な軽量なモデルとしてDeepLabV3を使用することとしました。 DeepLabV3の公式リポジトリはTensorflow実装になっています。セーフィーではPytorchの知見が多いので、Pytorch実装である MMSegmentation を使用しました。こちらのリポジトリはDeepLabV3に限らず多くのモデルが実装されており、バックボーンも豊富で使いやすいです。 データセットとアノテーション データセットはスーパーマーケット様より提供いただきました。モデル自体が軽量ということや、固定カメラにおける利用を想定していることから多くの画像のバリエーションは不要と判断しました。そこで、Train（学習用）・Validation（検証用）・Test（テスト用）含めて200枚程度としました。 アノテーションツールは弊社が日頃から利用させていただいている『 FastLabel 』を使用しました。FastLabelは物体検出、物体追跡、Segmentationなど豊富なタスクをアノテーションすることができます。クラウドベースのサービスのため、アノテーションした結果をチーム内で共有することも容易にできます。またUIが日本語なので使いやすいです。 FastLabelが出力するアノテーション形式は選ぶことができます。今回はMMSegmentationで利用することが容易だったマスク画像を使用しました。 アノテーションにおけるクラスは background package person wagon の4種類としました。packageが実際の商品を表すカテゴリです。backgroundとpackageさえあれば欠品状況は解析できるのですが、人やワゴンが映り込むことでオクルージョン（隠れ）が生じることがあり、そのような状況は検出不能と扱う必要があるためのでperson、wagonと別カテゴリを用意しました。 マスク画像(黒がbackground, 赤がpackage) MMSegmentationを使った学習 データセットClassの作成 独自データセットで学習するためには、まずそのデータセットClassを作る必要があります。 mmseg/datasets/以下にデータセットの設定ファイルを作成します。 class SaladDataset (CustomDataset): """Salad dataset.""" CLASSES = ( 'background' , 'package' , 'person' , 'wagon' ) PALETTE = [[ 0 , 0 , 0 ], [ 0 , 0 , 192 ], [ 0 , 192 , 0 ], [ 192 , 0 , 0 ]] def __init__ (self, **kwargs): super ().__init__(img_suffix= '.jpg' , seg_map_suffix= '.png' , **kwargs) おもにクラス（カテゴリ）の名前CLASSES、推論結果の画像出力時の色であるPALETTEを変更すれば大丈夫です。 作成したら mmseg/datasets/init.py に作成したクラスを追加します。 データセットConfigの作成 configs/base/datasets/以下に学習・テストの設定ファイルを作成します。 dataset_type = 'SaladDataset' data_root = 'data/salad' img_norm_cfg = dict ( mean=[ 121.13 , 118.48 , 115.98 ], std=[ 3.14 , 2.97 , 3.15 ], to_rgb= True ) crop_size = ( 512 , 512 ) train_pipeline = [ dict ( type = 'LoadImageFromFile' ), dict ( type = 'LoadAnnotations' ), dict ( type = 'Resize' , img_scale=( 2048 , 512 ), ratio_range=( 0.5 , 2.0 )), dict ( type = 'RandomCrop' , crop_size=crop_size, cat_max_ratio= 0.75 ), dict ( type = 'RandomFlip' , prob= 0.5 ), dict ( type = 'PhotoMetricDistortion' ), dict ( type = 'Normalize' , **img_norm_cfg), dict ( type = 'Pad' , size=crop_size, pad_val= 0 , seg_pad_val= 255 ), dict ( type = 'DefaultFormatBundle' ), dict ( type = 'Collect' , keys=[ 'img' , 'gt_semantic_seg' ]), ] ~~ 省略 ~~ data = dict ( samples_per_gpu= 4 , workers_per_gpu= 4 , train= dict ( type = 'SaladDataset' , data_root= '/workspace/mmsegmentation/data/salad' , img_dir= 'train/images' , ann_dir= 'train/annotations' , pipeline=train_pipeline), 特に dataset_typeの指定 data_rootの指定 data augmentationのパイプライン（train_pipeline, test_pipeline） train, val, testのtype、data_rootの指定 に注意してください。 学習・テストConfigの作成 configs/ユーザー名/以下にネットワークモデルの設定ファイルを作成します。 _base_ = [ '../_base_/models/deeplabv3_r50-d8.py' , '../_base_/datasets/salad_data.py' , '../_base_/default_runtime.py' , '../_base_/schedules/schedule_20k.py' ] model = dict ( backbone= dict ( type = 'ResNet' , depth= 18 ), decode_head= dict (in_channels= 512 , channels= 128 , num_classes= 4 ), auxiliary_head= dict (in_channels= 256 , channels= 64 , num_classes= 4 )) 特に データセット設定ファイルの指定（'../base/datasets/salad_data.py'） クラス数（num_classes） 学習スケジュール（'../base/schedules/schedule_20k.py'） の指定に注意してください。 環境 Dockerfileからイメージを作成し、コンテナを立ち上げます。ただ元のDockerfileではmmsegmentationをgitでcloneしてインストールしていますが、今回は独自データセットを利用するためにコードを変更しています。そのため、git cloneではなく現在のディレクトリをマウントするようにする必要があります。また、データセットがあるフォルダをマウントしてください。 学習 学習はtools/train.pyで可能です。今までの設定で準備は終わっているので、学習・テストのconfigファイルを引数で指定すればOKです！ 学習時間はGPUのNVIDIA GeForce RTX2080 Tiを使用して１時間ほどで終わりました。 評価結果 tools/test.pyで評価することができます。推論だけではなく評価もスクリプトに含まれているので、そのまま表示されます。 IoU は正解の領域と推論した領域の重なり具合を評価する指標です。一方で Accuracy はカテゴリを正確に推測できている画素の割合の指標になります。 Class IoU Acc background 95.31 97.35 package 85.38 92.61 person 87.1 97.14 wagon 78.65 86.24 クラス別の値をみるとbackgroundとpersonで高い値が出ています。一方wagonは少し苦手なようです。 aAcc はすべての画像でAccuracyを出したときの値、 mIoU は画像ごとのIoUの平均値、 mAcc は画像ごとのAccuracyの平均値です。 aAcc mIoU mAcc 96.13 86.61 93.33 精度という観点でみると９割以上を達成してます。勿論、今後さらなる改善に向けた精度向上は必要ですが、欠品検知という課題解決の目的では十分な性能と言っていいのではないかと考えています。 終わりに 今回はセーフィーで行っている、商品棚のSemantic Segmentationに関する取り組みを紹介しました。これ以外にもお客さんの課題を解決するためのPoCをどんどん行っていく予定ですので、興味がある方は是非チェックしてみてください！ また一緒に働く仲間も募集しています！採用ページは こちら にあるので、よろしくお願いします！

データ分析基盤グループでデータエンジニアをしている平川です。 近年注目されてきているDataVaultに関して、全3回(予定)で記事を書かせていただく予定です。 第1回の記事では、DataVaultとは何なのか？どんな特徴があるのかを書いていきます。 参考までに、1~3回の内容を紹介しておきます。(内容は変わる可能性が大いにありますのでお許しください🙇‍♂️) 第1回: DataVaultってなに？どんな特徴があるの？ ← 今回はここ 第2回: dbtvaultを使って実際にDataVaultモデリングでテーブルを作ってみた 第3回: BusinessVaultの使い所や特徴的なSatelliteの利用におけるハマったところや良いところ これまでのデータモデリング手法 3NF ディメンショナルモデリング DataVaultとは何か? Hub Link Satellite モデリングにおける注意点 DataVaultの優れている点と課題 DataVaultの優れている点 監査能力の高さ 取得するデータが増える場合のような変更に対する柔軟性の高さ 短いリリースサイクルでDWHを更新することの容易さ DataVaultの課題点 クエリがJOINだらけになる 初期構築時に「正しく」Hubを設計することが簡単ではない まとめ/次回予告 Hub Link Satellite 参考資料 これまでのデータモデリング手法 分析基盤構築において、 データウェアハウス(DWH) 層で行うデータモデリングは、アプリケーション開発のデータモデリングとは目的が異なります。 アプリケーション開発におけるデータモデリングの主な目的はシステムを円滑に動かすことです。 一方、DWH層でのデータモデリングはデータ分析のしやすさやデータの履歴化が目的になります。 両者の目的は異なるため、必要となるデータモデリングにも違いが現れます。 次に、これまでDWH層で使われてきたデータモデリングについて紹介します。 主要なデータモデリング手法には大きく2つあり、William Inmon氏が提唱した 第3正規形(3NF) によるモデリングとRalph Kimball氏が提唱した ディメンショナルモデリング があります。 今回はこれらのデータモデリングが主テーマではないですが、それぞれの特徴や課題を簡単にまとめておきます。 3NF 3NFによるモデリングは、アプリケーション開発でも使われている3NFと同じ意味です。3NFはテーブルの数が膨大なDWHの実装で使われることが多いです。 3NFの目的は、各テーブルの関係や情報を可能な限り詳細に保持することにあります。データソースであるアプリケーション全体のデータモデルをDWHに構築します。 3NFの問題点としては、作成するテーブルの数が膨大であることで、初期構築に多くの労力と期間が必要となることと新規パラメータの追加などへの柔軟性が低いことです。そのためユーザからの新たなパラメータの追加など柔軟性が高いとは言えません。 ディメンショナルモデリング ディメンショナルモデリングは、データソース(アプリケーション側のデータや別システムのデータ)をディメンションテーブルとファクトテーブルに分割して作成します。 ディメンションテーブルには、商品名などの属性情報を格納し、ファクトテーブルには売上などの数値情報が格納されます。 ディメンショナルモデリングはアプリケーション開発におけるデータモデリングとは構造が大きく異なり、データ分析に特化した構造になります。 ディメンショナルモデルの例 ディメンショナルモデリング手法をもとに構築されたテーブルは、データがディメンショナルとファクトで分割されていることで、データの理解がしやすくなります。 さらに、分析する際に実行するクエリも単純になります。一方でデータの変更対応には多くの時間やコストがかかります。 DWH層だけでなく、データマートの層においてもディメンショナルモデルが使われることが多いです。 これまで使用されてきた2つのデータモデリング手法には初期構築やデータの追加に多くの時間が取られるという課題があります。 データを使って意思決定を行いたいユーザは、分析基盤に変化するビジネスロジックに対する迅速な対応を期待します。 迅速で柔軟な対応のためには、リリースサイクルが短い方が利点があります。 柔軟性に欠けるという課題に対して、近年ではDataVaultと呼ばれるモデリング手法が注目されてきています。 DataVaultとは何か? DataVaultデータモデリングは、2000年頃にDan Linstedt氏が提唱したデータモデリング手法で現在では、進化を遂げてDataVault2.0(DV2.0)と呼ばれています。 DV2.0に基づいて作られたテーブルは、キー情報・テーブル間の関係情報・属性情報をそれぞれ格納する3つのテーブルに分割されます。 データを3つのテーブルに分離したことで、ビジネスロジックの変更に伴うデータの追加のような変化に対する柔軟さと俊敏さを手にしています。テーブルには一部の例外を除きデータをインサートするだけなので、データを履歴化して持つことができます。 さらに、特定の日付のデータを取得することが可能なことから監査の面でもメリットがあります。 データを分離しているという点ではディメンショナルモデリングと似ている部分もありますが、DV2.0では、テーブル間の関係情報も別テーブルで管理している点が、ディメンショナルモデリングとは異なっています。 DV2.0に基づいて作成される特徴的な3つのテーブルを紹介していきます。 Hub Hubテーブルはビジネスにおける中心となる実体・存在(エンティティ)を表現します。 Hubテーブルにはビジネスキーが格納されています。ビジネスキーは、エンティティをユニークにするキーのことを指します。ナチュラルキーとも呼ばれます。Hubテーブルに含まれるビジネスキーはビジネスの中心となるものなので、不変ないしは、ほぼ変化しないものが選ばれます。 テーブルを構成する要素は、ビジネスキーとそのhash key、さらにデータをロードした日付(or 日時)とどのデータソースからデータが来たかを示すカラムで構成されます。どのデータソースからデータが来ているかというカラムをRecord Sourceと呼び、元テーブルの名前やシステム自体の名前を格納します。 dbtvaultというdbtのパッケージのドキュメントでは、Record Sourceには元テーブルの名前を格納しています。 最後に簡単なテーブル構造の例を挙げておきます。 column type example product_pk binary 27634ff8002b12e75d98e07ccd005d18 product_name varchar Water loaded_on date 2022-12-01 record_source varchar products Link Linkテーブルの役割は全てのテーブル間の関係を表現することです。 テーブル構成は関係する2つのテーブルのhash keyと2つのテーブルのビジネスキーをconcatしてhash化したキーとHubテーブル同様にロードした日付とRecord Sourceで構成されます。 テーブルの構成は以下のようになります。 column type example order_product_pk binary 6fd0207c2d9ce3dcaddf870e96721a4b order_pk binary c4ca4238a0b923820dcc509a6f75849b product_pk binary 27634ff8002b12e75d98e07ccd005d18 loaded_on date 2022-12-01 record_source varchar orders Satellite Satelliteテーブルには、対象のエンティティの全ての属性情報が格納されます。 具体的には、商品というエンティティがあれば、値段や製造日のようなデータが格納されます。Satelliteテーブルはビジネスキーのhash keyとロードされた日付(日時)を主キーとします。 テーブルの構成は以下のようになります。 column type example product_pk binary 27634ff8002b12e75d98e07ccd005d18 hashdiff binary 1e6e0a04d20f50967c64dac2d639a577 price number 100 loaded_on date 2022-12-01 record_source varchar products Satelliteテーブルの特徴的なカラムは上記図にもあるhashdiffです。hashdiffカラムは属性情報を全てconcatしhash化した値です。 hashdiffの生成には全ての属性情報を使うため、属性情報に変更があった場合、hashdiffの値は変化します。 全ての属性情報のカラムを見るのではなく、hashdiffカラムだけを見ればよいため変更の検知が容易になります。 上図で示した例は属性情報のカラムが一つだけですが、属性情報が大量にあるエンティティを扱う可能性もあります。属性情報が大量にある場合、データの種類や変更頻度などでSatelliteテーブルを分割することも可能です。 Hub/Link/Satelliteテーブルの関係性を図にすると以下のようになります。 RawVaultの例 モデリングにおける注意点 DV2.0モデリングを進めていく際は、ビジネスの中心となるエンティティを最初に定義する必要があります。 なので今回紹介したHub > Link > Satelliteの順番でモデリングしていくことが推奨されます。 また、Hub/Link/Satelliteの3つのテーブルをまとめてRawVaultとも呼びます。 今回紹介したテーブル例ですとソースシステムのテーブルをただ3つのテーブルに分割しているだけですが、モデリングする際にソースシステムのテーブルのカラムを単純にHub/Link/Satelliteに分割することは良い手段とは言えません。 DataVaultを提唱したDan Linstedt氏曰く(元のブログポストはすでに消えてしまっているようです...) "Data vault modeling was, is, and always will be ABOUT THE BUSINESS. And if the Data Vault you have in place today is not currently about the business, then unfortunately you've hired the wrong people, and those people need to go back to school and relearn what Data Vault really means. Or you've build the wrong solution, and you need to fix it-immediately." と言っています。 ざっくりいうと、DataVaultモデリングは常にビジネスに関わるものでなければいけないということです。 ビジネスロジックなどを考えずにソースシステムのデータをそのままDataVault風に分割するのは適当とは言えません。 ここまで、DataVaultを構成するテーブルについて簡単に紹介させていただきました。DataVaultのメリットの片鱗は少し見えてきたかもしれませんが、次の章でDataVaultの優れている点をまとめていきます。 さらに、構築する上で課題となる点も紹介していきます DataVaultの優れている点と課題 DataVaultモデリングの優れている点はいくつかあると思いますが、個人的に他のモデリング手法よりも優れていると思われる点を3点ほど紹介させていただきます。 DataVaultの優れている点 監査能力の高さ DataVaultモデリングで作成されたテーブルにはインサートしかしません。(一部例外はありますが...) よって、過去の指定の時点のデータの状態を保持することが可能になります。インサートしかしないため、データの履歴化も可能になっています。 取得するデータが増える場合のような変更に対する柔軟性の高さ DV2.0モデリングに基づいて作られたテーブルはHub/Link/Satelliteに分割されています。 新規に追加するデータが、既に作成しているHubの属性情報であれば、Satelliteテーブルを作成するだけでデータ追加の対応が完了します。既にあるテーブル自体を拡張したりする場合と比べると考慮しないといけない点が減っています。 短いリリースサイクルでDWHを更新することの容易さ テーブルの設計方針が明確なため、新しいデータを取り込むことが他のモデリング手法と比べると容易なため変更へのコストが低くなります。そのため短い開発サイクルでリリースをすることが可能になります。そのため、ユーザー(データを使って意思決定をしたい人たち)が望んでいるビジネスロジックの変更に対する迅速な対応が実現できます。 紹介した以外にも、まだまだDV2.0の優れている点はあると思います。 一方で、残念ながらDV2.0にも課題があります。 DataVaultの課題点 クエリがJOINだらけになる 1つのエンティティから最低でも3つのテーブルが作成されるため、3NFやディメンショナルモデルと比べてテーブルが多くなります。 2つのエンティティ、例えば注文と商品というエンティティがあるとすると、商品情報と注文情報の両方を取得するには、以下のようなSQLを書く必要があります。 select order_name, product_name, order_created_at, price from hub_orders ho inner join link_order_products lop on ho.order_hk = lop.order_hk inner join hub_products hp on hp.product_hk = lop.product_hk inner join sat_orders so on so.order_hk = ho.order_hk inner join sat_products sp on hp.product_hk = sp.product_hk where sat_orders.loaded_at = ( select max(loaded_at) from sat_orders so2 where so.order_hk = so2.order_hk ) and sat_products.loaded_at = ( select max(loaded_at) from sat_products sp2 where sp.product_hk = sp.product_hk ) 上記のようなJOINだらけのクエリが生成されてしまい、可読性が高くありません。 なので、今回紹介したHub/Link/Satelliteテーブルだけを使って分析するのはクエリ自体は単純ですが、記述がかなり大変になります。 JOINが多くなってしまう課題への対処方法の一つはBridgeテーブルを作成することです。BridgeテーブルはHub/Link/Satelliteの各要素を統合してまとめたテーブルになります。 つまり、分析する際に毎回実行するようなデータの統合処理は先にやってしまおうという考え方です。 また、1つのHubに複数のSatelliteが付随している際に、それぞれのSatelliteテーブルの任意の時点のデータを抽出するというクエリも複雑になります。 この課題に対しては、PIT(Point In Time)テーブルの作成をすることが有効な手段と言えます。 データの統合や特定の期間のデータだけを取り出すような、ビジネスロジックの追加やデータを解釈する必要がある場合は、RawVaultとは別のテーブルを作成すると問題を解消できます。 Bridge TableやPIT TableのようなBusiness Vaultについての紹介は第3回でさせていただければと思います。 初期構築時に「正しく」Hubを設計することが簡単ではない 元のデータソースのテーブルをHub/Link/Satelliteに分けるだけで、見た目的にはRawVaultは構築できます。 DV2.0はビジネスに関するものであるという考え方からすると、単純にソーステーブルのデータを3つのテーブルに分割することは、必ずしも良い手段とは言えません。 DV2.0は、カラムの追加や取り込むシステムに対する柔軟性は高いですが、柔軟性が高いと言える状態にするためには、設計原理に基づいてRawVaultを設計する必要があります。 一見簡単に構築できそうですが、ビジネス理解やドメイン知識の理解がないとダメで、要求される知識が多く、初期構築が難しくなると思います。 設計・構築の難しさはモブプログラミングのような形式のモブモデリングである程度対処できるかもしれません。 まとめ/次回予告 本記事では、DataVaultモデリングに関する投稿の第1回として、モデリングの特徴や構築されるテーブルについて簡単に紹介させていただきました。 今回紹介したHub/Link/Satelliteがどんなカラムを持っているか最後に振り返っておきます。 Hub ビジネスキー/ナチュラルキーのhash化した値 ビジネスキー/ナチュラルキー ロードした日時/日付 元ソースの名称 Link Hubのビジネスキー/ナチュラルキーをconcatしてhash化した値 Hubのhash key その1 Hubのhash key その2 ロードした日時/日付 元ソースの名称 Satellite ビジネスキー/ナチュラルキーのhash化した値 属性情報を全てconcatしてhash化した値 属性情報(価格や登録日など) ロードした日時/日付 元ソースの名称 次回の記事では、これら3つのテーブルをdbtvaultというdbtのパッケージを使って構築する方法や実際に構築する際に困った点などについて紹介できたらと思います。 最後に、本記事を書くにあたり様々な書籍・ブログポスト・登壇資料などを参考にさせていただきました。より詳しい内容を知りたいという方はぜひ参考資料を見てみてください。 参考資料 Building a Scalable Data Warehouse with Data Vault 2.0 The Elephant in the Fridge: Guided Steps to Data Vault Success through Building Business-Centered Models The Data Vault Guru: a pragmatic guide on building a data vault Data Vault as a Modeling Concept for the Data Warehouse dbtvault入門 DataVault2.0をご紹介

こんにちは。セーフィー株式会社エンジニアの伊藤です。 今回の話はややフロントエンドエンジニア向けの内容となるのですが、UI/UX に関わる話もありエンジニアの方でなくてもお楽しみいただける内容となっていると思います。気軽に読んでいただけると幸いです。 さて、突然ですが、エンジニアのみなさんはユーザーが入力した画像のうち特定の部分だけを切り出したいと思ったことはないでしょうか？セーフィーでは SafieEntrance2 という顔認証技術を使った入退場の管理システムの開発において、そんな場面に遭遇しました。 SafieEntrance2 の課題 良さげな画像切り出しライブラリ Cropperjs Croppie まとめ おまけ 画像切り出し Canvas API マウス操作による切り出し範囲の変更 タッチ操作による切り出し範囲の変更 終わりに SafieEntrance2 の課題 SafieEntrance2 とは顔認証技術を使った入退場の管理システムで、自分の顔を鍵代わりにしてドアを開けることができるサービスです。こちらのサービスをオフィスに導入すれば、うっかりデスクに社員証を置いたまま外に出てしまったら誰か来るまでドアの前でそわそわしながら待たねばならない、という全ての社会人が抱えている悩みが過去のものとなります。気になった方はこちらの リンク を会社の偉い方に共有してあげてください。 SafieEntrance2 ではユーザーが利用登録するときに Web アプリ上で顔画像を登録します。この時にある程度の大きさでしっかりと正面を向いて顔が写っていないと顔認証の精度が落ちてしまいます。こちらとしては、免許証やパスポートの証明写真のように、ばっちり正面を向いた写真を登録してほしいのですが、何も意識せずに自撮りした写真は、引きで撮影されて顔が小さく映っていたり、写真の中に余計なものが映り込んでいたりします。また画像はスマホで撮影されるパターンが多く、そのままだと解像度が大きすぎるといった問題もありました。 さて、この課題を解決するために、下の図のように登録時に画像の上にガイド用の線を重ねて表示することで、観光地で顔はめパネルを見つけたらどうしても写真が撮りたくなる心理をつつき、顔認証に適した画像を登録させることにしました。 実際の手順は下記の通りで、顔写真の画像を撮影または選択した後に、PCの場合はマウス操作で、スマートフォンの場合はスワイプ・ピンチ操作で、ちょうどよい場所までユーザーの手で画像を移動してもらい、そこだけ切り出して顔写真を登録するという流れです。 ここでまさに画像の特定の範囲だけを切り出すという処理を実装する必要がありました。 良さげな画像切り出しライブラリ というわけで、上記のような機能を実装するにあたって、良さげなライブラリを探します。 Cropperjs とりあえず一番有名そうなのが cropperjs でした。実際の動作はリンク先のサンプルを動かすとわかりやすいと思います。 https://fengyuanchen.github.io/cropperjs/ こちらは画像の中から切り出したい範囲をボックスを動かして指定するという方法になります。よく見かける UI ではありますが、今回やりたいのとはちょっと違います。ただでさえ小さなスマホの画面の上で、小さく写った顔をなぞるようにしてボックスを指定するという形になるので、細かい指先の操作が要求されそうです。顔はめパネルに自ら顔をあてに行くというよりは、自分の顔の所に顔はめパネルの方を動かして持ってくるという感じです。というわけでこちらのライブラリは使いませんでした。 Croppie 続いて使えそうなのが Croppie でした。こちらもリンク先のサンプルを動かしていただくと実際の動作がわかりやすいです。 https://foliotek.github.io/Croppie/ こちらの方は切り出す範囲は動かずに、後ろに写った画像の方が動くというスタイルの UI になっております。目指したかったのはこちらの動きに近いです。しかもいろいろ機能もあってかゆいところにも手が届きそうです。 まとめ 今回は画像を切り出したいときに使える良さげなライブラリの紹介でした。世の中には便利なものがたくさんありますね。ただ、この内容だとフロントエンドエンジニア以外の人にとっては何にも面白くないので、こちらの技術を応用して顔はめパネルアプリを作ってみました。 顔はめパネル こんな感じの顔ハメ写真が作れます！ 以上、現場からでした。 おまけ ちなみに実際はどうしたかというと、今回紹介したライブラリは利用せずに、全て自前での実装となりました。というのも、細かい動きを実現しようとしたときにライブラリが対応しておらず、やりたいことが実現できなさそうだったのです。ここからはライブラリを使わずに Croppie 的な動きを再現するにはどうすればよいのか、興味のある人だけ続きを読んでみてください。 まずは見本となるシンプルなアプリを用意しましたので、実際に動作を確認しつつ、デベロッパーツールでコードを見ながら読み進めると良いと思います。 https://safiepublic.github.io/kaohame/image.html 画像切り出し Canvas API 画像切り出しには Canvas の drawImage が使えます。 https://developer.mozilla.org/en-US/docs/Web/API/CanvasRenderingContext2D/drawImage ctx.drawImage(image, sx, sy, sWidth, sHeight, dx, dy, dWidth, dHeight) こちらの API は、図が示すように画像の切り出したい範囲を引数の sx, sy, sWidth, sHeight で指定するだけのシンプルなものとなっています。各パラメータをユーザーの操作に合わせていかに更新していくかがポイントとなります。 sx, sy はどこから切り出すかのパラメータなので、マウスドラッグやタッチ操作の動きにあわせて良しなに更新すれば良さそうです。sWidth, sHeight はどれだけの範囲を切り出すかを指定するパラメータですが、最終的に切り出した画像のアスペクト比（画像の縦と横の比率）は固定する方針とするので、拡大率を scale としてひとつだけパラメータを持っておけばよいです。というわけで下記の値をグローバル変数として持っておきます。 let sx = 0 let sy = 0 let scale = 1 描画先では Canvas の全領域に描画することになるので、dx, dy はゼロで、dWidth, dHeight は描画先の Canvas のサイズで固定できます。 const dx = 0 const dy = 0 const dWidth = 500 const dHeight = 500 このように定義すると sWidth, sHeight は scale を使って下記のようにあらわすことができます。 const sWidth = dWidth / scale const sHeight = dHeight / scale こちらについては下の図を見てもらえるとわかりやすいかと思います。下図のように拡大率 (scale) が大きくなればなるほど切り出す範囲を狭くしていく必要があるため、数式の分母の方に scale が来ています。逆に scale が小さくなると、切り出し範囲は広くなり、より全体を見渡せる画像が結果として得られます。scale はマウスホイール操作やタッチのピンチ操作にあわせて更新することで、よくある画像ビューワーの UI を再現できます。 なんだかんだ描画している部分のコードは下記のような感じでとてもシンプルに書けます。 function draw() { const ctx = canvas.getContext( '2d' ) ctx.fillStyle = 'rgb(0, 0, 0)' ctx.fillRect(0, 0, canvas.width, canvas.height) const sWidth = dWidth / scale const sHeight = dHeight / scale ctx.drawImage(srcImage, sx, sy, sWidth, sHeight, dx, dy, dWidth, dHeight) } マウス操作による切り出し範囲の変更 続いてマウス操作で切り出す位置を更新しているコードを見ていきます。 切り出し位置 (sx, sy) の変更はマウスドラッグで行いますので、ドラッグ中かどうかを示すフラグを変数 (isMouseDown) として保持してする必要があります。またマウスの移動量を知る必要があるので、マウスの位置もグローバル変数として持っておきます。 let isMouseDown = false let mousePosX = null let mousePosY = null マウスイベントの mousedown, mouseup, mouseleave を拾って、isMouseDown フラグを On/Off を操作します。また mousedown のタイミングではマウスがクリックされた位置を記憶しておきます。 canvas.addEventListener( 'mousedown' , (e) => { isMouseDown = true mousePosX = e.offsetX mousePosY = e.offsetY } ) canvas.addEventListener( 'mouseup' , (e) => { isMouseDown = false } ) canvas.addEventListener( 'mouseleave' , (e) => { isMouseDown = false } ) mousemove ではドラッグ中の場合のみ、sx, sy を更新しますが、この時、画面上のマウスの移動量をそのまま sx, sy に反映させるのではなく、拡大率に応じて画面上の移動量を入力画像上の移動量に換算するところがポイントです。 canvas.addEventListener( 'mousemove' , (e) => { const newMousePosX = e.offsetX const newMousePosY = e.offsetY if (isMouseDown) { const mouseDiffX = mousePosX - newMousePosX const mouseDiffY = mousePosY - newMousePosY const canvasDiffX = mouseDiffX / canvas.clientWidth * dWidth const canvasDiffY = mouseDiffY / canvas.clientHeight * dHeight const imageDiffX = canvasDiffX / scale const imageDiffY = canvasDiffY / scale const newSx = sx + imageDiffX const newSy = sy + imageDiffY sx = Math.min(Math.max(newSx, 0), maxSx()) sy = Math.min(Math.max(newSy, 0), maxSy()) draw() } mousePosX = newMousePosX mousePosY = newMousePosY } ) 例えば、マウスが画面上を 100px 動いたとしても、倍率２倍で表示されていた場合、入力画像上では 50px (= 10 / 2) しか動いていません。 このように拡大率に応じて移動量を調整しないと、拡大時はマウス操作よりも大きく画像が動いてすべったような挙動になり、逆に縮小時はドラッグしてもなかなか画像が移動しないということになってしまいます。これを補正しているのが上記の処理です。 次はマウスホイール操作による拡大＆縮小のコードです。 canvas.addEventListener( 'mousewheel' , (e) => { e.preventDefault() const prevScale = scale const newScale = e.deltaY > 0 ? scale * 0.95 : scale * 1.05 scale = Math.max(newScale, minScale()) const focusX = mousePosX / canvas.clientWidth * dWidth const focusY = mousePosY / canvas.clientHeight * dHeight const newSx = sx + focusX * (1 / prevScale - 1 / scale) const newSy = sy + focusY * (1 / prevScale - 1 / scale) sx = Math.min(Math.max(newSx, 0), maxSx()) sy = Math.min(Math.max(newSy, 0), maxSy()) draw() } ) ホイールの操作に合わせて scale を更新すればよいのですが、コードを見ると同時に sx, sy も更新しています。これはマウスカーソルがある位置にフォーカスしてズームを行いたいからです。こちらも下の図を見てもらうとわかりやすいと思いますが、マウスポインタが指している位置を動かさずに拡大＆縮小を行おうとすると、切り出しの開始位置の座標である sx, sy も一緒に動かす必要があるのです。 マウスポインタがある位置の画像上の座標(imagePosX, imagePosY) を数式で表すと次のようになります。 imagePosX = sx + mousePosX / scale imagePosY = sy + mousePosY / scale ここで、拡大の前後でマウスポインタの指している位置が変わらないように sx, sy を調整するので、拡大前のsx, sy, scale を prevSx, prevSy, prevScale とし、拡大後の sx, sy, scale を newSx, newSy, newScale とすると、拡大の前後で次の式が成り立ちます。 prevSx + mousePosX / prevScale = newSx + mousePosX / newScale prevSy + mousePosY / prevScale = newSy + mousePosY / newScale こちらの式を newSx, newSy について解くと次のようになり、補正後の位置が求まります。 newSx = prevSx - mousePosX * ( 1 / prevScale - 1 / newScale ) newSy = prevSy - mousePosY * ( 1 / prevScale - 1 / newScale ) サンプルのソースコードでは Canvas 上の位置の補正も入っているので上記の式とはちょっと違うのですが大体こんな感じです。ちなみに Croppie はこのあたりの処理がややあまく、拡大＆縮小は常に画像の中心にフォーカスして行われるようになっていました。 タッチ操作による切り出し範囲の変更 スマホの場合はタッチ操作になるので、タッチイベントを拾って処理することになります。少し長いのでちょっとずつ見ていくことにします。 touchmove イベントでタッチした点の座標を配列で受け取ることができます。ただし、取得できる座標は canvas 上の座標ではなくウィンドウ全体の座標となっているので、canvas の位置を差し引いて、canvas 上の座標に変換します。 // タッチの位置を計算する const canvasRect = canvas.getClientRects() [ 0 ] const newTouches = [] for ( let i = 0; e.touches.length > i; ++i) { newTouches.push( { x: e.touches [ i ] .clientX - canvasRect.left, y: e.touches [ i ] .clientY - canvasRect. top , } ) } 続いて画像の移動処理ですが、２本以上の指で操作されることもあるので、戦略としては全てのタッチ点の平均位置を計算して、平均位置の移動量を画像の移動量とすることにしています。これによって２本指以上でも操作が可能です。処理のはじめにタッチ点の数が違う場合に処理を中断している理由は、途中でタッチの点数がかわることによって、平均位置が急激に変化して画像が一瞬で大きく動くということを防ぐためです。 // タッチ数が異なる場合はタッチの位置だけ記憶してリターン if (touches.length !== newTouches.length) { touches = newTouches return } // 全てのタッチの平均位置を計算する const prevTouchMeanPos = { x:0, y:0 } const newTouchMeanPos = { x:0, y:0 } for ( let i = 0; touches.length > i; ++i) { prevTouchMeanPos.x += touches [ i ] .x prevTouchMeanPos.y += touches [ i ] .y newTouchMeanPos.x += newTouches [ i ] .x newTouchMeanPos.y += newTouches [ i ] .y } prevTouchMeanPos.x /= touches.length prevTouchMeanPos.y /= touches.length newTouchMeanPos.x /= newTouches.length newTouchMeanPos.y /= newTouches.length // 全てのタッチの平均位置が動いた距離を視点の移動量とする const touchDiffX = prevTouchMeanPos.x - newTouchMeanPos.x const touchDiffY = prevTouchMeanPos.y - newTouchMeanPos.y const canvasDiffX = touchDiffX / canvas.clientWidth * dWidth const canvasDiffY = touchDiffY / canvas.clientHeight * dHeight const imageDiffX = canvasDiffX / scale const imageDiffY = canvasDiffY / scale let newSx = sx + imageDiffX let newSy = sy + imageDiffY タッチが２点以上の場合は同時に拡大＆縮小も行います。こちらの戦略としては、全てのタッチのうち最も離れた２点の距離の変化を拡大率の変化量とすることにします。これにより３本以上の指で操作されたとしてもピンチ操作ができます。またこの時に２点間の中心の位置にフォーカスして拡大＆縮小するように sx, sy も更新しており、注目しているポイントに寄っていく動きが実現できます。 // 2 点タッチ以上の場合、拡大縮小も行う if (touches.length >= 2) { // 全てのタッチのうち最も離れた２点の距離の変化を拡大率の変化量とする let prevMaxDistance = 0 for ( let i = 0; touches.length > i; ++i) { for ( let j = i+1; touches.length > j; ++j) { const p1 = touches [ i ] const p2 = touches [ j ] prevMaxDistance = Math.max(prevMaxDistance, calcDistance(p1, p2)) } } let newMaxDistance = 0 for ( let i = 0; newTouches.length > i; ++i) { for ( let j = i+1; newTouches.length > j; ++j) { const p1 = newTouches [ i ] const p2 = newTouches [ j ] newMaxDistance = Math.max(newMaxDistance, calcDistance(p1, p2)) } } const prevScale = scale const newScale = scale * newMaxDistance / prevMaxDistance scale = Math.max(newScale, minScale()) // スケールの変化に合わせて画像の位置更新 const focusX = prevTouchMeanPos.x / canvas.clientWidth * dWidth const focusY = prevTouchMeanPos.y / canvas.clientHeight * dHeight newSx += focusX * (1 / prevScale - 1 / scale) newSy += focusY * (1 / prevScale - 1 / scale) } ちなみに Croppie はタッチ処理で少し雑な部分がありました。ソースコードを覗いた感じですと、タッチ点を 2 点以上検知した場合は拡大＆縮小のみを行う動きとなっており、ピンチ操作しながら移動することができません。またピンチ操作の時に配列の最初の 2 点を使ってスケールを計算しており、3 本以上の指で操作した時に思った通りに動かないことがあります。 https://github.com/Foliotek/Croppie/blob/master/croppie.js 終わりに 長くなりましたが、以上が処理の全容になります。 今回お話ししたような内容は、OS に標準で入っているような画像ビューワーでも当たり前のように実装されている処理でもありますし、Photoshop のような画像編集ツールや draw.io や figma 等のドローイングツールを作ろうとしたときにも必要な処理となります。案外身近なところで出くわすものですが、ちゃんとした解説を見かけたことがなかったので、様々ある実装方法のひとつとしてみなさんの参考になれば幸いです。 最後までお付き合いいただきありがとうございました。

この記事は Safie Engineers’ Blog! Advent Calendar 2022 22日目の記事です。 こんにちは，あるいはこんばんわ 第1開発部QCDグループ 小山と申します。 アドベントカレンダーへの投稿に声がけいただけましたので 今回はQCDグループとしては”初”の投稿となりますので よく聞かれるQCDグループって何しているのという点と これからやりたいこと，目指したいことを紹介させていただきます。 一緒に開発に加わっている方にはほ～～んという内容なのは恐縮です。 QCDグループについて チーム名は分かった，でもQCDって何しているの？ テスト業務ってなにしてるの？ テスト計画書とテスト仕様書について テスト計画書とは テスト仕様書とは 次回予告 最後に QCDグループについて QCDグループのQCDとは”Quality（品質）、Cost（コスト）、Delivery（納期）”を 示しています。 本当はQCD”M（マネジメント）”がついていたのですが 組織編成の中で失われた文字に・・・ ただQCDグループのメンバーとしては ”QCDをマネージメントするグループ”の一員 ということを意識したうえで日々のQA（品質保証）業務に取り組んでいます。 チーム名は分かった，でもQCDって何しているの？ QCD（社内ではQAチームと言われたり）は 製品のソフトに関する”品質保証”を行っています。 品質保証といっても様々な活動があると思いますが 現在はソフトのテストを通してお客様へ提供することができる/ 満足していただける クオリティになっているか確認することが”現在の”主な日々の業務となっています。 前職などでテスト業務を中心に活動する組織に在籍されていた方や 社内でも営業よりの方からすると QCDってグループははテストだけを行っているの？と思われがちですが 他にも品質を向上させるために行っていることはあります。 ただ一旦，イメージのしやすいテスト業務に焦点を当てて，つらつら書かせていただけます。 テスト業務ってなにしてるの？ テスト業務ってテストを作る？実施する？イメージがつきづらい と思われるかもしれませんが，テストケースの作成から終了報告までは 意外と道のりがあります。 　　1,要件定義の確認，仕様把握 　　2,テスト計画（テスト計画書）の作成 　　3,テスト詳細仕様書（テストマップ）の作成 　　4,グループ内レビュー 　　5,開発メンバーとのレビューと確認    　　～ここからテスト期間（約2週間）～ 　　6,テストの実施（リグレッションテスト含む） 　　7,不具合報告 　　8,修正されたチケットの修正確認 　　9,上記の対応終了後，終了報告    　　　～テスト終了報告→次の製品開発スタートまで（約2週間） 　　10,追加，修正仕様のリグレッションテストへの反映 　　11,不具合分析とフィードバック 　　12,自動テストのメンテナンス 担当者ごとに粒度や形式の違いはありますが 概ね上記の活動を2名～3名で分担して行っております。 期間は定期的にリリースしているプロダクトなら 2週間前後，新規開発のものはそれ以上の期間で 市場に出せるか否か，セーフィーの製品としてふさわしい品質か否か を確認しています 中々聞かない言葉としては， テスト計画書とテスト仕様書でしょうか テスト計画書とテスト仕様書について テスト計画書とは 実施するテストの目的・方向性、スケジュール、体制などの要件を整理し、まとめるドキュメント その他にも実際のテストで想定される不具合管理や、プロジェクトに関わるメンバー同士のコミュニケーション方法などについて具体的にまとめます 引用元 テスト計画書の役割・目的とは｜記載すべき要件や漏れを防ぐポイントを紹介！ | テクバン株式会社 過去PJのテスト計画書 弊社ではこのようなものを作成して プロジェクト側に展開しています。 テスト仕様書とは テストマップとは、テスト対象システムにおける設計単位（機能、画面、状態など）と、実施するテスト観点の対応表 引用元： テストマップとは？テストを俯瞰し、抜け漏れ防止やテストケース数のバランス調整を行おう【ソフトウェア開発・テスト用語 】| Qbook テストマップ 引用したテストマップからはアレンジはしていますが， 追加される機能に対し，どの端末で，どういった観点でテストを行うか をマトリクス表にして記載しています。 テスト粒度の確認+実装時の観点の抜け漏れに気づく機会を テスト期間前に設けて，テスト期間中の修正工数の削減を目指すものとなります。 とここまで書いてきましたが このままだとテストだけやっている部署だと思われてしまう可能性があることに 気づいたため，テスト以外の業務についてもざっくり追記します 要件定義段階からPJへ参加し仕様策定時から 考慮漏れや改善案を提案する テスト実施中ではなく 動的に検証を行う前の段階で 他プロダクトへの影響や問題が発生してしまう点などを 指摘し解決できるような仕様を提案する 開発期間中にでたチケットを分析し，フィードバックを行う とこんなことも実はやっています （自分が十分にやれているかといえば疑問ですがorz） 上記のようにテストを行って品質を担保する業務以外でも プロダクトの品質を向上できる取り組みを行っている/行おうとしているのが セーフィーのQCD（M）グループとなります。 テストだけやっているのではなく テストも含めそれ以外でも積極的に関わっています。 セーフィーとしていいものを世の中に出すために 提案や小言を言っているんだな  期間通りにリリースできるようにしっかり計画だてて 品質を保証するための行動を行ってくれているんだなと 認識いただけますと幸いです。 また次回以降に書きたいな/書ければな と思っている お題目を先に宣言させていただきます 次回予告 リリース判定会って何やっているの テスト管理ツールの導入まで 品質基準の策定について 全社にまたがる品質向上への取り組み AIの品質保証 セーフィーのQAエンジニアってどんなことができる人 BitriseとMagicpodを連携させて見た結果，○○に！ 最後に 品質に携わる業務を行っているものとしては お客様に私たちの存在を意識されないことがいい（意識される＝バグ，不具合がある） と思っています。 同じプロダクトにかかわる人たちからは ”QCD”の人たちがいないと困る，いるとなんか開発が上手くいくよね と思われる存在，部署として認知されてたいです。 もちろんAIに関する品質保証等はまだ確立されていない領域なので そういったところで自分たちなりのやり方や挑戦したこと というのはゆくゆく発信していきたいです。 またQAエンジニアからプロジェクトマネージャー等の 新領域に挑戦する人をグループからも輩出したいと思っています。 （これは僕もやってみたい） まだまだ日々の業務に追われてしまっていて そういった挑戦に手を付けられていないので これから取り組んでいきたいと思います。 以上となります， セーフィーのQAエンジニアという仕事について ざっくり知っていただけると嬉しいです！ ありがとうございました。 みなさん，よいクリスマスを！！（ケンタッキー食べたいですね。）

この記事は Safie Engineers' Blog! Advent Calendar 2022 16日目の記事です。 こんにちは、開発本部 モバイルグループの池田です。 2016年入社以来、セーフィーのWebフロントエンドやモバイルアプリの開発に関わり、近年は Safie Viewer for Mobile ( iOS , Android )の開発チームリーダーとして、そして今年の5月ごろからは同プロダクトのPdM（プロダクトマネージャ）という立場でも活動しています。 この記事では、エンジニア出身のPdMがセーフィーのモバイル開発においてどのような取り組みをして、またどんな課題に直面していたのかを振り返ってみたいと思います。 セーフィーにおけるPdMの役割 B2B SaaSとモバイルアプリとPdM 今年の主な活動とアウトプット デザイナーとのチーム組成とFigma導入 VoC収集 ユーザーテスト UX改善リリース Map Viewerデモアプリ作成とPoC（進行中） まとめと課題 おわりに セーフィーにおけるPdMの役割 執行役員の植松さんと及川卓也さんの対談記事などでも触れられているように、セーフィーには多様なプロダクトが存在し、それぞれの開発プロジェクトやフェーズによってPdMの関わり方もさまざまです。 www.kandc.com セーフィーではターゲット業界ごとに区切られたビジネスユニットと呼ばれる各組織にプロダクト企画チームが散在しつつ、PdMオフィスというバーチャル組織としてPdM全員での情報共有を行っています。 私も開発組織に身を置きつつこちらにも所属させてもらい、メンバー育成のための座談会などにも参加するなど、ずっとエンジニアだけでやってきた身としては多くの刺激と学びがありました。 note.com そのようなPdM組織と開発チームを行き来しつつ、Safie Viewer for Mobile のプロダクトマネジメントを行なっていきます。 具体的には、機能開発の優先度設定、ユーザーニーズ調査、ロードマップ作成、技術的意思決定、開発進捗管理、品質と納期のマネジメント等々ですが、人によってはPdMの領域では無いと感じるものが含まれているかもしれません。 現時点で、私は開発チームも持ちながらPdMをやらせてもらっているため、 モノタロウさんの記事 にあった PdM兼任EM という動き方を意識しています。 tech-blog.monotaro.com 当初、CTO森本からモバイルのPdMどうですか、という話を受けたときには、 「まぁプロジェクト内にPM(Project Manager)もおるし、やることそんな変わらんやろ」 と軽く考えていましたが、PdMというものについて調べるほどにそこに求められる能力、資質におののくばかりでした。 https://ninjinkun.hatenablog.com/entry/the-product-management-triangle-ja PdMについてぐぐると必ず出てくる三角形。これらをバランス良く備えることがPdMには求められるそうです。 もちろん自分はそんなスーパーマンではないので、そこはチームの力をしっかり頼ろうと思いつつ、 現時点で自分としては、PdMとは「 プロダクトの方向性を示し、その成長に責任を持つ人 」という捉え方をしています。 B2B SaaSとモバイルアプリとPdM セーフィーはクラウド映像プラットフォームを提供しており、その大多数のユーザーは企業内での業務において、いわゆる B2B SaaS としてセーフィーのwebやアプリを利用しています。 さまざまな業界にその利用が広がっているセーフィーでは、カメラを1台だけ設置している個人ユーザーから、数百台のカメラが見えるチェーン店の管理者まで幅広いユーザーがサービスを利用しており、利用されるカメラデバイスのモデルも数百種類といった規模になってきています。 モバイルのシンプルさを保ちつつ、いかに多様なカメラ機能を利用するか、そのためにどういう取捨選択をするか、という課題は常に悩ましい問題です。 またB2B SaaSという点では、つい先日「 SaaSの解約理由の半数超が『操作性が良くない』 」というニュースがありましたが、企業向けSaaSにおいてこそ使い勝手は非常に重要です。 凝ったUIよりも、最速で見たいカメラ、見たい映像に辿り着けるわかりやすさと快適さがないと、あっさりと競合にその座を渡してしまうことになります。 またこれも（おそらく）B2Bあるあるとして、案件の多くが「 とりあえずPCで 」実現することのみを考えており、モバイルは後付けで話がやってくることが多いです。 そのあたりも社内外のステークホルダーとうまく連携し、「最初から」モバイルはどうあるべきかを一緒に考えていけるように、自分とチームのプレゼンスを上げていく必要もあると感じています。 ところでモバイルに関わるエンジニアであれば、 「シンプルでモダンで洒落たUIで、手触りがよくて驚きがあってユーザーに愛される、毎日思わず起動したくなるアプリ」 を、つくりたいと思う方は多いのではないでしょうか。少なくとも私はそう思います。 しかしながら、セーフィーが提供するサービスは（業務効率化やマーケティングにその用途が広がってきているとはいえ）やはりまず第一に「防犯・監視」、すなわち安心・安全を得ることにその目的があります。 設置した防犯カメラをアプリで毎日チェックするより、「今日も問題ありませんでした」「昨夜2:00の映像だけ確認が必要です」と、端的に教えてもらえるならその方がいいですよね。 企業生産性に寄与するB2B SaaSにおいては、アプリ利用時間やエンゲージメント率といったメトリクスが大きいことが単純に良いとは限らず、これもまた注意が必要です。 こういった多くの相反するニーズを理解し、プロダクトのビジョンすなわち「 誰の、どのような課題を解決するのか 」を示し、チームを実行に導くことが、PdMには求められます。（難しい。。。） 今年の主な活動とアウトプット PdMという立場ではなかった時期のものもありますが、モバイルアプリで今年行ったいくつかの活動・施策について振り返ってみます。 デザイナーとのチーム組成とFigma導入 1年ほど前、セーフィーのモバイル開発PJには専任のデザイナーがおらず、各案件から新規機能や画面の要件が発生すれば個別に画面案が出てくる、という状態でした。 これを「 開発チームと一緒にUX改善についてトライ＆エラーができるメンバーが欲しい 」と、新たにデザインセンターにアサインをお願いし、改めてチームビルディングを行いました。 デザイナーはエンジニアチームと共に毎朝のデイリーmtgやレトロスペクティブ（振り返り）にも参加いただくなど緊密に連携してもらい、 開発・デザイン・企画そしてQAメンバーも交えてUX改善について議論する定例を設定し、 新規・既存画面によらず「より使いやすい」「よりわかりやすい」UIを目指して課題と改善案を出す活動を続けています。 またその過程でデザインツールを Figma に移行しました。 それまで案件ごとの画面仕様は都度 Adobe XD で共有され、またもっと抽象的なUX議論においては Miro を使っていたりしたのですが、えいやと 全画面 をFigmaに移行していただきました。 工数的に迷ったところもあったのですが、結果的にこれは非常に良い選択でした。デザイナーの尽力のおかげでiOS/Androidそれぞれの画面仕様がすっきりと整理され、開発とデザイナーだけでなく、QAとのコミュニケーションも楽になりました。また、デザイナーとしてもトレンドトップになりつつあったツールの経験が得られたことは良かったようです。（その後のAdobeによる買収はビックリしましたが） Figma導入については以前にモバイルチームの渡部さんも記事を書いてくれています。 engineers.safie.link VoC収集 もっとモバイルのユーザーとユースケースを知ろう、ということであらためて社内外にヒアリングを行いました。 しかし結論から言うとこれはまだあまりうまく進んでいません。 ここで拾えた営業メンバーの声をもとにリリースした改善があったり、一部お客様から現場のモバイル/タブレット利用について聞けたりはしましたが、アナリティクスにあらわれる数字（webよりモバイルの方が多い）ほどには、まだその利用シーンやユースケースの分布が掴めていない状態です。 いくつかの仮説はありますが、ここについては来年度にかけて、今年新たに立ち上がったデータ分析チームやUXリサーチチームとも連携して、さらにモバイルユーザーの解像度を上げていきたいと考えています。 note.com ユーザーテスト 主に新入社員をターゲットに、アプリをまだ使ったことのない人にユーザーテストを不定期に開催しています。 ユーザーテスト体験中の新参メンバー 「XXというカメラを見つける」 「XXさんの出社した映像を見つける」 「XXさんが冷蔵庫を開けたシーンをクリップ保存してDLする」 など、こちらの用意したシナリオに沿ったミッションにチャレンジしてもらいます。 そのアプリを使う様子をまたSafie Pocket2で録画して、見えてきた使いにくさやわかりにくさの課題に対して、仮説と解決案をチケット化して少しずつ改善に含めていきました。 UX改善リリース 上記のような活動を通じてタスク化した改善を多数リリースしてきました。 設定画面など目立たないところでも「わかりやすい」「使いやすい」を意識した変更が多く含まれています。 この他にもいろいろいろいろ Map Viewerデモアプリ作成とPoC（進行中） Flutter を使って、最低限のマップ機能を持つデモアプリを作成しました。 GPS搭載ウェアラブルカメラであるSafie Pocket2の発売以来、Safie Viewer(Web)の位置情報連携（マップビューアー）が進化してきました。 先月にはついに GPS非搭載のカメラも手動で位置情報が設定できるように なり、その利用範囲はますます広がっています。 モバイルでもカメラのGPS情報からマップアプリを開くことはできますが、それ以上のマップ対応も当然進めたいと考えています。 しかし、 実際にモバイルでマップ表示や軌跡表示を行うニーズが不明確 現状のViewer開発と並列で追加実装しながらUIの検証はかなり重い そもそも工数がない といった課題があって足踏みしていたところ、 「じゃあFlutterでマルチプラットフォームの別アプリで最速MVP作って検証しよう」 と、半ば勢いで宣言したところもありますが、強いAndroidエンジニアがこの夏に参画してくれたこともあって、3週間ほどで見事に形にしてくれました。 開発中デモアプリ これもFigmaと同じく、チームにFlutterというトレンド技術の知見を取り入れられてその効果や課題が見えたのも良かったです。 まだ社内でFBを受けている（そしてその対応工数にふたたび苦慮している）段階ではありますが、来年には何らかの形にして世に出したいと考えています。 まとめと課題 他にも勉強会の定期開催や、CI/CDの拡充や、ここにはちょっと間に合わなかった少し大型のリニューアルなども進行中なのですが、一旦このへんで置くことにします。そのうちメンバーが書いてくれることも期待しつつ、来年はこういう発信をもっと細かくやっていきたいとも思いますね。 振り返ってみて感じる課題としては、 VoC収集の不足 1年を通して、既存画面・機能のボトムアップ的な改善はかなり進みました。が、ある新しい機能の実現を考えようとなったときに必要な取捨選択を決めるための指針（＝プロダクトビジョン）がまだ完全ではない、そのためにもっとユーザーの声を聞く必要はあると感じています データによる意思決定と検証 今もアナリティクスを追ってはいますが、もっと「これを出せばこう変わるはずだ」という仮説のもとにPDCAを回したり、何より最も需要なKPI（いわゆる North Star Metric ）をプロダクトビジョンと共に定義して、来期はプロダクトの成長を追っていきたいところです ビジネスビジョン 台数が増えるだけ売上に直結するカメラデバイスや、オプションの付加価値であるAI機能などと違って、Viewerフロントエンドは数字を直接意識しにくいところがあります。上のメトリクスの話にも繋がりますが、どの改善がどのようにビジネス的な価値を向上させるかについてもっとセンサーを張り、仮説構築と検証を行なっていきたいと感じます いろいろ書いては来ましたが、実際のところ「普通の開発PM」的な領域をなかなか超えられていないな、という焦りもあります。 これらの課題を打ち倒して前に進むために、来年も頑張って参りたいと思います。 おわりに モバイルアプリPdMとしての1年をざっくり振り返ってみました。 ユーザーの多様性やプロダクトの複雑性からPdMには難しい悩みがありますが、それゆえの面白さやサービスを育てるやりがいもあると思います。興味を持った方はぜひ下記をご覧ください。 現在セーフィー株式会社では、ソフトウェアエンジニアそしてプロダクトマネージャーを積極採用中です！ safie.co.jp

はじめに この記事は Safie Engineers' Blog! Advent Calendar 2022 23日目の記事です。 セーフィー株式会社 開発本部のソフトウェアエンジニア 斎藤です。 Safie のクラウド録画サービス の安定運用に寄与するべく、インフラ周りの構築・運用を主に担当しています。 今回は Amazon Aurora MySQL をバージョンアップグレード (5.6 -> 5.7) したお話です。 前回、私が執筆したブログ記事は GitHub Actions で小さな不便を解消してみた でした。約2年振りですね。 はじめに アップグレードする必要性 アップグレード手順候補案 インプレースアップグレード方式 レプリケーション && DNS 切り替え方式 検討する上での比較項目 実際に採用した手順 実際の作業イメージ 前提条件 step1 step2 step3 step4 step4 の詳細手順 万が一の rollback 手順 おわりに アップグレードする必要性 Preparing for Amazon Aurora MySQL-Compatible Edition version 1 end of life そもそも何故アップグレードするのかについては、上記記事の通りです。 Amazon Aurora MySQL バージョン 1(MySQL 5.6 互換) は、2023 年 2 月 28 日にサポートを終了する予定です。 そのため、Amazon Aurora MySQL バージョン 2(MySQL 5.7 互換) または Amazon Aurora MySQL バージョン 3 (MySQL 8.0 互換) にアップグレードする必要があります。 アップグレード手順候補案 インプレースアップグレード方式 https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/AuroraUserGuide/AuroraMySQL.Updates.MajorVersionUpgrade.html#AuroraMySQL.Upgrading.Sequence マネジメントコンソール もしくは (CLI/API) を使って簡単に 5.6 -> 5.7 へのアップグレードができます。 ただし、アップグレード中はクラスターエンドポイントに接続できないためダウンタイムが発生します。 ※弊社環境での事前検証だと約1時間でした。環境によってダウンタイム時間は前後します。 また、 rollback (切り戻し) したい場合、気軽に出来ないところがデメリットになります。 前バージョンのスナップショットからクラスターを復元するなど、時間が掛かります。 レプリケーション && DNS 切り替え方式 画像引用： https://aws.amazon.com/jp/blogs/database/performing-major-version-upgrades-for-amazon-aurora-mysql-with-minimum-downtime/ Blue/Green デプロイ手法で最後にアプリケーションの向き先を変える方法です。 ざっくり説明すると以下のイメージです。 現在動いている Aurora を Blue 環境とし、Blue からクローン、Green 環境を作ります Green (Older) をインプレースアップグレードします Blue とインプレースアップグレードした Green (Newer) でレプリケーションします 最後にアプリケーションの向き先をインプレースアップグレードしたクラスターに変更します この方法でもダウンタイムは少なからずどうしても発生します。 ただし、インプレースアップグレード方式よりもダウンタイムは短くできます。 検討する上での比較項目 ↓比較項目 インプレースアップグレード方式 レプリケーション && DNS 切り替え方式 手順がシンプルかどうか ✅ ❌ ダウンタイムの長さ ❌ ✅ 切り戻しがしやすいか ❌ ✅ 実際に採用した手順 レプリケーション && DNS 切り替え方式を採用 しました。 採用した理由は以下のとおりです。 ダウンタイムは極力短くしたい。 弊社サービスの性質上 、カメラの録画欠損はなるべくさせたくない。 こちらの理由が一番強い決め手となりました。 ※手順が少し複雑になる所は許容範囲としました。 実際の作業イメージ 前提条件 レプリケーションには AWS DMS Database Migration Service を利用します。 現在動いている Aurora MySQL の方で、 バイナリログ出力有効 (binlog_format=ROW 形式) になっていることが必須です。 https://docs.aws.amazon.com/dms/latest/userguide/CHAP_Source.MySQL.html#CHAP_Source.MySQL.AmazonManaged Set the binlog_format parameter to "ROW". step1 から step3 までは事前準備です。 (既存サービスには影響ありません) 最後の step4 だけダウンタイムを伴う、停止メンテナンスが必要です。 step1 Clone して Clone 先クラスターをインプレースアップグレードします。 step2 AWS DMS (Database Migration Service) でレプリケーションします。 step3 rollback (切り戻し) 用の 5.6クラスターを追加します。 基本的には rollback は必要無いはずですが、念には念を入れて準備しました。 DMS を中継することで、5.7 -> 5.6 への (ダウングレード) レプリケーションも可能になります。 ※ AWS サポートに質問し、可能と回答頂きました。担当サポートの方、誠にありがとうございました。 step4 step3 までの事前準備が完了したら、いよいよダウンタイムを伴う停止メンテナンスを実施します。 (停止メンテナンス) DNS 切り替え CNAME 変更 (aurora56 -> 57) step4 の詳細手順 DNS 切り替えの手順イメージは、以下のとおりです。 API などのリクエストを 503 Service Unavailable 固定レスポンスにし、メンテナンス中にします。 古いクラスター (5.6) への書き込みを止めます。 (db-cluster-parameter-group 変更で read_only にします) 新しいクラスター (5.7) へのレプリケーション遅延が無いことを確認します。 DMS の CloudWatch メトリクスで確認できます。 CDCLatencySource CDCLatencyTarget これらの値が 0 になると、レイテンシー (レプリカラグ)が無いと判断出来ます。 DMS のレプリケーションを停止します。 Route53 ルーティング先変更します。 (5.6 -> 5.7) API などの 503 Service Unavailable 固定レスポンスを解除します。 古いクラスター (5.6) を reboot します。(各アプリケーションの接続を強制的に切断する意味合いです) 以上でメンテナンス完了です。 万が一の rollback 手順 今回は rollback (切り戻し) しませんでしたが、基本的には step4 と似たような手順で実施可能です。 現行クラスター (5.7) への書き込みを止めます。 (read_only にします) rollback クラスター (5.6) へのレプリケーション遅延が無いことを確認します。 DMS のレプリケーションを停止します。 Route53 ルーティング先変更します。 (5.7 -> 5.6-for-rollback) 現行クラスター (5.7) を reboot します。 おわりに 以上、Amazon Aurora MySQL をバージョンアップグレード (5.6 -> 5.7) したお話でした。 余談ですが、2022年11月27日に Blue/Green デプロイ手法でダウンタイムを最小限に抑えつつデータベースを更新する方法が一般公開されました。 New – Fully Managed Blue/Green Deployments in Amazon Aurora and Amazon RDS 次回、データベースのアップグレードをする際には、こちらの Blue/Green デプロイメントを試してみたいと思っています。 セーフィーでは、 夢を語りまきこみやりきる 方を歓迎します。 ご興味のある方のご連絡をお待ちしてます。 Safie Engineers' Blog! セーフィー株式会社

こんにちは。セーフィー株式会社 バックエンドエンジニアの村田 ( @naofumimurata )です。 この記事はセーフィー株式会社 Advent Calendar 2022 の12月15日の記事です！ 本記事ではセーフィーにおけるdriftctlというツールを活用したIaC化推進に向けた取り組みについてご紹介したいと思います。 セーフィーのインフラ環境と課題 driftctlとは driftctlの使い方 準備 スキャンの実行 出力形式の変更 .driftignoreファイルによるスキャン対象からの除外 GitHub Actions による定期実行 ワークフローの解説 取り組みの結果 driftctlを使ってみて 良い点 カバレッジが出せる 「何をコード管理しないか」をコード管理できる 気をつける必要がある点 リソースが多い環境だとrate limit 超過のエラーで失敗する まとめ セーフィーのインフラ環境と課題 セーフィーではインフラ環境としてAWSを利用しており、 Terraform を利用してAWSリソースのコード管理を行なっています。基本的に新しく作られるものについてはTerraformで構築されるのでコード管理された状態になっているのですが、歴史的経緯（後からTerraformが導入された）によりコード管理できていないリソースがまだ残ってしまっているという課題があります。 また、そういったコード管理されていないリソースを見つけるには、Terraformコードベースの知識とセーフィーのインフラ構成の両方の知識が必要であるため、対応できる人がやるというような形になり中々コード化が進まないという課題もありました。 driftctlとは 前述のような課題の解決に役立ちそうなツールとして driftctl というものがあります。 https://github.com/snyk/driftctl driftctlはクラウド上のリソースと IaC (Infrastructure as Code) コードを比較し以下のリソースを検知することができます。 IaC管理されていないリソース IaC管理されているが実際の状態と差分が出てしまっているリソース 本記事の執筆現在 (2022/12/15) 、最新バージョンは v0.38.1 で、IaCツールは Terraformのみをサポートしており、クラウドプロバイダとしては AWS, GitHub, Azure, GCPをサポートしています。 また、READMEには以下の記載があり、まだbeta版であるということが注意書きされています。 ⚠️ This tool is still in beta state and will evolve in the future with potential breaking changes ⚠️ driftctlの使い方 準備 まず、以下を参考にインストールを行います。 https://docs.driftctl.com/0.38.0/installation その後、利用するクラウドプロバイダの認証情報を有効にします。 https://docs.driftctl.com/0.38.0/providers/aws/authentication スキャンの実行 以下のコマンドを実行するとスキャンが実施されます。 $ driftctl scan 特にオプションを指定しない場合、カレントディレクトリのHCLファイルから利用しているtfstateを検出し読み込みます。HCLファイルからtfstateの検出に失敗した場合、ローカルの terraform.tfstate ファイルを読み込もうとします。 tfstateを指定したい場合は --from オプション (環境変数で指定する場合は DCTL_FROM ) で指定することができます。 $ driftctl scan --from tfstate+s3://tfstate-bucket/terraform.tfstate ワイルドカードで複数tfstateをまとめて指定することもできます。 $ driftctl scan --from tfstate+s3://tfstate-bucket/*.tfstate 無事にスキャンが終わると、以下の様に結果がコンソールに出力されます。 Found missing resources: aws_s3_bucket: - test-bucket-1 Found resources not covered by IaC: aws_s3_bucket: - test-bucket-2 Found changed resources: - test-bucket-3 (aws_s3_bucket): ~ Versioning.0.Enabled: false => true Found 3 resource(s) - 33% coverage - 1 covered by IaC - 1 not covered by IaC - 1 missing on cloud provider - 1/1 changed outside of IaC 結果の内容は以下の様になっています。 IaC管理下のリソースに対するスキャン結果 IaCコードには存在するが実際のクラウド上には存在しないリソースの一覧 IaCコードと実際のクラウド上の設定で差分が出てしまっているリソースの一覧と差分 IaC管理されているリソースに対するスキャン結果 IaC管理されていないリソースの一覧 統計情報 カバレッジなど 出力形式の変更 デフォルトではスキャン結果はコンソールに出力されますが、 --output オプション (環境変数: DCTL_OUTPUT ) で出力形式を変更することができます。現在、利用できる出力形式はデフォルトのコンソール出力の他にJSON, HTMLがあります。 $ driftctl scan --output json://result.json $ driftctl scan --output html://output.html --only-managed オプション (環境変数: DCTL_ONLY_MANAGED ) を指定することで、IaC管理下のリソースに対するスキャン結果だけを出力させるができます。 $ driftctl scan --only-managed 逆に IaC管理されていないリソースに対するスキャン結果のみを出力したい場合は --only-unmanaged オプション (環境変数: DCTL_ONLY_MANAGED ) を指定します。 $ driftctl scan --only-unmanaged .driftignoreファイルによるスキャン対象からの除外 driftctlでは特定のリソースをスキャン対象から除外させる機能があり、ファイルに以下のような形式で除外パターンを記述しておくとスキャン対象から外すことができます。 除外パターンを記載しておくファイルは、デフォルトで .driftignore という名前のファイルが使われますが、オプションでファイル指定ができるので別の名前でも問題ありません。 aws_s3_bucket.test aws_instance.* 上記の除外パターンの意味としては、 test という名前のAWS S3バケットとAWS EC2インスタンスの全リソースを除外するという意味になります。 以上で、driftctlの基本的な使い方の紹介を終わります。 他のオプションや詳しい使い方については公式ドキュメントをご参照ください。 https://docs.driftctl.com/0.38.0/usage/ GitHub Actions による定期実行 実際にdriftctlを使ってスキャンした結果を元に改善を進めていく場合、定期的に改善の状況をチームで確認していく必要があるかと思います。都度、誰かがスキャンを実行して結果を共有するのでも良いですが、自動で実行できる仕組みがあると便利かと思い GitHub Actions で定期実行するワークフローを導入しました。 セーフィーでは複数のAWSアカウントがありますが、試験的に導入したかったため、ひとまず1つのAWSアカウントを対象にスキャンを実施するようにしました。 name : driftctl on : schedule : - cron : '0 12 1 * *' workflow_dispatch : jobs : driftctl : runs-on : ubuntu-latest permissions : id-token : write contents : write steps : - name : Checkout uses : actions/checkout@v3 - name : Configure AWS credentials uses : aws-actions/configure-aws-credentials@v1-node16 with : role-to-assume : ${{ secrets.ASSUME_ROLE_ARN }} aws-region : ap-northeast-1 - name : Run uses : snyk/driftctl-action@v1 continue-on-error : true env : DCTL_ONLY_UNMANAGED : true DCTL_OUTPUT : "html://report.html" with : version : 0.38.0 - name : Chown run : sudo chown -R runner report.html - name : Upload artifact uses : actions/upload-artifact@v3 with : name : Scan Report path : report.html ワークフローの解説 ワークフローの内容は以下の通りです。 schedule トリガーイベントにより毎月月初に実行 or 手動起動で実行 AWS認証情報を有効にする driftctl を実行 公式のAction sync/driftctl-action を利用 環境変数 DCTL_ONLY_UNMANAGED でIaC管理外のリソースに対する結果のみを出力するように指定 環境変数 DCTL_OUTPUT でHTML形式で結果を出力するように指定 continue-on-error: true で失敗してもワークフローが続行されるように 1つでもIaC管理外のリソースがあると終了ステータスが1になり、そのままだとそこでワークフローが失敗してしまうため https://docs.driftctl.com/0.38.0/usage/cmd/scan-usage#exit-codes 結果ファイルをartifactに保存 このワークフローをTerraformコードを管理しているリポジトリに設定し、月一でスキャンした結果をチームで確認、分担して調査とTerraform化を進めていく運用を開始しました。 取り組みの結果 現在、取り組みを始めてから数ヶ月経ちました。まだ全てのリソースのIaC化までは実現できていませんが、着々とカバレッジの数値が上がっており、引き続きこのまま取り組んでいきたいと思っています。 これまでは対応できる人が個人のモチベーションで対応していくという属人的な方法で改善していたものが、ツールを活用し誰でも確認し対応できる形にできたので、かなり進めやすくなりました。 driftctlを使ってみて 今回、driftctlというツールを使っていくなかで個人的に良いと感じた点、また、ちょっと気をつけて使わないといけない点があったので簡単にまとめたいと思います。 良い点 カバレッジが出せる スキャン結果として、リソース全体のうちどのくらいIaC化できているかというカバレッジの値を出してくれるのですが、改善の状況を数値として確認できるのでとても便利です。 「何をコード管理しないか」をコード管理できる .driftignore ファイルでスキャン対象から除外するリソースを指定できる機能もとても良いと思いました。リソースによってはあえてTerraformで管理していないものもあり（アプリケーションから作成されるリソースだったりGitHub PR環境用にCIから作られるリソースなど）、そういったリソースをスキャン対象が外せるとともに、「何をコード管理していないか」という情報をコード管理できるのが便利です。 気をつける必要がある点 リソースが多い環境だとrate limit 超過のエラーで失敗する リソースが多い環境だとスキャンの途中でAWS APIのrate limit超過のエラーが発生し、スキャンに失敗してしまうことがあります。自分達の環境では、特にAWS Route53 Recordのリソースをスキャンしようとした場合にスキャンに失敗することが多かったため、不本意ながらスキャン対象から除外するように設定する必要がありました。この問題があるため、AWS APIを利用するアプリケーションが動く本番環境用のAWSアカウントなどで気軽にスキャンできないという別の問題も生まれています。 こちらの問題はissueとしても挙げられており、動向を注視しています。 https://github.com/snyk/driftctl/issues/1344 まとめ 今回は、driftctl というツールを活用したIaC化推進に向けた取り組みについてご紹介しました。driftctlはまだbeta版ということもあり、不足している機能もありますがとても便利なツールだと思うので興味を持たれた方はぜひ触ってみてください。取り組みを始めて数ヶ月経ち、まだ完全なIaC化までは実現できていませんが、着実に改善を進められていくことができています。本記事が同じような課題を持っている方の参考になれば幸いです。ここまで読んでいただき、ありがとうございました。

こちらは セーフィー株式会社 Advent Calendar 2022 の 14日目の記事になります。 はじめまして。セーフィーでインフラエンジニアをしている近江です。 セーフィーでは AWS の各サービスごとのコストを詳細に把握するため、"AWS Cost Categories" という AWS のサービスを使用しています。本記事では AWS Cost Categories とは何か、どのようなシーンで活用できるのか、実際の設定方法、気をつけるポイントについて書いていきたいと思います。 AWS Cost Categories とは コストカテゴリとは 利用料金 AWS Cost Categories を活用できるシーン コストカテゴリの作成とルール設定 ルールに継承された値 (INHERITED VALUE) を使用する 気をつけるポイント コストカテゴリで使用できるディメンション OR 条件は root レベルでは使えない コストカテゴリの削除 まとめ AWS Cost Categories とは AWS Cost Categories 概要ページ AWS Cost Categories は AWS Billing の請求関連のサービスの 1つです。 AWS によるクラウド財務管理 のページでは ビジネスロジックに沿ったコスト配分戦略の構築 のコストの整理を提供するサービスの 1つとして挙げられています。コストの整理の機能には他にコスト配分タグ (AWS cost allocation tags) があり、こちらは利用されることが多く、ご存じの方が多いかと思います。しかし AWS Cost Categories はそこまで知られているサービスではないのかなという印象です。 2022年11月現在、AWS Cost Categories では主に以下のような機能が提供されています。 独自に定義したルールからコスト情報をマッピングしてコストカテゴリを作成 分割料金ルールを使用して、コストカテゴリ値の間で料金を配分 コスト管理機能でコストカテゴリ別に使用量を表示 AWS Cost Categories サービスページより コストカテゴリとは AWS Cost Categories ではコストカテゴリというものを作成して AWS のコストをカテゴリで分割することが可能です。 コストカテゴリはユーザー側が細かく定義することが可能で、アカウント、タグ、サービス、料金タイプ、別のコストカテゴリなどを指定してルールを作成できます。 作成したコストカテゴリは AWS Cost Explorer、AWS Budgets、AWS Cost and Usage Report (CUR) などの他のコスト管理機能から使用できます。 Cost Explorer のグループ化としてコストカテゴリを指定した際の画面のキャプチャ セーフィーは複数の AWS アカウントがあり、一部のサービスは複数のアカウントを横断してリソースがあります。Cost Explorer のグループ化の条件としてコストカテゴリを使用することでサービスごとのコスト状況が一発で分かります。更にフィルターを追加してサービスごとのデータ通信量だけを把握したりも可能です。 利用料金 AWS Cost Categories 利用料金は無料です。 Q: Is there a cost associated with using AWS Cost Categories? This service is provided free of charge. AWS Cost Categories FAQs - Amazon Web Services より AWS Cost Categories を活用できるシーン 例えば、以下のような一括請求が有効な 3つの AWS アカウントがあり、コスト配分タグ CostAllocation がついたリソースのある環境があるとします。 このような複数アカウントの環境で、以下のようにプロジェクトごとにコストを集計したいという要件が上がったとします。 プロジェクトA コスト配分タグ CostAllocation の ServiceA と ServiceB がついているリソースが対象 プロジェクトB アカウントA のうち、コスト配分タグ CostAllocation がついていないリソースが対象 プロジェクトC アカウントC が対象 上記以外 このような要件で実際にコストを把握したい場合、一般的には以下のようにするかと思います。 Cost Explorer から条件を指定してプロジェクトごとに集計 新たにコスト配分タグを全てのリソースに付ける しかし Cost Explorer を使う場合はプロジェクトの数に応じて集計回数が増えてしまってかなりの手間になります。新たにコスト配分タグを付ける場合は既存のリソースへのタグの設定変更が必要になり、コスト配分タグを有効化するより前の集計ができないなどのデメリットがあります。 そこで登場するのがコストカテゴリです。 コストカテゴリを用いることで、コスト配分タグの新たな有効化や既存のリソースへのタグ追加をする必要はありません。また Cost Explorer でコストカテゴリを指定してグループ化することで、一度にプロジェクトごとにコストを把握することが可能になります。 コストカテゴリの作成とルール設定 ここでは先程の活用できるシーンの設定例を想定して実際にコストカテゴリを作っていきます。 請求ダッシュボード (AWS Billing Dashboard) ページの左側の Cost categories をクリックします。 コストカテゴリを作成 をクリックして作成します。 コストカテゴリの名前 (キー名) を設定するページが表示されます。 名前は今回 Test01 としました。 名前は後から変更不可なので注意してください。 またルックバック期間も設定できます。通常はコストカテゴリを作成した当月のみ遡って使用できますが、ルックバック期間を設定すると最大12ヶ月間遡ってコストカテゴリを使用することが可能になります。 AWS Cost Categories がルールの遡及適用のサポートを開始 設定して 次へ をクリックします。 コストカテゴリの値とルールを設定するルールビルダーのページが表示されます。 各プロジェクトを想定してルールを設定していきます。 値：ProjectA 条件 コスト配分タグ CostAllocation の値が ServiceA か ServiceB 一括請求の管理アカウントでは複数の AWS アカウントに設定されたコスト配分タグが対象です。 値: ProjectB 条件 アカウントID が 111111111111 (アカウントAを想定) コスト配分タグ CostAllocation が存在しない コストカテゴリではルールが上から処理され、コストに一度だけ適用されます。 ProjectA のルールでアカウントA に CostAllocation の値 ServiceA か ServiceB を持つリソースがあっても、ProjectB の値には反映されません。 値: ProjectC 条件 アカウントID が 3333333333333 (アカウントCを想定) デフォルト値 デフォルト値を設定すると、全てのルールに一致しないコストは設定した値が使用されます。デフォルト値を設定しない場合は NoValue 扱いになります。 設定したら 次へ をクリックします。 オプションの分割請求の定義のページが表示されます。 分割請求を設定することで、特定のコストカテゴリの値を別の値に振り分けることができます。 こちらは設定しても Cost Explorer などには反映されず、コストカテゴリのページ中のみ反映されるため注意してください。 注: 分割請求は AWS Cost Categories でのみ利用できます。この機能は、他のコスト管理機能 (例えば、Cost Explorer、Cost and Usage Reports) には表示されません。 ここまで設定し、 コストカテゴリを作成 をクリックすると作成されます。 コストカテゴリが作成されました。 ステータスが最初は 処理中 になります。 作成した日が月の後半だったりルックバック期間が長いと処理が完了するまでに数時間かかることもあります。気長に待ちましょう。 分類分けされたコストがある場合は以下のように色分けされて分かりやすく表示されます。 ルールに継承された値 (INHERITED VALUE) を使用する ルールタイプを 継承された値 (INHERITED VALUE) にすることで、値を自動的に生成することが可能です。 継承された値: このルールタイプにより、定義されたディメンション値からコストカテゴリの値を動的に継承するルールを定義する柔軟性が追加されます。 コスト配分タグ もしくは アカウント が指定可能です。 自動的に値を設定してくれるため、全ての値をルールにいちいち指定するような手間をなくすことができます。 気をつけるポイント コストカテゴリで使用できるディメンション ルールで指定するディメンションですが、Cost Explorer のものとは異なるようです。 例えばディメンションにサービスにした場合に値として AWSDataTransfer が指定できますが、これは Cost Explorer では指定できません。料金タイプの方も若干異なるようなので、設定する際には気をつけましょう。 OR 条件は root レベルでは使えない 複雑な条件を使いたい場合には JSON でルールを指定でき、OR 条件も使うことが可能になります。 しかし以下の JSON のような Rule 直下に OR を指定することはできません。 { " RuleVersion ": " CostCategoryExpression.v1 ", " Rules ": [ { " Type ": " REGULAR ", " Value ": " ProjectA ", " Rule ": { " Or ": [ { " Dimensions ": { " Key ": " LINKED_ACCOUNT ", " Values ": [ " 111111111111 " ] , " MatchOptions ": [ " EQUALS " ] } } , { " And ": [ { " Tags ": { " Key ": " CostAllocation ", " Values ": [ " ServiceB " ] , " MatchOptions ": [ " EQUALS " ] } } , { " Dimensions ": { " Key ": " LINKED_ACCOUNT ", " Values ": [ " 222222222222 " ] , " MatchOptions ": [ " EQUALS " ] } } ] } ] } } ] } こちらを JSON エディタに入力しても、以下の検証エラーが出てしまい、適用することができません。 検証エラー Failed to create Cost Category: Expression cannot contain OR on root level このような root レベルの OR が可能であれば、簡単にコストを足し合わせて算出できるのですが…。 できないため、コストカテゴリを入れ子にすることで回避することが可能です。 先に別のコストカテゴリで合算したいルール条件ごとに値を作成してコストカテゴリを作成する 別のコストカテゴリから先に作ったコストカテゴリをディメンションに指定し、値を全て指定する また、設定したい OR 条件と、全てに合致する適当なディメンションの条件で AND 条件を使うことでも無理やり回避可能です。しかしかなり分かりにくくなるためあまり使わないほうがいいかと思います。 コストカテゴリの削除 コスト配分タグと同じですが、コストカテゴリを削除しても Cost Explorer 上のコストカテゴリの選択欄からは消えません。 コストカテゴリのキー名は後から変えることが不可能なため、検証する際は注意が必要です。 まとめ AWS Cost Categories を利用することでコスト集計作業を効率化する事ができます。 「Cost Explorer のフィルターでタグから複数の値を選択しているけど面倒だし一つにまとめたい」 このようなシーンでもコストカテゴリを使って効率化可能なので、集計の手間を感じたら利用を検討してみてはいかがでしょうか。

はじめに こんにちは、セーフィーのイマドです。 この記事は Safie Engineers' Blog! Advent Calendar 13日目の記事です。 セーフィーでは「映像から未来をつくる」というビジョンのもと、AIなどの技術をクラウドや映像と紐付けることでさまざまな業界の不を覆すソリューションを日々模索しています。 そんな折、画像生成AIのStable Diffusionや人間のように自然な対話ができるChatGPTなど、様々な技術がソーシャルメディア上で話題になってきました。実際に使ってみるとその完成度に衝撃を受けたという人も多いのではないでしょうか、私もその一人です。 これらの最新技術は別に雲の上の話ではなく、実は全ての人が少し手を伸ばせば届く距離にあるわけです。 そこである考えが浮かんできました。 世の中にある最新技術や既存の技術要素を部品に見立てて、レゴのように組み合わせることで業界や顧客の課題を解決できる価値を簡単に作れてしまうのではないか… そしてあわよくば、プログラミングとか面倒なことはAIにまかせてしまいたい… AI「ボクタチ ハタラク　アナタ ラクスル」 今回はそんな夢みたいな話を現実にしてくれるかもしれない組み合わせを見つけたのでご紹介します。 それが「 対話AIのChatGPTと、ローコードツールPipedreamの組み合わせ」 です。 次章からそれぞれを解説していきます。 はじめに 各種技術の紹介 OpenAI ChatGPT OpenAI API(GPT-3 text-davinci-003) Pipedream WEB上でコーディングが完結する。 価格 15分でAIチャットボットを作ってみる 背景 ざっくり構成を考えてみる STEP1：特定のチャンネルで特定の文字列を検知(Slack) STEP2：文字列から必要な部分だけを取り出す(Function) STEP3：回答文を生成する Open AIアカウント設定 APIキーの発行 Pipedreamの環境変数にAPIキーを設定 OpenAI APIへのリクエスト AIにキャラクターを付与する STEP4：回答をスレッドに投下する。 テスト/デプロイする 結果 おわりに 各種技術の紹介 OpenAI ChatGPT ChatGPTによるChatGPTの紹介(自己紹介) だそうです 以下からChatGPTのお試しをすることが可能です。(要OpenAIアカウント) https://chat.openai.com/chat こちらの ChatGPT使い方総まとめ を見てもらうとわかるように、質問への応答からコードの生成まで幅広くこなしてくれます。 この記事が公開される頃にはChat GPT系の記事が充実していると思われるので、詳しく知りたい方は他の記事も参照してみてください。 QiitaのChatGPT記事一覧 ちなみに、執筆当時(2022/12/06)まだ ChatGPTのAPIは公開されていません 。現在インターネット上で見かけるChatGPTのAPIで〜してみた系の記事は、後述するGPT-3の言語モデル”text-davinci-003”の可能性があります。 今回このChatGPTには、私がこれから行うアプリケーション開発のアシスタントになってもらいます。 OpenAI API(GPT-3 text-davinci-003) こちらはChatGPTと混同しがちですが、ChatGPTより前に開発された言語モデルです。 有料ですがAPIが公開されており使い勝手が良いので、 今回は部品の一つとして使わせてもらいます。 ChatGPTにtext-davinci-003とはなんですかと聞いてみている図 Pipedream www.youtube.com Pipedreamとは、ひとことで言えば「Zapier上でAWS Lambdaが使えるワークフローツール」です。 簡潔なインターフェースでZapierのように様々なサービスと簡単に接続するだけでなく、AWS LambdaのようにJavascript/Python/Goといった言語(とbash)で直接処理を記述/実行が可能です。 WEB上でコーディングが完結する。 これが、Pipedreamの最大の特徴であり、ZapierやAWS Lambdaとの違いになります。 たとえば、Zapierでもモジュールを作成することでnpmパッケージを扱うことができますが、ローカルでCLIを叩きながらデプロイしなければなりません。それがなんとPipedreamではWEB上でnpmパッケージが扱えます。 Javascript(node)を直接記述している Pythonでも科学計算用のライブラリをimport可能で、ちょっとした処理ならPipedreamだけで済みそうですね。 Pythonの科学計算用のライブラリを読み込んでいる 公式サイト https://pipedream.com/ 執筆している現在、日本語で検索すると産業用システムに対するマルウェアの方が出てきてしまう状況なので、これを機に日本語の記事が増えてくれることを望みます。 価格 Pipedreamの価格 https://pipedream.com/docs/pricing/ Pipedreamでは、Developer Tierとして、個人利用であれば無料で月10,000回の呼び出しが実行できるようになっています。 この呼び出しとは、ワークフロー内のステップ数ではなくワークフローが呼び出された回数のことです。そのため、5つのステップで構築したワークフローを実行した場合、それを1回の呼び出しとしてカウントします。 無料枠では333回呼び出し/日までという制限もありますが、Zapierの無料枠は月100回までと比べるとなんて太っ腹…！（組織だと66呼び出し/日でした） お試しなら良いですが、止まってはいけない運用をするのであれば有料版を検討してくださいね。 また、PipedreamはOSSとして公開されているため、これを自分のサーバーにデプロイして使ってみるのも良いかと思います。 https://github.com/PipedreamHQ/pipedream 15分でAIチャットボットを作ってみる 背景 弊社のSlackチャンネルの一部では、プライベートな一面を引き出し社員同士の理解を深めるという名目のもと、Colloという奇天烈カラクリロボットがユーザーに質問を投稿しています。 カラクリロボットによる執拗なSlack投稿 ですがこのCollo、毎日仕事の時間に質問してくるのです。 質問される側にとってはたまったものではありません。そのため、最近はみんなColloの質問を無視しがちになっています。 本来であれば、聞く時間をお昼時にするとか、みんなが興味をもってくれそうな質問をするとか、 もっと回答してもらいやすい方法 を考えるべきです。 そこで、社員をもうひとり用意し、一人が仕事をしている間に代わりに回答してもらうことで回答率100%を目指すことにしました。 いわゆるマルチプロセッサ ざっくり構成を考えてみる Pipedreamを使えば、以下のような構成で作成できそうです。Pipedreamでは、処理の単位をステップ。一連のステップの組み合わせをワークフローと呼んでいます。 ざっくりワークフロー構成 では、次節から具体的に組み上げていきます。 STEP1：特定のチャンネルで特定の文字列を検知(Slack) 質問文なりよ このステップでは、上のようなメンションを検知してワークフローが開始されるように、トリガーを設定していきます。 トリガーの選択 アプリからSlack→New Mention(Instant)を選択し、反応するチャンネルを指定。 アカウントの連携を済ませ、チャンネルを指定することで特定のチャネルへの投稿を検知することができるようになります。 トリガーの設計 ここでは、冒頭の「ねえねえ」をキーワードに指定しました。これで、「ねえねえ」を含むメッセージが指定されたチャンネル上で投稿されるとトリガーが発火されます。 ここで問題が発生しました。ignore botsをfalseにしても、なぜかColoの投稿だけ検知してくれません。他の機能ではちゃんとignore botsをfalseにしてもColoの投稿を検知してくれたので、バグかもしれません…。 →バグでした。 フォーラムに投稿 したところすぐに再現性のあるバグとして Issue が建てられました。めっちゃ対応早い この記事が公開される頃には修正されているかもしれませんね。 しかたないので、今回は別のやり方で実装してみました。 他の方法で実装してみる 「New Message in Channels(Instant)」で、特定のチャネルにきた投稿すべてを検知 「Filter」→「Continue based on Condition」を用い、検知されたメッセージのうち「ねえねえ」を含むものだけ次のステップに通す。 このやり方の欠点としては、すべての投稿に対してTriggerが実行されてしまうことで余計な呼び出しが発生してしまう点が挙げられます。 STEP2：文字列から必要な部分だけを取り出す(Function) 先程のステップで「ねえねえ」を含む投稿をトリガーにワークフローが実行されるようになりました。ここでもう一度、質問文を見てみましょう。 これは質問文なのか このうち1行目は要らないので削る必要がありますが、文字の処理はノーコードの範疇では難しそうですね。Pipedreamではプログラミング言語で直接処理を書くことができますが、面倒です。 ここは、AIに考えてもらいましょう。 AIに文字列処理のプログラムを書いてもらった いい感じのものが出てきました。 （今回は簡単な処理ですが、正規表現が必要なもっと複雑な処理でもChatGPTはよしなに生成してくれます。） 出力されたコードをPipedreamの様式に合うように少し改変します。ステップ名は”format_question”としました。 前のSlackのメンショントリガーステップからデータを取り出すために steps.{{step_name}}.event.text を指定しています。今回のstep_nameは”trigger"です。 export default defineComponent({ async run({ steps, $ }) { // 変数strに文字列を格納する var str = steps.trigger.event.text; // 改行コード(\n)で文字列を分割する var lines = str.split("\n"); // 2行目以降を抽出する var extracted = lines.slice(1); // 抽出した文字列を出力する return extracted.join("\n"); }, }) 抽出した文字列をreturnで返すことで、次のステップから format_question.$return_value で値を取り出すことができます。 このようにツールではカバーしきれない処理をAIに書かせるというのは、部分的にプログラムを記述できるローコードツールならではの使い方かもしれませんね。 STEP3：回答文を生成する ここでは、OpenAIのAPI(text-gpt-003)に質問内容を渡して回答文を生成してもらいます。 ※回答文を生成するAIはChatGPTではなくtext-davinci-003という自然言語モデルになります。ChatGPTはAPIが公開されていないので仕方ありません。 Open AIアカウント設定 OpenAIのAPIを使うためには、アカウント登録と有料アカウントへの変更が必要になります。 https://beta.openai.com/account/billing/overview 「Setup Paid account」からカード情報を入力してください。 https://openai.com/api/pricing/ 価格表(OpenAIの公式サイトより) 価格表にあるトークン(tokens)という単位ですが、入力プロンプトの文字数と出力された文字数を足し合わせた数がリクエストごとにカウントされ1,000トークンごとに所定の金額が課金されます。 今回質問に回答するのはDavinciという言語モデルなので、1,000トークン(文字)ごとに$0.02が必要になります。 APIキーの発行 以下のURLから、APIキーの発行が可能です https://beta.openai.com/account/api-keys 一度しか表示されないので、メモしておこう Pipedreamの環境変数にAPIキーを設定 Pipedreamでは、Enviroment Variablesから環境変数を設定することができます。 https://pipedream.com/settings/env-vars 「NEW ENVIROMENT VARIABLE」でキーを設置します。 環境変数を設定 今回は”OPENAI_APIKEY”という名前で環境変数を設定しました。 これで、ワークフローの中から{{process.env.OPENAI_APIKEY}}でキーを取り出す事ができるようになりました。 OpenAI APIへのリクエスト それでは、OpenAIのGPT-3 text-davinci-003”に回答文を生成してもらいましょう。 OpenAIのエンドポイントは https://api.openai.com/v1/completions です。 シンプルに回答してもらうだけなら、以下のようなリクエストをOpenAIにPOSTするだけで良いです。 POST https://api.openai.com/v1/completions Header： 　Authorization：Bearer {{process.env.APIKEY}} 　Content-Type：application/json Body： { "model": "text-davinci-003", "prompt": {{ここにプロンプトが入ります。}}, "max_tokens": 1000 } Bodyに指定しているパラメータの解説 model：今回使用するモデルを指定します。今回は現在公開されているAPIの中で一番高性能な”text-davinci-003”を指定して使います。 prompt：AIに入力するプロンプトになります。 max_tokens：回答に対する最大トークン数(≒文字数)を指定しています。text-davinci-003のmax_token数は4000なので、input/output合わせて4000を超えないように指定しましょう。 パラメータについては、 OpenAI API(GPT-3) 入門 (1) - 事始め が詳しかったです。 これをPipedreamに反映させると以下のようになります。 Authorizationに環境変数に保存したOpenAIキーを設定 Bodyの内容はこんな感じ 実行結果はこちら アットホームな職場です これで、AIに回答文を生成してもらうことができましたね。 AIにキャラクターを付与する GPT-3 text-davinci-003をそのまま使うと、当たり障りのない口調のキャラクターになってしまいます。 今回は質問された本人のように回答して欲しいので、弊社の従業員投票1位に輝いたことのある「とある社員」の偶像になってもらうことにしました。 今回利用したのはChatGPTとは違いますが、使い方は基本的には同じなはずなので ChatGPT使い方総まとめ を参考にプロンプトを生成してみました。本人のSlack投稿などをかき集め、キャラクターを作り上げています。(この記事は本人に許可を頂いて作成しています。) Pipedream上ではこのようになります AIにキャラクターを降臨させる儀式 STEP4：回答をスレッドに投下する。 最後に、生成された回答文をSlackに返しましょう。 「Slack」→「Reply to a Message thread」を選択してステップを作成していきます。 入力している内容は以下です。 Bot Username：Slack上で表示されるボット名 Icon(emoji)：ボットのアイコンを好きな絵文字にすることができます。今回は社員のアイコンを絵文字にしてから指定しました。 Thread Timestamp：親メッセージのタイムスタンプを指定します。今回のトリガーとなったメッセージのタイムスタンプを持ってきました。 Channel：親メッセージのあるチャネルを指定します。今回はトリガーとなったメッセージからチャネルを紐付けています。 Text：ここに投稿内容を記載します。今回は、OpenAI APIから返却されたテキストを挿入しています。 `steps.post_request_openai.$return_value.choices[0].text` テスト/デプロイする 「Test」を押して、ちゃんと一連のワークフローが実行できるか試してみましょう。 自分でキーワードを発言して動作確認している様子 ちゃんと意図したとおりに動きましたでしょうか。 さて、このままでは新しい投稿があってもワークフローが実行されませんので、右上のDeployボタンを押して、変更を反映させます。デプロイが完了することでワークフローが有効になり、次回から自動で返信されるようになります。 結果 かがくのちからってすげー 見事、回答率100%を達成することができました。 用意しているプロンプトが「以下の質問に対して回答してください {質問文}」で終わるように作ってあるため、質問文が空になってしまったときはAIが勝手に質問文を生成して勝手に回答してくれています。意図していなかったのですが、これはこれで面白いですね。 突然の自分語り おわりに 今回は、AIの力を借りながらPipedreamというワークフローツールで社員のように回答してくれるAIチャットボットを共同開発してみました。 ChatGPTのコード生成は素晴らしく、ちょっとした処理ならコーディングする必要もないくらいプロセスを簡潔化してくれました。まだプログラム全体を代わりに作成してもらうことは難しいかも知れないですが、ワークフローツールのようなステップ単位の処理やFaaS(Function as a Service)などではすぐに実用可能な技術なのではないでしょうか。回答生成で使用したtext-davinci-003もAPIとして気軽に利用でき、一時期話題になっていたドラマの登場人物っぽいチャットボットが簡単に作れるようになったのだと実感しています。 また、PipedreamはZapierよりも高度なことができるローコードツールという印象です。今回は簡単な処理しかしていませんが、Pythonを使った複雑な科学計算なども扱えることから様々なシーンに応用できそうです。 個人的には、ノーコードツールでは役不足なところをプログラミングにより補完できる幅をもたせたものがローコードツールだと思っていますが、プログラミングが必要ということは専門的知識が必要であり私のようなプログラマではない半端者には難しいところがありました。 しかし、ChatGPTのような文字生成AIが誕生したことでローコードツールの敷居は非常に低くなり、既製品として用意されていないモジュールを自分でも作れるようになりました。ローコードツールの特性としてもChatGPTとの組み合わせは非常に相性が良いように思います。 世の中には素晴らしい技術やサービスが点在しています。それらをレゴのように組み立てることで、プログラマではない私達にも様々なことが実現できるという可能性を感じていただけたのではないでしょうか。 セーフィーでは、業界の不に対し既存の技術を組み合わせ仮説検証を高速化し、誰よりも早く本質的な価値を創りあげていく仲間を幅広く募っています。一緒に映像から未来をつくる夢物語を現実にしていきませんか(カジュアル面談やってます。ぜひお話ししましょう) https://safie.co.jp/teams/ ここまでお読みくださりありがとうございました。 最後にこの記事とプログラムを手伝って頂いたAIさんからひとこといただきましたので、こちらに掲載させていただきます。 お疲れ様です！

こんにちは、セーフィー株式会社の23卒、新卒エンジニア職入社予定の伊東です。 この記事は Safie Engineers' Blog! Advent Calendar 10日目の記事です。 私たち新卒一期生は入社前に５ヶ月間インターンシップを行ってきました。 このインターンシップの振り返りをしつつ皆さんにセーフィーという会社の教育環境や会社の雰囲気をお伝えしようと思います。 自己紹介 伊東 スキルセット セーフィーを選んだ理由 インターンで期待していたこと 土田 スキルセット セーフィーを選んだ理由 1.会社と事業のビジョンに共感できる 2.エンジニアとして成長できる環境 なぜインターンをしようと思ったか インターンで取り組んだこと Udemy講座 チーム開発 1. 仕様書作成(半月) 難しかった点 心がけた点 画面遷移図 ER図 2.開発環境構築(２週間) フロントエンド バックエンド ぶつかった壁 心がけたこと 3. 実装(2ヶ月) ぶつかった壁 4. 結合テストとデプロイ(1週間) 結合テスト デプロイ 完成したアプリケーション 1. ログイン画面 2. ユーザー一覧表示画面 3. ユーザー情報詳細表示画面 4. ユーザー情報変更画面 インターンで学んだこと 伊東 土田 まず、今回のテックブログは2人で書いたので、それぞれ自己紹介させてください。 自己紹介 伊東 改めまして、23卒、エンジニア職入社予定の伊東です。私は、大学では水産学部といういわゆる情報系ではない学部からエンジニアを目指してこの業界に入ってきました。 スキルセット python暦2年(濃縮すると1年ぐらい) 他社の長期インターンでバックエンド(FastAPI)を使用し、約7ヶ月働いていた 競技プログラミング(AtCoder)は茶色になったばかり 大学の研究でfortran90という超レガシー言語を3年ほど使用している(早くやめたい) セーフィーを選んだ理由 就活シーズン、昨今の意識高い系youtube、(ニュースピックス、 日経テレ東大学等)の動画を見すぎていつの間にかベンチャー思考になっていました。その中で、勢いのある会社を探していたところ、就活していた2021年12月当時に上場したばかりのセーフィーを見つけ、選考に進んだところ内定をいただけたのでそのまま承諾しました。 インターンで期待していたこと フロント、インフラを実際に触り、web開発がどのように成り立っているのか知りたいと思いました。 土田 こんにちは、もう一人のブログの筆者で23卒の新卒エンジニア職入社予定の土田です。 私は大学は工学部で、現在は大学院でロボットアームとAIについての研究に取り組んでいます。また、研究室は立ち上げ一期目のタイミングに入り、環境構築のところから卒業研究を実装するところまでをやり遂げる経験をしてきました。 スキルセット ロボットの研究をC++でゼロから実装(２年) AIをpythonで実装(1年) 趣味の範囲ででC#を用いたwindowsデスクトップアプリ開発 (1か月) セーフィーを選んだ理由 私はセーフィーに対して二つの点で魅力を感じました。 1.会社と事業のビジョンに共感できる セーフィーのビジョンである「映像から未来を作る」を聞いて私はテクノロジーが社会に本格実装する未来を想像し、自分もその未来を作る一員になりたいと強く思いました。 2.エンジニアとして成長できる環境 セーフィーの技術領域はWebのフロントエンド、サーバーに加えてAIエンジニア、組み込みエンジニアの領域もあり、エンジニアとしてのキャリアの幅の広さに大変魅力を感じました。また自ら積極的に開発事業の立ち上げもできる期待もあり、成長環境としても最高だと思いました。 なぜインターンをしようと思ったか 一流のエンジニアから実際の開発現場で活かせる知識を身につけたい これまで開発の知識をほとんど独学で身につけていましたが、知識の偏りを感じていたため、本場の環境でバランスよく矯正したいと思いました。 チーム開発を経験したい これまでは研究や趣味での個人開発しか経験がなかったのでチーム開発の中で自分がどう役に立てるかを見出したいと思いました。 インターンで取り組んだこと セーフィーの新卒エンジニア向けインターンは以下のような流れで行われました。 Udemy講座(1ヶ月半) チーム開発(3ヶ月) Udemy講座 上長の方に選んでいただいた、今後エンジニアとして知っておいて欲しい技術として、SQLやドキュメント作成の方法フロント、バックエンド、インフラの基礎を受講しました。実際に手を動かしながら、今後エンジニアとして必要な知識を大量にインプットしました。 チーム開発 チーム開発は、フルリモートで、来年から同期になる23卒エンジニア内定者の4名で行いました。開発が始まって最初に要件が伝えられました。 ユーザーとデバイスの紐付けを管理するためのwebサイトが欲しい ユーザー、デバイスはそれぞれ、グループに所属しているのでその紐付けもして欲しい この要件以外には特に制約はなく、どんなフレームワークを用いるかなどはチームで自由に決めることができました。 開発の流れは大まかに以下のようになります。 仕様書作成 開発環境構築 実装 テストとデプロイ ここから一つ一つチーム開発の過程を述べていきたいと思います。 1. 仕様書作成(半月) 作成した仕様書は以下の4つです。 画面遷移図(画面とその遷移を現した図) クラス図(バックエンドの設計) ER図(データベース設計) シーケンス図(バックとフロントの関係をみる図) 難しかった点 仕様書の作成を誰も経験したことがなくどんな内容を書くべきか分からなかった 心がけた点 仕様書作成の目的を「メンバー間の認識のずれを解消するため」とした とりあえずできる範囲で形にして上長から早めにフィードバックを得て何度も修正した 画面遷移図 ER図 2.開発環境構築(２週間) フロントエンドとバックエンドでGitHubのリポジトリを分けて環境構築を行いました。 フロントエンド Vue.jsを使用 Vue-cli環境でyarnを用いてパッケージ管理 Dockerファイルの作成 リンターとフォーマッターを用いるためにEslintとprettierを設定 ユニットテストのためにJestの環境設定 バックエンド APIはFastAPI, データベースはMySQLを使用 poetryを用いたパッケージ管理 Dockerファイルの作成 リンター・フォーマッターはflake8, mypy, black, isortなどを併用 ユニットテストはpytestを用いて実施 ぶつかった壁 Eslint、 prettier、JestとVue-cliとの接続 FastAPIとMySQLのDockerコンテナ間の接続 心がけたこと ネットの記事をそのまま応用するだけではうまくいかなかったので、ローカルでひたすら実験を繰り返しながら解決策を探る チーム間で丁寧にレビューし合い、参考になる記事をみんなで見つけてアイデアを出し合う 3. 実装(2ヶ月) 実装にあたって、Githubを用いた開発を行うこととしたため、始めに開発の流れをチーム内で共有しました(どのブランチにマージするかやissueの書き方等)。 また、インターンでの学びを最大化するためメンバーみんながフロントとバックエンドの実装の両方に携われるように役割分担しました。しかし、いざ開発を進めてみると予定工数から2ヶ月も超過することに、、、 ぶつかった壁 1.フォルダ構成、クラス名、関数名、変数名において個人の色がでてしまい、その都度、ルール決めをする必要があった(工数が超過した大きな要因となりました) 対策: 命名規則をpython, Vue.jsのそれぞれで調べ、根拠をもって統一 2.詰まった時に誰に聞けば良いかわからない 対策: 普段から開発以外の中でもコミュニケーションを取ってお互いの強い分野を把握 3.インターン終了の期限が迫っている 対策:チーム内でやらないことを話し合うようにし、必須ではない工程(例: ユニットテスト)を削った 4. 結合テストとデプロイ(1週間) 実装で大幅に工数が超過し、インターンの残り期間一週間というところまで追い込まれていました。そこで効率を重視するため結合テストを三人、デプロイ一人で役割を完全に分けてスピード重視の体制をとりました。 結合テスト テストケースを作成する(全部で150ケースほどになりました) テストケースを一つ一つ実行しバグがあれば新たにイシューを作成 イシューをもとにコードの修正 ぶつかった壁: テストケースについて開発者目線ばかりの視点になっていて、ユーザー目線で考えられていなかった 対策: テストケースを考えるうえで先に大まかな観点を決め、それがユーザー目線になっているかを徹底的にフィードバックを受けてそのあと詳細にテストケースを作成 デプロイ AWSのEC2インスタンスをフロントとバックエンド両方に構築し、EC2内でDockerコンテナを作成してその内部でフロントはnginx、 バックエンドはuvicornによってプログラムを動作させました。 ぶつかった壁: ここ数年でサードパーティークッキーの制限が厳しくなった影響で、デプロイの際にブラウザにクッキーが保存されなかった 対応: もともとhttpドメインを使用していたが、ssl証明書をAWSから取得しhttpsドメインを使用することでセキュリティ要件に対応できるようにした クッキーの設定をhttps専用に設定を変更する 完成したアプリケーション 開発の終了日ギリギリまでかかりましたが、何とか要件を満たしたアプリケーションを作成することができました。以下が完成したアプリケーションの概要になります。 1. ログイン画面 メールアドレスとパスワードで認証を行う画面です。 2. ユーザー一覧表示画面 データベース内に存在するユーザーの一覧を表示します。 3. ユーザー情報詳細表示画面 マウスで選択したユーザーアカウントの詳細情報を表示します。また、所属(ユーザーグループ)や紐づいているデバイスも表示します。 4. ユーザー情報変更画面 ユーザーのアカウント情報の更新や新規アカウントの作成を行う画面です。 インターンで学んだこと 伊東 このインターンでは当初私が求めていた以上のことを学ぶことができたと思っています。 １つ目は、0から開発を行う経験です。これは、今回のインターンで最も大きな学びになりました。要件から初めてシステムを作成することは、すでに存在するシステムをアップグレードするのとは別の知識や技術がいるということを知ることができました。 2つ目はチームで開発する際のノウハウです。今回のチームは全員同期であることから、フラットに質問、会話をすることができましたが、時には意見が対立することがありました。そのような中でも開発を進めていくためには、コーディング技術以外のコミュニケーションが大事であるということを再確認させられました。 土田 私は今回のインターンをやってよかった点が三つあります。 一つ目は開発現場で活かせる知識をバランス良く得られたことです。UdemyやデイリーMTGでの上長への質問によって、体系的なところから実際に現場で使われる範囲までバランスよく身につけられました。 二つ目はチーム開発をスムーズに進めるための知見を実践を通して得られたことです。納期に間に合う開発にするために工程を細かく分割しそれぞれ工数の予定を立てることが大切だと分かりました。また、実際どれほど工数を消化するのにかかったかを振り返ったうえで自分たちの工数の見積もりの甘さも実感したので、今後より改善していきたいと思います。 三つめは開発に没頭するとユーザー視点を忘れがちになることに気づけたことです。特に仕様書作成やテストケースを考える際に自分がユーザー目線になれていないことを実感しました。開発のことで頭がいっぱいのときでもこの機能やユーザーにとって本当に必要か？という問いを自分で立てていけるエンジニアになっていかねばと強く思いました。

こんにちは、セーフィー株式会社 サーバサイドエンジニアの河津です。 この記事は Safie Engineers' Blog! Advent Calendar 6日目の記事、また enebular Advent Calendar 23日目の記事です。 約1年前に、弊社から提供しているSafie APIとNode-REDを連携して、ローコードな仕組みで会議室の空き状況を見る試みを記事にさせていただきました。 engineers.safie.link 今回はその続編ということで、この1年でSafie APIに追加された機能を用いて、部屋に入退室された方の時間と体温を把握するような試みをしてみようと思います。特に体温を取得できるというのは、ご時世的にもかなり需要があるのではないでしょうか。 Safie APIやNode-REDについての説明も上記記事内でさせていただいています。この記事内では説明を省略しますが、もし良ければ上記記事を読んでいただけると、この記事もわかりやすくなるかもしれません！ 今回作るもの Safie Entrance2とは フローの解説 injectノード functionノード(Safie APIへ送るリクエストパラメータ作成) http requestノード functionノード(Safie APIからレスポンスパラメータを受け取り加工する) slackノード フロー実行 まとめ 今回作るもの その日に部屋に入退室があったログを取得し、ログに含まれる入退室時間と体温情報を定期的にSlackに送るようなものを作ってみます。 入退室のログを確認するには、弊社から提供しているサービス「Safie Entrance2」を使用します。 Safie Entrance2とは Safie Entrance2は、顔認証端末を用いて自動解錠を行うことができる、クラウド型入退室管理サービスです。 顔認証なのでICカードなどと違い紛失やなりすましのリスクがないのと、データはクラウド管理されるためどこでも入退室履歴を確認することができます。 safie.link 入退室者の情報は、顔認証端末で解錠を行う際にサーバに溜まっていきます。溜まっていくデータは主に入退室した「日時」と、顔画像から画像処理にて割り出した「体温」が保存されます。 この情報を、Safie APIを用いて取得することができるようになりました。下記の「入退場一覧取得API」を使用します。 openapi.safie.link それでは、情報の取得ができるようNode-REDのフローを作っていこうと思います。 フローの解説 Node-REDで下記のようなフローを作ってみました。前回と同じように、今回もクラウドのNode-RED環境であるenebularというサービスを使いました。 www.enebular.com それぞれのノードの役割について解説していきます。 injectノード injectノードは手動でノードを始動させたり、一定間隔で実行させることができるノードです。 「inject実行」というボタンでフローを開始できるほか、実行間隔や繰り返しのあり・なしも設定することができます。 ノード同士で値を受け渡しする際は、 msg.payload というJavaScriptオブジェクトの中に値を作ってやりとりをしますが、今回はこのinjectノードから次のノードに値を受け渡すようなことはしないので、 msg.payload はデフォルト設定であるタイムスタンプを送るようになっています。 functionノード(Safie APIへ送るリクエストパラメータ作成) functionノードはノード間で受け渡しを行う msg.payload を加工することができるノードで、JavaScriptを用いて内部処理を記載することができます。 入退場取得APIはいくつかの条件で検索をかけることができますが、今回は特定の端末に紐づく入退場データを取得するために、 terminal_id を指定してデータを取得することにします。 http requestノード その名の通りHTTP Requestを行えるノードです。ここでは実際に入退場一覧取得APIが実行できるように、エンドポイントやアクセストークン情報などを入力していきます。 ※アクセストークンの取得方法については、こちらの記事に記載があります。 engineers.safie.link functionノード(Safie APIからレスポンスパラメータを受け取り加工する) 入退場取得一覧APIからは下記のようなレスポンスが返ってきます。 { total : 617 , offset : 0 , count : 20 , has_next: true , list : [ { detection_id: xxx , timestamp : " 2022-11-17T11:28:28+00:00 ", terminal : {} , // 割愛 result : false , person : null , temperature : 36.1 } ] } timestamp が入退場の日時であり、 temperature が体温の値です。 このレスポンス情報をSlackに送信するために加工を行います。 var list = msg.payload.list var response = "" list.forEach( function (obj, index) { var timestamp = obj.timestamp var temperature = obj.temperature response += "入退場時間:" + String (timestamp) + " 体温:" + String (temperature) + " \n " } ) msg.payload = response return msg; やってることとしては、入退場日時と体温情報をメッセージとともに1行の文字列にして、取得できるオブジェクト分改行しているだけです。 slackノード Slackに送信を行うことができるノードです。 SlackのWebhook URLと投稿したいチャンネル名を指定するだけで、 msg.payload の内容をSlack投稿してくれる便利ノードです。 Webhook URLの取得方法はこちらの記事を参考にさせていただきました。 qiita.com フロー実行 作成したフローを実行してみます。injectノードの「inject実行」をクリックすると・・・ このようにSlack送信できました！ あとはinjectノードを一定間隔で実行するような形で設定すれば、「定期的に入退場データをSlackに送信してくれる仕組み」の完成です！ まとめ 前回の記事を書く際にも感じていましたが、ローコードにシステムを作れるNode-REDとSafie APIは、かなり相性良いなと感じています。 この記事を書くためにNode-REDを色々と動かしていましたが、フローの組み始めからSlack投稿が完了するまで大体1時間かからないくらいで作成できました。(前回記事の知見を多数流用できたというのも大きいですが) プロトタイプ的に物作りをする上では便利ですね。 Safie APIは継続的に機能追加が行われていくため、しばらくしたらまた試してみたいなと思います！ここまでお読みいただきありがとうございました！

Safie Engineers’ Blog! Advent Calendar 12月5日を担当します。yokと申します。 Safie の本社には、「テックステージ」と呼ぶショールームスペースがあります。 (一般公開しているものではなく、打ち合わせなどでご来社いただいた方へのサービス紹介が主です。) テックステージ スマートプラグ スマートリモコン ここでは、Safie が取り扱うカメラの数々、最新機種 Safie One やそのAI 機能( Store People Detection Pack )、顔認証による入退管理( Safie Entrance2 )、 POS レジ連携 など、さまざまなサービスを体験できるようになっています。 タイミングによっては、検証を兼ねてリリース前の機能が展示されていることもあります。 Webサービスを展示しているため、多数のPCやディスプレイが稼働しています。 その他、市販のTVを8台繋いだ、手作り感のあるディスプレイウォールもあります。 これらのディスプレイをどう管理するか。以前のオフィスはモニターの台数が少なかったこともあり、つけっぱなしでもあまり気にならなかったのですが、これだけの台数になると、使わない時は消す必要があります。 オフィスのショールームに求められる要件としては できるだけ手間をかけず、自動的に起動・終了して欲しい 土日、祝日など営業していない日は使用しない(節電!) これらを満たすような電源管理が求められます。 あの手この手を試しましたが、、、最終的に「スマートホーム化」することにしました。 スマートプラグ コンセントをOn/Off することで、家電を無理矢理IoT 化するもの。自宅ではホットカーペットに愛用してます。 今回は SwitchBot 社の製品を使用しました。 https://www.switchbot.jp/products/switchbot-plug 公式のAPI で簡単にON/OFF 制御ができます。 https://github.com/OpenWonderLabs/SwitchBotAPI スマートリモコン インターネット経由で操作できるリモコン。こちらは M5Stack ATOM で自作しました。 TV のリモコン制御で困るのが、ON と OFF に同じリモコンコードが割り当てられているということです。つまり、現在ON なのか、OFF なのかわからないと、間違った制御をしてしまう可能性があります。 ネットの情報を調べて「何回か押す」というハックに辿り着きました。 参考: https://besma9.net/smart-remocon-tv-light/ メーカーや機種によって動作が異なるようで、今回制御したいTV は2回だとうまくいかず、「3回連続でON すると、ON状態でもOFF状態でも、必ず ONになる」ということがわかりました。 全部スマートプラグでもよかったのですが、PCとの相性で、「主電源を落とすとマルチディスプレイの設定が消える」箇所があり、一部リモコンでのON/OFF制御をおこなっています。 自作リモコン 3画面のそれぞれに確実に届くよう、IR信号を分配してTV の裏から操作するようにしています。 遠隔操作は Slackbot として実装し、専用のチャンネルで ("IR_ON"、"IR_OFF") といったメッセージを送るとON, OFF できるようにしました。 これらの制御をスクリプト化し、定期実行することで、要件を満たす制御が完成しました。 平日か土日祝かの判定も、スクリプト内で行っています。 ショールームのオープン当初は、出社が早いCEO や、遅くまでいるCFO が、手動でオン・オフしていたということもあって、自動化は課題でした。また、スマートプラグは消費電力が見えることもあって、あらためて節電意識が高まりました。 大画面TV の省電力はやばい。

こんにちは、セーフィーでバックエンドのエンジニアをしております神田です。 今回は、バックエンドのAPIを開発する際に使用しているフレームワークについてお話ししていこうと思います！ API開発で使用しているフレームワークの紹介 Tornado FastAPI FastAPIを使用するまでの流れ FastAPIの何がよくて採用したのか 速い ドキュメントが自動生成される 実際に使ってみて感じること ドキュメント自動生成が本当に助かる 簡単にデータの堅牢性が保たれる まとめ API開発で使用しているフレームワークの紹介 まず初めに、現在使用しているフレームワークについて紹介します。 Tornado 公式リンク セーフィーのサービスができた当初(2014年)から使われています。 複数あるフレームワークの中から、APIのみで使用する前提で パフォーマンス 開発のしやすさ デバッグのしやすさ の観点から、当時最も条件を満たしているために採用されたそうです。 FastAPI 公式リンク FastAPI自体は2018年にリリースされ、近年人気を集めているフレームワークです。 セーフィーでは2020年以降に新たに作成されたAPIサーバーで使用されています。導入の理由はこれからお話しします！ FastAPIを使用するまでの流れ もともとはtornadoですべてのAPIを開発していましたが、完全に新規のコンポーネントを開発することになり、せっかく新しく作るのであればtornadoにこだわる必要もないとのことで、その当時評判になりつつあったFastAPIをお試しで採用してみようという話になりました。 これが2020年ごろの話で、創業当初にはなかったFastAPIを導入するきっかけになりました。 FastAPIの何がよくて採用したのか 実際にFastAPIのどのようなところが魅力的で、導入に至ったのかをお話ししたいと思います。 速い 名前からもわかるように、FastAPIは速いことが特徴の1つで、公式ドキュメントにも「NodeJS や Go 並みのとても高いパフォーマンス 」と書かれています。 参考 Web Framework Benchmarks で確認すると、2020年時点ではFastAPIはかなり速いフレームワークであることがわかります。 Web Framework Benchmarksでベンチマークが示されているフレームワークの中で、FastAPIは全体4位、tornadoは29位でした。 表1. 1リクエストあたり20クエリでの1秒あたりのレスポンス(2022年時点) フレームワーク 1リクエストあたり20クエリでの1秒あたりのレスポンス FastAPI 12,991 Tornado 1,354 ドキュメントが自動生成される FastAPIでは作成したAPIのドキュメントが自動で生成されます。 ドキュメントを別途作成する手間がなくなるので、 ドキュメントの作成忘れ ドキュメント作成の手間 がなくなります。 実際に使ってみて感じること 現在、当初からあるコンポーネントはtornado、新規のコンポーネントはFastAPIで開発しているので、実際に開発していて両者にどのような違いがあり、FastAPIにどのような良さがあるかを2点お話ししようと思います。 ドキュメント自動生成が本当に助かる FastAPIの採用理由でも触れましたが、ドキュメントが自動生成されることで得られるメリットは想像以上でした。 tornadoでAPIを開発する場合、 仕様書のPRを作成 APIを実装するリポジトリでAPIを実装しPRを作成 APIに修正が入った場合も2つのリポジトリでPRを作成 という作業が必要になっています。 リポジトリが分かれている上、両者が連動されていないため、とくに、緊急に軽微な修正を行った際にドキュメントの修正漏れが発生してしまいます。 そうすると、APIを組み込むフロントエンドとモバイルの方が誤ったドキュメントを見ながら組み込んでしまい、うまく動作しないなどということが発生しかねません。。 FastAPIではこのような問題を全て手間なく解決してくれました！ 簡単にデータの堅牢性が保たれる FastAPIはpydanticがベースになっていて、リクエスト・レスポンスのデータ型を簡単に定義することができます。 下記のようなAPIを考えます。(例のためなので内容に意味はありません) FastAPI @ router.get ( "/api/hoge" ) async def get_hoge ( id : Optional[ int ] = Query( max title= "id" ), name: str = Query(max_length= 200 , title= "名前" ) ): id, nameをリクエストパラメータにもつgetのAPIです。 idは数値で任意パラメータ、 nameは文字列で必須パラメータであることがわかります。これをtornadoで書くと、 Tornado class HogeHandler (self): def async_get (self): id = self.get_argument( "id" , None ) if not instance( id , int ): raise Exception () name = self.get_argument( "name" , None ) if name is None : raise Exception () if not instance(name, str ): raise Exception () if len (name) > 200 : raise Exception () 条件分岐をたくさん書かなければなりません。。 このように、FastAPIではデフォルトで簡単にバリデーションの記述ができます。また、FastAPIの方がどのようなバリデーションをしているのか一目で理解できる上、自前で用意する必要がないため、データの堅牢性が保たれ、予想外のエラー発生を防いでくれます！ さらに、pydanticのBaseModelを使用すれば、ネストしたデータのバリデーションもできますし、レスポンスの型定義をすることで必要なデータを返却し忘れることもなくなります。 まとめ セーフィーでは、使い慣れた技術や手法を常に選ぶのではなく、その都度最適な技術を選定して開発を行っています。実際、FastAPIを導入することでたくさんの恩恵を受け作業効率も上がりました。 技術は日々進化するので、新しい技術情報にアンテナをはってより良いプロダクト・開発環境を作っていきたいな〜と思います！

サーバサイドエンジニアの松木 ( @tatsuma_matsuki ) です。Safie解析プラットフォームやSafie APIの開発を主に担当しています。 この記事は Safie Engineers' Blog! Advent Calendar 4日目の記事です。 解析プラットフォームでは、学習済みモデルおよびランタイムをSafieクラウド上に登録することで、Safieサービスで録画したカメラの映像・画像に対して、任意の推論処理を実行し、その実行結果をイベントとして保存することができます。 まだサービス公開はされていませんが、まずは社内エンジニアで利活用の推進したいという思いから、Safie解析プラットフォームを利用したアプリケーションの開発を実践しています。 私はサーバサイドのエンジニアで、機械学習の分野には明るくないのですが、今回解析プラットフォーム上でのアプリ構築を一から自力で開発可能にするために、学習済みモデルの作成と推論処理の実装を初めてやってみました！ 結果として、なかなか高い精度を出すまではまだ少し時間がかかりそうですが、その作業・開発工程をこの記事で共有したいと思います。 開発するアプリケーション 画像や動画の収集は簡単！ 学習（モデル作成） データの分割 データの拡張 ベースモデルの読み込み 学習の実行 推論処理の実行 精度の評価 AIモデル作成は簡単ではなかった 開発するアプリケーション まずは適当に思いついたものを開発してみよう！ということで、オフィスにいる弊社のCTOがカメラに写ったら検知して、通知（メール・Slack）を出すようにすることを目標としました。 弊社の五反田オフィスは、4F、5F、8Fの3フロアあり、分析対象として使えそうなカメラが10台弱ほど設置されています。様々なアングルや大きさで人が写りこみますが、全てのカメラで汎用的に使用できるアプリケーション（モデル）を作成できればベストです。 画像や動画の収集は簡単！ Safie社内で学習用の画像を集めるのはとても簡単です！ オフィス内にカメラが既に常時稼働しており、過去の映像も全て確認できるため、Safie Viewerからポチポチやるだけで画像がどんどん集まります。 Safie Viewerのストリーミング画面を開いて、右上のカメラのアイコンをクリックするとその時に写っている画像のスナップショットが取得できます。 実質1～2時間ほどで、様々なカメラから合計400枚ほどの学習用画像が集まりました。 学習（モデル作成） 今回開発するアプリケーションの場合、入力画像を「CTOが映っている」「CTOが写っていない」の二つに分類するモデルを作成する必要があります。 Efficientnetという有名な分類系のモデルをベースモデルとしてファインチューニングします。 arxiv.org また、以下のKaggleのnotebookを参考にして、学習処理部分を実装しました。 www.kaggle.com 以下では、その処理内容をざっくりと順を追って説明します。 データの分割 まず、 scikit-learn の train_test_split 関数を使って、集めた画像を用途ごとに分割します。 今回は、70%の画像を学習データ、15%の画像を評価データ、残りの15%をテスト用データとしてランダムに分割しました。 filepaths = [] labels = [] # `label_file_path`で指定したパスには、<画像ファイルのパス>,<ラベル> が列挙された # CSVファイルが置かれています。 with open (label_file_path) as f: reader = csv.reader(f) for row in reader: filepaths.append(row[ 0 ]) labels.append(row[ 1 ]) f_series = pd.Series(filepaths, name= "filepaths" ) l_series = pd.Series(labels, name= "labels" ) df = pd.concat([f_series, l_series], axis= 1 ) train_df, tmp_df = train_test_split( df, train_size= 0.7 , shuffle= True , random_state= 123 , stratify=df[ "labels" ] ) valid_df, test_df = train_test_split( tmp_df, train_size= 0.5 , shuffle= True , random_state= 123 , stratify=tmp_df[ "labels" ], ) データの拡張 深層学習ライブラリである Keras の ImageDataGenerator を使ってデータを拡張します。 gen = ImageDataGenerator( horizontal_flip= True , rotation_range= 20 , width_shift_range= 0.2 , height_shift_range= 0.2 , zoom_range= 0.2 , ) aug_img_count = 0 required = 100 # 作成する拡張画像の枚数 aug_gen = gen.flow_from_dataframe( df, x_col= "filepaths" , y_col= None , target_size=img_size, class_mode= None , batch_size= 1 , shuffle= False , save_to_dir=target_dir, # `target_dir`で指定したディレクトリに作成されます。 save_prefix= "aug-" , color_mode= "rgb" , save_format= "jpg" , ) while aug_img_count < required: images = next (aug_gen) aug_img_count += len (images) ベースモデルの読み込み 出力層付近を除いたモデルを読み込み（ include_top=False ）、2クラスの分類結果を出力するように置き換えます。今回はEfficientnet B3のモデルを利用しています。 base_model.trainable = True にするとファインチューニング、 False にすると転移学習となります。 base_model = tf.keras.applications.efficientnet.EfficientNetB3( include_top= False , weights= "imagenet" , input_shape=img_shape, pooling= "max" ) base_model.trainable = True x = base_model.output x = Dropout(rate= 0.4 , seed= 1 )(x) output = Dense(class_count, activation= "softmax" )(x) model = Model(inputs=base_model.input, outputs=output) model.compile( Adamax(learning_rate=lr), loss= "categorical_crossentropy" , metrics=[ "accuracy" ] ) 学習の実行 引数に、学習用データ（ train_gen ）と検証用データ（ valid_gen ）を指定して model.fit() を実行すると学習がスタートします。 model.fit( x=train_gen, epochs=epochs, verbose= 1 , callbacks=callbacks, validation_data=valid_gen, validation_steps= None , shuffle= False , initial_epoch= 0 , ) model.save(model_save_path) コンソールの出力を見ていると、 accuracy や val_accuracy の値が良くなっていくのが分かります。とりあえず、学習はうまく進んでいるようです。 Epoch 1/40 20/20 [==============================] - ETA: 0s - loss: 8.0606 - accuracy: 0.7800 validation loss of 9.0880 is 0.0000 % below lowest loss, saving weights from epoch 1 as best weights 20/20 [==============================] - 76s 3s/step - loss: 8.0606 - accuracy: 0.7800 - val_loss: 9.0880 - val_accuracy: 0.7000 Epoch 2/40 20/20 [==============================] - ETA: 0s - loss: 6.8788 - accuracy: 0.9050 validation loss of 7.7559 is 14.6582 % below lowest loss, saving weights from epoch 2 as best weights 20/20 [==============================] - 34s 2s/step - loss: 6.8788 - accuracy: 0.9050 - val_loss: 7.7559 - val_accuracy: 0.7000 Epoch 3/40 20/20 [==============================] - ETA: 0s - loss: 6.2107 - accuracy: 0.9225 validation loss of 6.1968 is 20.1025 % below lowest loss, saving weights from epoch 3 as best weights 20/20 [==============================] - 34s 2s/step - loss: 6.2107 - accuracy: 0.9225 - val_loss: 6.1968 - val_accuracy: 0.9167 Epoch 4/40 20/20 [==============================] - ETA: 0s - loss: 5.6444 - accuracy: 0.9350 validation loss of 5.6057 is 9.5382 % below lowest loss, saving weights from epoch 4 as best weights 20/20 [==============================] - 35s 2s/step - loss: 5.6444 - accuracy: 0.9350 - val_loss: 5.6057 - val_accuracy: 0.9500 Epoch 5/40 20/20 [==============================] - ETA: 0s - loss: 5.1150 - accuracy: 0.9500 validation loss of 4.9568 is 11.5753 % below lowest loss, saving weights from epoch 5 as best weights 20/20 [==============================] - 37s 2s/step - loss: 5.1150 - accuracy: 0.9500 - val_loss: 4.9568 - val_accuracy: 0.9833 Epoch 6/40 20/20 [==============================] - ETA: 0s - loss: 4.6689 - accuracy: 0.9675 validation loss of 4.5310 is 8.5913 % below lowest loss, saving weights from epoch 6 as best weights 20/20 [==============================] - 34s 2s/step - loss: 4.6689 - accuracy: 0.9675 - val_loss: 4.5310 - val_accuracy: 0.9833 Epoch 7/40 20/20 [==============================] - ETA: 0s - loss: 4.2913 - accuracy: 0.9900 validation loss of 4.2057 is 7.1782 % below lowest loss, saving weights from epoch 7 as best weights 20/20 [==============================] - 34s 2s/step - loss: 4.2913 - accuracy: 0.9900 - val_loss: 4.2057 - val_accuracy: 0.9500 Epoch 8/40 20/20 [==============================] - ETA: 0s - loss: 3.9923 - accuracy: 0.9750 validation loss of 3.9645 is 5.7369 % below lowest loss, saving weights from epoch 8 as best weights 20/20 [==============================] - 34s 2s/step - loss: 3.9923 - accuracy: 0.9750 - val_loss: 3.9645 - val_accuracy: 0.9500 Epoch 9/40 20/20 [==============================] - ETA: 0s - loss: 3.7193 - accuracy: 0.9725 validation loss of 3.6385 is 8.2214 % below lowest loss, saving weights from epoch 9 as best weights ... 推論処理の実行 テスト用のデータを model.predict() の引数に渡すことで推論を行うことができます。 推論の結果は、 [0.00226656, 0.99773353] というように、その画像がそれぞれのクラスである確率のようなものを表しているため、数値が最も大きいクラスを分類結果として使います。 image_generator = ImageDataGenerator().flow_from_dataframe( test_df, x_col= "filepaths" , y_col= "labels" , target_size=image_size, class_mode= "categorical" , color_mode= "rgb" , shuffle= False , batch_size=batch_size, ) results = [] predicts = model.predict(image_generator, verbose= 1 ) for i, p in enumerate (predicts): file = image_generator.filenames[i] label_index = image_generator.labels[i] predicted_index = np.argmax(p) results.append(( file , predicted_index, label_index, p)) print (results) 精度の評価 最初に用意した15%のテスト用画像（61枚）に対して評価してみた結果が以下の通りです。 label precision recall f1-score support 0 1.0000 0.8571 0.9231 21 1 0.9302 1.0000 0.9639 40 さくっとやった割に簡単に精度が出て、かなり驚きました。 AIモデル作成は簡単ではなかった しかし！ 別途、別の人が用意したテスト用の画像に対して推論を実行して評価すると、precision 0.5, recall 0.8！！という残念な結果でした。ほとんどランダムで0, 1選択したのと変わらない！！ 全くの未知の画像に対して精度を出すことの難しさがわかりました。。 おそらく私が集めた学習用データセット全体に対してかなり偏りがあるのではないかという考察をしているのですが、実際のアプリケーションとして使えるレベルにするにはもう少し試行錯誤が必要そうです。 精度を出すためにはもう少し勉強が必要そうですが、分類系の学習済みモデルの作成～推論処理の実装までを一通り経験することができました！ Safieのサービスを利用すると画像収集の部分はかなり楽なので、その点は大きなメリットがありそうです。が、まだまだ手間であることには変わりないので、ラベル付きのCSVのような形である程度まとまった単位で画像ダウンロードできるようになるとなお良さそうです。この辺りはフロントチームと連携して利便性を向上させていきたいと思います。 推論の精度を上げて、無事にアプリケーションが完成しましたらまたこの記事で結果を共有したいと思います！