メンバー全員が開発リードになれる、「エピック主管」という仕組み
はじめに HRMOSプロダクト本部で人財活用システム「HRMOSタレントマネジメント」のプロダクト開発をしている輿水です。 私たちのチームには、プロダクト開発を進める上で次のような課題がありました。 プロダクトオーナー（以下、PO）の業務が多岐にわたり、ドキュメントの更新が大きな負担となっていた 要件や仕様について最新の情報を把握することが難しく、ステークホルダー間でのコミュニケーションコストが増大していた これらを解決するため、私たちのチームは「エピック主管」という仕組みを導入しました。これは、エンジニアがリードしてドキュメント管理を行い、プロジェクトマネジメントの役割も果たすことで、POやエンジニアリングマネージャー（以下、EM）の業務負担を削減するものです。 本記事では、エピック主管とは何か、そしてその役割や成果について深く掘り下げて紹介します。 この記事では、プロダクト開発において
ゼロから始める社内セキュリティ留学 制度づくりの工夫と参加者の声
セキュリティ人材の不足が社会的な問題になっているのは皆さんも耳にしたことがあるのではないでしょうか。日本は3年連続で1組織あたりのサイバー攻撃が世界一の状況にありながら、欧米と比べ国家的な支援制度・法制度が乏しく、せっかくの人材も海外へ流出し、国内の少ない人材のパイを奪い合っているのが現状です。 Visionalグループでは、全社横断組織としてセキュリティ室があります。今回はそんな社会課題の解決と、Visionalグループが目指す事業とセキュリティの真の「共存」への1つの解決案として、セキュリティ室が実施する「サイバーセキュリティ社内留学制度」をご紹介できればと存じます。一方通行の文章とならないよう、実際に参加された留学当事者にも忌憚無く語っていただきました。皆様の組織のセキュリティ施策のご参考になれば幸いです。 まずは自己紹介です。私、佐藤はCEH (Certified Ethical
2023年 新卒研修② エンジニア・デザイナーが合同でモノづくりを学ぶ テスト駆動開発（TDD）編
Visionalグループ 株式会社ビズリーチでは、2023年4月に入社した新卒プロダクト職（エンジニア/デザイナー）を対象とした新卒研修を約3ヶ月の間実施しました。最初の約1ヶ月間はビジネス職と合同で顧客志向を中心に学び、その後はプロダクト職としてモノづくりのプロセスや品質の基礎を学びました。 研修を通して得た学びや変化について、受講した社員が3回にわたりご紹介します。 本記事では、テスト駆動開発（TDD）の日本での第一人者として知られる和田卓人(@t_wada)さんを講師としてお招きし、品質の大切さを学んだ「TDDワークショップ」について、プロダクト職（エンジニア）の渋谷がお伝えします。 TDDワークショップの概要 ワークショップの構成 TDDとはプログラム実装前にテストコードを書き、そのテストに適合するようにコードを実装する開発手法です。今回のTDDワークショップでは、@t_wadaさ
100万ユーザーをログアウトさせずに新認証基盤に移行した話
即戦力人材と企業をつなぐ転職サイト「ビズリーチ」は2009年にサービスを開始し、スカウト可能会員数は190万人以上（2023年1月末時点）のユーザーにご利用いただくサービスに成長しました。 今回、その「ビズリーチ」の認証基盤としてIDaaS（Identity as a Service）のOkta Customer Identity Cloud（Powered by Auth0）（以下Auth0という）の導入を行いました。 本記事では認証基盤を刷新するに至った背景とAuth0を用いて100万を超えるユーザーをログアウトさせることなく移行した方法についてご紹介いたします。 前提 本記事で得られる情報 本記事を読むことで以下のような情報を得ることができます。 IDaaSを選ぶ理由 IDaaSを用いて認証・認可を運用中のプロダクトに組み込んだ事例 運用中のプロダクトに組み込む際に発生しうる課題と対
エンジニアの枠を囚われないプロダクト開発 - 事業づくりに求められる「越境」をするには
私は「大きな社会の課題解決に挑む会社であること」、「不確実な状況下で事業づくりにチャレンジができること」に惹かれて新卒でVisionalに入社してから、約3年半新規事業でソフトウェアエンジニア兼プロダクトマネージャーとして手探りながらも事業開発に関わってきました。本記事では、その経験を元に、エンジニアから見たプロダクト開発における越境についてご紹介します。 これまでプロダクト開発を進める中で、事業の解決すべき課題にフォーカスするためには特定の役割のみに閉じているカタチでは実現できないと感じる場面が多くありました。世の中に価値あるプロダクトを提供するために、職種や立場にとらわれず、個々がオーナーシップを持って役割を染み出しながら、事業開発に向き合うということをここでは「越境」としています。 ここからは、私が「BizHint」で実際に行った「メールマガジン配信」における制作改善業務の具体的な体
ソフトウェアデリバリーパフォーマンスに関する考察（前編） - 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
「モノづくり」の視座を高める新卒研修 '22
Visionalグループ株式会社ビズリーチでは、2022年4月新卒入社のエンジニア職、デザイナー職（あわせてプロダクト職と呼んでいます）を対象とした新卒研修を、約2か月半の間実施しました。 今回のプロダクト職への新卒研修は「品質」に重きを置いて行われました。 本記事では、その新卒研修で大切にしていることや、それを通して得た学びと変化について、受講した新卒社員がお伝えします。 「モノづくり」において大切にしていること Visionalは、HR Tech領域を中心に複数の領域で事業を展開しております。 それらの多くは企業様の業務に密接に関係しており、また個人の生活や人生に関わるものです。 つまり、品質が保たれているものを継続的にデリバリーし、お客様のご期待に応えることが求められています。 モノづくりを行う上で大切なことは多くあります。 その中でも品質はモノづくりと切っても切り離せない関係です。
ダウンタイムなしでEC2のElasticsearchからマネージドなOpenSearchへと移行した際の工夫
「HRMOS採用」では、採用に関するデータをElasticsearchに保存し検索機能で利用しております。 以前はEC2インスタンスにインストールしたElasticsearchを利用していましたが、スケールやメンテナンスしづらいことからAWSのマネージドサービスであるAmazon OpenSearch Serviceへの移行を行いました。 移行の際には、ユーザに安心・安全な利用をしていただけるように、下記の4つの観点に気をつけました。 データのロストがないこと セキュリティ的に安全であること 機能・非機能ともに劣化がないこと ダウンタイムなしで移行完了させること この記事では、特に ダウンタイムなしで移行完了 に至った3つの工夫を紹介します。 ※以降、Elasitcseasrch=ES、Amazon OpenSearch Service=AOSと記載します はじめに 「HRMOS採用」とは
「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
iALSによる行列分解の知られざる真の実力
以下では、この表データは \(X\) という行列にまとめられているとします。上記テーブルに含まれる user_id 数を \(N_U\) , item_id 数を \(N_I\) とするとき、 \(X\) は \( N_U \times N_I\) 行列であり、その第 \(i\) 行は user_id として \(\mathrm{user}[i]\) を持つユーザーに、第 \(j\) 列 は item_id として \(\mathrm{item}[j]\) を持つアイテムに対応するとします。このマッピングのもと、 \(X\) の \(i\) 行 \(j\) 列の要素は、以下の式で与えられます。 $$ X_{ij} = \begin{cases} 1 & (\text{if } \mathrm{user}[i] \text{ and } \mathrm{item}[j] \text{ had
13部門のLog4j対応を7時間で実現した、地道な取り組み
去る2021年12月10日。Apache Log4jの脆弱性がセキュリティ界隈で大きなニュースになったことをご存知でしょうか。この脆弱性は、攻撃も非常に容易で、危険性もとても高いため、数多くの企業が緊急脆弱性対応を余儀なくされました。この記事を読まれている方の中には「対応が大変だった」と感じている方もいらっしゃるかもしれません。 Visionalでは、全13プロダクトの緊急脆弱性対応を7時間で実現しました。 全国の警察施設のセンサーで観測された攻撃数のグラフを見ますと、攻撃が増え始めたのが2021年12月12日頃です。それより2日前に、プロダクト開発部が13部門もある中で、全部門の回答が7時間で出そろったのですから、爆速対応と言っても過言ではありません。 これは、セキュリティ室とプロダクト開発部が一丸となって成し遂げた快挙です。 …恥じらいもなく厚顔で申し上げましたが、2年前までは事業部と
SREチームがスクラムを導入し1年でタスクの可視化と脱属人化を実現した話
ビズリーチ事業部のSREチームは、スクラムを導入して1年が経ち、タスクの可視化と脱属人化を実現しました。 導入にあたって何をしたのか、開発チームとは異なる工夫が必要だったところはどこか、導入後何が変わったのかを振り返ってみました。 ビズリーチ事業部のSREチームについて 「ビズリーチ」を担当していて、SRE(Site Reliability Engineer)としてアプリケーションエンジニアと共にプロダクトの継続的な成長のため信頼性・可用性の向上、自動化、効率化などに取り組んでいます。 なお、チームの構成は以下のようになっています。 開発者: SREチームのメンバー(5人) PO: SREチームのマネージャー スクラムマスター: 社内横断組織に所属している専任のスクラムマスター SREチームが抱えていた課題とスクラムの導入目的 まず、SREチームがスクラムを導入した背景を説明します。 PO
3年間のオンボーディングで培われた、リモートでも効果的な7+3のプラクティス
現場主導で始まったHRMOSの開発組織のオンボーディングは、ほぼ毎月、地道に運用と改善を続けてきました。2018年に開始してから3年近くになりますが、エンジニアを対象に始まり他職種のメンバーを巻き込みながら、効率と効果の両面を少しずつ洗練させてきました。この記事では、私たちのオンボーディングを定義や効果を俯瞰しながら紹介し、その中で徐々に確立されてきたプラクティスをご紹介します。 変化の時代に不可欠なオンボーディング オンボーディングとは採用や異動によって組織に加わった人材の早期戦力化のための施策であり、 組織に新しく加わった人材を1日も早く戦力化し、組織全体との調和を図ることを目的とした育成プログラムのことを指します。『機内』や『乗船』という意味を持つon-boardから派生して生まれた造語であり、直訳すると『飛行機や船に乗り込んでいる』という意味です。 〜 BizHint などと定義さ
大規模B2B SaaS 「HRMOS」におけるDesign Systemの開発・運用プラクティス
前回の記事ではHRMOSのDesign Systemの導入背景の紹介をしました。 本日はそのDesign Systemがどのように開発・運用されているのかを紹介したいと思います。 開発体制 Design Systemの開発はデザイナー、エンジニアが1つのチームとして開発を行っています。 開発のポイントとしては以下のとおりです。 デザインタスク、実装タスクなどすべてのDesign Systemのタスクは1つのバックログで管理 隔週に1度、やることの計画、やったことの確認をチーム全員で行う チームメンバーは全員兼務なので、極力MTGを増やさないよう、非同期でのコミュニケーションをメインにしている この体制になった背景として、当初はDesign System開発がデザイナーとエンジニアで分断されていたことにあります。 デザインとエンジニアリングでそれぞれ別のバックログをもち、それぞれ別のサイクル
大規模toB SaaS「HRMOS」のフロントエンド開発にDesign Systemを導入した理由
HRMOSでは複数存在するモジュールの体験を統一するために「Design System(デザインシステム)」の開発を行ってます。 そこで本日は HRMOSにおけるDesign System メリットだけではない、Design Systemのデメリット を中心に紹介をしたいと思います。 Design Systemとは？ 『Design System』という本の一節にこう書かれています。 デザインシステムとは、デジタルプロダクトの目的を達成するために首尾一貫したルールで編成された、お互いに関連づけられたパターンとその実践方法です。パターンは繰り返される要素で、これらを組み合わせてインターフェースを作成します。 — Design Systems - アラ・コルマトヴァ HRMOSにおいてのDesign Systemとは、いわゆるUI Kitのようにデザインパターンが羅列されているだけでなく、いつ
スクラムチームを支える心理学 - 死亡前死因分析
この記事では、私たちのチームがスプリントゴールの達成とコード品質の低下を防ぐために行っているプラクティス、「死亡前死因分析」について紹介します。 スクラムチームと計画 変化への適応が強調されるスクラムですが、だからと言って事前の計画をないがしろにすることはできません。 私たちのチームが大切にしているキーワードのひとつに、“Measure twice, cut once” （二度測って、一度で切る）があります。もともとは優れた大工の仕事を指す言葉で、注意深く計画し一度で仕事を済ませる、手戻りのない状況を表現する言い回しです。 私たちにとっても、“Measure twice, cut once” の大切さは大工にとってのそれと変わりません。手戻りはデリバリの速度だけでなく、実装の素直さやコードの端的さにも悪い影響を与えるためです。ソフトウェアのバグが一番現れやすい箇所は「苦労と試行錯誤の末にな
効果を維持しつつテスト工数を削減した話 〜テスト設計改善の質問回答編〜
以降では、このテスト設計改善の取り組みに対する質問に回答していきます。 テスト設計改善についての質問の回答 【質問1】テスト設計にあたって開発ドキュメントの参照はしないのでしょうか。開発ドキュメントがほとんど無い？ 開発ドキュメントの参照はします。チケットの内容、開発ドキュメントだけでなく、その内容に対しての疑問点は実際に開発と議論しておきます。開発者との議論はテスト設計に着手する前、テスト観点出しを行う前後の活動です。 【質問2】テストと設計の比率を出していらっしゃいましたが（テストをいっぱいやるようにした）、数える単位は何ですか？人数？時間？その他？ 説明資料では文字の大きさの都合上省略した形で書いていますが、比率を出していたのは「（開発の設計ではなく）テスト設計」と「テスト実施」の比率です。また、ここでの比率は感覚値ではありますが、工数比です。 【質問3】改善後の成果物サンプルやアク
100を超えるAWSアカウント運用におけるガードレール構築事例
先日行われました AWS JAPAN SUMMIT ONLINE 2020 にて、「大規模な組織変遷と100以上のAWSアカウントの横断的セキュリティガードレール運用について」のテーマにて、私たちのグループで取り組んでいる全ての AWS に対する横断的な取り組みを ビジョナル CTO 竹内 と ビジョナル CIO 園田 より発表させていただきました。 今回は、その発表内容について、発表の中で伝えきれていない内容などより詳細にお話しさせていただきます。 こんにちは、システム本部 プラットフォーム基盤推進室 ORE (Organizational Reliability Engineering) グループ の 長原 です。 私が在籍するグループでは、 Visional グループの全事業のクラウドや非機能要件等に対して、横断的にエンジニアリングによる課題解決に取り組んでいます。 複数事業・マルチ
今一番アツいWebセキュリティガイドラインOWASP ASVS v4でリスク評価した話
先日日本語訳版が発表されたばかりの OWASPアプリケーション検証標準 バージョン4（以下ASVS v4)を用いて、 Webアプリケーションセキュリティの評価をサービスに対して実施した感想などについて記載します。 ASVS v4は非常に包括的なWebアプリケーションセキュリティの評価ガイドラインです。 それこそ「エンジニア研修でまず最初に読もう！」と推進したくなるほど多角的に記載がされています。 どのぐらい包括的であるかについてですが、開発体制・ログ・認証・ログインフォームの設計・総当たりに対するアカウントロックの時間・GraphQLにおけるセキュリティなど、とにかく盛りだくさんな記載がされています。 すべてのエンジニアにとって必読の ASVS v4 こんにちは、佐分基泰と申します。 16年の新卒として入社し、サーバサイド -> 脆弱性診断士を経て、 現在はOSS Libraryセキュリテ
AWS S3に蓄積したlogをGoogleのBigQueryに投入する仕組み作り~概要編~ - BizReach Tech Blog
BizReachプロダクト開発部、SREグループの久保木です。5月頃に中途で入ってきて、今はinfrastructure中心に開発に従事しています。 最近はlog生成周りをいじっていった結果、生成元であるapplicationもいじれるようになってきた気がします。あとはfrontendいじれば制覇かな！（＜どこに行く気なの？） ところで、元々僕は何かを作る時に延々とmemoがてら作業進捗を書いていく癖があります。 それで作業が一区切りしたところで、 「あれ、これ記事のネタになるんじゃない？」 と思ったので書いてみることにしました。ボリュームがあるので連載にてお送りします。 どうぞよろしくお願いします。 前編: 概要 中編: 技術調査・設計 後編: 七転八倒ログ 何があったのか まず、前提。 BizReachのapplicationはlogをS3に飛ばして、そこからなんやかんやあって(後述)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
