プロジェクトを作ったら、Wikiに運用ルールを書こう
プロジェクト開始のタイミングで、仕事の進め方を運用ルールとしてまとめ、メンバー全員に周知しましょう。
なぜ運用ルールが必要なのか
運用ルールがないと・・・
- ツールの利用に慎重なメンバーは、Backlogを積極的に利用しない
- 不要なタスクを処理してしまう
- メンバーによって課題の処理にばらつきが生じる
- 課題の更新や入力内容もメンバーによってバラバラになり、プロジェクトの現状把握が難しくなる
- 暗黙の了解が多数生まれ、属人化してしまい、引き継ぎ時の手間が増える
運用ルールがあると・・・
- Backlogを初めて使うメンバーでも、安心して利用することができる
- 共通の手順に沿って仕事を進めることで、メンバーによって異なる対応を防ぐことができる
- 記入される情報が統一されるので、プロジェクト内で起きていることを、正確に把握できるようになる
- ルールを明文化することで、新規メンバーへ引き継ぐ際やプロジェクトの運用改善に役立つ
プロジェクト管理に慣れている人は、プロジェクト開始時にWikiを用意する場合が多いです。プロジェクト管理のベストプラクティスの１つと言えるでしょう。
運用ルールのサンプル
コピー・ペースト用
# プロジェクトの目的
**新商品を開発し、量産・流通体制を整える**
# プロジェクトメンバー
| ポジション | 担当者 | 役割 |
| ------------- | ------------- | ------------- |
| リーダー | 三宅彩 | プロジェクト管理 <br> Backlogのメンテナンス |
| デザイナー | 志村俊介 | 商品・Webサイト等のデザイン |
| エンジニア | 後藤真司 | ハードウェア |
| エンジニア | 六平圭佑 | ソフトウェア |
| 海外 | 仁井ゆかり | 広報部との窓口 |
# 課題登録のルール
## タスクの登録
* 新規タスクは、 「誰が」「何を」「いつまでに」やることが明確になったらBacklogに課題登録する
* 件名は必ず「○○を××する」の形式で登録する
* 詳細には、補足説明と完了条件を、箇条書きで簡潔に記載する
* 課題登録するときは、必ず担当者と期限日を設定する
## 課題更新時のルール
### 更新するタイミング
* タスクの状況が変わったとき
* 状態を更新する
* 連絡・相談をする場合
* コメント欄を使って会話する
* 会話をしたい相手を「コメントをお知らせしたいユーザー」に追加する
### タスクのチェック・完了
* 状態を「処理済み」、担当者を「リーダー（三宅）」にする
* リーダーがチェックして「完了」にする
* 修正が必要な場合は、差し戻す
## 課題の状態の定義
| 状態 | 意味 |
| ------------- | ------------- |
| 未対応 | タスクの存在を把握しているが、未着手 |
| 処理中 | 担当者と期限日が明確で、作業に着手している |
| 処理済み | 作業が一段落し、リーダーの確認待ち |
| 完了 | 確認が終了し、以後手戻りが発生することはない |
* プロジェクトの目的
''新商品を開発し、量産・流通体制を整える''
* プロジェクトメンバー
| ポジション | 担当者 | 役割 |h
| リーダー | 三宅彩 | プロジェクト管理 <br> Backlogのメンテナンス |
| デザイナー | 志村俊介 | 商品・Webサイト等のデザイン |
| エンジニア | 後藤真司 | ハードウェア |
| エンジニア | 六平圭佑 | ソフトウェア |
| 海外 | 仁井ゆかり | 広報部との窓口 |
* 課題登録のルール
** タスクの登録
- 新規タスクは、 「誰が」「何を」「いつまでに」やることが明確になったらBacklogに課題登録する
- 件名は必ず「○○を××する」の形式で登録する
- 詳細には、補足説明と完了条件を、箇条書きで簡潔に記載する
- 課題登録するときは、必ず担当者と期限日を設定する
** 課題更新時のルール
*** 更新するタイミング
- タスクの状況が変わったとき
-- 状態を更新する
- 連絡・相談をする場合
-- コメント欄を使って会話する
-- 会話をしたい相手を「コメントをお知らせしたいユーザー」に追加する
*** タスクのチェック・完了
- 状態を「処理済み」、担当者を「リーダー（三宅）」にする
- リーダーがチェックして「完了」にする
- 修正が必要な場合は、差し戻す
** 課題の状態の定義
| 状態 | 意味 |h
| 未対応 | タスクの存在を把握しているが、未着手 |
| 処理中 | 担当者と期限日が明確で、作業に着手している |
| 処理済み | 作業が一段落し、リーダーの確認待ち |
| 完了 | 確認が終了し、以後手戻りが発生することはない |
運用ルールに必要な要素
運用ルールには、以下の要素を含めると良いでしょう。
プロジェクトの目的と達成したいゴール
一つ一つのタスク処理やプロジェクト全体についての判断基準は「それが目的達成に貢献するか」どうかです。プロジェクトの目的の共有は、メンバーが適切にタスクを処理する上で重要です。
それぞれのメンバーの役割
メンバーの役割分担が不明瞭だと、タスクのアサイン時や状況確認の際に、誰と話せば良いか分からず時間が掛かってしまいます。メンバーがプロジェクトの中でどのような役割を担うのかを明確にしましょう。
誰が課題登録をするのか
Backlogはシステム上、一般ユーザーであれば誰でも課題登録・更新が可能です。しかしプロジェクトによっては、特定のタスクについて責任あるメンバーのみが編集できるようにしないと、プロジェクトに混乱を招く場合があります。例えば
- ソフトウェア開発プロジェクトでの新機能追加の課題を登録する
- 「処理済み」の課題を確認し、OKなら「完了」に状態変更する
そのような場合に運用ルールを明文化しておくことで、「自分が登録・更新して良いのだろうか？」という疑問をなくして、メンバーが課題を登録・更新しやすくなります。
課題に登録すべき項目（属性）
「件名」「詳細」「担当者」「期限日」の４つは登録するようにしましょう。くわしくは課題を追加しようをご覧ください。
余力があれば、種別・カテゴリーも設定しましょう。課題をグルーピングして、様々な角度からプロジェクトを可視化できます。種別とカテゴリーにどのような項目があり、それぞれどのような使い方をするのかを明文化しておくと、担当者が迷わず課題を整理することができます。
いつ状態を変更すればいいか
状態の定義を記載し、状態の更新を促しましょう。
メンバー間で状態がどういう状況を意味するのかの解釈が異なっていると、着手していない課題を「処理中」にしたり、まだ終わっていない課題を「完了」にしたりしてしまうことがあります。プロジェクトの中で状態の意味を定義して、明文化しましょう。
くわしくは状態を定義しようをご覧ください。
まずはシンプルなルールから始めよう
最初から完璧な運用ルールを作ろうとすると、大変な労力が掛かってしまいます。まずは簡単な箇条書きで構わないので、最低限プロジェクトの目的の共有と、課題に担当者・スケジュールを設定することから始めてみましょう。プロジェクトの進展やBacklogへの習熟に合わせて、少しずつ運用ルールを充実させましょう。