いわゆる無知の知ってやつを別の言い回しにしたやつ。
ことエンジニアにおいては、特定のチーム（これはエンジニアだけでなくBizも含めたチーム）において、「これってできる？」みたいな質問を（なんとなく日々の会話の中で）されたとき、実質的に最後の番人になっていることが多いと思う。
要はその回答内容次第で意思決定が完了してしまうということ。
このとき、大半の人は「できないことをできるって言いたくない」ので、なんか難しそうだな〜って思ったらできませんって言い切っちゃったり、なんか専門用語並べて無理そう感醸し出したり、俗に言う「技術的には可能です」的なことを言ったりするんだと思う。もちろんできるできないを断言できないとしても、断言できない時点で自分がその施策に関わるとろくなことがおきなさそうなので無理って言っちゃうとかもあるだろう。
ただ、この現象をすごーーーく引いてみて、会社単位で考えたとき、できないことをできるって言っちゃうより、できることをできないって言っちゃうほうがよっぽどリスクだなと思っている。
できることをできないって言った場合、エンジニア以外の人とか、その発言者よりスキルが低いと自覚している人は、反論のしようがない。なので、できるはずなのにずーっとできないものだという認識で進んでしまう。
もうちょっというと、実はできるとできないの2択じゃなくて、絶対にできないでしょそれみたいなもの、できるかもしれんけどコスパ合わないよねってやつ、できるかもしれんけど自部署のメンバーでは技術力的に無理、できるけどクオリティが出せない、できるけど時間がめっちゃかかる、5分でできるみたいなかなりのグラデーションがあり、だからこそ、自分だけでとっさに判断したときにそのリスクをメタ認知できるに越したことはない。
もちろん前提としてどういう業態でどういう事業をやっているかにはよる。受託だったらできないことをできるって言う方が致命的だしね。ただ、自社開発かつスタートアップにおいては少なくとも、できないことをできるって言っても、試してみたらいずれ分かることで、駄目なことがわかりましたっていう収穫が得られるんだから技術力が課題なら採用にフィードバックしたり、他部署から開発リソース引っ張ったりできるわけで。
CTOレイヤーの人間としては、結果できないってなっても全然いいぞっていう制度とか風土とか作り、職種横断で浸透させていくとともに、各メンバーはそれまでの職歴とか経験とか思い込みを一旦置いて、「できることをできないって思うほうがリスクだよね」という思想で揃えていくのは大事かなと思った次第。