失敗から学ぶ ドキュメントとチケット運用のコツ 株式会社ビズリーチ（Visionalグループ） 菊池信太郎 本当に使いこなせてる？プロダクト管理ツールの失敗&改善PMトーク 【開発PM勉強会 vol.20】 

略歴 ● 前職はSIer ○ 受託開発やSESで複数プロジェクト経験 ○ テックリード・PM・EMとして開発経験を積む ● 2018年〜 株式会社ビズリーチ ○ ビズリーチのtoBプロダクトを中心に開発 ○ 組織横断型プロジェクトなどのリード ○ EMとしてリアーキテクティングの推進 ● 2019年 合同会社PeerQuestを共同創業 自己紹介 株式会社ビズリーチ リクルーティングプロダクト本部 プラットフォーム開発部部長 合同会社PeerQuest Co-Founder / CTO 2 @be11 菊池 信太郎 

1. 組織が拡大し、ドキュメント管理が破綻した時の処方箋 2. プロダクトバックログが増え過ぎたらどうする？ 3. プロダクトバックログが増え過ぎないようにするには？ 4. 内部統制を考慮したチケット運用 本日話すこと 3 

● チケット管理 ○ 基本的にはJiraを利用 ○ Internal APIの開発チームはGitHub Issues / Projectsをメインで利用 ○ 一部チームでAsanaを利用 ● ドキュメント管理 ○ エンジニアだけでなくPdMやデザイナーも読み書きするので、 Confluenceを利用 ○ コードに強く紐付いているものはGitHubリポジトリで管理 前提：ビズリーチでのプロダクト管理ツール 4 

5 組織が拡大し、ドキュメント管理が 破綻した時の処方箋 

● もともと1つのConfluenceスペースに全チームがドキュメントを書いていた ● 組織が拡大し、ページが増えていった結果、次第にメンテナンス不能に 【失敗】1つのスペースでドキュメント管理 6 プロダクト開発には100名以上が関わり、チーム数は10を超えた 

● 新しいドキュメントを書く際に、どこの階層に書くべきか判断がつかない ● メンテナンスされていないページが多いため、時間が経つと、最新の情報か 信じられなくなる ● ドキュメントオーナーが異動や退職でいなくなると、ページを編集していい のかわからない なぜ破綻したのか？ 7 

● チーム、プロジェクトごとにスペースを割り当てる ● メンテナンス対象のページを絞り、オーナーを割り当てる ● スペースのオーナーが明確になり、メンテナンスがしやすくなる 【改善】Confluenceスペースを分割する 8 https://support.atlassian.com/ja/confluence-cloud/docs/use-spaces-to-organize-your-work/ 

● 整理整頓し続けるには、ドキュメントのオーナーやWiki警察が必要 ● 用途によっては、Scrapboxのようにリンクでつないでいくネットワーク構造 型のドキュメントのほうが望ましい ● 階層整理型のWikiが向いているドキュメント ○ プロジェクトやチーム内の情報集約 ○ 階層構造を使い、体系的に整理したい情報 参考：https://scrapbox.io/shokai/階層整理型WiKiはスケールしない 階層整理型のWikiはスケールが難しい 9 

プロダクトバックログが 増え過ぎたらどうする？ 10 

● ここまで増えると管理不可能… ● 定期的に棚卸ししないと、未対応のまま残ってしまう ● チケットが多いと不具合報告なども重複する 【失敗】気づいたらオープンな課題が数千件 11 

● 取捨選択する時間がもったいない ● 直近のものだけ残してあとは却下（クローズ）する ● 必要になったら再オープンすればよい 【改善】ばっさり捨てる 12 

プロダクトバックログが 増え過ぎないようにするには？ 13 

● チケット数が多くなると、バックログの優先順位づけが面倒になる ● Epicだけでなく、後々のStoryやSub Taskまで細かい粒度で起票し始めると 今重要なものにフォーカスできなくなる ● 計画が変わることはあるので、その時にチケットクローズの手間が増える 【失敗】将来のものまで細かくチケットを作成 14 

● Jiraなどのツールはアジャイルに進められるように設計されている ● WBSを作成することによって開発の計画をすることは大事 ● ただし、最初からJiraで細かくチケットを切るべきでない ● まずはConfluenceでプロジェクト計画を立て、Jiraで段階的に詳細化してい くのがおすすめ ○ Confluenceで要件定義 ○ Confluence内からJiraのEpic、Storyを作成もできる 【改善】チケットは段階的に詳細化していく 15 

内部統制を考慮したチケット運用 16 

● システム変更 ○ 企画、開発、テスト、リリースの承認 ○ … ● 運用 ○ 障害管理 ○ データマイグレーション ○ ジョブ実行 ○ … ● アクセス権 ● 物理機器 ● 外部委託先 プロダクトに関する内部統制の要件抜粋 17 

● なぜ、誰が、何を、いつ変更したのか? ● 誰が、いつ承認したのか？ ● リリース物から企画を遡って確認できるか？ 変更管理のトレーサビリティを担保 18 PR （承認済み） Story, Bug （MGR承認済み） Epic （PO承認済み） 例 承認のワークフローを挟み込み、なるべく人が手動で入力せずとも証跡が残るように設計するとよい 

19 ビズリーチでは絶賛採用中です！ カジュアル面談はこちらから https://hrmos.co/pages/hrmos/jobs/3100100100963/apply ● Software Engineer ● QA Engineer ● Data Scientist ● Designer ● Product Manager 

ご清聴ありがとうございました！ 20