ブックマーク / engineering.visional.inc (27)

  • ログ基盤をEFKスタックからDatadog Logsに安全に移行する工夫と効果

    はじめに 採用管理システム「HRMOS採用」は、企業の採用活動の効率化や採用データの可視化・分析により、採用決定数の向上につなげることができるクラウドサービスです。 この度、HRMOS採用のSREチームでは、技術負債解消のためにログ運用基盤のDatadog Logsへの移行を行いました。その取り組み内容を紹介します。 計画以前のログ基盤構成と課題 サービス開始以降、ログの運用管理はEFKスタック1で構築された基盤を利用していました。サービスが成長にするにつれログ増加などの環境変化も伴い、時間経過とともに様々な課題が生まれてきました。 なお、トラフィックの規模感としては数百万件/日(平日)、数十億件/月ほどログ件数があります。 移行以前のログ基盤の構成イメージを以下に示します。 課題1 インフラの運用負荷が高い OpenSearch の運用負荷 Amazon OpenSearch Servi

    ログ基盤をEFKスタックからDatadog Logsに安全に移行する工夫と効果
    toshikish
    toshikish 2024/07/31
  • 不確実なスパイクを確実にDONEする試み in スクラム

    スパイクしなければ開発計画が不確実なものになる、しかしそのスパイクがいつ完了するのかわからない、そのような経験はないでしょうか。スクラムでは、ソフトウェア開発の不確実性を乗り越えるためにスパイクを実施しますが、スパイクそのものの不確実性は残ったままです。スパイクとは不確実なものを早期に確実なものに変えるための手法であり、不確実性をはじめからなかったことにできる魔法のアイテムではないからです。 私は HRMOSプロダクト部で人財活用システム「HRMOSタレントマネジメント」のプロダクト開発をしているエンジニアの Suzaking です。私たちのチームでは、未経験の技術要素を使用し、1スプリントで完結せず完成までに数ヶ月を要する機能を開発した際に、スパイクの不確実性という課題に直面しました。 この記事では、私たちのチームがスパイクそのものの不確実性にどのように向き合い、どうやって乗り越えたの

    不確実なスパイクを確実にDONEする試み in スクラム
    toshikish
    toshikish 2024/05/24
  • ゼロから始める社内セキュリティ留学 制度づくりの工夫と参加者の声

    セキュリティ人材の不足が社会的な問題になっているのは皆さんも耳にしたことがあるのではないでしょうか。日は3年連続で1組織あたりのサイバー攻撃が世界一の状況にありながら、欧米と比べ国家的な支援制度・法制度が乏しく、せっかくの人材も海外へ流出し、国内の少ない人材のパイを奪い合っているのが現状です。 Visionalグループでは、全社横断組織としてセキュリティ室があります。今回はそんな社会課題の解決と、Visionalグループが目指す事業とセキュリティの真の「共存」への1つの解決案として、セキュリティ室が実施する「サイバーセキュリティ社内留学制度」をご紹介できればと存じます。一方通行の文章とならないよう、実際に参加された留学当事者にも忌憚無く語っていただきました。皆様の組織のセキュリティ施策のご参考になれば幸いです。 まずは自己紹介です。私、佐藤はCEH (Certified Ethical

    ゼロから始める社内セキュリティ留学 制度づくりの工夫と参加者の声
    toshikish
    toshikish 2024/03/21
  • 2023年 新卒研修② エンジニア・デザイナーが合同でモノづくりを学ぶ テスト駆動開発(TDD)編

    Visionalグループ 株式会社ビズリーチでは、2023年4月に入社した新卒プロダクト職(エンジニア/デザイナー)を対象とした新卒研修を約3ヶ月の間実施しました。最初の約1ヶ月間はビジネス職と合同で顧客志向を中心に学び、その後はプロダクト職としてモノづくりのプロセスや品質の基礎を学びました。 研修を通して得た学びや変化について、受講した社員が3回にわたりご紹介します。 記事では、テスト駆動開発(TDD)の日での第一人者として知られる和田卓人(@t_wada)さんを講師としてお招きし、品質の大切さを学んだ「TDDワークショップ」について、プロダクト職(エンジニア)の渋谷がお伝えします。 TDDワークショップの概要 ワークショップの構成 TDDとはプログラム実装前にテストコードを書き、そのテストに適合するようにコードを実装する開発手法です。今回のTDDワークショップでは、@t_wadaさ

    2023年 新卒研修② エンジニア・デザイナーが合同でモノづくりを学ぶ テスト駆動開発(TDD)編
    toshikish
    toshikish 2023/08/31
  • BizDevOpsを円滑にする品質改善開発プロセスモデル(実践編)

    「品質」は重要だと言われることは多いですが、「品質とは何か?」「品質を確保する/向上させていくために何をすれば良いのか分からない」ということは多いのではないでしょうか? 会社の組織規模が大きくなると、それに伴い新たに問題が発生することもあります。 「品質を確保する/向上する」方法については状況によるところが多く、完璧な正解はないと思っています。 株式会社ビズリーチの品質改善グループでは、プロダクト開発の品質をより良くするためのプロセス改善活動を行っており、BizDevOpsを円滑にする品質改善開発プロセスモデルを定義しました。この記事では、プロセスモデルを定義するための株式会社ビズリーチの状況を踏まえた私たちの考え方や、定義したプロセスモデルの実践について、「コンセプト編」と「実践編」に分けて紹介します。 記事は後編にあたる実践編になります。まだコンセプト編をご覧になっていない方は前編記

    BizDevOpsを円滑にする品質改善開発プロセスモデル(実践編)
    toshikish
    toshikish 2023/08/01
  • BizDevOpsを円滑にする品質改善開発プロセスモデル(コンセプト編)

    「品質」は重要だと言われることは多いですが、「品質とは何か?」「品質を確保する/向上させていくために何をすれば良いのか分からない」ということは多いのではないでしょうか? 会社の組織規模が大きくなると、それに伴い新たに問題が発生することもあります。 「品質を確保する/向上する」方法については状況によるところが多く、完璧な正解はないと思っています。 株式会社ビズリーチの品質改善グループでは、プロダクト開発の品質をより良くするためのプロセス改善活動を行っており、BizDevOpsを円滑にする品質改善開発プロセスモデルを定義しました。 この記事では、プロセスモデルを定義するための株式会社ビズリーチの状況を踏まえた私たちの考え方や、定義したプロセスモデルの実践について、「コンセプト編」と「実践編」に分けて紹介します。 記事は前編にあたるコンセプト編になります。 品質改善グループについて Visio

    BizDevOpsを円滑にする品質改善開発プロセスモデル(コンセプト編)
    toshikish
    toshikish 2023/07/31
  • 100万ユーザーをログアウトさせずに新認証基盤に移行した話

    即戦力人材と企業をつなぐ転職サイト「ビズリーチ」は2009年にサービスを開始し、スカウト可能会員数は190万人以上(2023年1月末時点)のユーザーにご利用いただくサービスに成長しました。 今回、その「ビズリーチ」の認証基盤としてIDaaS(Identity as a Service)のOkta Customer Identity Cloud(Powered by Auth0)(以下Auth0という)の導入を行いました。 記事では認証基盤を刷新するに至った背景とAuth0を用いて100万を超えるユーザーをログアウトさせることなく移行した方法についてご紹介いたします。 前提 記事で得られる情報 記事を読むことで以下のような情報を得ることができます。 IDaaSを選ぶ理由 IDaaSを用いて認証・認可を運用中のプロダクトに組み込んだ事例 運用中のプロダクトに組み込む際に発生しうる課題と対

    100万ユーザーをログアウトさせずに新認証基盤に移行した話
    toshikish
    toshikish 2023/05/23
  • エンジニアの枠を囚われないプロダクト開発 - 事業づくりに求められる「越境」をするには

    私は「大きな社会の課題解決に挑む会社であること」、「不確実な状況下で事業づくりにチャレンジができること」に惹かれて新卒でVisionalに入社してから、約3年半新規事業でソフトウェアエンジニア兼プロダクトマネージャーとして手探りながらも事業開発に関わってきました。記事では、その経験を元に、エンジニアから見たプロダクト開発における越境についてご紹介します。 これまでプロダクト開発を進める中で、事業の解決すべき課題にフォーカスするためには特定の役割のみに閉じているカタチでは実現できないと感じる場面が多くありました。世の中に価値あるプロダクトを提供するために、職種や立場にとらわれず、個々がオーナーシップを持って役割を染み出しながら、事業開発に向き合うということをここでは「越境」としています。 ここからは、私が「BizHint」で実際に行った「メールマガジン配信」における制作改善業務の具体的な体

    エンジニアの枠を囚われないプロダクト開発 - 事業づくりに求められる「越境」をするには
    toshikish
    toshikish 2023/02/14
  • ソフトウェアデリバリーパフォーマンスに関する考察(後編)- Four Keysと向き合うとはどういうことか

    去る2022年9月29日(アメリカ時間)にState of DevOps 2022が公表されました。 State of DevOpsとは、年に1回DORA(Google Cloud内のチーム)が発表しているソフトウェアのデリバリーパフォーマンスに関する調査結果レポートです。State of DevOpsでは、ソフトウェアデリバリーパフォーマンスの指標でもあるFour Keysや、Four Keysの改善効果が高いとされるケイパビリティについての詳細な内容が記載されています。 株式会社ビズリーチでは、日々プロセスをより良くするための活動を行っており、今回State of DevOps 2022の発表に伴い私が所属するプロセス改善部内でState of DevOps 2022に関する調査と議論を行いました。今回はプロセス改善部でまとめた内容を前編と後編の2部に分けて紹介したいと思います。 後編

    ソフトウェアデリバリーパフォーマンスに関する考察(後編)- Four Keysと向き合うとはどういうことか
    toshikish
    toshikish 2022/12/23
  • ソフトウェアデリバリーパフォーマンスに関する考察(前編) - State of DevOps 2022では何が示されたのか

    ソフトウェアデリバリーパフォーマンスに関する考察(前編) - State of DevOps 2022では何が示されたのか 去る2022年9月29日(アメリカ時間)にState of DevOps 2022が公表されました。 State of DevOpsとは、年に1回DORA(Google Cloud内のチーム)が発表しているソフトウェアのデリバリーパフォーマンスに関する調査結果レポートです。State of DevOpsでは、ソフトウェアデリバリーパフォーマンスの指標でもあるFour Keysや、Four Keysの改善効果が高いとされるケイパビリティについての詳細な内容が記載されています。 株式会社ビズリーチでは、日々プロダクト開発のプロセスをより良くするための活動を行っています。今回State of DevOps 2022の発表に伴い私が所属するプロセス改善部内でState of

    ソフトウェアデリバリーパフォーマンスに関する考察(前編) - State of DevOps 2022では何が示されたのか
    toshikish
    toshikish 2022/12/22
  • フロントエンドを改善し続けてきた道を振り返る 〜 ビズリーチ・キャンパス

    「ビズリーチ・キャンパス」は2016年にリリースされ、当時 Thymeleaf + Knockout.js の MPA として開発されていました。 現在、事業拡大に伴うユーザーの増加・機能開発に対応し、システムとしてのスケーラビリティを上げやすくするため、アーキテクチャの見直しや改善の真っ只中です。 この記事では改善活動で具体的に取り組んだことをご紹介します。フロントエンドの環境改善・統制の一例として、参考となれば幸いです。 ビズリーチ・キャンパスとは? 「ビズリーチ・キャンパス」のシステムは、企業・大学・OB/OG・学生・Adminのそれぞれのアプリケーションがあります。 就職活動をサポートするサービスなので、就活時期に合わせてピークが訪れ毎年新しい企画を実装・実行しながら進化を続けています。 当初の開発体制は? 事業に直結する新機能・施策の開発を主にしているスクラムチームの他に、ネイテ

    フロントエンドを改善し続けてきた道を振り返る 〜 ビズリーチ・キャンパス
    toshikish
    toshikish 2022/09/29
  • 「モノづくり」の視座を高める新卒研修 '22

    Visionalグループ株式会社ビズリーチでは、2022年4月新卒入社のエンジニア職、デザイナー職(あわせてプロダクト職と呼んでいます)を対象とした新卒研修を、約2か月半の間実施しました。 今回のプロダクト職への新卒研修は「品質」に重きを置いて行われました。 記事では、その新卒研修で大切にしていることや、それを通して得た学びと変化について、受講した新卒社員がお伝えします。 「モノづくり」において大切にしていること Visionalは、HR Tech領域を中心に複数の領域で事業を展開しております。 それらの多くは企業様の業務に密接に関係しており、また個人の生活や人生に関わるものです。 つまり、品質が保たれているものを継続的にデリバリーし、お客様のご期待に応えることが求められています。 モノづくりを行う上で大切なことは多くあります。 その中でも品質はモノづくりと切っても切り離せない関係です。

    「モノづくり」の視座を高める新卒研修 '22
    toshikish
    toshikish 2022/08/31
  • ダウンタイムなしでEC2のElasticsearchからマネージドなOpenSearchへと移行した際の工夫

    「HRMOS採用」では、採用に関するデータをElasticsearchに保存し検索機能で利用しております。 以前はEC2インスタンスにインストールしたElasticsearchを利用していましたが、スケールやメンテナンスしづらいことからAWSのマネージドサービスであるAmazon OpenSearch Serviceへの移行を行いました。 移行の際には、ユーザに安心・安全な利用をしていただけるように、下記の4つの観点に気をつけました。 データのロストがないこと セキュリティ的に安全であること 機能・非機能ともに劣化がないこと ダウンタイムなしで移行完了させること この記事では、特に ダウンタイムなしで移行完了 に至った3つの工夫を紹介します。 ※以降、Elasitcseasrch=ES、Amazon OpenSearch Service=AOSと記載します はじめに 「HRMOS採用」とは

    ダウンタイムなしでEC2のElasticsearchからマネージドなOpenSearchへと移行した際の工夫
    toshikish
    toshikish 2022/06/28
  • 「LeanとDevOpsの科学」を実際にチームに適用した際の工夫 - talk at DevOpsDays Tokyo 2022

    「LeanとDevOpsの科学」を実際にチームに適用した際の工夫 - talk at DevOpsDays Tokyo 2022 こんにちは、株式会社ビズリーチでプロセス改善活動をしている賀茂といいます。 少し前になりますが、2022年4月21日にDevOpsDays Tokyo 2022にて発表をしたので、発表内容の補足と発表後に会場の方からもらった質問について答えたいと思います。 発表内容について 今回は『ファクトから始める改善アプローチ 〜「LeanとDevOpsの科学」を実践して〜 』と題して「LeanとDevOpsの科学」という書籍の実践事例を発表してきました。 「LeanとDevOpsの科学」について 前提として今回の取り組みは「LeanとDevOpsの科学」というを参考にしています。 「LeanとDevOpsの科学」では開発組織のパフォーマンスを測る指標(Four keys

    「LeanとDevOpsの科学」を実際にチームに適用した際の工夫 - talk at DevOpsDays Tokyo 2022
    toshikish
    toshikish 2022/05/24
  • 13部門のLog4j対応を7時間で実現した、地道な取り組み

    去る2021年12月10日。Apache Log4jの脆弱性がセキュリティ界隈で大きなニュースになったことをご存知でしょうか。この脆弱性は、攻撃も非常に容易で、危険性もとても高いため、数多くの企業が緊急脆弱性対応を余儀なくされました。この記事を読まれている方の中には「対応が大変だった」と感じている方もいらっしゃるかもしれません。 Visionalでは、全13プロダクトの緊急脆弱性対応を7時間で実現しました。 全国の警察施設のセンサーで観測された攻撃数のグラフを見ますと、攻撃が増え始めたのが2021年12月12日頃です。それより2日前に、プロダクト開発部が13部門もある中で、全部門の回答が7時間で出そろったのですから、爆速対応と言っても過言ではありません。 これは、セキュリティ室とプロダクト開発部が一丸となって成し遂げた快挙です。 …恥じらいもなく厚顔で申し上げましたが、2年前までは事業部と

    13部門のLog4j対応を7時間で実現した、地道な取り組み
    toshikish
    toshikish 2022/03/14
  • Visionalの新卒向けスクラム研修の内容を題材を含めて公開します!

    Visionalグループでは、2019年より新卒研修のカリキュラムの1つとしてスクラム研修を実施しています。 この研修では、単にスクラムのイベントを一通り体験してもらうことが目的ではなく、実際に新卒入社者でチームを作り開発する中で、スクラムやAgileで重要にしている考え方を体験してもらっています。 記事では、研修で用いたリポジトリも公開しつつ、どのような考えで研修を行っているのか紹介します。 Visionalにおける新卒研修の全体像とスクラム研修 2021年度の新卒研修は実践課題だけでなく、その前提となるチーム開発やプロダクト組織で働くうえで欠かせない研修を含む、以下8つの研修で構成されています。 Git/GitHub研修 技術者倫理研修 サービス運用/信頼性研修 セキュリティ研修 グローバル研修 テストの考え方研修 スクラム研修 実践課題 これらの新卒研修で大切にしている考え方や大枠

    Visionalの新卒向けスクラム研修の内容を題材を含めて公開します!
    toshikish
    toshikish 2021/12/16
  • 3年間のオンボーディングで培われた、リモートでも効果的な7+3のプラクティス

    現場主導で始まったHRMOSの開発組織のオンボーディングは、ほぼ毎月、地道に運用と改善を続けてきました。2018年に開始してから3年近くになりますが、エンジニアを対象に始まり他職種のメンバーを巻き込みながら、効率と効果の両面を少しずつ洗練させてきました。この記事では、私たちのオンボーディングを定義や効果を俯瞰しながら紹介し、その中で徐々に確立されてきたプラクティスをご紹介します。 変化の時代に不可欠なオンボーディング オンボーディングとは採用や異動によって組織に加わった人材の早期戦力化のための施策であり、 組織に新しく加わった人材を1日も早く戦力化し、組織全体との調和を図ることを目的とした育成プログラムのことを指します。『機内』や『乗船』という意味を持つon-boardから派生して生まれた造語であり、直訳すると『飛行機や船に乗り込んでいる』という意味です。 〜 BizHint などと定義さ

    3年間のオンボーディングで培われた、リモートでも効果的な7+3のプラクティス
    toshikish
    toshikish 2021/06/16
  • 円滑なエラーバジェット運用に向けた取り組み

    HRMOSでは顧客満足を最優先し、価値あるソフトウェアを早く継続的に提供するため、スクラムに加え、Site Reliability Engineeringをプロダクト開発に適用し、SLI/SLOを定め、運用しています。また、エラーバジェット枯渇時にどのように行動するのか、その運用ルールも定めています。 私たちと同じようにエラーバジェットを運用する組織において、枯渇後のアクションとしてリリース凍結1を視野に入れようとする場合、プロダクトや関係者に与える影響は大きいため、そのルールの策定や調整に頭を悩ますケースも多いのではないでしょうか。 HRMOSの中でも特に歴史の長いプロダクトであるHRMOS採用では、SREチーム内や関係者との間で議論を重ねてルールを見直してきたため、これからエラーバジェットの運用を開始しようとしている方々の参考になればと思い、現在どういった点を考慮して運用しているかを紹

    円滑なエラーバジェット運用に向けた取り組み
    toshikish
    toshikish 2021/06/08
  • 大規模toB SaaS「HRMOS」のフロントエンド開発にDesign Systemを導入した理由

    HRMOSでは複数存在するモジュールの体験を統一するために「Design System(デザインシステム)」の開発を行ってます。 そこで日は HRMOSにおけるDesign System メリットだけではない、Design Systemのデメリット を中心に紹介をしたいと思います。 Design Systemとは? 『Design System』というの一節にこう書かれています。 デザインシステムとは、デジタルプロダクトの目的を達成するために首尾一貫したルールで編成された、お互いに関連づけられたパターンとその実践方法です。パターンは繰り返される要素で、これらを組み合わせてインターフェースを作成します。 — Design Systems - アラ・コルマトヴァ HRMOSにおいてのDesign Systemとは、いわゆるUI Kitのようにデザインパターンが羅列されているだけでなく、いつ

    大規模toB SaaS「HRMOS」のフロントエンド開発にDesign Systemを導入した理由
    toshikish
    toshikish 2021/05/25
  • 1年を超える長期プロジェクトを30人超でふりかえりした話(後編) 〜チーム構成、時間構成〜

    新規プロダクトや大きな機能のリリース、大規模リニューアルなど、長い時間かけて行うプロジェクトは少なからず発生します。 みなさんは、そのようなプロジェクトのふりかえりは上手く行えていますか?また、オンラインでのふりかえりはどのように行っていますか?この記事では、長期間のプロジェクトに対するふりかえりの方法を、どのように準備して行なっていったかをご紹介します。 今回のふりかえり会の全体像 今回のふりかえりではmiroを用いて下記の流れで行いました。それぞれのプラクティスの内容については、前編で説明しています。 ふりかえり事前会アジェンダ 参画時期の共有(プラクティス1) 起こったことの共有(プラクティス1) ふりかえり会アジェンダ 日のチャレンジ宣言(アイスブレイク) 良かったこと、気になったことを共有(プラクティス1) インタビュー×3(プラクティス2) 課題の狙いを定める(プラクティス

    1年を超える長期プロジェクトを30人超でふりかえりした話(後編) 〜チーム構成、時間構成〜
    toshikish
    toshikish 2021/04/27