こんにちは。ビズリーチのHRMOS SREチームの神田です。「HRMOS（ハーモス）」シリーズの各種サービスの信頼性向上や運用効率化をミッションとして、スクラムをベースとした開発手法で日々改善に取り組んでいます。 本稿では、私たちのチームで自然と始まった「Vibe Coding」というアプローチを紹介します。これは、生成AIの力を借りて、Daily Scrumでの日常のちょっとした会話やアイデアを即座に形にし、日々の業務を改善していく取り組みです。 この記事が、開発現場でのAI活用や、私たちのチームがどのように新しい技術を取り入れ、日々の業務をより良くしているか、その一端に触れていただく機会となれば幸いです。

こんにちは。 株式会社ビズリーチでSREグループに所属している、今村悠人です。 ビズリーチ事業部のSREグループ（以下、SREチーム）は「ビズリーチ」サービスを担当しており、信頼性向上を通じてプロダクトの成長を支えています。 この記事では、スクラム運用で直面した課題を乗り越える中で得られた実践的な知見を、皆さまのチーム運営のヒントとしてお役立ていただけるよう詳しくご紹介します。

「HRMOSタレントマネジメント」目標・評価チームでは日々スクラムを実践し、アジャイル開発を目指しています。 私たちのチームは開発の中で、以下の課題に直面しました。 🚨 開発者にとって、他の開発者やプロジェクトへのサポートや連携に入りづらい 仕様や見積ドキュメントが標準化されておらず、開発案件の進め方や知識が属人化していました。 これにより、開発者がどう他の開発者やプロジェクトへのサポートや連携に入って良いのかわかりづらくなっていました。

はじめに HRMOSプロダクト本部で人財活用システム「HRMOSタレントマネジメント」のプロダクト開発をしている輿水です。 私たちのチームには、プロダクト開発を進める上で次のような課題がありました。 プロダクトオーナー（以下、PO）の業務が多岐にわたり、ドキュメントの更新が大きな負担となっていた 要件や仕様について最新の情報を把握することが難しく、ステークホルダー間でのコミュニケーションコストが増大していた これらを解決するため、私たちのチームは「エピック主管」という仕組みを導入しました。これは、エンジニアがリードしてドキュメント管理を行い、プロジェクトマネジメントの役割も果たすことで、POやエンジニアリングマネージャー（以下、EM）の業務負担を削減するものです。 本記事では、エピック主管とは何か、そしてその役割や成果について深く掘り下げて紹介します。

スパイクしなければ開発計画が不確実なものになる、しかしそのスパイクがいつ完了するのかわからない、そのような経験はないでしょうか。スクラムでは、ソフトウェア開発の不確実性を乗り越えるためにスパイクを実施しますが、スパイクそのものの不確実性は残ったままです。スパイクとは不確実なものを早期に確実なものに変えるための手法であり、不確実性をはじめからなかったことにできる魔法のアイテムではないからです。

レトロスペクティブ（a.k.a レトロ）。アジャイル開発の中で良く見かける言葉。スプリントの振り返りの時間として、何が良かったか悪かったかの議論の場であり、これからどのように進めていくかが、ここで話されています。新しいことに取り組んだり上手く回ってないことを止めたり継続的にチームを改善していく重要な場になっています。

アジャイル開発の浸透で、顧客やステークホルダーとの対話に応じて臨機応変な対応が可能になり、大きな手戻りは減ったかもしれません。それでも、なお、ソフトウェア開発の本質的な複雑さや不確実性は、分割されたと言えるものの、誰もが満足できる状態で解決された、とは言えなさそうです。それでもプロセス改善の探求を繰り返していくなかで、私たちは「ロバストネス分析」にたどり着きました。単なる懐古主義ではなく、実際に以下のような問題への解を見出すことができましたので、その事例を紹介します。

アジャイル開発を採用しているチームにおいても、ビジネスの要求によっては「一定規模のフィーチャーセット」を「特定の時期にリリースする」ことを、達成しなければなりません。 そういった要求に対し、挑戦する20代の転職サイト「 キャリトレ 」 の開発チームがどのように立ち向かっているのか、リファインメントの実践例を通してご紹介します。

Visionalグループでは、2019年より新卒研修のカリキュラムの1つとしてスクラム研修を実施しています。 この研修では、単にスクラムのイベントを一通り体験してもらうことが目的ではなく、実際に新卒入社者でチームを作り開発する中で、スクラムやAgileで重要にしている考え方を体験してもらっています。 本記事では、研修で用いたリポジトリも公開しつつ、どのような考えで研修を行っているのか紹介します。

スプリントの失敗は「まったく予見ができなかった問題」が原因になるとは限りません。認識できたはずの問題を認識できなかった、存在は認識していたのに注目しなかった、問題に注目はしたが対策を検討していなかったなど、後から振り返ると「なぜそこでつまづいてしまったんだろう…」と思えるようなことが、スプリントの失敗の原因となることもあります。

ビズリーチ事業部のSREチームは、スクラムを導入して1年が経ち、タスクの可視化と脱属人化を実現しました。 導入にあたって何をしたのか、開発チームとは異なる工夫が必要だったところはどこか、導入後何が変わったのかを振り返ってみました。

この記事では、私たちのチームがスプリントゴールの達成とコード品質の低下を防ぐために行っているプラクティス、「死亡前死因分析」について紹介します。 スクラムチームと計画 変化への適応が強調されるスクラムですが、だからと言って事前の計画をないがしろにすることはできません。