DX事業部の鹿嶋です。
「プロジェクトの進捗が見えない」「タスクの優先順位がわからない」「チーム内のコミュニケーションがうまくいかない」、このような悩みを抱えていませんか？
弊社ではプロジェクト管理において、主に Backlog というツールを活用しており、透明性を担保したプロジェクト進行を行えるようにしています。本記事では、プロジェクトの「開始前」「進行中」「完了後」の各段階で、Backlog を活用してプロジェクトを効果的に『見える化』するための Tips をご紹介します。

1. プロジェクト開始前に意識していること

1.1. プロジェクトの作成、メンバーの追加

プロジェクトが何の用途で幾つ必要になるか検討する

プロジェクトの成功において、コミュニケーションは大切な要素ですが、コミュニケーションの場が複数あったり、参加者もまばらだったりすると、どこで何を話しているか、話すべきかが曖昧になってしまいます。

  • 開発用プロジェクトなのか保守用プロジェクトなのか
  • 内部メンバーのみのプロジェクトなのか、顧客も参加するプロジェクト（連絡用）なのか
  • プロジェクトのリリースが完了した場合、今後はどのように利用する想定なのか（そのまま保守で利用するのか、アーカイブしてプロジェクトを別で作成するのか）

プロジェクトに誰を招待するか検討する

プロジェクトの効率と情報セキュリティを最適化するためには、適切なメンバー選定が不可欠になります。
大前提として、プロジェクト関係者ではないメンバーを招待しないこと、が挙げられます。

  • プロジェクトに関係のないメンバーに招待を送らない
  • 単純に関係者でないメンバーに対して、情報がノイズになる
  • 関係者以外にもプロジェクトの情報が流れてしまう
  • プロジェクトが増えるごとにダッシュボードが重くなり、閲覧に支障が生じる（場合がある）

誰にどのような権限を与えるのか検討する

プロジェクト管理に限った話ではありませんが、適切な権限設定は、プロジェクトの円滑な進行とセキュリティの両立に重要な役割を果たします。

  • プロジェクトの管理者: PMO / PM / PL など: 主にプロジェクトを管理するメンバー
  • プロジェクトのメンバー: 開発者 / デザイナー / テスターなど: 主に割り振られたタスクを実行するメンバー
  • プロジェクトのゲスト: 顧客など: 主にタスクの閲覧やコメントのみを行うメンバー
    • 上記はメンバー権限としても良いが、ツールの利用に不慣れな場合など、破壊的操作を行わないかどうか、また行われてしまった際の対応は考慮・検討しておく必要がある

1.2. 運用ルールの策定

チケット識別子の定義

『見える化』においてチケットの種類を識別できることはとても大切な要素です。
ただし、識別子がプロジェクト運用にどのような効果をもたらすかを考えた上で追加をする必要があります。

  • 識別子をいたずらに数を増やしすぎない、用途をメンバーとすり合わせる
    • 作って終わりではなく、実際に使われないとただのノイズになってしまいます
    • デフォルトで用意されているもので事足りるのであれば、無理に追加する必要はありません
    • 「要件定義」などのフェーズは識別子として登録せず、フェーズはマイルストーンで管理すると見やすいです

チケットのタイトルの定義

プロジェクトが進めば進むほど、チケットは過去の情報を参照するための大切な財産となります。
チケットの中から狙った情報を探し出すために、タイトルもきちんと意味を持ったものに設定しておくことが大切です。

  • チケットを開かなくとも、タイトルで何のチケットかわかるように心掛ける
    • NG例: 〇〇画面のバグ / △△について
    • OK例: 〇〇画面のヘッダーロゴの画像リンクが切れて表示されていない

期日の定義

期日はプロジェクトを進行するにあたって大切な要素となります。
期日を超過したチケットが残り続けることは、プロジェクトのステータスが不透明な状態となりうるため、適時状況に気を配る必要があります。

  • 期日超過したタスクを生み出さない・そのまま放置しないようにどうするかを考える
    • なんらかの最終確認待ちで、期日が超過してそのままになっているケースがよく見られる印象です
    • MTGでチケットの状況確認の時間を設ける、コメントで連絡した上でクローズするなど、そのままとしないことを意識する必要があります
  • 期日を変更する（特に遅延によるもの）際は理由をコメントに残しておく
    • コメントは証跡でもありますので、万一認識齟齬が生じた場合などに有用な情報に変わります。変更が加わった場合は、最新の期日とその変更理由をセットで記載・管理するように意識しましょう。

優先度の定義

例えば全てのチケットの優先度が「高」だと、何から手をつけていいかわからないかと思います。
強い要望があるもの、緊急で対応しなければいけないもの、期間内であればいつでも良いものなど、タスクにはそれぞれ優先度があると思いますので、MTGのやり取りや外部からの情報を踏まえ、適切な状態を設定することを意識しましょう。

  • 利用する場合は、基準を設けて統一する
    • high: 緊急度・重要度が高く、即時の対応が必要であるもの
    • middle: 即時対応は不要であるが、期日が設定されており、期間内に実施する必要があるもの
    • low: 将来的に検討が必要など、クライアントからもまだGoが出ていないもの

進捗ステータスの定義

こちらも『見える化』には非常に大切な要素ですが、ステータスが多いことが良いわけではありません。
自分自身、またメンバーそれぞれが進捗を管理/報告しやすいようにステータスを定義することが必要です。

  • 状況が想像できるステータスであること（未着手・進行中・リリース待ち など）
  • 識別子同様に、いたずらに増やしすぎないこと
    • 識別子やすくするためのステータスの変更に、労力が必要になるのは本末転倒になります
  • ステータス遷移のフローが設けられていること、次のStepが明確にわかるステータス名であること

2. プロジェクト開始後に意識していること

2.1. チケットの作成

1つのチケットに全てを詰め込まない

こちらはチケットの視認性、プロジェクトの進捗管理のどちらにも関わってくる要素となります。
チケットをたくさん作らなければいけないから大変、と思われるかもしれませんが、作業単位を小さく管理することで得られるメリットはたくさんあります。

  • 1〜2営業日で完了する粒度でチケットを分割する
    • 全てが終わらないとチケットの状態が変えられない = いつの間にか当初設定した期日が超過しているというケースを避け、見通しをよくするのが主目的となります
    • ブレイクダウンしていくことで、完了までのプロセスが明確になりやすいです
    • 作業が分かれることから、優先順位づけもやりやすくなります
    • 顧客に対しても「ここまでは完了している」というような説明がしやすくなります

流用可能な依頼（作業）はテンプレート化する

例えば毎月の請求業務など、同じ形式でやり取りを行うことが確定しているタスクがあるのであれば、テンプレート化しておくことによって、毎回のチケット作成作業を簡易化することができます。

  • 誰が記載しても依頼が伝わるように、書くべき内容はもれなく盛り込んでおく
    • AさんとBさんで記載の粒度が異ならないように、大項目となる要素はきちんと含めておくことが大切です

テキストだけでコミュニケーションを取ろうとしない

テキストだけでの内容理解はどこかで限界が生じる場面がありますし、コミュニケーション初期の段階で付加情報があれば、その後のコミュニケーションもスムーズに進めることができる場合があります。

  • スクリーンショットや外部リンクなどを補足情報として追加する
    • 現在どういう状態で、それに対して何をして欲しいのか、どのような手順が必要になるのかをきちんと明記すると親切です
    • なぜこのチケット（作業）が必要なのかが伝わらないと、追加で説明のためのコミュニケーションが発生してしまいます

2.2. チケットの割り当て

担当者のアサインは依頼事項が固まってから

中身がない、または固まりきっていないチケットを渡されても、渡された方は何をすべきか困ってしまいます。
依頼する内容が固まった段階で、初めてアサインを切り替えましょう。

2.3. チケットの進捗・優先度管理

進捗に応じてステータスを変更する

Backlog を見ればどのタスクがどの状態か一目でわかる…これは理想系かと思います（それが難しいのですが）。

作業を仕掛かっている場合は「処理中」、作業完了で確認を残すのみ状態の場合は「処理済み」など、適切なステータスに変更することを意識するだけで、『見える化』には大きく貢献できます。ぜひ意識的に取り組んでみましょう。

  • ステータスを見れば「作業がどの段階にいるか」を判断できるので、不要なコミュニケーションを削減できます
  • これをおろそかにすると、コミュニケーションの始点が「着手してますか？」になってしまうため、本来不要なコミュニケーションが発生してしまう可能性が高いです

優先度変更・差し込み依頼の際は、コミュニケーションを厚くする

優先度の変更や新たなタスクの差し込みは、プロジェクトの流れを大きく変える可能性があるため、慎重に対応する必要があります。チーム全体への影響を考慮し、変更の必要性と緊急性を十分に検討した上で判断しましょう。

  • チケットからの連絡だけではなく、別途担当者に依頼背景などを説明する
    • 作業の中断はかなりのストレスを伴うので、誠実に対応しなければいけません
  • 依頼前に、自分の中で状況・優先度を咀嚼する、妥当性を判断した上で作業依頼を行う
  • ふわっとした優先度の依頼をそのまま横に流してはいけない
    • 例えば一般ユーザへの影響が何もなく、「なんだかデザインが気になる」ため優先度を高くする → そのままエンジニアに依頼をする、といったことは避けなければなりません

各チケットの作業時間は都度入力しておく

作業時間の正確な記録は、プロジェクトにおいて大切な情報となります。
今後の類似の作業のリソース配分の最適化や、見積の精度向上につながります。

また、振り返りの指標の一つとして利用できる（なぜ時間がかかった/かからなかったか、どの部分において時間がかかったか）ため、記録を習慣づけておくことが大切になります。

これは完全な余談ですが、Backlog は合計時間のみカウント・表示の仕様なので、誰が何時間かけたかを記録、可視化できると更に使い勝手が良いのにな…とずっと思っています。

3. プロジェクト終了後に意識していること

3.1. プロジェクトの振り返り

大まかではありますが、以下の観点を確認項目として、継続・改善などのアクションに繋げます。

チケットの進捗状況

  • スケジュール通りに完了したチケットの割合
  • 遅延がない理由と、活かせそうなもの/ことの共有
  • 何らかの理由で遅延したチケットの割合
  • 遅延理由と防止策の精査・検討
  • 完了できなかった（次フェーズに持ち越しなど）チケットの割合
  • 未完了理由と防止策の精査・検討

作業の予実工数

  • ピッタリ/前倒し/遅延の割合
  • 各作業の乖離度合いと、プロジェクト内で乖離が生じた要因を精査し、工数感を養う

コメント・ステータス変更履歴

  • コメントのやり取り（件数）が長い
    • こちらまたは先方が意図を理解できていない？チケットに記載外の話題がやりとりされている？などがあれば、コミュニケーションの改善方法を協議する
  • ステータスの変更が短期間で多く発生
    • 不完全な状態で確認依頼をしていないか？完了要件が曖昧な状態で完了 → 処理中に戻す などはなかったかを確認、依頼の前提や完了要件を協議する

顧客も含めてのチームであるため、顧客もいる場で振り返りができるととても良いですね。

3.2. プロジェクトのアーカイブ

  • 一区切りついたプロジェクトがどうなるのかによって、プロジェクト管理ツール上のプロジェクトの余生も考える必要がある
  • 追加開発など、継続して次のフェーズが始まる場合: 現在のプロジェクトを継続利用する or 新たにプロジェクトを作成する
  • 保守フェーズに移行する場合: 現在のプロジェクトを継続利用する or 新たにプロジェクトを作成する（後者の方がきれいではある）
  • プロジェクトが終了する場合: プロジェクトをアーカイブする

終わりに

本記事では、Backlogを活用したプロジェクト管理の効果的な方法について、プロジェクトの各段階に分けてご紹介しました。

今回は主にチケットベースの管理に焦点を当てましたが、Wikiやガントチャートなど、まだまだ『見える化』に便利な機能がたくさん備わっています。また別の機会に、これらに関してもお伝えできればと思います。

プロジェクトの『見える化』を促進し、チーム全体の生産性向上に繋げていただければ幸いです。