二人の管理職が机を並べて働いていました。
一人はできるさん、もう一人は残念さんと言いました。
二人は全然違うタイプですが、同じぐらい熱心に案件を気にかけ、同じぐらいの熱量を持って仕事に取り組んでいました。
できるさんは、案件に着手する時は部下に丁寧に案件の内容について説明し、必要な人や部材を先回りして調達し、環境を作ることに専念していました。環境を作った後はあまり干渉せず、部下の手法や判断を尊重していました。部下はどういった手法が適切か、どうやったら安全にリリースできるかを考えるようになりました。
残念さんは、案件の着手段階では客や営業からのメールを部下に転送し、案件を理解した部下が人の増員や部材の調達を依頼してきたら手配していました。反面、アウトプットについては細かくチェックを入れて、コードやお客向けの資料は何度もレビューを行っていました。部下たちはどうやったら残念さんの考えるアウトプットのイメージに沿えるかを考えるようになりました。
二人とも打ち合わせには積極的に同席していました。
できるさんは打ち合わせの場では基本的に話を聞いているだけでした。判断を求められたり、関係者間で認識にズレがある時などは発言していましたが、同席することで部下に報告の手間や時間を取らせないようにしようと考えているようです。
残念さんは打ち合わせの場で仕様やアウトプットのイメージをがっちり確認し、手戻りを避けようと一生懸命でした。
打ち合わせの前後にはメンバーと認識合わせを必ず行い、よりよい案件進行を部下とともに模索しようと考えているようです。
ある日二人の部下が躓きました。
できるさんの部下の案件は、リリースしようとしたときテスト環境では問題なく動いていたアプリが本番環境で動きませんでした。
お客さんは、再現環境を作ったり、ベンダーのサポートを呼ぶなどして早急に問題解決を図るよう求めてきましたが、できるさんはログの解析や、テスト環境と本番環境の違いの洗い出しなど、机上調査を優先することを主張しました。また、どのような手法でも時間は必要になると説明しました。
机上調査から被疑部位が絞られてきたところで再現環境を構築して、問題の再現と回避方法の確認が行われました。リトライが行われ、今度はうまく行きました。当初予想されたよりも早く解決できました。
ただ、お客さんの目には対応の初動が遅いと映ってしまったようです。
残念さんの部下は、あるタイミングでお客さんと自分たちの間で仕様に関する認識がズレていることに気が付きました。
急ぎお客さんに相談し、修正を加えていくことになりました。お客さんはスケジュールを気にしています。残念さんはなんとか当初のスケジュールを守れるよう努力することを約束しましたが、同時に現実的に実現できそうなリスケ案も提示しました。
残念さんは自分も案件に加わるとともに人も増やしましたが、混乱を助長しただけで、もとからのメンバーたちが深夜休日に出社するなどしてなんとか終わらせたのは、リスケされた完了日をだいぶ過ぎてからのことでした。
ただ、残念さんは自分も作業に加わっていることや、人を増やしていることをアピールするなど、状況をこまめに報告していたので、お客さんの印象は悪くなかったようです。
さらっと読んだだけだけど、 増田は、できるさんタイプでも、残念さんタイプでも、どちらもリストラされるじゃないか、と言いたいのかもしれないけど、 2人の上司のスキル分析が...