この記事は 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月：開発と未来設計のフェーズ 開発期間は、当初の計画よりもミニマム開発の完了が遅れてしまいました。また、明確なルールがないままアジャイル的な進め方になったため、進捗の把握に苦労しました。 もし「全体像」が可視化されていたら... 運用を見据えた設計: 開発の初期段階から「運用しやすい設計になっているか？」「コストに見合う価値があるか？」といった問いに向き合え、属人化を避けるための人員配置や計画を立てられたはずです まとめ この研修プロジェクトを通して、私は技術的なスキルだけでなく、『チーム全員が同じ全体像を共有し、目的を意識して開発を進めること』が、プロジェクトの成功と自身の成長に不可欠だと学びました。 研修で直面した壁は、私たちを大きく成長させてくれました。配属されて数週間経った今、この経験を活かし、 自身の成長とチームとしての成果、両方の視点を持って行動すること を心がけています。 今後、この研修で開発したプロダクトは、社内運用に向けてチームで議論を重ねていきます。技術を学ぶだけではないこの新卒研修プロジェクトを経験できたこと、そして多くの壁をチームで乗り越えた経験は、これからのエンジニアとしてのキャリアにおいて、常に活かされていく大切な教訓です。

こんにちは！ モバイルチームの夕田です！ 先日開催された国内最大級のiOSエンジニア向けカンファレンス「 iOSDC Japan 2025 」に、セーフィーのiOSチームが参加しました！ 今年セーフィーは本イベントに シルバースポンサー として協賛させていただきました！ 下記 connpass のページをぜひご確認ください！ yumemi.connpass.com おわりに 「ブログを書くまでがiOSDC」ということで、無事に私たちもiOSDCを締めくくることができました✌️ 最後になりますが、このような素晴らしいイベントを企画・運営してくださったスタッフ、関係者、スポンサーの皆様に心より感謝申し上げます。 来年も楽しみにしています！！ セーフィーでは一緒に働くエンジニアの仲間を随時募集しています。 少しでも興味を持たれた方がいましたら、ぜひ下記の採用ページをご覧ください。 safie.co.jp

はじめに セーフィーの情報システムグループでグループリーダーをしている松尾と申します。 セーフィーは「映像から未来をつくる」というビジョンのもと、クラウド録画サービスを提供しています 。私たちのサービスは、防犯・見守りに留まらず、業務効率化や現場DXなど、様々なシーンで社会の「安心安全」を支えています。 情報システムグループ(以下、情シスG)では2025年1月から半年ほど、アジャイルを導入したプロジェクト・タスク管理を実施しました。 今回はこちらの取り組みについて、主に以下の内容を書いていきたいと思います。 はじめに なぜアジャイルを導入したか どのようにアジャイルを導入したのか アジャイル勉強会の実施 スプリントの実施 情シスアジャイルプレイブックの作成 アジャイルを実施するための環境づくり どのような変化があったか 細かい改善の例 半年間を振り返って おわりに なぜアジャイルを導入したか 「日々の問い合わせ対応に追われ、本来注力すべき中長期的なタスクがなかなか進まない…」多くの情報システム部門が抱える悩みではないでしょうか。 私たちセーフィーの情シスGも例外ではありませんでした。タスクは常に「実施中」のまま停滞し、定例報告は「進んでいない状況」の共有になりがちで、チームの士気にも影響が出始めていました。 具体的には以下のような問題がありました。 日々の社内からの問い合わせ対応と、目標設定に紐づく長期的なタスクを並行して実施しており、目標に紐づく長期タスクは各自が開始と終了を設定して進めているが、 突発的な業務などにより、タスクの進捗が遅れがちになっていた その結果、 タスクがずっと「実施中」のままとなり、進捗が見えづらい状態 となっていた 2週間毎に実施している定例では「タスクが進んでいない状況」を共有することになり、 メンバーのモチベーションも上がらない状態になっていた 進捗が見えないため、 適切なタイミングでチームでサポート出来ないというジレンマ があった これらの課題を解決するため、情シスGでは以下の目的を掲げました。 無理のない形でメンバーが成果を出せるようにする そのために、 成果を可視化し、チーム内外にすぐに共有できる状態 を作る 目標設定の状況を明確にし、進捗を正確に把握できる状態を作る 目標達成までのプロセスを細かく刻み、その方法が適切か、 より良い方法はないかを常に探求できるようにする 定例会議を、単なる進捗報告ではなく、 成果を共有する場 にする これらの目的を達成するためのアプローチとして、私たちは「アジャイル」な働き方に着目しました。 どのようにアジャイルを導入したのか アジャイル勉強会の実施 まず、チームでアジャイルを始めるにあたり、セキュリティチームと合同でアジャイルの勉強会を実施しました 。詳細はこちらの記事をご覧ください。 参考記事 engineers.safie.link この勉強会を通じて、アジャイルを導入する際には以下を気をつけるということを学びました。 フレームワークの 「やり方だけ」を取り入れることはしない こと アジャイルの原則とプラクティスの目的を理解し、 現状のチームに合ったものを取り入れ、自分たちのものにしていく こと 上記をふまえ、情シスGに合う形で以下のような形でアジャイルを取り入れてみることにしました。 まずは 「半年間のトライアル」 として始めてみる アジャイルの専門用語はできるだけ使わない 情シスGの中で 取り入れられることだけを利用 する 最終的に、この仕組みがメンバーが 無理なく成果を出すための仕事の仕方の型として定着する ことを目指す スプリントの実施 2週間を1つのスプリント（期間）とし、以下のサイクルで業務を進めていきました。 2週間でやること決め（スプリントプランニング） 2週間で実施することを決める 朝会（デイリースタンドアップ） 毎日実施し、問い合わせ対応とタスクの進捗状況、困っていることを確認する 定例（スプリントレビュー） 2週間で実施した成果を発表する ふりかえり（スプリントレトロスペクティブ） 2週間の振り返りを実施し、その中で優先度の高い対応すべきタスクを決める 情シスアジャイルプレイブックの作成 特に意識したのは、単にフレームワークを導入するだけでなく、「なぜこのプラクティスを行うのか」という目的意識をチーム全員で共有することでした。 そのために、各プラクティスの目的や具体的な進め方を 「情シスアジャイルプレイブック」 として言語化しました。 このプレイブックは、途中でチームメンバーが変わっても「無理なく成果を出す仕組み」が継続されるための、私たちのチームの重要な道しるべとなっています。 記載した主な内容 背景：なぜ情シスGがアジャイルに取り組むのか 目的と具体的な進め方 スプリント（2週間）の進め方 2週間でやること決め（スプリントプランニング） 朝会（デイリースタンドアップ） 情シス定例（スプリントレビュー） ふりかえり（スプリントレトロスペクティブ） Notionページに情シスアジャイルプレイブックをまとめています。 アジャイルを実施するための環境づくり アジャイル導入と並行して、メンバーが目標設定に集中できる環境づくりも進めました。 具体的には、やり方がある程度決まっている定常業務のマニュアルを整備し、業務委託のメンバーに対応してもらう体制を作ることで、正社員メンバーが課題解決に集中できるような環境作りを進めました。 どのような変化があったか スプリントを進めていく中で、以下のような変化が現れました。 スプリント開始1ヶ月ほど プロジェクトの全体像を把握 できるようになった 目標に沿って 一日のタスクを可視化 できるようになった 自分の目標と進捗を以前より意識 するようになった 他のメンバーが何の目標を立てているか 分かるようになった やることが明確になり、目標やマイルストーンを立てることで 相談しやすくなった 2週間単位のスプリントを意識し、具体的に何回のスプリントでプロジェクトを終わらせなくてはいけないと考えたことで、 プロジェクトの全体像を意識し、どこまで実施すれば完了なのか、ということを考える ようなったという意見が出てきました。 また、スプリントでは必ず設定したタスクを完了する必要があるため、 完了するために今日はどのタスクをやるべきかを意識する ようになりました。 タスクを意識することで、進めるうえでの課題点が分かるようになり、チームで 相談がしやすく なりました。 2回目スプリントのふりかえりの様子 スプリント開始2ヶ月ほど (アジャイルブックの作成により)タスク管理の取り組みを言語化できた ゴールが抽象的なプロジェクトへの恐怖感が少なくなった （とりあえず2週間のタスクを決めて進め、都度修正していくサイクルが出来てきた) タスクのプロセスを意識し、 できるだけ細かくタスク化するようになった タスクを細分化することで、スケジュールに沿った対応ができた 突発的なタスクを考慮して、 バッファを持たせた目標設定をする感覚が馴染んできた 前回の振り返りと比較することで、より意識して目標管理に取り組めるようになった 2週間単位での仕事の進め方に慣れてきたこともあり、チームで 2週間で実施可能なタスクの量の感覚が少しづつ分かってきた という意見が出てきました。その結果、突発的なタスクを考慮し、 ある程度バッファをもたせた目標設定が出来る ようになってきました。 また、2週間でタスクが区切られているということから、ゴールが抽象的だったり全体のタスクサイズが分からないものでも、 とりあえず2週間で出来る事を決めて、都度方向を修正していく 仕事の進め方が出来るようになってきました。 細かい改善の例 スプリントを繰り返す中で、タスク管理の方法を細かく変更をしていきました。 今回は一例として、朝会の運営方法をどのように変更していったかをご紹介します。 課題： 朝会のスピード感がない 改善策： Backlogの表示をガントチャートからボード形式に変更。「今日やること」のステータスを追加し、 現在取りかかっているタスクを分かりやすくした 課題： 誰かが困っていても、その内容が分かりづらい 改善策： 当番制だった朝会のファシリテーションをグループリーダーに固定 。各パートでメンバーに 「確認したいことはありますか？」という問いかけを入れる ようにした 課題： 「2週間やること決め」の場が、ただタスクを各自が決めるだけの場になってきている 改善策： 「2週間やること決め」でメンバーが2週間でやることを決めた後に、疑問点や知りたいことなど皆から意見をもらう問いかけを追加し、 コミュニケーションの場にするようにした 課題： 困っていることの相談が解決策の議論にまで発展し、朝会が長引いてしまう 改善策： 朝会を2部制に変更 。前半は定常業務中心のヘルプデスクパートとし、非定常業務の相談は後半に回すようにした 課題： 問い合わせ対応を誰がやるか、お見合いになってしまう 改善策： チームで話し合い、 一旦の対応として問い合わせ対応をチケットごとの輪番制に変更 した このように、2週間ごとにふりかえりと細かい改善を繰り返すことで、朝会の運営方法を少しずつ改善していきました。 半年間を振り返って 半年間のトライアルを経て、チームには以下の変化や文化が定着しました。 細かい確認と改善を繰り返す仕組み (アジャイルな仕事の進め方)がある程度、 チームに定着 した 2週間ごとの定例が、成果を発表できる場になった 細かく成果を発表していく仕組みになったことで、 目標設定の評価が以前より書きやすくなった 非定常の問い合わせ対応をタスク毎の輪番制にすることで、チーム内でのノウハウ共有が進んだ。 やったことのない分野もやってみる文化が根付いてきた 「完璧でなくてもいいので、とりあえずやってみる。解決しなければチームのメンバーに相談する、プロに頼る」 という雰囲気が定着した 「頼ることは悪いことじゃない」 というマインドが浸透した 細かい確認と改善を繰り返す仕事の進め方が定着したことで、プロジェクトを進めるうえで手戻りが少なくなったり、方向性を修正しながら動くということが出来るようになりました。 特に、 とりあえずやってみて、分からなければチームに相談する、頼ることは悪いことではない という文化が定着したことは、チームにとっても非常に重要な事だと考えています。 上記の文化が定着したからこそ、問い合わせ対応の輪番制でメンバーが実施したことがない問い合わせがあった場合でも積極的に対応したり、難易度が高いプロジェクトについてもまずはやってみて、チームに相談して進めていくことが出来るようになったと感じています。 半年間のトライアルについてふりかえりをした様子 おわりに 最後までお読みいただき、ありがとうございました。今回は、セーフィーの情報システムグループが取り組んだアジャイル導入の道のりをご紹介しました。 今回のアジャイルの導入はこれで終わりではなく、今回の取り組みでチームに今後も改善を続けていく予定です。 私たちの試行錯誤の過程が、同じようなチームの課題に悩む方や、情報システム部門の働き方に関心のある方にとって、少しでも参考になれば幸いです。

導入 お久しぶりです。戌亥です。晴れてセーフィー株式会社新卒エンジニアとなりました。（ 参考 ） 研修で動画の仕組みに関して学ぶ機会があったのですが、そのうちの画像圧縮に関してイメージしづらい部分があると感じました。同期エンジニアで勉強会があり、今回はそこで話した内容を一部加筆修正して解説しようと思います。 導入 コンピュータでの画像の扱い方 YUVとは 離散コサイン変換（DCT） まとめ コンピュータでの画像の扱い方 画像圧縮の前に画像がデータとして扱われていることを知らない方向けに、画像がおおよそどのようにデータとして扱われているかを説明します。 説明のために画像を拡大して見ることができるアプリをGeminiで作成しました。 画像ピクセル拡大ツール (クリック固定機能付き) 画像を入力し、クリックした地点を8×8マスで拡大してみることができます。拡大だけでなく、RGB値で表示するモードとバイナリ値で表示するモードがあります。 こちらが画像を拡大した時の図です。左の画像の小さくオレンジ色になっている（セーフィーのロゴの嘴）部分が拡大されたものが右のグリッド図になります。 一般的に画像は0~255の256段階のRGB（Red, Green, Blue）値を各画素ごとにもっています。以下の画像は拡大したグリッド図をRGBの値で表したものです。 コンピュータは0と1で解釈するのでデータ量は2進数で考える必要があります。この0または1をビットと言う単位で考えます。 256は2進数で2 8 なので0～255を表すためには8ビットが必要です。画像において、このビット数を減らすのが画像圧縮です。 YUVとは YUVとはRGBやHSVなどと同じ色空間（色の表し方）の１つです。 人の眼の「輝度信号に対して敏感」と「色差信号に対して鈍感」という特性に合わせた表し方で、輝度信号Yと青色成分の色差U（または ）と赤色成分の色差V（または ）で構成されています。 ディスプレイに表示させる際やカメラで撮影した生のデータはRGBですが、この「色差信号に対して鈍感」という特性から、YUVに変換させることでビット数を減らすことができます。 これを体験できるアプリをGeminiを使って作りました。 YUV3層ビューワ ここに画像ファイルを上げると、YUVそれぞれの層がどのような役割をしているかが直感的にわかります。またこちらのスキップ数というのは、Yで縦×横、Uで縦×横、Vで縦×横とそれぞれ２次元の画素を持っています。これを何個ずつ進むかというものです。 例えばスキップ数が１であればその層は完全な情報です。スキップ数が２だと１つ飛ばして、飛ばしたマスはその前の値で埋められるので、同じ画素値が２つ連続することになります。そうした時の全体のビット数はYが100%、Uが50%、Vが50%となります。つまりビット数は2/3で67%ほどになります。これはYUV 4:2:2と呼ばれる方式と同じです。 YUV 4:2:0と呼ばれる水平・垂直方向にそれぞれ１つ飛ばしていく方式ではYが100%、Uが25%、Vが25%となりビット数は1/2となります。 アプリの方で試してもらうとわかる通り、Yをスキップするとすぐにわかりますが、UとVを少し飛ばしただけでは気づきません。こうして色差信号を減らしていくと圧縮することができます。 ITU-R BT.601というアナログ信号とデジタル信号を相互に変換するための規格があります。これによると、RGBとYUVの関係式は式１のように定義されています。 式１：RGB to YUV 離散コサイン変換（DCT） DCTは厳密には圧縮方法ではなく、圧縮のために必要な処理の１つです。変換のために画像に周波数の考えを導入します。 右のようなのっぺりとした濃淡の変化が少ない画像を低周波な画像、唐草模様や左の濃淡の激しい画像を高周波な画像といいます。自然画では高周波な画像が少なく、高周波成分を削ってしまってもあまり影響を与えません。そこでDCTを行って画像を周波数にしてから高周波成分を削ることで画質にあまり影響を与えずに画像を圧縮できます。 DCTの具体的な手法の前に、フーリエ変換という概念をお話しします。「全ての周期信号は正弦波の合成で表現できる」という考えがあり、これに基づき波形が永遠に続くと仮定して合成元の正弦波を導けます。ざっくりいうとこれがフーリエ変換であり、波形がどの周波数のどのくらいの強度の正弦波で構成されているかがわかるというものです。 DCTの式は式２で示すことができますが、勉強していた当時、これを見てもよくわかりませんでした。 式２：Image to Power DCTはフーリエ変換と似たことをやっており、画像の各層を２次元の波だと考え、ブロック単位で細かく分けた画像を周波数成分に分解します。 例えば８×８マス単位でDCTを行う場合、まず0～7Hzの波形を作ります。 そうすると下記の図のような8つの波形ができます。 図：0～7Hzの離散波形 それをもとに下記の図のような基底関数画像といわれるグレースケールの画像を作成します。これは2つの波の該当する部分を8×8の各マスで掛け算します。 図：基底関数画像（u, v）= (5, 2) このような画像を0～7Hzの8パターンを縦×横の計64パターンを用意します。 これは8×8マス単位でDCTを行うのであればどんな画像に対してでも同じ64パターンの画像を使います。 下記の図のように、生成した64パターンの画像と対象のブロックとの内績を取った値がDCT変換後の画素値となります。 図：DCT変換 DCT変換後の画像はブロック単位（この場合は8×8の画像）になります。分割した数だけDCT画像（係数）があるのでこの状態では圧縮されていません。画像が周波数情報に変わっただけです。 これを体験できるアプリも同様にGeminiを使って作りました。 DCT/IDCT可視化ツール 画像を入力し、クリックして範囲を指定するとその部分に対してDCT係数を計算することができます。出力されたDCT係数に対して全範囲を選択して逆DCTをすることで、元の画像に戻すことができます。当然範囲を限定して逆DCTをかけると圧縮によって元の画像とは少し違う結果となります。出力された表を見るとその画像の局所的なDCT係数がわかりますが、各係数がその周波数の影響を与える大きさだと思っていただけるといいです。ぜひいろんな条件で試してみてください。（逆DCT結果の画像がグレースケールなのはYUVのY成分のみで計算しているためです。） まとめ 動画圧縮の仕組みについてYUVとDCTを用いる部分について簡単なアプリを使って解説しました。YUVを用いることで色差情報を削ることができ、DCTを用いて画像を周波数成分にすることで画質に影響を与えない情報に絞って削ることができることがわかりました。大学で習っている当初はあまり何に使うのか理解できなかったフーリエ変換などの概念も、割と様々な場面で出てくることが多いので、昔の自分にしっかりやっておくよう忠告したいところです。 また私が調べていたときは、出力結果画像の差でみることができるYUVはまだしも、DCTに関しては64パターンの謎の画像（基底関数画像）の意味がずっとよくわからなかったので、今回のアプリで誰かの理解の助けになるとうれしく思います。 余談ですが、最近買った「H.264/AVC教科書」が図も交えてしっかり書かれていて個人的におすすめです。この記事で動画圧縮の仕組み等に興味を持ってくださった方は読んでみてもいいかもしれません。

こんにちは、iOS エンジニアの @monolithic_adam です。 iOSDC Japan が近づきましたね。今年は新しい会場で楽しみにしています。 #Safie は今年初めてシルバースポンサーとして参加させていただきます！ 会場にてセーフィーのメンバーを見かけたら、ぜひ声をかけてください。 iOSDC Japan 2025参加情報 ノベルティー パンフレット クラウド録画サービス「Safie」について Our App Safie Viewer（セーフィー ビューアー） 最後に We are hiring! iOSDC Japan 2025参加情報 ノベルティー セーフィーオリジナルのアンブレラマーカーです。 ノベルティー付きチケットの方にはお届けされるはずなので、ご活用ください！ パンフレット iOSDCブック内のパンフレットにも、以下の内容を掲載させてもらっています。 是非ともご覧ください！ クラウド録画サービス「Safie」について 今年スポンサーとして初参加ということもあり、Safie（セーフィー）というサービスについてご存じない方ばかりかと思います。 この場で簡単にSafieについてご紹介させてください。 Safieのサービスについて 一言で言うと、カメラの映像をクラウド化するサービスで、iOSアプリとしてはカメラを操作したり、映像を閲覧するといった機能を提供しています。 Our App ということで、次にiOSアプリについて紹介させてください！ Safie Viewer（セーフィー ビューアー） アプリは こちら からダウンロード可能 デモ機能により、無料・アカウントなしで体験可能です #SafieViewer ではいくつか特徴的な機能を提供する必要があり、 動画の再生 WebRTC / HLSのハイブリッド動画配信に対応 イベントや録画有無を表示するためのリッチなシークバー 広角撮影して歪んだ動画を3D空間で補正 参考: セーフィーの新製品「Safie Go 360」のAndroid実装 - Safie Engineers' Blog! トークバック機能 アプリから音声を入力、 WebSocket を経由してカメラから音声を再生 といった技術的にも面白い部分が色々とあります。 最後に 今年は新しい会場ですし、セーフィーも初スポンサーで色々とワクワクしています！ 会場でセーフィーくんのTシャツを着ている人を見かけたら、是非ともお話ししましょう！ 最高にiOSDCを盛り上げていきましょう！！ ※ iOSDCに関しての最新情報は公式サイトや各イベントページをご確認ください 他社様と合同で非公式のアフターイベントもやります！ yumemi.connpass.com We are hiring! モバイルチームでは、多様な環境で世界に向けたアプリをともに開発する仲間を募集しています！ open.talentio.com

はじめに こんにちは、データドリブン推進室でデータエンジニアをやっている鶴です！ 先日、 OSS BIツールについてのブログ記事 を同じチームの小宮が投稿しておりましたが、その中でご紹介していた「Lightdash」でカスタムチャートという機能があります。 個人的に気になっていた機能だったので実際に触ってみてどのような感じで使えるのか、グラフはどんな感じになるのかご紹介したいと思います！ はじめに Lightdashのカスタムチャートとは カスタムチャートを触ってみる 最後に Lightdashのカスタムチャートとは Lightdashには 公式ドキュメント に記載があるように標準でさまざまなチャートを使うことができます。 2025/06時点では以下の10個のチャートがあり、普通に使う分には困らない感じです。 表 (Table) 円グラフ (Pie chart) ファネルチャート (Funnel chart) 棒グラフ (Bar chart) 面グラフ (Area chart) 折れ線グラフ (Line chart) 横棒グラフ (Horizontal bar chart) 散布図 (Scatter chart) 複合グラフ (Mixed chart) 数字表示 (Big Value) 参考：積み上げ棒グラフのイメージ 更にLightdashではビジュアライゼーションの表現の幅を上げる機能として カスタムチャート 機能があります。 この機能は Vega‑Lite をベースとした高度なビジュアライゼーション機能で、Lightdash上で標準グラフではできないようなグラフスタイルや細かい設定をJSONベースで作成できます。 （なお、こちらの機能は公式ドキュメントに記載があるようにまだベータ版となっておりますのでご注意ください） 使い方としてはとても簡単で以下のようにしていくと使えます。 「Query from tables」で対象テーブルを開く 対象ディメンションとメトリクスを選択し、Chartの「Configure」をクリック チャート設定の「Chart type」のリストの中にある「Custom」をクリック JSON編集画面が出てきます（簡単に編集できますね！） またこのカスタムチャート機能ですが最近の アップデート でテンプレート機能が搭載され、より触りやすくなりました！ 今回は気になったいくつかのチャートを試しに作ってみてどんなグラフができるのか試してみます！ カスタムチャートを触ってみる 最近実装されたテンプレートはカスタムチャートを開いた時に表示される「+Insert template」から選ぶことができるようです。 テンプレートをクリックするとJSONコードが生成され、自動的に集計対象がマッピングされる感じになってます。 このfieldで利用されている項目はResultsの下にあるSQLで自動生成されたSQLの項目名を利用しているようです。 なお、利用する項目によってうまく表示されなかったりするのでその場合は編集して調整して利用しましょう。 それでは気になっていたグラフをそれぞれ見ていきたいと思います！ 棒グラフ (Bar chart) テンプレートを利用して適当に作成したサンプルデータの商品カテゴリと売上を使って棒グラフを選んでみました。 テンプレートを使うことでワンクリックで棒グラフが作られました！ 当たり前ではありますが見た目は標準の棒グラフと変わらない感じですね。 ヒートマップ 会員ランクと地域の会員平均年齢を使ってテンプレートを使ってみましたがうまく項目が選ばれなかったため手動で編集し作成してみました。 現在ヒートマップは標準グラフにはなく、カスタムチャートのみの機能になるためこちらを使うことになりそうですね。 バブルチャート 商品カテゴリと売上、平均単価、平均顧客年齢を使い散布図のバブルチャートを作成してみました。 軸の scale プロパティで年齢のスケールを30歳以上にすることで見やすくしています。 おそらく標準の散布図ではサイズオプションがなかったためバブルチャートは作れないと思われますので利用したい方はこちらを使うことになるかなと思います。 分散積み上げ棒グラフ(人口ピラミッド) 次はテンプレートにないものを作ってみます。 vega-liteのexampleを眺めていて気になった 人口ピラミッド です。 サンプルコードを見よう見まねで作ってみたところいけました…！ こういった手の込んだグラフはBIツールで作る経験がなかったので作れるんだなと感動しちゃいました。。。 こういったチャートが作れるのはメリットですね。 Tableauのリファレンスライン的な平均ライン 最後に棒グラフ上に平均ラインを 表示 させるexampleも試してみましたが苦戦しつつも表示できました。 なんだかんだ使うことありそうなラインです。 コードの工夫の仕方によっては目標値等のラインを設定できるのではと思います。 最後に 気になっていたカスタムチャートのいくつかのグラフや機能を触ってみました。 Lightdashはまだまだ成長の段階で他のBIと比べてビジュアライゼーションの面で実現できないことがあったりしますが、このカスタムチャート機能を使うことで痒いところに手が届くいい機能だなと思います。 しかしながらUIでぽちぽちっとグラフを作るようなBIツールの本来の操作と比べたらやはり難しい部分もあり、JSONコードを編集して作るのは苦労する面もありますのでChatGPT先生等にご教示いただきながら作ってみるといいかもしれません。 公式サイトにはサンプルコードがあるので流用できる部分も多いと思います。 またこのLightdashですが2025年6月現在でも高頻度で アップデート が行われており、今後も機能がさらに充実していくと思いますし、自分自身もかなり期待しています！ Lightdashのチャート機能が気になっている方々の参考になれば幸いです！

2025年新卒として開発本部に配属されました、恩智太陽です。 早速ですが若手エンジニアの皆さん、セキュリティを意識してコーディングできていますか？ 私はセーフィーに入るまでほぼ意識せずWebアプリ開発など行っていました… IT業界においてセキュリティは理系、文系どちらに行っても切っても切り離せない英語のような重要な存在です。 そんなセキュリティの学習をおろそかにしてしまうと、どんなにいいサービスを作ったとしても、悪意のある人の手によって台無しにされてしまうことがあります。 それぐらいとても重要な分野ですが、セーフィーでは新卒研修の一環として座学＋ワークショップ＋ハンズオン形式で実施するセキュリティ研修があります。 この記事の前半では研修で何を学んだのかについて、後半では学んだことをどのように業務でアウトプットしたのかをご紹介します。 はじめに この記事で伝えたいこと 誰向けの記事？ 座学：アジャイルと脅威モデリングについて ワークショップ：脅威モデリングを実践！ 4つの問いに対して行ったこと ステップ1：DFDで「私たちは何に取り組んでいるか？」を明確にする ステップ2：STRIDEで「何が問題になりうるか？」を洗い出す ステップ3 ：リスクマップで優先順位をつけて対策を考える ステップ4：＋／Δ (プラス／デルタ)で振り返える 完成後にチームごとに発表 このワークショップで感じたこと 脆弱性診断ハンズオン：ハッカーになって攻撃してみた データベースの情報を抜き取ってみる SQLインジェクションの本当の恐ろしさ 脆弱性診断ハンズオンで感じたこと アウトプット：セキュリティ研修で得た知識を実践へ！ 新卒研修プロジェクトに取り入れる ①設計の土台である非機能要件に反映 ②作った機能に「攻撃」を仕掛けてみる まとめ はじめに この記事で伝えたいこと セーフィーのセキュリティ研修の概要について 学んだことをどのように仕事に生かしたのか 誰向けの記事？ セキュリティの重要性をあまり認識していない方（開発者） 攻撃手法の概要は把握しているが、具体的な攻撃のイメージがついていない方 どんなところに脆弱性が潜んでいるのかイメージできない方 座学：アジャイルと脅威モデリングについて 研修の前半では、まず アジャイル開発 について学び、その後に 脅威モデリング を学びました。 私自身、「アジャイル開発」というものは知っていたのですが、「なぜセキュリティの研修なのに、なぜアジャイル開発の話から始まるんだろう？」というのが正直な感想でした。 それは、アジャイル開発の強みである「スピード」が、セキュリティ対策の遅れで弱点に変わるからです。開発終盤での設計の修正は、多大な手戻りとコストがかかってしまいます。 そこで重要なのが、セキュリティ対策を開発初期から行う「シフトレフト」という考え方です。 開発のスピードと安全性を両立させるためには、まずその土台となるアジャイル開発の全体像を理解することが不可欠だったのだと、深く納得しました。 出典：Security Compass - How to Sell Security Training Costs Internally https://www.securitycompass.com/blog/how-to-sell-training-costs-internally-2/ （2025年7月30日アクセス） ※「設計段階(青)」で不具合を見つけて修正するコストを基準の1とした時、「開発段階(橙)」、「テスト段階(灰)」、「リリース段階(黄)」それぞれで対応した時のコストのかかり方 脅威モデリングとは、システムに対して「どのように攻撃が発生しうるか」を体系的に分析し、具体的な攻撃経路やリスクを特定するためのリスク分析手法であり、シフトレフトを実践するための強力なプラクティス（実践手法）の一つです。 この手法の強みは、設計段階で 潜在的な問題 を 早期に発見・修正 できるため、後の工程での修正コストを最小限に抑えることができるということに加え、「チーム内の共通理解を形成できること」があります。 DFD（データフロー図）のようなモデルを使うことで、チーム全員が同じ図を見て同じ目線で「システムがどのように攻撃されうるか」を議論できるようになります。 研修を受ける前の私は、正直なところ「セキュリティ対策＝実装段階でのコーディングにて対策」というイメージでした。 しかし、この研修を通してシステムの設計そのものに脆弱性が潜む可能性や、チーム全体で脅威について対話し、共通認識を持つことの重要性を学びました。 セキュリティは専門家だけの閉じた仕事ではなく、開発に関わる全員で対話し、作り上げていくことが重要だと、セキュリティに対する考え方が大きく変わる経験となりました。 ワークショップ：脅威モデリングを実践！ 座学の後は、チームに分かれて脅威モデリングのワークショップを体験しました。 課題は、タスク管理Webアプリ（脆弱性診断ハンズオンで用いる「 Bad Todo List 」）の要件をベースに、どのような脆弱性があるのかを、脅威モデリングの「4つの問い」に沿って考えていくというものでした。 タスク管理Webアプリ（脆弱性診断ハンズオンで用いる「Bad Todo List」）の要件（研修資料から抜粋） ワークショップの流れについては「 セーフィーの脅威モデリングベースのセキュア開発トレーニング 」の記事をご確認ください。 4つの問いに対して行ったこと ステップ1：DFDで「私たちは何に取り組んでいるか？」を明確にする 脅威モデリングの最初の問い、「私たちは何に取り組んでいるか？」を明確にするため、今回は一般的に使われる「DFD (データフローダイヤグラム)」を用いてシステムの全体像を分析しました。 DFDの要素（研修資料から抜粋） DFDは、システムにおけるデータの「流れ」と「処理」を視覚的に表現する図で、詳細な動作(How)よりも「何をするのか(What)」を明らかにすることに長けています。 DFDの矢印はあくまでデータの流れ（Data Flow）のみを記述しなければならず、書き始めはこのルールになかなか慣れませんでした。 つい「データを取得するリクエスト」のような、処理の制御に関する矢印を何度も書きそうになり、苦労しました。 ですが、Bad Todo Listの要件から上記のようなDFDを作成していくと、要件を見ただけでは気づけなかった視点や懸念点が次々と浮かび上がってきました。 ステップ2：STRIDEで「何が問題になりうるか？」を洗い出す 次に、「何が問題になりうるか？」という問いに答えるため、 「STRIDE」 というフレームワークを使って「起きたら困ること（リスク）」を洗い出しました。 STRIDEは、以下の6つの観点から脅威を分類する「型」です。 STRIDEの説明（研修資料から抜粋） このフレームワークを用いることで、攻撃者の動機や目的といった、より高い視点から体系的に脅威を分析することができます。 作成したDFDの各機能やデータの流れに対して、 「ユーザー情報登録の際に、大量の登録リクエストが送られてくると、データベースが破壊される可能性があるから D(サービス拒否) が当てはまる」 「タスクの編集の際に、タスクを勝手に書き換えられたり、消されたりする可能性があるから S(なりすまし )と T(改ざん) が当てはまる」 などとSTRIDEの観点を当てはめていくことで、具体的なリスクを次々と見つけることができました。 私が作ってきたアプリも世の中に公開した場合、こんな風に攻撃者の視点で見られていたのかもしれないと思うと、少しぞっとしました。 ステップ3 ：リスクマップで優先順位をつけて対策を考える 多くのリスクを洗い出すと、次に「では、それに対して何をするのか？」を考えます。 しかし、すべてを一度に対策しようとすると、本当に危険なリスクへの対応が遅れてしまう可能性があります。 そこで、 「リスクマップ」 を使い、対策の優先順位を決めました。 研修で説明されたリスクマップ（研修資料から抜粋） これは、 「リスク＝発生確率 × 影響度」 という考え方に基づき、「発生しやすさ」と「発生した場合の被害の大きさ」で評価し、優先順位をつけていく手法です。 今回の要件では、タスクの情報などを保存するデータベースに関する攻撃が一番「影響度」が高く、「発生確率」に関しても攻撃しやすい箇所であると考えました。 よって、「データベースに大量の登録処理が行われ、データベースが破壊される」というリスクを「発生確率」「影響度」ともに 5 と設定し、一番優先度が高いものとしました。 このステップを通して、やみくもにすべてのリスクに対策するのではなく、最も危険なリスクから対処するという、現実的かつ合理的な手法を学びました。 ステップ4：＋／Δ (プラス／デルタ) で振り返える 各スプリントの最後には、 「＋／Δ (プラス／デルタ)」 という手法で振り返りを行いました。 これは、活動の良かった点（プラス）と改善点（デルタ）を出し合う手法です。 「＋／Δ (プラス／デルタ)」のアウトプットイメージ（研修資料から抜粋） 最初のスプリントで、私たちはタスクの「追加」「編集」「削除」をそれぞれ別のプロセスとしてDFDに書き出しました。しかし、結果的に3つのプロセスに繋がるデータの流れは、ほぼ同じ内容になってしまったのです。 この結果から、私たちは「 プロセスの粒度をきちんと決めずに書き始めてしまった 」という改善点（デルタ）を見つけ出しました。 この気づきを元に、次のスプリントではまず「データの流れが同じ処理は、一つのプロセスにまとめよう」と決めました。 その結果、DFDの粒度が統一されてプロセスが整理されただけでなく、同じリスクに対する付箋も一つに集約でき、格段に見やすい図に改善することができたのです。 この振り返りがあったことで、今回のスプリントで良かったことは引き続き継続し、改善点は次回のスプリントで意識して行動することができたため、アジャイル開発ととても相性のいい手法だと感じました。 完成後にチームごとに発表 ワークショップの最後にチームごとに作成したDFDをそれぞれ発表しました。 プロセスの粒度の違い、ユーザー権限ごとに表を分けて分析していたりなど、考え方の違いや、ホワイトボード、付箋の使い方が各チームそれぞれ個性があり、全く系統の違うDFDが完成していたので非常に面白かったです。 チームによってアプローチが異なり、多様な視点に触れることができました。 3チームのホワイトボード このワークショップで感じたこと この一連のワークショップを通して、脅威モデリングを行う上で便利なワークフローが多く存在し、それを用いることによって最初からでは気づけなかった脆弱性やリスクの大きさに気づくことができたため、ワークフローの有用性を改めて感じました。 一方で、「フレームワーク通りにやれば安心」という「罠」に陥ってはいけない、という講師の金原さんの言葉が印象に残っています。 最も重要なのは、フレームワークを参考にしつつも、チームや顧客との対話を続け、学び、改善し続けることなのだと実感しました。 脆弱性診断ハンズオン：ハッカーになって攻撃してみた 研修の最後に、実際に脆弱なWebアプリケーション（やられアプリ）に対して攻撃を仕掛けるハンズオンを行いました。 ローカルプロキシ「Burp Suite Community Edition」を使い、ハッカーが実際に脆弱性をどのように見つけ、どのように攻撃するのかを体験しました。 ここでは、代表的な攻撃である SQLインジェクション をどのように体験したかを紹介します。 SQLインジェクションは、アプリケーションが想定しないSQL文を意図的に実行させ、データベースを不正に操作する攻撃です。 (出典)IPA - 1. 安全なウェブサイトの作り方 - 1.1 SQLインジェクション https://www.ipa.go.jp/security/vuln/websecurity/sql.html （2025年7月30日アクセス） 今回は先のワークショップでリスク分析をした「 Bad Todo List 」という脆弱性を持ったアプリケーションで体験しました。 注意⚠️ 本記事で紹介している内容はあくまで学習目的で、特別な許可のもと安全な環境下で実施したものです。 許可なく第三者のウェブサイトやシステムに対して、脆弱性を試すような行為を行うことは法律で固く禁じられておりますので、ご注意ください。 サイトにアクセスしてみると、以下のようなごく普通のTodoアプリの画面が表示されますが、このサイトにはいたるところに脆弱性が潜んでいます。 Bad Todo Listのタスク一覧画面 データベースの情報を抜き取ってみる 脆弱性のある入力フォームに「 パソコン' OR 'a'='a 」と入力してみます。 これを入力すると、プログラムの内部ではSQL文が次のように組み立てられます。 ... AND todo LIKE ' パソコン ' OR ' a ' = ' a ' ; この命令文は、データベースに対して「 Todoに『パソコン』と書かれている 」または(OR)「 『a』と『a』は等しい 」という条件でデータを要求します。 「 'a'='a' 」は常に真（true）なので、結果として「 すべての条件を無視して、データベースにある情報をすべて表示しろ 」という命令に変わってしまうのです。 その結果、以下の画像のように、公開、非公開の設定（画像右側）に関係なくすべてのデータベースの情報が表示され、見えてはいけない重要な情報が見えてしまいます。恐ろしい… Bad Todo ListでSQLインジェクションを検証した結果画面 SQLインジェクションの本当の恐ろしさ 表示されている情報をすべて抜き取れるだけでも十分に恐ろしいですが、SQLインジェクションの危険性は これだけではすみません。 攻撃者は、この脆弱性を利用してさらに悪質な攻撃を仕掛けることができます。 個人情報の窃取 UNION といった特殊な命令を組み合わせることで、Todoリストだけでなく、システムに登録されている全ユーザーのID、メールアドレス、さらにはパスワード情報まで盗み取ることが可能です。 データの改ざんと削除 情報を盗むだけでなく、データベース内の情報を自由に書き換えたり、全てのデータを削除したりすることもできてしまいます。 サーバーの乗っ取り データベースの設定によっては、SQLインジェクションを足がかりに、最終的にWebサーバーそのものを乗っ取られてしまうケースさえあります。 このように、たった一つの入力欄の不備から、システム全体を揺るがす甚大な被害に繋がりかねないのが、SQLインジェクションの本当の恐ろしさなのです。 脆弱性診断ハンズオンで感じたこと このような形で様々な攻撃手法を実践的に学びました。 SQLインジェクションだけでも深刻な被害につながるのに、Webアプリケーションには他にも無数の攻撃経路が潜んでいるという事実に、「一体どうすればこんな攻撃を思いつくのか」と、その発想力に圧倒されるばかりでした。 これまでは「どうすれば動くか」という「作る側」の視点でしかコードを見ていませんでしたが、この研修では「どうすれば壊せるか」という「攻撃される側」の視点を初めて得ることができました。 アウトプット：セキュリティ研修で得た知識を実践へ！ ここからは、セキュリティ研修後に私がどのようなアウトプットを行ったかを紹介します。 新卒研修プロジェクトに取り入れる 現在、私たち新卒エンジニアは社内の課題を解決するシステムを開発するという研修に取り組んでいるのですが、そこで今回のワークショップやハンズオンで学んだ対策を盛り込みました。 ①設計の土台である非機能要件に反映 まず、プロジェクトの設計の土台となる非機能要件に、今回の研修で学んだ攻撃手法から実際に作るシステムでどんな脆弱性が考えられるかを洗い出し、それに対する対策を具体的に定義しました。 分類 項目 対策内容 アクセス・利用制限 アプリケーションレベルのアクセス制限 SlackOAuthを通して、許可された利用者（@safie.jpアカウント）のみがシステムを利用できること。 アクセス・利用制限 安全な認証・セッション管理 JWTを利用し、サーバー側で電子署名を検証することでデータの完全性を担保する。 脆弱性対策 SQLインジェクション対策 DBへの問い合わせはプレースホルダを用い、不正なSQL実行を防御する。 脆弱性対策 クロスサイトスクリプティング（XSS）対策 ユーザー入力値をWebページに表示する際は、適切にエスケープ処理を行う。 脆弱性対策 クロスサイトリクエストフォージェリ（CSRF）対策 トークンを用いて、意図したユーザーからのリクエストであることを検証する。 このように開発の初期段階からセキュリティを要件として定義することで、後工程での手戻りを防ぎ、まさにセキュリティ研修で学んだ「シフトレフト」の考え方を実践することができました。 ②作った機能に「攻撃」を仕掛けてみる 次に、定義した非機能要件の一つ、「アプリケーションレベルのアクセス制限」を実装し、実際にテストを行いました。 この機能は、許可されたドメイン（@safie.jp）以外のアカウントではログインできないようにするものです。 研修でお世話になった講師の金原さんに協力をお願いし、脆弱性診断で使った「Burp Suite」を用いて、外部のメールアドレスでログインを試みる擬似的な攻撃を仕掛けてもらいました。 「本当に防げているのだろうか？」という漠然とした不安が、Burp Suiteの画面でどのようなリクエストが飛んできて、どのようにデータが処理され、どのように外部からのメールアドレスがはじかれているかを可視化でき、設計したセキュリティ機能に自信を持つことができました。 実際の検証の様子 まとめ 今回のセキュリティ研修では、座学でのインプットだけでなく、脅威モデリングワークショップや脆弱性診断ハンズオンといった実践的な演習を通して、セキュリティの知識を深く理解することができました。 特に、実際に手を動かして攻撃者の視点を体験したことで、これまで漠然としていた脅威が、具体的なイメージ（勘所）として掴めるようになったのが一番の収穫だと感じています。 この研修で得た学びを活かし、今後の開発業務では開発初期段階から常にセキュリティを意識し、安全なプロダクト作りに貢献していきたいと思います。 25年度新卒研修に関する記事はこちらをご覧ください。 2025年、新卒エンジニア研修はじめました Notion初学者のためのショートカット活用術：業務効率を上げる第一歩 100人をマネジメントした指揮者が 新卒で挑戦した「不確実性」と向き合うチームビルディング 新卒一年目のエンジニアが感じた、プレ開発で見えたチームの“成長” ゼロから学んだフロントエンド実装 毎日の日報報告をワンボタンで ハッカーの視点を身に付ける！新卒が学んだセキュリティ研修 ← 本記事

はじめに こんにちは！セーフィーでサイバーセキュリティを担当している金原です。 以前のブログでは「 セーフィーのサイバーセキュリティ戦略の作り方 」や「 セーフィーのセキュリティチームづくり 」といったテーマで、私たちの取り組みを紹介させていただきました。 今回は、そのサイバーセキュリティ戦略の打ち手の一つである「セキュリティはみんなの仕事」を実現するためのトレーニングの実験として、アジャイル脅威モデリングをベースにした「新卒エンジニア向けのセキュリティ研修」を実施しましたので、その様子をご紹介します。 この記事が、エンジニアとしてセキュリティスキルを高めたい方、社内でのセキュリティ研修を企画されている方、そして脅威モデリングに興味がある方にとって、少しでも参考になれば嬉しいです。 なお、本記事は講師の私目線の記事です。 受講生の新卒エンジニア恩智さんの受講生目線の記事 も公開されてますので、合わせてご確認ください！ はじめに 大切にしたいのは「学習定着率」 コンセプトは「アジャイル脅威モデリング」 研修の全体像 アジャイル脅威モデリング（座学）の内容 脅威モデリングワークショップ（グループ討議）の進め方 脆弱性診断ハンズオン（自ら体験する）の進め方 フィードバック（効果検証） アジャイル脅威モデリング（座学）のアンケート結果 脅威モデリングワークショップ（グループ討議）のアンケート結果 脆弱性診断ハンズオンのアンケート結果 まとめ 大切にしたいのは「学習定着率」 皆さんは、研修で学んだ内容がどれくらい身についているか、意識したことはありますか？ ラーニングピラミッドによると、ただ講義を聞くだけの研修では、学習内容の定着率はわずか5%だと言われています。せっかくの研修が、それではもったいないですよね。 (出典)キャリア教育ラボ - 平均学習定着率が向上する「ラーニングピラミッド」とは？？ https://career-ed-lab.mynavi.jp/career-column/707/ （2025年7月25日アクセス） そこで今回の研修では、学習定着率がより高いとされる「 グループ討議 (50%) 」と「 自ら体験する (75%) 」を活動の中心に据え、学んだ知識がしっかりと身につくように設計しました。 コンセプトは「アジャイル脅威モデリング」 今回の研修のコンセプトは「 アジャイル脅威モデリング 」です。 「なぜセキュリティ研修でアジャイル？」と思われるかもしれません。 その理由は、アジャイル開発が多くのエンジニアにとって学びたいテーマであることに加え、その価値観や原則が、脅威モデリングを効果的に実践するための考え方と非常に親和性が高いからです。例えば、タイムボックス・プランニング・ふりかえりのようなアジャイルのプラクティスを活用することで、 対話を中心とした脅威モデリング を、楽しみながら実践できると考えました。 では、その「脅威モデリング」とは一体何なのでしょうか。 脅威モデリングは、開発するシステムにどのようなセキュリティ上の脅威（＝悪いことが起きる可能性）が潜んでいるかを、設計段階で洗い出すためのリスク分析手法です。「起きたら困ることは何か？」という視点でシステムの弱点を探し、事前に対策を講じることを目的とします。 このように、脅威モデリングは設計段階でセキュリティリスクを体系的に分析できるため、開発者が学ぶべきプラクティスとして最適です。「NIST SP800-218（Secure Software Development Framework）」や「OWASP SAMM 2.0」のようなフレームワークでも推奨されており 、これからの開発者にとって必須のスキルと言えるでしょう。 (出典) NIST Special Publication 800-218 https://nvlpubs.nist.gov/nistpubs/specialpublications/nist.sp.800-218.pdf （2025年7月25日アクセス） OWASP SAMM - About us https://owaspsamm.org/about/ （2025年7月25日アクセス） 研修の全体像 研修は丸一日かけて、以下の3部構成で行いました。 1. アジャイル脅威モデリング（座学） まずはアジャイルと脅威モデリングの基礎をインプット。座学で学んだ知識も、その後のワークで すぐに実践する ことで、定着率の向上を図ります。 2. 脅威モデリングワークショップ（グループ討議） アジャイルのプラクティスを活用しながら脅威モデリングを実践。チームで「 何が起きたら困るか 」など対話しながらリスクを洗い出します。 3. 脆弱性診断ハンズオン（自ら体験する） 実際に「やられサイト」を攻撃し、脆弱性がどのように悪用されるのかを 手を動かして 学びます。 アジャイル脅威モデリング（座学）の内容 座学パートでは、アジャイルと脅威モデリングそれぞれの「Why?」と「What?」を解説し、基礎知識を身に着けてもらいました。 脅威モデリングに関しては、実践するための以下の 4つの重要な問い を中心に進め方を説明しました。 【問１】私たちは何に取り組んでいるか？ 【問２】何が問題になりうるか？ 【問３】それに対して何をするのか？ 【問４】十分にうまくできたか？ また、最初の問い「私たちは何に取り組んでいるか？」に対する答えを可視化する DFD（データフロー図）の書き方 は、後のワークショップの質を高めるために、丁寧にレクチャーしました。 座学の様子。皆さん、真剣に説明を聞いてくれました。 脅威モデリングワークショップ（グループ討議）の進め方 知識は、使ってこそ初めて実践的なスキルとなります。 このワークショップでは、座学で学んだ脅威モデリングの進め方を、アジャイルのプラクティスを使いながらグループで実践します。 その目的は、単に手順をなぞるのではなく、対話を通じてリスクを発見する楽しさや、グループで協力して徐々にセキュリティを高めていくという、アジャイルと脅威モデリング双方の価値観や原則をリアルに体験してもらい、その活動やマインドセットを自分たちのものにしてもらうことにあります。 ワークショップは、以下の流れで進めました。 新卒2〜3名と先輩エンジニア1名でグループを組みます。（全3グループ） 各グループはホワイトボードを2枚使います。 ホワイトボードの1枚目は、脅威モデリング（モデル作成→リスクの洗い出し→対策検討）に使います。（【問１】～【問３】に該当） ホワイトボードの2枚目は、ふりかえりの内容を書き出します。（【問４】に該当） DFDはマーカーで書き込み、洗い出したリスクや対策は付箋で貼り付けます。 アジャイルのプラクティスを取り入れ、「 プランニング(10分) → 脅威モデリング(25分) → ふりかえり(10分) 」を1スプリント（45分）のタイムボックスとし、これを3回繰り返します。 脅威モデリングのお題として、分析対象アプリの要件を提示します。 なお、今回のお題は、後の脆弱性診断ハンズオンで用いる「やられアプリ（ Bad Todo List ）」として、【問１】のDFD作成からスタートしました。 ワークショップの様子。ホワイトボードを囲んで、活発に対話されていました！ ホワイトボード1枚目（DFDとリスク） ホワイトボード2枚目（ふりかえり） 最後にそれぞれのグループで成果を発表！ 脆弱性診断ハンズオン（自ら体験する）の進め方 このハンズオンの目的は、脅威モデリングで特定したリスクを、 攻撃者の視点で「追体験」する ことにあります。 頭で理解しただけの脅威も、自らの手で攻撃を成功させた瞬間に、生々しい実感へと変わります。この体験こそが、セキュリティを自分ごととして捉え、より安全な設計・開発につなげるための最も効果的な学びです。 具体的には以下のツールを使ってハンズオンを実施しました。 やられサイト : Bad Todo List 攻撃ツール : ローカルプロキシ「Burp Suite Community Edition」 また、取り扱う脆弱性は、IPAの「 安全なウェブサイトの作り方 」で紹介されている主要な脆弱性として、一歩ずつ解説しながら、実際にツールを操作して探してもらいました。 SQLインジェクション OSコマンド・インジェクション ディレクトリ・トラバーサル セッション管理の不備 クロスサイト・スクリプティング（XSS） クロスサイト・リクエスト・フォージェリ（CSRF） これらの脆弱性が、脅威モデリングで学んだ STRIDE のどの脅威カテゴリに繋がるのかをマッピングすると以下のようになります。 脅威と脆弱性のマッピング（研修資料から抜粋） そして、なんと今回のハンズオンには、『体系的に学ぶ安全なWebアプリケーションの作り方』の著者である 徳丸浩先生 に、特別ゲスト（オブザーバー）としてオンラインでご参加いただきました！徳丸先生、本当にありがとうございました！ 徳丸浩先生とハンズオン実施中の様子（画像が小さくて見にくいですが、ちゃんと徳丸先生ご本人がいらっしゃいます！） フィードバック（効果検証） 研修のゴールである「 セキュリティの勘所がわかる 」が達成できたかを検証するため、ワークショップで実践したふりかえりの手法「 +/Δ（プラス/デルタ） 」を使ってアンケートを取りました。 研修全体としては、研修のゴールの達成度は「 8.83点 （10点満点）」となりました。初回にしては及第点の効果を得ることができたのではないでしょうか。 研修全体の達成度 以下、それぞれのコンテンツのアンケート結果です。 アジャイル脅威モデリング（座学）のアンケート結果 座学でしたが、想定よりも満足度は高く、目的や手法が理解できたというフィードバックもいただけました。座学は学習定着率に難はありますが、知識の共通理解づくりという点ではワークの前に実施すれば効果が高まることが期待できます。 プラス（よかったこと） 「アジャイルの手法の詳細の説明、それを踏まえたうえでアジャイルを行う際の脅威モデリングについての解説があったため、話の道筋がわかりやすかった」 「知らない内容がほとんどで、かつ分かりやすく勉強になった」 「脅威モデリングがなぜ必要なのかがわかりましたし、DFDなど知らなかったことも知れた」 脅威モデリングワークショップ（グループ討議）のアンケート結果 満足度は非常に高く、ポジティブな意見が多く寄せられました。ワークショップ中は非常に活気があり、タイムボックスを区切って実施したことでメリハリも生まれたと感じています。 プラス（よかったこと） 「座学で学んだ内容をワークでアウトプットすることで、より知識を深められた。各スプリントもあっという間でした！」 「脅威の見つけ方が少しわかったし、単純に楽しかった」 「DFD, リスクマップ, STRIDEのフレームワークを実際に使用して脆弱性について考えることで知識が定着した」 脆弱性診断ハンズオンのアンケート結果 こちらは満足度にばらつきがあり、インプットが多くなりすぎた点が課題として残りました。 プラス（よかったこと） 「テストサイトで脆弱性を見つけていくのが楽しかった」 「事前学習である程度は理解していたが、どうやったら攻撃されるのかを実際に学ぶことができた」 デルタ（改善したいこと） 「もう少し後半、手を動かしながら学びたかった」 「実際に簡単なアプリを作ってから穴を探す形式の方が、実装と紐づきそうだと思った」 まとめ 今回は新卒エンジニア向けに「セキュリティの勘所を掴む」ことをゴールに研修を設計しました。 具体的には、オンラインでの事前学習（今回の記事では説明していませんが）から始まり、座学でのインプット、ワークショップとハンズオンでのアウトプットへと繋がる構成を取りました。アンケート結果からも、この一連の流れが知識の定着に効果的だったと感じています。 積極的に参加してくれた新卒エンジニアの皆さん、ありがとうございました！今回学んだ勘所を、ぜひ実際の業務で活かしてください。（来年も実施します！） もし、読者の皆様の組織でも「セキュリティが他人ごとになっている」と感じているなら、この「アジャイル脅威モデリング」のアプローチが、その文化を変えるきっかけになるかもしれません。本記事が皆様のお役に立てれば幸いです。