優先順位をつける（プロジェクトの人間学）

【この「プロジェクトの人間学」投稿シリーズは（後略）　初回投稿：はじめに（プロジェクトの人間学）】

トラブルやタスクに優先順位をつけないプロジェクトはない。優先順位を付けてどうするか。何もしやしない。せいぜいその優先順位が適切がどうかを議論するだけである。何のアクションにも結び付かない。いやむしろ無駄な議論が生まれるだけ、その優先付け作業が無駄である。最初から優先付けしなければ適切な優先付け度合は何かという議論をせずに済む。

重要度と優先度が混同されることも多い。優先度は重要度とは違う。重要度は気分の問題であり優先度は抜き差しならぬ選択である。何のために優先付けをするのか。それは限られたリソースを重要なタスクやトラブルに投入するためである。どういうことか。すなわち優先順位の低いタスクは切り捨て、思い切って他の課題に人をあてる。重要でないトラブルは割り切る。その決断をするため優先順位を付けるのである。

最近は「トリアージ」という言葉が使われている。トリアージとは「負傷者を重症度、緊急度などによって分類し、治療や搬送の優先順位を決める」という医療用語である。全てを救おうとして全てを死なせてしまう。それが普通のプロジェクトで発生している事態であろう。結局は全部執拗に追い求めるのである。しっかりしたマネジメントであればトリアージという概念を利用できるかもしれないが、筆者の感覚からすればほとんど望み薄な気がしないでもない。プロジェクトが緊急事態に陥るまでは、普通マネジメントがタスクを切り捨てることはない。

成果を産まないタスクから手を引き成果を最大限にするタスクにリソースを投入する。優先付けはいわばプロジェクトのリストラクチャリングの基礎とならねばならない。なぜそれができないのか。プロジェクトのリソースが金銭とは違って目に見えないからである。金銭＝人月として数値化してもその生産性が分からない。人によって生産性が余りにも違う。個人の生産性が５倍違う（尺度は時間）などざらである。また人を投入したからといって楽になるとは限らない。むしろ逆で投入した当初はオーバーヘッドが増えるだけで生産性は却って落ちるだけである。だから正確な作業見積が難しい。「なあに、ちょっと土日出勤すれば追い付きますよか」若手のお気楽な楽観論は２度目の土日出勤でもろくも崩壊してしまう。

金銭や人月よりも貴重な時間というリソースが、プロジェクトでは忘れられる傾向にある。１日１６時間は働けますよ。徹夜すれば何とかなると思います。残業しても休日出勤しても生産性は上がらない。文字通り少しも上がらない。なぜなら残業してもプレッシャーを与えても頭はよくならないし、集中力は残業すればするほど減る一方だからである。休日出勤している社員のモチベーションや働き振りを見てみたらよい。ネットサーフィンに時間を潰してないか。だらだらとおしゃべりをしていないか。残念ながらマネジメント層にも時間を忘れる傾向はある。夜遅くまで働くメンバーを見て、時間はふんだんにある、と思い込んでしまうのだ。

時間が貴重で限られたリソースであるという認識がなければ、そのリソースをどうして慎重に配分するかという問題意識もないであろう。ましてや、リソース配分のために障害を割り切ったり、タスクを削るなどという考えは出てこない。ただし、それも実際にプロジェクトが火を噴くまでは、の話ではあるが。

それをしなかったとしてどのような結果になるかを考える。優先度が低い作業を切り捨てるに当たって必要な考え方である。それが分からないから、不安だ。確かに先のことは分からない。だが不安とタスクは切り離して考えなければならない。さもなければリスクは少ないにも関わらず、そのリスクに対応するような作業が発生しかねない。例えば意味もなく頻繁に取得するバックアップなど。落ち着いて考えよう。不安はその対象を具体化すれば消える。不安とはそういうものである。あるいは不安は究極的には死の不安である。ハイデガーが言った。第二次世界大戦という背景はあるが、あながち的を外してはいないように思える。不安にとらわれる必要はない。それをしなかったとしてどうなるか。システムに対して、どういう時に、どのような影響が発生するか。例えばシステムが止まるか。あるいは次に保守するメンバが困るのか。システムが止まるのであれば当然対応しなければならない。しかしそうでないならば、作業を行うかどうか、踏みとどまる値打ちがある。帰宅して子供と食事を取って寝るのとどちらがよいか。一度検討してみてもよいのではないだろうか。

これまで何の疑念もなく行ってきた作業や手順についても、再度「今これを行わなかったとしてどうなるのか、検討してみるのは悪くない。その際、最初の認識を変えたがらない人間の習性に留意すべきである。もはや「おまじない化」している場合がある。ロジックで理詰めで動くように思われるかもしれないが、実はIT業界ではよくある話だ。以前この手順でうまく行ったから。必要ではないが念の為。そういう作業が多いのもこの業界の特徴である。実はどっぷりと呪術的な慣習に浸っているのである。

このような実績のある作業や設計をひっくり返すのは極めて困難である。敢えてやらない理由を見つけ（これは難しくない）、周りを説得する（これが大変）、こちらの方が体力がかかる。「こんな作業いらないっすよ」「いや昔この手順で事前に障害が食い止められたことがある」。ミドルウェアのバージョンも違う。開発環境も違う。だが否定はできない。ぶつぶつ言わずに実施してしまった方が早い、そういうことも多い。ある作業が実績化されそうな場合（繰り返される可能性がある場合）無駄な作業をなるべく省く努力が重要である。