破綻したドキュメント管理、増え過ぎたプロダクトバックログ…　「Jira」「Confluence」などの活用失敗から学ぶツール運用のコツ

菊池氏の自己紹介

菊池信太郎氏（以下、菊池）：ビズリーチの菊池から、10分枠で話をします。今日のテーマは「失敗から学ぶドキュメントとチケット運用のコツ」ということで、今まで経験したところで「こういうアンチパターンがあったよ」「こういう改善をしたよ」というようなところをお話しできればと思っています。

自己紹介を軽くすると、（私は）2018年からビズリーチで働いています。ビズリーチサービスを作っていて、プラットフォーム開発部の部長をしています。また、2019年から浪川（浪川舞氏）と一緒にPeerQuestを共同創業していて、そのCTOもしています。

セッションの概要

（スライドを示して）本日話すことは、こちらの4本立てです。

前提として、ビズリーチはプロダクト管理ツールのチケット管理で、基本的に「Jira」を使っているんですが、PdMとあまり関わらないチームでは「GutHub Issues」を使ったり、あとは一部のチームで「Asana」を使っていたりしています。

ドキュメント管理では基本的にJiraと相性の良い「Confluence」を利用していて、コードに強く紐付いているものはGitHubリポジトリで管理するような運用の仕方をしています。それを前提として聞いてもらえると幸いです。

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

まず1つ目が、組織が拡大してドキュメント管理が破綻した時の処方箋です（笑）。ビズリーチではもともと1つのConfluenceスペースにビズリーチプロダクトのドキュメントを書いていたんですが、組織が拡大して今ではもう100名以上の人が関わっていて。ページが増えていった結果、次第にメンテナンス不能になりました。

なぜ破綻したのかを考えてみたところ、新しいドキュメントを書く際に、どこの階層に書くべきか判断がつかないというところや、過去10年以上メンテナンスされていないページが増えに増え続けて、時間が経つと最新の情報か信じられなくなるとか。ドキュメントオーナーみたいな人がもともといたんですが、異動や退職でいなくなり、「ページを編集していいのかもうわからないよ」みたいなところが（できてしまったところが）課題だったのかなと思っています。

改善の仕方として、Jiraとコンフル（Confluence）のベストプラクティスって何なのかをけっこう調べました。Confluenceを組織、チームとかプロジェクトごとにきちんとスペースに割り当てようといったところや、メンテナンス対象のページを絞って、オーナーシップを割り当てる。オーナーが明確になるとけっこうそのチームでドキュメントを書きやすくなったりするので、分けていきましょうと。

階層整理型のWikiはスケールが本当に難しいと思っていて、整理整頓するにはWiki警察やオーナーみたいなところが必要かなと思っています。

用途によってはScrapboxのようにリンクでつないでいくネットワーク構造のドキュメントのほうが望ましかったりするのかなと、個人的には考えています。

プロダクトバックログが増え過ぎた時の対処法

プロダクトバックログが増え過ぎるのも「あるある」だと思っていて、管理がけっこう破綻する。ビズリーチも気づいたらオープンな課題が数千件になっていて。ここまで増えると管理不可能です。定期的に棚卸ししないと未対応のまま残ってしまうので、こういうことが起こってしまうんですね。チケットが多いと不具合報告なども重複してしまうので、プロダクトバックログがやたらめったら増えてしまう。

改善策としては、もうばっさり捨てるしかないかなと思っています（笑）。取捨選択する時間がもったいないので、直前のもの、直近1年とか半年というふうに絞って、あとは却下するようなことがいいのかなと思っています。必要になったら再オープンすればいいし、そもそも増やし過ぎないというところも次に大事になってきます。

今まで自分も経験してきた中で、このアンチパターンを踏んできてしまったこともあります。もともとウォーターフォールで開発をしていたりすると、けっこう細かくチケットを切りがちというか、作成したくなってくるので、優先順位づけがどんどん面倒くさくなってくる。Epicだけではなく、Taskなどまで細かい粒度で起票し始めると、重要なものにフォーカスできなくなります。計画も変わるので、チケットクローズの手間だけが増えていくわけです。

これについては、アジャイルのお作法に則りましょう。Jiraは本当にアジャイルに特化するように設計されているので、それに則らないとけっこう使いづらくなってしまいます。

計画は大事なんですが、いきなり細かく切り始めない。ConfluenceやNotion、スプレッドシートでもいいので、プロジェクトの計画を立てて、そこから段階的に詳細化していくというところで、Jiraを使ってチケットを切っていくようにしたほうがいいんじゃないかと思います。

内部統制を考慮したチケット運用をシステムに任せる設計の重要さ

最後に、内部統制を考慮したチケット運用のようなところです。ビズリーチは約3年前にグループ経営体制に移行し、上場、IPOしたんですが、その時に内部統制や会計監査に向けて準備をしてきて、プロセスの整備やドキュメントの整備などもあらためてしました。ここを最初からきちんとやっておいたほうが良かったなというところが反省としてあって（笑）。これもある意味アンチパターンかなと思っています。

何かというと、企画や開発、テスト、リリース物の承認などで、きちんと変更管理ができているというところの証跡をきちんと残していく。エビデンスを残していくことがけっこう大事です。

変更管理のトレーサビリティを担保するために、なぜ、誰が、何を、いつ変更したのか。エンジニアが変更したプルリクエストであったり、企画の内容そのものを「いつ、どうやって変更したの？」というところと、「誰が承認したの？」みたいなところ。

あとは、弊社の例だと、例えばGitHubのPRからJiraチケットを遡って確認ができる。さらにいうと、Epicレベルでのプロダクトも、戦略に基づいた企画をプロダクトオーナーがきちんと承認しているかというところですね。こちらを遡って確認できるのかが変更管理においては非常に重要です。

こういうところを手動運用（するの）はつらいので（笑）。Jiraなどのツールを使って承認のワークフローをシステムに任せて、なるべく人が入力せずとも証跡が残るように設計すると良いのかなと考えています。

時間がどうなっているのか……。ちょっと巻き気味でお話しできたかなと思います。ビズリーチは絶賛採用中です。エンジニアやQA、プロダクトマネージャーも絶賛募集中なので、ぜひぜひカジュアル面談をよろしくお願いいたします。

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