失敗から学ぶドキュメントとチケット運用のコツ株式会社ビズリーチ(Visionalグループ)菊池信太郎本当に使いこなせてる?プロダクト管理ツールの失敗&改善PMトーク【開発PM勉強会 vol.20】
View Slide
略歴● 前職はSIer○ 受託開発やSESで複数プロジェクト経験○ テックリード・PM・EMとして開発経験を積む● 2018年〜 株式会社ビズリーチ○ ビズリーチのtoBプロダクトを中心に開発○ 組織横断型プロジェクトなどのリード○ EMとしてリアーキテクティングの推進● 2019年 合同会社PeerQuestを共同創業自己紹介株式会社ビズリーチリクルーティングプロダクト本部プラットフォーム開発部部長合同会社PeerQuestCo-Founder / CTO2@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スペースを分割する8https://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
● なぜ、誰が、何を、いつ変更したのか?● 誰が、いつ承認したのか?● リリース物から企画を遡って確認できるか?変更管理のトレーサビリティを担保18PR(承認済み)Story, Bug(MGR承認済み)Epic(PO承認済み)例承認のワークフローを挟み込み、なるべく人が手動で入力せずとも証跡が残るように設計するとよい
19ビズリーチでは絶賛採用中です!カジュアル面談はこちらからhttps://hrmos.co/pages/hrmos/jobs/3100100100963/apply● Software Engineer● QA Engineer● Data Scientist● Designer● Product Manager
ご清聴ありがとうございました!20