バックログアイテムの管理をNotionで取り組んでみた
こんにちは、CastingONEでPdMをしている小林です。
日々プロダクト開発を行う中でバックログアイテムの管理は非常に重要です。今回は弊社がどのようにバックログアイテムの管理を行っているか、その設計思想や運用した結果どのような効果が得られたかについて紹介します。
バックログアイテム管理における弊社の課題
これまで弊社では、バックログアイテムの管理にTrelloやZenHubといったツールを活用してきました。しかしながら、これらのツールにはいくつかの課題がありました。
まず、ツールの使い勝手の面で、主にカンバンViewが採用されており、リストViewでのバックログアイテムの管理が難しく、全体像を把握しにくいという点が挙げられます。
直近のタスクを消化するという観点ではカンバンViewは非常に優れていますが、ビジネス部門が把握したいのは全体像であり、全体を俯瞰してプロジェクトを確認するという観点ではカンバンViewでは管理しづらいです。
また、ZenHubは閲覧を行うためにGitHubアカウントが必要であり、ビジネス部門にとってはバックログアイテムを閲覧する目的のみでアカウント作成が必要となります。さらに、ZenHubもGitHubも英語で提供されているため、それも利用障壁の一つとなっていました。
タスクの親子関係は一応設定できるものの、親タスクから子タスクをフィルタリングする機能しかなく、子タスクの進捗状況やストーリーポイントの合計を親タスクに反映させるといった親子タスク間の連動機能は備わっていませんでした。
さらに、ツールの挙動が重く、ラベルの更新が反映されないこともありました。
これらの理由から、運用面で使いづらさが顕著となり、ビジネス部門との連携も困難でした。
弊社の運用目的に合わなかったため、より適切なツールの選定を検討する必要がありました。
Notionを選定した背景
弊社では、社内のドキュメント管理にNotionを活用しており、すでに一元化された環境が整っています。
そのため、バックログアイテムの管理においてもNotionを活用することで、より円滑な運用が期待できると考えました。
Notionを利用することで、開発部門とビジネス部門が同じツールを利用できるため、コミュニケーションの円滑化も図れます。また、既存のドキュメント管理環境との連携を可能にすることで、効率的な運用が可能となります。
さらに、Notionを選定した最大の理由として、データベースによる管理機能があり、自社の運用に合わせて柔軟にカスタマイズできる点が挙げられます。
従来のプロジェクト管理ツールは、ツールごとに管理方法がある程度決まっており、カスタマイズが難しい傾向があります。そのため、導入は容易ですが、自社の運用に合わないといったデメリットが存在します。
Notionの導入には、他ツールからのバックログアイテムの移行に加えデータベースおよび管理方法の設計が必要ですが、その後は自社の運用に非常にフィットした形で利用することができます。
どのような設計を行ったのか
弊社では、バックログアイテムを「Epic」、「Story」、「Task」の3つのレベルで分類しています
※バックログアイテムの概念については、こちらの記事を参照してください。
全体像を把握しやすいように、Epicのみで構成されたデータベースと、個々の着手すべき内容を把握しやすいように、StoryとTaskで構成されたデータベースの2つに分割して管理するようにしました。データベースは分割されていますが、Epic、Story、Taskはすべて親子関係で結び付けられ、管理されています。
また、バックログアイテムの表示方法も、各役割に応じて把握しやすいように工夫しています。
全体像を俯瞰する必要があるプロダクトマネージャーはテーブルViewを利用し、一方、目の前のタスクを確認しやすくする必要がある開発者はカンバンViewを利用しています。
これにより、プロダクト開発がより円滑に行えるようになっています。
さらに、他の工夫として、各スクラムイベントごとに、そのイベントに適したページを用意し、管理しています。これにより、バックログアイテムの管理だけでなく、スクラムイベントもすべてNotion上で完結させることができました。
運用した結果どんな効果が得られたか
Notionを活用したバックログアイテム管理の運用を開始して以降、ビジネス部門との対話が活発になり、コミュニケーションの質が向上しました。
今までは、ビジネス部門とのコミュニケーションは口頭かチャットツールに限定されており、なぜそうなったのか背景がエビデンスとして残っていませんでした。
また、チャットツールに情報を残していた場合でも、わざわざチャットツールを見に行かなければならないという負担が発生していました。
完璧な状態まではまだほど遠いですが、ビジネス部門もドキュメントツール内でやり取りする機会が増えたため、これらの問題が少しずつ解消されてきました。
さらに、質問箱を設置することで、運用中の改善点を社内メンバーから収集し、随時改善することによって、日々使いやすく進化しています。
改善点を挙げたメンバーも、自分の提案が反映されたことがモチベーションとなり、さらに別の改善点を提案してくれるようになっています。
反省点としては、運用開始をスムーズに行うためにマニュアルを作成しましたが、最初から詳細に作り込みすぎたため、保守が大変になったことが挙げられます。
新しいオペレーションを開始した直後は、運用してみて改善点が多々発生します。その度に詳細に作り込まれたマニュアルを修正しなければならず、修正が追いつかない、マニュアル作成者以外が編集しづらい、といった問題があります。
また、カスタマイズの自由度が高い点も、一転するとデメリットになることがあります。運用を良くするためにカスタマイズした結果、複雑になりすぎてしまい、逆に運用に負担がかかるという事象も発生しました。
Notionは機能改善のスピードも早く、かゆいところに手が届かなかった部分が日々改善されています。これからも継続的にアップデートされる機能を取り入れながら、理想の管理ツールを目指して継続的な改善を行っていく予定です。
Discussion