任せてしまうと終わらないエンジニアと早く結果を見せてくれるができの悪いエンジニアのどちらを選べば良いか
執筆のスピード（出来高）について
これは単なる感想というか現状の自分に対する心理的な壁というか、もしくはあの頃と違ってやりたいことが増えすぎてリソースを集中できない状態を表しているのではないかと思えなくもないのであるのだが。
書くことの出来高については、あるケースで日別の出来高を記録していたことがある。
それを改めて見直すと、もうあのときの出来高をアウトプットすることは無理なのではないかと思えてならない。その点だけで言えば、やりたいことにリソースを全振りして集中的に没頭するというのはものすごく成果として残る。
今はやりたいことが山積みで結果的にリソースを成果が出るように配分できておらず、タスクが積み上がっている。
書くことについては、誰もがわかっていることであるが頭の中で悶々と考える時間があれば、ネットを巡回したりTL警備員をやっている時間があるならブラウザを閉じて原稿を書く行動を自分に取らせればいい。
これが一番難しい。
スピードと品質
自分としては、書く際に品質を求めてはいけないと思っている。最優先しなければならないことは、とにかく書ききることである。どんなに駄文であっても書ききる。
間違っても、前日書いたところを自分で添削を始めてはいけない。添削を始めると前々日の書いた箇所も気になってくる。当然、もっと前から読み直してしまう。
これも過去のエントリに何度か書いているが、進捗の出ないエンジニアから進捗を引き出すためには、タスクを1時間や30分のサイズに小さく切り出して、一つひとつ終わらせる成功体験と実際の実績を積み上げていくことを伴走するようにサポートをすることが必要だと主張してきている。
一方、とにかく早く、でもポカミスを仕込んでアウトプットするエンジニア。早く成果を見せる（終わっていないが）ことは、早く間違いを見つけられるという可能性を持っているということだ。業務処理能力は高いが予測できないエラーを含んでいる。
任せてしまうと終わらないエンジニアと早く結果を見せてくれるができの悪いエンジニア。
今必要とされるエンジニア
今必要とされるエンジニアは早く結果を出すエンジニア一択だ。任せてしまうと終わらないエンジニアと早く結果を見せてくれるができの悪いエンジニアならどちらが現場で必要とされるか。
見方を変えよう。
任せてしまうと終わらないエンジニアは、タスクを小さく作業員として扱えば結果が出る可能性がある。あくまでも可能性。
早く結果を出してくれるができの悪いエンジニアの方は、少しマシだ。なぜなら、開発プロセスや開発環境の中で出来の悪いポカを避ける仕組みを入れれば出来の悪いものをアウトプット前に排除できる可能性がある。
やはり、できたと言い切れることは最大の魅力だ。
なぜなら早いサイクルでアウトプットを継続することに耐えられるエンジニアが求められるからである。
実際、今の自分の担当部門のエンジニアとして欲しい方は、後者のエンジニアである。
そう判断する背景
結局、マネージャでもプロマネでもアウトプットに対して要求品質を備えなければ完了としないしできない。要求品質を備えていなければ、それが露呈した瞬間、いくら善良に注意義務を果たしていたとしても、リカバリをしなければならないことに巻き込まれることを知っているからだ。
後工程になればなるほど、当初から実現しておけば安価に対応できた要求品質の1000倍も労力を必要であることも経験的に知っている。
だからQCDがいくらトレードオフだと言っても、品質は固定化されトレードオフされない。だからこそ、CDで歪むのであるが、それをどうやり切るか（スコープのシュリンクを含め）。
任せてしまうと終わらないエンジニアと早く結果を見せてくれるができの悪いエンジニアとは関係のない、次元の違う話に読めるかもしれないが、それは違う。
エンジニアのアウトプットの積み上げがプロジェクトのアウトプットの結果なのだから。
