はじめまして、コラムニストのあぐです。
(1)か(２)かで言ったら、(1)派です。
というのも、いつまでに、と指示者は掲示するだけで、期日までに他の作業とやりくりをするのは作業者の自由だからだと思うからです。
そうすれば、指示者は細かく〇〇を何時間、△△を何時間、と細分化する必要がないから。
ただ、それはある程度自分でタスクをコントロールできる中級者以上にならないと無理だと思います。
相手が新人であれば、作業を細分化して何時間、何時間と区切ることも大切かと。
ありきたりな回答で申し訳ないですが、結局メンバーに合わせて使い分けるのがいいのかなぁ、なんて。
でも、工期って考え方があまり自分の中ではなかったので面白かったです。
どうもありがとうございます。

がると申します。
面白いお話でしたので、参加をさせていただければ、と。
私は「工数 -> 納期」の順番で質問をします。
流れとしては…
・(仕様/依頼内容を把握：自分が)
・(自分の中での見積もり：自分なら、と、依頼者のスキルなら、の２パターン)
・仕様を説明
・見積もってもらう
・もし「極端に見積もりが違う」場合、仕様認識齟齬の可能性があるので、もう一度仕様を説明、に戻る
・見積もりが概ね妥当だった場合「いつまでに出来るか(納期)」を決める。自分がマネージャなら他のスケジュールとの兼ね合いで考え、別のマネージャさんのエンジニアなら、マネージャに質問するなりお願いするなりねじ込むなり、する
という感じでしょうか？

工期(というか納期)は本質的に重要なので外せないのと、ただ、納期を決めるためには同じくらい「工数」は外せないのと。
あとついでに「この仕様をどれくらいの工数でこなせるか」は、スキルを図るよい指針にもなるので。

結果、どちらも大切にする、感じでしょうか。

面白い内容ですね。
依頼する時は工期（納期）。
依頼された身だと，工数をもとに管理します。
内注と外注でも違いますが，見積もりの話もあがってますので社外ですね？
そうなると，間違いなく工期ですね。

はじめまして、ちけんちと申します。

話しの前提として、作業を依頼される側が
・作業から工数を見積もれない
・スケジュール管理ができない
・作業がこなせるかどうかわからなくても、とりあえず仕事を引き受けてしまう
・締め切り直前まで仕事にとりかからない
というような、かなり問題のある人であることを前提としているんですよね？

そういう人に対しては工期だけで依頼するのではなく、いつ、どれくらいの時間をかけてやるかというところまで噛み砕く必要はあると思いますが、それはあまり一般的ではないと思います(私が経験していないだけで、よくあることなのかもしれませんが)。

工期と工数ってどちらかを管理すればいいというものではなく、工期を守るために工数を管理するっていうほうが一般的ではないでしょうか。

あぐさん、がるさん、ねこさん、ちけんちさん、こんなに沢山の方々にコメント頂いて嬉しい限りです。
ありがとうございます。

さて、皆様に置かれましては、前述の１）と２）をうまく使い分けて、
それぞれの長所短所を把握されて活用されていることと思われます。

いやぁ、羨ましいですね。
そんな方々と一緒に仕事ができたら、なんと幸せなことでしょう。
決して、私の周りの人間が、新人君ばかりだと言っている訳でもありません。
１０年選手、いやそれ以上の年輪を重ねた方々も沢山いらっしゃいます。

でも、ここは、魑魅魍魎の闊歩する異空間なのです。
常識が通用しません。
きっと、最初から「非常識」を「常識」として、叩き込まれて（OJTと称して）しまった廃人、、、
おっと失礼、諸先輩の方々は、「工数」って意味すら分からない（のように見える）かのごとく振る舞います。

きっと頭では理解していると思いますが、わざと知らない振りをしているのかもしれません。
（それこそ確信犯ですけどね）

ソフトウェア業界で長い間飯を食ってくれば、見積方法の２つや３つ知っていて当然です。
KKD以外に、デルファイ法だって全然構いません。

でも、（見積もり）しないんですよね・・・。

納期遅延を言い逃れる言い訳も、妖怪の極地です。
今度、「言い訳100選」とかを編修してみようかと思います。

では、また。今後ともよろしくお願いいたします。