プロジェクトを作ったら、ドキュメントに運用ルールを書こう

プロジェクト開始のタイミングで、仕事の進め方を運用ルールとしてまとめ、メンバー全員に周知しましょう。

なぜ運用ルールが必要なのか

運用ルールがないことで発生する問題

運用ルールがないと、以下のような問題が発生する可能性があります。

  • Backlogを積極的に利用しないメンバーがいる
  • 優先順位が低いタスクを優先的に対応してしまう
  • メンバーによって課題の対応に違いが生じる
  • 課題の更新や入力内容がメンバーによって違いが生じることで、プロジェクトの現状把握が難しくなる
  • 暗黙の了解が生まれ、属人化してしまい、引き継ぎ時の手間が増える

運用ルールがあることで生じるメリット

運用ルールがあると、以下のようなメリットがあります。

  • Backlogを初めて使うメンバーでも、運用ルールに沿って安心して利用することができる
  • 共通の手順に沿って仕事を進めることで、メンバーによる対応の違いを防ぐことができる
  • 記入される情報が統一されるので、プロジェクト内で起きていることを、正確に把握できるようになる
  • ルールを明文化することで、新規メンバーへ引き継ぐ際やプロジェクトの運用改善に役立つ

プロジェクト開始時に、運用ルールをまとめたドキュメントを用意することは、プロジェクト管理のベストプラクティスの1つと言えます。

運用ルールのサンプル

プロジェクトの目的や課題登録のルールについて、サンプルをご用意しております。

Backlogのドキュメント。プロジェクトの目的や課題登録のルールが記載されている。

コピーアンドペースト用

以下の内容をコピーして、ドキュメントに貼り付けてご利用ください。

Windowsをご利用の場合

ctrl + shift + Vで貼り付け

Macをご利用の場合

Command(⌘) + Shift + Vで貼り付け

# プロジェクトの目的

**新商品を開発し、量産・流通体制を整える**

# プロジェクトメンバー
| ポジション | 担当者 | 役割 |
| ------------- | ------------- | ------------- |
| リーダー | 三宅彩 | プロジェクト管理 <br> Backlogのメンテナンス |
| デザイナー | 志村俊介 | 商品・Webサイト等のデザイン |
| エンジニア | 後藤真司 | ハードウェア |
| エンジニア | 六平圭佑 | ソフトウェア |
| 海外 | 仁井ゆかり | 広報部との窓口 |

# 課題登録のルール

## タスクの登録

* 新規タスクは、 「誰が」「何を」「いつまでに」やることが明確になったらBacklogに課題登録する
* 件名は必ず「○○を××する」の形式で登録する
* 詳細には、補足説明と完了条件を、箇条書きで簡潔に記載する
* 課題登録するときは、必ず担当者と期限日を設定する


## 課題更新時のルール

### 更新するタイミング
* タスクの状況が変わったとき
   * 状態を更新する
* 連絡・相談をする場合
   * コメント欄を使って会話する
   * 会話をしたい相手を「コメントをお知らせしたいユーザー」に追加する

### タスクのチェック・完了
* 状態を「処理済み」、担当者を「リーダー（三宅）」にする
* リーダーがチェックして「完了」にする
* 修正が必要な場合は、差し戻す

## 課題の状態の定義
| 状態 | 意味 |
| ------------- | ------------- |
| 未対応 | タスクの存在を把握しているが、未着手 |
| 処理中 | 担当者と期限日が明確で、作業に着手している |
| 処理済み | 作業が一段落し、リーダーの確認待ち |
| 完了 | 確認が終了し、以後手戻りが発生することはない |

運用ルールに必要な要素

運用ルールには、以下の要素を含めると良いでしょう。

プロジェクトの目的と達成したいゴール

一つ一つのタスク処理やプロジェクト全体についての判断基準は「それが目的達成に貢献するか」どうかです。プロジェクトの目的の共有は、メンバーが適切にタスクを処理する上で重要です。

それぞれのメンバーの役割

メンバーの役割分担が不明瞭だと、タスクのアサイン時や状況確認の際に、誰と話せば良いか分からず時間が掛かってしまいます。メンバーがプロジェクトの中でどのような役割を担うのかを明確にしましょう。

誰が課題登録をするのか

Backlogはプロジェクトに招待されたユーザーは、課題登録や更新が可能です。しかしプロジェクトによっては、特定のタスクについて責任あるメンバーのみが編集できるようにしないと、プロジェクトに混乱を招く場合があります。例えば以下のような場合です。

  • ソフトウェア開発プロジェクトでの新機能追加の課題を登録する
  • 「処理済み」の課題を確認し、OKなら「完了」に状態変更する

上記のような場合に運用ルールを明文化しておくことで、「自分が登録・更新して良いのだろうか？」という疑問をなくし、メンバーが課題を登録・更新しやすくなります。

メモ

ユーザーの権限で「課題の閲覧のみ」の制限がかかっている場合、課題を登録したり更新することができません。詳しくはユーザーの権限>3.追加権限・制限を参照してください。

課題に登録すべき項目（属性）

「件名」「詳細」「担当者」「期限日」の4つは登録するようにしましょう。詳しくは課題を追加しようを参照してください。

余力があれば、「種別」や「カテゴリー」も設定しましょう。課題をグルーピングして、様々な角度からプロジェクトを可視化できます。「種別」と「カテゴリー」にどのような項目があり、それぞれどのような使い方をするのかを明文化しておくと、担当者が迷わず課題を整理することができます。「種別」や「カテゴリー」について詳しくは、種別・カテゴリー・マイルストーンを使い分けようを参照してください。

いつ状態を変更すればいいか

「状態」の定義を記載し、状態の更新を促しましょう。

メンバー間で、状態がどういう状況を意味するのかの解釈が異なっていると、着手していない課題を「処理中」にしたり、まだ終わっていない課題を「完了」にしたりしてしまうことがあります。プロジェクトの中で状態の意味を定義して、明文化しましょう。

詳しくは「状態」を定義しようを参照してください。

まずはシンプルなルールから始めよう

最初から完璧な運用ルールを作ろうとすると、大変な労力が掛かってしまいます。まずは簡単な箇条書きで構わないので、最低限プロジェクトの目的の共有と、課題に担当者・スケジュールを設定することから始めてみましょう。プロジェクトの進展やBacklogへの習熟に合わせて、少しずつ運用ルールを充実させましょう。

この記事は役に立ちましたか？

関連記事