アジャイル開発を採用しているチームにおいても、ビジネスの要求によっては「一定規模のフィーチャーセット」を「特定の時期にリリースする」ことを、達成しなければなりません。 そういった要求に対し、挑戦する20代の転職サイト「 キャリトレ 」 の開発チームがどのように立ち向かっているのか、リファインメントの実践例を通してご紹介します。 「キャリトレ」は2022年12月21日をもってサービス終了しました。 予測可能性を求めるビジネスの要求とは 分かりやすい例でいうと「業界の繁忙期に合わせて新機能をリリースしたい」などです。 また、BtoBビジネスの場合、開発チームがフィーチャーセットとリリース時期をある程度担保することができれば、 企業のお客様に対し事前のご案内がしやすくなります。 そのことは、リリース直後からその機能を最大限ご活用していただける、という大きなメリットがあります。 事業部一体となって

サービス価値向上に、脆弱性診断を活用できていますか？ 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） 課題の狙いを定める（プラクティス3

この記事では、私たちのチームがスプリントゴールの達成とコード品質の低下を防ぐために行っているプラクティス、「死亡前死因分析」について紹介します。 スクラムチームと計画 変化への適応が強調されるスクラムですが、だからと言って事前の計画をないがしろにすることはできません。 私たちのチームが大切にしているキーワードのひとつに、“Measure twice, cut once” （二度測って、一度で切る）があります。もともとは優れた大工の仕事を指す言葉で、注意深く計画し一度で仕事を済ませる、手戻りのない状況を表現する言い回しです。 私たちにとっても、“Measure twice, cut once” の大切さは大工にとってのそれと変わりません。手戻りはデリバリの速度だけでなく、実装の素直さやコードの端的さにも悪い影響を与えるためです。ソフトウェアのバグが一番現れやすい箇所は「苦労と試行錯誤の末にな

QAチームのテスト設計改善およびテストマネジメント改善の取り組みを、9月16日に主催したD3QAにて発表しました。事前登録者数は500名以上、配信時の同時視聴者数は最大300名以上となりました。 質問も60問ほどいただいたのですが、イベント期間内に全ての質問に答えることができなかったため、3つの記事に分けて質問に回答します。また、当日参加できなかった方にも把握していただけるように、当日の発表内容から抜粋して紹介しつつ、質問に回答していきます。 本記事ではテストマネジメント改善に関する質問に回答します。 発表概要の紹介 改めましてこんにちは！ビズリーチのQA基盤推進室のブロッコリーです。社内でも社外でも「ブロッコリーさん」と呼ばれています。 私は先日「テスト活動の納得感を持ってテストケースを激減させた話」というタイトルで発表を行いました。 発表スライドは下記となります。 また、当日の配信内容

以降では、このテスト設計改善の取り組みに対する質問に回答していきます。 テスト設計改善についての質問の回答 【質問1】テスト設計にあたって開発ドキュメントの参照はしないのでしょうか。開発ドキュメントがほとんど無い？ 開発ドキュメントの参照はします。チケットの内容、開発ドキュメントだけでなく、その内容に対しての疑問点は実際に開発と議論しておきます。開発者との議論はテスト設計に着手する前、テスト観点出しを行う前後の活動です。 【質問2】テストと設計の比率を出していらっしゃいましたが（テストをいっぱいやるようにした）、数える単位は何ですか？人数？時間？その他？ 説明資料では文字の大きさの都合上省略した形で書いていますが、比率を出していたのは「（開発の設計ではなく）テスト設計」と「テスト実施」の比率です。また、ここでの比率は感覚値ではありますが、工数比です。 【質問3】改善後の成果物サンプルやアク

BizReachプロダクト開発部、SREグループの久保木です。5月頃に中途で入ってきて、今はinfrastructure中心に開発に従事しています。 最近はlog生成周りをいじっていった結果、生成元であるapplicationもいじれるようになってきた気がします。あとはfrontendいじれば制覇かな！（＜どこに行く気なの？） ところで、元々僕は何かを作る時に延々とmemoがてら作業進捗を書いていく癖があります。 それで作業が一区切りしたところで、 「あれ、これ記事のネタになるんじゃない？」 と思ったので書いてみることにしました。ボリュームがあるので連載にてお送りします。 どうぞよろしくお願いします。 前編: 概要 中編: 技術調査・設計 後編: 七転八倒ログ 何があったのか まず、前提。 BizReachのapplicationはlogをS3に飛ばして、そこからなんやかんやあって(後述)

キャリトレ事業部の松岡(@little_hand_s)です。 キャリトレチームでスクラム開発を導入し、議論の機会が増えたため、議論自体の効率化必要性に突き当たりました。 そこで、会議設計やファシリテーションの書籍を何冊か読み、実際に現場で実践してみたころ、 議論が必要な仕事であれば幅広く、確実に生産性を向上できるという手応えがありました。 その実践結果から、再現性が高く、すぐ実行できそうなTipsを抜き出してまとめました。 「キャリトレ」は2022年12月21日をもってサービス終了しました。 議論を始める前に、必ず目的とゴールを設定する 議論を行う場合は、以下の2つを必ず設定します。 目的：なぜその会議を行うのか？ ゴール：議論終了時にどういう状態になっていたいか？ これはとにかく基本です。これを守るだけで、生産性が大幅に上がるので、まずはこれを徹底しましょう。 対象は主に会議のような場で

こんにちは。 ビズリーチ インキュベーションカンパニーで新規事業のエンジニアをしている藤村です。 幾つかのメディアに取り上げて頂きましたが、現在開発マシンとして全エンジニア、デザイナーの希望者に、iMac Pro と標準スペックの MacBook Pro を支給しています。 ※ ノート派の方は高スペックの MacBook Pro を選択できます。 一方で、iMac Pro って普通のサーバーサイド、Web 開発程度で効果あるの? と疑問を持つ方もいるかもしれません。 実際に私達も計測する前はそうでした。 結論からいうと、クリーンビルドで 2.13 倍〜 6.67 倍、インクリメンタルビルドで 1.33 倍〜 7.00 倍という効果がありました。 今回は、ビルド速度と金の弾丸の相関に興味がある方々に向けて、導入背景の小話と、iMac Pro 導入後のリアルなベンチマーク結果を共有したいと思い

ビズリーチで「HRMOS（ハーモス）採用管理」のフロントエンドエンジニアをしています、浅井です。 前編では「AngularJSのリプレースにAngularを選んだ話」についてお話しました。 今回は、長期的にサービスを発展させていくことを念頭に置き、アプリケーションの規模もチームメンバーの人数が増えていってもスムーズに開発・メンテナンスしていくために、AngularでWebアプリケーションを再構築していく中で盛り込んだことをご紹介したいと思います。 AngularJS時代の課題 せっかくAngularに移行するからには、「AngularJS時代からの負債は引き継ぎたくない、メンテナンスしやすい仕組みにしておきたい」というのがチームメンバー全員の想いとしてありました。 まずは、AngularJS時代に実装・運用フェーズで感じていた課題を洗い出したところ、 ページ単位で 似たようなUIが別々に

ビズリーチで「HRMOS（ハーモス）採用管理」のフロントエンドエンジニアをしています、浅井です。 HRMOS採用管理は、前身を含めると2014年に開発がスタートし、当初より Single Page Application (以下、SPA) を全面的に採用し、そのフロントエンドのすべてを AngularJS (以下、旧AngularJS) + TypeScript が担ってきました。サービスの拡大に伴って機能は増えていき、ソースコードは総計10万行まで膨れ上がってきました。 そこで現在は、旧AngularJSで記述されたコードを捨てつつ、新しいAngularを用いたコンポーネント指向のアーキテクチャに移行している真っ只中です。この移行で取り組んだ際の裏話を前編・後編のふたつに分け、前編では「AngularJSのリプレースにAngularを選んだ話」、後編では「Angularを用いたコンポーネ

株式会社ビズリーチで、SREエンジニアとして勤務しているmassです。2017年4月に入社してから、HRMOSというサービスのAWSのインフラを管理したり、アーキテクチャの設計・構築をしたりしています。 今回は、入社してから半年経ったらいつのまにかサービスのネットワーク管理者になっていて、そこで発生した問題と、それを解決するのに非常に役立ったCloudMapperというOSSを紹介したいと思います。 発生した問題 私がネットワーク管理者を引き継いだ段階では、ネットワーク構成図が作成されておらず、以下の問題が発生していました。 ロードバランサーを止められない 用途不明のロードバランサーが存在したため、停止を検討した。 しかし、どのリソースから利用されているか見えず、不用意に停止できなかった。 用途不明なEC2インスタンスの調査ができない AWSからメンテナンス通知が来た対象が用途不明なEC2