はじめに セーフィーの髙木( @hitsan8 )です。 セーフィーは2025年2月13、14日に行われたDevelopers Summit 2025（以下デブサミ）にブーススポンサーとして参加しました。 デブサミとは2003年から開催されているITエンジニアのための祭典です。今年のテーマは「 ひろがるエンジニアリング 」です。 event.shoeisha.jp 多くの方にセーフィーを知ってもらうために2023年から参加し続けて今年で3回目になりました。 この記事はデブサミのブーススポンサー参加レポートになります。 はじめに ブースのデザイン アニマルマスクのデモ 展示パネル さいごに ブースのデザイン 2024年にロゴをリニューアルしたのでブースで使用する備品、ノベルティを一新しました。 去年までは白をベースにしたデザインでしたが、今年はコーポレートカラーであるセーフィーブルーを基調としたデザインに仕上げています。 例えばバナースタンドはこのようなデザインになっています。 実際のブースに並べてみるとこんな感じになります。 全体の色味をそろえたので統一感がでたのではないでしょうか。 実際にお客さんに説明している様子はこんな感じでした。 ブースではアニマルマスクのデモとパネルの展示をしました。 こちらもそれぞれ紹介していきます。 アニマルマスクのデモ プライバシーマスクという機能があり、これは個人の特定を防ぐために映像の一部を隠す機能です。 通常は映像を隠すためにモザイク処理することが多いですが、今回は検出した人の上に動物のイラストを被せてアニマルマスクとして展示しています。 会場では三脚を使って俯瞰で撮影するようにしました。 この画角がセキュリティカメラっぽいですね。 実際にアニマルマスクを動かすとこんな感じです。 自分の顔が動物になっているのでお客さんの目を引くことができました。 こちらはお客さんや他のブースの方々から面白い、かわいいというお声をいただきました。さらに、内部のアルゴリズムやセキュリティについて興味を持たれた方も多かったです。 展示パネル 今回はアニマルマスクのパネルと技術スタックのパネルを展示しました。 どちらもコーポレートカラーを基調としたデザインにしています。 このパネルは動物たちの質問にセーフィーくんが回答してくれるという内容になってます。 楽しそうな雰囲気が伝わってきますね。 技術スタックのパネルはエンジニアの方々に好評でした。 「セーフィーではこれを使ってるけどうちの会社ではこれを使ってる」みたいな会話が生まれていました。 さいごに 2日間のブース出展を無事に終えることができました。実際にプロダクトを見てもらい、その場でフィードバックをもらえたので非常によい体験でした。 スタッフの感想としては アニマルマスクでエッジの処理にも興味を持ってもらえてよかった。 会場が広くてきれいだったのでおどろいた。 大変だったけど楽しかった。 ノベルティがかわいいと好評でよかった。 今後の改善点として挙がったのは アニマルマスクの動物を検出した人の属性で振り分けけてもよかったかもしれない 生成AIも組み合わせたら面白かったかも マスコットのぬいぐるみを置きたい ゲーム要素も入れたかった セーフィーは今後も認知拡大のため継続的にイベントに参加します。 セーフィーはエンジニアを積極的に募集しています。ご興味がある方は採用ページをご覧ください。 safie.co.jp

はじめに こんにちは！セーフィー株式会社でデバイス開発をしている杉本です。 セーフィーでは普段の業務以外にも、エンジニアのスキルアップのために様々な取り組みを行っています。その一つの取り組みとしてエンジニアの「やってみたい！」をボトムアップで実現する活動をしています。 今回はコンセプトの立案からプロトタイプのユーザー検証まで行うプロト開発WG(ワーキンググループ)の活動をご紹介します！ はじめに プロト開発WGの目的 やったこと 他部署からのフィードバック やってみて 最後に プロト開発WGの目的 セーフィーはクラウドカメラサービスを提供しており、様々な現場のユーザーの課題に向き合って新プロダクトの企画・開発を進めています。 営業、企画からの提案で開発をすることが多いのですが、エンジニアだからこその気付きもあります。ユーザーが気付かないような視点からエンジニアが提案ができる組織を実現すべく、プロト開発WGを開催しています！ 今回のワークショップの目的は以下のとおりです。 エンジニア自身でユーザーの課題の仮説を立てて検証し、プロト開発の知見を得ること 業務で使用する技術以外の技術領域にチャレンジしてスキルの幅を広げること やったこと プロト開発WGではコンセプト(仮説)の立案、プロト開発、ユーザー検証の大きく3つのプロセスで進めており、今回のプロト開発WGではデバイス開発部の有志メンバーにて計5か月の期間で実施しました。 コンセプト(仮説)の立案　約2カ月 ユーザーの想定課題 想定課題に対するユーザーへの提供価値 プロト開発　約2カ月 コンセプトを実現するための技術検討 コンセプトを試すためのプロトを開発 ユーザー検証　約1ヶ月 ユーザーにプロトを試してもらい、フィードバックを得る フィードバックから課題を抽出して改善の方向性を特定する コンセプトの立案ではエンジニアならではの視点でアイデアが合計12個出てきたのですが、そこからの絞り込みが苦労しました。ユーザーの課題をどう解決できるのか、どれだけユーザーにとって価値があるのか、などの深堀をしてコンセプトの絞り込みを進めました。 最終的には提供価値だけでなく、技術的に実現ができそうか、他社とは違いがありそうか、今後も活用できそうかの4つの観点で5段階で点数付けをしてコンセプトを1つに決定しました。 このような議論を通じてエンジニアが提案できる組織につながるような視点を養うことができたのではないかと思っています！ また、本活動で実際に立案したコンセプトや開発プロトタイプについてはありがたいことに商品化検討のステップにつながっているので、残念ながら本ブログでご紹介することができません。 ただ、ユーザーの課題に着目してコンセプトをエンジニア自身が考えたため、大変ながらも楽しくプロトタイプの開発ができました！ 他部署からのフィードバック ユーザー検証に協力いただいた各部署の方から本活動についてたくさんのフィードバックがありましたので一部抜粋して公開します！ とてもいい活動だと思いました。営業側では思いつかない視点もありありがたいです。 提案内容が突拍子もないものではなく、既にある機器の拡張や改造で行けるという、夢と現実のはざまの大変バランスの良い所を攻めているので、商品化の可能性が高いと思いました！ 技術オリエンテッドな提案は営業企画としても刺激されるとおもいます。なにより活動メンバーが楽しそうにしていたのが印象的でした！ 非常に面白かった。今すぐ商品に繋がらないことも多いと思いますが、このようなことをやって今後の商品につながる種をいっぱい作って欲しいです。 営業、企画スタートではなく、開発から発信したほうが固定概念に縛られないモノが作れる場合があるし、営業・企画が暗黙のうちに諦めたり後回しにしたものが作られたりするので、今後も継続してほしいです。 想定機能を型にすることで、もっとイメージしやすいです。「こんなこともできることだ」を直感でき、ペーパーより商品に対する理解が深くなる。また、実現可能性も参考になります。 日々とてもお忙しい中、アイディアを形にする時間を取るのは非常に大変だったと思いますが、ここまでWowのあるものを短期間で仕上げており本当に素晴らしいと思いました。 開発側の方がお持ちのアイディアと顧客課題をうまく紐づける活動をしていきたいと考えているので、こういった事がやりたい！これってニーズありそう？といった話はお気軽にしていただければと思います！ 非常に有意義な時間でした！プロトタイプと言いつつ、商品建て付け考えればそのまま売れるのではと思うくらいのクオリティだったのですぐ企画と連携して進めていきたいくらいです。 最終的にプロトタイプの実機デモと合わせて、セーフィー全社員向けのプロト開発WGの報告会を実施しました。 ありがたいことに、オフライン、オンラインのハイブリッドで開催したのですが、100名以上の方に参加いただいて報告会の後も質問が絶えないなど大盛況で終えることができました！ 全社員向けのプロト開発WG報告会の様子 やってみて 参加メンバーにて本活動の振り返りを実施しましたので一部抜粋して公開します！当初の目的についてはおおむね達成できた結果となり、一安心です！ 提案したプロトタイプ4つのうち、3つは具体的にユーザーの現場でのPoCにつながるなどエンジニアのボトムアップの活動から実際の商品化に向けて動き出すという予想以上の結果を出すこともできました！ 反省点としては記載の通りですが、通常業務をしながら本活動の時間をなかなか割くことができずにプロトタイプの開発に苦労してしまったことです。良かった点を活かしつつ次回の活動では改善をしていきたいと思います！ Keep 全員しっかり関わりながら、期間内にコンセプト立案～開発～実機デモまでやりきることができた 業務ではあまり使わないプロダクトや技術の知見が得られた 営業、企画への実機で技術提案をすることで、プロダクト化に向けた前向きな議論ができた Problem プロジェクトなどの主務の忙しい時期と重なると本活動に割り当てる時間が確保するのが難しく、進捗がない時期が発生してしまった トライ＆エラーでの実装となり、予想よりも開発に時間がかかってしまった Try 開発期間は2ヶ月ではなく3～4ヶ月は確保する 新しい技術に挑戦するため、開発期間に余裕が必要なため タスクと担当を明確にして計画を立てて進捗管理する トライ&エラーでの開発が前提だが、計画を立てて進めることで効率的に開発をするため 本活動はトライアルとしてデバイス開発部にて閉じて実施したのですが、他の部署からも参加したいという声が挙がってきており、ゆくゆくは開発本部横串での活動に広げていきたいと思っています。 最後に 本記事では、プロト開発WGの活動についてご紹介させていただきました。 セーフィーではエンジニアを積極的に募集しています。どのような職種があるのか気になる方はこちらをご覧ください！ safie.co.jp カジュアル面談から受け付けておりますので、気軽に応募いただければと思います！ 皆様のご応募、心よりお待ちしております！ 最後までお読みいただき、ありがとうございました。

はじめに こんにちは。 セーフィー株式会社でサーバーサイドの開発をしている金成です。 今回は、サーバーチームで「マイクロサービスアーキテクチャ第2版 」 を題材に、輪読会を開催したので、紹介させてください はじめに 背景 実装/実行 やってみて 終わりに 背景 セーフィーは、サービスの拡大と開発者の増加に伴い、工数の増加やリリースリスクの増大など、開発生産性の問題を抱えています。この問題の解決のために、組織の再編やコードベースの分割によるマイクロサービス化が進行しています。 私を含め開発チームのメンバーには、マイクロサービスとはなんなのか？何を目指してるのか？どういったメリット・デメリットをもたらすのか？などイメージがついていない部分がありました。 そこで、今回の「マイクロサービスアーキテクチャ第2版」を参考に輪読会を開催し、このトピックに対する理解度を深めようとしました。 実装/実行 開催の形式は、下記の通りです 週1回 30-45分で開催 1つの章を取り上げ、参加者は事前に読む 議論したい話題を取り上げ、自由に議論する 議論した内容を簡単に残し、後で見れるようにする 全16章、4ヶ月ほどかけて全ての章で実施しました。 議題は マイクロサービスにおける一番の目的は何か、どんな指標を持つべきか REST/RPC/GraphQL/メッセージキューの使い分け サーガパターンとその適用するケース コンウェイの法則と逆コンウェイ戦略について などがあり、技術的な側面から組織面まで様々な議論をしました。 弊社ではドキュメント管理にnotionを利用してるので、下記のようなテーブルを作成して、議題を管理しています。 下記のように笑顔の絶えない議論が展開され、4ヶ月間笑いが絶えることはありませんでした。 — アットホームな職場の写真サンプル(ﾀﾉｼｲﾖ, ｺﾜｸﾅｲﾖ) やってみて 輪読会後にアンケートをとったところ、下記のような結果が得られました。 よかったところ マイクロサービスへの理解が深まった 参加者の実務経験から周辺知識を補うことができた 対話の機会が増えた 問題点・改善点 事前の準備の時間が足りなかった 発言の機会が足りなかった 時間が足りなかった 事前準備や議論のファシリテーションには問題が残りますが、マイクロサービス化への理解を深めるという当初の目的を達成できたこと、リモートが多い弊社で対話の機会を増やせたことは一定プラスになったかと感じてます。 終わりに 自分の思い付きから企画した輪読会でしたが、参加してくれたメンバーの満足度は概ね高く、やってよかったと感じました。 実は、私もこの秋からマイクロサービス化を進めるチームに参画しています。マイクロサービスについて知らないままだと、仕事がうまく進められません。だから「マイクロサービスアーキテクチャ」を読む必要があったんですね。 セーフィーではエンジニアを積極的に募集しています。気になる方はこちらをご覧ください！ safie.co.jp この記事を読んでもし興味を持っていただけた方は、ぜひ採用サイトもご覧ください。 カジュアル面談のみでも大歓迎ですので、お気軽にご連絡ください。 最後までお読みいただき、ありがとうございました。

はじめに こんにちは！QCDグループに所属している小熊です。 Safie Viewer for PCのQA（システムテスト）を2019年9月頃から担当しているのですが、悩みのタネであった「度重なるバージョンアップによって増え続けるリグレッションテスト項目」の解消を目指してトライしてみたことについて書こうと思います。 セーフィーにおけるQCDグループはどういう事をしているのか？を紹介している記事もございますので、是非こちらもご確認ください！ engineers.safie.link はじめに リグレッションテストについて 暗黒時代 「整理整頓」時代 その後（現在） まとめ リグレッションテストについて Safie Viewer for PCは月イチで新バージョンがリリースされており（過去はもっと頻繁に（2～3週間に1回程度）リリースされていた）、その度に新機能追加や不具合修正などが既存機能に悪い影響（意図していない影響）を与えていないことを確認する必要が有ります。 Safie Viewer for PCは歴史が古いこともあって機能数が多くて思わぬところに開発影響が出たりするため、範囲や対象を絞り込まずに全てのテスト項目の実施（フルリグレッションテスト）をリリース毎に行っています。 暗黒時代 リリース毎に新機能もしくは改修が入るので、リグレッションテスト項目内容もそれに合わせて更新し続ける必要があります。 具体的には新機能は一度リリースされたら既存機能に含まれるのでその内容をリグレッションテストに落とし込んでいるのですが、その度にテスト項目は増え、増え、増え、と増え続け、これまで一番ひどかった時期の項目数をピックアップしたら下記表な感じでした。 リリース月 実施項目数 2022年7月 1083 2022年12月 1230 2023年3月 1584 2023年8月 2102 1年で実施項目数が約2倍！こりゃだめだ。。 この件について頭を悩ませていたポイントを下記にまとめてみました。 テストの実施に時間がかかる 項目ごとに優先度を割り振り、優先度低い項目は毎回は実施しないようにしていたがそれでも限界 テスト項目の視認性が悪くてやりにくい テスト項目のメンテナンスに時間がかかる 1と共通点が多い問題、メンテナンス後に項目レビューするのも大変 テスト自動化対応しにくい テスト自動化対応しにくい 自動化できる／できない（しない）の精査、自動化した後の管理が大変 これとは別に新機能／改修向けのテストの準備や実施が有り、特にテスト期間中はテスト項目消化に追われていた（探索的テストなど、他のことに割く工数が無い） これらによって改善活動（テスト項目の整理整頓）にリソース割くのが困難、改善しないので更に項目が増えていき、さらにリソースが逼迫するという悪循環に陥ってました。 「整理整頓」時代 暗黒時代の中、ただ手をこまねいていたわけでは無く、課題解決のためにはどのような方針で整理整頓する必要があるのかをQAメンバー全員で議論や準備を少しずつ進めていたところ、ある転機がやってきました。 engineers.safie.link ↑の記事にあるテスト管理ツールの導入イベントです。 これまでスプレッドシートでテスト項目を作成＆実施していたものを管理ツールで行うことが決定、せっかく管理ツールへの移行に工数割くなら準備してきた改善案を適用した内容でやってやろうじゃないかとなり、テスト実施にかかる以外の工数をほぼ全振りして整理整頓対応することとなりました。 その時の整理整頓の活動方針は これまでのテスト項目を優先度付けして、優先度高い内容を移行する新項目のメイン機能（骨格）とする 1で決めたメイン機能チェックは、なるべくシンプルにまとめる（肉付け） 肉付けの際は「自動化できる（自動テストのみで完結できる内容）」「できない or 困難（メンテナンスに時間かかるなど）」のように自動化可否を分けて（混在しないように）行う の3点です。 特に①と②の対応に苦心しました。 どの機能を骨にして（いわゆる優先度付け）どれだけ肉付けするかは、「これまでで実施してきた項目」から「どれだけインシデントが検知できてきたか」の分析を行ってその結果を指針にしたり（新しい項目によって実施工数は減ったけどリリース後に見つかるバグが増えた、は許されない）、①や②の対応後に「これまでのインシデントが検知できる内容になっているか」の見直しを行ったり、それをメンバー間でレビューしあったり（①②の実施は各メンバーの感覚によってバラつきが有るので）、とにかく試行錯誤の連続でした。 また、テスト項目での記載内容によってちょっとでも項目を減らすように工夫しました。たとえば「画面AでボタンAの確認」「モーダルBで機能Bの確認」とぶつ切りになっていた2つの項目を「画面AでボタンAを押下した後のモーダルBで機能Bの確認」のように一連の流れで網羅できるような1つの項目へ組み替えたりです。 その後（現在） 整理整頓を頑張り始めてから、その後項目数はどうなったでしょうか。 リリース月 実施項目数 2023年8月 2102 2024年5月 641 2024年12月 665 ピークから3分の1以下まで減りました（拍手！） ただし気を抜くとあっという間に以前に逆戻りしてしまう（実際、5月から少しずつ増えている）ので活動の継続は必要なのと、浮いた工数をどのように有効活用していくかも今後の課題のひとつです。 まとめ 今回の対応が最適解とせず、メンバー内で整理整頓（①～③）への共通認識ができている今の内に更なる改善目指し、これからも試行錯誤進めていこうと思っています。（そのことをまたお話できたら良いなぁ）

はじめに セーフィー株式会社 でサーバーサイドエンジニアをやっております石塚です。 今回はGoogle Chromeの拡張機能に入門したので備忘録として残しておこうと思います。完全にプライベートで利用するための拡張機能を実装したので、ゆるりと呼んでいただけると幸いです。 はじめに 拡張機能の作り方 インストール ローカルで実行 実装 最後に 拡張機能の作り方 今回はGoolge Chrome向けの拡張機能を実装する方法を紹介します。 Google公式の拡張機能ドキュメント があります。詳しくはこれを参照してください。基本的にはHTML, CSS, JavaScriptで実装可能なので簡単に構築することができそうです。他には他に WXT や Extention.js , plasmo などの拡張機能向けのフレームワークを使う方法もあります。 今回は plasmo を選択しました。”the all-in-one platform that makes it easy for browser extension developers to create, test, and publish amazing extensions.“とあったので全部入りかつ簡単に導入できそうという安易な理由です。 インストール 動作環境は以下の通りです。 macOS Sonoma 14.7 node v18.16.0 npm 9.5.1 まずはプロジェクトを作成します。今回はnpmを使いますが公式ではpnpmの使用が推奨されているようです。 npm create plasmo 対話形式でプロジェクト名や説明などを設定します。 しばらく待つとプロジェクトが作成され、以下のようなディレクトリ構造になっているはずです。 / < PROJECT_NAME > ├── README.md ├── assets │ └── icon.png ├── package.json ├── popup.tsx ├── tsconfig.json └── yarn-error.log 意外とシンプルな構造ですね。 ローカルで実行 まずはローカルで実行してみましょう。 # 筆者の環境では不足していたので追加 $ npm install sharp # 実行 $ npm run dev > extention-sample@ 0 . 0 . 1 dev > plasmo dev 🟣 Plasmo v0. 89 . 4 🔴 The Browser Extension Framework 🔵 INFO | Starting the extension development server... 🔵 INFO | Building for target: chrome-mv3 🔵 INFO | Loaded environment variables from: [] ( node:29924 ) [ DEP0040 ] DeprecationWarning: The `punycode` module is deprecated. Please use a userland alternative instead. ( Use `node --trace-deprecation ...` to show where the warning was created ) 🟢 DONE | Extension re-packaged in 1734ms! 🚀 ビルドされ、開発サーバーで実行可能な状態になっているのでブラウザから拡張機能を有効化して動作確認してみます。 chromeの右上の3点リーダーから「拡張機能」、「拡張機能を管理」に進みます。拡張機能のページの右上に「デベロッパーモード」があるので、このトグルボタンをおして有効化します。 「パッケージ化されていない拡張機能を取り込む」から先ほどビルドの成果物を選択します。 ./build/hrome-mv3-dev に出力されています。 取り込むと以下の画像のようになります。 ブラウザから拡張機能をピン留めしてクリックすると作成した拡張機能が確認できます。 これで最低限の開発ができるようになりました！ 実装 今回はサンプルとしてページがロードされたときにコンソールにURLを出力してみます。 mkdir contents code contents/content.ts 新しくcontents.tsを編集します。今回は以下のような実装にしました。 export {} ; window . addEventListener ( "load" , () => { const url = new URL ( window . location . href ); console .log( "URL:" , url. origin + url. pathname ); } ); ホットリロードが有効なのでコンソールを表示しながらページをリロードするとアクセスしているURLが表示されます！ ビルドの成果物にはHTML, JavaScript, manifest.json（それから画像ファイル）が含まれています。manifest.jsonは拡張機能に必須のファイルですが、これはplasmoが生成しています。manifest.jsonの内容はpackage.jsonで定義できます。 このままではあまり意味のある拡張機能ではないですが、ビルドしていつでも使えるようにしてみましょう。 npm run build ./build/chrome-mv3-prod/ にビルド成果物が出力されます。 これをブラウザの拡張機能のページから読み込むと開発サーバーが起動していないときでも使えます。 拡張機能を広く公開するにはパッケージ化したり、Googleウェブストアで公開したりしないといけないですが、ここでは紹介しないのでぜひ 公式のヘルプページ などを参照して公開してみてください。 最後に 簡単ですが、Google Chrome拡張機能の作り方について紹介しました。 シンプルにHTML, CSS, JavaScriptで実装する方法もありますが、フレームワークを使うとフレームワーク特有のお作法があったりと学習コストが増える分、いろいろとよしなに作ってくれます。 30分から1時間程度あれば簡単な拡張機能は作れると思いますので、年末年始に作ってみるのはいかがでしょうか？ セーフィーではエンジニアを積極的に募集しています。気になる方はこちらをご覧ください！ https://safie.co.jp/teams/engineering/ この記事を読んでもし興味を持っていただけた方は、ぜひ採用サイトもご覧ください。 カジュアル面談のみでも大歓迎ですので、お気軽にご連絡ください。 最後までお読みいただき、ありがとうございました。

メリー・クリスマス、セーフィーCTOの森本です。 こちらは Safie Engineers' Blog! Advent Calendar の25日目のエントリーです。 早いもので、昨年 創業以来10年の開発組織の振り返り について掲載してからもう1年が経ちます。昨年の記事の最後でも触れた通り、メンバーのお陰で事業、組織、プロダクト、内部的な仕組みなど全てにおいて様々な課題を乗り越え再成長軌道に載せると共に、その先の更なる成長へ向けての仕込みも適宜進められていると実感しています。特に大きなチャレンジであったシステム刷新も専任チームを組成し、一歩一歩ですが進められている状況となっています。 さて、今回のエントリーではシステム刷新とは別の、先々に向けた重要な取り組みの一つである AIソリューションプラットフォーム について紹介します。 はじめに AIソリューションプラットフォーム概要 実現したいこと AIソリューション開発における課題 システム構成イメージ 目指すべき姿 経産省PJへの採択 今後に向けて まとめ 最後に はじめに 図1 当社は主にB2B領域でクラウドレコーディングサービスを提供しています。 様々な業界のお客様の現場で、防犯だけでなく業務改善用途でも幅広く活用されており、既に27万台を超えるカメラがお客様環境で常時稼働しており、それらのカメラで録画された総量35PBを超える膨大な映像データが当社システム上で管理されています。 単純な録画視聴に加え、特に業務改善観点では映像データの解析なども重要で、既に複数の 汎用的用途のソリューション の提供は行っているものの、お客様からも業界、課題に特化、もしくはお客様に特化したデータ活用のご要望を幅広く頂いており、より広範囲で効率的に様々なソリューションの開発、提供を進められるような仕組みの整備が急務となっています。 尚、データ活用という観点ではAIの利用は当然考慮に入れる必要がありますので、如何にAIを活用したソリューションの提供を効率的に行えるかも重要な要素と捉えています。 AIソリューションプラットフォーム概要 実現したいこと 図2 冒頭で触れた通り、我々は映像データを活用し、我々のサービスをご利用頂いている様々な業界のお客様の現場課題の解決を進めて行きたいと考えています。ただ、様々な業界が存在し、その中の課題もまた多様な状況で、これらを我々単独で実現するのが不可能に近いのは明白です。（図2参照） だからこそ我々は我々のシステムをプラットフォームと定義し、APIやSDKを活用してデータを活用できるような機能を既に提供してきています。 developers.safie.link 今後に向けてはこれを更に発展させ、他のAI開発者も容易にお客様の課題解決につながるAIソリューションの開発と展開を行える仕組みを整備し、多面的にこれらの活動を進めていく事が必要だと感じています。 大前提として、AIソリューションの開発には適切なデータ活用が必要ですので、我々はまずはそれらを促進する為に何を実現する必要があるかの整理を行ってきました。 AIソリューション開発における課題 図3 適切なデータ活用を実現するための仕組みの整理を行っている中で、AI開発者とデータホルダー（我々に取ってのカメラをご利用頂いているお客様）がそれぞれ課題を抱えている事がわかりました。（図2参照）例えばデータホルダーで言うと、そもそもデータ提供を行うメリットが不明確だったり、いざデータを提供するにも手間がかかります。また、昨今は個人情報やプライバシーにも十分に配慮をする必要があります。一方で、AI開発者側はAIモデルを開発しようにもデータの収集に手間がかかったり、いざAIモデルを準備してもアプリケーションとして提供する環境が必要となります。 これらの課題がデータ活用の促進とAIソリューションの開発効率を高めるための課題となっている事がわかりました。 システム構成イメージ 図4 データホルダー、AI開発者の抱える課題を解決するため、我々は当社が管理する映像を教師データとして活用し、効率よく且つ一気通貫でAIソリューション開発が行える仕組みを提供すると共に、開発したAIソリューションが当社のカメラやクラウドプラットフォーム上に直ぐに展開でき、実行可能な環境を整備していきます。（※大前提として当社が管理するデータはデータホルダーに帰属していますので、その活用にはデータホルダーの合意が必須です） これによって、データホルダーはデータの取り回しやセキュリティについてあれこれケアする必要がなくなり、一方でAI開発者はAIモデル開発にできるかぎり集中し、データ収集に工数を割く必要も無ければ、アプリケーションの展開先も当社の環境を活用することにより素早く顧客に価値提供を行う事ができるようになります。 我々としては、わざわざデータ収集しなくとも、データホルダー環境に展開済みのカメラによって録画されたデータを活用できるのも非常に重要な点ですが、開発したAIソリューションを稼働中のエッジAIカメラやクラウドシステム上に展開し素早く利用して頂く状況に繋げられる点も非常に価値がある点であると捉えています。 目指すべき姿 図5 我々は、先ほどの仕組みによりデータホルダー、AI開発者の抱える課題を解決し、AIソリューションの効率的な開発、展開を可能としていく事だけでは、目標とする様々な業界の課題解決の実現には不十分だと考えています。 AI開発者がどこにどのような課題が存在するか十分に分かっていないケースがあれば、一方でデータホルダーも課題解決に向けてどのAI開発者と連携すればよいか不明確なケースがあると推測しています。 これらの状況を解決するために、上記に加え、データホルダーとAI開発者の連携を実現するような場の構築、提供を行う必要性も感じており、合わせて整備を行っていくことを考えています。 このようなデータホルダーとAI開発者間の多対多のコラボレーションの実現こそが、先程の仕組みの効果を適切に発揮させるために必要であると捉えています。 経産省PJへの採択 我々は上記で説明したAIソリューションプラットフォームについて、数年前より検討を進め少しづつ進めていましたが、この度、国立研究開発法人新エネルギー・産業技術総合開発機構（以下「NEDO」）が公募した「ポスト5G情報通信システ厶基盤強化研究開発事業／データ・生成AIの利活用に係る先進事例に関する調査（調査類型1）」に採択されることが決まりました。 safie.co.jp データ活用に対しての国としての課題感、危機感の現れでもあると捉えています。我々としてはこれはもちろん好機ではありますが、一方で国策の一貫に選定頂いた責任と自負を感じつつ、開発活動を加速して行きたいと考えています。 今後に向けて AIソリューションプラットフォームの開発を進め、2025年中には外部に公開できるよう準備を行うべく進めています。 図6 合わせて、その有効性を示すべく実際のデータホルダー、AI開発者にもご協力頂き、AIソリューションプラットフォームの効果の実証も進めていきます。 更に、有効なコラボレーションの場として成立させていく必要があり、その為にはよく知って頂く事が必須だと捉えていますので、認知向上に向けた取り組みも順次行っていきます。 テックブログでも継続的に具体的な取り組みについてアップデートする想定で検討を進めています。 まとめ 我々はお客様の様々な現場課題の解決を多面的に推し進めるため、それぞれの抱える課題の解決を行える仕組みの整備と、データホルダーとAI開発者の多対多のコラボレーションの場を提供すべくAIソリューションプラットフォームの整備を進めて行きます。 これらの仕組みを活用しデータ活用を多面的に進めて行くことにより、様々なお客様がAIの有用性を実感できるような社会の実現を目指して行きます。 最後に 今回はAIソリューションプラットフォームの紹介となりましたが、セーフィーでは他にも更なる成長へ向けて様々な開発に関わる取り組みを行っています。それらに一緒に関わってくれるエンジニアさんを絶賛募集しています！！！！

この記事は Safie Engineers' Blog! Advent Calendar 24日目の記事です。 はじめに こんにちは、セーフィー 企画本部 デザインセンターの碇石（いかりいし）です。 2024年10月30日、デザインシステムを用いたUIリニューアルがついに公開されました。対象プロダクトは、エンタープライズ向けに多台数のカメラを統合管理できるSafie Manager（セーフィーマネージャー）です。 まず、デザインシステムについては、2019年12月頃から開発を進めていました。2023年に入ってからSafie Managerを含む管理ツールの開発を行っている開発チーム内でフレームワーク移行の話が上がり、そのタイミングに乗せる形でデザインシステムを用いたUIリニューアルプロジェクトが始動。 手探りでスタートしたこのプロジェクトは約1年10ヶ月の開発期間を経て無事公開となりました。 はじめに 開発体制 戦略：手探り感満載の初動期 ターゲットユーザー 目的 UX課題 具体方針 構造：オブジェクト指向（OOUI）で再設計 サイトマップとデータ管理の流れの型化  骨格〜表層：作っては壊しを繰り返して磨き上げるUX 画面構成（ゾーニング） WF〜デザインカンプ マイクロインタラクション まとめ さいごに safie.co.jp 最適なUXを考える上で、デザインセンターでは日頃からJesse James Garrett 氏が提唱する5段階モデルを用いる事が多く、今回のプロジェクトもこちらをベースにデザイン制作までを振り返ってみようと思います。 UXの5段階モデル 開発体制 フレームワーク刷新を含む大型リニューアルはセーフィーとしても初めての試みとなるのですが、このプロダクトは初期リリースの後デザイナー不在となり開発チームのみで守っていたプロダクトなのです。 そういった背景もあり、このチームにおいてはエンジニアとデザイナーの共同開発は実質初めての状態。今回のプロジェクトのためにディレクターとデザイナーをアサインしました。 PdM 1名 フロントエンドエンジニア 9名 デザインディレクター 1名 デザイナー 2名 戦略：手探り感満載の初動期 UXの5段階モデル - 戦略 -  日頃から使い勝手に関する足元の課題感は多く、この機会にしっかり解決していきたい意志をエンジニアと共に意識を合わせ、再設計に当たり、ターゲットユーザーのすり合わせと目的、現状のUX課題の抽出を行いました。 ターゲットユーザー 企業の管理者 情報システム部など会社のシステムを管理する人物 スーパーバイザーやマネージャーなど、現場の監督責任者にあたる人物 利用用途 複数店舗を跨いで多台数カメラの設定および操作権限を管理する 目的 フレームワークの刷新（Nuxt2→React） デザインシステムの適用 【ポイント】UXの改善（あるべきを考え、使い勝手の負を解消する！） 今回のリニューアルのポイントは、最適なUXの実現です。ユーザビリティ *1 を担保することはもちろんのこと、複雑な仕様に対しユーザーがストレスなく利用できる状況を目指します。 UX課題 一貫性が無く、学習コストの高い操作体験 予測しづらい機能名称 つぎはぎ的に追加されたナビゲーションメニュー 生かされていない一等地のホーム画面 具体方針 構造の最適化 骨格の最適化（ナビゲーション） 機能名称の最適化 今回はUIのリニューアルなので、機能要件はそのままに、ユーザーニーズに則したUXの検討に向けて構造〜骨格の再設計を実施します。 構造：オブジェクト指向（OOUI）で再設計 UXの5段階モデル - 構造 -  Safie Managerでは、管理するオブジェクト（データ）が多くそれぞれを結合させることでカメラデバイスの管理や管理権限の組み合わせの自由度を実現させています。 その一方で複雑な機能にインターフェースが追いついておらず、例えばオブジェクトが選ばれていないのにタスク選択のUIが出っ放しになっており、実行ボタンはdisableになっている、、 実行不可の理由が分からないというストレスをユーザーに与える可能性のある箇所や、操作画面の初期状態から「この操作は無効です」というようなエラー表示がされているなど、散見していました。 また、一覧上の操作においては単一の場合でも一時的にオブジェクトを選択状態にしなくてはならず効率の面で課題がありました。 旧UIのオブジェクト操作のインタラクション 設計の基本思想としてオブジェクト指向（OOUI）を意識し、オブジェクトを選択→タスクの選択→結果という流れに調整しながら、インタラクションを含めた形で基本的な負を改善する事ができました。 整理したオブジェクト操作のインタラクション サイトマップとデータ管理の流れの型化  仕様理解もかねて、現行の構造も明らかにしながらデータ管理の流れを型化。全体像でBeforeAfterのイメージをすり合わせ、ナビゲーション構造はこのサイトマップを元に再設計を行いました。 サイトマップ ナビゲーション構造の再設計 データ管理の流れの型化 この辺りは、今後画面を作っていく中での指針となる部分なので細かく確認を交えながら設計していきました。 骨格〜表層：作っては壊しを繰り返して磨き上げるUX UXの5段階モデル - 骨格〜表層 - 型化したデータ管理の流れを元に各画面を制作していきます。このフェーズになってくるとイメージが具体化していくので、実装に向けた細かい調整に移っていくところではありますが、画面構成をユーザーニーズに立ち戻り一度壊して再考するといった場面も多く発生しました。 画面構成（ゾーニング） ゾーニング 画面構成はプロダクト全体で統一されるため、デザイン主体で設計しています。 ヘッダー プロダクト共通で固定化されています。デザインシステムがまだ反映されていないプロダクトにも既に展開されているUIになります。 ナビゲーションメニュー プロダクト固有のメニューが並びます。作成したデータなど可変するものをメニューに並べることはNGというルールを設けています。 コンテンツエリア 制約は特にないですが、横幅指定が画面幅100%を基準値とし、設定画面など横幅の長さによりコンテンツが見づらい、使いづらい場合に1040pxを最大値とするルールを設けています。 WF〜デザインカンプ UIComponentがある事で、より具体的な形で情報設計をする事ができます。見た目がデザインカンプなので、この段階で作って壊してっていうのは大変なのでは、、と思われるかもしれませんが、実際の作業負荷はそこまででもなかったりします。 ただ、エンジニア側からのFBや提案の際、現状の制作環境としてFigmaの編集権限をもっていないエンジニアにとっては改めてWFを作って伝えなければいけない環境だったので、画面要件を決めるまでのラリーが何度も繰り返されたのは、今回のプロジェクトの中でも一番大変だった部分なのではないかと思います、、 デザインFIXまでの流れ マイクロインタラクション disable時にリストをhoverすると、選択不可の理由がToolTipにより表示されるなどの細かいインタラクションを検討しながら最後の仕上げを行なっていきました。全ての画面に行き届いていない状況ではありますが、このToolTipが出ることで安心感が高まったように思います。 disableのオブジェクトをhoverした時 まとめ 今回はデザインを作るまでの話を5段階モデルに沿って振り返ってみました。改めて振り返ってみると、初動の「ユーザーを知る」ここの紐解きが甘すぎた事が今回の一番の反省点です。 実はこの5段階モデルの考え方もOOUIも、エンジニアには全く共有していないまま進めており、前提となる意識の部分で噛み合わない瞬間がしばしばあったように思います。 一方で、プロジェクトやデザインに対するエンジニアの思いの強さを肌で感じルことができ、プロジェクトが進行するにつれてプロジェクトメンバーの一体感が強くなったように思うのはすごく嬉しかったです。 現在、絶賛プロジェクトメンバーと振り返りを行っており、ユーザー理解が十分にできていればプロダクト特性を捉えた大胆な操作体験も実現できたかも？などなど後悔することもありますが、運用フェーズではデザイナーとエンジニアの連携強化に向けた相互理解の場や勉強会の実施など、前向きな取り組みを始めようとしています。 手探り感のある進行に全力で頑張っていただいたプロジェクトメンバーには感謝しかありません、、今後のエンハンス開発に向けて今回の反省を活かした共創体制を築いていきたいと思っています。 さいごに デザインセンターでは、今回のプロジェクトのキーとなるデザインシステム「Pantograph」を順次主要プロダクトに反映しています。 デザインシステムの全体像や、開発秘話を掲載しておりますので、よろしければ合わせてご覧ください。 note.com note.com セーフィーではデザイナー3期生を募集中です。 safie.co.jp *1 : ユーザビリティ＝「使いやすさ」ではなく「利用可能性」と考え、有効さ、効率、満足度の度合いで判断しています。

この記事は Safie Engineers' Blog! Advent Calendar  23日目の記事です はじめに はじめまして、サーバーチームの城山です。 弊社の一部サービスで Kinesis Client Library(v2) for Python を利用しており、私なりに感じた躓きやすいポイントについてお話ししたいと思います。 はじめに Kinesis Client Library for Python とは 構成について 躓きやすいポイント 同一シャード内でのパーティションキー毎の処理遅延 重複レコードの制御 ECS Fargate task での RecordProcessor のログ連携 タスク終了時の MultiLangDaemon のタイムアウトエラー ローカル開発環境の構築 まとめ Kinesis Client Library for Python とは https://github.com/awslabs/amazon-kinesis-client-python Kinesis Client Library for Python(以下KCL) は、kinesis data stream(以下KDS) からデータを取得し、処理するためのライブラリです。 Kinesis Client Library は Java で実装されており、MultiLangDaemon と言われる多言語インターフェースを利用することで、他の言語から利用することができ、Pythonでも利用することができます。 構成について シャード数3、ECSタスク数1の場合の構成図です。 ※ 簡潔にするため、一部省略している箇所があります。 KDSに書き込まれたデータを、KCL の MultiLangDaemon が取得し、標準出力を介して、複数レコードが RecordProcessor(Pythonサブプロセス) に渡されます。 RecordProcessor では、主にDBへのデータ登録や、API連携等のビジネスロジックを実装しています。 また、KDSは複数のシャードに分かれており、RecordProcessor はシャード毎に1つずつ起動されます。 これにより、シャード単位での並列処理が可能となっています。 躓きやすいポイント 同一シャード内でのパーティションキー毎の処理遅延 1つのパーティションキーで大量にデータが登録された場合、同一シャード内の他のパーティションキーのデータが処理待ちとなり、処理が遅延する可能性があります。 例えば、上図のように、パーティションキーAのデータが大量に登録された場合、パーティションキーAのレコードを全て処理するまで、パーティションキーBのデータが処理待ちになるという状況です。 それに対し弊社では、RecordProcessor でパーティションキー毎に非同期処理を行うことで、特定パーティションキーの処理遅延が他のパーティションキーに影響を与えないようになっています。 また、 queue.Queue を利用して、同一パーティションキー内でデータの順序を保持しつつ処理できるようにもなっています。 以下に一部抜粋してコード例を示します。(※ 実際のコードから一部簡略化しています) def process_records (self, process_records_input: messages.ProcessRecordsInput): """ Called by a KCLProcess with a list of records to be processed and a checkpointer which accepts sequence numbers from the records to indicate where in the stream to checkpoint. Args: process_records_input (amazon_kclpy.messages.ProcessRecordsInput): the records, and metadata about the records. """ async def process_queue_record (record_queue: queue.Queue, partition_key: str ): while not record_queue.empty(): record: messages.Record = record_queue.get() # ここからrecordの処理を行う async def process_records_in_parallel (records: list [messages.Record]): # partition key毎にqueueを用意し、recordをputする queues: dict [ str , queue.Queue] = {} for r in records: if r.partition_key not in queues: queues[r.partition_key] = queue.Queue() queues[r.partition_key].put(r) # partition key毎に用意したqueueをevent loop内で並列に処理していく tasks = [] async with asyncio.TaskGroup() as tg: for key, q in queues.items(): tasks.append(tg.create_task(process_queue_record(record_queue=q, partition_key=key))) event_loop = asyncio.get_event_loop() event_loop.run_until_complete(process_records_in_parallel(process_records_input.records)) 参考: awslabs amazon-kinesis-client-python (GitHub) / Apache License 2.0 重複レコードの制御 KCLのデプロイ、エラーによる予期せぬ終了、シャードのマージ、分割 等で、処理が途中で終了した場合、重複してデータが処理される可能性があります。 これに対し、データの生成元(弊社の場合はカメラデバイス)でデータの一意性を保証するためのIDを生成し付与してもらい、DB側でそのIDを保持し、重複レコードの制御が行われています。 以下に重複レコード制御に関する流れの例を示します。 ECS Fargate task での RecordProcessor のログ連携 弊社では、アプリケーションのログドライバーとして主にAWS FireLensを利用し、ログを特定のサービスに連携しています。しかし、RecordProcessorはサブプロセスとして起動され、かつ標準出力がMultiLangDaemonとの通信に使用されるため、RecordProcessorのログを連携するには工夫が必要でした。この課題は、ログ出力先をMultiLangDaemonの標準出力先に変更することで解決されています。 具体的なコードは以下の通りです。(※ 実際の設定から一部簡略化しています) import logging.config logging.config.dictConfig( { "version" : 1 , "handlers" : { "file" : { "class" : "logging.FileHandler" , "filename" : "/proc/1/fd/1" , # MultiLangDaemonの標準出力先 }, }, "loggers" : { "app" : { "level" : "INFO" , "handlers" : [ "file" ], }, }, } ) タスク終了時の MultiLangDaemon のタイムアウトエラー 開発初期の頃、デプロイ時など古いタスクの終了時に、MultiLangDaemon 側でタイムアウトエラーが発生していました。 実際にタイムアウトが発生した際の MultiLangDaemon のログが以下です。 2024-01-25 06:28:02,986 [Thread-1] INFO s.a.k.multilang.MultiLangDaemon [NONE] - Process terminated, will initiate shutdown. 2024-01-25 06:28:02,917 [ShardRecordProcessor-0000] INFO s.a.kinesis.multilang.MessageWriter [NONE] - Writing ProcessRecordsMessage to child process for shard shardId-000000000012 at java.base/java.lang.Thread.run(Thread.java:829) at software.amazon.kinesis.multilang.MultiLangDaemon.lambda$setupShutdownHook$0(MultiLangDaemon.java:183) at java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:2027) at java.base/java.util.concurrent.CompletableFuture.timedGet(CompletableFuture.java:1892) java.util.concurrent.TimeoutException: null 2024-01-25 06:28:02,732 [Thread-1] ERROR s.a.k.multilang.MultiLangDaemon [NONE] - Encountered an error during shutdown. この問題は、MultiLangDaemon が RecordProcessor に shutdown リクエストを送信し、その終了を待っている間にタイムアウトしていることが原因でした。これはKCLの設定値 shutdownGraceMillis を指定し、タイムアウト時間を調整することで解決されています。 shutdownGraceMillis = 10000 ローカル開発環境の構築 KCLは、DynamoDBとKinesis Data Streamに依存しています。KCLの設定でAWSのエンドポイントを指定できるため、AWSサービスをローカルでエミュレートできる LocalStack を利用して、AWS上のリソースを使用せず、ローカル開発環境が構築されています。 kinesisEndpoint = http://localhost:4566 dynamoDBEndpoint = http://localhost:4566 ちなみに、port 4566 は LocalStack のデフォルトのポート番号です。 まとめ KCLを利用すること分散コンピューティングに関連する複雑なタスクを簡素化してくれるが、独自の対応が必要な部分があることがわかりました。 また、awsドキュメント等に記載がない設定値( kinesisEndpoint , dynamoDBEndpoint 等)もあり、場合によってはソースコードを読むことも必要と感じました。

この記事は Safie Engineers' Blog! Advent Calendar  22日目の記事です はじめに こんにちは、セーフィー株式会社でAI開発をしている木村です。年の暮れということで、今年チームで始めた取り組みについて共有させていただきます。 私は昨年セーフィーに入社した新米エンジニアで、日々勉強の毎日を送っていました。そんな中、技術力向上のために本を読んでインプットすることは重要だと感じていましたが、一人では継続が難しく悩んでいました。 そこで、「複数人で読み進めれば、より効果的にインプットができるのではないか」と考え、チーム内で輪読会を開催することにしました。 輪読会は「始めたものの続かない」という声をよく耳にする活動ですが、私たちは1年間継続することができています。 本記事では、”サスティナブル” な輪読会を実現するために運営として気を付けたことや、実践を通じて改善してきたことなどについてお伝えしたいと思います。 はじめに なぜ輪読会を始めたのか 実施形態 基本情報 やり方 本選び 実際にやってみて ふりかえり アンケート アンケート結果を踏まえた改善 まとめ さいごに なぜ輪読会を始めたのか 知識を増やせる、インプットを楽できるという点の他にも、輪読会には多くのメリットがあると考えています。 相互サポートによる学習効果 理解に時間がかかってしまう難しめの本でも、互いにサポートし合うことで読破が可能になります。また、本に書かれている内容だけでなく、メンバーの実務経験や関連知識も共有できるため、一人で読むよりも多くの学びを得ることができます。 チーム内の共通知識の醸成 同じ本を読み、その内容を互いに認識していることで、チーム内の共通知識が育まれます。これはコードレビューなどの実務でも活かされ、「あの本のアレ」といった共通認識をベースにしたコミュニケーションが可能になります。 コミュニケーションの活性化 普段の業務では直接関わる機会が少ないメンバーとも対話する場となり、チーム内のコミュニケーションが活性化します。技術的な議論を通じて、お互いの考え方や知見を共有する良い機会となります。 これらのメリットを活かし、個人の技術力向上とチームの成長の両方を実現できる場として、輪読会をスタートさせました。 実施形態 基本情報 参加規模：6~8名程度 実施形式：基本オフライン（オンライン併用） 参加形態：自由参加制 開催頻度：週１回 所要時間：１時間 やり方 輪読会の実施方法には、大きく分けて「当日その場で読む」パターンと「事前に読んでくる」パターンがあります。 私たちは、コミュニケーションの活性化やディスカッションによる関連知識共有をを重視し、「事前に読んでくる」パターンを採用しました。 さらに、事前に読んでくるパターンにも以下の2つの方式があります： 全員が読んできてディスカッションを行う 数人が読んできて発表する ディスカッション方式の方がコミュニケーションの活性化には効果的ですが、参加者全員に毎回の予習が必要となり負担が大きくなります。 長期的な継続を考慮し、私たちは以下のようなハイブリッドな形式を採用しました。 1. 当日の発表担当者数名が事前に読んで簡単な発表を行う 2. その後、質問や補足の時間を設け、参加者全員で対話する この方式により、発表担当者以外の参加者の負担を抑えつつ、活発な意見交換の場を作ることができました。 本選び 本は参加者全員で候補を出し合い、投票によって選びました。 最初に選んだ本は、 出版社はオーム社の 「 リファクタリング(第2版): 既存のコードを安全に改善する 」 （著者：Martin Fowler、翻訳者：児玉 公信 , 友野 晶夫 , 平澤 章, 梅澤 真史）です。 この本は、リファクタリングの本質的な考え方から具体的な手法まで、体系的に解説された名著です。 （本の内容についてはここでは詳しく触れませんが、リファクタリングの勘所やコードを修正するステップについて細かく記載されており、非常におすすめな書籍でした。） 実際にやってみて 週1回1時間の頻度で実施し、4か月ほどかけて1冊を読み終えました。 実際に輪読会を運営してみて、当初の期待通りの効果が得られただけでなく、予想以上の学びもありました。 良かった点 一番の成果は、一人では途中で挫折しそうなぶ厚めの本を最後まで読み切れたことです。メンバー同士で分からない部分を教え合い、それぞれの理解を深めながら進められたことが、完走につながりました。 予想以上だったのは、メンバーそれぞれの実務経験や関連知識の共有から得られる学びの多さでした。例えば「製品コードの○○の部分はこのようにリファクタリングするとよさそうだね」といった具体的な改善提案が出てきて、より実践的な議論に発展することができました。 課題となった点 メンバーがあまり興味を持てない章に差し掛かると、議論も盛り上がらず、一時的にモチベーションが下がってしまう時期がありました。この経験から、本の内容から重要なポイントを見極めて読み進める必要性を実感しました。 ふりかえり アンケート 1冊通してやってみた後、運営改善のためにアンケートを実施しました。5段階評価での結果は以下の通りでした。 全体的な満足度：4.0 / 5.0 本がためになったか：4.1 / 5.0 発表資料のわかりやすさ：4.0 / 5.0 ポジティブな意見 知識が増えたという意見が多かったのはもちろんのこと、 新しい視点が得られた（他の参加者の意見や考え方から新しい視点を得た） 意見交換やディスカッションが有意義だった という意見が多かった。 改善点として挙がった意見 一方で、以下のような課題も指摘されました。 本の内容にあまり興味を持てなかった 自由に参加という形と発表者分担制がかみ合ってない 発表担当が連続するとやや負担に感じる チームの状況や目的に合わせて、取り上げる章を選択的に決めても良さそう アンケート結果を踏まえた改善 アンケート結果を踏まえ、より効果的な輪読会を目指して以下の改善を実施しました。 複数の本の並行読書制の導入 読む本を2種類に増やし、参加者がより興味のある本を選べるようにしました。これにより、メンバーの学習意欲を高めることが期待できます 班制度の導入 本ごとに班分けを行い、各班で発表を担当する形式に変更しました。これにより、業務都合などで輪読会に参加できない場合でも、班内で柔軟に担当を調整できるようになり、運営の安定性が向上しました。 期間の明確化と効率化 各本に対して輪読会の回数を事前に設定し、その期間内で完結させる方式を採用しました。これにより、 複数の本を並行して進めても、読了のタイミングを揃えられる 重要度の高い章に焦点を当てた効率的な進行が可能になった これらの改善により、より柔軟で効率的な輪読会の運営が実現でき、参加者の満足度向上にもつながりました。 まとめ 本記事では、1年間継続できた輪読会の運営について紹介させていただきました。 特に、アンケートを通じて得られた意見を基に実施した改善（複数の本の並行読書制、班制度の導入、期間の明確化）は、輪読会の質を大きく向上させることができました。 輪読会は、個人の技術力向上だけでなく、チーム内のコミュニケーション活性化や知識共有の場としても非常に有効です。 本記事が、みなさんの職場での ”サスティナブル” な輪読会立ち上げと運営の参考になれば幸いです。 さいごに セーフィーではこのように学習意欲の高いエンジニアとともに開発する仲間を募集しています！ この記事を読んでもし興味を持っていただけた方は、ぜひ採用サイトもご覧ください。 カジュアル面談のみでも大歓迎ですので、お気軽にご連絡ください。 https://safie.co.jp/teams/engineering/

この記事は Safie Engineers' Blog! Advent Calendar 21日目の記事です はじめに Hello~ モバイルグループのアダムです。 今年も誕生日に記事を出せて嬉しいです！🎅 最近自分がはまっているモバイルのアーキテクチャの遊びについて紹介させてください！ 今回の遊びの環境： Xcode: 16.2 Minimum Target: 17.0 Swift: 6 Concurrency: Strict はじめに MVVM Environment Repository ViewModel App/Scope View 結果 まとめ おわりに MVVM 将来的に理想なアーキテクチャを行うならどんな感じで実装するのか？をやってみました。 今まで開発に参加していたアプリはほとんどMVVMだったので、最新のSwiftUIで実装した場合どんな形になるんだろう？🤔 オンメモリーのCacheを持つRepositoryがある場合どんな形で作るのか？ そのために今回どんな感じで考えたかを紹介させて〜 もしこんな方法おすすめ、こちらの方がベターっていうのがあったらこちら→ @monolithic_adam or monolithic-adam.bsky.social にPOSTお願いします！ Environment 一旦例のためカウントを持つRepositoryとViewModelがincrementするUseCaseを用意します Repository @Observable にして何かの変更があった場合Viewが再描画される @Observable final class TestRepository { var count : Int = 0 } ViewModel ViewModelにシンプルなUseCaseを用意、Repositoryに最新の状態をアップデートできる func を用意します struct TestViewModel { let repository : TestRepository func increment () { repository.count += 1 } } App/Scope 今回のRepositoryがアプリスコープのため、Appの方で init ・ .environment にセットする @main struct TestProjectApp : App { @State private var testRepository = TestRepository() var body : some Scene { WindowGroup { ContentView() .environment(testRepository) } } } View こちらが 迷いポイント１ です！ RepositoryがEnvironmentの方で設定しているので、どうやってViewModelへ渡すのかを迷っています・・・ Environmentはinit時にまだ存在しないのでparentから渡すのか、ViewModelを .environment にセットして、observeすべきかも？ ま、一旦parentから渡す感じで実装してみましょう！ struct ContentView : View { @Environment ( TestRepository.self ) var repository : TestRepository let viewModel : TestViewModel init (repository : TestRepository ) { self .viewModel = TestViewModel(repository : repository ) } } 結局App側で二重に渡している感じになってしまう @main struct TestProjectApp : App { @State private var testRepository = TestRepository() var body : some Scene { WindowGroup { ContentView(repository : testRepository ) .environment(testRepository) } } } 最後に状態変化を見れるよう、シンプルにcountを表示させるTextとincrementできるボタンを用意して完成！ var body : some View { VStack { Text( "Current Count \( repository.count ) " ) Button { viewModel.increment() } label : { Text( "Increment" ) } } .padding() } 結果 まとめ View -> ViewModelにRepository渡すことがEnvironmentをちゃんと活用できていないな〜 画面遷移する時にどうせ次のビューを渡さないといけなくなるので、あまりEnvironmentにセットする意味がない init 時は気にしなくて良くなるViewModelをEnvironmentにした方が綺麗になる 理想はこうなるかな〜 おわりに モバイルチームでは、このように多様な環境で世界に向けたアプリをともに開発する仲間を募集しています！ open.talentio.com

こんにちは！第5開発部業務システム第1グループの常世田です。 この記事は セーフィー株式会社 Advent Calendar 2024 の12月20日の記事です！ 2024年4月1日、顧客お問い合わせ対応ツールをZendeskからSalesforce Service Cloudへ移行しました。移行前は営業部がSalesforce、カスタマーサービス部(以降CS部)がZendeskと部門ごとに違うツールを利用してきたことにより、データ一元管理がされてない、非効率な業務が多々発生している状態でした。 この記事ではService Cloud導入をどのように実現したかを説明します。 1.導入前の大きな課題 2.実現方法 3.試行錯誤した点 4.取り組んだ感想 1.導入前の大きな課題 顧客対応履歴の分断 営業部はSalesforceを利用して顧客対応をし、CS部ではZendeskを利用して顧客対応をしていました。分断されることで、1顧客に対しての対応履歴がすべて網羅できない状態になり、両部署でどのようなやりとりをしているか、素早くキャッチするのが困難になっていました。 顧客情報が正しくない SalesforceとZendeskはそれぞれ内部で顧客情報を管理しています。Salesforceにすべての情報が連携されておらず、一部の顧客で情報の不足や二重管理になり、正しい情報が一元管理されていないため判定が困難な状態でした。 　　　　　　 顧客に関連する情報がZendeskで管理されていない お問い合わせ対応のスタートはカメラのシリアルナンバーを頂いてからスタートします。シリアルナンバーはSalesforceで管理されているため、ツールを横断してSalesforceで検索し状況把握、Zendeskに戻り顧客へ返信する　といった非効率な作業が発生していました。 　　　　　　 2.実現方法 業務要件の洗い出し Zendeskで実現できていた機能がSalesforceで実現可能か否かの洗い出しを実施。 実現不可の場合は、どうやって実現するか、そもそも運用でカバーできる等も検討し、すべての機能を実現するのではなく、時には業務をシステムに合わせてもらうなど取捨選択をしつつ、一つ一つ丁寧に方針を決めていきました。 流入チャネルの整理 各流入チャネルからのお問い合わせデータ連携先がZendeskに集約されていたため、Zendeskにどういうお問い合わせが集約されているかの洗い出しを行いました。 標準とカスタムする範囲の選別( ※実装の一部分を抜粋 ) 標準機能を用いて対応 メール機能 顧客満足度アンケート チャット機能 Slack連携(Slackワークフローを利用) 電話機能(MiiTel)(※一部カスタマイズ実施) 開発して対応 お問い合わせフォームの連携(DataSpider Cloud) プラン変更/解約申請の連携(DataSpider Cloud) 業務効率化のためのSalesforce内カスタマイズ(関連情報の自動取得/他システム連携) お問い合わせ情報を正しい顧客へ紐づける運用の意識付け 一番のメリットはすべてのお問い合わせが適切な顧客に紐付けられ対応履歴が網羅できる点です。データの紐づきが汚い状態では、導入しても意味がありません。紐付けはなるべくSalesforceで自動的に行いますが、どうしても手動で対応しないといけない部分も発生しました。Zendeskではあまり意識していなかった顧客データ管理の意識付けを行い、正しい情報が正しい顧客へ紐づくようにオペレーションを見直して業務側へ周知を徹底しました。 Zendeskデータ移行 Zendesk内で保管されていたお問い合わせ履歴をすべてSalesforceへ移行しました。Zendeskの仕様上、データを抽出しただけではSalesforceへデータ移行はできず、データ成形方法から検討しつつ、移行作業を実施しました。 3.試行錯誤した点 どのような業務をしているかのキャッチアップ システム導入する前に大切なことは業務がどのような流れで進んでいるかという業務を理解することです。私は入社して早々にService Cloud導入を一任されました。入社研修でCS部がどのような業務をやっているかの座学はあったものの、実際に業務メンバーとの会話ではイメージが沸きずらい状態でした。当時業務PMを担当していた方に不明点あればすぐ確認し、どういう業務をしているかの理解から重点的に行い、周りの方にもサポートを頂きながらプロジェクトを推進していきました。特に業務PMの方にはとても助けられました(笑) Zendesk中心の機能要件 「Zendeskで出来ていたことだからSalesforceでもやってくれ」 という無理難題な要望もありました。運用でカバーするか、システム側で頑張って実装するか、実装した場合スケジュール的に間に合うか等考えた上でどこで着地させるか、という折衷案出しに苦労しました。 データ移行 Zendeskから出力されるデータはJSON形式になっており、Salesforceへ投入するにはCSV形式への変換が必要でした。 JSONデータを扱うことが私自身初めてでしたので移行に必要な項目がどのような構造となっているかから調査を始めました。変換にはCLIコマンドとPythonを用いました。 また、お問い合わせのデータだけではなく、紐づくメールデータ、添付ファイルデータも対象でしたので、3つのデータが正しく出力されるように相当苦労しました。 データ投入のリハーサルは何度もトライしながら、正しいデータでSalesforceへ移行されるよう慎重に対応をしました。またメールデータは通常のSalesforceレコードの容量(2KB)とは異なっていたため、Zendeskデータをすべて移行した際どの程度データ量が増えるかの試算も必要でした。今思い返すとでService Cloud導入プロジェクトで一番パワーを使った作業だったと思っています。 4.取り組んだ感想 今回のプロジェクトでは、要件定義〜開発、リリース、業務調整、運用定着支援まで幅広い領域に携われました。急遽発生する業務要件の変更や追加要望も多々ありましたが、業務側とシステム側がより良い関係を構築することでスムーズに推進できました。どちらかが一方的に要望を伝えるのではなく、お互いの理解があってこそ実現できたプロジェクトだと感じました。「現場を知る」という大切さをこのプロジェクトを経て学べることができたと思っています。 結果、Service Cloudを導入して良かったと思っています。Salesforceに情報が一元管理されることで、顧客対応履歴が瞬時に見れる世界です。また業務効率化という点でもService Cloudの機能が十分発揮し、業務側の力になっていると感じています。 セーフィーのビジネスが拡張していくと同時に新たなカスタマイズ要望もたくさん増えていくと思いますので、業務がスムーズにいくよう引き続き改善、サポートをしていきたいと思っています。 最後まで読んでいただきありがとうございました。

This post is for day 19th of Safie Engineers' Blog! Advent Calendar AWS Kinesis Data Stream and Apache Flink are two of the most popular tools for streaming data processing applications. In today's post, we will explore how those two tools can enhance each other and how Apache Flink compares to AWS counterpart AWS Kinesis Consumer Library (KCL) What is Apache Flink When use Apache Fink over KCL Application Code example DataStreamAPI example TableAPI example Deployment on AWS cloud Conclusion What is Apache Flink In order to understand how Apache Flink can enhance a AWS Kinesis application, firstly, we need to understand its purpose and basic characteristics. Apache Flink is an open-source stream processing framework developed to go hand in hand with data streaming processes, including, but not limited to, the open-source message broker Apache Kafka . Its goal is to be used on unbounded and bounded data streams in real-time and batch processing. One of its strengths is the ability to connect to various data sources and its final destination (downstream data sinks), including data streaming services, like AWS Kinesis Data Stream, filesystem such AWS S3 and directly to Databases, using JBDC Drivers. Fig1. Flink Application data flow Flink was developed considering native cloud deployment, providing a robust and scalable platform for building data-driven applications, offering features such as event time processing, stateful computations, fault tolerance, scalability. When use Apache Fink over KCL While KCL allows record processing checkpoint for each shard iterator for recovery, it does not support state recovery. On the other hand, besides record checkpoint recovery, Flink also allows for complex data structure state recovery. Similar to checkpoint settings, the user can define not only the frequency of state save, but also the backend location. It can be saved locally, on a filesystem, such as S3 or in a key-value store. In case of a failure, Flink restores the state from the latest checkpoint and replays the process until the current point. The number of restart attempts and delay between each attempt is also configurable. This robust state recovery process allows for a better fault tolerance and consistency (exactly-once processing). Another advantage of Flink over KCL is its ability to process records using event-time semantics. KCL does not provide event-time semantics. All the processing logic is based on arrival time. The implementation of event-time processing can be done using a custom logic for out-of-order events buffer, but its implementation can be cumbersome and error prone, besides its overhead on the processing power. Flink natively handles out-of-order records using a watermark strategy, which can be either monotonously increasing (only accept records with higher timestamp than previous) or fixed amount of lateness behind (only accept records within a defined duration behind the previous watermark). This system of event-time semantics allows for accurate window aggregation operations and time-based analysis. It also increases the scalable and resilient processing capability under unstable data flow conditions. The architecture and scalability characteristics of both Fink and KCL differ in many ways. White KCL allows for horizontal scalability, ultimately, the number of workers is limited by the number of active shards. Each KCL instance subscribes to one or more shards, and while multiple KCL can subscribe to one shard, it can lead to a record being processed multiple times. Flink uses a multiple node architecture, allowing for horizontal scalability not bounded by the number of shards. Flink's overall architecture is also more resilient and robust against failure. The process control is based on Task Manager and Job Managers instances. With the Job Manager acting as the central work coordinator handling the Task Manager, who performs the actual work. JobManager is also responsible for detecting and handling processing failures, including establishing new Task Managers nodes and retrieving the previous state and checkpoint. Task Managers can have internal sub-task slots, which with its own purpose and sharing data. Fig2. Flink internal Managers architecture One point where KCL clearly excels is in its simplicity to deploy to production. While a Flink Application has many moving parts that must be adjusted and managed, KCL is an out-of-the-box solution on the AWS environment. Although modem deployment tools, such as Amazon Kinesis Data Analytics for Apache Flink, and solution vendors can help to lower the difficulties of a Fink Application deployment, it is still necessary a high level of understanding of its inner architecture and definitions to really take the full potential of its usage. Application Code example Now, to get a feeling of how the application is written, lets try to make a simple example considering a hypothetical, but realistic, IoT data analysis and processing. One of the first choices to be made when writing an Flink Application is deciding which API to use. Both DataStreamAPI and TableAPI can be used to transform and analyse the data. DataStreamAPI is a lower level abstraction and allows a higher flexibility, while TableAPI is a higher level of abstraction based on SQL language that requires less code to write and thus quicker development cycles. For this example, let's try one example of each API to get a feeling of how each one can be used. Similar to KCL, Flink backbone is written in Java, but there is a wrapper for Python available. In this example, we will use its native Java language to show a few of its characteristics. So, now to the code: In order to connect to a AWS Kinesis Data Stream, we will first need to include its relative connector in our dependencies. The easiest way to do it is to use a Java build tool such as Maven or Gradle maven <dependency> <groupId> org.apache.flink </groupId> <artifactId> flink-connector-aws-kinesis-stream </artifactId> <version> 5.0.0-1.20 </version> </dependency> gradle implementation 'org.apache.flink:flink-connector-aws-kinesis-streams:5.0.0-1.20' While the datastream can be used unstructured and undefined, I will help a lot in the long run if we define the data schema that we expect to be receiving. For this particular case, let's assume the data is for a device that will be sending periodically a packet of data in bytes and a value related to its status. Keep in mind that Flink has a native AWS Glue Schema decoder that can also be used for bigger projects where the schema must be shared across several services. public class DeviceRecord implements Serializable{ public String device_id; public long timestamp; public double value; public String data; public DeviceRecord() { } public DeviceRecord(String device_id, long timestamp, double value, String data) { this .device_id = device_id; this .timestamp = timestamp; this .value = value; this .data = data; } public String getDeviceId() { return device_id; } public long getTimestamp() { return timestamp; } public double getValue() { return value; } public byte [] getData() { return data != null ? data.getBytes() : null ; } @Override public String toString() { return "DeviceRecord{" + "device_id='" + device_id + ' \' ' + ", timestamp=" + timestamp + ", value=" + value + ", data=" + data + '}' ; } } The next step is to define how to deserialize the data received from the stream. We can get that byte array and transform it into an DeviceRecord instance. public class DeviceRecordDeserializationSchema implements DeserializationSchema<DeviceRecord> { private static final long serialVersionUID = 1L ; @Override public DeviceRecord deserialize( byte [] message) throws IOException { String line = new String(message, StandardCharsets.UTF_8); ObjectMapper objectMapper = new ObjectMapper(); DeviceRecord deviceRecord = objectMapper.readValue(line, DeviceRecord. class ); return deviceRecord; } @Override public boolean isEndOfStream(DeviceRecord nextElement) { return false ; } @Override public TypeInformation<DeviceRecord> getProducedType() { return TypeInformation.of(DeviceRecord. class ); } } DataStreamAPI example This is the actual implementation code of the processing job that connects with the Kinesis DataStream. For now no actual processing is being done. We will implement the sink connector latter public class BasicStreamingJob { public static void main(String[] args) throws Exception { Configuration sourceConfig = new Configuration(); sourceConfig.set(KinesisSourceConfigOptions.STREAM_INITIAL_POSITION, KinesisSourceConfigOptions.InitialPosition.LATEST); // Create a new KinesisStreamsSource to read from specified Kinesis Stream. KinesisStreamsSource<DeviceRecord> kdsSource = KinesisStreamsSource.<DeviceRecord>builder() .setStreamArn( "your-stream-arn" ) .setSourceConfig(sourceConfig) .setDeserializationSchema( new DeviceRecordDeserializationSchema()) // The DeviceRecord deserializer .setKinesisShardAssigner(ShardAssignerFactory.uniformShardAssigner()) // This is optional, by default uniformShardAssigner will be used. .build(); WatermarkStrategy<DeviceRecord> watermarkStrategy = WatermarkStrategy.<DeviceRecord>forBoundedOutOfOrderness(Duration.ofSeconds( 10 )) .withTimestampAssigner((event, timestamp) -> event.getTimestamp()); final StreamExecutionEnvironment env = StreamExecutionEnvironment.createLocalEnvironment(); env.enableCheckpointing( 5000 ); // Define the data processing pipeline. We will create one job for each device_id KeyedStream<DeviceRecord, String> stream = env.fromSource(kdsSource, watermarkStrategy, "Kinesis Source" ) .returns(TypeInformation.of(DeviceRecord. class )) .keyBy(value -> value.getDeviceId()); // Print the records to the console stream.print(); // Execute the Flink job env.execute( "Order Records by Partition Key" ); } } In this example, we will retrieve the field “data” from the Device object and insert it in as AWS S3 bucket. The first step it to decide how to retrieve this data. This can be done with an encoder class that writes the data into an OutputStream. public class DeviceRecordEncoder implements Encoder<DeviceRecord> { @Override public void encode(DeviceRecord element, OutputStream stream) throws IOException { stream.write(element.getData()); } } After that we will need to decide where to put our objects. For this case, we will create a daily bucket, combined with the device ID. public class DeviceRecordBucketAssigner implements BucketAssigner<DeviceRecord, String> { private static final long serialVersionUID = 1L ; private static final DateTimeFormatter formatter = DateTimeFormatter.ofPattern( "yyyy-MM-dd" ); @Override public String getBucketId(DeviceRecord element, Context context) { LocalDate date = Instant.ofEpochSecond(element.getTimestamp()).atZone(ZoneId.of( "Z" )).toLocalDate(); return date.format(formatter) + "/" + element.getDeviceId(); } @Override public SimpleVersionedSerializer<String> getSerializer() { return SimpleVersionedStringSerializer.INSTANCE; } } Finally, now we can combine all these elements and create our processing job to insert the data into an S3 bucket, by adding the following code to the main function. // Define the S3 sink FileSink<DeviceRecord> s3Sink = FileSink .forRowFormat( new Path( "s3://testbucket/" ), new DeviceRecordEncoder()) // Use the custom encoder .withBucketAssigner( new DeviceRecordBucketAssigner()) // Use the custom bucket assigner .withRollingPolicy(DefaultRollingPolicy.builder() // Roll the file every 5 seconds .withRolloverInterval(Duration.ofSeconds( 5 )) .withInactivityInterval(Duration.ofMinutes( 1 )) .withMaxPartSize(MemorySize.ofMebiBytes( 16 )) .build()) .build(); // Add the S3 sink to the pipeline stream.sinkTo(s3Sink); With this piece of code, we can insert the "data" field from the Kinesis record into the S3 according to the rolling policy as we receive it. TableAPI example For the example with TableAPI, let’s consider a job that inserts the streaming data directly into a RDS Database. In this example, we will insert the Device field “value” into the table as we receive it. final StreamTableEnvironment tableEnv = StreamTableEnvironment.create(env); // Define the Kinesis source table tableEnv.executeSql( "CREATE TABLE kinesis_table (" + " device_id character varying(32)," + " `timestamp` NUMERIC," + " `value` NUMERIC" + ") " + "PARTITIONED BY (device_id) WITH (" + " 'connector' = 'kinesis'," + " 'stream.arn' = 'your-stream-arn'," + " 'format' = 'json'" + ")" ); // Define the PostgreSQL sink table tableEnv.executeSql( "CREATE TABLE postgres_table (" + " device_id VARCHAR(32)," + " `timestamp` NUMERIC," + " `value` NUMERIC" + ") WITH (" + " 'connector' = 'jdbc'," + " 'url' = 'jdbc:postgresql://db-host:port/dbname'," + " 'table-name' = 'yourtablename'" + ")" ); // Insert data from Kinesis source table to PostgreSQL sink table tableEnv.executeSql( "INSERT INTO postgres_table " + "SELECT device_id, `timestamp`, `value` FROM kinesis_table" ); The above TableAPI example shows how it trades granularity and control for simplicity and quick deployment. It is ideal to work with highly structured data; or for cases when it requires JOIN between several data sources. For either cases, both APIs can be mixed at will for any Flink Application. So choose the API you will be using depending on your necessity. Deployment on AWS cloud With your Flink Application ready, now you can deploy it and start analyzing the stream data. Strictly speaking, the deployment can be done even locally, but to really reap the benefits of scaling and parallel processing, deployment on the cloud is recommended. Since we will already be using AWS Kinesis Datastream, let's consider the options for deployment on AWS Cloud. The deployment can be done on several different services, each one with its own benefits and trade-offs. Amazon Kinesis Data Analytics for Apache Flink (previously called Amazon Kinesis Data Analytics) EMR (Elastic MapReduce) AWS Fargate with Kubernetes (EKS) ECS AWS Lambda For architectures based on nodes, such as EKS, another choice that must be made is to decide if the application will be run in Session mode or Application Mode. In Session mode, the resources are shared between the nodes inside the single cluster, lowering the overhead for the overall service, but miss the isolation. This mode is best suited for quick or small jobs. Some special considerations must be taken into account when defining the configuration for a Flink application on the cloud. A critical point that has a direct impact on the cost of operation is regarding resource allocation. The number of tasks should be decided considering the parallelism level that the Task Manager will use to process the job, while the instance size should be decided considering the expected load. While Flink allows for those parameters to be set in its configuration file flink.conf, most services, such as EMR and Amazon Kinesis Data Analytics for Apache Flink allow to integrate its autoscaling to AWS native metrics and setup. Conclusion In this post we showed how Apache Flink can be used to analyze and process data coming from a AWS Kinesis Data Stream. When compared to AWS native solution, KCL, Flink has a few advantages, such as better flexibility and the ability to create save states. On the flip side, it also increases the complexity of the system, and consequently, the need of inhouse skills. The choice of which stream data analysis framework to use should be taken considering your specific necessities. To have Apache Flink as one of the available tools will surely increase your possibilities to take the data analysis and transformation process even further.

こんばんは。データ分析基盤グループ所属の大室です。 この記事は Safie Engineers' Blog! Advent Calendar 18日目の記事です！ はじめに 登壇内容 セッション概要 当社のご紹介 プロジェクト背景 プロジェクト始動 CData Syncの採用ポイント 今後の展望 余談 会場風景 We are hiring! はじめに 2024年9月12日、 Snowflake World Tour Tokyo 2024 にて「SnowflakeとCData Syncを採用したSafieのデータ分析基盤構築におけるポイント」と題したセッションに登壇しました。 本セッションは事前登録時点で満席の申し込みを頂き、当日も多くの方にご参加頂きました！ この記事では当日の登壇資料をベースにセッション内容をご紹介します。 なお、本セッションはCData社のスポンサーセッションにご招待頂く形で実現しました。 登壇の機会を頂いたCData社とSnowflake社の皆様にはこの場をお借りして感謝申し上げます。 会場は昨年と同じく、 ANAインターコンチネンタル東京 でした。 登壇させて頂いたセッション会場はこんな感じです。 CData社の杉本さん（左）と共同で登壇しました。 登壇中はCData社の疋田社長に撮影頂きました。ありがとうございました！ 登壇内容 セッション概要 まず最初に、セッションの概要についてお伝えします。 当社では複数SaaS導入によりデータのサイロ化が加速し、財務会計/管理会計におけるデータ分析上の課題が発生しました。 この課題を解決する上でデータ分析基盤が重要な役割を担うことになったのですが、その背景やポイントについてご説明したいと思います。 当社のご紹介 本題に入る前に、当社について紹介させて下さい。 当社はクラウドカメラの映像プラットフォームを提供する会社で、会社名もサービス名もセーフィー（Safie）と言います。 当社のサービスに対応するカメラをご利用頂くと、リアルタイムで映像がクラウドにアップロードされ、Webやモバイルの専用アプリから確認できる、というのが基本機能になっています。 基本機能以外にも、YouTube Liveと連携する機能や、AIで人を検知する機能など、オプション機能も充実しています。 現在、当社のサービスに対応するカメラは全体で約26万台ご契約頂いており、ユーザー様の用途は多様化しています。 やはり防犯・監視用途で利用されることが多いのですが、防犯だけではなく、建設や工事の現場における異常検知や現場監督のリモート化など、人材不足解消を目的とした用途でも広く利用されています。 当社のサービスはオプション含め、基本的にサブスクリプション型で提供しているため、売上全体に占めるリカーリング売上の割合が大きいです。 また、当社はカメラ本体の販売や設置工事も行っておりますので、一般的なSaaS企業と比較するとスポット売上の割合が大きいのが特徴的だと思います。 プロジェクト背景 当社では元々、サブスクリプションの契約管理にSalesforceを使用していました。 しかし、Salesforceはいわゆるワンショットの取引をベースに設計されているサービスなので、サブスクリプションの契約、更新管理、月単位での請求のレコード自動生成等はアドオンを開発しなければならず、オペレーションコストや開発コストが非常に多くかかっていました。 そこで、ビジネスオペレーションの最適化、オペレーションコストの削減や開発コストの抑制を目的として、サブスクリプションに特化した契約管理サービスのZuoraを導入することになりました。 しかし、Zuora導入に伴い別の課題が浮上しました。端的に申し上げると、データのサイロ化です。 Zuora導入後もSalesforceはSFAとして継続利用するため、商談や商流、各種マスタデータはそのままSalesforceで維持されます。 一方、Zuora導入後はSalesforce上のサブスクリプション契約関連オブジェクトが更新されなくなるため、元々Salesforceのレポート機能で完結していた財務会計/管理会計に関連するレポートも更新されなくなるという課題が発生しました。 プロジェクト始動 前述の課題が顕在化したのはZuora本番稼働開始の数ヶ月前。上場企業としてタイムリーに会計業務を遂行できなくなることは、経営上の大きなリスクでした。 この課題を解決するためには、サイロ化している各種データをどこかで結合し、財務会計/管理会計レポートを再構築する必要がありました。そこで声を掛けられたのが、私が管轄しているデータ分析基盤グループです。 データ分析基盤グループでは元々、 Safieプラットフォーム（サービスのバックエンドDB）のデータをSnowflake（DWH）に連携し、Tableau（BIツール）で可視化する仕組みを構築していました。 しかし、SalesforceやZuoraをSnowflakeに連携する仕組みは構築していませんでした。当初はスクラッチ開発で仕組みの構築を検討しましたが、データエンジニアのリソースが不足している事情もあり断念。 短期間で確実に開発を終えられる方法を模索した結果、Salesforceのデータ連携用に CData Sync 、Zuoraのデータ連携用に Zuora Secure Data Share for Snowflake （Zuora社からSnowflakeのデータシェアリング機能でデータを共有頂くサービス）を導入しました。 各ツールの検証には1ヶ月程度掛かりましたが、CData社やZuora社のサポート、社内のSalesforceを管轄するチームと密に連携し、何とか正式導入に漕ぎ着けることが出来ました。 ちなみに、CData SyncはAWSのEC2インスタンスでホスティングして運用しています。 そして、既存の財務会計/管理会計レポートのロジックを、各種データを掛け合わせた形で再構築し、Tableauで可視化。会計業務の継続に大きく貢献することができました。 CData Syncの採用ポイント CData Syncの導入はすんなり決まったわけではなく、OSSのツールをホスティングする方法や、各種データ連携SaaSと比較検討していました。 CData SyncはGUIベースで容易にジョブの実装が可能であり、履歴化処理やメタデータの自動検出によるスキーマ同期機能・dbt Cloudとの連携機能を有しているため、少ない開発リソースでも短期間で実装可能なイメージを持つことができました。 また、中長期的にはSalesforce以外のSaaSとの連携にも活用でき、価格帯も予算にフィットしたことから、当社のデータ分析基盤にはCData Syncが適していると判断しました。 今後の展望 今回のプロジェクトは短納期かつデータエンジニアの工数が不足していた事情から、やむを得ずSalesforceやZuora由来のデータにはデータモデリングを適用せず、Tableau側でデータの結合や変換処理の大部分を実装しました。 そのため、開発者目線だと運用・保守の負荷が高く、利用者目線だとTableauを経由しないと財務会計/管理会計に関するデータを閲覧できないという課題が生じています。 また、コスト抑制の観点から、Tableauのライセンスは定期利用の見込みがある一部の利用者にしか提供できないという社内事情も相まって、データの民主化のボトルネックになっています。 現在はこのような状態ですが、 今後はSalesforceやZuora由来のデータにもデータモデリングを適用し、Tableau側の処理依存度を低下させ、データ分析基盤全体の拡張性や保守性を向上し、データの民主化を推進できる土壌を整えていきたいと考えています。 余談 イベント登壇前後で会場を徘徊しておりましたので、当日の写真を数点共有します。会場の雰囲気が少しでも伝われば幸いです。 ちなみに、Snowflake社公式で Snowflake World Tour Tokyo 2024のハイライト動画 が公開されていますので、こちらもぜひチェックしてみて下さい。 会場風景 Keynoteセッションは満席。Snowflake社のスリダール・ラマスワミCEOが登壇していました。 Snowflake界のアイドル（?）くま太郎。可愛さが爆発していました。 CData社のブースには、 SafieのAIソリューション「AI-App人数カウント」のデータ連携にCData Syncが対応した件 のチラシを置いて頂きました。ありがとうございます！ 来訪者には、Snowflakeに連携したいサービスにシールを貼ってもらっていたようです。 Safieにもシールが貼ってありますね！ Snowflakeの資格を持っていると素敵なグッズが貰えます。 今年はイケてる缶バッジとTシャツでした。家宝にします。 We are hiring! 最後になりますが、データ分析基盤グループでは一緒に働いてくれる仲間を大募集中です！ セーフィーのデバイスやアプリケーションからは1日あたり約80億件のログが発生し、データ量は線形的に増加しています。 このような超ビッグデータを効率的に処理し、ビジネスの意思決定に繋げるための仕組みを一緒に作ってみませんか？ ご興味のある方は セーフィー採用サイト を覗いてみて下さい。 皆様のご応募、心よりお待ちしております！

この記事は Safie Engineers' Blog! Advent Calendar 17日目の記事です はじめに こんにちは、第1開発部でサーバーサイドエンジニアをしている伊東公平です。今回は、昨年の11月から今日まで1年以上に渡って、スクラムマスターとしてチームの改善のために試行錯誤してきた内容についてお伝えします。 はじめに 課題 取り組んだこと スクラムの基盤づくり チームの強化 適切なツールへの移行 プロダクトバックログ スプリントバックログ 最後に 課題 私がスクラムマスターとして就任した際にはすでにチームでスクラム開発を採用していました。しかし、その中での課題はまだ多くありました。その中でも私個人としては、以下のようなものに改善するメリットがあると感じていました。 課題①: スプリントゴールが不明瞭で、スプリントの途中で現時点の進捗を把握する手段が少ない。そのため、チームとしての目的意識が保ちづらい 課題②: タスクの背景理解ができていないままタスクをとり、実装することで仕様とのズレが生じ、手戻りが発生しやすくなる 課題③: 使用しているツールがバラバラで、ツール間の連携がうまく取れていないため、ツールの管理や移行に時間がかかる 取り組んだこと 上記のような課題を感じていた中で、これに対処するために大きな取り組みとして以下のようなことを1年に渡り行ってきました。この3つの取り組みに対し、それぞれの目的と効果について以降では説明していきたいと思います。 スクラムの基盤づくり スクラムマスターとして最初に取り組んだのは、チーム内でのスクラムに対する認識やルールを整えることでした。これは先に挙げた課題①を解決するために行いました。 スクラムイベントの開催日時を見直し固定化 当初、スクラムイベントが開催される日時が非効率な点がいくつかありました。 例えば、スプリントの切り替わりで半日時間が空いてしまうため、スプリント間の連続性がなくなっていたというようなものです。 そのため、以下のようにスプリントの振り返りとプランニング間での連続性を持たせるようにスプリントのスケジュールを見直しました。特にスプリントの振り返りとプランニングは振り返りを行ったことを即座にプランニングで反映できるようにすることを意識しました。 定量的に現在の進捗を計測 チーム内でスプリントの途中でも現在の進捗を定量的に確認できるように、以下のようなバーンダウンチャートを作成しました。これにより、進捗が遅れている場合は朝会でそれを確認できるようになり、振り返りの際にその原因をチームで会話できる体制を整えました。 上記の2点の取り組みにより、スプリントの区切りがはっきりし、進捗も明らかになり、いつまでにスプリントゴールを達成するといった意識がより強くなったと考えています。 チームの強化 次にチーム内で取り組んだのは 強いチーム 作りです。私の中の定義としては、「一人一人が自律し、スプリントでのタスクを消化できるような状態」を目指すために行いました。 これは課題②の解決にもなると考え行いました。 具体的には、プランニングの際に以下のようなユーザーストーリーを作成するようにしました。 ユーザーストーリーとは、エンドユーザー目線から必要な機能をタスクに分解していく手法です。青枠がサービスの機能でそれを黄色枠部分のユーザーストーリー、さらにその下のタスクまで分解する作業をチームメンバー全員で行うようにしました。 ユーザーストーリーを作成することで、タスクの背景を重点的に説明する機会が増え、チーム全員が以前より背景を理解した上でタスクの消化を行うことができるようになりました。また、タスクを作成する際の属人化を避けられるようになり、チームメンバーの誰でもタスクを作成できるという意識づけもできたと考えています。 適切なツールへの移行 最後に、スクラムイベントを行うにあたり、私のチームで使用しているツールを使用方法や現状のチームに合わせていくつか移行してきましたので、その紹介をしたいと思います。 これは、課題③でもあったように、複数ツールを使用することにより、ツール間の連携が取りづらく、タスク管理が二重になってしまっていたり、うまくそのツールを有効活用できていなかったため、この負を解決するために移行しました。 以下に改善前の使用ツールと改善後の使用ツールの一覧を載せます。 種類 改善前 改善後 プロダクトバックログ Miro GitHub Projects スプリントバックログ Backlog GitHub Projects 振り返り Jamboard Miro 上記の移行により、最も効果が現れたのは、プロダクトバックログとスプリントバックログ をGitHub Projectsへ移行したことでした。以下のように、同じツールを使用することで二重管理から解放され、プルリクエストとの紐付け等も行いやすくなりました。 プロダクトバックログ スプリントバックログ 最後に 今回のブログでは、この一年間に渡ってスクラムマスターとして自分のチームをどのように変革してきたのかを紹介しました。ここでは紹介しなかった変革も沢山ありますし、失敗したものもいくつもありますが、全て挑戦して良かったと思っています。 また、今回紹介した内容が全てのチームに当てはまるわけではないので、参考にされる場合も「そんな考え方があるのかと」と思うぐらいで軽く考え、自チームにあった方法に改善して活用していただけると嬉しいです。

はじめに 　 この記事は Safie Engineers' Blog! Advent Calendar 16日目の記事です 　セーフィーのサーバーサイドエンジニアの三村です。 　セーフィーのサーバーサイドでは箇所によって色々な言語（Python, Go, Java…）が用いられていますが、コードベースの大部分はPythonを用いています。本記事では、そんな普段セーフィーのエンジニアが用いているPython（ *1 ）のガベージコレクションの仕組みについて調べたので、まとめてみます。 はじめに 概要の説明 参照数によるガベージコレクションの実装 概要 intのオブジェクトでの例 世代別の循環参照検知のガベージコレクションの実装 世代とは オブジェクトのリストの作成 オブジェクトのリストの走査 到達不能のオブジェクトの探索 まとめ 概要の説明 　多くのプログラミング言語には、ユーザーが明示的に行なわずとも自動で不要なデータをメモリから解放するガベージコレクションの仕組みがあります。こちらは各言語ごとに仕組みや詳細な実装は異なっていますが、Pythonの場合には2種類の自動のメモリ解放の仕組みがあります。 　一つ目は、Pythonの全てのオブジェクトに被参照数のカウントを持つようにして、それが0になったらメモリ解放をするという単純なものです。 　もう一つは、上記の手法では対応できない循環参照の検知のための仕組みです。全てのオブジェクトを「世代」に分けてトラックしておき、それらの中で使われていないものを探索し開放する手法のものです。 参照数によるガベージコレクションの実装 概要 　Pythonのオブジェクト（Cのコードでは PyObject と呼ばれる）は全て、被参照数をデータとして持っています。こちらのカウンターが0になるとメモリ解放がされます。こちらの、PyObjectの被参照数を減らして数が0になれば削除をしている実装を見てみます。 static inline Py_ALWAYS_INLINE void Py_DECREF (PyObject *op) { // Non-limited C API and limited C API for Python 3.9 and older access // directly PyObject.ob_refcnt. if ( _Py_IsImmortal (op)) { return ; } _Py_DECREF_STAT_INC (); if (--op->ob_refcnt == 0 ) { _Py_Dealloc (op); } } cpython/Include/object.h at v3.12.7 · python/cpython · GitHub 　引数で受け取ったPyObjectの被参照数を表す ob_refcount をデクリメントして、値が0になれば _PyDealloc というメモリ解放の関数を呼び出しています。 呼び出される _PyDealloc の関数は、以下の実装になっています。 // デバッグモードの時等の挙動が長いので、それらを省いて簡略化 void _Py_Dealloc (PyObject *op) { PyTypeObject *type = Py_TYPE (op); destructor dealloc = type->tp_dealloc; (*dealloc)(op); } cpython/Objects/object.c at v3.12.7 · python/cpython · GitHub 　削除対象のオブジェクトの型（ Py_TYPE ）がそれぞれ持つ tp_dealloc という関数を呼び出してメモリ解放を行なっています。このように、Pythonのオブジェクトの型ごとにメモリ解放の実装は異なっています。 intのオブジェクトでの例 　いくつもあるPythonの型の中で、一例としてint型のオブジェクトの参照数によるメモリ解放の例を見てみます。（ *2 ） long_dealloc (PyObject *self) { /* This should never get called, but we also don't want to SEGV if * we accidentally decref small Ints out of existence. Instead, * since small Ints are immortal, re-set the reference count. */ PyLongObject *pylong = (PyLongObject*)self; if (pylong && _PyLong_IsCompact (pylong)) { stwodigits ival = medium_value (pylong); if ( IS_SMALL_INT (ival)) { PyLongObject *small_pylong = (PyLongObject *) get_small_int ((sdigit)ival); if (pylong == small_pylong) { _Py_SetImmortal (self); return ; } } } Py_TYPE (self)-> tp_free (self); } cpython/Objects/longobject.c at v3.12.7 · python/cpython · GitHub 　条件分岐を経て、最後の部分でメモリ解放（ tp_free の中で実際にはされています）がされています。 　余談ですが、上で引用したコードの中ではこのintの値が特定の基準よりも小さいかどうかを判定（ IS_SMALL_INT ） *3 して、小さければ _Py_SetImmortal をしてガベージコレクションにかけられないようにしています。こちらはPython3.12以降には、使用頻度が高いことが見込まれる小さい値のintのオブジェクトを削除しないようにした、パフォーマンス向上目的の変更です。こちらの仕様の導入には色々議論があったようで、気になった方は こちら のPRを見てみてください。 世代別の循環参照検知のガベージコレクションの実装 　上記のようなシンプルな参照数によるガベージコレクションがあれば、それで足りるのではないかと思うかもしれませんが、実際はそれでは済みません。Pythonのオブジェクト同士の循環参照のケースが、上のやり方だとカバーできないためです。このケースを避けるため、Pythonにはもう一つ世代別のガベージコレクションの仕組みが存在します。 世代とは 　（プログラミングの実行時の一般論として）ほとんどのオブジェクトは作成直後に使用されなくなる傾向があり、作成直後のオブジェクトのリストのほうが作成から時間の経ったオブジェクトよりも、ガベージコレクションの対象となる確率が高くなります。 　そのため、循環参照の検知のような重めの処理では、「世代」の若い（作られて間もない）オブジェクトのチェックを頻繁に行い、「世代の古い」（作られて時間の経っている）オブジェクトのチェックはより稀に行うようにして、効率化を図っています。 　この考え方は、Python独自のものではなくそのほかのプログラミング言語（Java等）でも一般的に用いられています。 オブジェクトのリストの作成 　Pythonのこちらの方式のガベージコレクションでは、世代ごとに循環参照となり得るすべてのオブジェクト（=他のPyObjectへの参照を持っているPyObject）のリストを持ちます。その後、そのリストの内部を走査し、特定の世代内部のみで循環参照をしているものを見つけて、メモリ解放をします。 　ここではまず、特定の世代のPyObjectを双方向リストとして保持する実装を見てみます。こちらの双方向リストには、オブジェクトの作成時に追加されます。以下でtupleのオブジェクトの生成時の例を挙げます。 PyObject * PyTuple_New (Py_ssize_t size) { PyTupleObject *op; if (size == 0 ) { return tuple_get_empty (); } op = tuple_alloc (size); if (op == NULL ) { return NULL ; } for (Py_ssize_t i = 0 ; i < size; i++) { op->ob_item[i] = NULL ; } _PyObject_GC_TRACK (op); // 筆者注: ここで作成したオブジェクトを、トラックできるようにしている return (PyObject *) op; } cpython/Objects/tupleobject.c at v3.12.7 · python/cpython · GitHub 　引用したコードの最後の方で _PyObject_GC_TRACK 関数を呼び出して、世代別ガベージコレクションで追跡できるよう、作成したtupleのオブジェクトを双方向リスト（各要素が、自身の前と次へのリンクを持っているリスト）に追加しています。 　こちらの _PyObject_GC_TRACK の処理の実装を見てみます。 static inline void _PyObject_GC_TRACK ( // The preprocessor removes _PyObject_ASSERT_FROM() calls if NDEBUG is defined #ifndef NDEBUG const char *filename, int lineno, #endif PyObject *op) { _PyObject_ASSERT_FROM (op, ! _PyObject_GC_IS_TRACKED (op), "object already tracked by the garbage collector" , filename, lineno, __func__ ); PyGC_Head *gc = _Py_AS_GC (op); _PyObject_ASSERT_FROM (op, (gc->_gc_prev & _PyGC_PREV_MASK_COLLECTING) == 0 , "object is in generation which is garbage collected" , filename, lineno, __func__ ); PyInterpreterState *interp = _PyInterpreterState_GET (); PyGC_Head *generation0 = interp->gc.generation0; PyGC_Head *last = (PyGC_Head*)(generation0->_gc_prev); _PyGCHead_SET_NEXT (last, gc); // 筆者注: この辺からリストへの追加を行なっている _PyGCHead_SET_PREV (gc, last); _PyGCHead_SET_NEXT (gc, generation0); generation0->_gc_prev = ( uintptr_t )gc; } cpython/Include/internal/pycore_object.h at v3.12.7 · python/cpython · GitHub 　こちらのコード内の gc というものが、引数で受け取ったPyObjectをガベージコレクションで追跡できるような型にキャストしたものです。こちらを、現在のラインタイムにおける最も若い世代のPyObjectの双方向リスト（ generation0 ）の最後尾に追加しています。 オブジェクトのリストの走査 　上で特定の世代のPyObjectのリストに要素を追加する実装例を見たので、次にそのリスト内を走査する実装を見て見ます。こちらは以下の gc_collect_main 関数で実行されています。 /* This is the main function. Read this to understand how the * collection process works. */ static Py_ssize_t gc_collect_main (PyThreadState *tstate, int generation, Py_ssize_t *n_collected, Py_ssize_t *n_uncollectable, int nofail) { int i; Py_ssize_t m = 0 ; /* # objects collected */ Py_ssize_t n = 0 ; /* # unreachable objects that couldn't be collected */ PyGC_Head *young; /* the generation we are examining */ PyGC_Head *old; /* next older generation */ PyGC_Head unreachable; /* non-problematic unreachable trash */ PyGC_Head finalizers; /* objects with, & reachable from, __del__ */ PyGC_Head *gc; _PyTime_t t1 = 0 ; /* initialize to prevent a compiler warning */ GCState *gcstate = &tstate->interp->gc; // 略 // 筆者注: 1. 若い世代のマージ /* merge younger generations with one we are currently collecting */ for (i = 0 ; i < generation; i++) { gc_list_merge ( GEN_HEAD (gcstate, i), GEN_HEAD (gcstate, generation)); } /* handy references */ young = GEN_HEAD (gcstate, generation); if (generation < NUM_GENERATIONS- 1 ) old = GEN_HEAD (gcstate, generation+ 1 ); else old = young; validate_list (old, collecting_clear_unreachable_clear); // 筆者注: 2. 到達不能のオブジェクトの探索 deduce_unreachable (young, &unreachable); untrack_tuples (young); // 筆者注: 3. 到達可能のオブジェクトを古い世代に移動 /* Move reachable objects to next generation. */ if (young != old) { if (generation == NUM_GENERATIONS - 2 ) { gcstate->long_lived_pending += gc_list_size (young); } gc_list_merge (young, old); } else { /* We only un-track dicts in full collections, to avoid quadratic dict build-up. See issue #14775. */ untrack_dicts (young); gcstate->long_lived_pending = 0 ; gcstate->long_lived_total = gc_list_size (young); } // 略 // 筆者注: 4. 到達不能のオブジェクトの削除 /* Call tp_finalize on objects which have one. */ finalize_garbage (tstate, &unreachable); /* Handle any objects that may have resurrected after the call * to 'finalize_garbage' and continue the collection with the * objects that are still unreachable */ PyGC_Head final_unreachable; handle_resurrected_objects (&unreachable, &final_unreachable, old); /* Call tp_clear on objects in the final_unreachable set. This will cause * the reference cycles to be broken. It may also cause some objects * in finalizers to be freed. */ m += gc_list_size (&final_unreachable); delete_garbage (tstate, gcstate, &final_unreachable, old); // 略 } cpython/Modules/gcmodule.c at v3.12.7 · python/cpython · GitHub 　上記で引用したコード（ *4 ）では、引数 generation で受け取った世代のリストのコレクションを実行します。以下のような手順でオブジェクトのリストを走査しています。 1.若い世代のマージ 　本関数でコレクションをする対象の世代のリストに、それよりも若い世代のコレクション対象リストをマージします（ gc_list_merge 関数）。 　例として、第3世代のコレクションをしている場合は、第3世代のリストに第1世代と第2世代のリストをマージして、このリストをガベージコレクションのチェックの対象とします。こうすることで、若い世代のリストほど、ガベージコレクションの走査の対象となる頻度が高くなります。 2.到達不能のオブジェクトの探索 　 1. 若い世代のマージ で作成したリストの中から、到達不能なオブジェクトを探し出します（ deduce_unreachable 関数）。この関数の中では、循環参照を検知（後述）して、参照はあるものの実際は到達不能なオブジェクト（=参照数カウントのガベージコレクションでは検知できないが、実際は削除するべきオブジェクト）を探します。 3.到達可能のオブジェクトを古い世代に移動 　 2. 到達不能のオブジェクトの探索 でのチェックで引っ掛からなかった、コレクションの対象とすべきでないオブジェクトを、一つ古い世代に移します。こちらは先述した通り、作成されてから時間が経ったオブジェクトほど削除対象となる確率が下がるためです。 4.到達不能のオブジェクトの削除 　 2. 到達不能のオブジェクトの探索 で削除が必要と判明したオブジェクトを、実際に削除します。 到達不能のオブジェクトの探索 　上で、PyObjectのリストから到達不能なものを探索して削除する実装を軽くみてみました。次に、具体的にどのようなロジックで到達不能なオブジェクトを探しているのかを見てみます。上で到達不能なオブジェクトを探索するのに用いていた、 deduce_unreachable の実装を引用します。 // 筆者注: コードに元々あったコメントを削除し、筆者のコメントを追加 static inline void deduce_unreachable (PyGC_Head *base, PyGC_Head *unreachable) { validate_list (base, collecting_clear_unreachable_clear); update_refs (base); // 1. GC用のカウンターをセット subtract_refs (base); // 2. 他のオブジェクトからの参照を探して、その分カウンターを減らす gc_list_init (unreachable); move_unreachable (base, unreachable); // 3. カウンターの値を元に、削除対象のオブジェクトを探す validate_list (base, collecting_clear_unreachable_clear); validate_list (unreachable, collecting_set_unreachable_set); } cpython/Modules/gcmodule.c at v3.12.7 · python/cpython · GitHub 　まず、 1. GC用のカウンターをセット の部分で、検査対象の世代の全オブジェクトのリスト（実装上は containers と呼ばれる）を走査し、参照数によるガベージコレクションに用いられている obj_refcnt とは別に本処理用に gc_refs というカウンターを設定します。新しく設定した後者のカウンターには、デフォルト値として前者と同じ値を入れます。 　以下に、簡単な図解を用意します。ここでは、オブジェクト A から E までがあり、それら全てに gc_refs の値を参照数である obj_refcnt の値を設定しています。この例だと、 A , B , C はこの世代の外から参照されており削除対象とはなりませんが、 D と E はお互いの循環参照のみによって参照されていて、もう利用されておらずガベージコレクションで削除されるべきオブジェクトになります。 各オブジェクトにおいて、obj_refcntの数をgc_refsにコピーする 　次に、上で引用したコードの 2. 他のオブジェクトからの参照を探して、その分カウンターを減らす の部分で、GC対象のオブジェクトのリストでイテレーションを回します。その中で、それぞれのオブジェクトが持つ他のオブジェクトへの参照を探し出して、参照先のオブジェクトの gc_refs のカウンターを1ずつ減らします。 　例えばオブジェクトがdict型であれば、自身の辞書のkeyとvalueの両方のオブジェクトの gc_refs をデクリメントします。（ *5 ） 　以下の例だと、 A は B への参照を持つため B のgc_refsを減らし、同様に B は C への参照を持つためCのgc_refsを減らします。 D と E はお互いを参照しているので、お互いのgc_refsを減らします。 各オブジェクトの参照を辿って、参照先のオブジェクトのgc_refsを1ずつ減らしていく 　その後、上記引用のコードの 3. カウンターの値を元に、削除対象のオブジェクトを探す の箇所で、 gc_refs の値を元に循環参照でのみ参照されているオブジェクト（=参照数が0ではないがもう利用されていないオブジェクト）を探します。 　まず、 gc_refs が0であるオブジェクトと1以上であるオブジェクトに分離します。オブジェクトに参照がある場合はそのまま containers に置かれ、なければ unreachable というリストに移されます。 　 gc_refs が0である場合、この世代の外側から参照されていない可能性があります。こちらが、ガベージコレクションの対象となるオブジェクトの候補のリストとなります（後述する通り、この時点ではコレクションの対象となると確定したわけではないです）。 　逆に gc_refs が1以上であれば、それは現在使用されているオブジェクトであると判定できます。この場合、この世代以外の箇所からも参照されていると判断できるため、この時点でガベージコレクションの対象からは外れます。 　下記の例だと、gc_refsが1以上であり確実に利用されていると言えるのは A のみです。ただし、gc_refsが0である unreachable のリストの中には、確かにコレクション対象となるべき D と E も存在しますが、 A から利用されていて消されるべきではない B と C も存在します gc_refsが1以上であれば外部からの参照が確実にあると言えて、そうでなければ到達不能な可能性がある 　次に、 gc_refs > 0 のリストのオブジェクトでイテレーションを回して、それぞれのオブジェクトが持つ参照の中に、 gc_refs == 0 のリストに入れられたオブジェクトがないかを探します。 　もし gc_refs が0であったとしても（=オブジェクト間の循環参照のみによって参照されていても）、消してはいけないオブジェクトによって参照されているのであれば、そのオブジェクトはまだ利用されていると判断できます。 　元々 gc_refs が0である削除候補のリストに入っていたとしても、上記のチェックでまだ利用されていると判断された場合、 gc_refs が1以上のリストの方に移動されます。 　下記の例だと、 A からの参照があることにより B がcontainersに戻され、同様に B からの参照があることにより C が戻されます。 object Bからobject Cにたどり着いたので、Cのgc_refsを増やしてunreachableリストから除く 　上のチェックが全て終わった後も、まだ削除候補のリストに入っているオブジェクト（図の例だとオブジェクトの D と E ）は、削除されてメモリ解放がされます。 まとめ 　このように、Pythonのガベージコレクションは基本的には参照数を元に行なっていて、それではカバーできない循環参照を別途探して削除しており、後者は重い処理であるため世代の概念を導入しています。 　セーフィーではエンジニアを積極的に募集しています。気になる方は以下をご覧ください。 カジュアル面談から受け付けておりますので、お気軽にご応募ください。 safie.co.jp *1 : この記事でPythonという時、CPythonの3.12のバージョンのことを指します *2 : Cのコード内でオブジェクト名等は Long となっていますが、これは Pythonの世界的にはintのことを指します *3 : -5から257の間であるかを判定 *4 : 引用したコードはだいぶ省略していてかなり簡略化されているので、より詳細な実装が気になる方はコードの方を見てみてください *5 : dict型オブジェクトにおける実装は こちら

この記事は Safie Engineers' Blog! Advent Calendar 15日目の記事です はじめに こんにちは、あるいはこんばんわ。 第1開発部QCDグループ 小山と申します。 ついに24年も年末となり、今年も懲りず締め切り間際になってから筆を走らせている次第です。 今年のアドベントカレンダーですが、QCDグループの人数も計14名と増えできることも少しずつ増えましたので、改めて 24年版『QCDグループって何をしているグループ？』 をテーマに現状のQCDグループについて紹介をしたいと思います。 過去記事リンクはこちら engineers.safie.link 今回はスクショとかも少なく文字がいっぱいなので安眠効果抜群です。 はじめに 主な業務内容 実施しているテストの種類 テスト自動化に関して ＜リグレッションテストの自動化率＞ ＜リグレッションテスト自動化によって実現できた削減工数＞ ＜各プロダクトにおける自動テスト実行頻度＞ セーフィーのQAエンジニア＝テスト/SETエンジニアのこと？ ＜どんなバラツキがあるのか（一例）＞ その他 最近始めてみたこと セーフィーのQAエンジニアとは（まとめ） 来年度に向けた準備（MVVを決めました） ＜MVV＞ 主な業務内容 QCDグループですが通称QAチームといわれることも多いです。 大まかにテストに関わる部分を ”中心に” 担当しているグループということは変わりないです。 担当しているプロダクトとしては以下の図のようなものとなっています 上記一覧の中で、業務システム以外は概ねQCDとしてプロダクトの品質を向上すべく開発業務に携わっています。 基本的に、1メンバーに対し定期リリースのあるIoTデバイス系プロダクト・または新規プロダクトの複数を担当として受け持ってもらっているのが現状です。 プロダクト内でどういった業務（テストなど）をセーフィーのQAエンジニアが行っているかといいますと、プロダクトごとに差分はありますが概ね以下の内容となっています。 実施しているテストの種類 エンハンス内容に対する機能テスト 既存機能に対するリグレッションテスト（エンハンス時に設計したテストの簡易版） 上記をブラックボックステストとして実施しています。 非機能テストについては、プロダクトの要求・要件定義時にPdM側に協力は依頼しつつ、明記してもらえた場合は要求を満たせているかを各担当者ごとに保証するような形で行っていますが、体系的に非機能についても保証ができているとは言いづらいのが現状ではあります。 テスト自動化に関して 思い返せば3年前になりますね。 テスト自動化について動き始めた当初は、リグレッションテストの工数削減を目的としてテスト自動化を進めてきました（毎月楽になる未来を想像していた） しかしながらふたを開けてみると、月に一度実行しないとメンテナンスを短期間で終わらせないといけないこともあり、上手く削減できているという実感を得ることは難しかったです。 そこでリグレッションテストの実施工数削減だけでなく 毎日の成果物としてコミットされるエンハンスに対し自動テストを動かすことで、不具合を早期に発見しプロダクトの品質を向上させる 手動でしかできない所を注力してテストを実行できる環境を作る 上記を目的に加え自動テストのシナリオを大きく見直しました。 現在の実績として、リグレッションテストの自動テスト化の主要なプロダクトについては以下の進捗となっています。 ＜リグレッションテストの自動化率＞ ＜リグレッションテスト自動化によって実現できた削減工数＞ ＜各プロダクトにおける自動テスト実行頻度＞ 来期以降に関してはリグレッションテストだけではなく、影響範囲として漏れがちな直近でエンハンスがないプロダクトやソリューションも含め実装対象としていけるよう準備を始めています。 実行頻度についても現状より多くのプロダクトで毎日実行できることを目標に設定し、トラブルが発生してしまった場合に備え自動テストの実行結果をきっかけにして素早く異常に気付ける体制を築いていけるようにしていきたいと考えています。 自動テスト対象を増やし実行頻度をあげることで、リグレッションテストにかかる工数やエンハンスが暫くなかったプロダクトやサービスにかかる保守工数を下げ、改善活動や新規プロダクトに対するテストに注力できる体制を実現できるようになる（はず） セーフィーのQAエンジニア＝テスト/SETエンジニアのこと？ と、ここまで書いてきてセーフィーのQAエンジニアは テストエンジニア/テストマネージャー or SET（Software Engineer in Test）エンジニア のことなのかな？と思われてしまいそうですが・・・ いわゆる「良いプロダクト」を出すために様々なことを行うQAエンジニアとして、テスト活動だけでなく要件定義～リリース後のフェーズでプロダクト全体の品質を高められるように（担当者によってバラツキがあるのが現状ですが）活動を行っております。 ＜どんなバラツキがあるのか（一例）＞ ビジネスとして成り立つか（利益を生むことができるか） サポート部門の運用を踏まえ、特殊対応をしなくてよいか PoC（概念検証）実施時、何に気を付けなければならないか、目的がブレていないか 上記については体系的な知識の習得方法があるわけではないため、個人の経歴・経験・センスによって品質保証活動での粒度がバラついてしまっています。 このバラツキに関しては来期以降も解消に向け継続して取り組みたいと考えています。 対応案の一つとして、最近QAエンジニアとしてセーフィーに加わってくださったメンバーの方が、各フェーズで行ったほうがいい/注意しなければならない指針と観点を作成してくれていますので、近いうちに発信してくださるはず・・・！ その他 最近始めてみたこと 最近ですが社内ツールのエンハンスを開発しているプロダクトチームに対して「品質とは？」というテーマで勉強会を行った方がいます。 こういった啓蒙活動はプロダクトだけでなく、開発本部全体ゆくゆくは営業本部なども含め全社に対して行っていけるようにグループとして準備していきたいと考えています。 ※参考：狩野モデルとは？5つの「品質」や、導入するメリット・注意点を解説 https://service.shiftinc.jp/column/10933/ セーフィーのQAエンジニアとは（まとめ） 現状のセーフィーのQAエンジニアは、基本的なテストエンジニア/テストマネージャーとしての経験を活かし、 『テスト活動やE2Eテストの自動化やプロセスの改善などの品質を向上させるための様々な活動 を各自の希望に沿って行うエンジニア』 です。 今後はテスト活動以外で様々な品質を向上させるために”改善活動”を行い、より良い・価値のあるプロダクトをお客様に迅速に提供できるように来期からは準備を進めていきたいと考えています。 来年度に向けた準備（MVVを決めました） 急に話の内容が変わりますが、月日は早いもので私が入社してから3年が経過しおかげさまでQCDグループの活動領域も人員も増えてきました。 （業務委託メンバー合わせ14名、25年からは計16名） 様々な考えや経歴を持つ方がいて、個性豊かでいいグループになってきたのではないかと個人的には思っております。 そんな中、グループとして1つの共通認識があると業務を進めやすいという話がメンバーから上がりましたので、組織開発を担当するエンジニアリングオフィスとも相談しつつQCDグループのMVV（Misson Vision Values）を策定することができました。 ※策定までの過程・苦労は25年内にQCDのグループリーダーが書いてくれるはずです。 ＜MVV＞ Misson ： 高品質・適正価格の「映像ソリューション」を提供し、あらゆる産業の現場DXを実現する。 Vision： 創る組織で開発における品質課題に目を向け、品質文化に根ざした改善活動をおこなえるようにする。 Values ： より良い品質にしていくために品質とは何かを定義して開発本部全体に広げる。 広げるためにも開発プロセス改善をする（もしくはしてくれという提案をする） 品質改善をし続けるために新しい技術やプロセスを取り入れ１人１人が成長する 2025年からはMVVに沿ってセーフィーという会社の品質を向上させるため真摯に品質改善を続け、グループ一丸となってテストだけではなく改善活動に取り組みたい ・・・と目標を宣言させていただきます。 どういった活動をしてどういう効果があった/効果が出にくかったのかは、来年の年末に施策と共に振り返ることができればなと思っております。 来年も価値のあるプロダクトをお客様に届けられるようにテスト及びそれ以外の領域で活動できればと思います。

この記事は Safie Engineers' Blog! Advent Calendar 14日目の記事です はじめに はじめまして、サーバーサイドエンジニアの大町です。2024年も早くも年末になりました。年末ということで今年の技術トレンドを振り返りたくなってきたので、Qiitaのブログ記事１万本のデータを分析してみました。 この記事では、2024年はどのような技術が熱かったかを分析した結果とその分析方法について共有したいと思います。 はじめに Qiita APIを使ったデータ収集と分析 データ収集の方法 データ分析の方法 おまけ（バイグラム） さいごに Qiita APIを使ったデータ収集と分析 今回はQiitaの記事を分析したのですが、Qiitaというサービスを選んだ理由はその知名度とデータ収集の容易さです。 まず知名度ですが、Qiitaは技術に関する情報を共有するサービスとして有名な方だと思います。その会員は120万を超えるらしいです。日本のITエンジニアが144万人ということを考えると、多くのエンジニアがなんらかの形でQiitaというサービスを使っていることになります。 corp.qiita.com また、データ収集の容易さですが、Qiitaは外部の開発者向けに API を公開しています。それを使うことで整形された形でのデータを簡単に収集することができます。Qiitaは基本的に技術記事が投稿されますので、技術以外の記事のデータが混ざるということはなく、世の中のエンジニアがどういう技術を使っているのかを知るには適したサービスです。 データ収集の方法 Qiita API は 記事の収集や投稿など多くのAPIが用意されています。今回データを収集するのに使ったAPIは記事の一覧を取得するAPI GET v2/api/items です。このAPI を用いると、最新の記事から順番に記事の内容を取得することができます。APIのレスポンスには、タイトル・内容・タグ・いいねの数などのデータが含まれます。 パラメータとしてpage(ページ番号)とper_page(ページあたりの記事数)を指定することが可能です。 例えば、以下のようなURLをブラウザに打ち込むと最新の記事のデータ20件を取得できます。（制限はありますが、特に認証しなくてもデータを得られます） https://qiita.com/api/v2/items?page=1&per_page=20 ページあたりの記事数（per_page）を100にして、page=1 からpage=100 までのデータを取ることで1万本の記事を取得しました。2024/12/1に記事を取得したので最新のものは12/1です。最も古いものは2024/10/28でした。ということで、約１ヶ月分の記事１万本を収集することができました。 データ分析の方法 タグを使った分析 Qiitaは記事作成の際に、記事に対してタグを付与することができます。そのタグの使用頻度を求めることで今よく使われている技術がわかりそうです。 結果は以下のようになりました。 ＜タグの頻度TOP１０＞ 順位 タグ 頻度 1 Python 1033 2 初心者 826 3 AWS 652 4 JavaScript 423 5 AI 297 6 React 271 7 Ruby 264 8 TypeScript 256 9 Docker 226 10 Rails 206 １位はPythonということで、他を圧倒していますね。5位に「AI」がランクインしていることからAI系の文脈でよく書かれていそうですね。 ２位が「初心者」でした。これは技術トレンドを調べるという意図からは外れたデータですが、Qiitaは初心者向けに書かれた記事が多いということがわかります。今回集めたデータはQiitaのみなので、初心者向けの記事が多いといったデータの偏りはありそうです。 １位のPythonが他を圧倒したというのも初心者向けの記事が多いからかもしれませんね。 記事のタイトルを使った分析 次に記事のタイトルを使った分析を行いました。分析方法はタグの場合とほとんど同じで、タイトルの中でよく使われる単語を求めました。ただ、タイトルはタグのように単語単位で分けられているわけではないので、まずタイトルを単語に分割する必要があります。 この処理は「単語の分かち書き」と呼ばれます。さらに「です」や「ます」など今回の分析には不要なワードも除きたいですね。 このような処理には、形態素解析ツールが便利です。形態素解析は自然言語処理（NLP）の一つで、　文を最小の単位（形態素）に分解し、分解した形態素に対して品詞などの情報を付与する作業のことをいいます。形態素解析ツールには様々ありますが、今回は手軽に使えるJanomeというツールを使いました。 Janomeでは数行のコードで形態素解析ができます。 以下のコードで「私は東京で働くエンジニアです。」という文を形態素解析してみました。 from janome.tokenizer import Tokenizer # Janomeの形態素解析器を初期化 tokenizer = Tokenizer() title= "私は東京で働くエンジニアです。" # 文をトークン（形態素）に分割してリストにする tokens = tokenizer.tokenize(title) for token in tokens: print (token) コードを実行すると以下のような出力が得られます。 私 名詞,代名詞,一般,*,*,*,私,ワタシ,ワタシ は 助詞,係助詞,*,*,*,*,は,ハ,ワ 東京 名詞,固有名詞,地域,一般,*,*,東京,トウキョウ,トーキョー で 助詞,格助詞,一般,*,*,*,で,デ,デ 働く 動詞,自立,*,*,五段・カ行イ音便,基本形,働く,ハタラク,ハタラク エンジニア 名詞,一般,*,*,*,*,エンジニア,エンジニア,エンジニア です 助動詞,*,*,*,特殊・デス,基本形,です,デス,デス 。 記号,句点,*,*,*,*,。,。,。 「私は東京で働くエンジニアです。」という文が小さな単位に分割されていますね。さらに品詞や読み方の情報なども付与されています。 今回は形態素解析を記事のタイトルに対して行い、その結果から単語の頻度を求めました。 まず、名詞のみを取り出して頻度を調べてみた結果が以下となります。 ＜名詞の頻度TOP１０＞ 順位 単語 頻度 1 方法 746 2 AWS 408 3 AI 401 4 作成 381 5 Python 378 6 環境 341 7 化 308 8 開発 307 9 データ 276 10 ファイル 264 タグとはちょっと違ったデータが出てきました。一番多いのが「方法」ですね。２位と倍くらい違います。 全体的にみて技術用語より一般的な用語が多く出てきてしまいました。そこで、取り出す用語を固有名詞に絞ってみました。 ＜固有名詞の頻度TOP１０＞ 順位 単語 頻度 1 AWS 336 2 AI 230 3 Python 205 4 API 136 5 C 124 6 React 108 7 Google 103 8 Rails 100 9 GitHub 99 10 Cloud 97 意図した感じのデータが取れました。AWSが一位です。 Cが５位にランクインしているのは少し驚きです。 7位がGoogleで10位がCloudなので、これはGoole Cloud ~ が多かったのかもしれません。 解析ツールの品詞情報の揺れ ここでAWSの頻度を見ていて気づいたのですが、ちょっとおかしいですね。 上の「名詞」で取り出した時のAWSの頻度は408ですが、「固有名詞」で取り出した場合は336と頻度が小さくなってしまいました。どういうことでしょうか。 同じAWSという単語でも「固有名詞」に分類されることもあれば、別の品詞に分類されるなど解析結果に揺れがあるのかもしれません。 そこで品詞の解析結果の揺れについて調べるために、「AWSについて学んだこと」「AWSを使ったインフラ構築」という２つの文でAWSの品詞に差分があるかJanomeを使って検証してみました。 「AWSについて学んだこと」の場合 AWS 名詞,固有名詞,組織,*,*,*,AWS,*,* <- 固有名詞として分類 について 助詞,格助詞,連語,*,*,*,について,ニツイテ,ニツイテ 学ん 動詞,自立,*,*,五段・バ行,連用タ接続,学ぶ,マナン,マナン で 助詞,接続助詞,*,*,*,*,で,デ,デ こと 名詞,非自立,一般,*,*,*,こと,コト,コト AWSが固有名詞で分類されています。 「AWSを使ったインフラ構築」 AWS 名詞,一般,*,*,*,*,AWS,*,* <- 一般名詞として分類されている を 助詞,格助詞,一般,*,*,*,を,ヲ,ヲ 使っ 動詞,自立,*,*,五段・ワ行促音便,連用タ接続,使う,ツカッ,ツカッ た 助動詞,*,*,*,特殊・タ,基本形,た,タ,タ インフラ 名詞,一般,*,*,*,*,インフラ,インフラ,インフラ 構築 名詞,サ変接続,*,*,*,*,構築,コウチク,コーチク AWSが一般名詞で分類されていますね。 同じAWSでも異なる分類のされかたをしていました。 一般に形態素解析では辞書のデータをもとに品詞を特定するので、AWSという単語は辞書に載っていなかったのかもしれませんね。 辞書に載っていない単語は未知語と呼ばれ、解析ツールが周囲の単語などから予測して品詞を求めます。その結果は周囲の単語に依存するので結果に揺れが生じることがあります。 結果の揺れに対する解決策は形態素解析ツールに搭載されている辞書にAWSという単語を追加すれば揺れなく分類可能ですが、今回は大雑把に傾向がつかめれば良いのでそこまではしていません。 おまけ（バイグラム） 最後にバイグラムについても出してみました。 *1 バイグラムとは２単語が連続した文字列です。一般にN単語またはN文字が連続した文字列をn-gramと言います。 なぜ出してみたかったかというと、先ほど出した名詞での頻度分析の結果を１０位までしか表には出していなかったのですが、実は１１位が「構築」という単語でした。 ６位が「環境」なので、「環境構築」という言葉が分割されたのだろうと思い、それを確かめてみたくなりました。 ＜バイグラムの頻度TOP１０＞ 順位 バイグラム 頻度 1 (環境, 構築) 131 2 (初心者, 向け) 80 3 (Next, js) 79 4 (生成, AI) 72 5 (対処, 法) 58 6 (文字, 列) 48 7 (Raspberry, Pi) 39 8 (ilasm, stack) 39 9 (stack, machine) 39 10 (解決, 方法) 38 やっぱり、環境構築でした。環境構築、たしかに大変ですよね。 生成AIはトレンディですね。このブログで調査するためのコードの大部分を生成AIで作成しました。 Raspberry Pi はよく聞くのでハードウェアへの入門として触ってみたいと思っているのですが、まだ触れられてません。来年こそは触ってみたいです。 生成AIやRaspberry Pi などのように、１単語の頻度ではTOPに出てこなかった単語が出てきたのでバイグラムも有用な情報ですね。 さいごに 今回の記事では、Qiita１万本の記事を使って技術のトレンドを調査してみました。普段、仕事ではデータと向き合うことはないので新鮮な気持ちになりました。 結果としては、AWSやPythonといった技術が（Qiitaコミュニティでは）人気だということがわかりました。 分析方法はタグや単語の頻度を求めるという単純な方法でしたが、それでも大雑把な傾向は見られたと思います。もし大量のテキストデータに出会う機会があれば、 単語の出現頻度を眺めてみてはいかがでしょうか。 *1 : 名詞に絞ってから、連続する２単語を出しているので正確にはバイグラムではない

こんにちは！セーフィー第2開発部のAndroidエンジニアのジェローム( @yujiro45 )です。 この記事はセーフィー株式会社 Advent Calendar 2024 の12月13日の記事です！ 2024年2月1日、360°全方位を広範囲に撮影できる魚眼レンズを搭載した新しいカメラ「 Safie GO 360 」が公開されました。このカメラのプレビューをアプリで表示するために、3Dモデルを使用する必要がありました。この記事では、Androidでどのようにこれを実現したかを説明します。٩( ᐛ )و 半天球カメラの動画再生の表示する方法 1. 3Dモデルを表示する 2. テクスチャマッピング 3. 画角 ジェスチャー 最小・最大ズームの距離計算 回転と移動 タップ位置へセンタリング まとめ 半天球カメラの動画再生の表示する方法 Safieビューアーのストリーミング画面はまだCompose化されていないので、この記事ではxmlの実装を紹介しますが、composeでも同じロジックです。 1. 3Dモデルを表示する 👇10月に書いた記事に関する記事と深く関連していますので、まだ読んでいない方はぜひご覧ください〜。 engineers.safie.link 360°全方位を広範囲に撮影した映像を表示するために、半球の3Dモデルが必要です。カスタム3Dモデルはコードで作成することもできますが、あまりにも複雑で時間がかかるため、Blenderで3Dモデルを作成し、それを使用することにしました。 前回の記事で書いたように、SceneViewでは .glb と .glTF ファイルしかサポートされていません。どちらか一方を選択する必要がありますが、 .glb ファイルの方が軽く、効率的であるため、 .glb を使用することにしました。 sceneView.apply { // 3Dモデル作成 val modelNode = ModelNode( modelInstance = modelLoader.createModelInstance( R.raw.hemisphere ) ) // モデルの位置と向きの設定 modelNode.position = Position(x = 0f , y = 0f , z = 0f ) modelNode.rotation = Rotation(x = 90f , z = 180f ) // モデルを追加する addChildNode(modelNode) } 2. テクスチャマッピング カメラの動画再生ではExoPlayer使用しています。 ExoPlayerで再生している映像をもとに、3Dモデルのテクスチャにマッピングするために、 ARでビデオを表示した時 に作成した ExoPlayerVideoMaterial を使います。 sceneView.apply { // 3Dモデル作成 val modelNode = ModelNode( modelInstance = modelLoader.createModelInstance( R.raw.hemisphere ) ) // 動画再生によるExoPlayer作成 val exoPlayer = ExoPlayer... // ExoPlayerのカスタムVideoMaterial作成 val exoPlayerVideoMaterial = ExoPlayerVideoMaterial( engine, exoPlayer, materialLoader ) // モデルの位置と向きの設定 modelNode.position = Position(x = 0f , y = 0f , z = 0f ) modelNode.rotation = Rotation(x = 90f , z = 180f ) // モデルを追加する addChildNode(modelNode) } 上記のコードをそのまま使うと、SceneViewが3Dモデルの背面にテクスチャをマッピングします。そのため、コンテンツが逆方向にマッピングされるような見た目になってしまいます。 理想 現実 これを修正するには、GitHubで説明されているように、モデルのx 軸上のスケールを反転させる必要があります。 github.com modelNode.scale = Scale(x = - 1f , y = 1f , z = 1f ) いい感じですね！🥳 3. 画角 Safie GO 360カメラは、壁と天井の2つのpositionに設置できます。 横向き 下向き 撮影向きによって、3Dモデルを回転させる方法は異なります。壁に設置された場合、動きは頭の動き（上下、左右）に従います。 しかし、天井に設置された場合は、3Dモデルを宙返りしないような制限を入れる必要があります。 SceneViewのデフォルトの挙動を使用すると、3Dモデルをどの方向にも回転させ、任意のスケールでズームイン/ズームアウトができますが、ユーザーが3Dモデルの背面を見ることができないようにし、また無限にズームインやズームアウトできないようにした方がいいです。ソースコードを確認すると、SceneViewの CameraManipulator パラメーターはデフォルトで設定されていることになっています。 open class SceneView @JvmOverloads constructor ( // ... /** * Helper that enables camera interaction similar to sketchfab or Google Maps. * * Needs to be a callable function because it can be reinitialized in case of viewport change * or camera node manual position changed. * * The first onTouch event will make the first manipulator build. So you can change the camera * position before any user gesture. * * Clients notify the camera manipulator of various mouse or touch events, then periodically * call its getLookAt() method so that they can adjust their camera(s). Three modes are * supported: ORBIT, MAP, and FREE_FLIGHT. To construct a manipulator instance, the desired mode * is passed into the create method. */ cameraManipulator: CameraGestureDetector.CameraManipulator? = createDefaultCameraManipulator(sharedCameraNode?.worldPosition), // ... ) : SurfaceView(context, attrs, defStyleAttr, defStyleRes) https://github.com/SceneView/sceneview-android/blob/2969a2c5ef00e5e5a0bccb29053e33fd93fcc47d/sceneview/src/main/java/io/github/sceneview/SceneView.kt#L184-L199 望む結果を達成するには、それを削除する必要があります。しかし、ソースコードを編集できないため、SceneViewを継承した新しいクラスを作成し、 cameraManipulator のパラメーターを null に設定する必要があります。 class CustomSceneView @JvmOverloads constructor ( context: Context, attrs: AttributeSet? = null , defStyleAttr: Int = 0 , defStyleRes: Int = 0 ) : SceneView( context, attrs, defStyleAttr, defStyleRes, cameraManipulator = null // <--- ここ ) ただし、 cameraManipulator を null に設定すると、ユーザーのすべてのジェスチャーが削除されてしまいます。ということは、自分のジェスチャーを開発するしかありません。 ジェスチャー SceneView には、カスタムジェスチャーを実装するために setOnGestureListener() があります。 fun setOnGestureListener( onDown: (e: MotionEvent, node: Node?) -> Unit = { _, _ -> }, onShowPress: (e: MotionEvent, node: Node?) -> Unit = { _, _ -> }, onSingleTapUp: (e: MotionEvent, node: Node?) -> Unit = { _, _ -> }, onScroll: (e1: MotionEvent?, e2: MotionEvent, node: Node?, distance: Float2) -> Unit = { _, _, _, _ -> }, onLongPress: (e: MotionEvent, node: Node?) -> Unit = { _, _ -> }, onFling: (e1: MotionEvent?, e2: MotionEvent, node: Node?, velocity: Float2) -> Unit = { _, _, _, _ -> }, onSingleTapConfirmed: (e: MotionEvent, node: Node?) -> Unit = { _, _ -> }, onDoubleTap: (e: MotionEvent, node: Node?) -> Unit = { _, _ -> }, onDoubleTapEvent: (e: MotionEvent, node: Node?) -> Unit = { _, _ -> }, onContextClick: (e: MotionEvent, node: Node?) -> Unit = { _, _ -> }, onMoveBegin: (detector: MoveGestureDetector, e: MotionEvent, node: Node?) -> Unit = { _, _, _ -> }, onMove: (detector: MoveGestureDetector, e: MotionEvent, node: Node?) -> Unit = { _, _, _ -> }, onMoveEnd: (detector: MoveGestureDetector, e: MotionEvent, node: Node?) -> Unit = { _, _, _ -> }, onRotateBegin: (detector: RotateGestureDetector, e: MotionEvent, node: Node?) -> Unit = { _, _, _ -> }, onRotate: (detector: RotateGestureDetector, e: MotionEvent, node: Node?) -> Unit = { _, _, _ -> }, onRotateEnd: (detector: RotateGestureDetector, e: MotionEvent, node: Node?) -> Unit = { _, _, _ -> }, onScaleBegin: (detector: ScaleGestureDetector, e: MotionEvent, node: Node?) -> Unit = { _, _, _ -> }, onScale: (detector: ScaleGestureDetector, e: MotionEvent, node: Node?) -> Unit = { _, _, _ -> }, onScaleEnd: (detector: ScaleGestureDetector, e: MotionEvent, node: Node?) -> Unit = { _, _, _ -> } ) https://github.com/SceneView/sceneview-android/blob/2969a2c5ef00e5e5a0bccb29053e33fd93fcc47d/sceneview/src/main/java/io/github/sceneview/SceneView.kt#L819-L839 イベントがたくさんありますが、半天球カメラの場合は以下の実装しか必要がありませんでした。 onMove → ドラッグ操作の時カメラを回転するために onScale → 最小・最大ズームのために onSingleTapConfirmed → プレイヤーのコントロールボタンを表示・非表示するために onDoubleTap → ダブルタップ位置へセンタリングするために 最小・最大ズームの距離計算 ズームイン/アウトの動きは基本的にカメラが軸に沿って移動することで実現されます。最大ズームの時には、カメラの位置を(0, 0)に設定し、最小ズーム（最大ズームアウト）の場合はカメラの移動範囲をモデルの外側が映らないように制限したいです。 最大ズームは大きな問題ではありませんでした。なぜなら、カメラの位置(x, y)が 0 より下に行かないように制限すれば上手くいきました。しかし、最小ズームの場合は、カメラが到達できる最遠のポイントを決める必要があります。これは球体の半径とカメラの FOV の設定を元に算出できます。 tan(FOV / 2) = r / d → d = r / tan(FOV / 2) 動画再生領域が縦長の場合に、最小ズーム状態で左右が見切れてしまいました。そのため、画面のアスペクト比を考慮する必要がありました。 // 球の半径を設定する private val aspectRatio: Float get () { val cameraViewAspectRatio = width.toFloat() / height.toFloat() return if (cameraViewAspectRatio >= 1f ) { // 横長の画面の場合は単位球の半径 1 をそのまま利用する 1f // 球体は半径を1にしておくと計算が楽 } else { // 縦長の画面の場合は、 FOV が vertical な設定の関係から、半径相当のサイズをアスペクト比を利用して変換する 1f / cameraViewAspectRatio } } // z 軸上のカメラと半球面モデルの最大距離 private val maxDistance: Float get () = aspectRatio / tan(Math.toRadians(FOV / 2f )).toFloat() 結果を見てみましょう！ 横長 縦長 ズームできました〜🥳 回転と移動 Androidでは、 GestureDetector を使うと、ユーザーが画面にタッチした位置の(x, y)座標を取得できます。デフォルトでは、原点 (0, 0) はビューの左上隅にあります。 ユーザーがドラッグしている方向を特定するには、2つのポイント間のVectorを計算する必要があります： AB(x2-x1, y2-y1) の公式を使うと、ユーザーがスワイプした方向を特定することができます。 fun drag(from: Pair < Float , Float >, to: Pair < Float , Float >) { val previousPointX = from.first val previousPointY = from.second val currentPointX = to.first val currentPointY = to.second val dx = currentPointX - previousPointX val dy = currentPointY - previousPointY when (cameraControlMode) { CameraControlMode.CEILING -> { // カメラを回転する } CameraControlMode.WALL -> { // カメラを回転する } } } また、カメラの回転角度が制限内に収まるように調整しないといけないです。 球体の半径（r）と現在の距離（d）を元に最大回転角（α）を算出できます。 α = atan2(r, d) しかし、カメラの回転は画面中心を基準に行われるため、 FOV に応じた調整が必要です。 α = atan2(r, d) - (FOV / 2) /** * カメラの回転角度が制限内に収まるように調整を行う * * @param x x軸中心での回転角度 (deg) * @param y y軸中心での回転角度 (deg) * @return Pair<調整後の x 軸中心での回転角度 (deg), 調整後の y 軸中心での回転角度 (deg)> */ private fun adjustCameraNodeRotation(x: Float , y: Float ): Pair < Float , Float > { // 距離と球体の半径を元に最大回転角を算出 val rotationLimit = atan2( 1f , actualDistance) val rotationLimitDegree = Math.toDegrees(rotationLimit.toDouble()) // 球体外の写像を避けるために、 FOV を元に回転角をさらに制限 val xRotationLimit = if (rotationLimitDegree > (FOV / 2f )) { (rotationLimitDegree - (FOV / 2f )).toFloat() } else { 0f } when (cameraControlMode) { CameraControlMode.CEILING -> { // x 軸の縦回転は -90 deg から 0 deg の範囲となる val xAxisRotation = x.coerceIn(X_AXIS_ROTATION_LIMIT, X_AXIS_ROTATION_LIMIT + xRotationLimit) return Pair (xAxisRotation, y) } CameraControlMode.WALL -> { // FOV は縦方向を基準としているため、 y 軸方向の横回転はアスペクト比を元に変換した FOV 値を算出する val aspectRatio = width.toFloat() / height.toFloat() val hFOVHalf = Math.toDegrees(atan2(aspectRatio * tan(Math.toRadians(FOV / 2f )), 1.0 )).toFloat() val yRotationLimit = if (rotationLimitDegree > hFOVHalf) { (rotationLimitDegree - hFOVHalf).toFloat() } else { 0f } val xAxisRotation = x.coerceIn( - xRotationLimit..xRotationLimit) val yAxisRotation = y.coerceIn( - yRotationLimit..yRotationLimit) return Pair (xAxisRotation, yAxisRotation) } } } 横向き 下向き これもいい感じですね！🥳 タップ位置へセンタリング Safie Viewerでは、3Dモデルをダブルタップするとダブルタップした位置へセンタリングするという機能があります。3Dモデルの外側だと、普通に真ん中に最大ズームします。 それを実現するために、SceneViewの CollisionSystem を使用することで、ユーザーが3Dモデルをタップした位置を検知します。 setOnGestureListener( onDoubleTap = { motionEvent, _ -> val hitTest = collisionSystem.hitTest(motionEvent).firstOrNull { it.node == modelNode } if (hitTest != null ) { // 3DモデルのhitTest.pointの(x, y)をTapした! } else { // 3Dモデル外部をタップした } }, ) 横向き 下向き ただ、SceneViewのCollision Systemは四角いボックスとして機能されています。そのため、3Dモデルが四角形でない場合でも外側をクリックしてもタップイベントはモデルに当たることになります。 github.com 3Dモデルは半球形なので、外側にいる場合でも3Dモデルでタッチイベントがトリガーされてしまいました。 この問題を修正するために、3Dモデルの前に平面を配置しました。そして、ユーザーのタッチイベントのx座標とy座標に基づいて、それが3Dモデルの内側か外側かを知ることができます。 タップイベントは点が円内にあるかを確認するには、円の中心が位置 (0, 0) にあると仮定して、次の式を適用する必要があります： x² + y² ≤ d /** * 3Dモデルの外側をタップしているかどうか * @param x タップしたx座標 * @param y タップしたy座標 */ private fun isOutside3dModel(x: Float , y: Float ): Boolean { // 3Dモデルの外側をタップしている場合、nullにならない val outsideModelTouchPlaneHitTest = collisionSystem.hitTest(x, y) .firstOrNull { it.node == outsideModelTouchPlaneNode } ?: return false // ヒットテストの座標 (x, y) が半径 1 以内にある場合、3Dモデルのタップしている val isTouchInside = outsideModelTouchPlaneHitTest.point?.let { it.x.pow( 2 ) + it.y.pow( 2 ) <= 1 } ?: false return ! isTouchInside } Before After まとめ 半天球カメラの動画再生を表示する機能を開発するのは大きなチャレンジですが、たくさん勉強になりました。カスタムジェスチャーの開発は簡単ではなく、三角関数の知識が多く必要でした。しかし、SceneViewを使用すると、衝突システムなどの多くの便利な機能が提供され、希望するものを開発するのが楽になります。今回実装してみた結果もとても良く、スムーズです！ この記事を最後まで読んでいただきありがとうございます。 また、この機能の開発に多大な協力をしてくれた同僚に本当に感謝しています。 このような面白い機能を一緒に開発したい方は、ぜひ以下のリンクをご確認ください！ open.talentio.com open.talentio.com

この記事は Safie Engineers' Blog! Advent Calendar 12日目の記事です こんにちは、セーフィー株式会社でフロントエンドエンジニアをしている佐川です。 3Dプリンターでなんらかの入力デバイスや小物をつくることが趣味で、同好の士が増えることを願いながら部内のLTや深堀り会などで作ったものの話などをしています。 今回はその中で話していたことのひとつ、キーボードを作る話を書きたいと思います。実業務とは関係がなく、本当に趣味の話です。 3Dプリンターとはんだごてがあると、作れるものの幅が広がって楽しい パラメトリックモデリングによる3Dモデリングの容易さ あたりについて書いていきます。各工程について詳しくは記載していないため、もし気になったら調べてみてください。 キーボードを自作したい！ キーボードを自作する 作りたいキーボードを考える パラメトリックモデリングによるケースのモデリング ファームウェアを書く 組み立てる＆手配線 かかった金額 最後に キーボードを自作したい！ ここ数年でキーボードを自作する行為はだいぶメジャーになってきた印象があります。 2025年3月に行われる キーボードマーケットトーキョー という自作キーボードをメインに扱う即売会では、協賛企業も含めると70を超えるブースが出展するのだとか…。世は大自作入力デバイス時代ですね。 自作キーボードは市販品とは異なり、採算度外視の自由さが魅力です。 游舎工房のWEBショップ を少し覗くだけで、あまりのバリエーションと各制作者の発想力にただただ震えます。最近だと、キーボードにトラックボールがくっついているのを見たときの衝撃たるや…。 さて、自作キーボードと言っても自作の方法には2種類あります。 売られているキットを買ってきて組み立てる 0から作る プリント基板を発注する 手配線 大体の自作キットは基板、外装（＋ファームウェアを焼いたマイコン）がセットになっており、あとは必要な電子部品と好きなキースイッチ・キーキャップを用意すれば、プラモデルをぱちぱち組み立てていく感じでキーボードを作ることができます。 ただ、こんな自由度高く様々存在している自作キットといえど、100％自分が求めている要件を満たすものがあるとは限りません。当時、自分が求めている自作キットは存在していませんでした。ロープロファイルのキースイッチが使えて、格子配列の40％キーボードが欲しいだけなのに…。 妥協したものを買うのもなあ…と思ってキーボードの自作方法を見ていると、基本は電子回路を設計して外部にプリント基板を発注する方法がメジャーなようでした。 プリント基板は海外の制作会社に発注するとおよそ2000円～で作ってもらうことができますが、発注してから届くまでにある程度時間がかかります。（別料金を払えば翌日には出荷してもらえます） まずは作って、気に入らないところがあったら修正して…のサイクルを回したい自分としては、時間とお金が気になります。 また、発注時の最低ロット数は大体5枚なので、個人用に作りたいだけなのに4枚も余らせてしまうのはなんだか微妙という気持ちもありました。 もう少し調べてみると、3Dプリンターで印刷した外装にキースイッチをはめ込み、それらを手で配線していく方法で作っているものを見つけました。 なるほど、それなら100％自分好みに作れますし、ちょっと気に入らないところが出たらすぐに直して印刷してしまえばよいです。無限の可能性を感じます。 ScottoLong Handwired Keyboard 余談ですが、こちらは手配線にこだわるとここまで美しくできるのかと非常に感銘を受けたものです。 キーボードを自作する キーボードを作るにあたってやるべきことは、大まかにこれくらいでしょうか。 作りたいキーボードを考える ケースをモデリングする (回路図を書く) ProMicroやラズパイのようなマイコンボードを使う場合は単純なのであまり書きません マイコンボードに頼らないときは、マイコン、USBコネクタ、リセット・BOOTスイッチ、水晶発振器…などなど、登場人物が多いので書きます ファームウェアを書く フルスクラッチ QMK というキーボードファームウェアのベース 組み立てる＆手配線 作りたいキーボードを考える 上のほうでも書きましたが、こんなキーボードが欲しいなと考えました。 キー数40％ ロープロファイルスイッチ 格子配列 できるだけ本体を薄くしたい キーボードを作る前は、 hsgw氏のPlaid を使っていました。必要な電子部品たちが装飾も兼ねてきれいに配置されており、とても気に入っているキーボードです。こちらを使い始めてからは完全に格子配列に馴染んでしまい、他の配列に戻れなくなってしまいました…。 パラメトリックモデリングによるケースのモデリング 作りたいキーボード案をもとに簡単にラフを書いたあと、早速3DCADソフトを用いてモデリングしていきます。 ところで、自分は3DCAD、3DCGソフトを扱うのが不得意です。GUI上には膨大な数のアイコンやメニューが列挙されており、自分のやりたいことをスムーズに行うには、ソフトごとでの習熟が求められます。 自分の頭の中では「この平面に穴を等間隔で開けたい」「15mmの壁を足したい」など明確なのですが、それを行うための操作手順が煩雑で、作業に対するストレスがグングン溜まっていきます。 そんなとき、 OpenSCAD というコードベースでモデリングできるソフトウェアを見つけました。 実業務でも趣味でもコードを書いているため、こちらのアプローチにすんなり馴染むことができました。 たとえば「四隅に穴の空いたプレート」を作りたいと思ったら、以下のように書くことができます。 width = 10; length = 20; height = 1; difference() { cube([width, length, height], center=true); for (xpos = [-1, 1], ypos = [-1, 1]) { translate([xpos * (width / 2 - 1), ypos * (length / 2 - 1), 0]) cylinder(h=height, r=.5, center=true); } } 書きっぱなしで読みづらい状態ですが、参考までにキーボードをモデリングした際のコードを以下に置いておきます。 github.com ファームウェアを書く オープンソースで公開されているものがいくつかあり、そちらを用いることで簡単に自作キーボードのファームウェアを作成することができます。 有名なものは以下の2つかなと思います。詳しくはドキュメントなどをご参照ください。 QMK 一番有名なファームウェア Vial QMKベースで、WEBブラウザ上でのキーマップ変更機能を有していて便利 余談ですが、組み込み系の知識が乏しかったので、以下の動画を面白く見てました。 自作キーボードって組込みRustの入門にちょうどいいらしい #ch789 組み立てる＆手配線 一気に端折ってしまいますが、モデリングしたケースをSTLファイルに変換して3Dプリンターで印刷するとこんな感じになります。（ネジ止め用のインサートナットを圧入済み…） ケースにキースイッチをパチパチはめて、キースイッチとダイオードを銅線で配線し… マイコンボード（今回は家に転がっていたRaspberry Pi Pico）とキースイッチを配線。 キーキャップはめて完成！ （キーキャップの文字やアイコンは、テプラのマット透明テープに印字して貼っています。お手軽） かかった金額 部品名 金額（およそ） ダイオード38個 100円 Kailhロープロファイルスイッチ 38個 2600円 Raspberry Pi Pico 800円 キーキャップ 37個 1200円 3Dプリンタのフィラメントや、はんだとか、こまごま 500円 合計 4000円 …かかった時間を考えるとすごく安い！というわけでもないですが、キースイッチやマイコンなどのパーツは使い回せるので、作り直すときはより安価に作ることができますね。 最後に 後半はかなりふっ飛ばしてしまいましたが、3Dプリンターと手配線でキーボードを自作する話でした。 今後ですが、キースイッチを使いまわしたいときにキースイッチの足に直接はんだ付けしている場合、一度はんだを取り除く作業が必要になり非常に面倒くさいです。 なので付け外しが容易になるソケット（Kailh製やベリリウム銅のものなど）を用いてキースイッチのつけ外しが楽なように作りたいなあ…と考えています。 あとはロータリーエンコーダーをつけたり、一体型だけれど左右分離型のような配置のキーボードとか作りたいですね…。 最後までお読みいただきありがとうございました。年末年始のおともにキーボード作り、いかがでしょうか。

この記事は Safie Engineers' Blog! Advent Calendar 11日目の記事です はじめに みなさんこんにちは。法務部知財グループの永島です。 セーフィーでは様々な社内研修を行っていますが、今回は知財研修にスポットをあててお話したいと思います。 はじめに 知財研修ってなに？ セーフィーの知財研修 入社時の知財研修 希望者は誰でも受講できる任意知財研修 知財研修への想い 知財研修を始めたきっかけは？ 入社時の必須研修に知財研修（基礎編）を入れた理由は？ 知財研修の対象者を開発や企画だけでなく全社員とした理由は？ 知財レビュー（半年に１回）を始めたきっかけは？ 経営層への知財レビューを対面で実施している理由は？ 最後に、知財研修への想いを教えてください。 おわりに 知財研修ってなに？ 知財研修はその名の通り、知的財産に関する研修となります。 一般的な知財研修では一例として以下のようなことを目的として行われることが多いです。 知的財産の理解促進 知的財産（特許、意匠、商標、著作権など）の基礎知識を学び、企業にとっての重要性を理解する。 法的リスクの回避 知財侵害を未然に防ぎ、他社の権利を侵害しないようにする。 知的財産の実務概要理解 出願、中間対応、調査、契約などの知財実務の概要を理解する。 うわー、なんだか難しそう、聞いているうちに眠くなっちゃいそう・・・って内容ですよね。 セーフィーの知財研修 セーフィーの知財研修は「知財をみんなで楽しもう！」をモットーにしています。 楽しみながらも、一般的な知財研修では得られにくい「実情に沿った考え方」と「ネタに気付くカン」を磨くことに重点を置いています。 知財研修を楽しんでもらうための私たちの３つのこだわりを紹介させてください。 その1：わかりやすい資料作り より楽しく受けてもらえるよう、イラストや図表を多用した工夫を凝らした資料作りに取り組んでいます！ その２：極力専門用語は使わない 研修を気軽に受けてもらえるよう、専門用語の使用を極力控え、必要な場合はわかりやすい例えを交えて解説するよう心がけています！ その3：受講者参加型 研修は基本的にWebで実施しており、研修途中にGoogle Meetの機能を活用したアンケートや、ワーク、ティーブレイクを取り入れることで、受講者がただ聞くだけで終わらない工夫をしています！ ティーブレイクの雑談についてどのテーマの話が聞きたいかアンケートを取っている様子⇒⑨ラテアートはじめましたが一番人気でした(笑) セーフィーの研修の種類はいくつかあるのですが、そのうち、知財研修は「入社時の研修」と「希望者は誰でも受講できる研修」の２つがあります。 次はそれぞれの知財研修の内容についてお話します。 入社時の知財研修 セーフィーでは入社時の研修がとても充実しています！詳しくはこちらの記事でご紹介しています。 note.com 知財研修も入社時必須の研修となっているのですが、どんな内容かチラ見せ。 入社時の知財研修では主に以下のような内容を学びます。 知的財産権を取得する目的 特許、意匠、商標の基礎的な知識 セーフィーで取得した特許権、意匠権、商標権の紹介 入社時の研修では、一般的な知財研修に近い内容を扱いつつ、「知財は事業を守り発展させるために、開発や企画部門だけでなく全員が関わるべき重要なテーマである」というメッセージをしっかりと伝えています。 希望者は誰でも受講できる任意知財研修 任意知財研修は上期2回、下期2回の１年間計4回行います。今まで10回の任意知財研修が開催されています。 テーマ1：基礎編 テーマ2：特許編①特許文献の読み方 テーマ3：特許編②発明の捉え方／良い発明の条件 テーマ4：商標編 テーマ5：Safie知財の現状＆今後 テーマ6：契約交渉編 テーマ7：2023知財レビュー／Safieの知財方針 テーマ8：著作権編 テーマ9：2024上期知財レビュー テーマ10：特許調査編 この研修は希望者のみの任意参加としていますが、セーフィーでは毎回リアルタイムで約100名の社員が参加しています。アーカイブ配信も行っている中でのこの参加人数は、セーフィーの社員数461名（2024年7月時点）の約4分の1に相当します。セーフィー社員の知的財産に対する関心の高さがうかがえますね！ この中で異彩を放っているものといえば「知財レビュー」ですよね。 知財レビューは、上期・下期ごとに出願および登録されたセーフィーの知的財産権の内容を共有する研修です。経営層に関しては別途時間を設けて必須で実施しています。 任意研修のそれぞれの内容については別の回でじっくりお話させてもらえればと思います。 知財研修への想い ここからは、セーフィーで知財研修をやり始めた当事者である、知財グループGLの渡辺さんに、知財研修への想いを質問形式で聞いてみたいと思います。渡辺さんは、2022年1月に知財担当の1人目としてセーフィーに入社して以来、知財部門の立ち上げから知財の責任者として務めています。 知財研修を始めたきっかけは？ (渡辺)　私が入社した当初、知財に対して理解のある人がほとんどいなかったからです。 知財活動を本格化していくには、周りの協力を得たり、予算を適切に獲得する必要が出てきます。そうなった時、後々苦労するだろうなというのが目に見えていたため、これは早い段階でテコ入れせねばと思いました。 入社時の必須研修に知財研修（基礎編）を入れた理由は？ (渡辺)　基本的な知財リテラシーについては、常に全社員が身に着けている状態にしておきたいからです。 セーフィーは、毎月のように中途社員が入ってきて社員数が増え続けていますので・・・早い段階で確実に聞いてもらえる機会として、入社時の必須研修に目を付けました。 その副産物として、会社として知財を重要視している点はもちろん、知財部門の存在や知財担当の顔についても、初めから知ってもらえるという効果がありました。 知財研修の対象者を開発や企画だけでなく全社員とした理由は？ (渡辺)　近年、知財が影響を及ぼす範囲が広がってきているからです。具体的には、従来から重要である「他社にマネされないようにする」だけでなく、近年は「お客様への訴求力を高める」「会社のイメージを上げる」「社員の士気を高める」「経営に新たな視点を与える」等。その様な時代に対応するため、というのが当初の理由でしたが、やっていく中で思わぬ部門に知財のファンが増えたりするのも、楽しみの１つだったりします。 知財レビュー（半年に１回）を始めたきっかけは？ (渡辺)　もっと知財を身近なものとして、当事者意識を持ってもらいたかったからです。知財レビューでは、実際に出願／登録になった件の事例紹介にも力を入れています。 特にセーフィーのようにSaaS系の技術分野では、当事者も「新しいものを生み出している」という自覚が少ない傾向にあるため、知財を通してそれを見える化し、社員の士気を少しでも上げられたらと思っています。 経営層への知財レビューを対面で実施している理由は？ (渡辺)　お忙しくてなかなか聞いてもらえないからです（笑）それに、対面ならディスカッションもできて様々な要望を拾うことができ、今後の知財の方針に生かせます。 最近では、全社向けの研修でやったクイズの結果を従業員の意識調査として、経営層にフィードバックすることもあります。この前、知財から距離が遠い筈のCCOや監査役から「実は毎回楽しみにしている」という声を聞いた時は、とても嬉しかったです。 最後に、知財研修への想いを教えてください。 (渡辺)　とにかく、まずは知財を楽しんでもらえたらと。いいアイデアって、あれこれ楽しく考える中でたくさん生まれてくるものだと、今までの経験から感じてましたので。 知財に限らず、専門職の世界って素人には中々理解し難いですが、今後も工夫を凝らしていきますので、是非ご期待ください。 おわりに 「知的財産」って聞くと、なんだか専門的で難しそう…と思う人が多いと思います。私たち知財グループは知財研修で少しでもその垣根を取り除くことができればと考えています。 知的財産って、特別なスキルを持った人だけのものじゃなくて、社員全員がちょっとずつ関わることで、もっと強力な武器になります。部署の垣根を越えて学び合えば、きっとお互いに刺激を受けていいアイデアがどんどん生まれるはずです。 私たちはこれからも「知財をみんなで楽しもう！」をモットーにセーフィー独自の知財研修を実施していきます！ セーフィーではエンジニアを積極的に採用しています。 興味がある方は是非下記サイトを一度覗いてみてください。 エンジニア職 | セーフィー採用サイト