開発PM勉強会vol.20_LT_失敗から学ぶドキュメントとチケット運用のコツ

Transcript

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide