タスクが次から次と湧いていくる現象に名前をつけたい


兎角、プロジェクトが軌道に乗ってくると次から次とやらないといけないことが湧いてくるように思うけれど、現実は、目の前にまで仕事がやってくるまで真面目にそのタスクのことを考えていないからなんだけれどね。こういった事象に名前をつけるとしたらどんな名前がいいのだろう。


だんだんと、時間に追われるように、今日の午後のレビューの資料をまとめないと、明後日の定例の資料を準備しないと、となってくるともう、資料の出来具合はだんだんとやっつけになってくる。


まだ、メンバが資料を作ってプロジェクトマネージャがその資料を内部レビューしている余裕があれば少なくともプロジェクトマネージャの目線でのアウトプットの品質レベルは確保できるけれど、その指摘の修正をプロジェクトマネージャがやり始めると途端にプロジェクトマネージャの時間が許す限り、という制約条件が降りてくるから途端にアウトプットの品質が下がってしまう。


その結果突っ込みどころ満載の資料が出て行ってしまう。


そういった質には敏感なんですよ。見る方は。見た目でわかる間違い、てにをは、日本語としての欠如。みんなお勉強ができてきたからそうした質の資料からプロジェクトの状況やメンバのパフォーマンスも推察してしまう。このプロジェクトのメンバは大丈夫かなぁと目に見える失敗が露呈するまでは口に出したりしないけれど。


資料の主旨が明らかであること
資料の内容が報告か、承認を得ようとしているのか、選択肢を判断してもらうのか、資料の主旨にあった構成となっているかを見直そう。


1ページ目のタイトルから最後のページの結論につながっているかを確認しよう。2ページ以降は経緯や前提から要旨を押さえているかを確認しよう。


事実と推測を分けよう
事実は事実として議論したいテーマの議論を支えるように使おう。他の場の結論、第3者の資料、定量的な根拠を使おう。そうした議論を支える情報と推測は分けて論じよう。推察はテーマの範疇をはみ出したりしないように。議論が発散してしまうから。


シナリオとして成立させよう
資料のシナリオが成立しているかを確認しよう。議論の開始からきちんと結論に結びついているかを確認しよう。


曖昧な表現を排除しよう
曖昧な表現があったらそれは別の言葉に置き換えよう。システムを作っているなら、最終的にはコードにしなければならないのだから、コードで取り扱える情報になっていないといけない。正常の振る舞いばかり考えず、正常でない場合の振る舞いをきちんとフォローしよう。


フォロー、ほら曖昧だ。正常以外のケースは取り扱わないのか、異常処理するのか、異常処理とはどんな振る舞いかを明示的に書こう。もちろん、資料の工程レベルで方向性までにするか、具体的な仕様として書くかは資料の性質に合わせよう。


リミットを設けておくこと
忘れてはいけないのは、決まっているスケジュールから逆算して少なくとも半日単位くらいで前述してきたことを確認するステップをスケジュールに入れてしまおう。ここまでにやるために、とスケジュールにリミットを設けることが大事なんだ。


繰り返せばそれもプロジェクトのリズムになるのだから。