ToDoリストって使っている人多いですよね。専用のアプリも沢山出ています。
自分だけのToDoならまぁ問題がないのですが、仕事上チームでToDo管理をしている人はいませんか？
そして、そのチームのToDoは上手く回ってないのでは無いでしょうか？
その様なツールも沢山あると思います。
ただ、僕が仕事上経験してきて、プロジェクト・チームで使うToDoリストはある項目が抜けているために失敗する事が多々ありました。
Redmineのようなインシデントツールを作ってウォッチャーを沢山おけば問題は解決しますが、ウォッチャーが多くなるとスパムメールのようになってしまい、逆に大事な要件を見落としがちです。
さて、あなたは佐藤さんにXXと言うプログラムのバグ（バグNo.436）を明後日までに対応してほしく共用ToDo(主にExcelを想定)に次のように書きました。
起票日：2016/1/26
記載者：山田
対応者：佐藤
内容：バグNo.436の対策（プログラム名XX）
期限：2016/1/28
重要度：中
Status：新規
こんな感じでしょうか？
これだと、全員の頭が凄くよくない限り失敗します。
何が足りないのでしょう？
朝、佐藤さんが出社して、共用のToDoファイルを開き、フィルターで対応者＝’佐藤’になっている行を検索します。
バグNo.436の対策（プログラム名XX）と言うToDoが出てきました。
佐藤さんはバグ表のNo.436を見て不具合の内容を確認して、プログラムXXを直します。
終わったので、佐藤さんは、Statusを完了にしてファイルを保存します。
おわり。
：
ではないんですよね。山田さんは佐藤さんがプログラムを直したらそのスクリーンショットを取って、正しく治っている事をお客様の田中さんに送ってほしかったのです。
山田さんも常にToDoを更新している訳ではありません。佐藤さんはすでにこのToDoはクローズしたとしてステータスを変更します。
よくExcelとかであるのが、「条件付き書式」です。Statusが完了になったら、行が灰色になるとか、期限を過ぎたら行が赤くなるとか。
さて、期限の1/28になり、お客様の田中さんから山田さんへ連絡がきます。「No.436のバグって解決したんですか？」
山田さんは、ToDoリストを確認し、佐藤さんに「No.436のバグって治ってる？」と聞きました。
佐藤さんはNo.436のバグ表をみながら、「あぁ、それなら速攻です。1/26には終わってStatus：完了ですよ。」とそのまま言いました。
ここで、認識に齟齬が出ます。山田さんがきちんと最後まで書いておけばよかったですし、佐藤さんが対応した際に、起票者の山田さんに「バグ治りましたよ。」と一言を声をかけてもよかったのです。
これが失敗するパターンのコミュニケーションロスです。
これを解決する方法があります。
内容をきちんと細かく書け？
ちょっと違います。
これは、一つ項目に「完了条件」と言うフィールドを追加する事です。
先ほどのToDoリストに「完了条件」を付けると下記のようになります。
起票日：2016/1/26
記載者：山田
対応者：佐藤
内容：バグNo.436の対策（プログラム名XX）
期限：2016/1/28
重要度：中
完了条件：修正エビデンスを取得し、田中さんにメール
Status：新規
これで、佐藤さんは山田さんがいなくてもバグNo.436を直した後に修正スクリーンショットを取って田中さんにメールを出したでしょう。
自分用のToDoは内容が「何を持って完了するか」がわかっていると思います。
でも、他人に依頼する場合。それもToDoリストのような形式で文字で連絡する場合、案外依頼される側と依頼する側の最終目的が違っていたりするんですよ。
これは経験上絶対です。
もちろん、全員のスキルが高ければ次の行動を自律的に起こすかもしれませんが、ToDoリストはできれば自分の分はさっさと片づけたいものです。書いてある内容を解決したから完了で良いではないか！となってしまいます。
たとえば、新人に日報を書くと言うタスクを依頼しても、新人は日報を書いて終わりです。本来は、書いたらメールで上長に報告して欲しかったのです。
案外、「当たり前だろ、おい。」って言うToDoも人によっては違ったりします。
難しいのは承認・レビュー系です。
「新規プログラムの工数見積もり」とあっても、見積もれば終わりなのか、見積もった結果を営業に連絡するのか？見積もりが正しいか上長承認をもらうか？
など、「何を持ってこの作業が（誰が見ても）終わりか。」と言う事を周知する為に、この完了条件は必要なのです。
難しい話しちゃいましたね。もし、思い当たる節がありましたら、ぜひ取り入れてみてください。
