CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 要件定義とアジャイルな開発のバランス 2021/12/14 株式会社HERP 元木直哉 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 自己紹介 元木 直哉 / Naoya Motoki 株式会社HERP プロダクトマネージャー @motockey_ https://www.facebook.com/naoya.motoki.3 - 2013年4月にJXTGエネルギー（現ENEOS）でバックオフィスとLNGプラント投 資事業に従事 - 2018年7月にHERPに入社、採用コンサルタントとして主にWeb・ITベンチャー の採用支援を行う - 2019年8月よりHERPプロダクトマネージャー兼開発チーム責任者としてロード マップ策定、プロダクトのQCD、開発チームのピープルマネジメントに従事。 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 本日のお品書き HERPでの要件定義についてお話していくために、HERPの開発の流れと具体例を共有します❗ すこしでも役立てる情報があればと思います❗ - HERPについての説明（会社、サービス概要） - HERPの開発組織についての説明 - HERPで行っている要件定義について - HERPでの具体的な開発の流れについてのご紹介 - 現状の課題とこれから改善を考えていること 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy HERPについての説明(会社、サービス概要) 

5 CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 会社名 設立 代表者 MISSION 事業内容 東京本社 社員数 株式会社HERP 2017年3月 代表取締役 CEO 庄田 一郎 採用を変え、日本を強く 採用管理システム HERP Hire タレントプール管理システム HERP Nurture の提供 〒141-0031 東京都品川区西五反田7-22-17 TOCビル12F 55名(インターン含む) 資本金 497,467,000円 会社紹介 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 開発サービス概要 - 採用関連の toB SaaS を開発提供（採用管理、タレントプール管理） - 想定ユーザーは採用担当を始めとした採用に関わる全員（面接官、リファラルやスカウト送 付などに関わるメンバー） - 累計導入数は900社超え - 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy HERP の開発組織についての説明 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy HERP開発体制（2021.12現在、主にフルタイムメンバーを記載） Hire：採用管理プラットフォーム（ATS） Nurture：タレントプール管理プラッ トフォーム PO 1名 デザイナー 2名 フロントエンドエンジニア 2名 バックエンドエンジニア 7名 SRE 2名 フロントエンジニア 1名 基盤開発サポート（パートタイム業務委託） 2名 PO 1名 バックエンドエンジニア 2名 ※その他インターン数名がパートタイムで参加 大きく2チームに分かれて開発（ 12名 : 4名。全体サポート4名。） 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy HERPの開発スタイル（2021.12現在） 各チームごとにバックログを作成しでスクラム開発を実施（ 1週間スプリント）。 スプリントレビューは毎週金曜日の週次全体会議で全社メンバーの前で実施。 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy HERP開発チームの特徴 - ウォータフォール開発を経験したことある人がほぼいない - メンバーの入れ替わりが少ない（離職率が低い、誰かが歴史を知っ ている） - 役職・役割の垣根なく「やるべきこと」をやっていく自律した文化 - アジャイルな開発への志向、アジャイル宣言の尊重 - 「採用ツール」で自社も採用を積極的に行っているため、エンジニ アも含めて社内でサービスのドッグフーディングが可能（共通認識 が形成しやすい） - HERPの開発に協力的なユーザー様が多い https://agilemanifesto.org/iso/ja/manifesto.html 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy HERP で行っている要件定義について 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy HERP での要件定義（というよりも開発フロー） 前述の開発チーム特徴にも起因して、以下の特徴がある（と思っている） - 要件定義という単語が社内で使われていなく、要件定義書のような包括的なドキュメ ントが用意されない - ドキュメントよりもメンバー間での対話による共通認知形成と、開発者による一次情報取得を重視している - もちろんバックログは存在する（Notionで管理）。議事メモは残っている（Notion, Scrapbox, Slack） - また、開発において固定のフローがあまり存在しないので明示的な要件定義のフェー ズも存在しない 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy HERPでの具体的な開発の流れについてのご紹介 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy ある機能開発の大まかな流れ - 実際に開発している日程調整機能を例に説明します - 日程調整機能 = Calendly や Spir のような機能がサービス内でシームレスに使える機能（調 整結果がサービス内に自動的に反映される） 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 検査と適応、プロトタイピングと検証を繰り返してく 1. POが大元となる大きなユーザーストーリー（エピック）を書く（場合によっては開発メンバーと一緒に書く） 2. 開発チームで開発すべき機能への理解を深め要件を整理する - ユーザーヒアリング（社内・社外） - ユーザーストーリーマッピング（社内広く巻き込んですすめる） - システム構成・実装方針のおおまかな検討（SREも含んで会話） - ほか必要に応じて都度実施 3. 週次で動くものを作っていく。以下の流れで仕上がりに応じて試験利用〜本リリースの流れで進める。適宜 2. に戻る。 a. プロトタイピングでMVPを作成しながら社内外にヒアリングを進める b. 社内で試験利用（ヒアリングしながら改善） c. テストユーザー数社で利用（ヒアリングしながら改善） d. クローズドβ版として社数を絞って提供（非機能要件など提供キャパシティの調整） e. 本リリース（全ユーザーに公開） ある機能開発の大まかな流れ（実際に開発している日程調整機能を例に取る） 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 検査と適応、プロトタイピングと検証を繰り返してく 1. POが大元となる大きなユーザーストーリー（エピック）を書く（場合によっては開発メンバーと一緒に書く） 2. 開発チームで開発すべき機能への理解を深める - ユーザーヒアリング（社内・社外） - ユーザーストーリーマッピング（社内広く巻き込んですすめる） - システム構成・実装方針のおおまかな検討（SREも含んで会話） - ほか必要に応じて都度実施 3. 週次で動くものを作っていく。以下の流れで仕上がりに応じて試験利用〜本リリースの流れで進める。適宜 2. に戻る。 a. プロトタイピングでMVPを作成しながら社内外にヒアリングを進める b. 社内で試験利用（ヒアリングしながら改善） c. テストユーザー数社で利用（ヒアリングしながら改善） d. クローズドβ版として社数を絞って提供（非機能要件など提供キャパシティの調整） e. 本リリース（全ユーザーに公開） ある機能開発の大まかな流れ（実際に開発している日程調整機能を例に取る） 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy - POが概ね右のような文章を書いて共有する - 形式は特に決めておらず必要そうな情報を書く - 想定業務フロー - ソリューション案 - 顧客の声 - 競合事例 - など POが大元となる大きなユーザーストーリー（エピック）を書く（場合によっては開発メンバーと一緒に書く） 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 検査と適応、プロトタイピングと検証を繰り返してく 1. POが大元となる大きなユーザーストーリー（エピック）を書く（場合によっては開発メンバーと一緒に書く） 2. 開発チームで開発すべき機能への理解を深める - ユーザーヒアリング（社内・社外） - ユーザーストーリーマッピング（社内広く巻き込んですすめる） - システム構成・実装方針のおおまかな検討（SREも含んで会話） - ほか必要に応じて都度実施 3. 週次で動くものを作っていく。以下の流れで仕上がりに応じて試験利用〜本リリースの流れで進める。適宜 2. に戻る。 a. プロトタイピングでMVPを作成しながら社内外にヒアリングを進める b. 社内で試験利用（ヒアリングしながら改善） c. テストユーザー数社で利用（ヒアリングしながら改善） d. クローズドβ版として社数を絞って提供（非機能要件など提供キャパシティの調整） e. 本リリース（全ユーザーに公開） ある機能開発の大まかな流れ 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy - 社内社外ともにSlack上でカジュアルに顧客に接触できるので CS経由 or 開発チームが自分でテキスト ベースでのヒアリングやアポ取りをする - CS含む営業側のチームで顧客要望について詳細に検討し開発に伝える仕組みが整っているなど、日常的に以下の ことがありCSが顧客の開発要望や協力度の感度が非常に高いので、 CSと協力するとかなりうまくいく状況にある。 ユーザーの皆様に非常に助けられている。 ユーザーヒアリング（社内・社外） Slack上でワイヤーやモックを提示してクイックに意見をもらうことも 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy - ユーザーストーリーマッピング実施前に業務フローの整理と課題の洗い出しを実施、課題を特定（miroを利用） - ソリューションの案だしもしてアテをつけておく ユーザーストーリーマッピング 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy - 開発チームがメインでPOやCSなどを巻き込みユーザーストーリーマッピングをする（現在はmiroを利用） - アウトプットだけではなく検討プロセスを通じてメンバー全員が開発機能への共通認知を得ることが大きな目的 ユーザーストーリーマッピング 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy - 最終的にプロダクトバックログ（ notion上で管理）上にユーザーストーリーを優先順位順に並べる - 優先順位は最終的には POが判断するが、開発チームが並べて迷ったところを相談して変更がある程度で済む事が多い - 後工程のテスト利用でのユーザーヒアリングの都度優先順位の変更を行っていく ユーザーストーリーマッピング 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 検査と適応、プロトタイピングと検証を繰り返してく 1. POが大元となる大きなユーザーストーリー（エピック）を書く（場合によっては開発メンバーと一緒に書く） 2. 開発チームで開発すべき機能への理解を深める - ユーザーヒアリング（社内・社外） - ユーザーストーリーマッピング（社内広く巻き込んですすめる） - システム構成・実装方針のおおまかな検討（SREも含んで会話） - ほか必要に応じて都度実施 3. 週次で動くものを作っていく。以下の流れで仕上がりに応じて試験利用〜本リリースの流れで進める。適宜 2. に戻る。 a. プロトタイピングでMVPを作成しながら社内外にヒアリングを進める b. 社内で試験利用（ヒアリングしながら改善） c. テストユーザー数社で利用（ヒアリングしながら改善） d. クローズドβ版として社数を絞って提供（非機能要件など提供キャパシティの調整） e. 本リリース（全ユーザーに公開） ある機能開発の大まかな流れ 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 検査と適応、プロトタイピングと検証を繰り返してく 1. POが大元となる大きなユーザーストーリー（エピック）を書く（場合によっては開発メンバーと一緒に書く） 2. 開発チームで開発すべき機能への理解を深める - ユーザーヒアリング（社内・社外） - ユーザーストーリーマッピング（社内広く巻き込んですすめる） - システム構成・実装方針のおおまかな検討（SREも含んで会話） - ほか必要に応じて都度実施 3. 週次で動くものを作っていく。以下の流れで仕上がりに応じて試験利用〜本リリースの流れで進める。適宜 2. に戻る。 a. プロトタイピングでMVPを作成しながら社内外にヒアリングを進める b. 社内で試験利用（ヒアリングしながら改善） c. テストユーザー数社で利用（ヒアリングしながら改善） d. クローズドβ版として社数を絞って提供（非機能要件など提供キャパシティの調整） e. 本リリース（全ユーザーに公開） ある機能開発の大まかな流れ 面白そうな資料・話がなかったので ここだけ 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy - テスト利用スライドをつくってCSと開発チームでテスト利用提案 - テスト利用のフィードバックもアポを取ったりして開発チームが直接回収しに行く テストユーザー数社で利用（ヒアリングしながら改善） この条件で使っていただけるユーザーを探す。 そういったユーザーはかなりありがたい存在。 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy 検査と適応、プロトタイピングと検証を繰り返してく 1. POが大元となる大きなユーザーストーリー（エピック）を書く（場合によっては開発メンバーと一緒に書く） 2. 開発チームで開発すべき機能への理解を深める - ユーザーヒアリング（社内・社外） - ユーザーストーリーマッピング（社内広く巻き込んですすめる） - システム構成・実装方針のおおまかな検討（SREも含んで会話） - ほか必要に応じて都度実施 3. 週次で動くものを作っていく。以下の流れで仕上がりに応じて試験利用〜本リリースの流れで進める。適宜 2. に戻る。 a. プロトタイピングでMVPを作成しながら社内外にヒアリングを進める b. 社内で試験利用（ヒアリングしながら改善） c. テストユーザー数社で利用（ヒアリングしながら改善） d. クローズドβ版として社数を絞って提供（非機能要件など提供キャパシティの調整） e. 本リリース（全ユーザーに公開） ある機能開発の大まかな流れ 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy HERP での要件定義（サマリ） - 要件定義というフローも要件定義書もない - ドキュメントよりもメンバー間での対話による共通認知形成と、開発者による一次情 報取得を重視している - テスト提供や段階的なリリースによって仮説と検証を繰り返すことによって常に機能 要件・非機能要件はアップデートされていく 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy ● Good ○ 言われたものを作る、ではなく必要だと思ったものを各人が作っていくので「やらされている感」が少ない。そのた めモチベーションが担保され、きっちり決めていくよりもクオリティとスピードが担保できていると感じている。 ○ 要件の変更に柔軟に対応できる。ドキュメントの修正などもあまり必要ない（ないので）。 ○ 枠組みを決めないことで自由にいろんな手法が試せる良さがあると思っている。今度「デザインスプリント」を導入 してみる計画があるが、こういった話が各開発メンバーから自発的に上がってくる。 ● More ○ メンバーに高いスキルと自律性が求められるので、採用でそういった人を探すのが大変。 ○ スケールしてもこの開発体制のままでいけるかはわからない。今の良さを維持しつつスケールする方法は模索し つつ開発チームを大きくしていきたい。 ○ 非機能要件の検討の中でSLO, SLAなどを考慮に入れられていないので、今後よりそれらを考慮に入れられるフ ローを整備する必要があるかもしれない。 現状のGood・More 

CONFIDENTIAL INFORMATION: Not for Public Distribution - Do Not Copy THANK YOU❗