物事を依頼するときは最終的なアクションを明確に書いてくれ！
PjMは依頼することが仕事のひとつだ。
社内のエンジニアであったり、お客さんであったり、ひたすら「これお願いします」を日々やっている。
プロジェクトが大きくなると「この依頼事項は終わってるんだっけ？」とわからなくなることが多々ある。いや、多々あってはいけないんだけどさ。
以前、課題には「なぜ」を書いてくれと記事にしたが、今回は依頼時には明確な完了条件を書いてくれという話をする。
そのタスクはどうなったら完了なのか、ちゃんと書いてる？
Backlogのようなツールでもメールでも、依頼の際は具体的な完了条件が明記されていることが望ましい。
❌ BAD : この資料を作ってください。
🟢 GOOD : この資料を作ってください。作成後、資料の保管先を記載して、担当者を私に変更してください。レビュー後完了とします。
❌ BAD : このバグ対応をお願いします。
🟢 GOOD : このバグ対応をお願いします。PRのレビュー後マージされたら完了させてください。
❌ BAD : 対応方針を決めてください。
🟢 GOOD : 対応方針を決めてください。決まった対応方針を記載し、打ち合わせの議事録を添付して、担当者を私に変更してください。レビュー後完了とします。
ここの共通認識が芽生えないとやりっぱなしのタスクが発生する。対応者も次に取るべき行動が見えず重要な確認が漏れる。言っておくが、いい加減な依頼で問題が発生した際の非は100％依頼者にある。
新入社員が「気が利かない」「ちゃんと完了報告を誰々にしろ」なんて言われる光景を目にしてきたが、それは間違いだ。依頼者が果たすべき義務を果たしていないだけだ。
前提として、依頼者は完了までに至るフローを描けているだろうか？
まずはそこからだ。どうなったら完了するのかを依頼時に明確に書けないのであればその状況で依頼してはいけない。完了までのフローが描けないのは依頼事項（タスク）の粒度が不適切、もしくは前提条件が整理されていないからだ。典型的な悪いケースを書き出してみる。
依頼事項の粒度が大きすぎる
完了条件もしくは完了の決定者が不明
依頼事項の粒度が大きすぎる
終わらない依頼事項の典型的な例だ。
一例を挙げると「XXなプログラムを完成させる」みたいな一見普通っぽいタスクだが、細分化すると「実装」「テスト」「レビュー」「顧客確認」等、数多くの要素を孕んでいる。粒度が大きすぎると完了までの道筋が複雑になる。
最小の粒度とタスクとして切り出さなければいけない。実装すれば実装タスクは完了。後の工程で実装に問題があれば、修正を新たな依頼事項としてタスク化すればよい。
完了条件もしくは完了の決定者が不明
「顧客用の見やすい資料を作って下さい」みたいな依頼事項は最悪だ。
見やすいとは、タイポグラフィの話なのか？色弱の方に配慮した色使いの話なのか？もっとグラフを使ってくれなのか？何を満たせばよいのかが不明だ。そして、承認者が顧客なのか社内担当者なのかも不明だ。
完了するために満たすべき条件を定義し、承認者を明らかにする必要がある。もし依頼者が把握していなければ大問題だ。完了の定義をまず確認しろ！わかっているならきちんと書け！
対応者を迷わせないように依頼しろ！
タスクというものは基本的に以下の要素で構成されている。多分。。。
誰が
いつまでに
こんな作業をして
作業が終わったらこのアクションを実施して
完了条件を満たしたら完了とする
対応者は完了条件を満たすように作業を行い、指定されたアクションを経て完了に向かう。この要素は欠けてはいけない。欠けた場合、対応者が迷うことになる。迷わせてはいけない。
しかし、4,5についてはなぜか軽視されて明確に書かれない。そんで、できてないじゃないか！と怒られる。完了条件とかちゃんと定義されていないのに怒られるのは非常に困る。
4の作業後のアクションで圧倒的に多いのは「終わったら教えて」である。
教えてってなんだよ！フワッとしすぎだろ！あなたに教えたら他の人には報告しなくていいのかよ？報告方法は？報告時に必要な資料は？とか、こういうのはものすごく困る。
だから誰が対応しても迷うことのないように最終的なアクションを書いてほしい。僕は心からそれを望んでいる。継続的な開発だと、いちいち依頼事項に書いていられないので、プロジェクトのルールとして明文化しておけばいい。
対お客さんだったら、NGだったら返事くださいとか、OKの場合はXX NGの場合はXXして下さいって縛った方がいい。そっちの方が先方は対応を考える必要が減り楽になる。
先輩が言ってたが、ルールで縛ることで楽になる。まさにそうだ。
まあ、詳しくアクションを書いても守ってくれない人もいるけどさ。
でもちゃんとやろうぜって話でした。
書いてて思ったけど僕が神経質なだけかもしれない。だが、きちっとした方がくだらないミスは減るよ。マジで。
この記事は「プロジェクトマネジメントとか組織作りとか Advent Calendar 2022」の12月7日分として書きました。僕が普段考えていることを言語化しています。
この記事が気に入ったらサポートをしてみませんか？