Assured Engineering
募集職種一覧
募集職種一覧

Assured Engineering

Assured事業概要については👉こちら
 

チーム

Assuredのエンジニアリングチームは、
常に「事業が成長するか、より成功に向かえるか」ということに重きを置き、
技術だけでなくビジネスや組織など、事業を取り巻くもの全てに関心を持った上で、
最適な実現方法を考えるような、オープンなチームと今後の組織づくりを目指しています。

メンバー

Product Manager
鈴木 和幸
2013年、株式会社リクルートホールディングスに入社後、新規事業のプロダクト開発や事業開発に従事。2017年より株式会社リクルートマーケティングパートナーズ子会社のQuipperに転籍、EMとして「スタディサプリ」BtoB事業のプロダクト開発・エンジニアリングチームの組織開発を担当。2020年よりAssuredに参画
Software Engineer
岩松 竜也
2015年、株式会社ビズリーチに入社後、バックエンドエンジニアとしてHRMOS採用の開発に従事。プロダクトローンチからARR10億円規模に至るまでの主要な機能開発および改善、運用に携わる。2017年より新卒エンジニア採用のリクルーターも兼任。2020年よりAssuredに参画
Software Engineer
Huang Oliver
2015年、株式会社サイバーエージェントに入社。AbemaTV, AmebaOwndの新規事業の開発に参画。その後、AIスタートアップ、 株式会社ABEJAに転職。開発、企画、営業、パートナー開拓、海外拠点と調整の事業部立ち上げを経験。2020年よりAssuredに参画
Software Engineer
内山 陽介
2012年、株式会社サイバーエージェントに入社後、グループ会社2社に在籍。モバイル向けSaaSの開発全般、プリセールス、テクニカルサポートを担当。その後、アマゾンウェブサービスジャパン合同会社にてソリューションアーキテクトとして、クラウド導入支援や技術支援、を担当。2022年よりAssuredに参画
 

技術スタック

技術選定

フロントエンドの技術選定の振り返り（2022年版） - Assured Tech Blog
プロダクトマネージャーの鈴木（ @kechol ）です。PMと言いつつフロントエンドを書いたりもしています。 前回の記事で バックエンドとフロントエンドの構成についてご紹介しました が、選定の理由等まで深堀りできなかったため、今回はフロントエンドの構成についてもう少し詳しく、これまでの技術選定の振り返りも兼ねてご紹介したいと思います。 「Assured」の開発が始まったのは2020年8月頃なので、その頃からの変化を感じながらお読みいただければ幸いです。 新規事業として過去の負債がないまっさらな状態から開発をスタートしている 開発するアプリケーションは Single Page Application の構成である 言語は TypeScript、 フレームワーク は React を利用しています。 現代のフロントエンド開発において、型の恩恵を受けつつより安全に開発が可能な TypeScript をあえて使用しないことは考えにくいと思います。また、React は現在でも最も広く使われているフロントエンド フレームワーク の一つであり、安定した選択肢だと思います。 選定当時は create-react-app で作成し、その後も eject せずに利用していました。 選定した当時はまだ Next.js がそこまで広く普及しておらず、 SSR（Server Side Rendering）するならNext.js、 CSR（Client Side Rendering）なら create-react-app で良いのでは、くらいの風潮だったように思います。我々のアプリケーションは SSR が不要な類のものであったこともあり、当時はよりシンプルな選択をしたつもりでした。 それから2年が経ち、状況は大きく変わったように見えます。Next.js は ISR（Incremental Static Regeneration） という概念の発明から始まり、直近でも Layouts
https://tech.assured.jp/entry/2022/07/11/120000

働き方

Assuredでのチーム開発 - Assured Tech Blog
プロダクトマネージャーの鈴木 @kechol です。今日は「Assured」でのチーム開発の様子をお伝えしたいと思います。 「Assured」の開発チームは小規模な1チームです。PM1名（私）、エンジニア4名（うち業務委託1名）、デザイナー1名というチーム構成となっています。また、これ以外に、副業で開発を手伝ってくださっているメンバーが数人います。 「Assured」では現在（2022年5月）、基本的に週3リモートワークという形で仕事をしていますが、業務委託や副業のメンバーはフルリモートのため、基本的にミーティングはオンラインを前提として行っています。最近、会社から高性能イヤホンの Shokz が配布されたのですが、これを利用し出社しながらも全員が自席からミーティングに出席するくらいにはオンラインでの進行が当たり前になっています。 「Assured」では二週間スプリントのゆるい スクラム を実施しています。二週間ごとに Planning、Review、Retrospective を実施しています。Sprint Planning は開発チームで行い、Sprint Review には営業メンバーやCSメンバーも含めたほぼ全員が参加しています。 「ゆるい」と書いたのは、現状「Assured」では Sprint Backlog となる開発アイテム（チケット/Issue）の厳密な見積もりを行っていないからです。開発チームのベロシティについては各 Sprint で消化した Issue 数を記録し、振り返ることとしています。また、Daily Scrum や Refinement といった日々の進捗確認やタスクの再調整は週1-2回実施する形で収まっています。今のところこれくらいの スクラム運用でも開発はうまく回っていると思います。チームとしても会話した上で、そうした MTG や運用の厳密さよりも、各々が自律的に開発タスクを進めコードを書く時間を捻出することに重きを置いた働き方をしています。 実際の開発タスクは、 GitHub Projects (beta) を利用して管理しています。 GitHub を利用しているのは、実際のコード/commit と Issue が双方向にリンクされ、後からその変更のコンテキストを追いやすいからです。普段は Sprint 内の開発ステータスをカンバン上で閲覧することが多いです。 Projects (beta) では、レイアウトをテーブルとボードで切り替えたり、Issue に イテレーションや マイルストーンを設定したりできます。現在は見積もりをしていないと前述しましたが、見積もりポイントをIssueごとに入力することも可能です。まだ beta
https://tech.assured.jp/entry/2022/06/13/092000

登壇資料

 
 

インタビュー記事

 

Tech Blog

⏩ Assured Tech Blog　随時更新しております！　
先日リリースの新機能「ウェブ評価」を自分たちで使ってみた - Assured Tech Blog
こんにちは、「Assured」でプロダクトマネージャーをしている鈴木です。 去る7月13日に 「ウェブ評価」という機能をリリースした ので、今日はその機能のご紹介とAssured自身での活用の様子をお届けしたいと思います。 「ウェブ評価」機能は、 クラウドサービスの技術的なセキュリティ対策状況を評価する機能です。実際にアプリケーションにアクセスした結果に基づくHTTPヘッダの情報や DNS の設定情報などからセキュリティの対策状況を推定し評価します。 私たちはこの機能を、 クラウドサービスをラーメン屋に例えて「ラーメン屋を、お店に入らずに門構えや外から見た行列、口コミから評価するような機能」と表現することがあります。本当に美味しいラーメン屋かはラーメンを食べてみるまでわかりませんが、それが良さそうなお店かどうかは外からでもわかることが多い、ということです。実際我々も、その クラウド サービスにログインして使うことなく、インターネットに公開された情報を収集し可視化することでその安全性を推定し、評価レポートを生成しています。 せっかくなので「Assured」自身のウェブ評価を確認し、実際にセキュリティ対策状況を改善してみたいと思います。いくつかあるカテゴリの中から、今回は「HTTPヘッダ」と「メール」の項目を見てみます。 HTTPヘッダの評価結果は以下のようになりました。主にセキュリティヘッダと呼ばれるような、 XSSやクリックジャッキング等の攻撃を防止するためのヘッダ情報を確認しています。これらのHTTPヘッダの設定値については、 OWASPからもガイダンス等が公開 されています。 ここでは 「Feature-Policy」 と 「Content-Type with character set」がうまく設定されていない様子が伺えます。特に「Content-Type with character set」は IPA の 安全なウェブサイトの作り方テキストでも XSS対策として取り上げられており、正しく設定したほうがよさそうです。「Feature-Policy」については、「 実験的な機能であり Permissions-Policy に改名されている 」と MDN にも記載がありますので、「Permission-Policy」が設定されていれば問題ないでしょう。 他に、個人的な推しポイントで言えば Content-Security-Policy (CSP) が設定されていることでしょうか。CSPを安全な設定値で設定すると、 XSS等により発生する意図しない（悪意ある）外部 スクリプト・インライン スクリプトの実行を阻止することができます。一方で、外部サービスの APIや SDK などを利用している場合にはそれを明示的に許可しないとうまく動作しなくなってしまうこともあるため、セキュリティ対策として強力な反面、設定がしづらいものの一つです。「Assured」ではサービス開始当初からこのCSPを利用してサービスのセキュリティを高めています。 メールのなりすまし対策の項目についても見てみたいと思います。 代表的な送信元 ドメインの認証技術である「 SPF（Sender Policy Framework）」はきちんと設定できていそうです。メールの送信 ドメイン・サーバが ブラックリストに登録されているかを判定する「Blocklist」についても問題ないという判定なので、自身の ドメイン からメールを送信する際に迷惑メールと判定されてしまう可能性は低そうです。 一方、「 DMARC（Domain-based Message Authentication, Reporting, and Conformance）」については設定ができていませんでした。DMARCは SPFや DKIMを利用した認証結果の取り扱いやレポート先を指定できる仕様です。認証の結果、なりすましと見なされるメールを不審メールとして扱うように設定することで、なりすましメールによる詐欺行為等を防止する効果がありますし、認証結果のレポート受け取ることで、自身の管理する ドメイン がなりすましの疑いのあるメールに利用されていないかを把握することができます。 それでは、ウェブ評価で可視化された適切でない設定値を修正し、「Assured」のセキュリティ対策状況を改善したいと思います。 実際に「Assured」の Content-Type レスポンスヘッダを確認してみると、以下のようになっており、確かに charset は指定されていませんでした。 $ curl -sI https://c.assured.jp | grep ...
https://tech.assured.jp/entry/2022/08/02/120000
Google CloudのカスタマーエンジニアによるSRE勉強会参加レポート - Assured Tech Blog
こんにちは、 「Assured」でソフトウェア・エンジニアと翻訳をしている オリバーです。コロナで増えた体重がなかなか減らないこの頃です。今回は、 Google CloudのカスタマーエンジニアによるSRE勉強会に参加してきました。スタートアップフェーズにある「Assured」でも活用できそうな学びが多数あり、個人的にはとても嬉しい機会だったのでレポートにしました。 今回のSRE勉強会は、 Google Cloud が開催する Site Reliability Engineering の入門的なイベントです。Visional グループ各事業部の開発チームから参加者を募り、クローズドなイベントとして開催いただきました。内容としてはSRE の基本的な考え方と Google における SRE の取り組みについて解説していただくプレゼンテーションを中心とした、2時間半のプログラムでした。 当日は、弊社から30人弱が参加し、 渋谷ストリームの Google オフィス入り口を埋めました。 渋谷ストリームオフィス前 SRE (Site Reliability Engineering) とは、その言葉の通りシステムの信頼性に重きをおいたシステム運用におけるアプローチです。当日のセッションでは、まず始めに SRE における「信頼性」とはなにか、どういうスタンスでエンジニアリングに望むべきかを説明いただきました。 原則1. いかなるシステムにおいて最も重要な機能は、信頼性である 「すごく魅力的な写真が取れるけど画質が安定しないカメラ」と「普通の写真だけど安定して撮れるカメラ」、どちらをユーザーが欲しがるか。ちゃんとこの瞬間を残せるものを選ぶ人も多いはずです。このように、信頼性は機能と比べても重要なものである、ということです。 原則2. 監視が信頼性を決めるのではない。ユーザーが決めるのだ サーバーが稼働していて、監視システムでもすべてがグリーンになっている。それでもユーザーがサービスを利用できない状態であれば、それは正しく信頼できるシステムとはいえない、ということです。 原則3.
https://tech.assured.jp/entry/2022/07/26/111652
 

採用情報

 
📎
まずは気軽にお話ししませんか？ 少しでもご興味持っていただけましたら、ぜひ一度カジュアルにお話ししましょう。 👉お申し込みはこちら
 
 
 
 
 
©︎ 2022 Assured, Inc.