怒っても設計書やプログラムができるわけではない
寧ろ、酷い内容の設計書やプログラムしかできない、ということを経験的に知っているのではないかと思うのですが、不思議と立場が変わると怒る人もいれば粘着して責める人もいて、どうかなぁと。
提案書でも設計書でもソースコードでもできない人というか、進捗しない人にはそれなりの理由があるものです。
・コミュニケーション不足
・スキルレベル不足
・スキルミスマッチ
コミュニケーション不足は、タスクをオーダする側にも原因があることが多いし、タスクをやる側に自分から不確かな状況を詰めに行くことをしないという受け身のような原因があったりします。どっちも毎日見かける日常の風景ですが、アウトプットが期日までに出てこないという結果からタスクをやる側が一方的に攻められる構図が出来上がるのが様式美と成っています。
スキルレベル不足は、タスクをやる側のスキルは持っているけれどタスクのレベルが高いので結果がでないという形で露呈するケースです。社内の若手に１ステップ高いタスクを与えて育てよう、という前向きなアサインならタスクのアサイン時点でギャップがあることを認識しているので生暖かい視線で見守ってあげるしいざというときを初めから考えているものです。
それが、そうじゃない場合、上流工程の経験値が多いとか専門性を持っているとかでプロジェクトにjoinしているときにアウトプットがでないとなるとことは深刻化するわけです。だって、実体のスキルと比べて過大に広告していたようなものですから。こういったケースはアサイン方針を見直すか（お勧めできません）か入れ替える（早急に手配をしてください）しか方法はありません。
スキルミスマッチは、明らかにアサイン側の見極め誤りです。何か暗黙で前提を置いていてそれを鵜呑みにしている状態です。先の売り込みを自分の目で見極めもせずに信じでいることがおおいです。チームメンバ数が多かったりすると割と見抜けなかったりします。なぜなら、周りのメンバがカバーするようにできるメンバにアサインを寄せたり、フォローしあったりするからです。
このようなケースは全体が遅れ始めるときに原因を追究していくことでやっと実情を解ったり知ったりすることになったりしますがそのときはすでに致命的なところまで来ていることがおおいです。メンバがそれまでにカバーをしていたりするとそれまでの負荷が蓄積されていて身体的にもメンタル的にも閾値を超えてていることがおおいからです。
さて、話を戻して。
怒ったって設計書やソースコードはできるわけではないし、なんとかできたとしても相当に鞭が入っているはずで、そんなアウトプットは作ったメンバの意思なんて微塵もありません。鞭を入れた人の意思しかないんです。
そのアウトプットの品質は…言わなくてもいいですよね。
わたしたちは何ができるのでしょうか。
入れ替えのできないリソースや育てるリソースなら、そのリソースが生きる使い方を考えなければなりません。タスクをさらに分解する。チェックポイントのサイクルを短くする、標準化を進める、標準化されたプロセスで成功体験を積ませる。
入れ替えることができるなら、他のメンバのためにも、プロジェクトのためにも、そのメンバのためにもいち早く入れ替えるように手配をしたほうが良いです。
どちらにしても怒るイベントは発生する余地はないです。怒っている暇があったら、もっと前に放置できると確信できるサイクルに到達するまでポーリングをかけてモニタリングしておくのです。
