任せてしまうと終わらないエンジニアが終わらせるとしたら
私は「任せてしまうと終わらないエンジニア」だから耳がいたい https://t.co/OqSv3865SG
— こばせ🥴 (@kobase555) November 2, 2019
想像するに、全く、何もが終わっていないということはないと思う。もし、渡したタスクが全く、ひとつも終わっていないとするならば、今もエンジニアとして生き残れるほど寛容ではないはずだ。
という仮説が成り立つとするならば、任せられた途中までは終わっているか、任せられて期待されている納期に完了基準に到達していないの途中のどちらかに違いない。
任せる→終わっていない→エンジニアとして続けられていない→このルートはない
＋→途中までは終わっている→Aルート
＋→納期に完了基準を満たしていない→Bルート
Aルート
終わらないのは、期待されたこととやる側のエンジニアの次のギャップだろう。
- 双方の作業ボリュームが任せる方＜エンジニアになっている
- 力量が合っていない
- 合意した仕様に検討していないことが見つかった
- 作業期間に割り込みが入った、入れた
- 正味の作業期間に終わらせることを最優先にしなかった
これらは、作業自体の難易度の見誤り、力量の見誤り、仕様の検討もれ、優先順位の謝り、差し込みによる納期の再設定忘れが原因である。
Bルート
このルートは納期に間に合ったが内容が伴っていない。
- 判断基準がチームに統一しバリューとして存在しない
- エンジニアの価値判断を基準としてチームに合わせていない
- チームの作業プロセスが存在しない
- やってから必要に応じてルールを決めればいいと思っている
これらは、エンジニアがルールを守っていないか、チームにルールや意思決定の基準がないために起きる。
対策
AルートもBルートも反対のことをやればいい。これは、任せてしまうと終わらないエンジニアに限ったことではないことに気づくだろう。
そういうこと。
