後出しジャンケンに負ける時

開発の仕事を行う時にはソースコードだけではなく、仕様書、バグレポート、再発防止策まで様々な資料をまとめる必要がある。そんな情報は、通常「社内ヒエラルキーの上位の人」が確認するわけで、それはそれで組織として必要なプロセスだし、記載の問題を指摘してくれるなら有益なことだと思う。

しかしながら、そのような確認作業が現場担当者の反感を買うこともある。その一例。

確認レベルが人によって異なる
あるリーダがOKと言ったのに、同じ記載を見た隣のリーダはNGと判断してしまう。部門としての統一基準が無く、確認する人の思い込みや気分次第で判断はバラバラ。両者で認識合わせをして現場の混乱を招かないようにして欲しいところだが、「あの人にはあの人の考えが有るから」等という非合理的な言い訳がなぜか平気で通用してしまう。
資料記載の基準が存在しない
特に明確な基準が無いので、今までの資料の記載内容に合わせる形で追記したら、分かりにくいから「はダメ」と言う。情報としてアレも書いておけ、コレも書けという指示は分かるとしても、そのような記載を求める理由が明確に存在するのなら、事前に教えてもらいたいものだ。

何も情報が無いから、担当者は手探りで作業を進めなければならない。明確な「判断基準」や「標準的な書き方」をガイドラインとして事前にまとめておけば、担当者はそれに従って資料を作れるし、余計な手戻り作業が発生しなくて済む。何度も確認と再修正を繰り返す無益なループから抜け出せるはずだ。

開発現場の作業がスムーズに進められるようにお膳立てをするのがリーダの役目だと思うのだが、出された情報に対して場当たり的な判断を下す「後出しジャンケン」型リーダに限って、「判断を下すのは自分の仕事」と頑なに思い込んでいるので手に負えない。ホワイトカラーの生産性の低さとか、開発現場のモチベーション低下というものは、実はそんなお粗末な開発プロセスに一因があるような気がしている。