QCDはトレードオフする。という話があります。
Quality、Cost、Deliveryは一つ上げると他が下がるみたいな話。
エンジニアにとって特に重要な要素としてはQとDなわけですが、世の中に案外QとDを調節できる人は少ないです。
私もぶっちゃけ得意じゃないです。
なぜかと言うとどこらへんまでQを重視／軽視していいのか、どこらへんまでDを重視／軽視していいのかという温度感を学ぶのが非常に難しいからです。
一番良いのは新規立ち上げのベンチャー企業でバグだらけでも構わないシステムを最速で出す経験と、大企業で人名に関わるようなクリティカルなシステムを開発したり、その中間のいくつかのパターンのプロジェクトを経験しないとわからないからです。
例えばそういったQとDの組み合わせパターンがナレッジとしてまとめられていたとしても、各々が受けいれること自体が非常に難しいのです。
なぜならある組織においては固定のQとDの組み合わせさえあれば十分だからです。ベンチャーならベンチャーのQとD、大企業なら大企業のQとDさえあればよく、それ以外を唱える者を異端者として糾弾したほうが手っ取り早いのです。
特定のQとDがあり、それを元に「どのようにそれ（より重視する方）を実現するか」という点に重きをおいてキャリア構築をするとなると、別パターンのQとDの存在は否定したくなります。ひょっとしたら自分のやり方は間違っているのではないか？と思いなから仕事するのは精神的にかなりきついです。
自分の中の相場（品質はこのくらい、速度はこのくらいが普通）というのを信じて、それ以上もそれ以下も「おかしい」と糾弾するのは、その組織で生きるために戦略として間違ってはいないと思います。
気をつけなければならないのは採用者です。
今の事業にとって、どのQとDの相場感覚を持った人が必要なのかよく考えなければなりません。間違うと非常に厄介なことになります。
特に品質過剰においてそれが顕著ですから、採用者のやるべきことは「納期に対するモチベーション」だと思います。
あるいはフリーランスであれば複数のQとDの組み合わせを駆使しないと行けないシーンが有るのかもしれません。
とはいえそんな器用に組み合わせて仕事をしている人なんてほとんど見たことがないですけどね。
私はそうなりたいですが、やはり億劫なので、「自分がベンチャー寄りに偏っている」というあたりを認識する程度に留めています。
しかしそれだけでも採用者には非常に喜ばれる事が多いです（そして仕事につながる）
