サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
世界禁煙デー
engineering.visional.inc
こんにちは、Assured事業部の岩松です。先日、Visionalグループとしてクラウドリスク評価「Assured(アシュアード)」を正式にリリースしました。本記事ではこの新規事業がどのように仮説検証を進めてきたのか、技術観点でどのような取り組みをしてきたのかご紹介します。ここで紹介する技術や仕組みは、新規事業という文脈において「やらなくても良いのではないか」「悪手なのではないか」と感じられるものもあるかもしれません。 Startups are very counterintuitive. ~ Before the Startup 「スタートアップは極めて直感に反する」というY Combinator創業者Paul Grahamの言葉通り、スタートアップもしくは急成長を目指す新規事業においては、一見うまくいかないと判断される反直感的な選択が正しい場合も多いのではないかと考えています。そこで「
以前 オンボーディングプラクティスの紹介記事 を紹介しました。 しかし、その記事を読まれた方の中には「ちょっと内容が綺麗すぎない?本当?」と感じた方もいらっしゃるかと思います! そこで今回の記事では、新入社員が実際にオンボーディングを受けてみて、本当に効果的なプラクティスであったのかを実証・紹介しようと思います! 「ふーん「HRMOS」おもしろそうじゃん」と思ったそこの貴方、ぜひとも カジュアル面談 にどうぞ〜。 君の名は? まずオンボーディングを実際に受けてみた執筆者の背景を紹介します。 社会人歴4年目のソフトウェアエンジニア 2021年ビズリーチにソフトウェアエンジニアとして入社 前職は医療系 IT 企業に所属 Rails や React を主に使っていた 前職とは事業規模や業種、技術スタックも異なるため、完全に無知でジョインしています。 そのような状態でオンボーディングを受けてみまし
アジャイル開発を採用しているチームにおいても、ビジネスの要求によっては「一定規模のフィーチャーセット」を「特定の時期にリリースする」ことを、達成しなければなりません。 そういった要求に対し、挑戦する20代の転職サイト「 キャリトレ 」 の開発チームがどのように立ち向かっているのか、リファインメントの実践例を通してご紹介します。 「キャリトレ」は2022年12月21日をもってサービス終了しました。 予測可能性を求めるビジネスの要求とは 分かりやすい例でいうと「業界の繁忙期に合わせて新機能をリリースしたい」などです。 また、BtoBビジネスの場合、開発チームがフィーチャーセットとリリース時期をある程度担保することができれば、 企業のお客様に対し事前のご案内がしやすくなります。 そのことは、リリース直後からその機能を最大限ご活用していただける、という大きなメリットがあります。 事業部一体となって
Visionalグループでは、2019年より新卒研修のカリキュラムの1つとしてスクラム研修を実施しています。 この研修では、単にスクラムのイベントを一通り体験してもらうことが目的ではなく、実際に新卒入社者でチームを作り開発する中で、スクラムやAgileで重要にしている考え方を体験してもらっています。 本記事では、研修で用いたリポジトリも公開しつつ、どのような考えで研修を行っているのか紹介します。 Visionalにおける新卒研修の全体像とスクラム研修 2021年度の新卒研修は実践課題だけでなく、その前提となるチーム開発やプロダクト組織で働くうえで欠かせない研修を含む、以下8つの研修で構成されています。 Git/GitHub研修 技術者倫理研修 サービス運用/信頼性研修 セキュリティ研修 グローバル研修 テストの考え方研修 スクラム研修 実践課題 これらの新卒研修で大切にしている考え方や大枠
「キャリトレ」では「アーキテクチャファースト」を軸に据えて、Androidリニューアルプロジェクトを進めました。結果的に、プロジェクトの進行がスムーズに終わり、リリース後10ヶ月経った今でもなお、リニューアルをした効果を感じています。この記事では、アーキテクチャファーストの施策を振り返り、現在、どのような効果につながっているのかを紹介します。 「キャリトレ」は2022年12月21日をもってサービス終了しました。 ゼロからの出発となったリニューアルプロジェクト キャリトレ事業部スマートデバイスグループにて、「キャリトレ」Androidアプリの開発を担当しております萩尾と申します。2020年12月、挑戦する20代の転職サイト「キャリトレ」は、スマートフォンアプリをフルリニューアルしました。 「キャリトレ」のリニューアルプロジェクトは、単なるアプリケーションの作り直しにとどまらず、多くの機能追加
Visionalの新卒エンジニアは、入社後の約1ヶ月半、新卒研修を受けます。 この研修の最終プログラムでは、Visionalのものづくりにおいて基礎となる技術、プロダクト開発プロセスを実体験する実践課題があります。 既にその課題を終え数ヶ月経ちますが、この記事ではその実践課題の内容や、実際に受けてみて感じたことなどを新卒社員の目線でご紹介します。 Visionalにおける新卒研修の全体像と実践課題 新卒研修は実践課題だけでなく、その前提となるチーム開発やプロダクト組織で働くうえで欠かせない研修を含む、以下8つの研修で構成されています。 Git/GitHub研修 技術者倫理研修 テストの考え方研修 スクラム研修 サービス運用/信頼性研修 セキュリティ研修 グローバル研修 実践課題 これらのVisionalの新卒研修で大切にしている考え方や大枠については、技術力だけではない、Visionalの
スプリントの失敗は「まったく予見ができなかった問題」が原因になるとは限りません。認識できたはずの問題を認識できなかった、存在は認識していたのに注目しなかった、問題に注目はしたが対策を検討していなかったなど、後から振り返ると「なぜそこでつまづいてしまったんだろう…」と思えるようなことが、スプリントの失敗の原因となることもあります。 この記事ではそのような問題を「予見できたはずの問題」と呼び、それらに「Emoji」で立ち向かうプラクティスを紹介します。 予見できたはずの問題へ対処するための「RPMプロセス」 私たちのチームでは、例えば「着手をしてみたら設計が生煮えだったことが分かり、予定通りにタスクの実装が進められなかったこと」や、「タスク間の依存関係が認識できておらず、不要な待ちが発生してしまったこと」などといった、本来ならプランニングの時点で予見できたはずの問題を適切に扱えなかったことによ
サービス価値向上に、脆弱性診断を活用できていますか? Visionalグループでは、事業とセキュリティの真の「共存」を実現するため、全社横断組織としてセキュリティ室があります。セキュリティ室では、様々な事業部を巻き込み、脆弱性診断を通して事業部に寄り添ったリスクコントロールを実践しています。そして、「事業部の仲間たちが実現したいことに全力で挑戦できる、安心・安全な環境づくり」 を目指しています。 皆さんの職場ではどのように脆弱性診断と関わっていますか? 「監査対応の要件として実施している」「リスクを抑止するための根拠を提供してもらっている」だけでしょうか。 私たちセキュリティ室も、はじめは在り方が定まっておりませんでした。しかし、様々な課題を乗り越え、現在では事業部との適度な抑止関係でスピード感のあるリスクコントロールができるようになりました。 2021年4月22日に上場を果たすまでの約1
ビズリーチ事業部のSREチームは、スクラムを導入して1年が経ち、タスクの可視化と脱属人化を実現しました。 導入にあたって何をしたのか、開発チームとは異なる工夫が必要だったところはどこか、導入後何が変わったのかを振り返ってみました。 ビズリーチ事業部のSREチームについて 「ビズリーチ」を担当していて、SRE(Site Reliability Engineer)としてアプリケーションエンジニアと共にプロダクトの継続的な成長のため信頼性・可用性の向上、自動化、効率化などに取り組んでいます。 なお、チームの構成は以下のようになっています。 開発者: SREチームのメンバー(5人) PO: SREチームのマネージャー スクラムマスター: 社内横断組織に所属している専任のスクラムマスター SREチームが抱えていた課題とスクラムの導入目的 まず、SREチームがスクラムを導入した背景を説明します。 PO
現場主導で始まったHRMOSの開発組織のオンボーディングは、ほぼ毎月、地道に運用と改善を続けてきました。2018年に開始してから3年近くになりますが、エンジニアを対象に始まり他職種のメンバーを巻き込みながら、効率と効果の両面を少しずつ洗練させてきました。この記事では、私たちのオンボーディングを定義や効果を俯瞰しながら紹介し、その中で徐々に確立されてきたプラクティスをご紹介します。 変化の時代に不可欠なオンボーディング オンボーディングとは採用や異動によって組織に加わった人材の早期戦力化のための施策であり、 組織に新しく加わった人材を1日も早く戦力化し、組織全体との調和を図ることを目的とした育成プログラムのことを指します。『機内』や『乗船』という意味を持つon-boardから派生して生まれた造語であり、直訳すると『飛行機や船に乗り込んでいる』という意味です。 〜 BizHint などと定義さ
HRMOSでは顧客満足を最優先し、価値あるソフトウェアを早く継続的に提供するため、スクラムに加え、Site Reliability Engineeringをプロダクト開発に適用し、SLI/SLOを定め、運用しています。また、エラーバジェット枯渇時にどのように行動するのか、その運用ルールも定めています。 私たちと同じようにエラーバジェットを運用する組織において、枯渇後のアクションとしてリリース凍結1を視野に入れようとする場合、プロダクトや関係者に与える影響は大きいため、そのルールの策定や調整に頭を悩ますケースも多いのではないでしょうか。 HRMOSの中でも特に歴史の長いプロダクトであるHRMOS採用では、SREチーム内や関係者との間で議論を重ねてルールを見直してきたため、これからエラーバジェットの運用を開始しようとしている方々の参考になればと思い、現在どういった点を考慮して運用しているかを紹
前回の記事ではHRMOSのDesign Systemの導入背景の紹介をしました。 本日はそのDesign Systemがどのように開発・運用されているのかを紹介したいと思います。 開発体制 Design Systemの開発はデザイナー、エンジニアが1つのチームとして開発を行っています。 開発のポイントとしては以下のとおりです。 デザインタスク、実装タスクなどすべてのDesign Systemのタスクは1つのバックログで管理 隔週に1度、やることの計画、やったことの確認をチーム全員で行う チームメンバーは全員兼務なので、極力MTGを増やさないよう、非同期でのコミュニケーションをメインにしている この体制になった背景として、当初はDesign System開発がデザイナーとエンジニアで分断されていたことにあります。 デザインとエンジニアリングでそれぞれ別のバックログをもち、それぞれ別のサイクル
HRMOSでは複数存在するモジュールの体験を統一するために「Design System(デザインシステム)」の開発を行ってます。 そこで本日は HRMOSにおけるDesign System メリットだけではない、Design Systemのデメリット を中心に紹介をしたいと思います。 Design Systemとは? 『Design System』という本の一節にこう書かれています。 デザインシステムとは、デジタルプロダクトの目的を達成するために首尾一貫したルールで編成された、お互いに関連づけられたパターンとその実践方法です。パターンは繰り返される要素で、これらを組み合わせてインターフェースを作成します。 — Design Systems - アラ・コルマトヴァ HRMOSにおいてのDesign Systemとは、いわゆるUI Kitのようにデザインパターンが羅列されているだけでなく、いつ
新規プロダクトや大きな機能のリリース、大規模リニューアルなど、長い時間かけて行うプロジェクトは少なからず発生します。 みなさんは、そのようなプロジェクトのふりかえりは上手く行えていますか?また、オンラインでのふりかえりはどのように行っていますか?この記事では、長期間のプロジェクトに対するふりかえりの方法を、どのように準備して行なっていったかをご紹介します。 今回のふりかえり会の全体像 今回のふりかえりではmiroを用いて下記の流れで行いました。それぞれのプラクティスの内容については、前編で説明しています。 ふりかえり事前会アジェンダ 参画時期の共有(プラクティス1) 起こったことの共有(プラクティス1) ふりかえり本会アジェンダ 本日のチャレンジ宣言(アイスブレイク) 良かったこと、気になったことを共有(プラクティス1) インタビュー×3(プラクティス2) 課題の狙いを定める(プラクティス
新規プロダクトや大きな機能のリリース、大規模リニューアルなど、長い時間かけて行うプロジェクトは少なからず発生します。 みなさんは、そのようなプロジェクトのふりかえりは上手く行えていますか?また、オンラインでのふりかえりはどのように行っていますか?この記事では、長期間のプロジェクトに対するふりかえりの方法を、どのように準備して行なっていったかをご紹介します。 今回のふりかえり会の全体像 今回のふりかえりではmiroを用いて下記の流れで行いました。それぞれのプラクティスの内容については、本記事で説明します。 ふりかえり事前会アジェンダ 参画時期の共有(プラクティス1) 起こったことの共有(プラクティス1) ふりかえり本会アジェンダ 本日のチャレンジ宣言(アイスブレイク) 良かったこと、気になったことを共有(プラクティス1) インタビュー×3(プラクティス2) 課題の狙いを定める(プラクティス3
この記事では、私たちのチームがスプリントゴールの達成とコード品質の低下を防ぐために行っているプラクティス、「死亡前死因分析」について紹介します。 スクラムチームと計画 変化への適応が強調されるスクラムですが、だからと言って事前の計画をないがしろにすることはできません。 私たちのチームが大切にしているキーワードのひとつに、“Measure twice, cut once” (二度測って、一度で切る)があります。もともとは優れた大工の仕事を指す言葉で、注意深く計画し一度で仕事を済ませる、手戻りのない状況を表現する言い回しです。 私たちにとっても、“Measure twice, cut once” の大切さは大工にとってのそれと変わりません。手戻りはデリバリの速度だけでなく、実装の素直さやコードの端的さにも悪い影響を与えるためです。ソフトウェアのバグが一番現れやすい箇所は「苦労と試行錯誤の末にな
Webサービスを開発する場合、画像配信はtoB/toC問わず必要になることが多いです。人財活用プラットフォームHRMOSの評価管理は2019年にリリースされた機能ですが、データ連携・インフラ整備・セキュリティ強化など、リリースに向けて様々な準備が必要でした。今回はその中から、AWSのサーバーレスを活用して、セキュアに画像を配信する仕組みを構築した時の取り組みをご紹介します。 画像配信を新たに構築した経緯 評価管理をリリースするにあたり、従業員データベースに設定されている顔写真を評価管理に取り込んで、プロフィール画像として利用可能にすることになりました。PoCの段階では、プロフィール画像はユーザーが任意に設定できる画像しかなかったため、画像配信はSNSのプロフィール画像のような公開画像が前提で作られており、以下のような構成でした。 顔写真は個人情報に該当するためセキュアに配信する必要がありま
Visionalグループでは、2013年より新卒エンジニア採用を開始し、これまで約130名の新卒エンジニアが入社しています。毎年様々なバックグラウンドを持った仲間を迎え入れるため、新卒入社研修も毎年バージョンアップしています。 これまでの経験や実績から導き出された、事業会社で活躍できるエンジニアになるために何が必要なのか、2021年4月に行われる研修の企画と併せて紹介します。 グローバル基準に引き上げたVisionalの新卒エンジニア採用 近年、新卒エンジニアの採用基準をグローバル基準に引き上げました。Visionalグループは、テクノロジーとプロダクトの力で社会の課題を解決していく事業を展開していくため、ソフトウェアエンジニアに高い技術力と新たな価値を創造し続ける力を求めています。 グローバル基準採用では、日本国内での採用と海外での採用の間にあった採用基準の差分をなくし、技術知識とともに
Multi-Stage Programming、そして脆弱性レジリエンス × Clean Architecture 〜 ScalaMatsuri2020 登壇者インタビュー 2020年10月17日(土) ~ 18日(日)にかけて開催された、アジア最大級のScalaカンファレンス “ScalaMatsuri 2020”。 Visionalからも2名のエンジニアが登壇をいたしました。 本日は「Dotty ではじめるマルチステージプログラミング入門」というタイトルで登壇した鈴木 健一さんにインタビューを行い、その舞台裏に迫りました。 ──はじめに、自己紹介をお願いします。 鈴木 健一です。脆弱性管理ツールの「yamory」 の開発をしています。 もともと SIer の出身で、主にアプリケーション基盤やアーキテクチャ設計、開発統括/支援等の業務を担当していました。Scalaに関連するものでいうと、
無事アプリをリリースできたとしても、アプリ開発は終わりではありません。 限られた業務時間を本当に取り組むべき課題の解決に充てるためには、非生産的な作業を可能な限り排除する必要があります。 約半年にわたる地道な改善を経て、メンバーの受け入れ体制の整備や非属人化の施策にまで手が回っていなかったiOSアプリ開発チーム(以下、iOSチーム)が主体的に改善活動に取り組むチームへと変化を遂げました。この記事では、iOSチームが変化するきっかけとなった4つの効果的な取り組みをご紹介します。 目次 はじめに リニューアル直後の開発環境の状態 1. オンボーディング体制の整備 オンボーディング資料を作成 環境構築手順を自動化 2. 継続的改善の仕組みを作る 3. レビュー支援の充実 CIワークフローの構築 SwiftLint x Danger スタイルガイドの作成とコードレビュー観点の明文化 4. App
QAチームのテスト設計改善およびテストマネジメント改善の取り組みを、9月16日に主催したD3QA にて発表しました。事前登録者数は500名以上、配信時の同時視聴者数は最大300名以上となりました。 質問も60問ほどいただいたのですが、イベント期間内に全ての質問に答えることができなかったため、3つの記事に分けて質問に回答します。また、当日参加できなかった方にも把握していただけるように、当日の発表内容から抜粋して紹介しつつ、質問に回答していきます。 本記事ではテスト設計改善に関する質問に回答します。 発表概要の紹介 改めましてこんにちは!ビズリーチのQA基盤推進室のブロッコリーです。社内でも社外でも「ブロッコリーさん」と呼ばれています。 私は先日「テスト活動の納得感を持ってテストケースを激減させた話」というタイトルで発表を行いました。 発表スライドは下記となります。 また、当日の配信内容はYo
QAチームのテスト設計改善およびテストマネジメント改善の取り組みを、9月16日に主催したD3QAにて発表しました。事前登録者数は500名以上、配信時の同時視聴者数は最大300名以上となりました。 質問も60問ほどいただいたのですが、イベント期間内に全ての質問に答えることができなかったため、3つの記事に分けて質問に回答します。また、当日参加できなかった方にも把握していただけるように、当日の発表内容から抜粋して紹介しつつ、質問に回答していきます。 本記事ではテストマネジメント改善に関する質問に回答します。 発表概要の紹介 改めましてこんにちは!ビズリーチのQA基盤推進室のブロッコリーです。社内でも社外でも「ブロッコリーさん」と呼ばれています。 私は先日「テスト活動の納得感を持ってテストケースを激減させた話」というタイトルで発表を行いました。 発表スライドは下記となります。 また、当日の配信内容
以降では、このテスト設計改善の取り組みに対する質問に回答していきます。 テスト設計改善についての質問の回答 【質問1】テスト設計にあたって開発ドキュメントの参照はしないのでしょうか。開発ドキュメントがほとんど無い? 開発ドキュメントの参照はします。チケットの内容、開発ドキュメントだけでなく、その内容に対しての疑問点は実際に開発と議論しておきます。開発者との議論はテスト設計に着手する前、テスト観点出しを行う前後の活動です。 【質問2】テストと設計の比率を出していらっしゃいましたが(テストをいっぱいやるようにした)、数える単位は何ですか?人数?時間?その他? 説明資料では文字の大きさの都合上省略した形で書いていますが、比率を出していたのは「(開発の設計ではなく)テスト設計」と「テスト実施」の比率です。また、ここでの比率は感覚値ではありますが、工数比です。 【質問3】改善後の成果物サンプルやアク
SoRの性質が強いBtoBアプリケーションでは、「堅く」作ることを求められる箇所がしばしばあります。 Scalaの型安全性が頼もしく感じられるのは、まさにこのような箇所においてです。 「堅く」作るために、私たちがいま注目しているのが refined と newtype というライブラリです。 この記事では、refinedとnewtypeを使ってScalaの型安全性をさらに引き出すテクニックを紹介します。 Value Class / Tagged Type refined + newtypeの話題に入る前に、これまでにどのようなテクニックが使われてきたかを簡単に振り返りましょう。 ここに、SNSのユーザーアカウントを表現するクラスがあります。 case class User(id: String, email: String, age: Int) val user1 = User("@tod
先日行われました AWS JAPAN SUMMIT ONLINE 2020 にて、「大規模な組織変遷と100以上のAWSアカウントの横断的セキュリティガードレール運用について」のテーマにて、私たちのグループで取り組んでいる全ての AWS に対する横断的な取り組みを ビジョナル CTO 竹内 と ビジョナル CIO 園田 より発表させていただきました。 今回は、その発表内容について、発表の中で伝えきれていない内容などより詳細にお話しさせていただきます。 こんにちは、システム本部 プラットフォーム基盤推進室 ORE (Organizational Reliability Engineering) グループ の 長原 です。 私が在籍するグループでは、 Visional グループの全事業のクラウドや非機能要件等に対して、横断的にエンジニアリングによる課題解決に取り組んでいます。 複数事業・マルチ
先日日本語訳版が発表されたばかりの OWASPアプリケーション検証標準 バージョン4(以下ASVS v4)を用いて、 Webアプリケーションセキュリティの評価をサービスに対して実施した感想などについて記載します。 ASVS v4は非常に包括的なWebアプリケーションセキュリティの評価ガイドラインです。 それこそ「エンジニア研修でまず最初に読もう!」と推進したくなるほど多角的に記載がされています。 どのぐらい包括的であるかについてですが、開発体制・ログ・認証・ログインフォームの設計・総当たりに対するアカウントロックの時間・GraphQLにおけるセキュリティなど、とにかく盛りだくさんな記載がされています。 すべてのエンジニアにとって必読の ASVS v4 こんにちは、佐分基泰と申します。 16年の新卒として入社し、サーバサイド -> 脆弱性診断士を経て、 現在はOSS Libraryセキュリテ
出典:厚生労働省ホームページ https://www.mhlw.go.jp/toukei/saikin/hw/k-tyosa/k-tyosa09/2-2.html より、図8「所得金額階級別にみた世帯数の相対度数分布」 今回の論文では、これらの3点全てに対処するアプローチとして、問題を順序回帰として定式化 + 補間曲線を用いて連続値を回復というアプローチを提案しました。 順序回帰による定式化 以下では、レジュメ情報は\(X\)という形でスパースな\(D\)次元のベクトルにまとめられており、それらから\(K\)(今回は\(K=10\))クラスの年収区分値\(c\)を推定する、という問題を考えます。まずは問題を順序ロジット/順序プロビット回帰として定式化します。若干マイナーなテクニックなのでおさらいをしたいと思います。 冒頭で申し上げた通り、ビズリーチの年収データは「750万円~1000万円」
こんにちは! ビズリーチのAI室でデータサイエンティストとして働いている dimensional_homegoer(異次元の帰宅者)です。この二つ名は大学院時代に隣のイケメンが付けてくれました。 みなさんはAI室というとどんな業務を想定されますか?今はディープラーニング全盛の時代ですし、ビズリーチは大量の自然言語情報を持っていることもあるので、ディープラーニングで自然言語処理とか如何にもやってそう、といったイメージを持たれているかもしれません(僕も入社前はそうでした)。 実際、過去記事で少し紹介された職務内容からの給与推定のように、教師データが揃っている比較的綺麗な予測タスクの際には、そういった王道的なアプローチもとります。 しかし、ビズリーチは大きくなったとは言っても、まだまだ様々な新規事業が立ち上がり続けている会社でもあります。そういった領域では、まだ活用できるデータが揃っていないこと
こんにちは、BizReach で DBRE チームをやらせてもらっている あわっちです。 今回は DBRE としてデータマイグレーションをサポートした際のサービスとの関わり方と手法について、令和最初の Tech Blog として紹介します。 DBRE というよりも、 DBA という要素が強いかもしれませんが、サービスサポートも私たちの重要な役割の1つです。 前回のDBRE(Database Reliability Engineering) の活動 〜 Backup Platform 編 〜とは少し違って泥臭いオペレーションのお話になりますが、お付き合いいただければと思います。 ビズリーチサービス Restart Project Slow Query 撲滅に向けて ビズリーチサービスはサービス開始から10年が経過しましたが、データの肥大化による Slow Query の増加が問題になったり、
次のページ
このページを最初にブックマークしてみませんか?
『engineering.visional.inc』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く