チームが実際にどう仕事を届けているかを軸にプロジェクト管理システムを作るための実践ガイドです。なぜ汎用のプロジェクトツールは使われなくなるのか、自分たちの本当の工程と引き継ぎをどうモデル化するか、最初のバージョンに何が必要か、そしてステータス会議なしで進行中の仕事をどう見えるようにするかを扱います。
既製のプロジェクトツールに納品の流れが収まらない、代理店、クリエイティブチーム、業務委託者、プロダクトチーム、そしてサービス業の方々。
- 自分たちの本当の納品工程と引き継ぎの上に築いたプロジェクトモデル
- ステータス会議を置き換える、進行中の仕事を見るビュー
- 納品プロセスの変化に合わせて作り替えられるシステム
多くのチームがプロジェクト管理ツールを試したものの、結局は表計算とチャットに戻っています。問題はツールそのものではなく、合っていなかったことです。汎用のプロジェクトツールは、タスクを列に並べるという一つの型を押しつけますが、あなたの納品にはあなた自身の型があります。あなたの工程、あなたの承認、あなたの引き継ぎです。ツールが実際の届け方と噛み合わないと、更新することが無駄な作業になり、やがて静かに使われなくなります。このガイドが扱うのは、噛み合うものを作って定着させる方法です。
汎用の型、たいていはタスクが列を移動していく形を押しつけてくるからです。一方であなたの納品には、そこに収まらない固有の工程、承認、引き継ぎがあります。そのため人々は管理側のためにツールを維持するだけになり、本当の調整はチャットで進み、ツールの情報は古くなり、見るべき場所ではなく、更新すべきもう一つの場所になってしまいます。プロジェクトシステムが定着するのは、その工程があなたの工程そのもので、あなた自身の言葉で表されているときだけです。
分かりやすい兆候があります。ツールはあるプロジェクトを「進行中」と表示しているのに、誰もが本当は「クライアントの素材待ち」だと分かっている、という状態です。ツールにはその名前がありません。欠けている状態の一つひとつが小さな嘘であり、小さな嘘だらけのボードは誰も信じないので、誰も最新に保たなくなります。直し方は、もっと規律を求めることではありません。工程が実際のものと一致するシステム、しかも仕事が本当に止まる、あの気まずい待ち状態まで含めたシステムです。
だからこそ、自分たちの納品を言葉にしてその周りにシステムを作るほうが、他人のテンプレートを設定するよりも優れています。工程、承認の地点、引き継ぎこそが成果物であり、それはあなたの働き方に固有のものだからです。
どんなボードを作るよりも先に、最近のいくつかのプロジェクトが開始から完了まで実際にどう動いたかを、どこで止まったかも含めて再現してください。あなたは自分たちの納品の型を取り出そうとしているのです。
あるデザインスタジオは、「クライアントに送付済み」と「クライアントが返信済み」のあいだの隙間でいつもプロジェクトを見失っていました。そこでは物事が何日も、担当者もなく、見えるタイマーもないまま放置されていたのです。正直にモデル化したところ、彼らの流れには八つの工程があり、そのうち三つが待ち状態でした。そして決め手となった機能は、待ち状態をタイマー付きで見えるようにしただけのことでした。「クライアントのフィードバック待ち」で一週間止まったプロジェクトが、汎用の「進行中」の列に隠れる代わりに、赤く表示されるようになったのです。ほかには何も変えていないのに、納期どおりの納品が跳ね上がりました。
プロジェクトツールは、ほかのほとんどの種類より速く肥大化します。時間の記録、請求、リソース計画、クライアントポータル、依存関係。最初のバージョンは、仕事を見えるようにし、動かし続けるための、最小のものです。
繰り返されるステータス会議が存在するのは、状態がどこにも見えないからです。良いシステムなら示してくれるはずのことを、人々は口に出して言うために集まっているのです。プロジェクトシステムの目的は、その会議を不要にすることであって、会議で話題にするためのツールを増やすことではありません。
誰でも一つのビューを開けば、すべてのプロジェクト、その工程、その担当者、そしてどれだけの期間放置されているかが見える。そうなったとき、そこにたどり着いています。タイマー付きの待ち工程は、静かな停滞を見える停滞に変えます。「クライアントレビュー」に八日間あるプロジェクトはひとりでに浮かび上がり、会話は発見ではなく決定になります。ボードが信頼され、最新であるとき、会議は本当に議論が必要な数点にまで縮み、しばしば消えてなくなります。
システムを信頼され続けるものに保てるかどうかは、自分でそれを所有することから生まれる二つのことにかかっています。ボードが現実と一致するのは、そこにある工程が本当の工程だからであり、一致し続けるのは、納品が変わったときに自分で工程を変えられるからです。自分たちのワークフローを軸に作られ、エンジニアリングのチケットなしに作り替えられるプロジェクトシステムこそ、チームが最新に保ち続けるものです。それがようやく、仕事についての本当のことを語っているからです。
ツールが汎用の型、たいていはタスクを列に並べる形を押しつけてきて、それがあなたの本当の納品工程、承認、引き継ぎに一致しないからです。人々は管理側のためにそれを維持し、本当の調整はチャットに残るので、情報が古くなります。システムが定着するのは、その工程が仕事が本当に止まる待ち状態も含めた、あなたの実際の工程であるときです。
最近のいくつかのプロジェクトが実際にどう動いたかを、どこで止まったかも含めて再現し、本当の工程をあなた自身の言葉で名付けてください。ブリーフ済み、デザイン中、クライアントレビュー、修正、承認済み、といった具合です。とりわけ大切なのは「クライアントのフィードバック待ち」のような待ち状態を含めることです。汎用ツールでは、まさにそこに仕事が隠れるからです。
一つの明確な本当の工程に置かれたプロジェクト、すべてのプロジェクトと工程の担当者、進行中の全作業を工程ごとに見る一つのビュー、そして次の担当者がチャットのメッセージなしに分かるための明示された引き継ぎです。時間の記録、請求、依存関係は、すべて第二バージョンまで待てます。
おおむね、はい。会議が存在するのは、状態がどこにも見えないからです。信頼できる一つのビューが、すべてのプロジェクト、その工程、その担当者、そしてどれだけ放置されているかを、待ち工程のタイマー付きで示すとき、会議の発見の部分は消え、本当の決定だけが残ります。ボードは最新で真実でなければならず、それは自分で所有し形づくることから生まれます。