プロジェクト管理の定番ツール
プロジェクトの進捗を管理するのにBacklogやRedmineなどの定番ツールがありますよね。
それぞれのタスクがどういったステータスでどれくらいの進捗率かを見たり、予定や実績をガントチャートで見る事が出来ます。
タスク管理だけでなくWikiのようなドキュメントを作る事も出来れば、ファイルサーバーとして使う事も出来ます。
GitやSVNなどとも連携すればソースファイルの管理もする事が出来ます。
昔はExcelファイルのメール添付でよくやりましたが、クラウドサービスの時代では距離の離れたメンバー同士で仕事する事が可能です。
ちょっとした会話はチャットで、
がっつり会話したい時は電話やビデオ通話で、
そして進捗確認やドキュメント管理をする時はBacklogを使うという仕事のやり方が定番になりつつあります。
Backlogの使い方
1タスクあたりのBacklogの使い方の流れは次のようになります。
- 管理者が予定されているタスクの作業内容を記載する。この時のステータスは「未対応」でタスクのページが生成される。
- 作業者が作業を開始したらステータスを「対応中」にする
- 作業者が作業を完了したらステータスを「対応済み」にする
- 管理者が作業が完了している事を確認したらステータスを「完了」にする。作業者に差し戻す場合は「対応中」ステータスまで戻して、コメントを入力する。
これを各タスク毎に行う事で、条件などで絞り込む事が出来るので、全体や種類毎の途中経過を見る時に大変役立ちます。
またプロジェクト終了後もその記録を残しておく事が経験をノウハウとして貯める事にもなります。
クライアントや外注先とも使う
これは社内だけの運用に限りません。
「招待」という機能を使えば、自社で契約しているBacklogに他社の人を参加させる事が出来ます。
これによって自社のタスクと、クライアントや外注先のタスクやマイルストーンをまとめて管理する事が出来ます。例えば、
・クライアントにいつまでにタイトル文や説明文を決めてもらわないといけないか
・デザイナーはいつまでにデザイン案を作らないければいけないか
・外注先の開発がいつまでに完了しないといけないか
・自社での動作確認がいつまでに完了しないといけないか
・サービスはいつローンチになるか
など、よりプロジェクト全体を見ながら管理をする事が出来ます。
また途中経過がちゃんと文字というエビデンスとして残るので議事録代わりになり、相手との「言った」「言わなかった」問題を防ぐ事にもなります。
進捗ミーティングをする時も、書類を紙で印刷するより、Backlogをモニターで一緒に見ながらやる方が効率も良く、地球にも優しいです。
よって他社とのやりとりにおいても、こういったプロジェクト管理ツールを使う事はとても良い事なのです。
社内用と社外用で使い分ける必要性
ここでPM(プロジェクトマネージャー)あるあるなのが、社外用と社内用の両方のBacklogアカウントを用意して使い分ける必要性があるという事です。
社外用とはクライアントまたは外注先とのコミュニケーション用で、参加者は各社の窓口担当です。
社内用とは自社内のみのタスク管理用で、自社のプロジェクトメンバー全員が参加するものです。
PMは社外の人といろんな調整をしながら、社内の管理もしなければなりません。
これをBacklogを使ったクライアントとのやりとりの例を挙げてみます。
- クライアントからクライアント用Backlog経由で要望がくる。
- 社内Backlogにその内容を転記してメンバーに作業を伝える
- メンバーが作業完了した事を社内Backlogで報告してくる
- クライアント用Backlogでクライアントに作業完了を報告する
このように、 いわゆる伝言ゲームの状態になります。
しかしこのように社外用と社内用を分ける事には理由があります。
・プロジェクトに関わる社内と社外のメンバーが全員参加すると、内容が煩雑になって管理しづらい
・社内メンバーの不用意な発言を社外の人に見られないように食い止める
などです。そのためにPMが間に入って管理しなければいけません、まさに中間管理職のようなものです。
これが2次請け状態になるとこのアカウントがまた増えるわけです。
・クライアント用
・社内用
・外注先用
先ほどの例を外注先を使った場合にすると、
- クライアントからクライアント用Backlog経由で要望がくる。
- 社内Backlogにそのタスクを追加する。
- 外注用Backlogにその内容を転記して外注先に作業を伝える
- 外注先が作業完了した事を外注用Backlogで報告してくる
- 外注先の作業内容を確認して、社内Backlogのタスクを完了ステータスにする
- クライアント用Backlogでクライアントに作業完了を報告する
このようになり、さらに伝言ゲームの階層が深くなるのです。
しかしクライアントに外注を使っている事を知らせていない事も多いので、やはりアカウントは別々に分ける必要があるのです。
転記の時間がもったいない
管理すべきタスクの量が増えればこの転記するという作業も膨大になります、まさに塵も積もれば山となるです。しかし
・作業のエビデンスを残したい
・見られたくないものを見せたくない
などの理由もあり、そのためにはやはりアカウントは分けて管理するしかありません。
そうすると管理作業が多くなり、PMの作業が大変になってくると、PMOとかPLというPMをサポートする職種の人がさらにアサインされ、またプロジェクト管理費が増す事に繋がっていく訳です。
プロジェクト管理費さえなければその分が利益になるのに、実にもったいない。
しかし案件が大きくなればなるほど、管理者が1人では管理しきれなくなるのもまた事実なのです。
結局何を優先するのか
ただの伝言ゲームの管理工数がいかに人件費の無駄になっているかがよく分かったと思います。しかし
・作業のエビデンスを残したい
・見られたくないものを見せたくない
というのであれば、やはりアカウントは分けて管理するしかありません、それは仕方のない事です。
他に我々が出来る事があるとすれば、プロジェクト管理＝Backlogを使うという先入観をなくす事ではないでしょうか。
何でもかんでもプロジェクトが立ち上がるたびにBacklogを使わなくても良いと思うのです。
すべての工程のエビデンスを残しておくほどでもないプロジェクトもあるでしょうし、
量よりも質よりもスピードを重視するプロジェクトだってあるでしょう。
Backlogではタスクの1つ1つにページが割り当てられますが、Office365を使えばクラウド上でExcelファイルを複数人同時編集出来るので、Excelファイル1つでプロジェクト管理をする事だって出来ます。
プロジェクト管理する事自体を作業としてしまってはいけません。
プロジェクト管理すべきだから必要に応じて対応を取るという考え方でなければ、余計な作業で利益を食いつぶすだけです。
