セーフィー株式会社 の技術ブログ
全221件
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のフレームワークを実際に使用して脆弱性について考えることで知識が定着した」 脆弱性診断ハンズオンのアンケート結果 こちらは満足度にばらつきがあり、インプットが多くなりすぎた点が課題として残りました。 プラス（よかったこと） 「テストサイトで脆弱性を見つけていくのが楽しかった」 「事前学習である程度は理解していたが、どうやったら攻撃されるのかを実際に学ぶことができた」 デルタ（改善したいこと） 「もう少し後半、手を動かしながら学びたかった」 「実際に簡単なアプリを作ってから穴を探す形式の方が、実装と紐づきそうだと思った」 まとめ 今回は新卒エンジニア向けに「セキュリティの勘所を掴む」ことをゴールに研修を設計しました。 具体的には、オンラインでの事前学習（今回の記事では説明していませんが）から始まり、座学でのインプット、ワークショップとハンズオンでのアウトプットへと繋がる構成を取りました。アンケート結果からも、この一連の流れが知識の定着に効果的だったと感じています。 積極的に参加してくれた新卒エンジニアの皆さん、ありがとうございました！今回学んだ勘所を、ぜひ実際の業務で活かしてください。（来年も実施します！） もし、読者の皆様の組織でも「セキュリティが他人ごとになっている」と感じているなら、この「アジャイル脅威モデリング」のアプローチが、その文化を変えるきっかけになるかもしれません。本記事が皆様のお役に立てれば幸いです。
こんにちは。25新卒エンジニアの緑川です。 この記事では、私が社内でのルーティンを自動化しようとして、うまくいったりいかなかったことについて紹介します。 目的 先輩に倣う Notionボタン Slackワークフロー NotionボタンからSlackへwebhook送信 失敗 多重投稿の防止 おわりに 目的 セーフィーの開発本部では、メンバーの勤務状況を把握するため、毎日仕事の開始時と終了時に「始業」「終業」のスタンプをSlackチャンネルへ送信するルールがあります。 さらに、我々新卒エンジニアは研修期間中、その日やったことについてまとめた日報をNotionに書き、報告に添付することになっています。 こんな感じ こんな感じ この投稿をするためには、 日報のURLをコピーする Slackに、 :syugyo: と打ち込む 改行して、 日報 と打ち込む 日報 の部分を選択 URLをペースト という、たいしたことはないものの毎日だと微妙に面倒くさい作業を要していました。 この日報報告の投稿を、たとえば、ボタンを一つ押すだけでできたら楽じゃないかと考えました。 先輩に倣う そんなことを１年先輩のトレーナーに相談すると、まさに同じことを去年やったと教えていただきました。やり方は以下の通りです。 GASのウェブアプリを作り、クエリパラメータつきのGETリクエストを送るとその内容がJSONでSlackに送られるようにする Notionの日報テンプレートに、クエリパラメータとして記事のIDと作成者を埋め込んだリンクを自動で作成する関数を置く 関数で生成されたリンクをクリックするとブラウザからGASにリクエストが飛び、それをもとにSlackに情報が送信される Slackで、 {名前} :syugyo: 日報 という投稿を行う sequenceDiagram ユーザー ->> Notion: 記事上の通知リンクをクリック Notion ->> GAS: クエリパラメータ(記事URLなど)を埋め込んだURLで遷移 Note over GAS: クエリパラメータからSlack向けJSONを作成 GAS ->> Slack ワークフロー: JSONを含んだPOSTリクエストを送信 Slack ワークフロー ->> 出退勤連絡チャンネル: 記事リンク付き終業報告を送信 これを拝借（コピペ）すれば目的達成！ ですが、それだけだと面白くないので、何かアップデートを加えたいものです。このやり方では、NotionとSlackの仲介役としてGASが使われています。このGASをなくし、SlackとNotionで直接通信することはできないか？と考えました。 Notionボタン Notionでは、ボタンというオブジェクトが使えます。 ボタンが押されると指定した処理が実行可能という便利な機能ですが、その中に Webhook送信 というものがあります。これは、POSTリクエストで指定URLにJSONを送信するというシンプルな動作をします。ここから作成者と記事のIDを送信するように設定することができれば、Slackを直接操作できそうです。 Slackワークフロー ここでSlack側の機能について説明します。今回終業報告の自動投稿に使ったのは、 Slackワークフロー です。これは特定のイベントが起きたときに設定した処理を実行できるという機能です。よって、Webhookを受信したときに、そこに含まれた情報を埋め込んだ投稿を指定チャンネルに送信するように設定します。 今回は、日報のURLを特定するのに必要な記事のID（notion_id）と書いた人の名前（name）を受け取るように設定し、それをメッセージに埋め込むことにします。 手順は以下の通りです。 Slack左下の「その他」から、「自動化」を選択 右上の「＋新しいワークフロー」を押す ワークフローの開始条件を「Webhook を使って開始する」 受け取る変数として、notion_idとnameを設定 指定チャンネルに受け取った情報を埋め込んだメッセージを送信するように指定 <ol start=5"> ワークフローのURLをコピーしておく NotionボタンからSlackへwebhook送信 いよいよNotionボタンからSlackへのWebhook送信を試してみます。 まず、日報の記事テンプレートの中にボタンを作成し、日報の記事には自動でボタンが準備されるようにします。そして、以下のようにWebhookの設定を行います。 /button コマンドでボタンを作成する。 下の画像のような設定画面が表示 実行を「Webhook」を送信する」に設定。 送信先のSlackワークフローURLを入力 「コンテンツ」の項目から送信したいページのプロパティを選択 これで完成！実際にボタンを押してSlackに投稿がされるかどうか試してみます。 失敗 しかし、 いくらボタンを押しても何も起きませんでした 。ここで、Notionから送信されるJSONの構造がどうなっているのか気にしていなかったことに気づきました。 調べてみると、Notionから送信されるWebhookに含まれるJSONは、設定した情報以外にも多くのメタデータを含み、階層も複雑になっていることがわかりました。一方、SlackワークフローではJSONの１階層目にあるキーだけを参照できるようでした。 { " notion_id ": " <id> ", " name ": " <name> " } 上は、Slackで受け取れるJSONのイメージです。階層構造はありません。 { " id ": " {ID} ", " timestamp ": " 2025-01-01T07:00:00.001Z ", " workspace_id ": " {ID} ", " workspace_name ": " {ワークスペース名} ", " subscription_id ": " {ID} ", " integration_id ": " {ID} ", " type ": " page.created ", " authors ": [ { " id ": " {ID} ", " type ": " person " } ] , " accessible_by ": [ { " id ": " {ID} ", " type ": " person " } ] , " attempt_number ": 1 , " entity ": { " id ": " {ID} ", " type ": " page " } , " data ": { // この値がほしい " parent ": { " id ": " {ID} ", " type ": " page " } } } 上はNotionから送られるJSONの例です。多くのメタデータが入り、階層構造になっていることがわかります。Slackで受け取りたいNotion記事の情報は data キーの下に入るため、Slackは直接取得することができません。 つまり、NotionボタンとSlackだけの連携は難しいようです。GASを削除するという目論見は潰えてしまいました。 多重投稿の防止 仕方がないので、GASの削除はあきらめ運用しました。お手軽に報告できるのは機能自体は好評でよく使われたものの、日報内をワンクリックするだけで終業報告を送ることができるという手軽さから、一つ問題が発生してしまいました。日報は書いた本人以外も読むことがあるので、その時に誤って通知ボタンをクリックされた結果、その時点で もう一度終業報告が投稿されてしまった のです。しかも、Slackでの送信元が日報を書いたユーザーではなくワークフローのbotになるので、投稿を削除することもできません。これでは困ります。 この問題を解決するために、以下のような方法を考えました。 GASで、記事IDをスプレッドシートに記録する。 リクエストが来るたびに、スプレッドシートを確認し、既存の記事IDだったらSlackへ情報を送らない これで、最初の一回しかSlackに通知が投稿できません。 以下はGASに実装したソースコードの全体です。 // GETリクエストが来たときに実行する関数 const doGet = ( e ) => { const params = e . parameter const workflow_url = "<SlackワークフローのURL>" ; if ( ! params . id || ! params . name ) return ContentService . createTextOutput ( "パラメータエラー発生: " + e . message ) ; const data = { "notion_id" : params . id , "name" : params . name } if ( is_artice_already_saved ( params . id )) { return ContentService . createTextOutput ( "指定された日報はSlackに投稿済みです " ) ; } save_article_id ( params . id , params . name ) try { UrlFetchApp . fetch ( workflow_url , { method : "POST" , contentType : "application/json" , payload : JSON . stringify ( data ) , }) } catch ( e ){ return ContentService . createTextOutput ( "Slackエラー発生: " + e . message ) ; } return ContentService . createTextOutput ( "退勤を登録しました!" + JSON . stringify ( params )) ; } // IDが登録済みか const is_artice_already_saved = ( id ) => { var sheet = SpreadsheetApp . getActiveSpreadsheet () . getSheetByName ( 'シート1' ) ; const idIndex = 1 ; // A列 const lastRow = sheet . getLastRow () ; const ids = sheet . getRange ( 1 , idIndex , lastRow , 1 ) . getValues () ; // 各セルの値を入力IDと比較 for ( let i = 0 ; i < ids . length ; i ++ ) { if ( ids [ i ][ 0 ] === id ) { return true ; } } return false ; } // スプレッドシートへの書き込み const save_article_id = ( id , name ) => { var sheet = SpreadsheetApp . getActiveSpreadsheet () . getSheetByName ( 'シート1' ) ; sheet . appendRow ([ id , name ]) } また、最終的なシーケンス図は以下のようになりました。 sequenceDiagram participant User participant Notion participant GAS participant GoogleSpreadsheet as Google Spreadsheet participant SlackWorkflow as Slackワークフロー participant SlackChannel as 出退勤連絡チャンネル User->>Notion: 記事上の通知リンクをクリック Notion->>GAS: クエリパラメータ(記事IDなど)を埋め込んだURLで遷移 Note over GAS: クエリパラメータからSlack向けJSONを作成 GAS->>GoogleSpreadsheet: 記事IDの存在確認 alt 記事が存在する GoogleSpreadsheet-->>GAS: 記事IDが存在する Note over GAS: 処理を終了 else 記事が存在しない GoogleSpreadsheet-->>GAS: 記事IDが存在しない GAS->>SlackWorkflow: JSONを含んだPOSTリクエストを送信 SlackWorkflow->>SlackChannel: 記事リンク付き終業報告を送信 end GASでの処理に、スプレッドシートに記事が記録されているかどうかの条件分岐が追加されました。この対策を行ったあと意図しない終業報告がされる事故は起こっていません。 自動終業報告の様子 自動終業報告の様子 上は、実際に終業報告が行われている様子です。 おわりに 結果的にはほとんど先輩の作ったものの模倣にはなってしまいましたが、このシステムの制作を通じてアプリ間の連携方法について知見を得ることができました。たとえば、同期の間で読んだ本や参加した勉強会についてNotionで紹介する場があるのですが、その更新通知を自動でSlackに送信する仕組みを整備できました。 また、なによりも実際に同期の新卒メンバーに作ったものが毎日使われているのがうれしいです。今後は課題を見つける能力と技術知識をさらに鍛え、ユーザーの課題を解決できるエンジニアになりたいです。 25年度新卒研修に関する記事はこちらをご覧ください。 2025年、新卒エンジニア研修はじめました Notion初学者のためのショートカット活用術：業務効率を上げる第一歩 100人をマネジメントした指揮者が 新卒で挑戦した「不確実性」と向き合うチームビルディング 新卒一年目のエンジニアが感じた、プレ開発で見えたチームの“成長” ゼロから学んだフロントエンド実装 毎日の日報報告をワンボタンで ← 本記事 ハッカーの視点を身に付ける！新卒が学んだセキュリティ研修
はじめに こんにちは。2025年度新卒入社しました川上達也です。 この記事では新卒開発研修の中で個人的に開発したRaspberry Piを使ったアプリについてお話しします。 私のこれまでの開発経験はPythonによるAI開発のみで、バックエンドやサーバーサイドといった概念も考えずに開発していました。 入社後に行う開発研修では新卒エンジニア7人で社内課題を解決するプロダクトを作ります。このプロダクト開発をチームで円滑に行うために、開発を始めるより先に新たな技術領域を身につける必要がありました。 そのためプロダクト開発に先駆けてプレ開発として、「近くでも遠くでも忙しさがわかるアプリ」を作りました。近くにいるときはRaspberry Piの画面で、遠くにいるときはSlackのステータスで「忙しい」、「話しかけてもいいよ」、「お昼寝中」の3つの業務状態を確認できます。 この記事ではプレ開発を通して身につけたフロントエンド開発の成果を伝えようと思います。 はじめに 作ったもの システムの説明 動作の説明 Reactの処理 FastAPIの処理 所感 作ったもの 今回、SlackのステータスをRaspberry Piから更新するアプリを作りました。Raspberry Piに接続したタッチディスプレイから入力を行い、Slackのステータスの更新を行います。 実際に使っている様子は次の画像のようになります。 アプリを起動すると次の画像の左側のようにStartと書かれた状態で画面が表示されます。この状態はSlackのステータスには影響を与えません。 その後3つのボタンを押すとそれぞれのボタンに対応したステータスにSlackとWebクライアントで更新が行われます。 この時にSlackでも更新が行われます。 システムの説明 アプリのユースケース図を示します。 ユーザーがステータスの入力を行うと、そのステータスをWebクライアントで表示します。 そしてシステム構成は次のようになります。 Raspberry Piでユーザーの入力を処理するWebクライアントとSlackサーバーにリクエストを送信してステータスを更新するAPIサーバー両方の機能を持っています。 WebクライアントはReactで、APIサーバーはFastAPIで実装しました。 動作の説明 ここでWebクライアントを実装するReactの処理とSlackステータスの更新を行うFastAPIの処理を説明します。 Reactの処理 入力処理 予め想定してある3つのステータスに合わせたボタンを3つ生成します。それぞれのボタンに onClick イベントと key を設定しておき、押されたボタンに応じたステータス表示とリクエストの送信を行います。 const Status = ["busy", "free", "sleep"] {Status.map((work) => ( <button className="btn-color" key={work} onClick={() => onClickButton(work)}> {work} </button> ))} ステータス表示 useState を使い、押されたボタンの持つ key に対応する画像と文字列をそれぞれ状態として表します。ボタンが押された時に状態の更新が行われ、新たな画像と文字列が状態に設定されます。そして状態が変更されるとレンダリングが実行され、画面に表示されるステータスが変更されます。 const onClickButton = (work:string) => { const [workStatus, setWorkStatus] = useState<string>("Start"); const [imgPath, setImgPath] = useState<string>(sunImg); setWorkStatus(work) if (work === "busy"){ setImgPath(busyImg) }else if (work === "free"){ setImgPath(freeImg) }else if (work === "sleep"){ setImgPath(sleepImg) } send_request('http://localhost:8000/api/update_status', work) } リクエストの送信 fetch APIを使ってReactからFastAPIへPOSTリクエストを送信します。その際に async/await 構文を使い、非同期処理を実装します。このPOSTリクエストでは押されたボタンに対応する key を送信します。 const send_request = async (req:string, work:string) => { try { const requestOptions = { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ work: work }) }; fetch(req, requestOptions) .then(response => response.json()) } catch { console.log("error") } } FastAPIの処理 ステータスのセット FastAPIではまずReactからPOSTリクエストを受け取ります。このPOSTリクエストではユーザーが押したボタンに対応する key を受け取ります。この key を使い、Slackサーバーに送信するための text ステータスと emoji ステータスを設定します。 text ステータスと emoji ステータスをSlackサーバーに送信すると、 text ステータスはそのままステータスの文字として、 emoji ステータスは emoji ステータスに対応した絵文字として、ステータスが更新されます。 from fastapi import FastAPI, Query from slack_sdk import WebClient @app.post('/api/update_status') async def UpdataStatus(data: Work): SLACK_BOT_TOKEN = "xxx" if data.work == "busy": status_text = data.work status_emoji = ":working-in-office:" elif data.work == "sleep": status_text = data.work status_emoji = ":zzz:" elif data.work == "free": status_text = data.work status_emoji = ":good-nya:" リクエストの送信 slack_sdk の WebClient を使って、 text ステータスと emoji ステータスをユーザーの token とともにSlackサーバーへ送信します。Slackサーバーが受け取った token によりユーザーを識別して、ユーザーのステータス更新が行われます。 client = WebClient(token=SLACK_BOT_TOKEN) try: response = client.users_profile_set( profile={ "status_text": status_text, "status_emoji": status_emoji, "status_expiration": 0 }) except Exception as e: print(f"unexpected error: {e}") このようにして更新されたステータスはSlackとWebクライアントで次の画像のように表示されます。 💤 sleepとなっているところがステータスです。SlackでもWebクライアントでも同じステータスを表示することができます。 また更新可能な3つのステータスはそれぞれ次の業務状態を想定しています。 忙しい時・作業に集中したい時 余裕のある時 お昼寝中 所感 このアプリ実装を通して、これまで開発経験のなかったフロントエンドやAPIの実装をすることができました。ReactとFastAPIを連携させましたが、React単体でも実装できるアプリであったのでFastAPIを使う必要はありませんでした。今回は「エンジニアとして成長する」という研修の目的を意識しReactとFastAPIを連携させる構成を選択してより多くの技術に触れました。この構成は、それぞれの技術の役割分担や連携方法を学ぶ上で非常に有益でした。一方でどのような技術選択が最適なのかを考えることも、今後は行わなければならないところではあります。 現在私は開発研修の中でチームのふりかえり会の運営を担当しています。ふりかえり会の一つとしてチームメンバー同士で褒め合うことをしました。その進行方法は、次のように設定しました。 チームメンバーから1人 褒める人 、もう1人 褒められる人 を選択する 1分間 褒める人 が 褒められる人 を褒める 褒められる人 が感想を言う この進行を1ターンとしてチームメンバー全員が 褒める人 と 褒められる人 の両方を担当する1セクションを繰り返します。 この会を盛り上げながら、円滑に行うために次の画像のようなアプリを開発しました。 抽選ボタンを押すと、 褒める人 と 褒められる人 をランダムで抽選します。表示を押すとターンが進行して、抽選された 褒める人 と 褒められる人 が表示されます。 再び抽選ボタンを押すと、 褒める人 と 褒められる人 の抽選が行われセクションが進行します。抽選ボタンを押して行う抽選はバックエンドで実装しました。その際に”すでに行った 褒める人 と 褒められる人 の組み合わせになる抽選は行わない”という制約を持たせました。バックエンドのPythonでこの機能を実装することで、短い時間でアプリを作ることができ、役割分担を考えて技術選定を行えました。 初めてのフロントエンド実装を通して得た学びを糧に新たなアプリを作ることができました。これからもユーザーにとって価値あるプロダクトを開発できるエンジニアを目指して、学習を続けていきます。 また私は入社前に自身の開発経験の少なさを不安に思っていました。現在はこの記事で説明したプレ開発や開発研修での学びを通してエンジニアとしての成長を感じています。この記事を読んで入社後の不安を抱えている学生や就活生の助けになればいいと思います。 25年度新卒研修に関する記事はこちらをご覧ください。 2025年、新卒エンジニア研修はじめました Notion初学者のためのショートカット活用術：業務効率を上げる第一歩 100人をマネジメントした指揮者が 新卒で挑戦した「不確実性」と向き合うチームビルディング 新卒一年目のエンジニアが感じた、プレ開発で見えたチームの“成長” ゼロから学んだフロントエンド実装 毎日の日報報告をワンボタンで ハッカーの視点を身に付ける！新卒が学んだセキュリティ研修
自己紹介 初めまして！セーフィー株式会社 25卒エンジニアの高橋侑歩です。 大学院では機械工学研究科に所属し、ロボットアームと機械学習について研究を行っていました。 「映像から未来をつくる」というセーフィーのビジョンに共感し、25卒のエンジニアとして入社を決意しました。 新卒エンジニア研修 セーフィーの新卒エンジニア研修では、4~7月までの4ヶ月を使って、社内課題を解決するためのプロダクト開発を行ってきました。 今年も7人の新卒エンジニアが1つのチームとしてプロダクト開発を行っていますが、メンバーのバックグラウンドや得意分野がそれぞれ違う中で、技術に対してどうやってキャッチアップしていくかがチームとしての課題だと感じていました。 そこで、アイデアを確定させるための期間としていた5月にプレ開発という形で、簡単なアプリを作成し、メンバーが技術のキャッチアップを行う機会を設けることにしました。 ただ、他の研修と重なり、メンバーの一部が参加できないという状況であったため、全員が参加できるように2回に分け、それぞれ6日間でプレ開発を行いました。 自己紹介 新卒エンジニア研修 プレ開発の目的 ①開発経験を積むための技術のアウトプットを行う場にする ②チームで開発することの難しさと楽しさを体感する プレ開発で行ったこと 開発したもの 開発の過程 プレ開発に参加したメンバーからの評価 プレ開発を終えて感じたチームの成長 まとめ プレ開発の目的 プレ開発は2つの前提のもと、実施することにしました。 1つ目は「開発経験を積むため、技術のアウトプットの場にする」、2つ目は「チームで開発することの難しさと楽しさを体感する」です。 ①開発経験を積むための技術のアウトプットを行う場にする 「メンバーのバックグラウンドや得意分野がそれぞれ違う中で技術に対してどうやってキャッチアップしていくか」はチームの中でも、重要な課題の1つだと感じていました。 また、オンライン学習教材を通して、知識や技術のインプットはできるものの、実際に手を動かして物を作るという経験はできていませんでした。 そこで、オンライン教材で学んだ知識や技術をプレ開発でアウトプットすることで、チームの技術力を向上させることができると考えました。 ②チームで開発することの難しさと楽しさを体感する チームとして何かを成し遂げたことのあるメンバーはいたものの、チームで開発を経験したことのあるメンバーはあまり多くありませんでした。 25卒エンジニア研修の目的としてチーム開発を通してプロダクト思考を学ぶことが掲げられています。プレ開発を通してチームで開発することの難しさと楽しさを経験できればチームとして目的を達成できるのではないかと考えました。 プレ開発で行ったこと ここでは、2回行ったプレ開発のうち、1つを紹介します。 開発したもの プレ開発では、フロントエンド・バックエンド・データベース(DB)の要素があり、6日間である程度形にできる分量のものを開発できるようなテーマである必要がありました。 そこで、「オフィスビルのキッチンカー出店状況を可視化するツールの開発」というテーマでローカルで動くWebアプリの開発を行いました。 セーフィーのオフィスビルでは、毎日1階にキッチンカーが5台ほど出店しています。毎日違うキッチンカーが来るので、なんのキッチンカーが来ていて、何を売っているのかを可視化できたら便利だと考えたためです。 開発の過程 6日間という開発期間の中で、いつまでに何をするのかを明確にするため、ガントチャートを作成して、スケジュールの管理を行いました。 1つのタスクにつき1人の担当者を決め、成果物を共有することでチームとして開発をすることを意識しながら取り組みました。 ミニマムでWebアプリを作るために必要な画面遷移図やシーケンス図、ER図などを作成する際にも、これまでの経験を問わずやってみたいものに挑戦しました。 以下のER図は過去に経験がないメンバーの1人が、プレ開発期間を通してアウトプットしたものです。 プレ開発に参加したメンバーからの評価 プレ開発に参加してくれたメンバーから、プレ開発にアンケートを取り、目的が達成できたかどうかを調査しました。 アンケートでは以下の4つの質問に10段階で評価をしてもらいました。 プレ開発に参加してよかったですか？ プレ開発で自身の成長を感じましたか？ プレ開発で技術的なアウトプットをすることはできましたか？ プレ開発を通して、チームで開発することの難しさと楽しさを体感できましたか？ 結果はこのようになりました。(グラフ内の数値はアンケート回答者の平均値) また、プレ開発に関して、以下のようなフィードバックをいただきました。 楽しかったし、やったことがないことができた 短い時間の中で、できる限りのことができましたし、何より参加してとても楽しかった 個人のタスクをやりながら、リーダーとしてチームの進捗を管理できるようになった 作ったものを突き合せないと整合性がとれないということは実感できた 完全に初めてチーム開発を体験したので、もう少しヒントやtipsなどがあると嬉しかった プレ開発の目的としていた「開発経験を積むため、技術のアウトプットの場にする」、「チームで開発することの難しさと楽しさを体感する」という観点では、目的はある程度達成できたのではないかと感じます。 プレ開発を終えて感じたチームの成長 チーム開発経験がない・大学や大学院では全く別の分野に関する研究を行っていたなどバックグラウンドの違うメンバーが、6日間という短い期間の中でWebアプリを開発することができました。 メンバーのそれぞれが興味のある領域に対してのインプットを行い、プレ開発を通してアウトプットすることができるきっかけを作れたのはよかったのではないかと感じます。 また、研修が始まってまだ1ヶ月しか経っていない状況で、今回のプレ開発がメンバー同士の仲を深めるきっかけとなったことも非常に良かった点の1つです。技術的なスキルアップだけでなく、チームとしての結束を強めることができたと感じています。 まとめ 新卒のエンジニア研修の中で、「バックグラウンドや得意分野がそれぞれ違うメンバー同士が、どうやって技術的なキャッチアップしていくか」という課題に対するアプローチを考え、実践しました。結果として、チームメンバーの技術力向上と、チームとしての関係性が向上したという点で、プレ開発を実施してよかったと感じています。 エンジニアの新卒研修の途中ですが、一人前のエンジニアになるために日々精進していきます。 最後までお読みいただきありがとうございました！ 25年度新卒研修に関する記事はこちらをご覧ください。 2025年、新卒エンジニア研修はじめました Notion初学者のためのショートカット活用術：業務効率を上げる第一歩 100人をマネジメントした指揮者が 新卒で挑戦した「不確実性」と向き合うチームビルディング 新卒一年目のエンジニアが感じた、プレ開発で見えたチームの“成長” ← 本記事 ゼロから学んだフロントエンド実装 毎日の日報報告をワンボタンで ハッカーの視点を身に付ける！新卒が学んだセキュリティ研修
はじめに こんにちは。法務部 知財グループの永島です。今回は、知財グループ立ち上げから現在までの約3年間を、「1年目」「2年目」「3年目」と時系列で区切り、それぞれのステージでどんな挑戦があったのか、具体的な取り組みを深掘りしていきます！ はじめに 【1年目：2022年】ゼロから始まった、手探りの一年 【2年目：2023年】芽を出し始めた知財活動！1人で走り続けた試行錯誤の日々 【3年目：2024年～】新たなステージへ！2人体制で目指す、セーフィー知財の未来 まとめ：3年間で築いたものと、これからの「楽しむ知財」への挑戦 おわりに 【1年目：2022年】ゼロから始まった、手探りの一年 2022年1月、グループリーダーの渡辺がセーフィーに入社し、初代の知財担当としての仕事が始まりました。それは輝かしいスタートというより、まさに「何もない」場所から、何をするべきかを探す日々からの幕開けでした。 最初のミッション：社内ヒアリングと現状把握で見えたリアル 入社直後の1ヶ月は、役員や開発のキーパーソンとの面談を実施しました。そこで皆さんの声に耳を傾けるうち、「知財の重要性は分かるけど、何をしたら…？」「うちの事業で特許って取れるのだろうか？」といった、現場の率直な戸惑いや疑問に触れることができました。 方針決定：セーフィー知財、2つの約束 この現状を踏まえ、知財活動の柱として二つのことを掲げました。 「地に足の着いた知財活動（権利形成）」 ：まずは守りを固める！ 「知財に強い企業文化を築くこと」 ：みんなで知財を強くする！ ↑知財に強い企業文化を築くことの重要性を全社員向けの知財研修で伝えました。 土台作り：信頼できるパートナー探しとルール作り まずは、会社の状況を理解し、柔軟に対応いただける特許事務所を探すことから始めました。そして、活動の根幹となる職務発明規程も、特許庁の情報を参考にしながら、本当に手探りで整備を始めました。 発明発掘へGO！：社内に眠る「お宝」を探せ 商品開発会議に参加したり、CTOや新規事業部門の方々と話したり、そして何より「この技術、面白いかも！」と熱意を持つ社員の方々と対話する機会を少しずつ作っていきました。 初の出願と早期審査：「まずやってみる」精神で挑戦 特許出願や他社特許のクリアランス調査もできることから始めました。一人のため、先行技術調査は時間を区切って効率的に行うなど工夫が必要でした。そして、少しでも早く社内に良い報告をしたくて、「早期審査制度」を活用しました。UIデザインなどの意匠出願も、試験的に開始しました！ 1年目の成果と手応え：初の特許登録に歓喜！ 早期審査の活用もあり、セーフィーにとって記念すべき初の特許登録が実現！これは、開発に携わった社員にとっても大きな自信となり、本当に嬉しい出来事でした。Excelでの暫定的な管理体制や、商標活動もこの年からスタートしています。 【2年目：2023年】芽を出し始めた知財活動！1人で走り続けた試行錯誤の日々 1年目で蒔いた種が、少しずつ芽を出し始めた2年目。引き続き1人体制ではありましたが、活動を少しでも前に進めようと試行錯誤する日々でした。 発明のタネが続々！高まる期待と嬉しい悲鳴 1年目の活動の甲斐もあってか、社内から「こんなアイデアはどうだろう？」と多くの相談をいただけるようになりました。嬉しい反面、一人ではすぐに対応しきれないほどの状況になり、協力してくれる皆さんに感謝するばかりでした。 権利化プロセスの確立と、失敗からの学び 特許、意匠、商標の権利形成活動を続ける中で、早期審査のメリットを実感する一方、自社が既に公開していた情報が先行技術として引用されるという、今となっては苦い、しかし貴重な経験もしました。この経験から、出願前にはIR・広報部門としっかり連携することの重要性を改めて痛感しました。 攻めの知財活動へ：他社調査の本格化と「伝わる」報告 競合だけでなく、投資先やアライアンス先の知財状況も調査をするようになりました。その結果を報告する際も、どうすれば専門外の方に伝わるか、星の数で評価を示したり、図やグラフを用いたりと、試行錯誤の連続でした。投資担当者との対話からは「知財は経営指標の一」という視点を学びました。 社内啓発スタート：「知財を楽しむ」文化の第一歩 「知財をみんなで楽しもう！」をモットーに、分かりやすく、専門用語を避けた参加型の知財研修（入社時必須＆任意）をスタート。さらに、半年に一度の「知財レビュー」で実際の事例を紹介し、知財を身近に感じてもらう試みも始まりました。地道に続けてきた知財研修を通じて、開発や企画部門以外にも「知財、面白いね」と言ってくれる方が現れたりもしました。活動が少しずつ社内に根付いているのかもしれないと、ささやかな手応えを感じ始めた時期でした。 ↑知財レビューの資料の一部。特許が登録された際は知財的な観点の特徴を【ココがすごいよ】ポイントとして全社的に展開しています。 1人体制の奮闘と見えてきた「次」への課題 ありがたいことに活動の幅が広がるにつれ、1人体制では限界があることも、正直に感じ始めていました。管理システムの本格導入を検討し始めるなど、将来を見据え、次の一手を考えなければいけない時期に差し掛かっていました。 【3年目：2024年～】新たなステージへ！2人体制で目指す、セーフィー知財の未来 そして、2024年。3年目を迎え、セーフィーの知財部門は新たなステージへと突入します。 組織としての進化：2人体制と理想のチーム像 活動を前に進めるため、組織的な変化もありました。永島がJOINし2人体制となり、渡辺はグループリーダーという役割を担うことになりました。壁打ち相手として、議論を深め戦略を練り上げ部門としての成長を図っています。 目指す未来：リーダーの視点と「攻める知財」 そして、セーフィーの知財部門が目指すのは、単なる「守り」に留まらない知財の未来です。 スタートアップでの挑戦を「実証実験（POC）」と捉え、常に会社の未来を模索しています。その中で、知財が営業活動に貢献できるように、「攻め」にも繋がる活動を続けていきたいです。 新たなステージの証明：相次ぐ外部からの評価 こうした日々の活動の証として、2024年には外部から評価をいただく機会にも恵まれました。 まず、 特許庁の「 「事例から学ぶ 商標活用ガイド」 - ビジネスやるなら、商標だ！- （2024年版） 」に、これまでの取り組みを掲載 していただきました。私たちの活動が、少しでも他の方の参考になるかもしれないというのは、大変光栄なことでした。 （出典）特許庁,商標の活用事例集「事例から学ぶ 商標活用ガイド」 - ビジネスやるなら、商標だ！- （2024年版）,セーフィー株式会社「映像から未来をつくる」その想いをロゴに込めて・・・,URL： https://www.jpo.go.jp/support/example/document/trademark_guide2024/guide01.pdf#page=18 （2025年6月9日アクセス） さらに、 関東地方発明表彰で「発明奨励賞」を受賞 するという、望外の機会もいただくことができました。( こちらの記事 で詳しく紹介) この受賞は、開発を進める社員たちの大きな励みになったと感じており、それが何より嬉しかったです。 まとめ：3年間で築いたものと、これからの「楽しむ知財」への挑戦 たった一人でゼロから立ち上げたセーフィーの知財部門。この3年間で、権利形成の基盤を築き、社内の知財意識を高め、そして何よりも「知財を楽しむ」という文化の種を蒔き、育ててきました。 これからも、セーフィーの知財部門が、社員と共に「知財を楽しみながら」、会社の成長を力強くドライブしていく姿に期待してください！ おわりに セーフィーではエンジニアを積極的に採用しています。 興味がある方は是非下記サイトを一度覗いてみてください。 https://safie.co.jp/teams/engineering/
こんにちは！25卒エンジニアの夕田です！ 「このプロジェクト、本当に終わるのかな？」 エンジニアであれば、誰もが一度はそんな不安に駆られたことがあるのではないでしょうか。 漠然としたゴール、曖昧な要件、先の見えない課題の山……。 まるで霧の中を手探りで進むように、開発の現場には常に「不確実性」がつきまといます。 私自身、学生時代に指揮者として団体を率いてきた経験があります。 音楽の世界も、エンジニアリングとよく似ています。 演奏会という「本番」に向けて、多くのメンバーがそれぞれのパートを練習し、最終的に一つの「作品」を創り上げます。 しかし、楽譜通りに音を出しても良い演奏はできません。 そんな時、指揮者に求められるのは、まさにこの「不確実性」をマネジメントし、チーム全体を最高のパフォーマンスへと導くことです。 私が指揮者として学んだ知見は、形は違えど、エンジニアのチーム開発に応用ができると気付きました。 本記事では、学生時代にオーケストラの指揮者として培った経験と、新卒エンジニアとして現場で得られた学びを融合させ、 両者に共通する不確実性やチームビルディングの重要性 について共有させていただきます。 経歴 不確実性の高い「音楽」をアジャイルで合奏する マエストロがするチームビルディング 1. 開発研修での目標設定：未来像から見出すチームの可能性 2. 5年後になっていたいエンジニア像：個人の夢がチームを動かす 3. 「ito」で深まる信頼関係：遊び心から生まれるチームビルディング 4. 今持っている技術力：強みの可視化で不確実性を減らす おわりに 経歴 広島市立大学にてマンドリン・ギター部に所属し、大学ではマンドリン奏者・指揮者として活動。大学院では指揮者に専念。三大学合同定期演奏会にて50名規模の指揮を担当（第25回三大学合同定期演奏会）。その後、中国学生マンドリン連盟が主催する、中国ブロック定期演奏会の全大学参加大合同ステージにて100名規模の指揮を担当。（第62回中国ブロック定期演奏会 大合同指揮、第64回中国ブロック定期演奏会 大合同指揮） 不確実性の高い「音楽」をアジャイルで合奏する アジャイル開発という概念に触れた際、私は自身の指揮者としての経験との間に共通点があると気が付きました。 それは私が指揮をする合奏練習で、曲の難易度に関わらず行っていた「ルーティーン」です。 私の行う合奏練習は、まさしく アジャイル開発 でした。 具体的には、以下の3つのステップを繰り返していました。 成果物の全体像把握（スプリントレビュー） 練習の冒頭に、楽曲全体を一度通しで演奏します。 これは、現在の成果物（合奏）を「ユーザー」（指揮者である私）に提示し、全体的な品質と方向性を評価するプロセスに相当します。 不確実性の高い要素の優先的解消（バックログの管理、スプリントの実行） 全体像を把握した後、詳細な修正作業へと移行します。 この段階で最も重視したのは、 「特にまずい！！」と思った箇所から優先的にフィードバックを行い、改善に着手する ことです。 例えば、極端なパート間における拍のずれや、オーケストレーションのバランス調整などがあげられます。 このアプローチは、まさにエンジニアリングにおける 「不確実性の高い要素から優先的に処理する」 ことの実践でした。 継続的な改善サイクル（イテレーション） 合奏を通じて得られた具体的なフィードバックを基に、次回の練習（スプリント）でチームが取り組むべき改善点を明確に提示します。 各メンバーはそれを受けて個別の練習に励み、次回の合奏でその成果をアウトプットします。 この継続的なサイクルを繰り返すことで、楽曲の不確実性を段階的に低減させ、最終的に聴衆がストレスフリーに聴くことができる、 最高の演奏という「完成されたプロダクト」 へと昇華させることが可能となるのです。 いかに複雑で不確実性の高い開発課題に直面したとしても、 「フィードバックを積極的に取り入れ、不確実性の高い要素から着実に解消していく」 アプローチは極めて有効です。 完成度を追求する前に、まずは全体像を把握し、課題の根源を特定します。 この原則は、指揮者の曲作りとソフトウェア開発において普遍的に適用されるものであると考えます。 マエストロがするチームビルディング チームビルディングにおいて、私が最も重要視しているのは、単なる情報伝達を超えた「関係性構築」です。 「指揮棒から音は出ません」 私がどれほど熱意を込めた指揮をしても、実際に音を出すのは目の前にいる奏者たちです。 あくまで指揮者は「お願いする」立場です。 私の中にある最高の音楽を作るためには、奏者たちとの間に言葉では表現しきれないほどの信頼関係が不可欠でした。 彼らが私の意図を汲み取り、自らの音で表現してくれるからこそ、一つの音楽が生まれます。 これは、ソフトウェア開発におけるマネジメントにおいてもそのまま当てはまると考えます。 マネージャーがどんなに素晴らしいビジョンや設計を描いても、実際にコードを書き、プロダクトを形にするのはエンジニア一人ひとりです。 まるで指揮棒から音が出ないように、マネージャーが直接コードを書くわけではありません。 どれだけ言葉を尽くしても、メンバーとの間に深い信頼関係がなければ、最高のパフォーマンスは引き出せないと思います。 だからこそ、私はメンバー間の関係性構築、特に 心理的安全性の確保 に積極的に時間を投資しました。 そこで行ったのが「マエストロがするチームビルディング」です。 ここからは具体的な取り組みについて紹介します。 1. 開発研修での目標設定：未来像から見出すチームの可能性 「開発研修が終わったときにどんなエンジニアになっていたいか」という目標を共有しました。 あるメンバーは技術的なリーダーシップと分かりやすい説明を重視し、また別のメンバーはチームへの貢献に重きを置いていると共有しました。そして、私自身はマネジメントと組織開発への関心を示しました。 これらの目標共有は、単に個人の志向を知るだけでなく、チームとしてどのような強みや役割を持つメンバーがいるのかを理解する貴重な機会となりました。 それぞれの目標が明確になることで、不確実な開発課題に対し、誰がどのような視点から貢献できるのかという見通しが立ちやすくなりました。 2. 5年後になっていたいエンジニア像：個人の夢がチームを動かす 「5年後になっていたいエンジニア像」を共有する場では、さらに深い、メンバーの価値観や人生観に触れることができました。 大胆な起業の野望を披露するメンバー、音楽や趣味に対する強い情熱を共有するメンバー、T字型人材を追求するメンバー、その未来像は多岐にわたりました。 ここで行った共有は、メンバーがお互いの多様な価値観を理解し、より深いレベルで人間関係を構築する上で非常に有益でした。 個人の夢や情熱を知ることで、互いへのリスペクトが生まれ、それがチーム内での協調性を自然と高めていくことにつながったと感じています。 3. 「ito」で深まる信頼関係：遊び心から生まれるチームビルディング 💡 ボードゲーム「ito」 1～100までの数字が書かれたカードを使い お互いの数字を言葉で表現し合う協力型パーティゲーム 出典：ArclightGames ito https://arclightgames.jp/product/ito/ (2025/7/10アクセス) 「ito」では、お互いの価値観や感覚を言葉にすることで、それぞれの個性を見ることができました。 ちなみに1時間プレイしましたが、1度もクリアできませんでした。。笑 これは情報が不足している中で、お互いの意図を深く汲み取ろうとしなかったり、あるいは誤解したまま判断してしまったことが原因です。 しかし、この経験を通じて、情報共有の重要性はもちろん、普段の何気ないコミュニケーションがいかに重要かをチーム全員が肌で感じることができました。 加えて、ゲームを通じてメンバーの人間性が垣間見え、それが後の開発における心理的安全性の向上にも繋がったと感じています。 4. 今持っている技術力：強みの可視化で不確実性を減らす 最後に、「学生時代に学んだ今持っている技術力」を共有する場を設けました。各自がこれまで培ってきたスキルや経験を武勇伝形式で発表し、質疑応答を行いました。 Web開発と機械学習をバランス良く習得しているメンバーや、AI領域の専門性を持つメンバー、さらにはアマチュア無線といったユニークなスキルも共有されました。 この技術力共有会は、チーム内でのスキルの「見える化」を促進し、誰がどのような分野に強みを持っているのか、またどのような興味を持っているのかを明確にしました。 これにより、今後の開発において、タスクの割り振りや困った時の相談先が自然と見えてくるようになりました。 それぞれの専門性を知ることで、高め合える関係性が構築され、結果的にプロジェクトの不確実性を減らし、効率的な進行につなげることができたと感じています。 おわりに 本記事では、指揮者としての経験と新卒エンジニアとしての学びから、開発現場に常に存在する「不確実性」、そしてそれを乗り越えるための「チームビルディング」についてお話ししました。 最高のパフォーマンスを出すには、日々のコミュニケーションを通じて心理的安全性を確保することが重要です。 心理的安全性を担保することで、メンバーが安心して意見を交わし、失敗を恐れずにチャレンジできるようになります。 この強固な信頼関係こそが、不確実性を乗り越え、最高の成果を生み出すチームの強力な武器となるでしょう。 最後までご覧いただきありがとうございました！ 25年度新卒研修に関する記事はこちらをご覧ください。 2025年、新卒エンジニア研修はじめました Notion初学者のためのショートカット活用術：業務効率を上げる第一歩 100人をマネジメントした指揮者が 新卒で挑戦した「不確実性」と向き合うチームビルディング ← 本記事 新卒一年目のエンジニアが感じた、プレ開発で見えたチームの“成長” ゼロから学んだフロントエンド実装 毎日の日報報告をワンボタンで ハッカーの視点を身に付ける！新卒が学んだセキュリティ研修 .box-d1 { max-width: 500px; margin: 1.5em auto 1em 0; /*左寄せ*/ border: 2px solid #565656; border-radius: 5px; overflow: hidden; } .box-d1 > div { font-size:90%; padding: .5em 1em; color: #ffffff; background:#565656; } .box-d1 li, .box-d1 p { font-size:90%; margin: 0.5em 1em; }
2025年新卒として開発本部に配属されました、恩智太陽です。 現在、新卒エンジニア研修の一環で、社内課題の解決をテーマに、企画から実装まで一貫して取り組む自由度の高いチーム開発に励んでいます。 この研修を通して痛感したのは、Notionのショートカットを使いこなすことによる業務効率の劇的な向上です。 「Notion初学者」である私自身の視点から、これからNotionを使い始める方や、さらに活用したいと考えている皆さんに向けての記事を書くことにしました。 はじめに このテーマを選んだ背景 誰向けの記事？ ショートカットキーを習得するメリット ショートカットの入力5パターン ショートカットページの見方 必須ショートカット 見出し（h1, h2, h3） 箇条書きリスト（bullet） 番号付きリスト（num） トグルリスト（toggle） トグル見出し1~3（toggleheading1~3） ここまでのブロックタイプを使うと… 個人的にお勧めするショートカット 区切り線 直前に使った文字色を反映（color） 太字 下線 コールアウト（callout） ここまでのショートカットを使うと… まとめ はじめに このテーマを選んだ背景 セーフィーの研修では、Notion、Slack、Backlogなど、多くのツールに初めて触れる機会がありました。 特にNotionは、学習内容の記録から議事録作成、チームのポータルサイト作成まで、研修期間中に最も頻繁に利用するといっても過言ではないほど活躍の場面が多いツールです。 私自身、Notionに触れるのは大学時代以来でしたが、使っていくうちに「もっと使いこなせたら、さらに業務が楽しく、効率的になるはずだ」と感じるようになりました。その中で、Notionを楽しく、スピーディーに使いこなすための鍵となるのが「ショートカットキー」であることに気づきました。 この発見をNotion初心者の方々に共有したいという思いから、この記事を執筆することにしました。 この記事では「もし入社時にこんなNotionのまとめページがあったら嬉しいな」という私の思いを詰め込んだ内容を書いていこうと思います。 今後入社される新卒の方で、「Notionをほとんど触ったことがない」という方にとって、少しでもお役に立てれば幸いです。 誰向けの記事？ Notionをまだ一度も使ったことがない方 基本的な機能は知っているけれど、操作のたびに「ブロックタイプの変換」メニューを探していて、もっと効率的にNotionを使いたいと感じている方 頻繁に使うショートカットキーを一目で見たい方 ショートカットキーを習得するメリット 議事録の効率化と質の向上 インプットの質とスピードの両立 マークダウン記法も取得できる（Notionはマークダウン形式で記述できる、エンジニア向け） 「自分Notion使いこなせてる！まとめるの楽しい！！」という優越感（議事録係が楽しくなります） ショートカットの入力5パターン Notionのショートカットキーは、主にブロックの先頭で特定のキーを入力することで機能します。基本的な使い方として、以下のパターンがあります。 特定の記号 + Space キー (日本語入力時は Enter キー) (マークダウン記法) ブロックの種類を素早く変換できます。 例： # + Space : 見出し1を作成 特定の記号でテキストを囲む (マークダウン記法) 入力中のテキストに直接スタイルを適用できます。 例: **適用したい文章** または __適用したい文章__ : 太字にする Ctrl / Cmd + 特定のキー 文字装飾やページの操作など、様々なアクションを実行できます。 例： Ctrl + B : 選択範囲を太字にする Ctrl / Cmd + Shift + 特定のキー さらに高度なブロック操作や書式設定が可能です。 例: Ctrl + Shift + L : チェックリストを作成 Ctrl + Shift + 数字キー (1-9) : ブロックタイプを特定のタイプに変換（例： Ctrl + Shift + 1 で見出し1） スラッシュコマンド ( / または ; ) によるブロック操作 ブロックの先頭で特定の記号を入力し、続けてコマンドやブロック名を入力すると候補が一覧で表示され、その中からブロックタイプを選択することで、新しいブロックを素早く挿入したり、既存のブロックタイプを変換したりできます。 半角英数入力時: / (スラッシュ) コマンド / に続けて、挿入したいブロック名を入力、または表示された候補から選択し Enter キーで決定 例: /h1 と入力して Enter ：見出し1を作成 日本語入力時: ; (セミコロン) コマンド 日本語入力モードのまま ; を入力し、続けて日本語でブロック名を入力すると、 / コマンドと同様に候補が表示され、選択・決定できる スラッシュコマンドの 日本語入力版 例: ；見出し と入力して Enter ：見出し1を作成 ※個人的なおすすめと補足 スラッシュコマンド ( / や ; ) は、利用可能なブロックの種類を視覚的に確認しながら直感的に操作できるため、初心者の方には特におすすめです。 一方で、特定の記号と Space キーを組み合わせる、テキストを記号で囲むといったマークダウン記法のショートカット（1,2の方法）、 Ctrl と Shift を使用するショートカット（3,4の方法）に慣れると、よりスピーディーな入力が可能になり、マークダウン記法も覚えられるので個人的には「1~4」のショートカットをお勧めします。 ショートカットページの見方 これからNotionのショートカットを紹介していきます。以下の形式で記載しております。 ブロックタイプ名：ブロックタイプの名前、「；」,「/」を入力した後にブロックタイプ名を入力すると使用することができます（「；見出し1」、「/h1」） ショートカット：ブロックタイプを使用するためのショートカット 見た目：使用した場合のNotion上での表示画面 補足：使用用途など 必須ショートカット まずNotionをまとめるうえで「これがないとNotionじゃない！」というブロック要素のショートカットを紹介します。 見出し（h1, h2, h3） 「#」 + Space （「##」で 見出し２ 、「###」で 見出し３ ） 見出しは１~３と種類があり、大きさを変えて使うことができます。 箇条書きリスト（bullet） 「*」「・」「-」「+」のいずれか + Space Ctrl + Shiht + 「5」 箇条書きのところでカーソルを合わせTabキーを押すとネストを深くできます（Shiht＋Tabでネストを浅くできる） 議事録ですごく重宝する 番号付きリスト（num） 「数字」 + 「.」 + Space Ctrl + Shift + 「6」 箇条書きリスト同様、Tabキーでネストを変更可能 トグルリスト（toggle） 「>」 + Space 用語の補足や、説明が長くなってしまう場合などに用いる トグル見出し1~3（toggleheading1~3） 「>」 + Space してトグルリスト作成後に、「#」 + Space（「##」,「###」でも可能） 見出しとトグルを合わせたもの 見出しを作成した後に 「>」 + Space でも可能です ここまでのブロックタイプを使うと… ここまで様々なブロックタイプのショートカットを紹介してきました。 実際にこれらのブロックタイプを使うとどれぐらい見やすくなるかを体感していただくために研修中に自分が記述した議事録の文を用いて「ブロックタイプ適応前の文章」と「ブロックタイプ適応後の文章」とで比較していただこうと思います。 以下の議事録は「オフィスに冷凍弁当を供給する冷凍庫を設置し、各ユーザーに適したおすすめの冷凍弁当を選定する機能を通じて、オフィス内で手軽な栄養摂取をサポートするプロダクト案」を練っているときのものです。 ブロックタイプ適応前の議事録 誰が何を話したかを淡々とまとめていているだけで、「いつ話題が切り替わったか」と「何が決まったのか」が全く分からない議事録となっています。 ですが、今まで紹介したショートカットを使って議事録を書いてみると以下のようになります。 ブロックタイプ適用後の議事録 どうでしょうか？先ほどのブロックタイプ適応前の文章に比べて、「いつ話題が切り替わったか」、「何が決まったのか」の点が明確になっているかと思います。これを「ブロックタイプの変換」から要素をいちいち選択していたら会議のスピードに間に合わないですが、ショートカットを覚えることで、スピードを落とさず見やすい分が書けるようになります。 個人的にお勧めするショートカット 次に、自分がよく使うお勧めのショートカットを紹介します。ブロックタイプではないですが、文字を装飾するショートカットも追加しています。 区切り線 「-」を三つ（※全角では変換されません） 下のコンテンツとの差がはっきり認識できるようになり、視認性が向上する 直前に使った文字色を反映（color） Ctrl + Shift + H 文字色で協調すべき部分を目立たせられる 太字 文字を選択後、Ctrl + Shift + 「B」 「 」+ 「太字にしたい文章」 + 「 」（「_」二つでも可） 文字色と同じく、協調すべき部分を目立たせられる（短い単語を強調したいときに使われる） 下線 文字を選択後、Ctrl + Shift + 「U」 協調すべき部分を目立たせられる（多くの文字を強調したいときに使われる） コールアウト（ callout ） ※コールアウトに関しては「/callout」で呼び出すしか方法がないです😢 コールアウトの中にブロックタイプを挿入することができ、画像のコールアウトでは「太字」と「区切り線」が使われています。 ここまでのショートカットを使うと… 最後に今まで紹介したショートカットを先ほどの議事録に適用すると以下のようになります。 以下の点が見やすくなったのではないかと思います。 「区切り線」や「下線」を用いて項目の境目を見やすくする 「コールアウト」を用いて多数決や資料の文章を目立たせる 「文字色」で結論がどうなったかを明確にし、決定事項が一目でわかるようにする まとめ 今回の記事では、Notionのショートカットの紹介とその具体的な活用例をご紹介しました。 最後にお見せした議事録の例はブロック要素がかなり多いので、すべて使おうとすると議事録のスピードに間に合わないと思います。 しかし、まずはご自身が「これは便利だ」と感じるショートカットをいくつか選び、会議中や会議後の見直しの際に、特に強調したい箇所や情報の区切りを整えるために活用するだけでも、Notionのドキュメントは格段に見やすく、分かりやすくなるはずです。 Notionには、今回ご紹介しきれなかった便利なブロックタイプやショートカットがまだまだたくさんあります。本記事をきっかけにNotionのショートカットの可能性に気づいていただけたなら、ぜひご自身でも色々と検索して活用してみてください。 ここで挙げきれなかったブロックタイプ、ショートカットはたくさんあるので、今回の記事でNotionのショートカットに興味をもっていただけた方は、是非ご自身で調べてみてください！ この記事が、皆さんのNotion活用を後押しし、日々の業務効率向上に少しでもお役立てできれば幸いです。 25年度新卒研修に関する記事はこちらをご覧ください。 2025年、新卒エンジニア研修はじめました Notion初学者のためのショートカット活用術：業務効率を上げる第一歩 ← 本記事 100人をマネジメントした指揮者が 新卒で挑戦した「不確実性」と向き合うチームビルディング 新卒一年目のエンジニアが感じた、プレ開発で見えたチームの“成長” ゼロから学んだフロントエンド実装 毎日の日報報告をワンボタンで ハッカーの視点を身に付ける！新卒が学んだセキュリティ研修
はじめに こんにちは！2025年4月にセーフィーに新卒として入社した竹田です。私は25卒内定者として約10か月間、企画本部 AIソリューション部でインターンをしていました。ビジネス職として採用され、APIという単語も知らなかった私が、奮闘しながらシステム開発を行ったのでこのたび記事にさせていただくことにしました。 今回は「映像×生成AI」を使ったオフィス5S管理ツールについて紹介させていただきます。 はじめに なぜつくろうと思ったのか？～総務の課題見つけちゃったの巻～ どんなものをつくったのか～血と汗と涙(?)の結晶の巻～ どうやってつくったの？～いばらの道を振り返るの巻～ ステップ① 静止画取得 ①-1：設定ファイルからデバイス情報を取得する ①-2：Safie APIからの画像取得 ①-3：画像の保存と更新 ステップ②：LLMのBot作成 ステップ③：LLMのAPI連携 ステップ④：画面作成（UI作成） 完成したツールのその後～つくってどうだったの？の巻～ 今後の可能性～未来に羽ばたけの巻～ 取り組みを終えて～ちょっと成長しましたの巻～ なぜつくろうと思ったのか？～総務の課題見つけちゃったの巻～ 弊社は事業拡大に伴い社員数が急増し、オフィス環境の適切な管理が課題となっています。特に総務部門において、大きく2つの問題が顕在化してきていました。 まず第一に、社員数の増加に比例して総務部門の業務負担が著しく増大していたことです。日々のオフィス巡回、整理整頓の確認、備品管理など、５S（整理・整頓・清掃・清潔・躾）に関わる業務量が従来の管理体制では対応しきれない状況となっていました。 第二に、オフィスの拡張に伴い設置された多数の防犯カメラからの映像確認作業が煩雑化してきたことです。複数フロアに渡る数十台のカメラ映像を目視で確認する作業は、人的リソースの観点から非効率であり、重要な異常を見落とすリスクも高まっていました。 現状のオペレーションと課題に関する詳細を以下の図に示します。 このような状況を打開するため、LLM（大規模言語モデル）の活用が最適であると判断しました。LLMを活用することでカメラ映像からの環境異常の自動検出だけでなく、状況に応じた改善提案の生成など、従来のオフィス管理で顕在化していた負担を軽減できると考えたからです。 上記の背景から、LLMを活用した効率的なオフィス５S管理ツールのシステム開発を行うことにしました。本ツールは総務部門の負担軽減と管理品質の向上を同時に実現することを目指しています。 この時の構想としては上の図のような複数台のデバイスに対して一度に質問ができる仕組みがあれば便利そうだという構想を練っていました。質問に対して見る必要のあるデバイスの情報のみが結果として返ってくれば、大幅に目視の手間を省けると考えました。 どんなものをつくったのか～血と汗と涙(?)の結晶の巻～ 早速ですが、最終的に作ったツールを紹介させてください。 ツールの機能は大きく3つあります。 1.分析するデバイス（カメラ）を選択する機能 どのデバイスから情報を取得するかを決めるために設定ファイル（簡単なJSONファイル）を用いています。この設定ファイルには『デバイスID』と『エリア名』が書かれていて、このファイルを編集するだけで、別のデバイスから情報を取得する場合でも簡単に切り替えることができます。 2.分析に使う画像を更新する機能 分析にリアルタイムの画像を使用したい場合、「画像を更新」ボタンを押すだけで5S分析用の最新静止画を自動的に取得できます。取得した画像は「取得画像一覧」に表示されるため、簡単に確認できます。 3.テキストで質問を送って回答を取得できる機能 この機能では、利用者の目的に合わせてテキストで質問ができます。質問に対しては、該当するデバイスの画像、AIによる解説、該当の映像までのリンクが表示されます。視覚情報とAIの説明で、効率よく問題を解決できるという特徴があります。 どうやってつくったの？～いばらの道を振り返るの巻～ さて、ここからは実際に作っていく過程をお話しできればと思います。 システムの構成は以下のようになっています。 このシステムは、利用者が入力した質問と各デバイスから取得した静止画を組み合わせてLLMに送信します。LLMはその情報を処理して回答を生成し、システムはその回答をツールの仕様に合わせて整理してから利用者に表示します。つまり、質問と画像を入力として受け取り、AIが処理した結果を見やすい形で出力する仕組みになっています。 こちらはGradioで実装しており、作成時点ではローカル環境で実行しています。 ここから実際に作成した手順に合わせて、工程を説明します。 ステップ① 静止画取得 ①-1 設定ファイルからデバイス情報を取得する ①-2 Safie APIからの画像取得 ①-3 画像の保存と更新 ステップ② LLMのBot作成 ステップ③ LLMのAPI連携 ステップ④ 画面作成（UI作成） ここでは、各ステップに対して、前半が作業内容（🧑💻）、後半が私の感想（🗣️）という構成で書かせていただいています。 ステップ① 静止画取得 まず初めに取り組んだのは各カメラから分析用の静止画を取得する作業です。 システム構成図のこの部分ですね。 こちらは3Stepで作業を実施しました。 ①-1：設定ファイルからデバイス情報を取得する 🧑💻）どのカメラから情報を取得するかは、管理者が変更しやすいように、JSON形式の設定ファイルで管理するようにしました。このファイルには、各カメラのIDと、オフィス内のどのエリアを映しているかの名前が紐付けられています。アプリ起動時や設定変更時にこのファイルを読み込み、連携するカメラを特定します。 書いたコードがこちら def load_device_info_from_json (): """ デバイスファイルからデバイスID、エリア名のリストを読み込む関数 Returns: list: (device_id, area_name) のタプルのリスト。エラー時は空リストを返す """ try : config = load_config() with open (config[ "device_file_path" ], 'r' , encoding= 'utf-8' ) as file : devices = json.load( file ) # データ構造が期待通りかチェック if not isinstance (devices, list ): raise ValueError ( "JSONデータがリストではありません" ) device_info = [ (device[ 'device_id' ], device[ 'area_name' ]) for device in devices if 'device_id' in device and 'area_name' in device ] return device_info jsonファイルの中身は以下のような形式になっております [ { " device_id ": " xxxx ", " area_name ": " yyyy " } , { " device_id ": " zzzz ", " area_name ": " wwww " } ] 🗣️）ここまでは順調な滑り出しで、コードを書くのは初めてでしたが楽しんでできていました。 「よっしゃーこのままいくぞー」と意気込んでいたのもつかの間、トントン拍子にことが進むわけではありませんでした。 ①-2：Safie APIからの画像取得 🧑💻）実際にカメラの画像を取得する部分の作成を行いました。ここでは、Safie APIを用いて、各カメラの静止画を指定した時刻でリクエストします。取得した画像データに対して、どのカメラのものか、どのエリアのものかといった情報も付与し、一緒に保存します。静止画取得の詳細は こちら のリファレンスをご参考ください。 静止画取得のSafie APIは以前に勉強会でコードを見たことがあったので、それを参考に書き始めました。「リファレンスを見て１から書く」ではなかったので、完全停止することなく進めることができました。 🗣️）ここでは忍耐力が大切だと気付きました。最初は意図したタイミングで画像が取得できないことがありました。画像らしきものは入っていたものの、No Imageといった形で中身が空だったり、意図した時間と違う時間の画像が取れたりと苦戦しました。何度か繰り返すと取得自体は問題なくできたので、この時点でもまだ余裕な気持ちがありました。 ①-3：画像の保存と更新 🧑💻）取得した画像は一時的にアプリ内に保存されるようにしました。これは「質問を送るたびに画像取得のAPIが走る」という不要なアクセスを減らし、サーバ側の負荷を軽くすることで、アプリケーションの応答性を向上させることが目的です。（リセットボタンを押すまでは、異なる質問を送っても同じ画像に対して分析が行われるようになっています） とはいえ、リアルタイム画像を分析したいという要望もあると思うので、ユーザーの指示によって最新の情報に更新できる動作も加えました。 🗣️）ステップ①で最も大変だったのがこの①-3の部分です。 「画像を更新」ボタンを押してもエラーが返ってきたり、うまく画像が保存されていなかったりと、「どこが間違ってるんだこれ」と思うことも増えました。そこで調べながら試行錯誤を繰り返すうちに、プログラムの間違い探しと修正、いわゆるデバッグ作業をどのように行っていくかが分かってきました。一気にやろうとしすぎずに細かく分けて考える方が自分には合っているなと思いました。この時ほふく前進くらいのスピードですが、まだ前には進めている実感がありました。 ステップ②：LLMのBot作成 次にLLMとの連携の部分の説明をさせていただきます。システム構成の以下の部分です。 🧑💻）今回、質問文と画像を組み合わせて分析して回答を出してくれる存在としてLLMを使用しています。 LLMはBedrockを使いました。こちらはAWSが提供する生成AIアプリケーション開発用のサービスです。主要なAI企業やAmazonが提供する高パフォーマンスな基盤モデルを、API経由で利用できます。 まず最初に行ったのは、今回私が使うツール専用のBotを作成することです。 メニューの「ボットコンソール」を開き、「ボットを新規作成」を選択します 次にボットの基本情報を設定します。必要な情報は以下の3つ（ボット名、説明文、インストラクション）です。 今回はシンプルに、ボット名を「Office5S」、説明文を「オフィス5S可視化くん」、インストラクションには「あなたは5S分析のプロフェッショナルだ」といった内容を入れました。 ボットを作成すると、作成したBotのAPIエンドポイント、APIキーを取得することができます。これはBotを使うために必要となる情報です。 最後にアクセスを許可するクライアントのオリジンを入力したら準備完了です！ ボットの作成が完了したら、それを動かすためのコードを書く必要があります。 🗣️）このBotをつくる作業は特段大変なことはなかったものの、プラグラムを書く上で重要なことを1つ学びました。それはBotのAPIエンドポイント、APIキーなどの重要な情報は直接書かないという点です。当たり前じゃんと思った方、その通りです。その通りなのですが、私はそんな当たり前を知らず、最初はプログラムにそのままAPIキーやエンドポイントを書いてしまっていました…。 現在はenvファイルに入れ、そのファイルを読み込むような仕様にしたのでご安心ください。（先ほどのSafie APIのキーもこちらに入っています） ステップ③：LLMのAPI連携 🧑💻）Botを作成して次に行ったのが、Botと今回のツールをAPI連携することです。リファレンスはAWSが出している書き方をもとにつくった社内用のものを使いました。 まず、いきなり本体ツールにコードを組み込むのではなく、API連携が成功しているかを試す軽めのテストをしました。テストに使用したコードはこちらです。 import boto3 from botocore.exceptions import ClientError # AWS認証情報（セキュリティ上の理由で環境変数やAWS CLI設定を推奨） AWS_ACCESS_KEY_ID = "XXXXXXXXXXXXXXXX" AWS_SECRET_ACCESS_KEY = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" AWS_REGION = "us-east-1" # 使用するリージョン # Bedrock Runtimeクライアントを作成 client = boto3.client( "bedrock-runtime" , region_name=AWS_REGION, aws_access_key_id=AWS_ACCESS_KEY_ID, aws_secret_access_key=AWS_SECRET_ACCESS_KEY, ) # 使用するモデルID（Claude 3 Haikuなど） model_id = "anthropic.claude-3-haiku-20240307-v1:0" # ユーザーメッセージを定義 user_message = "こんにちは、今日の天気はどうですか？" conversation = [ { "role" : "user" , "content" : [{ "text" : user_message}], } ] try : # Converse APIを使用してメッセージを送信 response = client.converse( modelId=model_id, messages=conversation, inferenceConfig={ "maxTokens" : 512 , "temperature" : 0.5 , "topP" : 0.9 }, ) # conversation_idを取得して表示 conversation_id = response.get( "conversationId" ) if conversation_id: print (f "Conversation ID: {conversation_id}" ) else : print ( "Conversation IDを取得できませんでした。" ) except (ClientError, Exception ) as e: print (f "エラー: {e}" ) ここで大体どんな関数を使い、どのような形でコードを書いていけばうまくAPIが動作するのかを把握することができました。そして、そのコードをもとに質問文と画像を同時にBedrockに投げて分析してもらえるような機能を実装しました。 🗣️）今回の取り組みで一番の山場がこのBedrockのAPI連携です。 あたかも簡単にできたみたいな書き方をしていますが、まずリファレンスを見て最初に思ったことは「何が書いてあるんだこれ」でした。Safie APIのリファレンスはこれまで何回か見たことがあり、意味が分からず固まるということがなかったのですが、今回のBedrockのAPIは初見では何が書いてあるのかほぼわかりませんでした。リファレンスを見て１からコードを書くということが初めてだったのです。そんな困ったときはまずChatGPT先生の出番です。「このリファレンス通りにコード書いて」と指示を送り、出てきたコードを実行してみましたが、結果はAPIエラーと返ってきてしまいました。 エラーを繰り返していくとさすがに自分が行き詰まっていることを感じました。その後開発の方に質問を投げましたが、いただいた回答は「リファレンス通りになっていない」というものでした。「え？これってリファレンスに沿えてないんだ」と思うと同時に今の理解では前進できないと感じ、トレーナーにヘルプを出しました。 一緒に考えてくださり、テスト用のコードをつくっていただきました。これがなければ前に進めていなかったと思います（感謝） 次の質問文と画像を同時にBedrockに投げて分析してもらえるような機能を実装していく過程も非常に大変でした。「一番整理されていないのはどこ？」といった質問を送って回答が返ってくるようになったので「できました！」とトレーナーに自信満々に見せたところ、画像が送られておらず質問に対してそれっぽい回答と解説をただ返してくれる謎ツールが誕生したのはいい思い出です。そんな紆余曲折あり、いろいろな人の力も貸していただき最大の山場を乗り越えることができました。 ステップ④：画面作成（UI作成） 🧑💻）UIの作成にはGradioを使いました。Gradioとは機械学習モデルのデモを行うWebアプリケーションを簡単に作ることができるPythonのライブラリです。詳細は こちら をご確認ください。 まず、説明を割愛していましたが、事前に「こんな感じのものをつくりたい」という仕様書を作成していました。それを実際の利用者となる総務の方に見せて意見をいただき、画面構成のすり合わせを行いました。そこで完成した仕様書のイメージに沿うようにコードを書き画面を作成していきました。 いざ完成してみると「やっぱりこっちのほうがいいかも」としっくりこないことも多発し、最終的に5パターンほど検討して今の配置にたどり着きました。 以下が実際のコードの一部の例になります。より細かい部分は用意したCSSファイルを読み込ませて設定しました。 # メインコンテンツエリア with gr.Row(elem_classes= "main-row" ): # 左側カラム（質問入力エリア） with gr.Column(scale= 3 ): with gr.Group(elem_classes= "content-section" ): # 質問入力セクション with gr.Group(): text_input = gr.Textbox( label= "質問テキスト" , placeholder= "ここに質問を入力してください" , lines= 4.7 , max_lines= 20 ) with gr.Group(): with gr.Row(): reset_btn = gr.Button( "会話をリセット" , size= "lg" , elem_classes= "custom-button half-width reset-button" ) analyze_btn = gr.Button( "送信" , size= "lg" , elem_classes= "custom-button half-width" ) 🗣️）ここで面白かったのは、総務の方の「こんなのが欲しい」という意見に対して実現の可否も含めて調整していく過程です。「このやり方なら難しいけどこっちなら希望は叶えられるのでは？」と自分の中で選択肢を吟味して「それいいね」と言っていただいたときは嬉しかったのを覚えています。そしてイメージ通りの画面が作成できた時は非常に達成感がありました。 完成したツールのその後～つくってどうだったの？の巻～ 作成したツールを総務の方に見せたところ、非常に良い反応をいただくことができました！ デモも試していただき、使いやすいという声もいただきました。現在はローカルではなく、セキュアな環境での運用に向けて開発の方を巻き込む動きをしていただいています。 今後の可能性～未来に羽ばたけの巻～ こちらのツールはLLM活用の最初の一歩としてシンプルな機能になっていますが、今後の可能性として幅広い展開が考えられます。今回はその中から2パターン紹介します。 5Sツールとしての強みを尖らせる方向 現在の評価は 5S項目のどこに問題があるのかわかりにくい仕様になっていますが、各5S項目を数値化して定量的な評価を導入すれば、より総務の方にとって使いやすいツールに改善できるのではと考えています。 既存のテキスト指示機能を応用する方向 Safie Viewer 上に質問用チャットを開けるボタンを設置することで、カメラ映像を目視する時間を減らし、効率的な映像分析が実現できるのではと考えています。 取り組みを終えて～ちょっと成長しましたの巻～ 今回このツールの作成を振り返ってみると、最初に率直に思い浮かんだ感想は「難しかったなあ...」というものでした笑。 プログラミングやコーディングの知識がまったくのゼロからのスタートだったため、予想以上に多くの壁にぶつかり、挫折しそうになる場面がありました。特に初期段階では、専門用語の理解すらままならず、基本的な概念を把握するだけでも時間がかかってしまっていました。 しかし、日々の継続的な学習と実践を通じて、少しずつではありますが確実に進歩を感じられるようになりました。最初は断片的だった知識が次第につながり、システム全体の構造や各コンポーネントの関係性を理解できるようになっていきました。 特に学べたと思うのは、コードを単に「動かす」だけでなく、その「中身」や「仕組み」を理解できるようになったことです。なぜこの関数がここで必要なのか、このパラメータがどのような役割を果たしているのかといった点まで考えられるようになりました。 そして何より、「次はこんな機能が実装できるのではないか」、「このようなツールがあれば業務がもっと効率化できるだろう」といったアイデアが浮かんだときに、それを実現するための具体的な手段や方法をおぼろげながらも構想できるようになったことが、今回の取り組みで得られた最大の収穫だと感じています。 まだまだ学ぶべきことは山積みですが、今回の経験を足がかりに、今後も新たな挑戦へ挑んでいきたいと思います。
1. はじめに：プロジェクトマネージャーに挑戦するか悩んでいる人へ みなさん、こんにちは。2024年9月にセーフィーに入社して、ハードウェア開発プロジェクトマネージャー（以下、HW開発PM）として働いている松岡です。 それまでは新卒からメカエンジニアとして働いており、セーフィーでHW開発PMに挑戦しましたので、その挑戦の振り返りを記します。 セーフィーのHW開発PMに興味はあるものの、募集要項を見て「自分にはまだ早いかも」「ハードルが高いな」と感じたことがある方もいるかもしれません。 実は私自身も、PMとしての十分な経験がない状態でセーフィーに応募しました。 このブログでは、経験が浅い立場からでもチャレンジできた私の実体験をお伝えします。 1. はじめに：プロジェクトマネージャーに挑戦するか悩んでいる人へ セーフィーのHW開発PMの担当業務とは 2. セーフィー入社前について 私の経歴 転職で実現したかったこと 募集要項のどこにハードルを感じていたのか 3. セーフィーに入社して 入社前の不安、実際にどうだったか 活きた経験 感じたこと 4. 振り返り（9ヶ月働いてみて） 開発PMとして ハードウェアエンジニアとして 5. この先に目指す姿 開発PMとして ハードウェアエンジニアとして その先のキャリアとして 6. おわりに セーフィーのHW開発PMの担当業務とは HW開発PMという職種は、 開発PMとハードウェアエンジニアの両方の役割を担う職種 になります。 ハードウェアエンジニア 開発パートナーと連携して、設計、性能評価、信頼性試験、法規制対応、量産品質の確保までハードウェア開発を推進する 開発PM プロジェクト全体の開発計画を策定し、品質、コスト、納期、リスクなどを管理しながら、開発パートナーや社内のエンジニア、関係部署などと連携して、プロジェクトの目標を達成できるように推進する 2. セーフィー入社前について 私の経歴 私は、これまでのキャリアで2つの会社を経験してきました。 1社目 電機メーカー ：R&D部門に所属し、新製品開発に携わっていました。しかし、最後まで製品を作り上げられずに終わり、 「自分の手で製品やサービスを世に送り出したい」 という強い思いから転職を決意しました。 2社目 IT会社 ：IoT機器開発を行い、サービス化まで実現するという目標は達成できました。しかし、品質問題によるメンテナンス作業での出張が多くなり、今度は 「品質を意識した製品やサービスを作り上げたい」 という新たな課題意識が芽生え、再度転職を考えるようになりました。 転職で実現したかったこと 前職までの経験を通じて、私は自身のスキル不足を感じ、以下の2点を身につけたいと強く思うようになりました。 ハードウェアエンジニアとして、品質を意識した製品開発を行える人材になりたい ビジネス視点を持ったマネジメント人材になりたい 転職先を調査している際に、セーフィーのHW開発PM職がまさに私の思い描くキャリアにピッタリだと感じました。しかし、同時に募集要項に不安を覚えたのも事実です。 募集要項のどこにハードルを感じていたのか 特にハードルだと感じたのは以下の点でした プロジェクトマネージャー職への不安 役割と責任 ：プレイヤーとは異なり、プロジェクトを成功に導くために具体的に何をすればよいのか分からず、漠然とした不安 成果 ：これまで経験のない業務で本当に成果を出せるのかという不安 開発メンバーのマネジメント ：ソフトウェアエンジニアを含むチームをマネジメントできるかという不安 スキルや知識、経験への不安 具体的なマネジメント手法を知らないこと ソフト開発の理解不足 ハードウェアエンジニアとしての不安 セーフィー製品における法規制対応や量産品質の確保といった特定の専門分野における知識や経験の少なさ そのハードルを乗り越えられそうと思ったのはなぜか そんな不安を抱えつつも、セーフィーへの応募を決断し、最終的に入社できたのは、選考プロセスの中で不安が払拭されていったからです。 面接前のカジュアル面談 ：この職種は、エンジニアスキルも重要だが、PM職としての業務に重きを置いていると説明していただき、自分の目指す方向性と一致していることを確認できました。 面接後にメンバーとの入社前カジュアル面談 ：面接前カジュアル面談と比べて、より具体的な業務内容やオンボーディング内容に関する詳細な説明を受け、入社後のイメージが明確になり、不安が払拭されました。 3. セーフィーに入社して 入社前の不安、実際にどうだったか 意外とスムーズに適応できたこと 「ソフトウェア開発の知識がない中で開発メンバーをマネジメントできるか」という点については、入社後、想像以上にソフトウェアエンジニアとの連携が密接であることが分かり、そこまで大きな壁ではないと感じています。ソフトウェア開発の深い知識がなくても、PMとして必要なコミュニケーション能力や課題解決能力があれば、円滑な連携が可能です。また、私自身セーフィー独自のファームウェア SafieClient に触れ、ビルドしてテストすることでソフトウェア開発の理解を進めております。周囲には相談しやすいメンバーがいて、疑問点があればすぐに相談できる環境が整っています。 やはり直面した課題、得られた手厚いサポート HW開発PMは非常に幅広い知識と経験が求められる領域だと実感しています。前職では他の部署が担当していたような業務も自分の役割に入ってくるため、経験が少ない分野では戸惑うことも少なくありません。 しかし、社内では、こうした未経験分野のサポートや育成に非常に力を入れています。単に業務を割り振るだけでなく、 「どうすればできるようになるか」を一緒に考えてくれる文化がある ため、安心して挑戦できています。また、オンボーディング面でもサポートが手厚く、開発PMとして、ハードウェアエンジニアとして必要な知識やスキルを身に付けるためのプログラムを用意して頂き、少しずつ担当領域が広がっていることを実感しています。 活きた経験 前職までに培ったメカエンジニアとしての経験は非常に活きていると感じます。特に「ハードウェアの設計・評価に関する経験」と「製造現場での問題解決経験」は、ODMベンダーとの技術的な議論において、相手の言っていることの本質を理解し、的確な質問や指示を出す上で大きな助けになっています。 感じたこと HW開発PMのチームは社内では比較的新しく、現在も発展途上にあるため、私たちは業務手順書の整備を積極的に進めています。私自身もその一端を担い、各メンバーが培ってきた豊富な知識を手順書に落とし込む作業に携わっています。 特に、私がメカエンジニアとして培ってきた経験は、この手順書作成において大いに役立っており、メンバーと活発に議論しながらより良いものを作り上げています。これは、私と同じように経験が浅い方がスムーズにチームに加わり、活躍できる環境を皆で協力して築いている証でもあります。 4. 振り返り（9ヶ月働いてみて） 入社から9ヶ月が経ち、開発PMとしてもハードウェアエンジニアとしても多くの学びがありました。 開発PMとして 身についたこと ： 限られたリソースで目標を達成するというコミットメント意識 が身につきました。 成長を実感したこと ：メンバーのサポートのもと、計画通りにプロジェクトを推進し、販売を開始することができました。今後は、オンボーディングで得た知識の実践と、メンバーのスキルを吸収し、 独り立ち を目指します。 出来ていないこと ：前任者から引き継いだプロジェクトでは、コストを考慮した仕様策定やODMメーカー選定といったプロジェクト序盤の作業に携わる機会がありませんでした。次回のプロジェクトでこれらを実践し、身につけていきます。 ハードウェアエンジニアとして 身についたこと ： ユーザー体験を、品質を意識して開発すること ができました。 成長を実感したこと ：品質を意識した開発品の評価、評価レポート作成、評価レビュー会を主導し、商品化プロセスのマイルストーンを達成できたことは大きな自信になりました。 出来ていないこと ：開発製品における認証や規制に関するODMメーカーとのやり取りは、まだメンバー頼みになっていました。オンボーディングでの学習や、他製品の実施事例を参考に、次回のプロジェクトでは自ら実践して身につけます。 5. この先に目指す姿 開発PMとして 私は、まず「プロジェクトを完遂できるPM」を目指します。計画通りにプロジェクトを進め、目標とする品質・コスト・納期で成果物を完成させ、プロジェクトを無事にクローズできるPMになることです。 ハードウェアエンジニアとして ハードウェアエンジニアとしては、自身の専門性を活かして技術課題を自律的に解決し、周囲と連携しながら品質・コスト・納期を意識してプロダクトの成功に貢献できる状態を目指します。 その先のキャリアとして 将来的に目指す姿は、技術とビジネス、そして人を繋ぐ「ハブ」となる存在です。単なるプロジェクト管理に留まらず、プロダクトの成功に深く貢献できるPMとして、さらにハードウェアエンジニアとしての専門性を深めることで「プロダクト全体を俯瞰し、ビジネス価値を最大化できる技術者ビジネスパーソン」を目指します。 6. おわりに セーフィーでは、私のようにPM経験が浅いメンバーでも、挑戦と成長の機会が豊富にあります。 HW開発PMを現在も募集しておりますので、「望ましい経験／スキル」の全てが揃っていなくても、その一つ一つをセーフィーで極めていきたい！というあなたの意欲を、ぜひ私たちに聞かせてください。 safie.co.jp
はじめに こんにちは、データドリブン推進室でデータエンジニアをしている小宮です。 最近、個人的に気になっていたOSS BIツールのLightdashとMetabaseを社内でPoCする機会があったので、それぞれ使ってみた所感をまとめてみました。 はじめに 背景 比較軸 比較表 特に差が大きかったポイント Lightdashはスペースをネストできない（2025/5時点） ユーザの利用ログの取得 dbtとの連携 選ばれたのはLightdashでした 最後に 背景 データ分析の社内展開をさらに進めていく中で「より多くのメンバーが扱いやすく、かつ既存の分析基盤との親和性が高いBIツール」を検討することになりました。 そこで、分析基盤で導入しているdbtとの連携に強いLightdashと、使いやすさに定評のある Metabaseを候補に選び、PoCを実施しました。 比較軸 BIツールはユーザーの使いやすさと開発業務の効率性のバランスを取る必要があります。 そこで、以下の観点を重視しました。 開発業務の効率性：データモデル開発やダッシュボード作成がスムーズに行えるか ユーザビリティ：非エンジニアでもグラフを簡単に作れるか、日本語対応の有無 運用機能：通知・アラート、権限管理、利用ログの取得といった運用に必要な機能の有無 比較表 どちらもセルフホスティングでローカルに環境を作って触りましたので、その前提での比較表になります。 比較項目 Lightdash Metabase UI/UX ◯ ややエンジニア寄りな印象 ◎ 直感的でビジネスユーザでも使いやすい グラフの自由度 △ 基本的なものはある ◎ 種類が豊富（Tableauに近い） データガバナンス ◎ ymlで定義一元化 △ 属人化しやすい Dashboard as Code ◯ ◯ 機能はあるが有料プランのみ dbt との親和性 ◎ yml定義を直接利用 △ 標準では用意されていない Git 連携 ◎ dbt writeback機能で直接PR作成 × 日本語対応 × ◯ 日本語に違和感あり 学習コスト ◯ dbt経験者には低い ◎ 非エンジニアにも優しい 私たちのチームのデータ分析基盤 ではDWH層に DataVault2.0 、データマート層にディンメンショナルモデリングを採用しており、データモデリングに注力した設計を行っています。 そのため、BIツール上での複雑なロジックは最小限で済み、両ツールとも基本的な分析ニーズを満たすことができそうでした。 特に差が大きかったポイント PoCを通じて使い勝手や運用面など、2つのBIツール間で特に差が際立った点がいくつかありました。 以下に代表的なものを紹介します。 Lightdashはスペースをネストできない（2025/5時点） Lightdashはスペースというフォルダのような概念を持っていますが、このスペース機能は階層構造を持つことができません。 部署ごとにダッシュボードを階層的に整理したいケースはよくあるので、この点は実運用を考えると大きな差になると感じました。Metabaseでは階層構造に対応しており管理がしやすい設計になっています。 ※検証段階では未実装でしたが、新たに スペースのネスト が実装されたようです！！！ ユーザの利用ログの取得 どのダッシュボードがどれだけ見られているか、表示速度はどうかなど、日々の運用で改善につながる指標を把握する必要があります。 Lightdashは基本的なインサイトダッシュボードを標準提供しており、セルフホスティングであれば内部のPostgreSQLメタデータに直接アクセスして自由に分析も可能です。 一方でMetabaseで提供している同等の機能のUsage Analyticsは、有償プランが必要でOSS版ではカバーされていません。 dbtとの連携 Lightdashの強みであるdbtとの連携はやはり大きな差を感じるポイントでした。 ymlによる定義でデータガバナンスを担保できる点と、UI上から作成した指標もdbt writeback機能を通してymlに反映できる点もよかったです。 選ばれたのはLightdashでした どちらのBIツールも操作性や導入のしやすさという点では優れており、甲乙つけがたい印象でした。 PoCの定量的な評価以外にも実際に触ってどうだったかの感触など定性的な部分も含めて、 Lightdashの方が以下の理由でフィットしそうだなと思いました。 ビジネスユーザーにも十分扱えるシンプルなUI dbtとの統合によるメトリクス定義の一元管理がしやすい アナリストもGitを使った開発を行っているため、チーム全体でコードベースの運用に慣れている 将来的な拡張性やCI/CDの自動化による運用面のガバナンスを担保しやすい 最後に 私たちのチームではLightdashが合いそうでしたが、BIツールの選定は単なる機能比較だけでなくチームの文化やスキルセットにも大きく依存すると思います。 チームによって最適なBIツールは様々あると思いますので参考になれば幸いです！
はじめに セーフィー株式会社 AI開発部 でテックリードを務めます橋本です。 本記事は、社内勉強会で取り上げた「プログラミングパラダイム」についての内容をまとめたものです。日常的に使っている Python や C++ といった言語でも、「副作用をどう扱うか」という視点の重要性を感じており、それをチーム内でも共有したいと思い勉強会のテーマとしました。 副作用とは、関数や処理が外部の状態に影響を与えたり、外部から影響を受けたりすることを指します。プログラムの規模が大きくなるほど、こうした副作用がバグの原因になりやすく、保守性にも影響します。この問題に対して、宣言型プログラミング、特に純粋関数型プログラミングの考え方は多くの示唆を与えてくれます。 本記事では、Haskell を例にしながら、命令型と宣言型の違い、副作用との向き合い方、そしてそれらの考え方をどのように他の言語に活かせるかを紹介していきます。 はじめに 命令型プログラミングの特徴と課題 命令型の特徴 Pythonによる実装例 オブジェクト指向との関係 命令型が抱える課題 宣言型プログラミングの考え方 宣言型とは何か 宣言型の特徴とアプローチ Haskellによる実装例 Haskell に見る副作用の扱い 副作用とは何か？ コンテキストと持ち上げ Functor / Applicative / Monad の枠組み Functor：コンテキスト内の値に関数を適用する Applicative：関数そのものをコンテキストに包んで適用する Monad：コンテキスト間の連続した処理をつなげる 他の言語で宣言型の考え方を活かす Python C++ Rust おわりに 命令型プログラミングの特徴と課題 命令型の特徴 命令型プログラミング（Imperative Programming） は、「どのように処理を進めるか」を具体的な手順として記述するスタイルです。1950年代から1960年代初頭にかけて、コンピュータの普及とともに広まりました。 主な特徴 状態の変化に基づく処理 プログラム内の変数が繰り返し更新され、その変化によって処理の流れが決まります。例えば、ループ内で集計用の変数を加算していくような処理が代表的です。 逐次実行（手続き型） 命令は記述された順に上から下へ実行されます。制御の流れが明示的でわかりやすい一方、状態の追跡が難しくなることもあります。 繰り返しや分岐による制御 for や while によるループ、 if や switch による条件分岐を使い、柔軟な制御フローを実現します。 このような特徴は、 ノイマン型アーキテクチャ （プログラムとデータを同一メモリ空間に格納し、逐次実行するモデル）と親和性が高く、今日でも多くの言語の基本構造として使われています。 Pythonによる実装例 命令型プログラミングの特徴を具体的にイメージするために、Python を使った簡単な例を見てみましょう。 ## 1から10までの合計を計算する total = 0 for i in range ( 1 , 11 ): total += i # 状態（total）がループのたびに更新される このような記述スタイルは、多くのプログラミング言語で標準的に用いられています。 オブジェクト指向との関係 オブジェクト指向プログラミング（OOP） は、命令型プログラミングのサブパラダイムと捉えることができます。なぜなら、OOP でも依然として「状態の変化」と「手続きの実行」によって処理が進むからです。 class Cat : def __init__ (self, color): self.color = color # 状態を持つ def meow (self): print (f "I'm a {self.color} cat. Meow!" ) 命令型が抱える課題 命令型は柔軟で理解しやすい一方で、状態の追跡や副作用の管理に課題があります。 特に、変数の状態が頻繁に変わるようなコードでは、処理の意図やバグの原因を追いにくくなります。また、関数が外部に影響を及ぼす副作用を持つと、テストや再利用が難しくなり、保守性も低下します。 宣言型プログラミングの考え方 宣言型とは何か 宣言型プログラミング（Declarative Programming） は、「どのように処理を行うか」ではなく、「何をしたいのか」を記述するスタイルです。意図が明確で、状態や制御の管理が最小限で済むという特徴があります。 宣言型の特徴とアプローチ 宣言型プログラミングでは、以下のような設計上の特徴・原則が重視されます。 不変性（Immutability） 値や状態を途中で変更せず、すべての変数は定数として扱われます。 純粋関数（Pure Function） 同じ入力に対して常に同じ出力を返し、副作用を一切持たない関数です。外部の状態に依存せず、予測可能な挙動が保証されます。 遅延評価と記述順の自由度 計算は必要になるまで評価されないため、処理の記述順に意味が薄く、より宣言的な記述が可能です。 これらにより、状態や制御の複雑さを抑えながら、保守性・再利用性に優れたコードを書くことができます。 Haskellによる実装例 命令型のスタイルでよく書かれる処理が、宣言型の代表である Haskell でどのように記述されるのかを見ていきます。具体例を通じて、宣言型プログラミングの特徴である 不変性、純粋関数、遅延評価 がどのように現れるかを確認します。 total :: Int -- totalはInt型と宣言 total = sum [ 1 .. 10 ] -- totalを「1から10までのリストをsum関数で合計する関数」と定義 main :: IO () -- エントリポイントは main 関数。戻り値がIO () 型という宣言 main = print total -- main関数の定義 sum 関数を再帰関数を使って書くこともできます。 sumArray :: [Int] -> Int sumArray [] = 0 -- 基底ケース sumArray (x : xs) = x + sumArray xs -- 再帰ケース: 先頭の要素を残りの要素の合計に足す main :: IO () main = print (sumArray [ 1 .. 10 ]) Haskell に見る副作用の扱い ここからは、Haskell を通じて、宣言型プログラミングにおける副作用との向き合い方を見ていきます。 Haskell は、副作用の扱いを明示的に設計に取り込んでいる言語であり、純粋関数型プログラミングの特徴を強く備えています。そのため、副作用を制御・分離する考え方を学ぶには最適な題材といえます。 副作用とは何か？ 副作用（Side Effect） とは、関数や処理が、計算結果以外の影響をプログラム内外に及ぼすことを指します。例えば以下のようなものがあります。 非決定性 同じ入力でも結果が変わる処理。例：乱数生成、現在時刻の取得など。 外部状態の変更 例：ファイルへの書き込み、グローバル変数の更新、データベースの変更など。 外部依存の参照 例：ファイルの読み込み、ユーザー入力、環境変数の取得など。 コンテキストと持ち上げ Haskell では、副作用をそのまま実行するのではなく、コンテキストと呼ばれる構造の中に閉じ込めて扱います。これにより、副作用や曖昧さを型レベルで明示し、安全かつ予測可能に制御できるようになります。 以下に、代表的なコンテキストの例を示します。 通常の型 コンテキスト付きの型 説明 Int [Int] リスト。複数の値を1つのまとまりとして扱う。 Int Maybe Int 値がある（Just）か無い（Nothing）かを区別できる型 Int IO Int 外部の副作用を伴う処理で得られる Int 通常の関数や値を、こうしたコンテキストの中でも使えるように変換する操作のことを、 持ち上げ（lift） と呼びます。 この仕組みは、次のような 可換図式（commutative diagram） で表すことができます。可換図式とは、定義域と値域（型）をノード、関数やその関係性を矢印で示し、それらの構造的対応を視覚的に捉える図です。 例えば、以下の図では： 下段が通常の関数適用 g :: A -> B 上段が g を f によって持ち上げた関数 f g :: f A -> f B を表しています。 Functor / Applicative / Monad の枠組み Haskell では、副作用や不確実性を含む値（コンテキスト付きの値）を安全に扱うために、Functor・Applicative・Monad という抽象的な枠組みが用意されています。これらは順にできることが広がっていきます。 Functor：コンテキスト内の値に関数を適用する Functor は、 f a というコンテキストに包まれた値に、通常の関数 a -> b を適用したいときに使います。 -- fmap の定義: (a -> b) と f a を受け取り、f b を出力する fmap :: (a -> b) -> f a -> f b 可換図式を用いると、引数と出力を視覚的に整理できます。 通常の関数 g をコンテキストに包まれた値に適用する具体例を示します。リストに対するブロードキャスト演算は、Haskell 以外の言語でもなじみがあるのではないでしょうか。 g n = n * 2 main = do print $ fmap g [ 1 , 2 , 3 ] -- [2, 4, 6] print $ fmap g (Just 5 ) -- Just 10 print $ fmap g Nothing -- Nothing Applicative：関数そのものをコンテキストに包んで適用する Applicative は、関数そのものがコンテキストに包まれている場合に使います。 f (a -> b) という形の関数を f a に適用するための仕組みです。 pure :: a -> f a -- pure関数は、値aを、コンテキスト f a に持ち上げます -- Applicative 演算子は、Functor の第一引数 a -> b が f (a -> b) に変わっただけです ( <*> ) :: f (a -> b) -> f a -> f b pure 関数で (*2) を持ち上げたあと、コンテキスト付の型に対して、演算子 <*> を使って作用させます。 main = do print $ pure ( * 2 ) <*> [ 1 , 2 , 3 ] -- [2, 4, 6] print $ pure ( * 2 ) <*> Just 5 -- Just 10 Monad：コンテキスト間の連続した処理をつなげる Monad は、値だけでなく処理そのものがコンテキスト付きであるときに、それらを連鎖的につなげるための仕組みです。 ( >>= ) :: m a -> (a -> m b) -> m b -- バインド演算子の定義 このように Monad を使うと、途中で失敗したとき、安全に次の処理に進めるかを自動的に判断できます。 -- xが0ならNothing、それ以外ならJust xを返す関数 safeDiv x y = if y == 0 then Nothing else Just (x `div` y) -- xが負ならNothing、それ以外ならJust xを返す関数 safeSqrt x = if x < 0 then Nothing else Just (floor (sqrt (fromIntegral x))) -- xを2で割る関数 halve x = Just (x `div` 2 ) result = safeDiv 10 2 >>= safeSqrt >>= halve -- Just 1 他の言語で宣言型の考え方を活かす 命令型言語でも、宣言型の特徴が取り入れられています。 Python リスト内包表記は、手続き的にforループを使うのではなく、宣言的にリストを作成します。 squares = [x** 2 for x in range ( 10 ) if x % 2 == 0 ] ラムダ関数とmap add = lambda x, y: x + y result = list ( map ( lambda x: x * 2 , [ 1 , 2 , 3 ])) # [2, 4, 6] C++ C++17 では、値があるかどうかを型で扱える std::optional が導入されています。 std :: optional < int > twice ( int n) { return n > 0 ? std :: optional < int >{n * 2 } : std :: nullopt ; } C++23 では、Optional に対して Haskell のモナド的演算に相当する and_then が追加されました。 int main () { std :: optional < int > o = 2 ; assert (o. and_then (twice). and_then (twice). value () == 8 ); } このように、副作用やエラーの可能性を含んだ処理を安全に連結できる仕組みが取り入れられています。 Rust 近年注目されている Rust も、宣言型プログラミングの考え方を強く取り入れられており、型システムによって副作用の制御が言語レベルで保証する設計がなされています。例えば、 Option 型による明示的なエラーハンドリングによって副作用を局所化することができます。 fn double (n: i32 ) -> Option < i32 > { Some (n * 2 ) } fn main () { let result = Some ( 5 ) . and_then (double) . and_then (double); // Some(20) } このように、 and_then を使って処理を連鎖させることで、状態の変更やエラー分岐を持たずにロジックを構築できます。 おわりに 本記事では、命令型と宣言型という二つのプログラミングパラダイムを比較しながら、特に副作用の扱いに注目してその設計思想を紹介しました。命令型では、状態の変化と逐次実行を通じて柔軟な処理が可能である一方、状態の追跡や副作用の管理が複雑化する傾向があります。 それに対し、宣言型プログラミングは処理の目的を明示的に記述し、副作用を抑えることで、コードの予測可能性と保守性を高めるアプローチです。Haskell を例に、コンテキストや持ち上げといった概念、そして Functor・Applicative・Monad という構造を通して、副作用を型として管理する手法を紹介しました。 こうした考え方は、純粋関数型言語に限らず、Python・C++・Rust をはじめとした他の言語でも応用可能です。日々の開発においても、関数の純粋性や状態の局所化を意識することで、より読みやすく、安全なコードを書く参考になれば幸いです。
はじめに CVPR (Computer Vision and Pattern Recognition Conference) は、コンピュータビジョンとパターン認識の分野における最前線の研究成果を集める国際会議です。今年の論文提出数は13,008件で、昨年のCVPR 2024から約13％の増加を記録しました。その中で採択されたのは2,878件、採択率は22.1％です。この採択率は CVPR 2010以降で最も低い数字 となっており、例年以上の競争の激しさが伺えます。厳しい競争を勝ち抜いた論文の中から特に優れた14件の論文がBest Paper Award候補として選出されました。 本記事では 昨年 に引き続き、これらのAward候補となった論文の概要と、その技術的な特徴を紹介します。最先端の技術トレンドの全体像を把握し、皆様の研究開発の一助となることを願っています。 はじめに CVPR 2025の技術トレンド Award Candidatesの紹介 マルチビューおよびセンサーからの3Dデータ生成 FoundationStereo: Zero-Shot Stereo Matching VGGT: Visual Geometry Grounded Transformer MegaSaM: Accurate, Fast and Robust Structure and Motion from Casual Dynamic Videos TacoDepth: Towards Efficient Radar-Camera Depth Estimation with One-stage Fusion Convex Relaxation for Robust Vanishing Point Estimation in Manhattan World Zero-Shot Monocular Scene Flow Estimation in the Wild 3D Student Splatting and Scooping DIFIX3D+: Improving 3D Reconstructions with Single-Step Diffusion Models 画像と動画の生成 Navigation World Models 「マルチモーダル学習」と「ビジョン、言語、推論(Reasoning)」 Molmo and PixMo: Open Weights and Open Data for State-of-the-Art Vision-Language Models Generative Multimodal Pretraining with Discrete Diffusion Timestep Tokens その他注目論文 Descriptor-In-Pixel : Point-Feature Tracking For Pixel Processor Arrays The PanAf-FGBG Dataset: Understanding the Impact of Backgrounds in Wildlife Behaviour Recognition UniAP: Unifying Inter- and Intra-Layer Automatic Parallelism by Mixed Integer Quadratic Programming おわりに CVPR 2025の技術トレンド CVPR 2025の公式ニュース「 Three of the Hottest Topics in Computer Vision Today 」では、今年の提出論文における主要な技術トレンドとして以下の3つが挙げられています。これらを押さえることで、会議全体の方向性が見えてきます。 マルチビューおよびセンサーからの3Dデータ生成 : この技術は、複数の異なる視点から撮影された画像や、深度センサー（例：LiDAR、ToFセンサー）から得られる情報を統合することで、現実世界の物体やシーンの正確な3Dモデルを生成します。これにより、自動運転、ロボット工学、バーチャルリアリティ、拡張現実など、様々な分野で高精度な空間理解が可能になります。 画像と動画の生成 : この技術は、人工知能、特に深層学習モデル（例：GANs、Diffusion Models）を用いて、テキストの説明、既存の画像、またはランダムなノイズから、リアルな画像や動画を生成します。これにより、デザイン、エンターテイメント、コンテンツ制作、データ拡張といった分野で、これまでにない視覚的コンテンツの創造とカスタマイズが可能になります。 「マルチモーダル学習」と「ビジョン、言語、推論(Reasoning)」 : マルチモーダル学習は、画像、音声、テキストなど、複数の異なる種類のデータを同時に学習するAIの技術です。これにより、AIは単一のデータ形式からでは得られない、より深く包括的な理解を獲得します。特に「ビジョン（視覚情報）」、「言語（テキスト情報）」、そしてそれらを統合した「推論（Reasoning）」能力を組み合わせることで、AIは人間のように世界を認識し、状況を理解し、複雑な問題に対して適切な判断を下せるようになります。例えば、画像の内容を言語で説明したり、テキスト指示に基づいて画像を生成したり、あるいは視覚情報と言語情報を組み合わせて複雑な質問に答えたりする能力がこれに当たります。 Award Candidatesの紹介 今年の技術トレンドをふまえて、分野ごとにAward Candidates論文の概要を紹介します。 マルチビューおよびセンサーからの3Dデータ生成 FoundationStereo: Zero-Shot Stereo Matching 著者：Bowen Wen, Matthew Trepte, Joseph Aribido, Jan Kautz, Orazio Gallo, Stan Birchfield セッション：Oral Session 2A: 3D Computer Vision 提案手法は、ゼロショット汎化に優れたステレオ深度推定の基盤モデルです。多様で写実的な100万組の合成ステレオデータと、曖昧なサンプルを除く自動キュレーションにより学習をおこなっています。単眼深度推定の事前知識を活用するバックボーンや長距離コンテキスト推論を用いることで、ドメインをまたいで高精度かつ高いロバスト性を実現しています。 出典：FoundationStereo: Zero-Shot Stereo MatchingのFigure 2, URL: https://arxiv.org/abs/2501.09898 (2025年6月5日アクセス) 提案されたアーキテクチャでは、まず固定された DepthAnythingV2 から得られる単眼事前知識を活用し、マルチレベルCNNによる高周波特徴と組み合わせて特徴を抽出します。次に、Attentive Hybrid Cost Filtering（AHCF）により、抽出された特徴を効率的に統合し、コストボリュームを生成します。特に、Disparity Transformer（DT）は自己注意機構により、長距離のコンテキスト情報を効果的に捉える役割を担います。その後、GRUブロックは初期視差を反復的に精緻化し、最終的な視差マップを出力します。 VGGT: Visual Geometry Grounded Transformer 著者：Jianyuan Wang, Minghao Chen, Nikita Karaev, Andrea Vedaldi, Christian Rupprecht, David Novotny セッション：Oral Session 2A: 3D Computer Vision Visual Geometry Grounded Transformer (VGGT) という新しいフィードフォワード型トランスフォーマーモデルを提案しています。VGGTは数枚から数百枚の画像を入力として、カメラパラメータ、深度マップ、点群、トラッキング情報など、画像の3Dタスクを一括で高速に推定します。従来の3D再構成手法では最適化処理が必要でしたが、VGGTはポストプロセスなしで高精度を実現し、カメラ姿勢推定や点群再構成など複数のタスクで最先端性能を達成しています。さらに、下流タスクにも応用可能で、例えば新規視点合成や動画中の点追跡性能を大幅に向上させることができます。 出典：VGGT: Visual Geometry Grounded TransformerのFigure 2, URL: https://arxiv.org/abs/2503.11651 (2025年6月5日アクセス) 入力画像をDINOでトークン化し、カメラ予測用の「カメラトークン」を付加します。これらのトークンはフレーム単位と全体のアテンションを繰り返し適用され、専用のヘッド（Camera HeadやDPT Head）を通じ、最終的に各フレームのカメラパラメータ、深度マップ、点群、トラッキング特徴が出力されます。 MegaSaM: Accurate, Fast and Robust Structure and Motion from Casual Dynamic Videos 著者：Zhengqi Li, Richard Tucker, Forrester Cole, Qianqian Wang, Linyi Jin, Vickie Ye, Angjoo Kanazawa, Aleksander Holynski, Noah Snavely セッション：Oral Session 3A: 3D Computer Vision 従来の技術では、動きの多い動画やカメラの動きが少ない映像から、3D構造（奥行き情報）やカメラ位置を正確に推定するのは困難でした。特に、日常的な動画ではこれらの条件を満たさないことが多く、既存の手法では誤った結果になりがちでした。 この論文は、深層学習に基づくVisual SLAM（カメラ映像から自己位置推定と環境地図作成を同時に行う技術）の手法を改良。訓練方法や処理の仕組みに工夫を加えることで、複雑でダイナミックなシーンや、カメラの動きが自由で視差（位置による見え方の違い）が限定的な動画であっても、高速かつ安定して高精度な推定を可能にするシステムを提案しています。 出典：MegaSaM: Accurate, Fast, and Robust Structure and Motion from Casual Dynamic VideosのFigure 1, URL: https://arxiv.org/abs/2412.04463 (2025年6月5日アクセス) 本技術では、まず動画から数フレームごとに画像を取り出し、それぞれの画像間で似ている部分を検出し、それらの対応点の位置関係をもとに、カメラがどの方向に動いたかを推定します。 この際、歩いている人や動いている車は背景と関係ないため、動いている領域を識別し、計算から除外します。 また、各フレームごとに深度マップをモデルで推定し、それを使って空間の立体構造も考慮に入れながらカメラ位置を調整します。 これらすべての情報をまとめてAIが一括で最適化することで、何も手動調整しなくても、動画から正確なカメラの動きと、シーンの3D構造を得ることができます。 TacoDepth: Towards Efficient Radar-Camera Depth Estimation with One-stage Fusion 著者：Yiran Wang, Jiaqi Li, Chaoyi Hong, Ruibo Li, Liusheng Sun, Xiao Song, Zhe Wang, Zhiguo Cao, Guosheng Lin セッション：Oral Session 3A: 3D Computer Vision TacoDepthは、効率的で正確なRadar-Camera深度推定のための、ワンステージフュージョンモデルです。従来技術のマルチステージフレームワークが抱える時間的制約とロバスト性の問題を解決するため、グラフベースのRadar構造抽出器とピラミッドベースのRadarフュージョンモジュールを設計。これにより、中間深度を必要とせずに、効率性とロバスト性を向上させました。 出典：TacoDepth: Towards Efficient Radar-Camera Depth Estimation with One-stage FusionのFigure 3, URL: https://arxiv.org/abs/2504.11773 (2025年6月5日アクセス) 技術的なポイントとして、グラフベースのRadar構造抽出器がRadar点群の幾何学的構造とトポロジーを捉え、ピラミッドベースのRadarフュージョンモジュールが画像とRadarの特徴を階層的に統合します。また、Radar中心のフラッシュアテンションメカニズムを導入し、効率的なクロスモーダル相関を実現しています。nuScenesとZJU-4DRadarCamデータセットでの実験により、精度と処理速度が大幅に向上することを示しました。 Convex Relaxation for Robust Vanishing Point Estimation in Manhattan World 著者：Bangyan Liao, Zhenjun Zhao, Haoang Li, Yi Zhou, Yingping Zeng, Hao Li, Peidong Liu セッション：Oral Session 4C: 3D Computer Vision この論文は、人工物の多くは直交座標系に平行に作られているというマンハッタンワールド仮説における消失点の高精度な推定手法を提案しています。従来手法は計算コストが高いか、最適解を保証できないという課題がありました。本研究では、マンハッタンワールドと仮定することで、高精度な推定ができるようになりました。具体的に、誤差を抑えつつ複数の消失点と線分の関係を同時に求めるため、「Convex Relaxation」という数学的手法を用い、問題を解きやすい形に変換します。そして、「GlobustVP」という新しいアルゴリズムを提案し、高速かつロバスト性高く消失点を推定します。 出典：Convex Relaxation for Robust Vanishing Point Estimation in Manhattan WorldのAlgorithm 1, URL: https://arxiv.org/abs/2505.04788 (2025年6月5日アクセス) GlobustVPアルゴリズムは、画像内の線分から3つの消失点を段階的に求める手法です。 各ステップでは、残っている線から補助Tensorを作り、数理最適化（SDP）を使って消失点を一つ推定します。その消失点に最も合う線（inlier line）を抽出し、以後の処理から除外します。これを3回繰り返してVP1〜VP3を推定し、残りの線はoutlierとします。最後に、Manhattan Worldの条件（直交性）を満たすように消失点を調整する後処理を行います。 Zero-Shot Monocular Scene Flow Estimation in the Wild 著者：Yiqing Liang et al. セッション：Oral Session 5C: Visual and Spatial Computing 単眼RGB画像ペアからシーンフロー（3D構造と動きを同時に推定するタスク）を導出する手法です。ViTベースのネットワークでpointmapと3Dオフセットを出力し、未知のドメインでも高精度なシーンフロー推定を実現します。大規模・多様なデータセットとスケール適応型学習戦略により、ゼロショット汎化性能を大きく向上しました。DAVISのような現実世界のデータセットシーンにおいて、未知なデータセットながら高精度な動きを再現し、高い汎化性能を示しました。 出典：Zero-Shot Monocular Scene Flow Estimation in the WildのFigure 2, URL: https://arxiv.org/abs/2501.10357 (2025年6月5日アクセス) 図は、提案手法のシステム構成を示しており、2枚のRGB画像 C1（t1）と C2（t2）を入力として、3つの出力マップを同時に生成します。ViTベースのエンコーダを共有し、各フレームに対応したデコーダがクロスアテンションで情報を融合。出力ヘッドHX1とHX2が時刻t1, t2における3D点群（pointmap）を、HSがシーンフロー（3Dオフセット）を予測しています。学習時は点群・動き・オプティカルフローの3種の損失を用いて、幾何と動きの整合性を高めています。 3D Student Splatting and Scooping 著者：Jialin Zhu, Jiangbei Yue, Feixiang He, He Wang セッション：Oral Session 5C: Visual and Spatial Computing 3D Gaussian Splatting の定式化を見直し、Student Splatting and Scooping（SSS）という新たな手法を提案しています。従来のガウス分布の代わりに、位置、スケール、回転、裾の長さの自由度を与えた柔軟なスチューデントのt分布を用いた混合モデルを導入し、また、正の密度（Splatting）と負の密度（Scooping）の両方を扱うことで表現力を高めています。さらに、学習の安定化のための新しいサンプリング手法も導入しています。実験の結果、SSSは既存手法を品質およびパラメータ効率の両面で上回りました。 出典：3D Student Splatting and ScoopingのFigure 2, URL: https://arxiv.org/abs/2503.10148 (2025年6月5日アクセス) 著者らは、(a) トーラス形状のトポロジーを再構成できるかどうかを実験しています。正の密度のみを用いた場合、(b) 2つの要素では不十分であり、(c) 正しいトポロジーを捉えるには少なくとも5つの要素が必要です。一方、(d) 負の密度を使って中央の密度を打ち消すことで、正と負の要素を1つずつ用いるだけでトポロジーを正しく再現することができます。 DIFIX3D+: Improving 3D Reconstructions with Single-Step Diffusion Models 著者：Jay Zhangjie Wu, Yuxuan Zhang, Haithem Turki, Xuanchi Ren, Jun Gao, Mike Zheng Shou, Sanja Fidler, Zan Gojcic, Huan Ling セッション：Oral Session 6A: 3D from Single or Multi-View Sensors 本論文では、NeRFや3D Gaussian Splatting（3DGS）による3D再構成の限界を克服するため、単一ステップの拡散モデル「DIFIX」を活用した新手法「DIFIX3D+」を提案しています。DIFIXは、再構成中および推論時に画像のノイズやぼやけ、誤りを除去することで、写実的な新規視点合成を実現します。NeRFおよび3DGSの両方の手法に適用可能で、汎用的な補正ツールとして使えます。FIDスコアを従来のNeRFや3DGSの単体手法と比較し平均で2倍以上改善し、リアルタイム処理も可能です。 出典：Difix3D+: Improving 3D Reconstructions with Single-Step Diffusion ModelsのFigure 3, URL: https://arxiv.org/abs/2503.01774 (2025年6月5日アクセス) DIFIXモデルのアーキテクチャを示しています。劣化した3Dレンダリング画像と参照画像を入力とし、ノイズやぼやけ等を除去した高品質な画像を出力します。構造はU-Netを基盤とし、異なる視点の情報を統合する「Reference Mixing Layer」を備え、複数視点間の整合性を保ちながら画像品質を向上させます。事前学習済みのVAEエンコーダを固定し、LoRAでデコーダを微調整します。 画像と動画の生成 Navigation World Models 著者：Amir Bar, Gaoyue Zhou, Danny Tran, Trevor Darrell, Yann LeCun セッション：Oral Session 4B: Embodied Computer Vision Navigation World Model (NWM)は、過去の観測（過去から現在の一連のフレーム）とナビゲーション行動（平行移動、回転）に基づき未来の視覚情報を予測する、制御可能なビデオ生成モデルです 。Conditional Diffusion Transformer (CDiT) を採用し、標準的なDiTと比較して計算要件を大幅に削減しつつ、10億パラメータまで効率的にスケールする学習を実現しています 。NWMは、既知環境での軌道計画や未知環境において単一の入力画像から軌道を想像する能力を有し 、計画中に動的な制約を組み込むことも可能です。 出典：Navigation World ModelsのFigure 2, URL: https://arxiv.org/abs/2412.03572 (2025年6月5日アクセス) CDiTアーキテクチャは、CDiTブロックを複数層積み重ねた時間的自己回帰型のトランスフォーマーモデルです。各ブロックでは、Multi-Head Self-Attentionにより空間的整合性を確保し、現在フレームのクエリと過去フレームのキー/バリューを結びつけるMulti-Head Cross-Attentionによって時間的整合性を維持します。この二段階の注意機構により、計算効率を保ちながら空間・時間両方で一貫性のある未来のフレームの生成を実現しています。 「マルチモーダル学習」と「ビジョン、言語、推論(Reasoning)」 Molmo and PixMo: Open Weights and Open Data for State-of-the-Art Vision-Language Models 著者：Matt Deitke et al. セッション：Oral Session 1B: Interpretability and Evaluation プロプライエタリな視覚言語モデルに依存せず、完全にオープンな手法で高性能なVLM「Molmo」と、その訓練データ「PixMo」を構築・公開した研究です。PixMoは詳細説明を持つ画像キャプション、自由形式の画像質問応答、ポインティング（２次元座標(x, y)とそこにある物体が対となるデータセット）を含む多様なデータを含み、Molmoは学術ベンチマークや人間評価でClaude 3.5やGeminiを上回る性能を達成しました。 出典：Molmo and PixMo: Open Weights and Open Data for State-of-the-Art Vision-Language ModelsのFigure 2, URL: https://arxiv.org/abs/2409.17146 (2025年6月5日アクセス) 図は、Molmoのアーキテクチャを示しており、視覚エンコーダ（ViT）、コネクタ、トークナイザ、LLMという4つの主要モジュールから構成されています。ViTは画像を複数のクロップに分割し、パッチごとに特徴ベクトルを出力します。コネクタはそれらの特徴ベクトルをアテンションプーリングし、LLMの埋め込み空間に変換します。最終的にLLMが応答を生成します。ポインティング出力では、位置情報をHTMLライクな形式で埋め込み、画像内の対象を明示できます。 Generative Multimodal Pretraining with Discrete Diffusion Timestep Tokens 著者：Kaihang Pan, Wang Lin, Zhongqi Yue, Tenglong Ao, Liyu Jia, Wei Zhao, Juncheng Li, Siliang Tang, Hanwang Zhang セッション：Oral Session 6B: Scene Understanding, Image Editing and Multimodal Learning 画像と言語を扱うAIでは、従来の画像情報の形式がAIにとって直感的に理解しづらく、言語のように扱えない課題がありました。本論文は、AIが画像を生成する途中経過を利用し、文章のように意味がつながる新しい形式の視覚情報（DDT: Discrete Diffusion Timestep token）を開発しました。これによりAIの言語理解力と画像生成力を一つの仕組みで効果的に組み合わせ、高度な画像と言語の処理を実現します。 出典：Generative Multimodal Pretraining with Discrete Diffusion Timestep TokensのFigure 2, URL: https://arxiv.org/abs/2504.14666 (2025年6月5日アクセス) (a)の「Diffusion Timestep Tokenizer」は、画像をエンコーダと複数タイムステップ（アテンション等で特徴を精錬・属性を補完）で処理し、学習済みの代表的な画像パターン集であるコードブックを用いた量子化で再帰的・離散的なDDTを生成します。 (b)では、このDDTとテキストのトークン結合列を、LLaMA等の大規模言語モデル（LLM）が「next-token prediction」で処理し、画像とテキスト間の関連性を学習。この統一的予測機構が、画像理解や双方向生成などマルチモーダル処理の基盤を構築しています。 その他注目論文 Descriptor-In-Pixel : Point-Feature Tracking For Pixel Processor Arrays 著者：Laurie Bose, Jianing Chen, Piotr Dudek セッション：Oral Session 2C: Temporal Modeling and Action Recognition ※本記事を執筆している 2025/6/3 時点で論文が未公開のため、関連情報を記載します。 本論文は、ピクセルプロセッサアレイ（PPA）センサー向けの新しい点特徴検出・追跡手法「Descriptor-In-Pixel」を提案しています。この手法は、すべての計算をセンサー内部のピクセルプロセッサで実行します。特徴記述子を各ピクセルプロセッサに保存し、並列処理で高速な検出と追跡を実現。 SCAMP-7 PPAプロトタイプで3000 FPS以上を達成し、激しい動きにも対応します。これは、点特徴の検出と追跡を完全にインピクセルで実行する初の研究です。 出典：Descriptor-In-Pixel : Point-Feature Tracking for Pixel Processor Arraysのデモ動画, URL: https://lauriebose.github.io/DIP/ (2025年6月5日アクセス) The PanAf-FGBG Dataset: Understanding the Impact of Backgrounds in Wildlife Behaviour Recognition 著者：Otto Brookes, Maksim Kukushkin, Majid Mirmehdi, Colleen Stephens, Paula Dieguez, Thurston C. Hicks, Sorrel Jones, Kevin Lee, Maureen S. McCarthy, Amelia Meier, Emmanuelle Normand, Erin G. Wessling, Roman M. Wittig, Kevin Langergraber, Klaus Zuberbühler, Lukas Boesch, Thomas Schmid, Mimi Arandjelovic, Hjalmar Kühl, Tilo Burghardt セッション：Oral Session 2C: Temporal Modeling and Action Recognition 野生チンパンジーの行動認識における背景情報の影響を研究するためのデータセット「PanAf-FGBG」を紹介しています。本データセットは、同じ位置からカメラトラップ（野生動物の自然の行動を自動撮影する無人のセンサーカメラ）で撮影されたチンパンジーを含む前景映像と、含まない背景映像のペアで構成されています。これにより、背景情報が行動認識モデルの汎化性能に与える影響を定量的に評価できます。結果として、背景情報が動物の行動認識の強力な予測因子であることと、CNNとTransformerのアーキテクチャ間での影響度の違いを明らかにし、データセットの有用さを示しました。 出典：The PanAf-FGBG Dataset: Understanding the Impact of Backgrounds in Wildlife Behaviour RecognitionのFigure 1, URL: https://arxiv.org/abs/2502.21201 (2025年6月5日アクセス) 本研究で提案されたPanAf-FGBGの構成を示しています。チンパンジーを含む前景（FG）映像と、含まない背景（BG）映像のペア5070組で構成されており、アフリカ6か国・389か所のカメラから収集された21時間分の映像が含まれています。実験の結果、映像ペアのうちFGまたはBGのいずれか一方のみで学習したモデルと比較して、それぞれから抽出した特徴量を融合したモデルは、分布外データに対してより高い性能を示すことが確認されました。 UniAP: Unifying Inter- and Intra-Layer Automatic Parallelism by Mixed Integer Quadratic Programming 著者：Hao Lin, Ke Wu, Jie Li, Jun Li, Wu-Jun Li セッション：Oral Session 5B: Learning Systems and Medical Applications 大規模モデルの学習には、複数のマシンやGPUを用いた分散学習が用いられ、大きく層間並列（Inter-layer parallelism）と層内並列（Intra-layer parallelism）の2つのカテゴリに分けられます。既存の自動並列化(AP)手法は、層間並列と層内並列の2つのカテゴリを同時に最適化しないという問題を抱えており、UniAPは分散学習の並列戦略最適化において、これまで個別または階層的に扱われていた層間並列と層内並列を混合整数二次計画法（MIQP: Mixed Integer Quadratic Programming）により統合的に扱うことで、既存手法の限界を超え、より優れたパフォーマンスと効率的な最適化時間を実現した手法です。 出典：UniAP: Unifying Inter- and Intra-Layer Automatic Parallelism by Mixed Integer Quadratic ProgrammingのFigure 2, URL: https://arxiv.org/abs/2307.16375 (2025年6月5日アクセス) 層間並列と層内並列の自動並列化を統合し、これら2つのカテゴリの並列戦略を同時に最適化するために、UniAPはMIQPを用いています。この統合された最適化プロセスをUnified Optimization Process (UOP)と呼んでいます。UOPは、ハードウェアとモデルのプロファイリング結果、計算グラフ、コストモデルから得られた推定コストを基にMIQP問題を定式化し、最適な並列戦略（層の配置や層内戦略の選択）と最小のトレーニング時間（TPI）を探索します。 おわりに 本記事では、CVPR 2025のBest Paper Award候補論文を通じて、コンピュータビジョンとパターン認識分野の最先端の技術動向をご紹介しました。どの論文も大変興味深く、今後のAI研究開発の方向性を示唆するものであったと感じています。 現在、私の所属するAI開発部は10人の多様なバックグラウンドを持つメンバーで構成されており、今回の論文紹介も各メンバーが分担して取り組みました。私たちは最先端の研究成果を積極的に取り入れ、社会に貢献するAIの開発に日々邁進しています。 このような最先端のAI技術開発に情熱を傾け、私たちと共に未来を創造したいとお考えの方、ぜひ弊社の 募集要項 をご覧ください。皆様のエントリーを心よりお待ちしております。
新卒一期生が感じたキャッチアップの壁とその打開策 こんにちは！フロントエンドエンジニアの一氏です。 2023年に新卒一期生として入社し、現在は Safie Viewer （セーフィー ビューアー）のフロントエンド開発を中心に業務に取り組んでおります。 先日、若手エンジニアの課題と乗り越え方というLTに登壇してきました。 【増枠】若手エンジニアの課題と乗り越え方 (2025/04/15 18:40〜) toggle.connpass.com 本稿では、LTで発表した新卒エンジニアとして入社後に直面したキャッチアップの壁、そしてそれをどのように乗り越えてきたのかをご紹介させていただきます。 新卒一期生が感じたキャッチアップの壁とその打開策 新卒エンジニアとして直面した課題：3つの壁 課題克服のための実践と打開策 そのほかやって良かったこと おわりに 新卒エンジニアとして直面した課題：3つの壁 入社後、業務を開始するにあたり、私は主に以下の3つの「壁」に直面しました。 サービスの壁 弊社の提供するクラウド録画サービス「Safie（セーフィー）」は、カメラをインターネットにつないで、スマホ・パソコンから、いつでもどこでも映像を確認することができるサービスです。また、他システムとの連携やAI解析による業務効率化や課題解決も行っています。 映像データの汎用性は非常に高く、小売・飲食・建設といった様々な業界で活用することが可能であり、それがSafieのサービスの強みになっています。しかし、裏を返せば映像データを活用したソリューションを実現するには理解すべき領域が非常に広いとも言えます。また、カメラというハードウェアが存在することで、カメラ自体のハードウェア・ソフトウェアの開発、カメラの販売方法や商流、カメラ特有の専門用語の理解も必要になります。 サービスの全体像、各機能の詳細、そしてそれぞれの業界における活用方法など、キャッチアップすべきドメイン知識の多さに、サービスの理解が最初の大きなハードルとなりました。 技術力の壁 私は新卒一期生として入社したため周りは経験豊富な中途入社のエンジニアのみでした。そうした環境下では、自身の経験や知識の不足を痛感する場面が多くありました。実装方法に迷ったり、既存コードの意図を把握するのに時間を要したりと、技術力における周囲との差を感じ、時に自身の成長速度に不安を感じることもありました。新卒の先輩がいない状況で、どのタイミングで質問をするべきか、適切なコミュニケーションの取り方に悩むこともありました。 オンボーディングの壁 私が入社した際の新卒研修のオンボーディングは以下の流れで行われました。 4~7月：エンジニア共通の研修 基礎知識習得（主にUdemy） チーム開発研修 8月：各チームに配属されてそれぞれオンボーディング チュートリアル 簡単なタスクから開始 新卒一期生として入社したこともあり、当時のオンボーディングは構築段階にありました。エンジニアとしての基礎知識の習得としてUdemyが活用されていましたが、長期間の動画視聴は集中力の維持が難しい側面もありました。また、チーム開発研修やその後のそれぞれのチームへ配属後、トレーナーや先輩社員への質問やレビュー依頼の頻度、タイミングについて手探りな部分があり、コミュニケーションの壁を感じることもありました。さらに、配属後のチームのオンボーディング資料が最新の状態に保たれていない箇所などもありました。 課題克服のための実践と打開策 これらの課題に対し、私は試行錯誤しながら以下の打開策を実行しました。 サービスの壁への打開策：あらゆるドキュメントを読む サービス理解を深めるため、社内に存在するあらゆるドキュメントを読み込むことを徹底しました。サービス紹介資料、詳細な仕様書、ヘルプページはもちろんのこと、Slackでの過去の議論やGithubのリポジトリ、ユーザーヒアリングの議事録に至るまで、関連性のありそうな情報はすべて参照しました。 自身で30分調査しても解決しない不明点については、周囲の詳しい先輩社員に質問することをルールとしました。そして、そこで得られた知識は個人のメモとして整理し、いつでも参照できるようにしました。 なお、古い仕様に関する情報が追いにくい場合もありましたが、その際は素直に担当者に確認することが最も効率的であると感じました。 技術力の壁への打開策：コードリーディングと幅広いタスクへの取り組み 技術力の向上に向け、自身の担当するタスクに関連する既存コードのリーディングに注力しました。実際に稼働しているコードを読むことで、チームのコーディング規約や設計思想を実践的に学び、サービスの理解も同時に深めることができました。 自身の技術的な引き出しを増やすことを意識し、比較的小さな機能追加や改修タスクに積極的に取り組みました。簡単なタスクから着実に成功体験を積み重ねることで自信に繋がり、より複雑な課題に取り組むための基礎力を養うことができたと感じています。複雑な機能も、分解すれば単純な要素の組み合わせであることを意識するようになりました。 オンボーディングの壁への打開策：自分たちで改善 オンボーディングプロセスの改善には、新卒メンバー自身が積極的に関わりました。Udemyでの基礎学習については、必須範囲を絞り込み、早期にチーム開発研修へ移行するフローを提案・実行しました。これにより、実践的な開発に早期に触れる機会を増やし、チーム開発研修中に必要に応じてUdemyでの学習に戻るスタイルを取り入れました。 チーム開発研修においては、レビュー依頼のガイドラインを明確化し、トレーナーが積極的にプルリクエストに関わる体制を構築しました。 また、日々の業務に関する雑談や、なんでも相談できる1on1の時間を設ける、日報に対してコメント返しすることで、質問や相談の心理的なハードルを下げる工夫を行いました。 チーム配属後のオンボーディング資料についても、新しくチームに参加するメンバーが随時更新していく運用を取り入れました。これにより、情報の鮮度を保ち、今後入ってくるメンバーがよりスムーズに立ち上がれるように改善を進めています。 そのほかやって良かったこと 上記の打開策に加え、以下の取り組みもキャッチアップにおいて有効であると感じています。 コーチング コーチングとは対話を通じて相手の能力やモチベーションを引き出し、目標達成を支援するコミュニケーション手法です。 上司との定期的なコーチングセッションを通じて、自身の現状や目指す姿、目標について対話する機会を持ちました。これにより、自分一人では気づけなかった視点を得ることができ、客観的に自身の成長課題や進むべき方向性を認識することができました。 よもやま（カジュアルなコミュニケーション） よもやま話とはとりとめのない話や、決まった話題がない話のことで、私の所属するチームではメンターと何を話しても良い1on1の場をよもやまと呼んでいます。初めは毎日30分、次第に頻度を減らして実施していました。 業務に直接関連しないことでもカジュアルに話せるよもやまのような場や、Gatherを活用したコミュニケーションは非常に有効でした。普段の業務では聞きにくい疑問点を解消したり、新たな気づきを得たりすることができ、なんでも話すことができるという安心感があります。心理的な安全性は、スムーズなキャッチアップにおいて非常に重要であると実感しました。 おわりに 新卒エンジニアとしてのキャリアをスタートするにあたり、サービスの理解、技術力の向上、そしてオンボーディングプロセスの活用といった様々な面で多くの課題に直面しました。しかし、これらの「キャッチアップの壁」は、主体的に学び、実践し、そして周囲と積極的にコミュニケーションを取ることで、一つずつ乗り越えていくことが可能です。 本稿でご紹介した私の経験が、これからエンジニアを目指す方々、現在キャッチアップに励んでいる若手エンジニアの方々のお役に立てれば幸いです。
はじめに こんにちは！セーフィー株式会社でサイバーセキュリティを担当している金原です。 前回、こちらの記事でセーフィーがどのようにセキュリティ戦略を策定しているか、その考え方についてお話しさせていただきました。 engineers.safie.link さて、今回はその続編として、策定した戦略を実行していくために不可欠な 「チームづくり」 について、私たちの考えとこれまでの取り組みをご紹介したいと思います！ はじめに 戦略を実行する「チーム」の重要性 基本的な考え方は「ちゃんとマネジメントする」 マネジメントは「セルフマネジメント」から 「個」から「チーム」へ：チームビルディング アジャイルな仕事の仕方を取り入れる チームを育成し、拡大していく おわりに 戦略を実行する「チーム」の重要性 前回お話ししたサイバーセキュリティ戦略ですが、策定した時点では、まだ多くの 仮説 を含んでいます。 また、脅威の状況やビジネス環境は常に変化するため、戦略も固定的なものではなく、継続的に見直していく必要があります。 そこで、私たちは以下のような、 小さく実行し、 フィードバックを得て、 学びを次に活かす というサイクルを、うまく実行できる、 フィードバック駆動のハイパフォーマンスなチーム になりたいと考えました。（このアプローチが戦略をうまく進めていける鍵になると信じてます） では、どうすればそのようなチームになれるのか？ その問いに答えていきたいと思います。 基本的な考え方は「ちゃんとマネジメントする」 セキュリティ問わず、ハイパフォーマンスなチーム作りに、特別な近道や魔法はありません。 私たちが大切にしている基本的な考え方は、 「ちゃんとマネジメントする」 ということです。 （当たり前のことを主張してすみません。でも大事なんです） マネジメントと聞くと「管理職」というキーワードから「管理すること」と捉えられがちなのですが、ここで言うマネジメントとは、単なる「管理」ではありません。 ドラッカーも言うように、マネジメントとは 「メンバーとチームの力を最大限に活かし、チームとして価値の高い成果を生む」 ための働きかけを指します。 これは、どの業務でも同じですよね。 ということで、まずは正しい理解を身に着ける（体系的な知識を得る）のがよいだろうということで、以下を実施しました。 ＜私たちの取り組み＞ マネジメント勉強会 を実施しました。チーム全員がそろって参加して、「マネジメントとは何か？マネジメントがなぜ重要なのか？」を学び、マネジメントについての目線合わせをしました。 勉強会の様子 具体的には以下の書籍を参考にしたスライドを作成して講義形式で開催しています。 （私自身が、著者の藤田勝利先生のマネジメント講座を受講した際にとても分かりやすく学べたので参考にしました） (出典)藤田勝利,新版-ドラッカー・スクールで学んだ本当のマネジメント,日経BP,URL: https://www.amazon.co.jp/新版-ドラッカー・スクールで学んだ本当のマネジメント-藤田-勝利/dp/4296108832 ,（2025年5月2日アクセス） (出典)藤田勝利,ノルマは逆効果 〜なぜ、あの組織のメンバーは自ら動けるのか〜,太田出版,URL: https://www.amazon.co.jp/ノルマは逆効果-〜なぜ、あの組織のメンバーは自ら動けるのか〜-藤田-勝利/dp/4778316614 ,（2025年5月2日アクセス） ＜チームからのフィードバック＞ マネジメントって苦手意識があったけど、ハードルが下がった。 マネジメントの目的が何かを知ることができてよい学びの機会だった。 マネジメントにあまり魅力を感じてなかったけど、今後必要なスキルだとわかった。 マネジメントは「セルフマネジメント」から マネジメントとは何かを学んだことで、何から始めたらいいか、が分かるようになりました。 チームをマネジメントする前に、まず私たち自身が 「セルフマネジメント」 できているかを見つめ直すことがマネジメントの出発点です。 では、セルフマネジメントとは具体的に何を意識することなのでしょうか？ それは、まず 自分自身を客観的に理解すること から始まります。 自分自身の強みや弱み、仕事の進め方を理解しているか？ 自身のセキュリティ知識・スキルレベルを把握し、常にアップデートする意識を持っているか？ 定期的に 内省 （振り返り）を行い、学びを得られているか？ そのためのツールとして、 1on1ミーティング などを効果的に活用できているか？ 自分という最も身近な資源を理解し、活かすことから全ては始まります。（と、ドラッカーも言っているはずです） 特にセキュリティ分野は変化が激しくストレスも多い仕事であるため、自分自身をモチベートして、継続的な学習意欲を維持することがとても大事だと考えています。 自分自身に向き合うという方法としては、1on1が使えるだろうということで、以下を実施しました。 ＜私たちの取り組み＞ 1on1勉強会 を実施しました。1on1の重要性や具体的な方法について、1on1を実施される側も含めて、こちらもマネジメントと同じくチームで共通理解を作りました。 勉強会で学んだことを、少しずつ1on1に取り入れて、私たちの1on1の型を作っていっています。とくに、セキュリティエンジニアとしてのキャリア形成やスキルアップをどのように進めていくかを対話し、支援していくことが大事になるだろうと思っています。 ＜チームからのフィードバック＞ 前職で1on1を実施していたが、なんとなくやっていた。進め方が分からないので最初から本題に入るとか…。これだと1on1をよい場にはできないんだという気づきを得ることができた。 1on1にも型があって、それをまずは実践して、守破離の流れで自分のものにできれば、今後のキャリアの役に立ちそう。 「個」から「チーム」へ：チームビルディング セルフマネジメントを意識できるメンバーになってきたら、次は 「チーム」として機能するための土台作り 、すなわち チームビルディング です。 （実際は、セルフマネジメントができているかにかかわらず、チーム組成のタイミングで実施するのがおすすめです） 実は、組織体制上の箱として組織を作り、そこに人を集めただけだと、それは単にグループであって、チームとは言えません。チームになるためには、共通の目的、相互理解、期待のすり合わせが必要で、それができて初めてチームになれるのです。 そのため、まずは正しい理解を身に着ける（体系的な知識を得る）のがよいだろうと考え、以下を実施しました。 ＜私たちの取り組み＞ 「ドラッカー風エクササイズ」という手法を使いました。 メンバーそれぞれが「 他のメンバーに期待すること 」や「 自分がチームに貢献できること（強み） 」「 大切にしたい価値観 」などを共有し、相互理解を深めました。 ※ 実際に使ったドラッカー風エクササイズのテンプレート（Miro）。一般的な4つの問い（四方）に真ん中の「個人の夢/目標」を入れているのが工夫ポイントです。人数分作成して、チームで対話しながら共有していきます。 チームビルディングを通じて共有された個性や期待を参考に、チームの「ミッション」や「大切にしたい価値観」を作りました。 チームの大きな方向性は「 セーフィーのサイバーセキュリティ戦略の作り方 」にある通りです。 これを組織の「意図」として捉え、チームのミッションと価値観に落とし込みました。 （記事での紹介は長くなるので割愛します！） ＜チームからのフィードバック＞ 一緒に仕事していても、意外とその人のこと知らないんだって気づいた。こういう機会があると、今後の仕事もちょっとやりやすくなりそう。 期待を伝え合うのはちょっと気恥ずかしいけど、このすり合わせが大事なんだと思った。ちょっとやる気が出たかも。 アジャイルな仕事の仕方を取り入れる さて、チームビルディングをしたぞ！明日から、いいチームワークで仕事ができるぞ！となればいいのですが、そう簡単ではありません。 仕事の仕方を少し工夫する必要があります。 フィードバック駆動のチームになるためのヒントは 「アジャイル」 です。 アジャイルとは何かの説明は本記事では省略しますが、アジャイルを取り入れようとしたときに気を付けないといけないのは、盲目的かつ表面的にプラクティスに従ってしまう 「フレームワークの罠」 です。 そして、この「フレームワークの罠」から逃れる方法は、「①意義のあるものにする」「②自分のものにする」の2つが大事になってきます。 ※ 脅威モデリングナイト#8 （金原登壇資料）より抜粋 「①意義のあるものにする」に関しては、すでにセキュリティ戦略とチームのミッション、価値観という理由付けができているので、ここでは「②自分のものにする」ためのプラクティスを考えます。 具体的には以下のような形で、プラクティスを取り入れました。 ＜私たちの取り組み＞ スクラム を採用しました。（わかりやすい＝自分のものにしやすい） スクラムのインベントの中で、今のチーム状況に合った以下の3つから始めています。 スプリント期間の設定 ：現在は2週間としています。 スプリントの始まりと終わりにイベントの実施 ：スプリントの開始時に「スプリントプランニング」を、終了時に「スプリントレビュー」を実施します。 タスクを可視化してデイリーで認識合わせ ：「カンバン」を利用して日々のタスクの状況をデイリーで共有しています。困っていることはここで可能な限り解消します。 ※ 実際に使っているカンバンです。弊社はNotionを使っており、「 Anthropic プロジェクトプランナー 」というテンプレートをカスタマイズして使ってます。プロジェクトとタスクでうまく整理できる良いテンプレートです。 特に重視しているのが 「スプリントレビュー」 です。 ここでは、2週間のスプリントで得られた成果や学びを、 経営層（正確にはCTO森本）に直接報告・デモンストレーション しています。 これにより、セキュリティに関する課題や進捗状況の透明性を高め、経営層からの理解とサポートを得やすくなると思っています！（そう願っています） なお、お気づきと思いますが、フィードバック駆動と言いながら「ふりかえり」をやっていません。これは現時点で私たちチームの人数が少数なのと、日々のコミュニケーションで常に改善を実施できている（デイリーでフィードバックができている）ことが理由です。 そして、これが完成形ではないので、これから徐々に自分たちの型を作っていきます！ ＜チームからのフィードバック＞ チームでタスクを共有して、2週間でやるとコミットしてるので、メリハリが生まれる。 カンバンで、チームのみんなが何をやっているかわかるので、タスクの調整がしやすくなった。 スプリントレビューで、自分たちのやっていることを把握してもらいやすくなった。 チームを育成し、拡大していく チームとして機能し始めたら、次に取り組むべきはメンバーの 成長支援 と、戦略実行のための チーム拡大 です。 なお、ここまでのチームづくりでは、セキュリティの話題はあまり出てきませんでしたが、ここまで整えてやっとセキュリティの話ができます。（お待たせしました） セキュリティチームの育成と拡大になりますので、サイバーセキュリティにどのようなキャリア（スキルセット）があるのかという全体像を把握した上で、セーフィーのサイバーセキュリティ戦略と個人の意図をうまく整合させて、成長につなげます。 ＜私たちの取り組み＞ SANSの「COOLEST CAREERS IN CYBER」を参考にしました。 (出典)SANS - Discover the Coolest and Most In-Demand Cybersecurity Careers, https://www.sans.org/cybersecurity-careers/20-coolest-cyber-security-careers/ （2025年5月2日アクセス） まずは、私を含めた ”今ここにいる” セキュリティチームのメンバーがそれぞれどのキャリアの意図なのか、それに必要なスキルセットは何かを「1on1」や「チームビルディング」を活用して明らかにして、成長の目標にします。 加えて、先に策定したサイバーセキュリティ戦略から、戦略実行に必要な人員とスキルセットを見定めます。（下の画像はコーポレートセキュリティの例です） コーポレートセキュリティの例 そうすると、現状のチームメンバーでカバーしきれないスキルセットやキャパシティ（リソース）が見えてきます。これが戦略とのギャップになります。 このギャップをベースに採用計画を立てて、今現在、積極採用しております！ ＜チームからのフィードバック＞ 目指すべき場と次のステップの具体的なイメージを持つことができた。 セキュリティ業務の大まかな全体像がつかみやすい。 現状のチームと戦略とのギャップが見えて、どういう強みや経験を持った人を採用したいかが言語化できた。 おわりに セーフィーのサイバーセキュリティ戦略を実行し、より高いレベルの「安心・安全」を実現するためのチームづくりは、まだ始まったばかりです。 今回お話ししたように、 「ちゃんとマネジメントする」ことを全ての基本とし、 そのうえで戦略に基づいた人材の育成と採用を進めること が、その核心にあると考えています。 セルフマネジメントから始め、チームとして機能させ、アジャイルに動き、成果を出していく。このプロセスを通じて、セーフィー全体のセキュリティ文化をより良いものにできるよう私たちセキュリティチームも成長していきたいと思います！ 私たちのこうした取り組みに少しでも共感し、 「セーフィーのセキュリティチームで一緒に仕事がしたい！」 と感じていただけたなら、ぜひ採用情報もご覧いただけると嬉しいです。 open.talentio.com 最後までお読みいただき、誠にありがとうございました。
はじめに こんにちは！ クオリティマネジメントオフィスQCD第2グループ 吉田と申します。 セーフィーでは様々なプロダクトがありますが、主にSafie Viewer for モバイルのQAを担当しております。 今回はモバイルチームのリグレッションテストケース改善見直しについて書かせていただきたいと思います。 先日Safie Viewer for PCの方でもリグレッションテストケースの改善についての記事を公開しましたが、今回はモバイルチームとしての取り組みを共有したいと思います。 Safie Viewer for PCの記事も合わせてご確認ください！ https://engineers.safie.link/entry/regression_test はじめに リグレッションテストとは? モバイルチームの現状 取り組み 現在 今後について リグレッションテストとは? 改めてリグレッションテストについてはJSTQBのシラバス(41p)で下記の様に定義されています。 修正および変更でコードの一部に対して行った変更が、同一コンポーネント、同一システム内の他コンポーネント、または他システムの振る舞いに意図せず影響を及ぼす場合がある。変更には、オペレーティングシステムやデータベース管理システムの新しいバージョンなど、環境の変更も含まれる。そのような意図しない副作用をリグレッションと呼ぶ。 リグレッションテストでは、テストを実行して、そのような意図しない副作用を検出する。 Safie Viewer for モバイルでは、現在月一で定期的にリリースを行っており、1リリースで大小様々な機能を追加、不具合改修を行っております。 リリースを繰り返す中で、悪い影響(意図しない影響)を与えていないか、既存の機能が問題なく動いているかを毎回実施しており、ここが実はすごく重要なテストになっております。 SafieViewer for PCのテックブログでも触れていましたが、毎月リリースをということで機能を追加すれば、それだけ次のリリース以降で確認するリグレッションテストケースに追加されていくことになり、月一のリリースの中で、実は一番時間がかかっているのもリグレッションテストだったりします。 モバイルチームの現状 そんな状態で、どんどんテストケースが追加していくと当然ながらテスト時間も追加していきます。 そうして行く内にどうなるかというと、簡単に言うと「あれ、今まで時間内に終わっていたけどもしかしてテストが終わらない…?でもリリースは迫っている、残業するしかない！！？？」みたいなことがおこり得ることになります。 実際のテストケースですが、私が入社した2022年12月では600ケース程度だったものが、約2年経った2024年10月時点では1300ケース近くと約2倍に増加しておりました。 ※初期からテストケースの修正は重ねてはいるので、粒度は違いますが、それだけ多く追加されているということです。 さらにAndroidとiOSでアプリ同時リリースをしているので単純に2倍の時間がかかります。 リリース 実施項目数 2022年12月 (v3.18.0) 623 2024年5月 (v4.13.0) 903 2024年10月 (v4.18.0) 1353 取り組み さて、どうしようかと考えた時モバイルチームでは下記を取り組みました。 ①自動化テストケースへの置き換え 以前から片手間で推進していた自動化を強制的に、メンバー全員でMagicPodによるリグレッションテストケースの自動化導入をすることで、手動でしかできないテストケース以外は自動化に置き換え、効率化を進めました。 こちらはQCD第1グループの森重さんが中心になって進めてくれたおかげで3割程度が自動化で回せるようになっています!!こちらは森重さんの方でまた新たに記事にしてくれるはず！！ 自動化の理解が浅かったメンバーの育成から開始して結果としてモバイルチーム全体で大きな取り組みになりました！ ②テストケースの優先度の見直し 今までも優先度自体は付与していたのですが、基準をより詳細にすることでチーム内で確認できるように再定義しました。 リリース後に不具合が出たらユーザー影響が高い機能(再生、デバイス設定、データ作成)などは優先度を高(Critical)に、毎回確認する必要がないようなエラー系や、閾値の確認などは優先度は低(Low)にするなど。 再定義することでPJメンバーとも認識の共有もできたと思っています。 また、今回新たに【Medium01】【Medium02】としてローテーションという優先度を設定しました。 これはリリース単位で毎回ではなく、ローテーションして実行するというケースです。 例えばモバイルアプリにはイベントを検知したらプッシュ通知が飛ぶようになっているのですが、このイベントには種類が複数あります。 プッシュ通知が飛ぶという機能の仕組み自体は一つのイベントで確認できるので、複数のイベントを分割することで、1回に確認する量を効率化させる調整をしました。 この様に新たな優先度を設定することでテスト内容を見直し、重要な機能により注力してテストを実行する様に調整をいたしました。 現在 取り組みを始めた後、1リリースに1300近くあったテストケースは900ケース弱くらいまで整理することができました！！ 自動テストを除外すると、現在約700ケース程を手動テストで実施しています。 また、実施にかかる工数自体も削減でき、リソースが逼迫するということもなくなりました。 【Medium01】/【Medium02】などのローテーションのケースに関しても、現状では大きな問題はなく、引き続き追加されるケースについては精査を続けて行きたいと思っています。 リリース 実施項目数 実施工数 2024年10月 (v4.18.0) 1353 18h 2024年12月 (v4.20.0) 897 10h 2025年2月 (v4.22.0) 707 8.4h 今後について 改めてになりますが、本取組はただテストケースが多いから減らしたいということではなく、リグレッションテストは大事なテストだという大前提の元、どこがお客様にとってよりリスクになりうる機能なのかに重点を置き、効率よく品質のいいものを素早く提供したいという軸の見直しとなります。 お客様にとってあまり使われていないような機能の挙動をひたすら叩くよりは、より使われる機能に対して、重点をおいて確認をしていきたい。 また、そのような使われていない機能の確認は自動化に置き換えてそちらで担保をしていくなど、QCDチームも日々研鑽しております。 自動テストについてもメンバー全員の理解力と技術力が向上し、問題解決にかかる時間も短縮されるなど、成果も出てきています。 これからも日々研鑽しながらよりよいテスト活動をしていきたいと思っています。 セーフィーではエンジニアを積極的に募集しています。どのような職種があるのか気になる方はこちらをご覧ください！ safie.co.jp カジュアル面談から受け付けておりますので、気軽に応募いただければと思います！ 皆様のご応募、心よりお待ちしております！ 最後までお読みいただき、ありがとうございました
はじめに セーフィー株式会社 AI開発部 でテックリードを務めます橋本です。 テックリードとしてキャリアを積む中で、避けては通れないテーマの一つが「レバレッジの効いた仕事」です。つまり、自分一人のアウトプットを超えて、チームや組織全体により大きなインパクトを与える働きが求められるようになります。 その中でも、特に重要だと感じているのが「組織力の強化」、つまり チーム開発 です。どれだけ自分が手を動かしても、個人の力には限界があります。しかし、自分が持つ知識やノウハウ、考え方をメンバーに共有し、仕組みとして浸透させることができれば、その効果は現在だけでなく、将来のチームにも大きなレバレッジを生むと考えています。 私の前職は、個人主義が強い研究職の文化に身を置いており、チーム開発や組織に働きかける経験はほとんどありませんでした。実際、チームの成長のために良かれと思って行った発言が、批判的に受け取られ、防衛的な反応を招いてしまったこともありました。結果として、チームに良い影響を与えたいという気持ちとは裏腹に、うまくいかないと感じることがありました。 本記事では、そうした課題感から学び始めた チーム開発やコミュニケーションに関する書籍 を紹介し、読書を通じて得た気づきや学びを紹介したいと思います。 はじめに 読んだ本 「何回説明しても伝わらない」はなぜ起こるのか？ NVC人と人との関係にいのちを吹き込む法 サーチ・インサイド・ユアセルフ ヤフーの１on１ ダイアローグ――対立から共生へ、議論から対話へ 学習する組織――システム思考で未来を創造する おわりに 読んだ本 「何回説明しても伝わらない」はなぜ起こるのか？ 著者: 今井 むつみ 出版社: 日経BP 発売日: 2024/5/9 概要 思考のスキーマについて、分かりやすく解説しています。聞き手は、自分が発した言葉そのものではなく、これまでの経験や価値観を手がかりに「意味を補完・再構成」して受け取ります。これが、何回説明しても伝わらない大きな理由だと述べています。 気づき これまで、聞き手が正しく理解してくれることを想定して、説明力を付けることを意識していました。しかし、本書を通じて、聞き手の頭の中に再構成された情報に注意を向けることが重要だと気付きました。 NVC人と人との関係にいのちを吹き込む法 著者: マーシャル・B・ローゼンバーグ 出版社: 日本経済新聞出版 発売日: 2018/2/17 概要 Non-Violent Communication（NVC、非暴力コミュニケーション）について提案しています。何かを依頼するときや、相手と対立が生じているとき、私たちの内面では「観察」「感情」「ニーズ」「要求」というプロセスが起こっています。自分と相手の内面のプロセスに注意を向けることで、対立を避け相互理解を深められると述べています。 気づき 何か依頼するとき、私たちは、現状のままで依頼が受け入れられないと「開発効率が悪化する」「不具合の原因になる」といった不安（感情）を根底に持っています。今までその感情を伝えることを考えたことはありませんでしたが、本書を通じて重要性に気づきました。 サーチ・インサイド・ユアセルフ 著者: チャディー・メン・タン 出版社: 英治出版 発売日: 2016/5/17 概要 Google のエンジニアの視点で、マインドフルネスとその効果、その能力を高めていく実践法を、科学的な知見に基づき解説しています。特に「マインドフルネスとは、今この瞬間に注意を向ける能力」であることを、エンジニアにも馴染みやすい表現で丁寧に伝えています。 気づき これまで紹介してきた本では「内面に注意する重要性」が強調されていましたが、本書では、その注意力をどう高めるか、具体的な方法が示されており、理解が深まりました。 ヤフーの１on１ 著者: 本間 浩輔 出版社: ダイヤモンド社 発売日: 2025/2/19 概要 ヤフー社が実践してきた1on1ミーティングのノウハウを紹介しています。1on1の目的はメンバーの成長支援であり、沈黙や問いかけによって、メンバー自身の気づきを引き出すことが重視されています。また、コミュニケーションを「意図が伝わり、相手の行動が変わること」と定義している点も特徴的です。 気づき コーチングの重要性は頭では理解していたものの、実践できていないという自覚がありました。1on1の目的や沈黙の価値を改めて認識し、設計を見直したいと感じました。また、伝えたつもりで終わらせず、相手が動ける状態になるまで責任を持つ姿勢の重要性にも気づきました。 ダイアローグ――対立から共生へ、議論から対話へ 著者: デヴィッド・ボーム 出版社: 英治出版 発売日: 2007/10/2 概要 物理学者である著者の経験から生まれた本書では、対話（ダイアローグ）の本質が語られます。ダイアローグとは、個々の意見をぶつけ合うのではなく、集団で意味を紡ぐ参加型思考です。組織が陥りやすい「断片化」（考えや価値観がバラバラな状態）を乗り越え、全体が「コヒーレント」（一貫性を持った状態）になることで、組織の力が本当に発揮されると述べています。 気づき 断片化が進むと、チームのエネルギーが分散し、レバレッジが効かなくなるという点が非常に腑に落ちました。テックリードとして、メンバーが同じ方向を向けるように、意識的に対話の場を作っていきたいと感じました。 学習する組織――システム思考で未来を創造する 著者: ピーター・M・センゲ 出版社: 英治出版 発売日: 2011/6/22 概要 組織が学習するとは、個人や組織が持っている前提や思い込み（スキーマ）を更新することだと定義しています。そのためには、組織内でダイアローグを行い、共通認識を作ることが重要です。また、システム思考を用い、組織の課題がどこにあり、どこにレバレッジポイント（少ない力で大きな変化が起きる場所）があるのかを具体例を交えて解説しています。 気づき これまで読んできた本で語られていた「スキーマ」「対話」「内面への注目」と、組織開発が密接に関係していることを理解できました。特に、システム全体を捉え、どこに働きかければ最大の変化を生むかを考えるレバレッジ思考は、テックリードとして実践していきたい重要な視点です。 おわりに 本記事では、チーム開発やコミュニケーションに関する書籍を通じて、私自身が得た気づきや学びをまとめました。 特に印象的だったのは、チームメンバーとの関係性、対話の質、そして内面への理解といった、一見すると曖昧で目に見えない部分こそが、チームの力を最大化する鍵であるということです。説明が伝わらない、対立が生まれる、チームが同じ方向を向けないといった問題は、単に個人のスキルだけでは解決できない、もっと深い要因があるのだと分かりました。 もし、同じような課題や悩みを感じている方がいれば、今回ご紹介した書籍や学びが少しでも参考になれば幸いです。 最後になりますが、書籍の選定に際し、当社CTOの森本数馬、および鎌倉マインドフルネス・ラボの宍戸幹夫様よりご助言をいただきました。この場を借りて、心より感謝申し上げます。
はじめに セーフィーの髙木 @hitsan です。 今年の4月に新卒3期生が入社しました。セーフィーでは約3週間の全体研修を行い、職種別研修に分かれます。職能別研修である開発本部での新卒エンジニア研修は7月末まで実施し、そのあと各チームに配属という流れです。 新卒3期生のエンジニア研修がスタートしたので研修内容について説明します。 はじめに セーフィーの新卒エンジニア研修 研修の基本的な考え 新卒研修の目的を再定義 活躍するエンジニアって？ Mission Vision Value カリキュラムの紹介 コーディングルール作成 カンファレンス参加 セキュリティハンズオン チーム開発 キックオフの様子 おわりに セーフィーの新卒エンジニア研修 今年は去年と同様、7名の新卒エンジニアが入社しました。 今年の新卒研修は今までのカリキュラムを踏襲しつつ、目的の再定義やいくつかのアップデートを行っています。 研修の基本的な考え 成長機会とサポートをしたうえで、研修の運営そのものは新卒エンジニアが自分達で考えて実行するというスタイルで研修を進めます。 例えば、以下のようなことも新卒エンジニアで考え提案して合意を得るところから研修がスタートします。 進捗報告のやり方 会議体設計 研修のスケジュール決め 新卒研修の目的を再定義 新卒研修の目的は「エンジニアとして活躍できるように成長すること」と定義しています。新卒研修の目的としては一般的だと思いますが、成長できるかどうかを意思決定の基準にする、という意図があります。意思決定の基準を提示する意図は以下のとおりです。 成長につながるなら貪欲にチャレンジすることができる 判断に迷ったときに新卒が立ち返る指標になる 研修中は常に自分たちの成長を意識してもらいます。 活躍するエンジニアって？ エンジニアとして活躍するために今回の研修で身に付けてほしいことは以下の3つです。 プロダクト思考 エンジニアのマインド 基礎スキル さらに分解するとこんな感じです。 プロダクト思考 ユーザー体験 プロダクトマネジメント エンジニアのマインド チームプレイ 学習し続けること 成果をアピール 基礎スキル ソフトウェア ファームウェア セキュリティ 品質マネジメント etc.. セーフィーのエンジニアとして意識してほしいことですが、そもそもエンジニアとして働くために重要な項目をピックアップしました。研修中のカリキュラムもこれを身に付けられるように組んでいます。 実際のカリキュラムはこんな感じです。 プロダクト思考 チーム開発 テクニカルサポート研修 エンジニアのマインド チーム開発 チームビルディング ブログ執筆 カンファレンス参加 基礎スキル チーム開発 Udemy AWSハンズオン セキュリティハンズオン コーディングルール作成 Mission Vision Value 新卒エンジニアのチームビルディングの一環としてチームのMission Vision Valueを今年から策定しました。 Mission エンジニアとして活躍できる状態になる Vision プロダクト思考を体得する Value ユーザー体験を追求する 不確実性と正しく向き合う 研修期間にアップデートしてもらうことを前提にしているため現時点では最低限のMVVしか用意してません。研修が終わった時点でどのようになりたいかを考えて定期的にアップデートしてもらいます。 カリキュラムの紹介 カリキュラムをいくつか紹介します。 コーディングルール作成 去年まではリーダブルコードの要約を課題にしていましたが、今年はこれを読んだうえでどのようなコードを書くか考えてもらいます。 書くことのルールは以下のとおりです。 できること、取り組めそうなことを記載する できない、わからないことは記載しない 研修中アップデートしていく このようにした目的は以下のとおりです。 学んだことをどう生かすか考えてほしい 自身のスキルを客観的に見れるようになってほしい カンファレンス参加 去年もいくつかのカンファレンスに参加してもらいましたが、今年は1件以上の参加とその報告してもらいます。外部からインプットする習慣を身に付けてもらうこととエンジニア文化に触れてもらうことが目的です。 セキュリティハンズオン こちらも今年からはじめたものです。セキュリティエンジニアの金原さんに講師をやってもらい脆弱性体験ハンズオンとリスク評価ワークショップをやってもらいます。金原さんが執筆された記事があるのでよければ こちらの記事 もご参照ください。 チーム開発 毎年やっている課題で研修の大部分を占めるものになります。こちらは例年通り「社内の不を解決するプロダクトの開発」がテーマです。 去年の研修の内容はこちらをご覧ください。 新卒研修の紹介とチーム開発前にやったこと 2024年新卒エンジニア研修-アジャイル開発編 2024年新卒エンジニア研修-isai connectについて 2024年新卒エンジニア研修-isai connect開発のアウトプット_サーバーサイド 2024年新卒エンジニア研修-フロントエンド開発編 2024年新卒エンジニア研修-インフラ構築編 2024年新卒エンジニア研修-isai connect開発のアウトプット_デバイス編 2024年新卒エンジニア研修-新卒研修の成果発表とその後 キックオフの様子 最後に初日の研修キックオフとトレーナー顔合わせの様子をお見せします。 新卒、トレーナーを集めて本記事で説明した研修の概要と目的、期待値を共有しました。以下の画像はキックオフの様子です。 キックオフMTGの様子 研修のキックオフをした後は新卒とトレーナーの顔合わせです。全員で14名いるので3チームに分けて行いました。 トークテーマは以下のとおりです。 最近のささやかな楽しみ 何でセーフィーに入ったの？ 自己紹介を深掘ろう！ 新卒研修って実際どう？ トレーナーとの顔合わせ 顔合わせの後は24卒が定期的にやっている勉強会に参加してもらいました。トレーナーの1年間の成長が感じられていいですね。 勉強会の様子 おわりに セーフィーの新卒エンジニア研修の組み立て方について解説しました。どのような考えで研修をやっているか分かっていただけたのではないでしょうか？ 今後、新卒エンジニアの記事も投稿されます。温かく見守っていただけると幸いです。 25年度新卒研修に関する記事はこちらをご覧ください。 2025年、新卒エンジニア研修はじめました ← 本記事 Notion初学者のためのショートカット活用術：業務効率を上げる第一歩 100人をマネジメントした指揮者が 新卒で挑戦した「不確実性」と向き合うチームビルディング 新卒一年目のエンジニアが感じた、プレ開発で見えたチームの“成長” ゼロから学んだフロントエンド実装 毎日の日報報告をワンボタンで ハッカーの視点を身に付ける！新卒が学んだセキュリティ研修
こんにちは。サーバサイドエンジニアの村田 ( @naofumimurata )です。 この度、Safie API を利用するMCP (Model Context Protocol) サーバである「Safie API MCP Server」を作成・公開しました。 github.com 本記事では使い方などを簡単に紹介したいと思います。 MCPサーバとは Safie API MCP Server の概要 使い方 事前準備 利用例 まとめ MCPサーバとは Model Context Protocol とは、Anthropic社が発表したアプリケーションがLLMにコンテキストを提供する方法を標準化するオープンプロトコルです。 LLMに対してMCPで機能を提供する MCPサーバ を用意することで、LLMから外部APIを呼び出してその結果をLLMに与えて判断させるといったことが可能になります。 MCPを利用できるクライアントとしては、Anthropic社が提供するClaude Desktopをはじめとして ClineやVS Code GitHub Copilot Agentなどでも利用可能です。直近だとOpenAIもMCPのサポートを発表しました。 MCPサーバ実装も既に様々なものが公開されており、多くのクライアントで多くのMCPサーバが利用できる様になってきています。 github.com Safie API MCP Server の概要 Safie API を利用してデバイスの情報取得や操作を行う機能を提供します。 (Safie API リファレンス: https://developers.safie.link/reference/api ) 現時点で提供している機能（Tools）は以下の通りです。 list_devices デバイス一覧を取得します get_device_image 指定されたデバイスから画像を取得します list_device_media 指定されたデバイスで録画されている映像（メディア）の一覧を取得します get_device_location 指定されたデバイスの現在のGPS位置情報を取得します get_device_thumbnail 指定されたデバイスの最新サムネイルを取得します list_device_standard_events 指定されたデバイスの標準イベント情報一覧を取得します 詳しくは README をご参照ください。 使い方 事前準備 Safie APIを利用するにあたり、以下のドキュメント、記事を参考にSafie Developersへのディベロッパー登録とアプリケーションの作成、認証情報（OAuth2 アクセストークンまたはAPIキー）の発行を行なってください。 developers.safie.link engineers.safie.link 認証情報発行後、Claude Desktop等のAIツールに以下の設定を追加することで、利用可能となります。(Python 3.10+, uv が手元にインストールされている必要があります) OAuth2アクセストークンを利用する場合: { "mcpServers": { "Safie API": { "command": "uv", "args": [ "run", "--with", "git+https://git@github.com/SafiePublic/safie-api-mcp-server.git", "safie-api-mcp-server" ], "env": { "ACCESS_TOKEN": <発行したOAuth2アクセストークン> } } } } APIキーを利用する場合: { "mcpServers": { "Safie API": { "command": "uv", "args": [ "run", "--with", "git+https://git@github.com/SafiePublic/safie-api-mcp-server.git", "safie-api-mcp-server" ], "env": { "API_KEY": <発行したAPIキー> } } } } 利用例 それでは、実際に使ってみた例をご紹介しましょう。今回は社内にあるオフィスコンビニの商品棚の状況についてLLMに聞いてみたいと思います。 AIツールはClaude Desktop を利用し、モデルは Claude 3.7 Sonnet を利用しました。 ちゃんとLLMがSafie API MCP Serverを実行して答えを返してくれました。 プロンプトにはあえてデバイスを特定するIDを入れなかったのですが、デバイス一覧取得（list_devices）をまず実行してオフィスコンビニに設置してあるカメラを特定し、その後、対象カメラに対して画像取得（get_device_image）を実行、取得した画像から答えを返してくれました。 まとめ 本記事では、Safie APIを利用するMCPサーバである「Safie API MCP Server」について概要と利用方法について紹介しました。 ぜひ、使ってみてください！ なお、本実装はプレビュー版であり一部の機能のみを試験的に提供しています。 サポート対象外となりますのでご了承の上、お使いください。 セーフィーではエンジニアを積極的に募集しています。どのような職種があるのか気になる方はこちらをご覧ください！ safie.co.jp カジュアル面談から受け付けておりますので、気軽に応募いただければと思います！ 皆様のご応募、心よりお待ちしております！ 最後までお読みいただき、ありがとうございました
はじめに こんにちは！セーフィー株式会社でサイバーセキュリティを担当している金原です。 セーフィーは「映像から未来をつくる」というビジョンのもと、クラウド録画サービスを提供しています。私たちのサービスは、防犯・見守りに留まらず、業務効率化や現場DXなど、様々なシーンで社会の「安心安全」を支えています。 この「安心安全」を実現する上で、サイバーセキュリティは極めて重要な要素です。お客様の大切な映像データを守り、サービスを安定して提供し続けることは、私たちの事業の根幹を成すものです。そして、単に守るだけでなく、セキュリティを競争優位性に繋げていくことも目指しています。 そのために、私たちはセキュリティ戦略を策定し、全社で取り組んでいます。 今回の記事では、私たちがどのようにセキュリティ戦略を考え、構築しているのか、その全体像をご紹介します。この記事が、セーフィーのセキュリティへの取り組みに興味を持ってくださる方や、同じようにセキュリティ戦略の策定に取り組む企業の担当者の方にとって、少しでも参考になれば幸いです。 はじめに なぜセキュリティに「戦略」が必要なのか？ 私たちが考える「戦略」とは？ セーフィーのセキュリティ戦略のコンセプトとゴール 戦略を形にする「打ち手」 戦略を推進する「ストーリー」とは？ 今後の展望と仲間募集 おわりに なぜセキュリティに「戦略」が必要なのか？ まず「セキュリティ対策」と聞くと、ファイアウォールの導入、脆弱性診断、従業員教育など、具体的な施策を思い浮かべる方が多いかもしれません。もちろん、それらは非常に重要です。 しかし、セキュリティの世界は広大で、やるべきことは無数にあります。技術は日々進化し、脅威の手法も巧妙化しています。限られたリソースの中で、場当たり的に対策を進めていては、本当に重要な課題に対処できなかったり、対策の効果が薄れたりする可能性があります。 どこに向かうのか（ゴール）、なぜそこに向かうのか（目的）、そして、どのような道筋で進むのか（計画）。これらを明確にする 「戦略」 がなければ、迷子になってしまいます。 だからこそ、私たちはまず立ち止まり、腰を据えて「セキュリティ戦略」を考えることから始めました。 では、私たちは「戦略」をどのように捉えているのでしょうか？ 私たちが考える「戦略」とは？ 一般的に、戦略とは「目標達成のための中長期的な計画や方針」を指しますが、私たちは楠木建先生の著書『ストーリーとしての競争戦略』の考え方を参考に、戦略を 「人を動かすストーリー」 として捉えています。（事業戦略の本ですが、考え方は様々な戦略に応用できるものです） ストーリーとしての競争戦略 出典：Amazon https://www.amazon.co.jp/ストーリーとしての競争戦略-―優れた戦略の条件-Hitotsubashi-Business-Review/dp/4492532706 （2025年4月9日アクセス） この本では、優れた戦略には、顧客や従業員の心を動かすような「面白いストーリー」が必要だと説かれています。なぜなら、戦略を実行するのは「人」だからです。どれだけ立派な計画も、実行するメンバーが共感し、ワクワクできなければ、絵に描いた餅になってしまいます。 この考え方に基づき、私たちは以下のステップで戦略ストーリーを練り上げました。 徹底的に自分たちに向き合う まずは自分自身に「何を成し遂げたいのか」「どんな状態が理想か」を内省して問いかけ、そのあとじっくり腰を据えてチームメンバーと対話を重ねました。 コンセプト（目的）を磨く 対話を通じて、「これだ！」と確信が持てる戦略の核となるコンセプト（目的）を考え抜きました。 ゴール（競争優位）を設定する コンセプトの先に、どのようなビジネス上の価値（ゴール）を実現したいのかを明確にしました。 ストーリーで繋ぐ コンセプトとゴールを、具体的なアクションプラン（打ち手）を含んだ、誰もが情景を思い描けるような一連のストーリーとして紡ぎました。 セーフィーのセキュリティ戦略のコンセプトとゴール こうして生まれたセーフィーのセキュリティ戦略の コンセプト（目的） は、 「バランスの取れた本当の意味での高セキュリティの実現」 です。 ここで言う「バランス」とは、 「生産性を落とさず、柔軟に現場にセキュリティを適用すること」 を意味します。セキュリティを強化するあまり、開発スピードが落ちたり、従業員の業務が煩雑になったりしては本末転倒です。事業の成長を加速させつつ、セキュリティレベルも高めていく。この両立こそが、私たちが目指す「バランス」です。 そして、このコンセプトが目指す ゴール は以下の2つです。（2つ作っちゃいました） セキュリティを事業戦略上の重要な差別化要素にする セキュリティの専門家でなくてもセキュリティを向上させることができる文化を作る 単に「守る」だけでなく、セキュリティの高さを顧客への提供価値や信頼に繋げ、全従業員が当たり前のようにセキュリティを意識し、実践できる。そんな状態を目指しています。 戦略を形にする「打ち手」 コンセプトとゴールを実現するための具体的な 打ち手（アクションプラン）の中心となるのが、「セーフィー版セキュリティ成熟度モデル」 の構築と運用です。 セーフィー版セキュリティ成熟度モデルの概要図は以下になります。このモデルは、大きく以下の2つの領域に適用されます。（図中のLevelは、サンプル値です） 1. コーポレートセキュリティ: 従業員や社内システム、オフィス環境など、企業全体のセキュリティ。NIST CSF をベースにしています。 2. プロダクトセキュリティ: お客様に提供する セーフィーのサービス自体のセキュリティ。OWASP SAMM をベースにしています。 セキュリティ対策には、NIST CSF や OWASP SAMM など、世界的に参照されている優れたフレームワークが存在します。私たちはこれらのフレームワークを積極的に活用しています。 しかし、これらのモデルをそのまま導入するだけでは、セーフィーのカルチャーやビジネスドメイン、開発プロセスに完全にフィットするとは限りません。そこで、これらの一般的なモデルをベースにしつつ、セーフィーの実情に合わせてカスタマイズ（ セーフィー化 ）し、独自の解釈を加えた「セーフィー版 セキュリティ成熟度モデル」を作成・運用しています。（概要図には、大枠のカテゴリしか記載がありませんが、実際にはカテゴリの中で、何をやるかをカスタマイズしている形になります。今回は説明しません。） さらに、各カテゴリの施策の優先度付けには「The Sliding Scale of Cyber Security」という考え方を導入し、「Architecture（設計思想・基盤）」から段階的に強化していくアプローチを取っています。 各施策の進捗状況は、私たちが定義した 成熟度レベル (Level 0〜4) で可視化し、継続的な改善を促しています。例えば、「Level 1: 方針やルールが文書化されている」状態から、「Level 3: チームで自律的に運用されている」状態へ、そして最終的には「Level 4: 継続的な改善が回っている」状態を目指します。 戦略を推進する「ストーリー」とは？ コンセプト、ゴール、打ち手。これらを繋ぐことで、私たちを突き動かす 「ストーリー」 になります。ストーリーの核心は、先ほど説明した 「セーフィー版セキュリティ成熟度モデル」 と、全社一丸となって、安心安全な未来を作り上げていくという 「組織文化」 です。 セキュリティは、特定の部署や担当者だけのものではありません。 セキュリティはみんなの仕事 です。開発、運用、営業、管理部門など、すべての社員が当事者意識を持ち、それぞれの立場でセキュリティ向上に貢献できる文化を醸成すること。セキュリティを向上しつつも、生産性を維持してお客様に価値を届けていくこと。そのための仕組み（メカニズム）があること。 このような組織文化を踏まえ、コンセプトとゴールを結んだ戦略ストーリーが以下のような形になります。（簡単化のために、抽象度を上げています。本当はもっと細かい打ち手があります） このストーリーに共感し、共に汗を流してくれる仲間がいるからこそ、戦略は前に進みます。今はまだきれいなストーリーにはなっていませんが、戦略自体も定期的に見直すことで徐々に筋のいいストーリーに仕上げていく予定です。 （ストーリーの中の詳細な打ち手や、具体的な取り組み状況については、また別の記事でご紹介できればと思います！） 今後の展望と仲間募集 セーフィーのセキュリティ戦略はまだ始まったばかりです。中期的なロードマップに基づき、コーポレート・プロダクト両面で様々な施策を計画・実行しています。 例えば、 コーポレートセキュリティ: サプライチェーンリスク管理の強化、全社的な脆弱性管理プロセスの確立、ゼロトラストに基づいたアクセス管理の導入など プロダクトセキュリティ: 脅威モデリングに基づくセキュリティ要件の定義、セキュア開発トレーニングの実施、SAST/DAST/ペネトレーションテストの強化など これらの取り組みを加速させ、より高いレベルのセキュリティを実現するためには、新たな仲間の力が必要です。 セーフィーでは、セキュリティエンジニアをはじめ、様々なポジションでエンジニアを積極的に募集しています！ セキュリティへの情熱を持ち、戦略策定から実行まで幅広く携わりたい方 急成長する事業環境の中で、セキュリティの側面から貢献したい方 「映像から未来をつくる」というビジョンに共感し、安心安全な社会の実現に貢献したい方 少しでも興味を持っていただけたら、ぜひ下記の採用ページをご覧ください。カジュアル面談も大歓迎です！ https://open.talentio.com/r/1/c/safie/pages/76312 おわりに 今回は、セーフィーがどのようにセキュリティ戦略を考え、構築しているのか、その一端をご紹介しました。 私たちの取り組みが、セーフィーという会社や、セキュリティという仕事に興味を持つきっかけとなったり、他社のセキュリティ担当者の方々の戦略策定のヒントになったりすれば、これほど嬉しいことはありません。 最後までお読みいただき、ありがとうございました！