機能別 活用事例

プロジェクト管理の悩み解決!最適なプロジェクトの粒度とは?






Backlogを導入したものの、
「プロジェクトをどこまで細かく分けるべきか」
「逆に、どこまでまとめるべきか」で悩んだ経験はありませんか?

今回は、多くのプロジェクトマネージャーやチームリーダーが直面する
「プロジェクトの作成粒度」というテーマについて掘り下げていきます。

プロジェクトの粒度が適切でないと、
「タスクが埋もれて進捗がわからなくなる」
「プロジェクトが多すぎて全体像が見えない」といった問題が発生しがちです。

今回はこの根深い課題を解決するヒントとして、私たちヌーラボのカスタマーサクセス課
(以下、CS課)が実践しているプロジェクトの使い分けを、実例を交えてご紹介します!


目次

最適な粒度を見つけるための2つの観点
ケーススタディ:ヌーラボCS課の「2種類のプロジェクト」




最適な粒度を見つけるための2つの観点


ここでは、業種を問わず応用できる2つの観点をご紹介します。

■観点1:誰が関わるのか?(メンバーで分ける)


最も基本的な考え方は、
「誰がその業務に関わるのか」「プロジェクトの中身は誰が見ていいのか」という
「人」の単位でプロジェクトを分けることです。

Backlogの「プロジェクト」は、単なるタスクの入れ物ではありません。
プロジェクトに参加する「メンバー」を定義し、アクセスできるメンバーを制御することです。

例えば、「採用管理」というプロジェクトを作れば、採用に関わるメンバーだけがその中の情報にアクセスできます。一方で、「管理部」という、より大きな単位のプロジェクトを作れば、部内のメンバー全員が情報共有できる場になります。

まずは「この業務は、主に誰と誰で進めるのか?」を基準に、プロジェクトという「情報の置き場所」を作るのが第一歩です。

■観点2:情報の見通しは良いか?(目的で分ける)


関わるメンバーが同じでも、
1つのプロジェクトに全てのタスクを詰め込むと、情報がカオスになることがあります。

例えば、私たちCS課でも、「オンボーディング」と「クロスセル」という施策は、関わるメンバーが重複しています。しかし、これを「CS課」という1つの巨大なプロジェクトにまとめてしまうと、オンボーディング担当者にとってクロスセル施策のタスクがノイズになり、逆もまた然りです。

このように、1つのプロジェクト内の課題数が多くなりすぎたり、目的の異なるタスクが混在して見通しが悪くなったりした場合は、性質に応じてプロジェクトを分割することを検討しましょう。

「このプロジェクト、最近ごちゃごちゃして分かりにくいな」と感じたら、
それはプロジェクトの分け方を見直す良いサインです。


ケーススタディ:ヌーラボCS課の「2種類のプロジェクト」


まず、私たちのチーム体制を簡単にご紹介します。
CS課は、「ビジネスグロース部」という大きな部の中に所属しています。

そしてプロジェクトは、大きく分けて以下の2種類を運用しています。
 ・A:部署全体で共有する「ハブ」プロジェクト
 ・B:施策ごとに特化した「専門」プロジェクト

この2種類を使い分けることが、情報整理と施策推進の鍵となっています。
それぞれ詳しく見ていきましょう。

■A:部署全体の「ハブ」プロジェクトの役割


部署や課を横断する共通タスクや、特定の施策に紐付かない業務を集約するための「受け皿」
となるプロジェクトです。ビジネスグロース部全体で一つのプロジェクトを持っています。

■どんな課題(タスク)を入れる?
①部署共通の管理業務
 CS課の管理職がメンバーに依頼する「月末の勤怠確認」や「経費精算のリマインド」
 といった、毎月発生する管理系のタスクがここに入ります。

②新入社員のオンボーディング
 メンターが新入社員に任せるオンボーディングタスクも、このプロジェクトで管理します。


■ポイント
①全員が必ず確認すべき共通連絡事項は「ハブ」プロジェクトに集約することで、情報の見落としを防いでいます。

②新入社員は、入社直後に多数の専門プロジェクトに招待されると混乱してしまいます。
まずはこの「ハブ」プロジェクトだけを見れば、何をすべきかが分かる状態を作ることで、スムーズな立ち上がりを支援しています。


■B:施策ごとの「専門」プロジェクトの役割


CS課が掲げる大きな目標を達成するため、
具体的な施策ごとにゴールとメンバーを絞って集中管理するためのプロジェクトです。

■どんなプロジェクトがある?
①オンボーディング プロジェクト
 ・目的:新規でBacklogを使い始めたお客様の利用定着を促進する。
 ・課題例:チュートリアルコンテンツの作成、ユーザーアプローチの実行など

②クロスセル プロジェクト
 ・目的:既存のお客様に、より価値を感じていただけるプランや製品を提案する。
 ・課題例:資料の作成、ユーザーアプローチの実行など

③bラボ プロジェクト
 ・目的:ユーザーコミュニティを活性化させ、お客様同士の交流を促進する。
 ・課題例:記事企画・執筆など

■ポイント
これらのプロジェクトは、それぞれが追いかけるべきゴール(KGI/KPI)が明確です。
関わるメンバーも限定されるため、議論が分散せず、施策の推進スピードを上げることができます。


■なぜこの分け方なのか?3つのメリット


ヌーラボCS課が「ハブ」と「専門」の2種類を使い分けるのには、明確な理由があります。

①施策ごとに最適化されたプロジェクト設定

施策が異なれば、進捗管理の観点やタスクの内容も当然異なります。
プロジェクトを分けることで、それぞれの目的に合わせて「カテゴリー」「マイルストーン」「種別」「状態」、「課題のテンプレート」といった各種設定を、完全に独立させてカスタマイズできます。

チームにとって最もわかりやすい形での進捗の可視化と、業務効率の向上に繋がります。

②情報の整理整頓とノイズ削減

メンバーは、自分に関係の深い「専門」プロジェクトに集中しつつ、
共通業務は「ハブ」プロジェクトで確認すればOK。
自分に関係のない通知が減り、重要な情報が埋もれません。

③思考の切り替えがスムーズに

「ハブ」プロジェクトを見るときは「管理・共通業務モード」、
「専門」プロジェクトを見るときは「施策推進モード」と、自然と頭を切り替えられます。



今回は、ヌーラボCS課の実例をご紹介しました。

しかし、完璧なプロジェクトの分け方は存在しません。
大切なのは、チームの状況に合わせて、常により良い形を模索し続けることです。
この記事が、その第一歩となれば幸いです。


関連記事

「結局、今やるべきタスクはどれ?」Backlog複数プロジェクトの横断管理術