この記事は Safie Engineers' Blog! Advent Calendar  14日目の記事です はじめに はじめまして！エンジニアリングオフィスの山崎麻衣子（ @ymzaki_m4 ）と申します。 セーフィーには2025年3月に入社し、開発本部の組織開発全般に携わっています。 （エンジニアリングオフィスのお仕事については、昨年の記事も良ければご覧ください！） engineers.safie.link 今回は、私がこれまで取り組んだ 「組織の横連携強化」 に関する施策についてご紹介します。 組織の拡大によって生じ始めた課題と、その解消に向けた最初の一歩。組織マネジメントで同じような悩みを抱える方の、何かちょっとしたきっかけになれば幸いです。 はじめに 強力な組織の実現へ：課題を探る 本質的な課題を特定：浮き彫りになった2つの壁 「横のつながり」を生む：GL横断ミーティングの実行と設計 組織変革の第一歩と、次の目標 おわりに 強力な組織の実現へ：課題を探る 開発本部の今年度（FY25）の目標の1つとして、 「強力な組織」の実現 が掲げられていました。 セーフィーのさらなる事業成長を促進するためには、将来の成長を実現しうる仕込みや組織体制の整備を進める必要がありました。 そのためには、現状の成長速度に満足せず、組織文化の醸成、個人の成長支援、情報連携強化など、多面的な成長を強力に推し進めることが重要となります。 こうした状況下で入社した私がはじめに取り組んだことは、開発本部の部室長、グループリーダー（GL）との1on1で、 組織の現状を多角的に把握 することでした。 約3週間かけて計25名の部室長やGLに対してヒアリングを実施しました。 現在の組織の取り組みや課題などについて、採用、オンボーディング、育成、評価、文化醸成、開発プロセスなどの幅広い切り口でお伺いしました。 業務の合間を縫って快く応じてくださり、みなさんが抱いている想いや組織の現状を把握することができました。（ありがとうございました！） 本質的な課題を特定：浮き彫りになった2つの壁 ヒアリング内容は 構造化・抽象化 し、開発本部全体の本質的な課題を特定しました。 これらの課題を基に、解決のための道筋を考え、直近で実施すべき具体的な施策を策定しました。 まず、組織として課題感が大きいものを以下の4つのテーマに分類しました。 組織運営の基盤強化 人材育成・成長の仕組み化 業務効率と生産性向上 組織文化と帰属意識の醸成 さらに、短期・中長期に分類し、課題の関連性と施策の優先順位を探っていきました。 その結果、直近で取り組むべき課題が以下の2つであると特定するに至りました。 組織の明確な方向性・ビジョンが不足している 役割や権限が不明確で、横のつながりが薄い これらの2つの課題を解決していくにあたり、まずは「既存のリソースを活用してすぐに実施可能で、直接的に効果が見込めるもの」に取り組み、着実に成果へとつなげていきます。一方で、「根本的解決に時間を要し、新たな仕組みや文化の醸成が必要なもの」についてはバックキャスティングで計画を策定し、この両輪で課題解決を推進します。 そこで、まず着手したのが 「GLの横連携強化」 でした。 GLという組織の中核を担う存在が積極的に連携することで、組織の一体感を醸成し、グループを超えて成果や付加価値を創出し続けられる組織を目指したいと考えました。 また、GLの半数以上から共通課題として挙げられたのが「GL役割と権限の定義の曖昧さ」や「部門・チーム間の情報共有と連携の弱さ」であり、これらが組織の方向性の不明確さや横のつながりの希薄さにつながっているとも考えられました。 この短期的な基盤強化が、長期的な成長のための「土台」を固める上で必要だったのです。 開発本部FY25下期キックオフ（2025年7月開催）での説明資料より（一部改変） 「横のつながり」を生む：GL横断ミーティングの実行と設計 「GLの横連携強化」を進めるために、 「GL横断ミーティング」 の定期開催を企画しました。 この会議は「組織の中核を担うGLが、自身のチームを超えて組織全体を理解し、相互に協力しながら、より良い組織を共に創っていくための、 主体的な場 」と定義し、GLの中で有志を募って始めることとしました。 企画の検討にあたって特に意識した点は以下の4点です。 一方的な情報提供ではなく、双方向の対話やワークを中心とした設計にする 毎月の開発本部会で実施内容を全体共有することで、活動の透明性を高める 各回でテーマを明確に定め、明日からの活動につながるアウトプットを意識する アウトプットや実施後アンケートを踏まえ、会議自体の改善を繰り返す また、目指す状態とそのためのステップを意識しながら、段階的なロードマップを設定しました。 会議は8月から開始し、月1回以上の頻度で継続的に開催しました。 はじめは「相互理解と安心できる場の醸成」をテーマに、参加者同士の交流を重視しました。回を重ねるごとに「実践と改善のサイクル」を重視し、具体的な現場の課題解決のための議論や、マネジメントスキル向上を意識した学習を取り入れ、組織への貢献を視野に入れていきました。 11月末までで全6回開催しましたが、当初からGLのみなさんが意欲的に参加してくださり、会議への満足度が高い状態が維持できています。（ありがとうございます！！） また、要望も踏まえて会議の運営やコンテンツを調整することで、マネジメントスキル向上などへの貢献度も高められていることをアンケート結果を通じて感じることができました。 組織変革の第一歩と、次の目標 「GL横断ミーティング」は、GL同士が 部門やチームを超えて課題を共有し支え合う ための「横のつながり」を強化し、 ラインマネジメント能力の向上 という成果も出始めていると感じています。 今後はさらに、長期施策として 「組織ビジョンの策定と言語化」 を進めたいと考えています。 「実行力と創造力を兼ね備え、事業成長に必要な変化に迅速に対応できる組織」を目指し、その想いを言語化して社内外に示すことで、想いに共感したメンバーが集まる「異才一体」な強い組織となり、さらなる事業成長に貢献できるように取り組んでいきます！ また、これまでの取り組みを通じて、セーフィーは 自ら考え、判断し、行動することで、自律的に価値を創造する メンバーのスタンスを大切にしてくれると強く感じることができました。 これからも組織課題に真摯に向き合い、改善プロセスを継続的に推進していきます。 おわりに 本記事では、私が取り組んだ組織変革の第一歩についてご紹介しました。 まだ道半ばでやりたいことも数多くあるので、いつか別の機会にご紹介できればと思います。 ついでに宣伝です！セーフィーでは 一緒に働く仲間を募集中 です！ 少しでもご興味を持っていただけたら、ぜひ以下の採用サイトを覗いてみてください。 safie.co.jp 最後まで読んでいただき、ありがとうございました。

この記事は セーフィー株式会社 Advent Calendar 2025 の13日目の記事です！🎄 はじめに こんにちは！ セーフィー株式会社 基幹システム開発部 戦略グループの佐々木です。 約１年前、セーフィーの中途採用の選考を受けようとしていた私は途方に暮れていました・・・ なぜなら 「セーフィーの基幹システム開発部とはなにか」 についての情報が、募集要項以外にほぼ見つけられなかったからです。 過去の私と同じように「基幹システム開発部に興味はあるけど、情報が全然見当たらないな・・」とお困りのみなさんへ、セーフィーの基幹システム開発部についてご紹介したいと思います！ はじめに セーフィーにおける「基幹システム」 基幹システム開発部について 基幹システム開発部ってどんな雰囲気？ おわりに セーフィーにおける「基幹システム」 みなさんは「基幹システム」と聞いてどんなシステムを思い浮かべるでしょうか？ セーフィーにおいて、基幹システムは 「企業活動に必要不可欠な最小限の業務を取り扱うシステム」 と定義されています。 と言われても、ちょっとイメージがわきにくいですよね。 セーフィーは、クラウド録画サービスというSaaSビジネスを展開しつつ、カメラデバイスなどの「モノ（ハードウェア）」も取り扱っている点が特徴です。 そのため「企業活動に必要不可欠な最小限の業務」として、以下のような領域を定義しています。 「モノ」を管理する領域：SCM、サービス/製品保証管理 「サブスクリプション」を管理する領域：契約管理 「モノ」「サブスク」から請求を管理する領域：請求管理 営業活動を支える領域：SFA/CRM 企業活動の根幹を支える領域：会計管理、組織管理、データ分析/活用 では、これらの領域について、それぞれどのようなシステムを利用しているのでしょうか？ 利用システムを領域ごとにグルーピングすると以下のような形となります。 このように様々なシステムを組み合わせながら、日々の業務、ひいては顧客のセーフィー利用を支えているのが、セーフィーにおける「基幹システム」です。 基幹システムについては過去のテックブログでも紹介していますので、興味を持たれた方はぜひこちらもご覧ください。 「モノ」×「サブスク」業務システム紹介！ 基幹システム開発部について ここまでご紹介してきた基幹システムのうち、CRMシステム群、契約・請求・会計管理システム群を管理しているのが「基幹システム開発部」です。 （注：データ分析基盤はデータドリブン推進室が担当しており、そちらも過去記事で紹介されています。 What is データ分析基盤 ） 基幹システム開発部のMissionは 「持続可能で柔軟な基幹システムを提供し、企業の成長と経営効率化を支える」 であり、セーフィーのさらなる成長を支えるための基盤づくりに取り組んでいます。 基幹システム開発部は以下の3グループで構成されています。 開発第１グループ 開発第２グループ 戦略グループ それぞれのグループの役割は以下の通りです。 開発第１グループ 主にSalesforceに関する開発・保守を担当しています。 セーフィーではSalesforceを幅広い領域で活用しており、営業からカスタマーサポートまで、様々な部署の業務を支える大切な基盤となっています。 開発第１グループでは、社内の要望を元に開発・リリースを行っているほか、現在はSCM業務の改善を目的とした「山桜プロジェクト」（製品・在庫管理システムの強化）に内製で取り組んでおり、社内ユーザーであるCS本部のメンバーと密に連携しながら開発を進めています。 ユーザー部門と一体となってのプロジェクト運営は、セーフィーの基幹システム開発における大きな醍醐味のひとつです。 開発第２グループ 主にECサイトやZuora、請求書管理ロボに関する開発・保守を担当しています。 契約管理・請求管理という顧客影響が大きいシステムも担当しており、日々のデータの整合性確認、月次決済の確認といった重要な業務も多く担当しています。 ベトナム子会社の業務システム開発やECサイトの保守など、幅広い領域のプロジェクトを担当する開発第２グループですが、2026年からは会計領域へのSAP導入を行う「欅プロジェクト」も本格スタートし、セーフィーの成長を支えるための大きなプロジェクトが今後数年続く見込みです。 戦略グループ 主に基幹システム全体の戦略企画や、開発プロジェクトにおけるプロジェクトマネージャー（PM）としての役割を担当しています。 前述の山桜プロジェクト・欅プロジェクトのPMや、子会社の業務システム構築プロジェクトのPM、代理店向け自社開発システムのプロダクトマネージャー（PdM）といった形で、各メンバーがそれぞれのプロジェクトの推進役を担っており、部門横断的な課題の解決をリードしています。 基幹システム開発部ってどんな雰囲気？ 私が入社後すぐに感じたのは、「落ち着いたおだやかな人が多い」雰囲気でした。 一方で、システムに関する議論ではそれぞれのバックグラウンドを基に様々な意見が飛び交い、よりよい基幹システム構築に向けた熱い思いを日々感じています。 また、育児中のメンバーも多く、裁量労働制をいかして柔軟に子育てと両立しているメンバーも多いです。 プロジェクト単位での活動が多い基幹システム開発部ですが、隔週で開催されている「基幹システム開発部会」では、全員が一言話す「チェックイン」が冒頭に設けられており、「子供の時の夏休みの思い出」「老後の夢、生き方」「便利なフリーソフト」など多岐にわたるテーマを元にお互いの人となりを知る良い機会となっています。 ボルダリング部に参加しているメンバーの報告や、お子さんとのトカゲの飼育エピソード、育休明けのパパメンバーと赤ちゃんの登場など、「異才一体」のセーフィーらしく、いろいろなジャンルのエピソードが飛び出す笑いが絶えない時間で、私も毎回とても楽しみにしています。 おわりに 基幹システム開発部についてのご紹介はいかがでしたでしょうか？ この記事を読んだ皆さんの基幹システム開発部への解像度が少しでも上がっていたらうれしいです。 セーフィーのさらなる成長を支えるため、基幹システムは今まさに進化の時を迎えています・・・！ さらなる成長を見据える 今のセーフィー「だからこそ」味わえるダイナミックな基幹システム再構築 に、あなたも一緒に取り組んでみませんか？ 基幹システム開発部では、一緒に働いていただける仲間を絶賛募集中です！ 興味を持っていただけた方は、ぜひ採用サイトもご覧ください。 safie.co.jp

この記事は Safie Engineers' Blog! Advent Calendar 12日目の記事です。 はじめに そのテストコード、まだ全部「手」で書いていますか？ 今はどんな生成AIを使っているのか？ なぜ「全自動」ではないのか？ 実践！Claude Codeを使ったテスト半自動化4ステップ このワークフローがもたらした、時間以上の「価値」 おわりに：AIとの協業が当たり前になる未来へ はじめに こんにちは！セーフィー株式会社でサーバーサイドエンジニアをしている坂上( @Bobtaroh )です。新卒2年目となり、私を含め同期のエンジニアたちも、それぞれの配属先で一生懸命に業務をこなしています。 本記事では、同じく新卒2年目であるフロントエンド開発を担当している東條さんにインタビューを行い、開発現場で話題の「Claude Code」を活用した テスト半自動化のワークフロー について紹介します。 「AIに全部任せる」のではなく、あえて「半自動化」を選ぶその理由と、具体的な実践手法について深掘りしました。 そのテストコード、まだ全部「手」で書いていますか？ テストコードは、アプリケーションの品質担保に不可欠ですが、その実装は時としてエンジニアの負担になることもあります。セーフィーのフロント開発チームでは、特に以下の課題がありました。 大規模なデザインシステム移行をやっていて、工数見積もり上、テストを後回しにしていた テストを実装する箇所多かった 配属されてから開発したコンポーネントが40~50ほどあり、1コンポーネントあたり1000行ほどのテストが必要だった テストの中には、作業に近い単純な実装が多く存在し、エンジニアのモチベーションがあまり上がりづらい側面も少々あった これらの課題を抱えていた時に、世間ではCoding Agentが注目を集め始め、弊社でも社内ツールとしてGeminiやClaude Codeの利用環境が整備されました。それを機に、今回のテストの半自動化ワークフローを組むことに至ったとのことでした。 今はどんな生成AIを使っているのか？ 昨今、Claude Code以外のさまざまな生成AIが登場していますが、以下の4つの生成AIに関して、どのように使い分けているのか、東條さんに聞いてみました。 Gemini 相棒的な存在 Gemini単体でタスクをお願いすることはなく、調べるためのツールとして使うことが多い 会議中に出てきた分からないことについても聞くことがよくある Claude Code 部下に近い存在 以下の仕事を投げている テストの実装 新規開発の雛形作成 複雑な実装の解説依頼 Github Copilot 以前使っていたが、今は完全に使用していない Bedrock Chat Geminiが導入される前までは主流だったが、今は使用していない 2025年12月現在では、主にGeminiとClaude Codeを使用しているとのことでした。 なぜ「全自動」ではないのか？ 現在のテスト半自動化に至るまでには様々な試行錯誤がありました。 弊社でClaude Codeが利用可能になる前までは、Github Copilot Agentを使って、One-shotのプロンプトでテストを生成させる手法を試みました。しかし、プロジェクト固有のルールが守られなかったり、意図しないコードが生成されたりと、結果として出力の6〜7割を人間が書き直すことになっていました。 Claude Codeが利用可能になった当初では、劇的な変化はありませんでした。Github CopilotでSonnet 4モデルを使用することができていたため、Github Copilotで培った仕組みをそのまま流用していたとのことです。hooksやmemoryの分散化の利用を試みましたが、管理が難しく、チーム開発になかなか向かないということがわかりました。 現在では、Subagentsを用いて、設計、実装、スタイルレビューと統合の4つに工程を分けることで、半自動化まで進めることができたとのことです。 実践！Claude Codeを使ったテスト半自動化4ステップ Claude Codeを使った半自動化の詳細説明をします。 この半自動化では、主に Subagents の機能を使っています。Subagentsとは、メインの会話に左右されずに特定のコンテキストを保持し、適切な権限のものと、特定の領域に特化して精度を向上させることができる再利用可能なエージェントのことです。公式サイト( https://code.claude.com/docs/ja/sub-agents )では、以下の4つの利点が挙げられています。 コンテキストの保持 特化した専門知識 再利用性 柔軟な権限 この機能とClaude Codeのファイル仕様に従って、以下のファイル構成で実現しています。 .claude ├── agents # Agentの定義が詰まったディレクトリ │ ├── consolidate-text-fixes.md │ ├── generate-test-spec.md │ ├── implement-test.md │ ├── investigate-test-pattern.md │ ├── review-test-first.md │ ├── review-test-second.md │ ├── review-test-third.md │ └── search-translation-key.md └── commands # ワークフロー(コマンド)を実行させる定義が詰まったディレクトリ └── test-workflow.md commandsディレクトリで定義したワークフロー(test-worklow.md)では、以下のような構成になっています。 🔽実際のtest-workflow.mdの中身を見る。(ここをクリック！) --- name: test-workflow description: テスト設計・実装・レビューの一連のワークフロー --- # テスト実装ワークフロー管理エージェント このエージェントは、テストの設計から実装、レビューまでの一連のワークフローを管理します。**各フェーズで適切なサブエージェントを呼び出し**、高品質なテストコードを作成します。 ## ワークフロー概要 1. **テスト設計** → 2. **テスト実装** → 3A. **並列テストレビュー** → 3B. **統合修正・最終調整** → 4. **最終確認** テスト設計後にユーザーレビューを求め、ユーザーの修正後承認を得てからテスト実装以降のフェーズに進みます。 ## 実行手順 ### Phase 1: テスト設計 📝 **使用エージェント**: `generate-test-spec` 1. 対象ファイルを分析 2. テスト設計書を作成（`<fileName>テスト設計書.md`） 3. **ユーザーに設計書のレビュー・修正を依頼** 4. 承認を得たら次フェーズへ ### Phase 2: テスト実装 💻 **使用エージェント**: `implement-test` 1. テスト設計書を基にテストコードを実装 2. テストを実行してカバレッジ確認 3. エラーがある場合は修正（最大3回試行） ### Phase 3A: 並列テストレビュー 🔍 3つのテストレビューエージェントを**並列実行**して、その結果を結合した問題の分析と改善方針を1つ作成します： #### Review 1: 基本修正分析 **使用エージェント**: `review-test-first` - 動的import、getState、非同期処理などの基本的な問題を分析 - 改善方針と具体的な修正内容を提案 - **ファイル修正やテスト実行は行わない** #### Review 2: DOM・マッチャー・設定分析 **使用エージェント**: `review-test-second` - detectChanges、translate関数、MockStoreValueなどの問題を分析 - 改善方針と具体的な修正内容を提案 - **ファイル修正やテスト実行は行わない** #### Review 3: spyOn・配列・追加ルール分析 **使用エージェント**: `review-test-third` - 専用マッチャー、spyOn配置、DOM要素取得などの問題を分析 - 改善方針と具体的な修正内容を提案 - **ファイル修正やテスト実行は行わない** #### レビュー結果ファイル生成 - レビュー結果ファイル名: `<fileName>レビュー結果.md` - 管理のためレビュー対象ファイルと同ディレクトリに生成 - 加工は行わず各レビューエージェントから返却された結果を結合する ### Phase 3B: 統合修正・最終調整 🛠️ **使用エージェント**: `consolidate-test-fixes` - **前フェーズで作成したレビュー結果ファイルを渡します** 1. **実際の修正実行**: 統合された修正計画に従ってファイルを修正 2. **テスト実行**: 修正後のテストを実行して動作確認 3. **最終調整**: エラーがあれば原因分析して再修正 4. **最終確認**: もう一度並列テストレビューを行い、修正が完了しているかを確認する 5. **レビューファイルの削除**: 不要になったレビューファイルを削除する ### Phase 4: 実装最終確認 ✅️ 実装内容が設計書から乖離した内容になっていないかを確認 ## 注意事項 ### 各フェーズ共通 - エラーや問題が発生した場合は詳細をユーザーに報告 ### テスト実行コマンド ```bash npm run test <project> --specs=<testFile> --agent # e.g. npm run test viewer --specs=hoge.component --agent ``` YOU MUST: **テスト実行時は必ず`npm run test <project> --specs=<testFile> --agent`を使用し、他のコマンド実行を試みないこと、特に`--agent`オプションを追加しないとテストが終了しません** - `<project>`: プロジェクト名（`viewer`, `myportal`, `core`, `sdk`のいずれか） - `<testFile>`: `.spec.ts`を除くテストファイルパス。例：`example.component` ### 品質基準 - カバレッジ: 95%以上 - すべてのテストケースが成功すること - コードスタイルがプロジェクトの規約に準拠していること ## トラブルシューティング ### テストが失敗する場合 1. エラーメッセージを確認 2. consolidate-test-fixesエージェントで再修正を試行 3. 3回試行しても解決しない場合は`investigate-test-pattern`エージェントを使用して同様の実装がないか調査してから再修正 ### レビューで問題が見つからない場合 1. 該当するレビューエージェント（review-test-\*）を再実行 2. 特定の問題に焦点を当ててレビューを指示 3. 新たなレビュー結果でconsolidate-test-fixesを再実行 全体の流れとしては、以下の4ステップです。 テスト設計 まず generate-test-spec エージェントが対象コードを分析し、テスト設計書を作成します。ここで重要なのが 「人間の承認」 を必須にしている点です。設計書がプロジェクトの意図と合致しているかをエンジニアが確認し、修正を経てOKが出て初めて実装フェーズへ進むようにしています。 テスト実装 承認された設計書を元に、 implement-test エージェントがコーディングを行います。ここではテストの実行とカバレッジ確認までを自律的に行い、エラーが出れば自己修正するように指示しています。 ここで工夫した点は、実装内容に直接関係しない弊社特有のルール（命名規則やスタイル）はあえてこの工程では指示しないことです。ルールを厳格に守らせようとすると、肝心な処理に関わるロジックの精度が落ちてしまう傾向があった経験があったためです。これによって、まずは純粋な処理のみに集中させることで、本来のコーディングスキルを存分に発揮してもらい、 Claude Codeが自信を持って 実装してもらえるようになったとのことです。 並列トリプルレビュー 実装されたコードに対し、3つの異なる専門家エージェントが 並列で レビューを行います。 Reviewer A: 基本的な構文や非同期処理のチェック Reviewer B: DOM操作やマッチャーの正確性チェック Reviewer C: SpyOnやモック定義など、高度なルールのチェック この過程では、2番目のステップの出力結果をもとに、処理内容には関係ない弊社特有のルールに沿っているかの確認のレビューを行い、提案のみを行います。コード編集は行いません。 これによって、以下の3つのメリットがあったとのことです。 複数の項目をAgentに投げると、細かい見落としが多くなる傾向にあったが、Subagentsで分けることで、特定の観点に絞ることができ、精度が上がった 並列実行することで、実行速度が向上した 処理内容のレビューは考慮せずに、スタイルレビューに限定させたことで、この過程で弊社特有のルールや表現を入れ込むことができた 統合修正・最終調整 3匹のレビュアーから上がってきた指摘事項を consolidate-test-fixes エージェントが集約し、実際のコード修正に適用します。最後に改めてテストを回し、設計書との乖離がないかを確認して完了となります。 このワークフローがもたらした、時間以上の「価値」 この「半自動化」を導入した結果、テスト実装にかかる時間は 体感で約20%短縮 されました。数字だけ見ると劇的な変化ではないように見えるかもしれません。しかし、東條さんは「時間短縮以上の価値がある」と語ります。 並行処理による生産性向上 AIがコードを書いている間、人間はSlackの返信やBacklogの整理、あるいは他の複雑な実装の考察など、別のタスクをこなせるようになりました。0から1の面倒な記述をAIが肩代わりしてくれることで、脳のメモリを他の業務に割けるようになったそうです。 品質の向上 AIとの対話の中で、「そのエッジケースは考慮しましたか？」と逆に指摘されることもあり、一人で書くよりもテストの網羅性が上がったといいます。 おわりに：AIとの協業が当たり前になる未来へ 今回は、新卒2年目が実践する、生成AIを用いたテスト半自動化ワークフローについて紹介しました。今回紹介したワークフローを導入したことで、2025年6月〜2025年12月までに完了するという目標だった予定が、2ヶ月早く終えることができたとのことです。 今後は、このノウハウをチーム全体から開発部署全体に広げつつ、さらなる精度の向上に取り組んでいきたいとのことです。 また、生成AIをテスト自動化以外のことで使っていきたい分野はあるかを聞いてみました。 「勉強に使いたいなと思っています！10時に出勤して、10時〜12時はエージェントに任せている間に、優雅にコーヒーを飲みながら最新技術のキャッチアップに費やしたいなと思ってます。そして、もっと使うエージェントを増やして、10や20匹のAgentに対して指示を出して、操ってみたいなという野望もあります。」 最後に、これからAIを使いこなしたいと考えている後輩や学生エンジニアへのアドバイスをもらいました。 「使いこなし方こそ、生成AIに聞いたら良いと思います！笑。バイブコーディングが流行っていますが、やはり、読む力は引き続き必要になっていくのではないかと思っています。大切なのは、AIに使われるのではなく、使いこなす側になること。AIが出してきた成果物に対して、自分の頭で考え、疑い、責任を持つ。エンジニアとしての『思考力』が、これからの時代こそ重要になると思います。」 AIはあくまでツールであり、最後に品質を保証するのはエンジニア自身です。この当たり前の原則を忘れずに、AIを「賢い部下」のような立ち位置で活用し、協力していくスタイルこそが、これからの開発のスタンダードになっていくのかもしれません。 いま改めて、AIとの向き合い方を意識的に考えることが最も重要だと気付かされました。 以上、新卒2年目が実践するテスト半自動化に関するご紹介でした。

この記事は  Safie Engineers' Blog! Advent Calendar 2025 11日目の記事です。 はじめに 今年も残すところあとわずかとなりましたね。AI開発部の田中です。 現在は、複数のカメラ映像を統合して解析するシステムのR&D（研究開発）に取り組んでいます。 画像認識AIの分野ではPythonが主流ですが、 「Pythonでロジックを書いたら、処理が遅すぎてリアルタイム性が確保できない」 という壁にぶつかったことはありませんか？ 今回は、6台のカメラを使った リアルタイムマルチカメラトラッキング を実装する過程でまさにその問題に直面し、一部の処理を Rust に置き換えることで劇的な高速化を実現した話を紹介します。 「Rustは難しそう」と思っている方でも、Pythonと連携させるだけなら意外とハードルは高くありません。ぜひ最後までお付き合いください。 はじめに リアルタイムマルチカメラトラッキングとは システム構成と技術スタック 1. 推論部（映像のデコード・AI推論） 2. 統合部（トラッキング・ID統合） Pythonでの限界とRustへの転換 なぜRustを選んだか PyO3とmaturinを使った実装フロー 前提ツール 1. プロジェクトのセットアップ 2. Rustコードの実装 (src/lib.rs) 3. Pythonからの呼び出し (main.py) 4. ビルドと実行 導入結果：10倍以上の高速化を実現 まとめ リアルタイムマルチカメラトラッキングとは リアルタイムマルチカメラトラッキング（オンラインマルチカメラトラッキング）とは、RTSPなどで接続した複数のカメラから現在の映像を取得し、リアルタイムに以下の処理を行う技術です。 検出 : カメラごとに被写体の領域（バウンディングボックス）を検出 追跡 : カメラ内で被写体を追跡し、カメラ内のIDを割り当て 特徴抽出 : 被写体の見た目の特徴量（ReID特徴量など）を抽出 統合 : 全カメラの情報を統合し、エリア全体で「被写体がどこにいるか」を一意に特定 これらを 「次のフレームの映像が来る前」 に完了させる必要があります。 今回目指したスペックは、 「ネットワークカメラ6台、各20FPS」 です。つまり、全カメラの処理を 50ミリ秒（1000ms / 20fps）以内 に完了させなければ、遅延が発生してしまいます。 システム構成と技術スタック システムの大まかな構成図は以下の通りです。 処理は大きく「推論部」と「統合部」に分かれています。 1. 推論部（映像のデコード・AI推論） GPUリソースを最大限に活かすため、NVIDIAの技術を採用しています。 DeepStream SDK GStreamerベースのマルチメディアフレームワーク。動画のデコードやDNN推論をパイプライン処理で高速に実行可能です。 DeepStream Python Apps DeepStreamをPythonから制御するためのバインディングです。 【出典】NVIDIA-AI-IOT, deepstream_python_apps, GitHub https://github.com/NVIDIA-AI-IOT/deepstream_python_apps （2025年11月23日アクセス） 2. 統合部（トラッキング・ID統合） 推論結果を受け取り、ロジックベースで被写体の同一性判定を行います。 Python : 全体の制御・グルーコード Rust : 計算コストの高いマッチング処理を担当 PyO3 & maturin : PythonとRustを繋ぐためのツール群 【出典】PyO3 Project, PyO3 User Guide, Webページ https://pyo3.rs/main/index.html （2025年12月10日アクセス） 【出典】PyO3 Project, maturin, GitHub https://github.com/PyO3/maturin （2025年12月10日アクセス） Pythonでの限界とRustへの転換 推論部に関しては、DeepStreamの恩恵によりPythonバインディング経由でも十分高速でした。 問題が発生したのは、後段の「統合部」です。 複数のカメラから検出された被写体の位置や特徴量を総当たりで比較し、同一被写体判定を行う処理（マッチング処理）において、Pythonの処理速度がボトルネックになりました。 カメラが増え、被写体が増えれば増えるほど計算量は指数関数的に増加します。 純粋なPython実装でテストしたところ、被写体が多いシーンでは処理に 数百ミリ秒 かかってしまいました。目標の50ミリ秒を大幅に超えており、映像はカクつき、処理落ちは避けられない状態です。 なぜRustを選んだか NumPyなどを使ったベクトル化も検討しましたが、条件分岐を含む複雑なロジックだったため、コンパイル言語への置き換えを検討しました。そこで白羽の矢が立ったのが Rust です。 C++並みの高速性 : メモリ安全性を担保しながら爆速で動く。 PyO3のエコシステム : Pythonとの連携が非常に容易で、既存のPythonコードの一部だけをRust関数に置き換える「部分的な導入」がしやすい。 「全体を書き直すのは無理だが、重いループ処理だけRustに任せよう」という戦略です。 PyO3とmaturinを使った実装フロー ここからは、実際に今回採用した開発フローを紹介します。 パッケージ管理には、最近話題の高速なツール uv を使用しました。 前提ツール uv : Pythonのパッケージ管理・プロジェクト管理ツール Rust : コンパイラ言語（cargoなどが含まれます） 1. プロジェクトのセットアップ maturin を使えば、Rustのプロジェクト作成からPythonパッケージとしてのビルドまで一気通貫で行えます。 # 作業ディレクトリへ移動 cd ${WORK_DIR} # maturinのインストール（uv toolを使用） uv tool install maturin # PyO3バインディングを含む新規プロジェクト作成 # --mixed オプションでPythonとRustのハイブリッド構成を作成 uvx maturin new -b pyo3 --mixed study_maturin cd study_maturin # 仮想環境の作成（Python 3.12指定） uv venv -p 3 . 12 2. Rustコードの実装 (src/lib.rs) デフォルトで生成されるコードです。 use pyo3 :: prelude :: * ; /// 2つの数値を足して文字列として返す関数 #[pyfunction] fn sum_as_string (a: usize , b: usize ) -> PyResult < String > { Ok ((a + b). to_string ()) } /// Pythonモジュールとしての定義 #[pymodule] fn study_maturin (m: & Bound < '_ , PyModule > ) -> PyResult < () > { // Pythonから呼べる関数として登録 m. add_function ( wrap_pyfunction! (sum_as_string, m) ? ) ? ; Ok (()) } 3. Pythonからの呼び出し (main.py) ビルドされたRustの関数は、通常のPythonモジュールと同じようにimportして使用できます。 import study_maturin def main (): a = 2 b = 3 # Rustで実装された関数を呼び出し result = study_maturin.sum_as_string(a, b) print (f "The sum of {a} and {b} is: {result}" ) if __name__ == "__main__" : main() 4. ビルドと実行 開発モード（ maturin develop ）でビルドすると、現在の仮想環境にパッケージがインストールされます。本番性能を出すため --release を付けています。 # キャッシュクリア（念のため） uv cache clean # リリースビルドでインストール uvx maturin develop --release # Pythonスクリプト実行 uv run main.py 実行結果: The sum of 2 and 3 is: 5 このように、非常に少ない手順でRustの関数をPythonから呼び出すことができました。 今回は単純な足し算ですが、実際の業務ではここに「マルチカメラのID統合ロジック」を実装しました。 Rust側で構造体を定義してPythonのクラスとして扱ったり、型ヒント（.pyiファイル）を生成してVSCodeでの補完を効かせたりすることも可能です。 導入結果：10倍以上の高速化を実現 統合部のボトルネックとなっていた解析ロジックをRustに置き換えた結果、パフォーマンスは劇的に改善しました。 Before (Python) : 1フレームあたり 300ms超 （ピーク時） After (Rust) : 1フレームあたり 30ms以内 約10倍以上の高速化 を達成し、目標としていた「6台・20FPS（50ms以内）」の処理時間を余裕を持ってクリアすることができました。これにより、リアルタイムで滑らかなトラッキングが実現できています。 まとめ 「Pythonは遅い」と諦める前に、ボトルネック部分だけをRustにオフロードするアプローチは非常に有効でした。 特に PyO3 と maturin （そして uv ）のエコシステムのおかげで、PythonエンジニアにとってもRust導入の敷居はかなり低くなっていると感じます。 今回はロジックの一部のみの置き換えでしたが、今後はRustで処理する領域を広げ、システム全体の堅牢性とパフォーマンス向上に挑戦していきたいと思います。

この記事は Safie Engineers' Blog! Advent Calendar 10日目の記事です こんにちは！Safie（セーフィー）でモバイルアプリの開発をしている河原( @rui_qma )です。 🚀 はじめに：なぜComposeでドラッグ＆ドロップが必要なのか 従来のViewシステムとの壁 AndroidチームではAndroid ViewベースのUIから Jetpack Compose ベースのUIへの移行を進めています。 弊社のプロダクト「 Safie Viewer （セーフィー ビューアー）」のカメラ一覧画面には、カメラの順番をドラッグ＆ドロップ（D&D）によって並び替える機能があります。 従来のAndroid Viewでは、 RecyclerView に ItemTouchHelper を組み合わせることで、D&Dによる並び替えが公式APIとして簡単に実現できていました。 しかし、Jetpack Composeでは、2025年11月現在、 LazyVerticalGrid （または LazyColumn ）内で同様のD&D並び替え機能を「公式APIだけで」実現するための専用のコンポーネントはまだ提供されていません。( composeBom : 2025.11.01で確認) 本記事では、この「Composeでドラッグ＆ドロップによる並び替えが可能なグリッド」を、公式API未提供の中でどのように作り込むか、その設計と実装手法について解説します。 🚀 はじめに：なぜComposeでドラッグ＆ドロップが必要なのか 従来のViewシステムとの壁 ✨ 実現したい機能の要件定義 📦 Step0: 土台となるComposableを用意 👆Step1: 要素の長押し検出と触覚フィードバック 実装のポイント ↔️Step2: 要素をドラッグして移動する 実装のポイント 🔄Step3: ドラッグによる要素の入れ替え処理 実装のポイント 💫Step4: 入れ替わる際のアニメーションを実装 実装のポイント ⬇️Step5: リストの上下端到達時の自動スクロール 実装のポイント 🎉 まとめと今後の展望 👀将来的な見通し 💻 実装コード ✨ 実現したい機能の要件定義 今回の記事で実装を目指すD&D並び替えグリッドの要件は以下の5点です。 要素を 長押し したタイミングでD&D可能状態にし、 触覚フィードバック を実行する。 ドラッグに沿って要素を移動させる。 順番の入れ替わりが発生した場合、 アニメーション で視覚的に表現する。 ドラッグ位置がリストの上下端に達した場合、 リスト自体を自動でスクロール する。 ドラッグ終了時に要素を定位置に戻す。 これらの機能を、土台となるComposableから段階的に実装していきます。 📦 Step0: 土台となるComposableを用意 今回の設計方針としてLazyVerticalGridをラップするComposableを作成し(DraggableGridと命名)、このComposableの中で状態の管理及びD&D機能の拡張を進めていきます。 @Composable fun DraggableGrid( list: List < String >, modifier: Modifier = Modifier, itemContent: @Composable (item: Camera, modifier: Modifier) -> Unit , ) { val lazyGridState = rememberLazyGridState() LazyVerticalGrid( modifier = modifier, columns = GridCells.Fixed( 3 ), state = lazyGridState, horizontalArrangement = Arrangement.spacedBy( 12 .dp), verticalArrangement = Arrangement.spacedBy( 12 .dp), ) { items(list) { id, modifier -> itemContent(id, modifier) } } } 👆Step1: 要素の長押し検出と触覚フィードバック 要素の長押しを検知する処理を実装します。 実装のポイント ドラッグ対象のCompose要素に Modifier.pointerInput を追加 pointerInput内でジェスチャー検出関数 detectDragGesturesAfterLongPress で長押しを検出 onDragStart に長押し時の処理、 onDrag にドラッグ中の処理を実装する 触覚フィードバックは performHapticFeedback を呼び出すことで動作するため、以下のように実装することによってユーザーに長押し状態であることを知らせることができます。 Developers ... val haptic = LocalHapticFeedback.current LazyVerticalGrid( modifier = modifier.pointerInput( Unit ) { detectDragGesturesAfterLongPress( onDragStart = { offset -> // ドラッグ開始時に行いたい処理をここに実装する haptic.performHapticFeedback(HapticFeedbackType.LongPress) // 触覚フィードバック }, onDrag = { change, dragAmount -> // ドラッグ中に行いたい処理をここに実装する change.consume() // ドラッグイベントの消費 }, onDragEnd = { // ドラッグ終了時に行いたい処理をここに実装する }, onDragCancel = { // ドラッグがキャンセルされた時に行いたい処理をここに実装する } ) }, ... ↔️Step2: 要素をドラッグして移動する Step1で記述したdetectDragGesturesAfterLongPressのコールバックにドラッグに関する処理を実装していきます。 実装のポイント onDragStartでドラッグ対象のインデックスを取得 onDragでドラッグ量を加算して保持 ドラッグ対象要素に対して Modifier.offset でドラッグ量を指定して移動 onDragEnd, onDragCancelでドラッグ量を初期化 （今回は簡単に実装するためにComposable内でインデックスやオフセット等の状態を管理していますが、Stateクラスの作成などViewとは分離して管理することをオススメします） val density = LocalDensity.current var draggingIndex by remember { mutableIntStateOf( 0 ) } var dragOffset by remember { mutableStateOf(Offset.Zero) } LazyVerticalGrid( modifier = modifier.pointerInput( Unit ) { detectDragGesturesAfterLongPress( onDragStart = { offset -> // ドラッグ開始位置のインデックスを取得 draggingIndex = lazyGridState.layoutInfo.visibleItemsInfo.find { info -> val rect = Rect(info.offset.toOffset(), info.size.toSize()) rect.contains(offset) }?.index ?: - 1 haptic.performHapticFeedback(HapticFeedbackType.LongPress) // 触覚フィードバック }, onDrag = { change, dragAmount -> dragOffset + = dragAmount change.consume() // ドラッグイベントの消費 }, onDragEnd = { dragOffset = Offset.Zero }, onDragCancel = { dragOffset = Offset.Zero } ) }, ... ) { itemsIndexed( items = list, key = { index, item -> item }, ) { index: Int , item: String -> val dragging = draggingIndex == index val modifier = if (dragging) { Modifier .offset( x = with(density) { dragOffset.x.toDp() }, y = with(density) { dragOffset.y.toDp() }, ) .zIndex( 1f ) // ドラッグ中のアイテムを前面に表示 } else { Modifier } itemContent(item, modifier) } } 🔄Step3: ドラッグによる要素の入れ替え処理 ドラッグ中アイテムの 中心位置 が他要素の領域に入ったタイミングで、リストの順番を入れ替える処理を実行します。 実装のポイント 要素入れ替えコールバック(ex: onListChange)を定義し、並び替えの処理を実装する ドラッグ中アイテムの中心位置を算出する 中心位置が他要素の領域内に存在する場合、要素入れ替えコールバックを実行する 実際の入れ替えロジックは複雑になるため、ここでは詳細を割愛しますが、リスト変更を親に委ねるコールバック設計が重要です。詳細な実装は コチラ を参照ください。 💫Step4: 入れ替わる際のアニメーションを実装 要素が入れ替わったことをユーザーにわかりやすく伝えるため、アニメーションを追加します。 このStepに関しては標準で提供されている機能を利用することで、手軽に実装することができます。 実装のポイント アイテムにキーを設定する 入れ替えられる側の要素に Modifier.animateItem() を設定する itemsIndexed( items = list, key = { index, item -> item }, // Compose側でアイテムを特定するためのキー ) { index: Int , item: String -> val dragging = draggableGridState.draggingIndex == index val offset = draggableGridState.dragOffset val modifier = if (dragging) { Modifier .offset( x = with(density) { offset.x.toDp() }, y = with(density) { offset.y.toDp() }, ) .zIndex( 1f ) } else { Modifier.animateItem() // 入れ替えられる側にアニメーションを設定 } itemContent(item, modifier) } ⬇️Step5: リストの上下端到達時の自動スクロール 例えば「1番目から100番目に移動したい」といった大幅な移動を行いたい場合、現状は1回のドラッグにつき最大1画面分しか移動できないため、複数回のドラッグが必要になります。 この問題を解決するため、ドラッグによってリストの上下端まで持っていった場合はリスト自体のスクロールも行う機能を実装します。 実装のポイント ドラッグ中の要素がリストの上下端からどれだけはみ出しているかを算出する はみ出している場合は、はみ出した量に応じたY軸移動量を算出する リストと要素の両方を同時にY軸移動量分だけ移動する（同期する） この実装はパフォーマンスと競合回避の観点から複雑な部分であり、スクロールと要素移動を同時に行う同期処理に工夫が必要です。詳細な実装は コチラ を参照ください。 🎉 まとめと今後の展望 本記事では、Jetpack Composeにおいて標準で提供されていない機能を、 Modifier.pointerInput を活用してゼロから作り込む手法を解説しました。 タッチイベントの検出、オフセットによる位置調整、 Modifier.animateItem() によるアニメーション、そして自動スクロールを組み合わせることで、従来のAndroid Viewの RecyclerView + ItemTouchHelper に匹敵する、高度なUXを実現することができました。 この実装には手探りの部分が多く、リファクタリングやパフォーマンス改善の余地は十分にあると考えていますが、本記事が皆様のCompose実装の手助けとなれば幸いです。 👀将来的な見通し 執筆時点では自前での実装が必要でしたが、ロードマップにはドラッグ＆ドロップに関する記載があるため、将来的には標準機能としてサポートされる可能性が高いです。 出典：Jetpack Compose のロードマップ https://developer.android.com/jetpack/androidx/compose-roadmap?hl=ja （2025年12月3日アクセス） それまでは今回解説したような自前の実装を行うか、あるいは、従来のAndroid Viewの ItemTouchHelper を ComposeView でホストして利用するという選択肢も一つの回避策となります。状況に応じて、最適なアプローチを選択してください。 💻 実装コード 執筆にあたって実装したコード全体は、以下のGitHubリポジトリで公開しています。是非参考にしてください。 https://github.com/ruiqma/DraggableGridSample モバイルチームは開発する仲間を募集しています！ open.talentio.com open.talentio.com

この記事は Safie Engineers' Blog! Advent Calendar 2025 9日目の記事です。 はじめに こんにちは、エンジニアリングオフィスの横道 ( @m_yokomichi )です。 2025年、AI技術は私たちの予想を超えるスピードで進化を遂げました。いまや生成AIを使いこなせるか否かは、個人の生産性だけでなく、 エンジニアとしてのキャリア、ひいては企業の競争力そのものを左右する と言っても過言ではありません。 今後、活用できる層とそうでない層の差は広がる一方です。そのため、生成AIの活用は私たちセーフィーにとっても全社の重要課題であり、開発本部として組織的に向き合うべきテーマとなっています。 本記事では、開発本部全体で取り組んでいる「生成AI利用促進プロジェクト」について、以下のポイントを中心にご紹介します。 組織課題を解決するための「5つの戦略軸」 ボトムアップで進める実際の活動内容 導入による具体的な成果と今後の展望 単なるツールの導入事例ではなく、「組織文化をどう変えていくか」という観点での全貌をお伝えします。 はじめに 私たちが直面していた「5つの壁」 1. 情報収集の「非効率性」 2. 技術検証・導入の「属人化」 3. ナレッジの「サイロ化」 4. 活用機運の「温度差」 5. 技術的取り組みの「認知不足」 解決への戦略的アプローチ：5つの軸 プロジェクト全体構想図 軸1：情報収集活性化 📡 軸2：技術検証・導入 🛠️ 軸3：ナレッジデータベースマネジメント 📚 軸4：生成AI活性化 🔥 軸5：社外発信 📢 実際の活動と想定外の反響 20名の有志が集結 分科会による自律的な運営 成果と今後の展望 主な成果 今後のロードマップ おわりに 私たちが直面していた「5つの壁」 生成AI活用を組織的に推進しようとした際、私たちは大きく分けて5つの問題領域に直面していました。これらは、多くの開発組織が共通して抱える悩みではないでしょうか。 1. 情報収集の「非効率性」 外部の技術動向を個人がバラバラに追っているため、組織としてのインプットが非効率でした。「隣のチームも同じ調査をしていた」という車輪の再発明が起きており、組織としてのスピード感が損なわれていました。 2. 技術検証・導入の「属人化」 「この新機能を使いたい」と思っても、導入プロセスや評価基準が不明確でした。結果として、意欲あるメンバーの技術選定に時間がかかり、有益な技術の導入による機会損失が発生していました。 3. ナレッジの「サイロ化」 Aさんは高度なプロンプトを知っているのに、Bさんは同じ課題で躓いている。成功事例や失敗事例（アンチパターン）が共有されず、ノウハウが個人の頭の中だけに留まっていました。 4. 活用機運の「温度差」 「便利そうだけど、自分の業務での使い所がわからない」というメンバーも多く、一部の感度が高い層だけが活用している状態でした。 5. 技術的取り組みの「認知不足」 せっかく先進的な取り組みをしていても、それが外部に伝わっていなければ採用やブランディングには繋がりません。また、外部コミュニティとの接点が薄く、フィードバックを得る機会も不足していました。 解決への戦略的アプローチ：5つの軸 これらの課題を打破するため、私たちは「5つの軸」を定義し、戦略的なアプローチを開始しました。 プロジェクト全体構想図 まず、以下のサイクルを回すことで、生成AI（AI技術）の導入・定着を目指しました。生成AI利用促進チームがハブとなり、開発本部全体を巻き込んでいます。 ここからは、具体的な5つの軸について解説します。 軸1：情報収集活性化 📡 目的： 組織的な「アンテナ」の感度を高め、技術選定を高速化する 個人の努力に依存していた情報収集を、組織の活動へと昇華させました。 トレンドの定点観測: 最新ツールや事例をチームで分担して調査 導入ジャッジ: 利用方法が明確なものは「実務検証」へ、未導入技術は「企画」へとスムーズに移行させるフローを確立 軸2：技術検証・導入 🛠️ 目的： 新技術を「安全に」「素早く」試せる環境を作る 「使ってみたい」を「使える」にするための環境整備です。 環境整備: アカウント管理やLLM Proxy基盤の構築 ガイドライン策定: セキュリティや個人情報の取り扱い、機密情報の保持に関するルールを明確化し、安全に利用できる環境を提供 軸3：ナレッジデータベースマネジメント 📚 目的： 知見を「資産」化し、車輪の再発明を防ぐ DB構築: ベストプラクティス、失敗事例、プロンプトライブラリを一元管理 メンテナンス: 情報の鮮度を保つため、陳腐化した情報の更新フローを整備 テンプレート化: 開発、分析、ドキュメント作成など、用途別の「再利用可能なプロンプト」を整備 軸4：生成AI活性化 🔥 目的： 組織全体の「熱量」を上げ、文化を作る イベント開催: 勉強会、LT（ライトニングトーク）、ハッカソンなどを企画 横展開: 成功事例を部門を超えて共有し、「自分もやってみよう」という空気を醸成 軸5：社外発信 📢 目的： 取り組みを「価値」に変え、新たな知見を呼び込む アウトプット: 技術ブログやイベント登壇を通じた発信 還流: 社外からのフィードバックを社内に取り込み、さらなる改善につなげるサイクル 実際の活動と想定外の反響 戦略は描けましたが、私一人で実行できるものではありません。そこで開発本部全体からメンバーを公募したところ、予想外の反応がありました。 20名の有志が集結 当初は数名集まれば良いと考えていましたが、 約20名ものメンバーが手を挙げてくれました。 開発本部のエンジニアたちが、いかにこの課題に熱意を持っていたかの表れであり、非常に嬉しい誤算でした。 分科会による自律的な運営 メンバーの自主性を尊重し、前述の5つの軸ごとに「分科会」を組成しました。 週次・隔週で定例MTGを行い、それぞれの強みを活かしてアクションプランを実行しています。トップダウンではなく、現場のエンジニアが主導するボトムアップ型のプロジェクトとして機能しています。 成果と今後の展望 2025年9月の発足から数ヶ月、土台づくりに注力してきましたが、すでに目に見える変化が起きています。 主な成果 利用率の向上: Claude CodeのMaxプラン等の高度な機能を利用するメンバーが前月比で増加傾向。 学習文化の定着: 開発本部の 約半数 が生成AI勉強会に参加。 ナレッジベース稼働: 独自のデータベースが構築され、日々知見が蓄積されている。 ポータルサイト開設: ツールやガイドライン、最新情報を集約した「生成AIポータル」を公開。 今後のロードマップ 📍 短期（FY25年度内） 技術検証: LLM Proxy基盤の構築、Claude Teamプランへの移管。 活性化: LT大会の実施（11/27、12/11予定）、ハンズオン・ハッカソンの開催。 ナレッジ: プロンプトライブラリのカテゴリ拡充（コードレビュー、設計支援など）。 📍 中長期（来年度以降） 効果測定: 単なる利用者数ではなく、コード品質や開発速度など「生産性指標」への貢献を可視化。 全社展開: 開発本部で培ったノウハウを他部門へ横展開し、全社的なDXを支援。 文化の定着: 新入社員向けの「生成AI活用研修」などを通じ、AI活用を空気のような「当たり前」にする。 おわりに 生成AIを組織で活用できている状態にするには、個人の「点」の活動だけでは限界があります。組織全体で戦略的に取り組み、「面」の活動にすることで初めて、知見の標準化や文化醸成が可能になります。 今回ご紹介した「5つの軸」はあくまでセーフィーの一例ですが、組織的なAI活用に悩む皆様のヒントになれば幸いです。 セーフィー開発本部では、今後もイベント等を通じて知見をオープンにしていきます。「うちではこうしているよ！」という他社の皆様、ぜひ情報交換させてください！

この記事は  Safie Engineers' Blog! Advent Calendar  の8日目の記事です。 こんにちは、セーフィー株式会社でサイバーセキュリティを担当している金原です。 前回の記事「 セーフィーのサイバーセキュリティ戦略の作り方 」では、私たちが目指す「セキュリティが当たり前の文化」と「そこに到達するための戦略」についてお伝えしました。今回は、戦略の具体的な打ち手の一つ、 「脅威モデリング」 について深掘りします。 「脅威モデリング」と聞くと、専門用語が多くて「難しそう」「時間がかかりそう」と感じてしまうことはありませんか？ 正直に言うと、私たちも最初はそうでした。 しかし、試行錯誤してたどり着いた結論はシンプルです。脅威モデリングの本質は 「関係者同士の対話を促進するコミュニケーションツール」 だということ。 今回は、一般的な脅威モデリングの手法を解説しつつ、それを「セーフィーではどう解釈し、運用しているか」という 実践的なナレッジ（＝セーフィー流の型） をセットで公開します。これから脅威モデリングを始めたい方、もっと活用していきたい方の「生きた教科書」になれば幸いです。 そもそも「脅威モデリング」って何？ なぜ今、私たちがこれを推すのか 脅威モデリングの進め方（解説とセーフィー流の実践） 4つの重要な質問 【問1】私たちは何に取り組んでいるか？ ～モデルを作る～ 【問2】何が問題になりうるか？ ～STRIDEでリスクを見つける～ 【問3】それに対して何をするのか？ ～リスク評価と対策～ 【問4】十分にうまくできたか？ ～ふりかえり～ セーフィーでの活用事例 1. セキュリティレビューへの「部分導入」 2. 「すぐに始められる」テンプレートの用意 3. 生成AIを「副操縦士」にする さいごに そもそも「脅威モデリング」って何？ 一言でいうと、 「システムを作る前に、攻撃者の視点を踏まえ『起きたら困ること』を分析し、対策を考える活動」 です。 通常、開発の現場では「どんな機能を作るか（要件）」や「どうやって作るか（設計）」に集中しがちです。そこに 「何が問題になりうるか（セキュリティリスク）」 という視点をプラスします。 なぜ今、私たちがこれを推すのか 理由は大きく2つあります。 「シフトレフト」の世界標準だから NISTの「SSDF」やOWASPの「SAMM v2」など、主要なガイドラインで推奨されています。設計段階でリスクを潰すことで、手戻りを防ぐためです。 生きたセキュリティ教育になるから（★最重要） 私が特に重視しているのはこちらです。脅威モデリングを行うには、エンジニア、PM、セキュリティ担当者が集まって会話をする必要があります。 「ここのデータって、どういう流れでDBに入るんだっけ？」 「このAPI、認証なしで叩けたらマズいよね？」 こうした会話自体が、座学の研修よりもはるかに効果的な 「生きたセキュリティ教育」 になります。ドメイン知識とセキュリティ知識が、対話を通じてチーム全体に染み渡るのです。 脅威モデリングの進め方（解説とセーフィー流の実践） では、具体的にどう進めればいいのでしょうか？ 基本は以下の 「4つの重要な質問」 に答える形で進めていきます。 ここで大事な心構えは 「完璧を目指さない」 こと。セーフィーでは、 「間違ってもいいから、まずはホワイトボードに絵を描いて話そう」 を合言葉にしています。 4つの重要な質問 【問1】私たちは何に取り組んでいるか？ ～モデルを作る～ まずは、システムの「形」を可視化します。一般的には、データフローダイヤグラム（DFD）が推奨されます。 ■DFDの書き方（いきなり詳細を描かない） DFDは「データがどこから来て、どこへ行くのか」という流れに注目した図です。 以下の5つの要素で図を表現します。 プロセス (Process) ：処理や機能（丸） データストア (Data Store) ：DBやファイルなどのデータが留まるところ（二本線） 外部エンティティ (External Entity) ：ユーザーや連携システム（四角） データフロー (Data Flow) ：データの流れ（矢印） 信頼境界 (Trust Boundary) ：インターネットと社内LANの間などの境界線（点線） よくある落とし穴が、「最初から詳細に描こうとして挫折する」ということ。私たちは 「抽象から具体へ」 という2ステップをおすすめしています。 ① コンテキストダイヤグラム でまずは「外」と「中」を分ける システム全体を1つの「箱」として捉え、外部（ユーザーや連携システム）とのやり取りだけを描きます。これだけで「守るべき範囲」が明確になります。 ② レベル0ダイヤグラム で内部構造を分解する 次に、箱の中身を主要なプロセスに分解し、データの保存場所（データストア）を描き足します。 ここで最も重要なのが 「信頼境界（Trust Boundary）」 という点線です。ここをデータがまたぐとき、脅威が発生しやすくなります。 必要に応じて、ここからさらにレベル1…、のように詳細化していきます。 ■セーフィー流の実践（厳密さよりも「対話の種」） 教科書通りの記号（丸や二本線など）を使おうとすると「これであってる？」と手が止まりがちです。私たちの現場では、 「ホワイトボード（またはMiro）に10分ぐらいで描けるレベルでいい」 としています。 厳密な記法より、 「データの流れ（線）」 が合っていればOK。 詳細な設計図である必要はない。先ほどの 「信頼境界（点線）」をまたぐ場所 がわかれば、そこが攻撃ポイントだと判断できる。 加えて、一度で終わりにせず、徐々に詳細度を上げていくスタイルを取っています。 📘 もっと学びたい方へ 具体的なDFDの作り方は、書籍『データフローダイアグラム いにしえの技術がもたらす システム設計の可能性』（大嶋和幸、松永守峰 / 翔泳社）が非常に参考になります。 【問2】何が問題になりうるか？ ～STRIDEでリスクを見つける～ モデルができたら、次は「ここが攻撃されたらどうなる？」を考えます。 ここでのポイントは、高度なハッキング方法を語るのではなく、 「起きたら困ること」 を洗い出すことです。攻撃手法の話になると専門家しかわからなくなりますが、「困ること」なら関係者全員で議論できます。 ■STRIDEフレームワーク 脅威を見つける切り口として、 「STRIDE（ストライド）」 というフレームワークを使うと便利です。以下のような「問いかけ」をしながら問1で作成したDFD上に付箋で書き出していくとスムーズです。 頭文字 脅威の種類 問いかけの例 具体例（Webアプリ） S Spoofing (なりすまし) 私たちまたはユーザーは、なりすましが起きて何が困るか？ 他人のアカウントでログインされる T Tampering (改ざん) 私たちまたはユーザーは、データ改ざんが起きて何が困るか？ DBの値や通信内容を書き換えられる R Repudiation (否認) 私たちまたはユーザーは、否認できる状態で何が困るか？ 「操作していない」と言い逃れされる I Information Disclosure (情報漏洩) 私たちまたはユーザーは、データ漏洩が起きて何が困るか？ 個人情報や機密データが漏れる D Denial of Service (サービス拒否) 私たちまたはユーザーは、システムの停止/遅延が起きて何が困るか？ システムがダウンして使えなくなる E Elevation of Privilege (権限昇格) 私たちまたはユーザーは、権限を越えた操作ができて何が困るか？ 一般ユーザーが管理者操作を行う ■セーフィー流の実践：「思考停止を防ぐカンペ」として使う STRIDEを事前にすべて暗記する必要はありません。私たちは上記のような具体例をいくつか添えた表を「問いを立てるためのカンペ」として使っています。 レビューの場で問いかけるためのトリガーになれば十分です。エンジニアが「あ、それだとこういうことが起きると困りますね」と気づけば、それが立派な脅威分析です。専門用語を覚えるより、 「困ること」を言語化できること を重視しています。 📘 もっと学びたい方へ STRIDEやセキュア設計については、書籍『セキュアなソフトウェアの設計と開発 脅威モデリングに基づく普遍的アプローチ』（ローレン・コンフェルダー / 秀和システム）がおすすめです。 【問3】それに対して何をするのか？ ～リスク評価と対策～ 脅威がたくさん出てくると、「全部直すなんて無理！」となってしまいますよね。 大事なのは、「同時にすべてを対策することはできない」 という前提に立つことです。リソースも時間も有限ですから、優先順位をつける必要があります。 リスクマップ： 「発生確率」×「影響度」で定性的に評価して優先度を決めます。 対策： リスク「高」のものから順にチケット化し、バックログに積みます。 ■リスクマップの例 ■セーフィー流の実践：必要に応じて評価方法を変える 教科書的には厳密にスコアリングして評価することが推奨されがちですが、全てのリスクでそれをやるとスピードが落ちてしまいます。 セーフィーでは、対象システムや情報の重要度に応じて「評価方法（物差し）」を使い分けています。 スピード感や柔軟性が求められる通常の機能は、「定性評価（高・中・低）」でスピーディに判断し、対策の要否を決めます。一方で、決済周りや特に重要な基盤システムは、「定量評価（ CVSS や OWASP Risk Rating Methodology 等）」を用いて厳密にスコアリングし、監査にも耐えうる根拠を残します。もちろん、2つを組み合わせるケースもあります。 「スピード重視」と「厳密さ」のメリハリをつけること。これを私たちは大切にしています。 📘 もっと学びたい方へ リスク評価の深掘りには、書籍『脅威インテリジェンスの教科書』（石川朝久 / 技術評論社）が参考になります。 【問4】十分にうまくできたか？ ～ふりかえり～ このふりかえりは飛ばされがちですが、実は脅威モデリングを組織やチームに浸透させるためには、とても重要な問いになります。 対策が妥当かどうかの評価も大事ですが、「脅威モデリングの進め方自体がどうだったか」 のふりかえりで経験学習のサイクルを回します。 ■セーフィー流の実践（10分で終わらせる「タイムボックス」） ふりかえりの手法は多数ありますが、セーフィーでは軽量に実施できる「＋/Δ（プラス/デルタ）」を採用して、 「10分間」 という時間を区切って実践しています。理由は、重くすると続かないからです。継続性が大事。 「DFDのスコープが広すぎて議論が発散したね」 「××さんが詳しいから、次は呼ぼう」 こうした小さな改善の積み重ね（アジャイルなアプローチ）が、チームのセキュリティ筋肉を育てていきます。 📘 もっと学びたい方へ ふりかえりの手法や有用性を学ぶなら、書籍『アジャイルなチームをつくる ふりかえりガイドブック 始め方・ふりかえりの型・手法・マインドセット』（森 一樹／翔泳社）がおすすめです。 セーフィーでの活用事例 ここまで脅威モデリングの手法とセーフィー流の実践をお伝えしました。では、これを具体的にどのように現場に落とし込んでいるのか？私たちの現在の取り組みを紹介します。 1. セキュリティレビューへの「部分導入」 これまでチェックリストベースで行っていたセキュリティレビューの一部に、脅威モデリングを取り入れ始めています。 開発者から説明を受ける際、セキュリティチームが手元で簡易的なモデルを作り、「ここのデータの流れ、信頼境界またいでるけど大丈夫？」といった対話をします。 チェックリストだけでは見えない重要箇所のレビューができますし、静的なアーキテクチャ図よりもデータやプロセスの流れが整理できるので、開発者からも好評です。私自身も、多くのセキュリティレビューを実施する中で、「あれどうなってたっけ？」となったときに、レビュー時に作成したモデルを見ることで思い出すことができて助かってます。 セキュリティレビューで作った脅威モデルの例 2. 「すぐに始められる」テンプレートの用意 「準備が面倒」という心理的ハードルを下げるため、オンラインホワイトボードツール（Miro）に 「脅威モデリングテンプレート」 を作成しました。 DFDのパーツとSTRIDEの付箋、そして「進め方」があらかじめ配置されています。これを開けば、すぐに議論に入れる状態を作っています。 脅威モデリングテンプレート（Miro） 3. 生成AIを「副操縦士」にする ここが最近のホットトピックです。私たちは 生成AI（Gemini等） を積極的に活用しています。 ゼロから「どんな脅威がある？」と考えるのは、認知負荷が高い作業です。そこで、システムの概要やユースケースをAIに与えて、 「DFDのドラフト」や「想定される脅威リスト」 を出力させます。 もちろんAIの出力は完璧ではありません。しかし、 「AIが出した80点の回答」を、人間のエンジニアが「セーフィーの現場知識（ドメイン知識）」で修正・補完して100点にする というプロセスは、ゼロから考えるより圧倒的に効率的です。 例えば、「小規模なIoTクラウドカメラシステム」というお題でGeminiに出力させた例がこちらです。（注：セーフィーのシステムではありません） Geminiが出力したモデル（Mermaid） Geminiが出力したリスクの一例 「カメラの物理的盗難」といった、IoTならではのリスクまで指摘してくれています。これを叩き台にすることで、議論のスタート地点を大幅に進めることができます。 さいごに 脅威モデリングを組織に浸透させるために一番大切なこと。それは、 「最初から完璧を目指さない」 ことです。 最初から正解の図を作ろうとすると手が止まってしまいます。「間違っててもいいから、まずはホワイトボードに絵を描いて話そう」。このスタンスこそが、セキュリティ文化を作る第一歩だと私は信じています。 この記事を読んで、「ちょっと面白そうだな」と思った方は、ぜひ次の設計レビューで 「これ、攻撃者に狙われたとして、起きたら困ることは何ですかね？」 と問いかけてみてください。 セーフィーでは、こうした「対話」を大切にしながら、セキュリティを「専門家だけの仕事」から「従業員みんなの仕事」に変えていこうとしています。 「一緒に文化を作っていきたい！」という方がいれば、ぜひカジュアルにお話ししましょう！ https://safie.co.jp/teams https://open.talentio.com/r/1/c/safie/pages/71628

この記事は Safie Engineers' Blog! Advent Calendar の7日目の記事です。 情報システムグループの松尾です。 以前、当ブログにて、情シスチームがアジャイル型の仕事の話へ変革した際の記事を書かせていただきました。 engineers.safie.link 今回はその続編として、アジャイルなチーム作りをさらに進める中で生まれた、 「もやもやリスト」を用いた継続的改善（カイゼン）の取り組み についてお話しします。 「隠れた負債」への気付き 心理的ハードルを下げる「もやもやリスト」 登録コストを下げる「仕組み」 「もやもや」から生まれた具体的なカイゼン 1. 入社フローにおけるプロセスの標準化 2. 障害対応の脱属人化（クロスファンクショナルなチームへ） リーダー任せにしない、持続可能な運用に向けて 「隠れた負債」への気付き スプリントを回す中で、日々の業務に埋もれがちな「小さな違和感」を放置することでも問題が発生することに気づきました。 「これは後で対応したほうがいいね」と会話には出るものの、タスク化されずに流れてしまい、忘れた頃に同じトラブルが発生して手戻りになることがありました。 これはアジャイルで言うところの 「透明性」 が欠けている状態であり、見えない技術的負債がチームに蓄積されている状態でした。 そこで私たちは、「完璧な解決策」を最初から求めるのではなく、まずは 「小さな違和感をチームで検知し、カイゼンする仕組み」 を作ることにしました。方針は以下の2点です。 ストックする（透明化）: 「やらなきゃ」「ちょっと気になる」を可視化する場所を作る 振り返る（検査と適応）: 定期的に見直し、再発防止の仕組みに変える 心理的ハードルを下げる「もやもやリスト」 この仕組みを回すため、Notionにデータベースを作成しました。 ここで重要なのは、 「タスク」として登録するのではなく、「もやもや」として登録すること です。 「タスク登録」と言われると、「完了条件は？」「期限は？」と考えてしまい、登録の心理的ハードルが上がってしまいます。 アジャイルなチームには心理的安全性が不可欠であるため、 「もやもやリスト」 という名前にすることで、未完成の状態でも気軽に放り込めるようにしました。 登録コストを下げる「仕組み」 運用も、徹底的にハードルを下げる工夫をしました。 手動登録: 朝会や雑談で出たものはその場で追加 Slack連携による自動登録: Slack上で課題らしき発言があった際、特定のスタンプを押すと自動的にNotionの「もやもやリスト」に起票される これにより、フロー情報として流れてしまいがちなSlack上の会話を、強制的にストック情報として蓄積する仕組みを整えました。 リストに入った項目は、2週間に一度のサイクルで棚卸しを行います。ここで初めて 「見守り（今は何もしない）」 か 「進捗中（タスク化する）」 かを判断します。 チームのリソースには限りがあるため、「もやもや」は全ての項目を改善するのではなく、現時点で は現状維持でも問題ないとチームで判断できたものは一旦、「現在の対応で継続する」 とすることもありました。 「もやもや」から生まれた具体的なカイゼン このサイクルを回すことで、実際にどのような改善が行われたかをご紹介します。 1. 入社フローにおけるプロセスの標準化 新入社員向けのITオリエンテーションについて、毎月の振り返りを通じてプロセスを改善しました。 作業フローの統一: 雇用形態ごとにバラバラだった手順を統一し、複雑性を排除（オペレーションミスの削減） フィードバックの反映: PC郵送時や代替機貸与時の「ヒヤリハット」をリストから拾い上げ、事前対策フローを追加 一度決めたルールを再確認し、発生した事象に合わせてフロー自体をアップデートし続けています。 2. 障害対応の脱属人化（クロスファンクショナルなチームへ） ネットワーク障害は、どうしても特定のエキスパートに依存しがちな領域です。しかし、アジャイルなチームは「誰かがいないと回らない」状態を良しとしません。 そこで、「もやもやリスト」に上がった障害対応を振り返り、 「従業員の業務を止める時間を極力短くする（MTTRの短縮） 」ことにフォーカスを絞った初動対応マニュアルを作成しました。 これにより、 ネットワーク専任担当者以外でも一次切り分けが可能になり、チーム全体での対応力が向上しました。 リーダー任せにしない、持続可能な運用に向けて 「もやもやリスト」の運用は、現在はグループリーダーである私がファシリテートすることが多いですが、長期的には チームメンバーの誰もが課題を発見し、自律的に改善サイクルを回せる（自己組織化）」状態 を目指していきたいと考えています。 今後は運用ルールのドキュメント化を進め、誰でもこのプロセスを運用できるようにしていきます。また、溜まっていく 「見守り」ステータスの棚卸しも定期的なイベントとして組み込み、「もやもやリスト」を健全に保つ仕組み を作っていく予定です。 来年以降も、こうした小さな「カイゼン」を繰り返し、変化に強い情シスチームを作っていきたいと思います。

この記事は セーフィー株式会社 Advent Calendar 2025 の12月6日の記事です。 こんにちは！ セーフィー株式会社のAndroidエンジニアのジェローム( @yujiro45 )です🎄 昨年、私が書いた「 AndroidでSceneViewを使って、3D/ARを表示する 」という記事で、アプリに3D/AR機能を簡単に実装できるライブラリを紹介しました。 しかし現在、SceneViewはメンテナンスされておらず、コントリビューターさんの GitHubでのコメント によれば新しいリリースの予定はありません。 出典：Github, https://github.com/SceneView/sceneview-android/issues/623#issuecomment-3097955731 (2025/11/12アクセス) 本記事では、 Android XR の新しいライブラリ「 SceneCore 」を使って、アプリ内に3D/ARを表示する方法を説明します。 Android XRとは Android XRのEmulator作成方法 SceneView vs SceneCore 3Dモデルを表示する SceneView SceneCore ExoPlayerの動画を表示する SceneView SceneCore まとめ Android XRとは Android XR は、AR/VR向けのヘッドセットやスマートグラス用に作られた、AI搭載のAndroid OSです。アプリを3D空間に表示・操作でき、開発ではCompose for XRやSceneCoreなどのライブラリを使って実装します。 Android XRのEmulator作成方法 Android XRは、XRが対応した端末でしか使えないので端末持っていない場合は、XRのEmulatorを作成しないといけないです。 セッションの作成は、Android XR デバイスでのみサポートされています。互換性のないデバイスでセッションを作成しようとすると、結果は失敗します。 https://developer.android.com/develop/xr/jetpack-xr-sdk/add-session Android StudioのデバイスマネージャーでXRのカテゴリがあります。そこで、XRのEmulatorを簡単に作成できます。 SceneView vs SceneCore 3Dモデルを表示する 💡この記事では、SceneCoreの最新版（執筆時点）である 1.0.0-alpha08 を使用しています。 SceneViewは最新版の 2.3.0 を使用しています。 SceneViewとSceneCoreの違いを理解するため、両方のライブラリで「ドロイド君」の3Dモデルを表示してみましょう！٩( 'ω' )و 出典：Sketchfab, https://sketchfab.com/3d-models/android-7c30eda007684abbb78ea4b99d22fc2c 　(2025/11/12アクセス) SceneView SceneviewexampleTheme { val engine = rememberEngine() val modelLoader = rememberModelLoader(engine) // 3Dモデル用のノードを作成 val modelNode = ModelNode( // 3Dモデルの読み込み (/res/raw) modelInstance = modelLoader.createModelInstance(R.raw.android) ).apply { // 3Dモデルの初期設定 scale = Scale( 1 / 40f ) position = Position( 0f ) } Scene( modifier = Modifier.fillMaxSize(), engine = engine, modelLoader = modelLoader, childNodes = rememberNodes { // モデルノードの追加 add(modelNode) } ) } 結果） 詳細は、以前の記事「 AndroidでSceneViewを使って、3D/ARを表示する 」で説明しているので、ぜひ読んでください〜😃 SceneCore Subspace { val session = LocalSession.current ?: return @Subspace val capabilities = LocalSpatialCapabilities.current var entity by remember(session) { mutableStateOf<GltfModelEntity?>( null ) } LaunchedEffect(session, capabilities.isContent3dEnabled) { // Full Spaceモードに切り替え if ( ! capabilities.isContent3dEnabled) { session.scene.requestFullSpaceMode() return @LaunchedEffect } // 生成は1回だけ if (entity == null ) { // 3Dモデルの読み込み (app/src/main/assets/models/android.glb) val model = GltfModel.create(session, Paths. get ( "models" , "android.glb" )) // 3Dモデルを作成する entity = GltfModelEntity.create(session, model).apply { // Positionを設定する setPose(Pose(Vector3( 0f , 0f , - 1.5f ), Quaternion.Identity)) // Scaleを設定する setScale( 0.2f ) } } } // Lifecycle管理 DisposableEffect(session) { onDispose { entity?.setEnabled( false ) entity?.parent = null entity = null } } } 結果）Android XRで3Dモデルを表示できました〜！ SceneViewとSceneCoreの主な違いは以下となります。 SceneView SceneCore 3D Space Scene Subspace 3Dオブジェクト Node Entity 3DモデルのPath /res/raw/ app/src/main/assets/models/ Lifecycle対応 rememberEngine / rememberModelLoader / rememberNodes を使用すると、Compose がライフサイクルを面倒みるためlifecycleを対応するのは不要です。 SceneCore の Entity は XR側で自動破棄されないため、Composableの終了やセッション切替時に DisposableEffect(session) 内で明示的に解放しないといけないです（メモリリーク防止のため）。 3Dオブジェクトの追加方法 Scene を使うと、中に Node を作成できます。 childNodes = rememberNodes { add(modelNode) } のように Node を追加すると、表示されます。 GltfModelEntity.create(session, model) を呼ぶと、3Dモデル用の Entity が作成され、 .add() しなくても表示されます。 3Dスペースモードを切り替える 不要 Android XRのEntityを使う時、 session.scene.requestFullSpaceMode() のように、Full Spaceモードに切り替えないといけないです。 ExoPlayerの動画を表示する 出典：Pexels,  https://www.pexels.com/ja-jp/video/13299023/ 　(2025/11/12アクセス) SceneView SceneViewで以前の記事「 AndroidでSceneViewを使って、3D/ARを表示する 」で書いた通りで、Materialを作成しないといけないです。 class ExoPlayerVideoMaterial( engine: Engine, exoPlayer: ExoPlayer, private val materialLoader: MaterialLoader, ) { // SurfaceTexture作成 private val surfaceTexture = SurfaceTexture( 0 ).apply { detachFromGLContext() } // SurfaceTexture→Surface作成 private val surface = Surface(surfaceTexture) // Textureのために、FilamentのStream作成 private val stream = Stream.Builder() .stream(surfaceTexture) .build(engine) // Texture作成 private val texture = VideoTexture.Builder() .stream(stream) .build(engine) // VideoTextureを使ったMaterialInstance作成 val videoInstance get () = materialLoader.createVideoInstance(videoTexture = texture).apply { setExternalTexture(texture) } init { // ExoPlayerのSurface設定 exoPlayer.setVideoSurface(surface) } } SceneviewexampleTheme { // ExoPlayerの設定 val player = remember { ExoPlayer.Builder(context).build().apply { repeatMode = Player.REPEAT_MODE_ALL } } // さっきの作成したExoPlayerVideoMaterial val videoMaterial = ExoPlayerVideoMaterial(engine, player, materialLoader) val videoNode = PlaneNode( engine = engine, // 動画は16:9のため size = Size( 16f , 9f ), // NodeのMaterialInstance設定 materialInstance = videoMaterial.videoInstance, ) ARScene( //... childNodes = rememberNodes { // ノードの追加 add(videoNode) }, ) } 結果） SceneCore ExoPlayerの .setVideoSurface() を使うと Surface に再生できます。SceneCoreには SurfaceEntity があり、 Surface を提供するため、ExoPlayerを接続してXRで再生できます。 Subspace { val session = LocalSession.current ?: return @Subspace val capabilities = LocalSpatialCapabilities.current val context = LocalContext.current // 作成した SurfaceEntity を保持 var surface by remember(session) { mutableStateOf<SurfaceEntity?>( null ) } // ExoPlayer はコンポーザブルのライフサイクルに合わせて1つだけ val player = remember { ExoPlayer.Builder(context).build().apply { repeatMode = Player.REPEAT_MODE_ALL } } // Lifecycleのため DisposableEffect(session) { onDispose { player.clearVideoSurface() player.release() surface?.setEnabled( false ) surface?.parent = null surface = null } } LaunchedEffect(session, capabilities.isContent3dEnabled) { // Full Spaceモードの切り替え if ( ! capabilities.isContent3dEnabled) { session.scene.requestFullSpaceMode() return @LaunchedEffect } if (surface == null ) { // SurfaceEntity val surfaceEntity = SurfaceEntity.create( session = session, pose = Pose( // Positionを設定する Vector3( 0f , 0f , - 1.5f ), ), // 動画は16:9のため shape = SurfaceEntity.Shape.Quad(FloatSize2d( 16f , 9f )), ) // Scaleを設定する surfaceEntity.setScale( 0.25f ) // 最初の黒塗りを避けるため、1フレーム目まで非表示 surfaceEntity.setEnabled( false ) // ExoPlayerをSurfaceEntityに接続して再生（res/raw/video.mp4） val uri = RawResourceDataSource.buildRawResourceUri(R.raw.video) player.setVideoSurface(surfaceEntity.getSurface()) player.setMediaItem(MediaItem.fromUri(uri)) player.prepare() player.addListener( object : Player.Listener { override fun onRenderedFirstFrame() { screen.setEnabled( true ) } }) player.play() surface = surfaceEntity } } } 結果）Android XRで動画を表示できました！🎉 動画を表示するために、 SceneView と SceneCore の主な違いは以下となります。 SceneView SceneCore ExoPlayerの表示方法 VideoNode がコメントアウトされているので、動画再生用の Material を作成必要があります。 SurfaceEntity を使うと、簡単に動画再生できます。 まとめ SceneViewはメンテナンスされていないので、SceneCoreは有力な代替です。書き方はおおむね似ており、Googleが作っているライブラリです。ただし前述のとおり、Android XRに対応したデバイスでのみ動作します。一般的なスマートフォンでは実行できませんが、ぜひEmulatorで試して遊んでみてください！ モバイルチームは開発する仲間を募集しています！ open.talentio.com open.talentio.com

この記事は  Safie Engineers' Blog! Advent Calendar  の5日目の記事です。 はじめまして、クオリティマネジメントオフィス QCDグループの稲員です。 この記事を書こうと思った理由ですが、 2025年1月にセーフィーのQAチームにジョインしてしばらく経ちましたので、おじさんのQAエンジニアがセーフィーのQAチームでどんなことに取り組んできたか振り返ろうと思いました。 チームのテスト活動を改善するためにどのような施策を実行してきたのかを共有することで、QAエンジニアの方々や開発チームの方々にとって何かしらのヒントになれば幸いです。 MagicPodでのテスト自動化 QAフローの改善 スクラムの改善 MagicPodでのテスト自動化 QAを担当することになったシステムはちょうどテスト自動化をやろうというフェーズだったため、そのキャッチアップから行いました。 採用しているツールが「MagicPod」というもので、下記のような特徴があります。 AIによるスクリプト作成支援＆自動修復 インストール不要な手軽さと、クラウドの端末やブラウザを使ってすぐにテスト作成可能 Webアプリ・モバイルアプリに対応 MagicPodは手軽さと直感的な操作ができるということで、こちらは低い学習コストで実装できるようになりました。MagicPodに詳しいメンバがオンボーディングをしてくれたのも大きかったです。 共有ステップや変数の活用、上手なデータ分割などテクニカルに使いこなそうとするとまた技術は必要になってきます。 一通りテストの自動化が完了できて、日々の運用にのせるというところが実現できたのはチームメンバの作業時間を日々固定で押さえたのが良かったと思います（強制労働） 日々固定の時間を確保して良かったポイントは以下です。 実装で困っているところを質問して解消しやすい 実装を進めるモチベーションになる 全件成功した朝は気持ちが良いです。鳥も猫もうれしそうです。 この「自動化の時間」があるおかげか、テスト自動化実装が終わった後に大きめの改修があってもテスト自動化は腐ることなく、運用を継続できています。 QAフローの改善 他に取り組んだのがQAフローの改善です。 部の目標であったテストにまつわる”工数削減”、”品質向上”、および現場の”不”の解消という軸で改善に取り組みました。 施策の一部 工数削減の方では自分でもっとこうしたいなと感じたことや、振り返りミーティングでメンバーから話題に上がったものを改善事項としてピックアップしました。 上記の改善が落ち着いてからはNotebookLMを使ってナレッジをまとめよう、非機能要件のテスト観点をシステマティックに盛り込もう、AIに不具合分析させよう、AIにテストケースレビューさせよう、などに取り組んでいます。 テスト設計で変えたところですと、改修内容によってはテストケースの粒度を大きくしてテストケース作成の工数を減らすようにしました。 テスト実施の方ではお客様はFirefoxをほとんど使用されていないという事がデータから分かったため、リグレッションテストは自動テストに任せて、手動でのテストを大きく減らしました。 テストの時間はいくらでもかけられますが、必要十分なテストを少ない時間でやるということを意識しています。 スクラムの改善 最後にスクラムの改善ということで朝のデイリースタンドアップの中に「チェックアウト」のコーナーを作るようにしました。 チェックアウトは”何を話しても良いよ”というコーナーで当番制です。 QA関係のお話をすることもあれば、好きな漫画や映画、最近話題の○○、おしゃれになりたいんやけどみんなどこで服買ってる、アタック25形式のクイズ勝負やろうや、猫の肛門から分泌される”肛門液（？）”がなんか足に付いててすごい臭いんですが、などなど朝から笑いが起きたりしていて楽しみな時間になっています。 これはチームの心理的安全性を高めるのに一役買っていると思います。 これらの取り組みを通じて、チーム全体が改善活動に対する意識を高め、より良いQAプロセスを追求する文化が醸成されつつあります。現状に満足せずに今後も継続的に改善を重ねていく予定です。 この数か月は、単にテストをするだけでなく、新しいチームとして成長するための基盤を築く期間でした。今後もより良いプロダクト品質とテスト品質を追求し、開発チームと共にお客様のカメラ管理を楽にする素晴らしいプロダクトを世の中に届けていきたいと思います。

この記事は  Safie Engineers' Blog! Advent Calendar  の4日目の記事です。 こんにちは。カルチャー＆コミュニケーション室の おかだみかこ です。 カルチャー＆コミュニケーション室は、社長直轄組織として社内外の広報活動等を担当しているチームです。「映像から未来をつくる」というセーフィーのビジョン実現に向けて「セーフィーカルチャー」を推進する活動も内包しています。 私は2025年4月、ちょうど当社の社員数が500名を超えたタイミングでセーフィーに転職しました。セーフィーが上場した2021年から比べると社員数は2倍以上。ビジネスも組織も圧倒的なスピードで成長している会社に入社したなあと思ったのを覚えています。 一般的に、組織が拡大すると「隣のチームが何をしているか分からない（サイロ化）」や「経営の意図が伝わらない」といった課題が生まれがちです。 多くの企業では社内報といえばテキストが多いと思いますが、私たちは「映像データ」を扱うテック企業として、テキストでは削ぎ落とされてしまう「熱量」や「文脈」こそが重要だと考え、「動画」による社内コミュニケーションを行ってきました。ということで、今回は私が担当している社内動画メディア「空フク」についてご紹介します。 「空フク」とは 現状把握のためのアクション 現在までに実施したこと 信頼関係をレバレッジする「公式発信」よりも「知っている人」 「動画の弱点」を補完する＋αの要約テキスト コミュニケーションは続けること 「空フク」とは 端的にいうと、「空フク＝動画社内報」と考えていただくとイメージがしやすいかと思います。スタートしたのは2023年10月で、今まで2年以上に渡り継続して社内向けの発信を続けてきました。 「空フク」は通称で、正式名称は「空飛ぶフクロウ~Safie's company newsletter~」です。セーフィーのシンボルマークでもお馴染みの「フクロウ」は知恵の象徴とされています。「空フク」の名前には、社員一人ひとりが持つ知恵をシェアし、お互いの知恵の循環を通じて、社内コミュニケーションを活発にしていきたいという想いが込められています。 空フクは2つのカテゴリで構成されています。 Sadoxサロン 社長の佐渡島さんがスピーカーとして語るコンテンツ フクロウたちの知恵泉 社員の活躍、部署の取り組みを語るコンテンツ 左：Sadoxサロン「2030年目指すこと_ストレッチ組織の課題と解決にむけて」 右：フクロウたちの知恵泉「デザインセンター_ロゴデザインの思想と、セーフィーがつくるデザインとは」 現状把握のためのアクション 私が担当になってまず行ったのはアンケートです。社員の「空フク」活用状況を知り、今後の企画において参考とするために行うことにしました。 結果として、90％以上の人が認識しており、社員の2/3は何らかのコンテンツは見たことがあるというポジティブな回答が得られました。一方で「見たことがない！」という社員も少なからずいる状況がわかりました。見る機会がなかった人は大きく分けると以下の3つに分類されることも把握できました。 忙しく見る時間がない 更新タイミング不明 そもそも存在を知らなかった 届ける相手である「社員」の皆様の声を確認したことで、実際に活動の方向性を決めることにも繋がったため、初手でアンケートをとったことは非常に有用でした。 現在までに実施したこと アンケートを実施した5月から現在まで、まずは短期目線ですぐにできることからアクションを行ってきました。大きく分けると「告知の工夫」と「さまざまな社員が登場する企画」です。このブログでは「告知の工夫」にフォーカスしてもう少し詳しくお話ししたいと思います。 信頼関係をレバレッジする「公式発信」よりも「知っている人」 突然の話ですが、友人から手紙を渡されたとしたら、そりゃ必ず目を通しますよね。それと同じで同じチームや関係性の深いメンバーからのSlackは目につくと思うのですが、あんまりよく知らない人からの全体に向けたSlackは見落としがちではないでしょうか。 「空フク」の告知は社内のSlackを活用して発信していますが、全体メンションでの私からの告知は、情報の「ノイズ」として処理されてしまう可能性があると感じていました。 そこで着目したのが、社内における「ソーシャルグラフ（人間関係のつながり）」の活用です。担当者から言われるより、普段関わりのある同僚から「出演したので見てください」と言われた方が、圧倒的に視聴意欲が湧くはず。 アナログな手法ですが、「出演者に告知協力をお願いする」というフローを組み込むことで、「点」の発信を「面」の広がりに変える工夫を取り入れました。 最近も、出演者からではないのですが、社員の方が面白いよとご自身のチームに発信していただいたことでアクセスが急増したケースがありました。そういう循環をもっと増やしたい。そのための前提としては社員の皆様が「これいい！」と思ってもらうコンテンツが重要です。企画自体も力を入れていますが、引き続き良いコンテンツ作りには特に時間を割いていきたいと感じました。 「動画の弱点」を補完する＋αの要約テキスト 映像は圧倒的に得られる情報量が多いのがメリットです。一方で、「忙しい時に手を止めて動画を見るのは正直しんどい。倍速だとしても」というのは正直あるのではと思います。 そのため、空フクNotionページで公開する際に、興味があるトピックかどうかを数秒で判断できるように「動画で話されていること」を箇条書きで添えるようにする工夫もはじめました。 また、要約の作成にはNotebookLMに編集した映像を読み込ませて、そこからテキスト案を検討することで効率化も進めています。 コミュニケーションは続けること 担当を引き継ぐ際に前任担当者のコメントで最も印象に残ったことは「継続して発信し続けることを大事にしてきた」という話です。首がもげそうになるくらい同意をしました。それは、私もコンテンツの発信は継続して続けていくことが大事だと思っていたからです。 現在、セーフィーは開発本部を含めた5つの本部、500人以上の社員がいる会社に成長し、ビジネスも組織も更なる飛躍に向けてみんなで歩みを加速させています。 最後になりましたが、社内の戦略や開発秘話なども含まれるため、「空フク」を見ることができるのは社員だけの特権です。セーフィーのお仕事にご興味がある方は 採用サイト もぜひご覧ください。 safie.co.jp この記事を読んでいただいた方が、仲間となり動画を見たり、はたまた出演者として登場したりとする日が来るのを楽しみにしています。 今後もより「面白い」「役立つ」「楽しい」空フクの発信を期待していただけると嬉しいです！

はじめに この記事は Safie Engineers' Blog! Advent Calendar の3日目の記事です。 こんにちは、技術広報のたかぎ（ @hitsan ）です。 2024年の中盤から技術広報をはじめ、2025年はセーフィーにとって 「技術広報活動を本格始動させた年」 という、非常に大きな節目の1年となりました。 これまでも技術発信は行ってきましたが、今年は発信数を増やすことに注力しました。 本記事では、セーフィーの技術広報が掲げるミッションと、2025年に取り組んだ具体的な施策について振り返ります。 はじめに セーフィーにおける技術広報のミッション ファンを増やし、すごいを広げる 2025年の活動 1. イベント登壇数を増やしたよ 2. 技術広報専用Xアカウントをつくったよ 直近のイベント情報 BASEとセーフィーが語るバックエンド開発の技術的負債解消への道のり 生成AIで業務を改善しNight！ さいごに セーフィーにおける技術広報のミッション ファンを増やし、すごいを広げる 技術広報として掲げている最大のミッション、それは 社内外にセーフィーのファンを増やすこと です。 この言葉には2つの意味が込められています。 「セーフィーって技術的に面白い会社だね」と認知してもらうこと。 エンジニア自身が自分たちの開発しているプロダクトはすごいと胸を張れる状態を作ること。 どれほどがプロダクトが良くても伝わらなければファンは増えません。このミッションを達成するために、以下のような3年計画を策定しました。 年度 フェーズ 2025年 発信文化の醸成 2026年 聞き手を意識した発信 2027年 テックブランドの確立 2025年の活動 2025年のテーマは「土壌づくりと発信文化の醸成」です。 文化を作るためには、まず行動の総量を増やす必要があります。そこで打席数を増やしました。 発信数（打席）が増えれば、「自分たちは技術発信をする組織だ」という認識が生まれる 第三者の目に触れることで、「自分たちが当たり前にやっていることは、実はすごいことなんだ」と気づける これらを実現するために、具体的に実行した施策をご紹介します。 1. イベント登壇数を増やしたよ 今年はイベントへの参加・開催数は昨年と比較して2倍になりました。 2024年までは依頼があれば登壇するというスタンスでした。2025年からは他社と共催してイベントを企画するようになりました。 企画から行うことで、ターゲット層や伝えたい技術テーマをコントロールできるようになり、以下のようなトピックを深く掘り下げることができました。 映像解析アプリケーションの開発プラットフォーム構築の紹介 若手エンジニアの活躍 大規模プロダクトにおける技術的負債の解消 企画から携わることで、参加者からのフィードバックをエンジニアへ直接還元するサイクルも作れています。 2. 技術広報専用Xアカウントをつくったよ 先月、セーフィー技術広報アカウント（ @SafieDev ）を新たに開設しました。 はじめまして！このアカウントは、セーフィーの技術情報やエンジニアの取り組みを発信するアカウントです🎉 エンジニアの皆さんが気になる情報をお届けします。 ぜひお気軽にフォローしてください！ #セーフィー #エンジニア #開発者 #技術広報 — セーフィー技術広報 (@SafieDev) 2025年11月7日 これまでは企業公式アカウントから発信していましたが、以下の理由から独立させました。 エンジニア、PdM、デザイナーに特化した情報を届けたい エンジニアの日常的な取り組みや試行錯誤も発信したい 企業の公式アカウントよりも高頻度で投稿したい アカウントを分けたことで、テックブログの更新情報やイベント情報に加え、開発現場の空気感が伝わるような発信を強化しています。ぜひフォローをお願いします！ 直近のイベント情報 12月は注目のイベントを2件開催します。ぜひご参加ください。 BASEとセーフィーが語るバックエンド開発の技術的負債解消への道のり 明日、12/4(木)にBASE株式会社様と共催でバックエンドの技術的負債にフォーカスしたイベントを開催します。セーフィーからは、大規模リアーキテクチャの取り組みについて紹介予定です。 safie.connpass.com 生成AIで業務を改善しNight！ 12/15(月)には、生成AIを活用した業務改善イベントを開催します。 こちらはLTやセッションではなく、ワールドカフェ形式を採用。参加者全員で業務改善のアイデアをディスカッションする参加型イベントです。 safie.connpass.com さいごに 2025年の活動を振り返りましたが、正直に言えば、全員が自然と発信する文化にはまだ到達できていません。 今年はイベントという場を用意し、打席数を増やすことには成功しました。しかし、それが組織全体の習慣として定着し自走していくまでには、まだいくつものハードルがあります。 まだまだ手探りですが、これからも走り続けるので2026年のセーフィーの技術発信にも、ぜひご期待ください。

この記事は Safie Engineers' Blog! Advent Calendar 2日目の記事です。 はじめに 私にできること 新たに作ったもの アプリの紹介 作ったきっかけ 作り方 AWS Bedrockでお題を生成 Next.jsでUI実装 AWS Amplifyでデプロイ 終わりに はじめに こんにちは！セーフィーに25新卒で入社し、AI開発部に配属された川上です。 学生時代は研究で、人の歩き方を解析するAIの開発をしていました。 そして配属前に行われた研修では、社内備品を管理するアプリTreasure Collectionを開発しました。（Treasure Collectionの記事は後日掲載されるのでぜひご一読ください。） この記事では私が新たな技術領域を身に付けるためにアプリの開発に挑戦した話をしたいと思います。 私にできること 先に述べたように、学生時代はPythonをつかって映像の研究をしていました。そして研修のTreasure Collectionの開発では、入社するまでに体験したことがなかったフロントエンド領域を担当しました。研修を終えて、フロントエンドとバックエンド（データ処理）の領域を経験したエンジニアになれました。 しかしながら、インフラ領域が分からないという気づきも得ました。 Treasure CollectionはWebアプリで、デプロイなどのインフラ回りはすべてチームメンバーが実装してくれました。フロントエンドの技術は身につけられましたが、アプリをユーザーに届ける方法が分からないという状況になりました。 新たに作ったもの これから、研修を終えた後に開発した ice-breaker というWebアプリの紹介をします。このアプリを作ったことで新たな技術領域を体験でき、ユーザーに作ったものを届けられるようになったのでそこを共有できればと思います。 アプリの紹介 ice-breakerはミーティングなどの冒頭で行うアイスブレイク・チェックインのお題を提供します。 アイスブレイクとチェックインは少し異なるものですが、大まかに以下のように説明できます。 アイスブレイク、チェックインとは 目的：集まりの冒頭で、参加者の間の緊張をほぐし、場に活気や一体感を生み出すこと。 特徴：「場」の雰囲気づくりに焦点を当てる。 多くの場合、ゲームや簡単なアクティビティ形式で行われる。 参加者同士が気軽に話せるきっかけを提供し、本題に入る前の心理的な障壁を取り除く。 このアイスブレイク、チェックインはセーフィーに入社してから何度も行ってきました。そしてこの度、アイスブレイク、チェックインに役立つアプリを開発しました。 アプリにアクセスすると次のような画面が表示されます。 画面左側の“話題を生成”ボタンを押すとボタンの下にお題が表示されます。 参加者一覧に名前を入力し”追加”ボタンを押すと参加者が追加されていきます。 “次の発表者”ボタンを押すとボタンの左に次の発表者が表示され、発表済みに発表者が追加されます。 “次の発表者”ボタンを何度か押して、全員が発表済みに追加されると”終了！全員話し終わりました”と表示されます。 作ったきっかけ 配属前に行っていた研修の週次定例の冒頭に、10分程度のアイスブレイクを行っていました。 アイスブレイクのお題はその都度考えていたために、お題に困ることがありました。 また進め方はお題を考えた人が最初に発表して、発表した人が次の発表者を指名するという方式をとっていました。この進め方はアイスブレイクが盛り上がるいい方法でした。しかし、「全員発表した？」と確認したり「次誰にしよう」と悩んだりして、時間を使ってしまうためにアイスブレイクの予定時間を少し超えてしまうという問題もありました。 行っていたアイスブレイクのよさを保ちながら、困りごとを解決するためのアプリを作ってみようと思ったことがこのアプリを作ったきっかけです。 作り方 ここからはアプリの作り方を説明します。 AWS Bedrockでお題を生成 まず、アプリの核となるお題の生成についてです。 お題の生成は生成AIで行っています。生成AIはAWS Bedrockから利用しました。AWS Bedrockにアクセスし、APIキーを発行します。 Next.jsでUI実装 UIはNext.jsで実装しました。Next.jsを使った理由は研修で唯一身につけたフロントエンドの技術スタックだからです。 アプリの構成は以下のようになっています。 src/app/ ├── page.tsx # メインUI（クライアントコンポーネント） ├── api/ │ └── bedrock/ │ └── route.ts # Bedrock API呼び出し（サーバーサイド） └── components/ ├── addNames.tsx # 参加者追加コンポーネント └── participants.tsx # 参加者表示コンポーネント UIはシンプルなのですべての紹介は控えますが、工夫したことを2つ紹介します。 同じ話題が表示されないようにプロンプトを改善 api/bedrock/route.ts ではAWS BedrockのAPIにプロンプトを含んだ、API Requestを送信しています。そのコードは以下のようになっています。 import { BedrockRuntimeClient, ConverseCommand } from "@aws-sdk/client-bedrock-runtime"; import { NextRequest, NextResponse } from "next/server"; export async function POST(request: NextRequest) { try { const url = "xxx"; const history = (await request.json()).history || []; const payload = { "messages": [ { "role": "user", "content": [{"text": "ちょっと変わったアイスブレイクの話題を1つ返して。" + "過去の話題履歴: " + history.join(", ") }] } ], "inferenceConfig": { "temperature": 1.0, "maxTokens": 500, "topP": 1.0, } }; const response = await fetch(url, { method: "POST", headers: { "Content-Type": "application/json", "Authorization": `Bearer ${process.env.NEXT_PUBLIC_API_KEY}` }, body: JSON.stringify(payload) }); const data = await response.json(); return NextResponse.json({ output: data }); } catch (error) { console.error("API Error:", error); } } 過去の話題履歴を page.tsx と連携してプロンプトに含めながら話題を何度か生成したときに同じ話題が表示されないようにしました。 Next.jsのサーバーサイドからAPI Rrequestを送信 以下のコードは page.tsx に実装した、話題を生成するときに実行される関数です。この関数ではまず api/bedrock にAPI Requestを送信します。これはNext.jsのサーバーサイドで実装されているAPIです。 const onGenerate = async () => { setloading(true); const data = await fetch("/api/bedrock", { method: "POST", headers: { "Content-Type": "application/json", }, body: JSON.stringify({ history: history, }), }) .then((res) => res.json()) .then((data) => { setResult(data.output.output.message.content[0].text); setHistory([...history, data.output.output.message.content[0].text]); }) .catch((error) => { console.error("Error fetching data:", error); }); setloading(false); }; 先に説明したようにAWS BedrockへのAPI Requestの送信は api/bedrock から行われます。 このようにAPIを経由してAWS Bedrockを利用していることには理由があります。それはAWS Bedrock への API Requestの送信はフロントエンドから行えないからです。セキュリティ上の理由でその仕様になっています。 今回開発に用いたNext.jsでは別途バックエンドサーバーを立てずにサーバーサイドにAPIエンドポイントを立てることができます。図らずも、開発中に生じた課題が解決され、スムーズな開発を進めることができました。 AWS Amplifyでデプロイ ローカル環境で動作確認を完了したら、デプロイの準備です。 デプロイはAWS Amplifyで行いました。AWS Amplifyを使って想像以上に手軽にデプロイを行えました。 AWS AmplifyへはGithub経由でアプリをデプロイできます。 作成したアプリをGithubへpushしたら以下のAWSのマニュアルに従って設定を行います。 https://docs.aws.amazon.com/ja_jp/amplify/latest/userguide/setting-up-GitHub-access.html#setting-up-github-app 設定後にAWS Amplifyにアクセスし、以下の流れでAWS Amplify上にアプリを作成します。プロバイダーはGithubを選択しました。 ここまで進めて、問題がなければすべてのアプリから、デプロイが始まっていることが確認できます。5分程度待つと、デプロイ済みに変わっていました。 この時点でもアプリはデプロイされアクセスすることができますが、もう一つ必要な設定があります。 環境変数の設定です。 すべてのアプリから、デプロイしたアプリをクリックします。サイドメニューのホスティング、環境変数を選択して、以下の画面に遷移します。 ここで変数はローカル環境で使う.envファイルで決めた変数名です。値は取得済みのAWS BedrockのAPIキーを入力します。 ここまで行うとアプリはローカルと同じように動作します。デプロイ・リリースの完了です。 終わりに この記事では私が初めて自身の力でデプロイを行ったアプリの紹介をしました。 アプリを作ってみて考えたことが大きく2つあります。 1つ目はソフトウェアサービスの理解度が上がったことです。これまではどうやったらサービスとして動作するんだろうという漠然とした疑問を抱えながら開発などを行っていました。そこをどうやったらいいか、手段を1つでも知れたことはとても良いことだと思います。 2つ目は別のAWSサービスも利用したいと思ったことです。私はAI開発に長い間携わってきましたが、それらはローカル環境のマシンで動作させるだけでした。これを機にオリジナリティを持ったAIを使ったアプリをユーザーに届けてみたいと思いました。 私がセーフィーに入社して8カ月経ちましたが、その間新しい技術領域を体験し身に着けながら課題解決に取り組めています。この記事を読んでいただいた人にとって、セーフィーで働きながらどのように技術を身に着け成長できるかが伝わると幸いです。

この記事は Safie Engineers' Blog! Advent Calendar  1日目の記事です。 はじめに そもそも「1on1」とは？ 定義の再確認 1on1 のゴール（ありたい姿） 人にフォーカスした対話型1on1のすすめ 具体的な質問例１：「最近どう？」をより良くする工夫 具体的な質問例２：未来志向への誘導 1on1 は組織開発の最前線 最後に はじめに セーフィーの VPoE 兼 開発本部 エンジニアリングオフィス 室長の武田です。 2023年にセーフィーに入社し、エンジニア組織の組織開発に取り組むエンジニアリングマネージャーとして活動しています。セーフィーでは創業当初から 1on1 文化 が根付いており、私自身2025年には600件以上の1on1を実施しました。前職を含めたエンジニア組織開発の経験と、コーチングや本質行動学などの学びを活かしたトライ＆エラーから得た、1on1の本質をご紹介します。 そもそも 「1on1」とは？ 定義の再確認 私が考える1on1の定義は以下の通りです。 💡 1on1とは？ 1on1とは、メンターとメンティーが定期的にマンツーマンで行うミーティングのこと。 人事評価を目的とした面談とは異なり、 人の成長促進と組織の活性化 を主な目的とする。上司・部下の関係性に限らず、人と組織の成長を促すための対話の場である。 この1on1の定義には 「これが正解」という型はありません。 1on1では「業務の話はすべきではない」という一般的な風潮もありますが、私はその限りではないと考えます。 なぜなら、メンティーが目の前の業務で困っているのに、それを解決してくれるかもしれない人に聞けないのはフラストレーションがたまるだけ。無理にキャリアの話に誘導するより、 メンティーが本当に求めている話 をすることが、結果的に成長につながります。 1on1 のゴール（ありたい姿） では、目指すべき1on1のゴール（ありたい姿）は何でしょうか。 それは 「次も1on1をしたい」 と思ってもらえる状況を作ることです。 1on1は、一度きりのイベントではなく 継続してこそ意味のあるもの になります。 前向きさを維持し、対話を重ねることで初めて、人の成長と組織の活性化という目的に近づけます。 メンターのスタンス メンティーの状況に合わせて臨機応変に対応する 具体的な行動 業務の話も、キャリアの話もする。コーチングもすれば、ティーチングもする 重視すること その瞬間や1on1直後に心地よい時間を作ることではない、時にはネガティブなフィードバックも必要 目指す状況　 対話後、時間経過と共に気づきがあり、行動変容を促し、結果が伴うこと。そして、対話が継続できていること。 人にフォーカスした対話型1on1のすすめ 「次もやりたい」と思ってもらうためのコツ、それは 「対話しやすい状況」 を作ることです。 対話しやすさの鍵は、「事（コト）」ではなく 「人（ヒト）」にフォーカス した質問をすることにあります。 ✅ 「事」への質問 vs. 「人」への質問 例えば、メンティーが「釣りに行ってきました」と話した場合の質問例です。 質問の焦点 具体的な質問例 メンティーの受取られ方 事　(コト)　 - どこ行きましたか？ - 釣れましたか？　　　　 事実の深堀り 人　(ヒト)　 - 楽しめましたか？ - 釣り好きなんですか？ 自分に向き合ってくれている と感じ、話しやすくなる 人の 感情（楽しい、好きなど）に寄り添う 質問を意識するとより話がしやすくなります。 例えば仕事で失敗したときはなぜ失敗をしたのか？ではなく、その時どう思った？どう感じたか？なぜそう感じたのか？メンターの自分はどう思ったか（例えば悲しかったとか）など、お互いの感情を深堀しシェアすることでより人に向き合えるようになります。 具体的な質問例１：「最近どう？」をより良くする工夫 1on1 の初めに「最近どう？」から始まることはよくあると思います。 ただ、この「最近どう？」だけでは、少しもったいないです。 最初の導入として、ぜひ メンターの所感 を付け加えてほしいです。 そうするとメンティーはより話しやすくなります。これは、 メンターの気持ち（感情）を先に伝えている ことで、共感を生みやすくスムーズな対話につながる効果があります。 より良い質問例 ポイント 最近どう？ 〇〇定例での××の発表良かった。内容もだけど イキイキ話していて感動したよ ポジティブな所感 を伝え、話すきっかけを作る 最近どう？ 残業時間が多くなっているようなので ちょっと心配 懸念点（心配） を伝え、安全な場で話すことを促す ❌ 注意すべき質問例 「最近どう？元気がないように思うけど大丈夫？ 何かあった？ 」は良い質問ではありません。 なぜなら「何かあった？」は、 事の深堀り につながるからです。本当に元気がないときは、日常の小さなことの積み重ねであることが多く、「特別なことはありません」という回答で対話が終わってしまう可能性があります。 　　〇 最近どう？元気がないように思うけど大丈夫？ 心配です。 心配している気持ちを正直に伝えて反応を待ちましょう。 補足 ちなみに私は1on1が始まる前にその人のGoodポイントを探すという事前準備をよくやります。ネガティブな情報は広がりやすいですが、ポジティブな情報はなかなか表に出てきません。1on1でポジティブ情報が交換できれば組織全体の雰囲気にもつながります。ぜひ、EMはポジティブ情報を常に拾って1on1につなげてほしいと思います。 具体的な質問例２：未来志向への誘導 1on1は過去の振り返り（ふりかえり）になりがちで、ワクワクしにくい傾向があります。過去の結果は分かりきっているからです。 できるだけ 未来の話 に誘導しましょう。 質問例 目的 前回から今回までの 自己満足度、何点 ありますか？（100点満点で） メンティーの現状認識を引き出す （例：60点と回答）40点足りていないけど、その 40点を増やすためには何が必要ですか？ 私も一緒に協力できることありますか？ 次回までの Next Action をメンティー主体で決め、 未来の話 へ誘導する ここでのポイントは、メンティー側だけでなく、 メンター側のNext Actionも決めること （小さなことでOK）。お互いのコミットメントにより、一体感が生まれます。 1on1 は組織開発の最前線 会社や組織は人の集まりであり、 組織＝人 です。 1on1は、その人のことを知るための 一番の手段 であり、組織開発の最前線です。1on1が機能することで情報が流通し、組織が活性化するきっかけになります。 ぜひEM（エンジニアリングマネージャー）の皆さんには、この1on1を使いこなしてほしいと思います。 正解がないからこそ面白い！ この記事が、あなたの1on1を楽しむきっかけになれば幸いです。 📝 まとめ：人に向き合う1on1の5つの要点 1. 基本スタンス　 1on1のやり方に正解はない (メンティーの状況に臨機応変に対応する) 2. 目的　　 人（と組織）が成長するために、人（と組織）に向き合う時間。 3. ゴール　 「次も1on1をしたい」 と思ってもらうこと（継続による成長と成果） 4. コツ 　　 「事」ではなく 「人」にフォーカス した質問で、より 共感と気づき を与える 5. 価値 　　 組織開発の最前線として、 情報流通と組織活性化 のきっかけとなる 6. 願い　　 1on1 自体を楽しもう！ 最後に 本記事では、私が取り組んでいる1on1の実践の一部をご紹介しました。 1on1 は奥深く自分自身もまだまだ足りていない部分があり、常にふりかえりを実施中です。 また、ポイントはほかにもある（例えば、1on1 の情報をどう他の人にシェアして組織変革に使っていくか）と考えており日々奮闘中です。またいつか別の機会にご紹介できればと思います。 最後に宣伝です！セーフィーでは 一緒に働く仲間を募集中 です！ 少しでもご興味を持っていただけたら、ぜひ以下の 採用サイト を覗いてみてください。

はじめに こんにちは。セーフィーでサーバーサイドエンジニアをしている金成です。 本記事は、ffmpegを初めて使う方や、360度カメラのデワープ処理について学びたい方を対象にしています。専門的な知識は不要ですので、ぜひお気軽にお読みください。 セーフィーでは、半天球カメラなど、魚眼レンズを用いて広範囲を撮影する360度カメラの映像も取り扱っています。そのため、このようなカメラの画像や映像をデワープ (歪みを補正し、歪みの少ない映像に変換すること) するユースケースが存在します。仕事をする過程で、ffmpegのビデオフィルターを使った変換について調べたのでこちらで共有いたします。 はじめに ffmpegとvfオプションについて デワープの具体的な手順 まとめ ffmpegとvfオプションについて ffmpegは、動画や音声を記録・変換・再生するソフトウェアで様々な処理を行うことができます。その中でも、vfオプション(video filter オプション) は、入力に対し、映像を拡大する、一部分を切り取る、色を補正するなどの処理(フィルター) を適用することができる機能です。 簡略化すると、下記のようなシンタックスでオプションを指定することができます。 -vf <フィルタ名>=<フィルターごとのオプション> (実際にはもっと複雑な指定が可能です。詳細は公式サイトをご参照ください。 https://ffmpeg.org/ffmpeg-filters.html) 例えば、cropフィルターであれば、下記のようなコマンドで画面の一部を切り取った映像を作ることができます。 ffmpeg -i input.mp4 -vf crop=500:500:100:100 output.mp4 vfオプションの中には、v360フィルターがあり、360度カメラで撮影された魚眼などの映像をデワープされた映像に変換することができます。 デワープの具体的な手順 360度カメラの映像と環境の準備 今回は、ffmpegコマンドを使った360度カメラの変換について説明します。 利用するツールのバージョンは下記になります。 ffmpegのバージョンは7.1.1です。 デワープのためのffmpegコマンドの記述 デワープのためのffmpegコマンドの記述 今回は、v360フィルターを使って、半天球カメラなどで撮影された「魚眼 (fisheye)」形式の映像を歪みを補正した映像に変換します。 v360フィルターは下記のようなシンタックスで構成されており ‘v360=<入力の形式>:<出力の形式>:<key=valueで指定したオプション> といった形式で指定できます。 例えば、下記のコマンドであれば指定したオプションで、魚眼 (fisheye) の映像からデワープされた通常の映像に変換されます。 ffmpeg -i input.mp4 -vf ‘v360=fisheye:flat:v_fov=50:yaw=50’ output.mp4 v360フィルターでは、下記のような入力/出力先が用意されています。 e / equirect => Equirectangular projection flat / gnomonic / rectilinear => regular video fisheye => 魚眼 pannini => Pannini projection. and etc 入力/出力形式ごとに必要なパラメーターが変わり、様々な変換を行うことができます。 v360のフィルターでは、共通でyaw/pitch/roll などのカメラの視点をコントロールするオプションや、カメラの回転を制御するオプションがあります。 今回使用する flatフィルターでは、特にデワープ後の調整を行うため、出力するカメラの画角を以下のオプションで制御できます。 v_fov (垂直画角) h_fov (水平画角) d_fov (対角画角) これらのオプションを利用することで、変換後の映像を細かく調整することが可能です。 コマンドの実行例 例1: 上下の振り向け ffmpeg -i input.mp4 -vf v360=fisheye:flat:v_fov=50:pitch=<角度> output.mp4 例2: 左右の振り向け ffmpeg -i input.mp4 -vf v360=fisheye:flat:v_fov=50:yaw=<角度> out.mp4 例3: 右に振り向けた映像の左半分だけを切り取る ffmpeg -i input.mp4 -vf v360=fisheye:flat:v_fov=50:yaw=30,crop=iw/2:ih:0:0 output.mp4 まとめ このように魚眼の映像など360度カメラで撮影した映像は、簡単にデワープすることができます。画像や動画の変換に役立てていただければ幸いです。 セーフィーでは、このような映像解析技術を活用し、より高度なサービスを提供しています。興味をお持ちいただけましたら、ぜひ採用情報もご覧ください。

はじめに こんにちは、データドリブン推進室でデータエンジニアをやっている鶴です！ みなさん、LightdashのTable calculation機能って使ってますか？ 自分はLightdashを触っていて[+Table calculation]という表記を見かけた際に 「Table calculationってことは表計算機能のことか〜 Tableauとかにもある出力した結果データの中で集計したりするやつかな あると便利だよな…そのうち使う機会くるっしょ〜」 みたいなこと考えてあまり触らずスルーしてました… 同じような方もいらっしゃるのではないでしょうか？ 実はLightdashのTable calculation機能はちょっと面白い機能になっているのでここでご紹介したいと思います！ はじめに Table calculationを触ってみよう テンプレート機能もあります 実はこれだけじゃなかったTable calculation 最後に We are hiring! Table calculationを触ってみよう まずはQuerying from tablesから見たいテーブルを選択し、Resultの右上にある[+Table calculation]を押してみると… こんな画面が出てきます。 つまり出力したデータを使ってSQLを書いて集計する、という感じなんですね。 やはり表計算といえばウィンドウ関数ということで書いてみます！ 今回サンプルで用意したスーパーマーケットデータで売上前日比を作ってみます。 ※本記事に登場する「さくらマート」は、サンプルデータ用に作成した架空の名称であり、実在のいかなる店舗・団体とも一切関係ありません SQLはこんな感じです。編集画面で文字を入力するとサジェストしてくれるので便利です。 ${sample_supermarket_sales.sum_of_total_price} / LAG(${sample_supermarket_sales.sum_of_total_price} OVER(${sample_supermarket_sales.sale_date_day})) このデータはソートを設定しているので一旦ORDER BYは記載せず進めてみます。 フォーマットはパーセント表示にしましょう。 保存して実行するとこんな感じになりました！ またこの作った項目を直接フィルターに設定することができます！ 右上のボタンを押すと[Filter by 売上前日比]があるので押してみると… フィルター欄に追加されました！ これを使って前日売上比100%越えの日を出してみる、なんてこともできます。 テンプレート機能もあります ウィンドウ関数はSQLに慣れていない方だと正直難しい部分がありますよね… ですがLightdashにはテンプレートが用意されてます！ [Sum of total price]の右上のボタンを押すと、Add quick calculationにテンプレートがあります。 Percent change from previous(前からの変化率)をクリックしてみます。 項目が自動で作成されました！ 一応内容を確認するため項目右上を押し、Edit calcultationをクリックします。 内容的には先ほど自分が作ったクエリの内容に近いロジックがあり、それに対して1を引いている形になります。 なお、注意して欲しいのがLAG関数のORDER BYの箇所がDESCになっています。 日付で昇順にしたいためここは消しておきましょう。 ここは見たいものによると思うので適宜調整してください！ 実行した結果はこうなりました。正直こっちの方がわかりやすいですね！w このようにテンプレートをうまく使うとサクッと作れます。 他にもテンプレートはあるのでぜひ公式ドキュメントの 解説ページ をご確認ください。 また今の時代はChatGPT先生やGemini先生などに聞けばわかりやすく教えてくれますし、作ってくれます。有効に活用していきましょう！ 実はこれだけじゃなかったTable calculation さて、ここまで触ってきたTable calculationですが察しの良い方はこのことに気づいているかもしれません… 　SQLで書けるってことはSQLでやれることは割と何でもできるのでは…？ そうです、何でもできます。 たとえばこのようなCASE文を書いてバナナフラグを立てることもできます(Result typeはbooleanにしてます) ストアと商品の文字列を結合するようなテキスト計算もできます(Result typeはstringにしてます) なんか自分が思ってた表計算と違う…！！！！ 集計した項目をさらに好きなようにデータ加工・計算できるので面白いと思います。 また少し前の Lightdashアップデート で作成した表計算項目を再利用できるようになりました。 つまりこうやって先ほど作成したバナナフラグとストアと商品の項目も合わせることが可能です。 作成した表計算結果をさらに計算して…みたいに広げていけるので柔軟性が上がっていいですね！ 最後に Table calculationは定義されたメトリックで対応できなかった集計やデータ加工をカバーする機能となっていて利用される方はこういう機能があると認識されておいた方が良い機能だと思います！ ただ公式ドキュメントにも 記載 がありますがこのTable calculationは一時的なニーズに対応するものとしては良い機能ですが、繰り返し再利用されている場合はdbt側の定義に追加して管理するようにした方が良いので管理者は適宜チェックしておきましょう。 We are hiring! 現在、データドリブン推進室では データエンジニア/アナリティクスエンジニアを大募集中 です！ セーフィーのデバイスやアプリケーションからは1日あたり数十億件のログが発生し、データ量は線形的に増加しています。 このような超ビッグデータを効率的に処理し、ビジネスの意思決定に繋げるための仕組みを一緒に作ってみませんか？ ご興味のある方は セーフィー採用サイト を覗いてみて下さい！ よいLightdash Lifeを〜それではまた！

こんにちは！セーフィーでハードウェア開発を担当している持丸です。 ご存じの通り、「セーフィー」はクラウド録画サービスやソフトウェアを事業の中核とする会社です。 そして当然のように、クラウドやソフトウェアの技術をベースとしたエンジニアの割合が多い会社になります。 しかし、お客様に最高の体験をお届けするためには、映像の入り口となるカメラをはじめとした「ハードウェア」の存在が欠かせません。 今日は、普段あまり語られることのない、セーフィーのハードウェアへの熱い想いと、その品質を支える取り組みについてご紹介したいと思います。 すべては「お客様に寄り添う」ために 「ただ仕入れる」だけでは終わらない、セーフィーの製品評価 仕組みで支える品質。製品評価プロセスの標準化 不具合解析こそ、腕の見せどころ おわりに すべては「お客様に寄り添う」ために 私たちハードウェア担当が最も大切にしているのは、 「お客様に寄り添った製品（ハードウェア）を提供していく」 という、とてもシンプルな方針です。 お客様がどのようなシーンで、どのような課題を解決したいのか。 それを深く理解し、機能や性能はもちろんのこと、長期にわたって安心して使える品質、そして安全性を兼ね備えた製品をお届けすること。 それが私たちの使命です。 セーフィーが提供するハードウェア製品には、他社から購入した製品（一部をセーフィー向けにカスタマイズしたものを含む）と、自社で開発した製品の2種類があります。 今回は、特に他社製品をお客様にお届けする際の、私たちのこだわりについてお話しします。 「ただ仕入れる」だけでは終わらない、セーフィーの製品評価 他社製品を選定する上で、私たちは特に以下の2つのプロセスに多くの時間を費やしています。 お客様の利用シーンの把握と理解 提供する製品の設計思想の読み取り Fig1 なぜなら、この2つのステップを疎かにすると、「思い込み」によって後々大きな問題を引き起こしかねないからです。 「普通はこうのはずだ」といった思い込みを排除し、お客様の本当のニーズと製品の特性を正確に結びつける。 そして、関係者全員がその共通理解の上に立つことが、プロジェクト成功の鍵を握っています。 この考え方に基づき、私たちは以下のようなステップで製品の評価を進めています。 お客様の要求内容を明確にし、文書化する（ユーザー情報） 選択する製品の仕様（機能、性能、品質など）がお客様の要求を満たせているかを確認する（製品情報） カタログスペックだけでは確認できない項目を洗い出し、評価・検証を実施する（追加評価） Fig2 仕組みで支える品質。製品評価プロセスの標準化 「言うは易し、行うは難し」ですが、これらの製品評価プロセスが担当者のスキルや経験だけに依存してしまうと、品質にばらつきが生まれてしまいます。 そこで私たちは、誰が担当しても一定の品質を担保できるように、評価プロセスを前述のように標準化し、専用の入力フォーム（下記参照）や手順書を整備しています。 利用シーンの把握: 製品設置要件確認シート 製品の設計・安全思想の把握: 設置ガイドの確認シート、製品認証の確認シート 製品性能・品質の確認: 製品性能の確認シート、製品品質の確認シート Fig3 さらに、ソフトウェアエンジニアが多く在籍するセーフィーの特性を踏まえ、各シートの入力方法や注意点をまとめた手順書を準備しました。 これは、普段から設置業務、部材に触れている担当であれば用語にも精通していますし、どこにどういった情報があるかもすぐわかります。 しかし、頻度の低い人が作業を始めようとすると、思いのほか時間がかかったりもします。このような背景に対応するための手順書を作成しています。 Fig4 これらを用いることにより、ハードウェアの専門家でなくても、スムーズかつ網羅的に検証を進められる環境を整えています。 加えて、使用上の注意、安全上の注意、認証前提といった文言、用語、表現が各社で幅広く単純な検索ではマッチしないものには生成AIを用いることを想定し、対象項目を調査できるようにキーフレーズを併記しています。 多くの人が実感している通り、生成AIによる調査のメリットは、網羅的な抽出ができることにより、調査範囲が不十分なことによる抜け、漏れの発生を防ぐことができます。 しかしながら、調査者の経験・知識が少ない場合には、生成AIに入力するフレーズが十分でなく、このメリットが十分に享受できないケースの発生があります。 これらから、フレーズ例を併記し、出力結果が限定されすぎないようにしています。 Fig5 不具合解析こそ、腕の見せどころ このように確認を行った製品であっても販売後に、残念ながら何らかの不具合が発生することもあります。そんな時こそ、私たちハードウェア担当の腕の見せどころです。 解析の進め方で一番やりがちなことは、つい経験と勘に頼って解析を進めてしまうことです。 当たればよいのですが、当てが外れると原因究明が困難になることも多々あります。 我々は製造メーカーではなく、大量に世の中に製品を出荷しているわけではないので、解析ができる不具合対象機が数台程度であることが常です。 慎重にことを進めることが重要になります。 このようなことも踏まえながら、経験豊富なエンジニアも、そうでないメンバーも、同じ情報を残しながら解析を進められるよう、体系的な不具合解析フローを構築しています。 不具合報告の確認（不具合報告確認シート） 不具合品の外観（外観確認報告シート） 不具合再現（再現確認報告シート） 不具合品の分解（分解確認報告シート） 不具合品の解析（解析報告シート） 各シートには、HWエンジニアの経験してきた確認項目がリストされ、その内容を順次チェックしていくつくりになっています。 これにより、後戻りのない、的確な原因究明と、再発防止に繋げています。 Fig6 おわりに 今回は、セーフィーのハードウェアへの取り組み、特に他社製品を評価する際のプロセス及び不具合解析についてご紹介しました。 これは、 HWエンジニアを抱えるセーフィーだからこそのアプローチです 。 私たちの目標は、この HWエンジニアの経験や見識に裏打ちされた仕組み をさらに進化させ、HWエンジニア以外のメンバーを含めた全体の底上げをすることでお客様に品質の高いハードウェアを届けられるようにすることです。 次回は、もう一つの柱である「自社開発製品」について、詳しくお話ししたいと思いますので、お楽しみに！

こんにちは。セーフィー株式会社エンジニアの伊藤です。 今回のお話は、動画配信サービスを開発・運営されている皆さまへ 「UI/UX」 についてのお願いです。冒頭からかなり対象を絞った内容に感じられるかもしれませんが、きっと多くの方にも共感していただける部分があると思います。 どうぞ気軽にお読みいただければ幸いです。 まずは こちら をご覧ください。（※音が出ます） ※ iOS では上手く表示されない不具合があります。動作環境は PC がおススメです。 動画見ながら寝落ち問題 シークバーのツライところ 理想のシークバーの提案 まとめ おまけ（シークバーの作り方） ステップ１ 設計図を書く ステップ２ 座標変換 ステップ３ 描画 ステップ４ 再生位置の移動 & スケール変換 まとめ 動画見ながら寝落ち問題 さて、皆さんは「動画配信サービス」を利用していますか？ YouTube、Netflix、Amazonプライム・ビデオ、他にも数えきれないほどのサービスが乱立していますが、現代人なら何かしら一つは使っているのではないでしょうか。中には、いくつものサービスに加入して、毎晩ついつい夜更かししてしまったり、休日は朝から晩まで動画漬け、、なんて方もいらっしゃるかもしれませんね。かく言う私も、そんな動画漬けの毎日を送っている一人です。 そして今回は、そんな生活の中でどうしても気になる “あるUI” について、一言物申したいと思います。 それは 「シークバー」 です。 私は普段、寝ころびながらスマホで動画を見ることが多いのですが、ついつい 寝落ち してしまうことがあります。気づけば動画は再生し終わっていて、「あれ？どこまで見たんだっけ？」と、後から見返そうとするのですが、そこで困るのがシークバーです。動画の総再生時間に対して、シークバーの表示があまりにも短く、指で正確に寝落ちした位置まで移動するのがとても難しいのです。 シークバーのツライところ 「いやいや、それって本当にそんなに難しいの？」とピンとこない方もいるかもしれません。そこで、どれくらい操作が難しいのかを定量的に検証してみましょう。 まず、シークバーの物理的な長さですが、スマホを横向きにしたときの画面幅に依存します。端末によって違いはあるものの、大きめのスマホでも画面の横幅はせいぜい 150mm 程度です。（ちなみに、私が使っているスマホは 110mm でした） ただし、これは画面全体の幅。実際のシークバーには左右にマージン（余白）があるため、バー自体の有効な長さはもう少し短くなります。ここでは仮に、シークバーの長さを 140mm としてみましょう。この状態で 2時間（= 7,200秒）の映画を見ているとすると、 1mm あたりの時間 ： 7,200秒 ÷ 140mm ≒ 50 秒/mm さらに、指の腹の太さはだいたい 15mm くらいありますよね。つまり、 指先 1 本分に約 12 分 （＝50秒 × 15mm）の映像が圧縮されているわけです。 この状態で「あと5秒戻りたい」と思っても、1mm以下の繊細な操作が求められます。まるでお米に字を書くようなものですね。しかも、苦労してシークバーを微調整したところで、動画が再生されるまでは、どの場面から始まるのか分かりません。「このシーンはまだ意識があったな」「あっ、ちょっと行きすぎた」そんなことを考えながら、スクリーンを何度も指でスリスリ。そして、行きすぎては戻し、戻しすぎては進める。こうして、微調整を何度も繰り返す羽目になるのです。 理想のシークバーの提案 そこで冒頭の動画の新しいシークバーの提案です。各社の動画配信サービスでぜひ採用していただきたい、 理想のシークバー を自分なりに実装してみました。 工夫したポイントは、主に以下の2つです。 １. シークバーのスケールを拡大・縮小できる 再生位置の指定は、マウスならドラッグ操作で、スマホならタッチ操作で行います。これ自体は一般的な操作ですが、ここに スケーリング機能 を加えました。 マウスホイールで拡大・縮小（スマホの場合はピンチイン・ピンチアウト） スケールを大きくすれば、ざっくり全体を早送り・巻き戻し スケールを小さくすれば、秒単位での微調整もストレスフリー 「まず大まかに探し → 細かく調整する」 という動作が、スムーズに完結できるのです。 ２. 動画のサムネイルを表示して視覚的に検索できる シークバーの上に 動画のサムネイルを表示する 機能も加えました。これは最近のプレイヤーにもよく見られる機能ですが、今回の提案ではスケール拡大・縮小と組み合わせて使えるのがポイントです。 拡大時には、前後のフレームが視認できるようにし、シーンの切り替わりもひと目で把握できる 「どこで寝落ちしたか」が視覚的に探しやすくなる この2点を組み合わせることで、「あの場面を探したいのに見つからない」という、あのもどかしさから解放されるのではないかと考えています！ まとめ 以上、現場からのお願いでした！ ちなみに冒頭のデモのサムネイル部分の描画には、ブラウザにそこそこ負荷がかかっているようで、上手く動作しないことがあります。特に iOS ではサムネイルが上手く表示されない不具合が見つかっています。動作環境は PC がおススメです。 また今回作ったシークバーをお好きな動画でお試しいただけるように、 お手元の動画ファイルを読み込めるバージョン を用意しました。良ければこちらも使ってみてください。 動画配信サービスを手がける皆さま、どうかこの寝落ちユーザーの声に耳を傾けていただければ幸いです！ おまけ（シークバーの作り方） ここからはエンジニア向けのお話しになります。せっかくなので、スケールを自由に変更できるシークバーの実装方法について解説したいと思います。 冒頭の動画サンプルでは、サムネイル表示などの機能も含めているため、コードが少し複雑になっています。そこで、今回はシーク機能に限定したシンプルな デモ を用意しました。こちらのコードをベースにして、具体的な実装ポイントや仕組みをわかりやすく説明していきたいと思います。ソースコードは こちら です。 実装方法はいくつか考えられますが、今回はWebアプリとしての開発ということで、 Canvas API を使って実装しました。Canvas API は標準的な描画処理のインターフェイスを提供しており、モバイルなど他のプラットフォームでも似たような機能やライブラリがあるので、比較的簡単に移植が可能だと思います。 ステップ１ 設計図を書く まずはデザインを決めて、その設計図を描きましょう。Canvas API では点や線、長方形といった基本的な図形のほか、テキストや画像も描画できますが、どんなGUIを作るにしても、まずは 描きたいものを細かな要素に分解する ことが大切です。 サンプルは下図のようなデザインになっていますが、よく見ると線と長方形、そしてテキストで構成されていることが分かると思います。 こちらに細かく寸法を記入していきます。 寸法の取り方はセンス次第で自由に決めていただいて構いませんが、 このようなパラメータを変数としてまとめておく と、あとからデザインを調整するときにとても便利です。 const SEEKBAR_POS_Y = 60 ; const SEEKBAR_HEIGHT = 15 ; const SCALE_LINE_HEIGHT = 8 ; const SCALE_TIME_TEXT_SIZE = 16 ; const CURRENT_TIME_TEXT_SIZE = 28 ; const HEIGHT = 120 ; ステップ２ 座標変換 続いて、シークバーの描画に必要な知識をインプットしていきましょう。 シークバーの横方向は、動画の時間の経過を表しています。ここで、動画の時間と画面上の描画位置を結びつけるために、 「座標変換」 という考え方が役立ちます。聞き慣れない言葉かもしれませんが、実は中学生のときに習った 一次関数 の考え方とほぼ同じものです。 今回作ったものは、まず図のように動画全体から、その一部を切り取った赤枠の部分を画面上に描画しています。このように考えると、 「動画の時間軸」と「画面の座標軸」 という、2つの異なる座標軸が存在していることになります。 ここで、動画の時刻を 、画面の水平方向の位置を とします。さらに、 画面の左端の位置に対応する時間： 画面1ピクセルあたりの時間幅： とすると、次のような変換式が成り立ちます。 こちらの式だけでは、時間軸と画面座標軸の変換を具体的にイメージしづらいと思うので、下記のように値を定義して、その関係を図示してみます。 画面の幅： 現在時刻： 画面の右端の位置に対応する時間： 動画の長さ： 図の上側の青色の直線が時間軸で、下側のオレンジ色の直線が画面座標軸になります。グラフにすると次にような直線（一次関数）です。 この直線の式の定数項である を変化させると、時間軸上で切り取る範囲が変わります。その結果、画面上ではシークバーの表示位置が左右に移動し、まるで時間が動いているように見えるのです。 また、直線の傾きを表す の値を変えると、画面上で切り出される時間の範囲が変わります。これにより、シークバーのスケールが拡大・縮小されたような見た目になります。 ちなみに今回のデザインでは、画面の中央の位置が現在時刻 ( ) をあらわしているので、 は現在時刻から画面幅の半分 ( )の時間を差し引いた値となり、次のように表せます。 というわけで、動画の切り出し位置を制御するための変数として現在時刻 ( ) 、スケールを制御するための変数として１ピクセル当たりの時間( ) 、この 2 つを保持しておけば十分です。 // 現在の時刻 currentTimeMs = 0 ; // 1ピクセルあたりの時間（ミリ秒） timeMsPerPix = 2400 ; 元の変換式に を代入して消すと、現在時刻 ( ) と1 ピクセル当たり時間幅 ( ) を用いた式に整理できます。 ここからさらに変形して イコールの形にすると、時間軸上の座標 を画面上の座標 に変換できます。 これらが動画の時間軸と画面の座標軸を行き来するための変換式になります。描画位置の計算のために頻繁に利用するので 関数化 しておきます。 pix2time ( pix ) { const startTimeMs = this. currentTimeMs - this. canvas . width / 2 * this. timeMsPerPix ; return pix * this. timeMsPerPix + startTimeMs ; } time2pix ( timeMs ) { const startTimeMs = this. currentTimeMs - this. canvas . width / 2 * this. timeMsPerPix ; return ( timeMs - startTimeMs ) / this. timeMsPerPix } ステップ３ 描画 さて、準備が整ったので、いよいよ描画方法について解説していきます。 描画に用いる Canvas API の利用方法はここで詳しく解説はしませんが、長方形とテキストの描画しか用いないので、下記の２点だけ雑に理解していればオッケイです。 長方形の描画 (fillRect) テキストの描画 (fillText) 描画処理は draw() 関数 の中にまとめられていますが、少し長いので段階的に見ていきましょう。 背景の描画 まずは背景の描画から。ここでは、キャンバス全体を指定した色で塗りつぶしています。つまり、この時点では背景が真っ白になっているだけです。 ctx . fillStyle = SEEKBAR_BACKGROUND_COLOR ; ctx . fillRect ( 0 , 0 , this. canvas . width , this. canvas . height ) ; シークバー本体の描画 次にシークバー本体を描画します。バーの背景は画面の横幅いっぱいに長方形を描くだけです。その後に動画コンテンツが存在する部分を緑色で塗り分けます。 // シークバーの背景描画 ctx . fillStyle = SEEKBAR_BLANK_COLOR ; ctx . fillRect ( 0 , SEEKBAR_POS_Y , this. canvas . width , SEEKBAR_HEIGHT ) ; // シークバーの動画コンテンツがある部分を描画 const dataStartPosX = this. time2pix ( 0 ) ; const dataEndPosX = this. time2pix ( this. durationMs ) ; ctx . fillStyle = SEEKBAR_DATA_COLOR ; ctx . fillRect ( dataStartPosX , SEEKBAR_POS_Y , dataEndPosX - dataStartPosX , SEEKBAR_HEIGHT ) ; シークバーの目盛りの描画 続いて少し長めですが、シークバーの目盛りを描画しているコードをご紹介します。 ctx . font = SCALE_TIME_TEXT_SIZE + 'px sans-serif' ; const { scaleInterval , textInterval } = this. adjustScale ( this. timeMsPerPix ) const startTime = this. pix2time ( 0 ) const endTime = this. pix2time ( this. canvas . width ) const firstScaleTime = Math . floor ( startTime / scaleInterval ) * scaleInterval let i = 0 while ( 1 ) { const scaleTime = firstScaleTime + i * scaleInterval if ( scaleTime > endTime ) { break; } if ( scaleTime > this. durationMs ) { break; } if ( scaleTime < 0 ) { i ++ continue } // 目盛りを描画 const scalePosX = this. time2pix ( scaleTime ) const scalePosStartY = SEEKBAR_POS_Y + SEEKBAR_HEIGHT const scalePosEndY = scaleTime % textInterval === 0 ? scalePosStartY + SEEKBAR_SCALE_HEIGHT * 2 : scalePosStartY + SEEKBAR_SCALE_HEIGHT ctx . fillStyle = SEEKBAR_SCALE_COLOR ; ctx . fillRect ( scalePosX , scalePosStartY , 1 , scalePosEndY - scalePosStartY ) // 時間をテキストで描画 if ( scaleTime % textInterval === 0 ) { ctx . textAlign = 'center' ctx . textBaseline = 'top' ctx . fillText ( this. time2str ( scaleTime ) , scalePosX , scalePosEndY + 5 ) } i ++ } 最初に描画する目盛りの時間は以下のように計算しています。 const firstScaleTime = Math . floor ( startTime / scaleInterval ) * scaleInterval ここで使っている scaleInterval は目盛りの間隔を表す変数で、1ピクセルあたりの時間幅に応じて調整しています。この位置は、下図のように 画面の左端ギリギリの外にある目盛りの時間 を指しています。 最初の目盛りの位置が決まれば、あとは画面右端まで等間隔で線を描画していくだけです。 let i = 0 while ( 1 ) { const scaleTime = firstScaleTime + i * scaleInterval ・ ・　ループを抜ける判定 ・ const scalePosX = this. time2pix ( scaleTime ) ・ ・　scalePosX の位置に目盛りを描画 ・ ++ i } 現在時刻の描画 現在時刻を示す赤い線とテキストを描画して完成です。 // 中心の線を描画 ctx . fillStyle = SEEKBAR_CENTER_LINE_COLOR ; ctx . fillRect ( this. canvas . width / 2 , 0 , 1 , this. canvas . height ) ; // 現在時刻の文字背景を塗りつぶす const textBgWidth = 100 const textBgHeight = CURRENT_TIME_TEXT_SIZE + 5 const textBgPosX = ( this. canvas . width - textBgWidth ) / 2 const textBgPosY = ( SEEKBAR_POS_Y - textBgHeight ) / 2 ctx . fillStyle = SEEKBAR_BACKGROUND_COLOR ; ctx . fillRect ( textBgPosX , textBgPosY , textBgWidth , textBgHeight ) ; // 現在時刻のテキストを描画 ctx . font = CURRENT_TIME_TEXT_SIZE + 'px sans-serif' ; ctx . textAlign = 'center' ctx . textBaseline = 'middle' ctx . fillStyle = SEEKBAR_TIME_TEXT_COLOR ; const textPosX = this. canvas . width / 2 const textPosY = SEEKBAR_POS_Y / 2 ctx . fillText ( this. time2str ( this. currentTimeMs ) , textPosX , textPosY ) ; ステップ４ 再生位置の移動 & スケール変換 最後に、マウスイベントに合わせて再生位置の移動やスケール変更を行っているコードを見ていきましょう。 まず、再生位置の移動はマウスのドラッグ操作に連動して currentTime を更新するだけです。 this .canvas . addEventListener ( 'mousedown' , ( e ) => { this. isMouseDown = true this. mousePosX = e . offsetX }) this .canvas . addEventListener ( 'mouseup' , () => { this. isMouseDown = false }) this .canvas . addEventListener ( 'mouseleave' , () => { this. isMouseDown = false }) this .canvas . addEventListener ( 'mousemove' , ( e ) => { if ( this. isMouseDown ) { const prevMousePosX = this. mousePosX this. mousePosX = e . offsetX const diffX = prevMousePosX - this. mousePosX const newCurrentTime = this. currentTimeMs + diffX * this. timeMsPerPix this. currentTimeMs = Math . max ( 0 , Math . min ( this. durationMs , newCurrentTime )) this. draw () } }) 次に、スケールの変更もシンプルで、マウスホイールの操作に応じて timeMsPerPix を調整するだけです。 this .canvas . addEventListener ( 'wheel' , ( e ) => { e . preventDefault () ; let newTimeMsPerPix = this. timeMsPerPix if ( e . deltaY > 0 ) { newTimeMsPerPix *= 1 . 1 } else { newTimeMsPerPix *= 0 . 9 } this. timeMsPerPix = Math . max ( MIN_TIME_MS_PER_PIX , newTimeMsPerPix ) this. draw () }) これで、マウス操作による直感的なシークとスケール調整が実現できます。タッチ操作もサポートしていますが、実装方法は過去に執筆した 記事 でも解説しておりますので、こちらを参考にしていただければと思います。 まとめ 長くなりましたが、以上が処理の全容になります。 今回解説した座標変換の考えを利用すれば、アイデア次第で色んなものが作れそうな気がしませんか？ちなみに座標軸を２次元に拡張すれば、GoogleMap のようなマップアプリも作れます。みなさまの何かのお役に立てれば幸いです。 最後までお付き合いいただき、ありがとうございました。

こんにちは！セーフィーでQAエンジニアをしている福山です。 今回は、入社間もない私が、他プロジェクトのQAメンバーを巻き込み、探索的テストで製品品質を向上させた経験をお話しします。 この記事は、特にこんな方々に読んでいただけると嬉しいです。 探索的テスト や新しい品質保証の取り組みを考えているQAエンジニアの方 チームや部署を横断した連携で、組織全体の生産性や品質を高めたいテックリードやマネージャーの方 新しい環境で自身の強みを活かして成果を出したい中途入社の方 課題：リリースを前に、担当チームだけでは見つけられない不具合の壁 成功の鍵は「巻き込む力」！他チーム連携で意識した5つの工夫 1. タイミングを見極める 2. 心理的ハードルを下げて「テストに集中できる」環境を作る 数値的な目標は慣れてから 気軽に共有できる場を設ける バグを見つけることだけが成果ではない 3. 上長を味方につける 4. モチベーションを維持する 週替わりの画面担当ローテーション 個別フォローと密なコミュニケーション 迅速なフィードバック 5. 共有の場から関係性を築く テスト結果を数値的に可視化 関連題材を用いた勉強会 挑戦の裏側：ぶつかった壁と、思いがけない発見 ぶつかった壁 実施時間と他業務との調整 自身の認知度と信頼感 思いがけない発見 メンバーの協力的な姿勢 多様な視点からの発見 まとめ：組織を動かし、成果を出すために必要なこと 課題：リリースを前に、担当チームだけでは見つけられない不具合の壁 セーフィーのQA部門には、合計16名のQAエンジニアがいます。それぞれが複数の製品を担当しており、私が担当する製品のQAメンバーは4名。残りの12名は別の製品に携わっています。 日頃からテストスクリプトを使った網羅的なテストと、探索的テストを並行して実施していましたが、担当プロジェクトのメンバーだけでは、どうしても見つけにくい不具合があると感じていました。 迫りくるリリースを前に「どうすればもっと品質を高められるだろう？」と考えた私がたどり着いたのが、 「他プロジェクトを担当するQAメンバーを巻き込む」 というアイデアでした。同じQAという職種でも、普段は別の製品に携わっているメンバーの新鮮な視点と専門的な経験を活かした探索的テストは、きっと製品の隠れた問題を発見し、品質を一段と引き上げてくれると確信したのです。 成功の鍵は「巻き込む力」！他チーム連携で意識した5つの工夫 他プロジェクトのQAメンバーに協力を依頼するにあたり、スムーズな連携と参加者のモチベーション維持が重要だと考え、以下の点を意識して準備を進めました。 1. タイミングを見極める テストの実施タイミングは非常に重要です。今回は、機能が90%以上実装されており、かつリリースまで1ヶ月半というタイミングで協力を依頼しました。未実装の機能が多いとテスターが混乱しますし、開始が遅すぎると開発への負荷も大きくなるため、このタイミングが最適だと判断しました。 2. 心理的ハードルを下げて「テストに集中できる」環境を作る 主担当ではない製品の探索的テストはどうしても心理的ハードルがあるため、できるだけハードルを下げ、スムーズに進むようにいくつか工夫を行いました。 数値的な目標は慣れてから まずは目的を意識しつつも慣れてもらうことを最初の目標にしました。裏では具体的な目標数値は設定していましたが、いきなり数値を提示すると逆効果だと考え、後から共有することにしました。 気軽に共有できる場を設ける Backlogへの直接起票はやめ、スプレッドシートに記入してもらう形式にしました。これにより、内容の精度や不具合の重複を気にせず報告できるため、心理的なハードルが下がります。 バグを見つけることだけが成果ではない 不具合が検出できなかった場合でもモチベーションを下げないよう、「不具合がない」ことも貴重な情報であることを伝えました。また「違和感」や「改善点」も歓迎し、UI/UX向上に直結する重要な情報だと強調しました。 3. 上長を味方につける プロジェクトを円滑に進めるには、上長（グループリーダー：GL）の理解と協力が不可欠です。私たちは2つのグループに分かれているため、他グループのメンバーを巻き込むには、各グループのGLの理解と協力が必要でした。事前に相談し、快諾を得るとともに貴重なアドバイスもいただきました。上層部のサポートは、プロジェクトを成功させる上で非常に心強い後押しとなります。 4. モチベーションを維持する 約1ヶ月半の探索的テストへのモチベーションを維持してもらうため、具体的な仕組みをいくつか導入しました。 週替わりの画面担当ローテーション 参加者には週ごとに担当画面を割り当て、飽きを防ぎながら主要機能を優先的にテストできるよう工夫しました。 個別フォローと密なコミュニケーション リモートワーク中心のメンバーには、DMなどを活用して積極的にコミュニケーションを取り、不具合検出の感謝を伝えたり、困っていることがないか確認しました。 迅速なフィードバック 報告された内容は、極力その日のうちに確認し、何かしら返信するように心がけました。迅速なレスポンスは、報告する側のモチベーション維持につながります。 5. 共有の場から関係性を築く テスト結果を数値的に可視化 毎週、テスト結果を数値的に可視化し、参加者全員に共有しました。これにより、自分たちの活動が製品品質にどのように貢献しているかを実感してもらいました。さらに、特に参考になった報告内容については、感謝の意を込めて共有し、参加者の努力を称えました。 関連題材を用いた勉強会 テストの中盤には、探索的テストに関する勉強会を開催しました。共通の題材を通して、お互いの考え方やテストスタイルを共有する機会を設け、チーム全体のテストスキル向上と連携強化を図りました。 挑戦の裏側：ぶつかった壁と、思いがけない発見 今回の取り組みでは、もちろん悩みもありましたが、幸運にも助けられる場面も多くありました。 ぶつかった壁 実施時間と他業務との調整 各メンバーの業務が見えない状況で、どの程度時間を捻出可能かは非常に悩ましい点でした。GLに相談し、最低1時間/週という下限値を設けて自主性に任せる方針を決定しました。 自身の認知度と信頼感 最も困ったのがこちらです。中途入社から半年弱ということもあり、普段接点のない他グループのメンバーに自身の存在を知ってもらい、信頼関係を築くことが課題でした。勉強会などを通じて積極的に自己開示を行い、少しずつ関係性を構築していきました。 思いがけない発見 メンバーの協力的な姿勢 通常、初めての試みでは様子見から入ることが多いものですが、率先してスタートダッシュを切ってくれたメンバーがいました。また、中盤でも熱心に多くの報告をくれたメンバー、そして終盤まで継続してテストに参加してくれたメンバーなど、様々な協力がプロジェクトを前進させました。 多様な視点からの発見 各メンバーがそれぞれの得意な観点や、様々な視点から不具合を検出してくれたのは大きな収穫でした。これにより、私自身も「こんな観点があったのか」と学びを深めることができました。この多様な視点こそが、探索的テストの真価だと改めて感じました。 まとめ：組織を動かし、成果を出すために必要なこと 他プロジェクトのQAメンバーを巻き込んだ探索的テストは、製品の品質向上に大きく貢献しただけでなく、部内間のコミュニケーション活性化にもつながる、非常に有意義な取り組みでした。 本記事の最大の価値は、製品の品質向上という 結果 だけでなく、 その成果を生み出した「他チームを巻き込む」ための具体的なプロセスとノウハウ を共有した点にあります。具体的な数値は皆さんのチームの状況によって変わるかもしれませんが、ここに書かれている工夫や考え方は、きっと皆さんの組織でも再現できると思います。 私自身のように中途入社でドメイン知識が少ないメンバーでも、今回の工夫を凝らすことで、きっと素晴らしい成果を生み出すことができるはずです。 本記事が、皆さんの品質保証活動の一助となれば幸いです。

こんにちは。25新卒エンジニアの中です。 大学院では、ある車の会社と共同で「機械学習を用いて物理シミュレーションを置き換える手法」について研究を行い、先日ローマにて行われたAI関連の学会でポスター発表してきました。エスプレッソもパスタもワインも美味しかったです。 このブログでは、入社してから4ヶ月弱で行われた新卒研修プロジェクトで学んだ、「全体像の可視化」の重要性について話していきます。 新卒エンジニア研修について 研修で直面した壁 プロジェクトの全体像が見えなかった初期フェーズ 振り返り会と「可視化」の徹底 Before After 研修を振り返ってみて 4月-5月前半：課題発見フェーズ もし全体像が可視化されていたら… 5月後半-6月前半：課題発見フェーズ2 6月後半-7月：開発と未来設計のフェーズ まとめ 新卒エンジニア研修について 今回のセーフィーの新卒エンジニア研修では、4月真ん中から7月末までの4ヶ月弱で、「社内課題を解決するためのプロダクト開発」を行ないました。この研修の最大の目的は、「プロダクト思考を体現し、エンジニアとして成長する」ことです。つまり、ユーザー目線に立ち、プロダクトを考え、それに沿って開発を進め、その上で成長していくことが求められました。 研修で直面した壁 研修プロジェクトが始まってすぐに私たちが直面したのは、『チーム全員でプロジェクトの全体像を把握すること』の難しさでした。私たちのチームには、以下の2つの目的がありました。 新卒研修プロジェクトの目的：プロダクト思考を身につけ、エンジニアとして成長する プロダクトの目的：ユーザーの課題を解決する プロジェクトの全体像の把握ができていないと、この2つの目的を同時に達成することは難しいと痛感しました。 プロジェクトの全体像が見えなかった初期フェーズ チームでの開発フェーズが始まった初期段階では、プロジェクトの進捗状況が把握できていませんでした。 口頭でのタスク管理：口頭で決まったことがタスクとして記録されず、それぞれのタスクの粒度もバラバラでした タスクの偏り：誰が何をするのかが曖昧になり、チーム全体でタスクを抱えている人と、そうではない人の差が大きくなっていきました。 漠然とした不安：目の前のタスクをこなすことに精一杯で、「本当にユーザーの課題を解決するものなのか？」「このプロセスが自身の成長に本当につながっているのか？」という漠然とした不安が常に付きまといました。 これは、プロジェクト全体の把握ができていないことにより、「自身の成長」と「ユーザーの課題解決」という2つの目的を見失っていたことが原因でした。 振り返り会と「可視化」の徹底 プロジェクト全体の把握ができていないという課題を解決するため、私たちは開発機関の中間地点で開催した振り返り会で現状を共有しました。そこで、私たちは以下のシンプルなルールを徹底することに決めました。 タスクは必ずチケットとして可視化し、粒度を揃える 具体的なルールは以下の通りです。 チケットは1~2営業日以内で完了するものに限定する 処理中のタスクは1~2個にする 複数のタスクが同日に並ぶ場合は、全てその日で終わらせられる場合のみとする このルールにより、メンバー間でタスクの共通認識が生まれ、スムーズに開発を進められるようになりました。 Before 弁当競合調査の中で何をするのか、どう調べるのかがわからず、進捗状況が一目で分かりづらい。開発本部会は1日のはずなのに4日分引かれており、その中で何をするのかがわからない。 After アイテム画面実装という親タスクに対し、何をするのかを小タスクとして設定し、進捗を確認しやすくなりました。 研修を振り返ってみて もし研修開始当初に「全体像の可視化」の重要性に気づけていたら、私たちのプロジェクトはもっとスムーズに進んだという仮定のもと、開発研修を振り返っていきたいと思います。 4月-5月前半：課題発見フェーズ この時期は、プロジェクトの進め方や課題を発見するための手法に関する知識が不足していました。 もし全体像が可視化されていたら… 最終ゴールの明確化：最終的に完成させるプロダクトの規模やビジョン、最終到達点をチームで明確に合意していれば、そこから逆算してマイルストーンを設定できたはずです Backlogの適切な運用：ゴールが定まっていれば、Backlogのチケットの粒度も自然と定まり、手探りでの運用を避けることができたはずです 5月後半-6月前半：課題発見フェーズ2 この期間は、メンバーが入れ替わりで研修に参加していたため、チーム内での進捗共有が不十分になってしまいました。 もし「全体像」が可視化されていたら... スムーズな進捗共有：プロジェクトの全体像が可視化され、Backlogに適切にチケットが反映されていれば、戻ってきたメンバーもすぐに状況を把握できたはずです チームの一貫性の維持：チームとしての判断軸が定まっていれば、メンバーが抜けても方向性がぶれることはなかったでしょう 6月後半-7月：開発と未来設計のフェーズ 開発期間は、当初の計画よりもミニマム開発の完了が遅れてしまいました。また、明確なルールがないままアジャイル的な進め方になったため、進捗の把握に苦労しました。 もし「全体像」が可視化されていたら... 運用を見据えた設計: 開発の初期段階から「運用しやすい設計になっているか？」「コストに見合う価値があるか？」といった問いに向き合え、属人化を避けるための人員配置や計画を立てられたはずです まとめ この研修プロジェクトを通して、私は技術的なスキルだけでなく、『チーム全員が同じ全体像を共有し、目的を意識して開発を進めること』が、プロジェクトの成功と自身の成長に不可欠だと学びました。 研修で直面した壁は、私たちを大きく成長させてくれました。配属されて数週間経った今、この経験を活かし、 自身の成長とチームとしての成果、両方の視点を持って行動すること を心がけています。 今後、この研修で開発したプロダクトは、社内運用に向けてチームで議論を重ねていきます。技術を学ぶだけではないこの新卒研修プロジェクトを経験できたこと、そして多くの壁をチームで乗り越えた経験は、これからのエンジニアとしてのキャリアにおいて、常に活かされていく大切な教訓です。