この記事は、あなたがエンジニアが見積もった期間をもとにスケジュールを作り、それを顧客などのステークホルダーに伝える立場にある人だと想定しています。
開発に思ったより長い期間を要することが分かった時、あなたはそれを伝えることに後ろめたさを感じる人ですか？
見積りは、後ろめたさを感じる対象ではない
見積り結果が、あなたの個人的な期待より大きくても、それを顧客に見せる時に後ろめたさを感じてはいけません。
見積りは、「これぐらいの期間がほしいです」という希望やお願いではなく、「これぐらいの期間がかかると予測される」という冷静な予測です。
その見積りが、必要な作業や起こりうる出来事をシミュレーションして出したものであるならば、後ろめたさはないはずです。
あなたは顧客に対して弁解や交渉をするのではありません。あなたがすべきことは、見積りが何を想定して出したものなのかを納得がいくように説明することです。
あなたにあるのは見積りに対する説明責任です。
顧客の顔色を伺ってスケジュールを短縮しようとする考え方は責任放棄に等しい
顧客が難色を示すのは、彼の期待通りでない結果を見たからです。
そこに顔色を伺って、スコープの調整もせずに「短い期間でやりますよ」などと言ってはいけません。
開発における将来の予測をごまかしているという点で、開発者としての責任を果たしていません。見積りは交渉材料ではありません。
そもそも見積りを正確な時間として出すことは現実的に不可能です。
不確定な未来でいっぱいな開発プロジェクトというものを、シミュレーションではなく顧客の期待を基準にして進めてしまって本当に大丈夫ですか？
期日におさめる点で一致しているならば、顧客もまた期日におさめることに貢献していくものだと思います。
もしも見積り結果が、ビジネス上求められる期日をオーバーしているならば、期日におさめる方法を、顧客と一緒に模索していくべきでしょう。
他はもっと早くできるよと言われたら？
それは、そのチームのほうが能力が高かったか、そのチームが無理をしているかのどちらかだと思います。
前者であれば、あなたのチームや組織も効率的な開発手法を学ぶなどして、能力を上げていく必要があるだけの話です。
後者であれば、無理をしている他所に合わせてはいけません。それこそ無責任な行為だと思います。
動いているように見せるためのものを作り、テストも省いて、ユーザーが使えないものを作ることがあなたのチームの仕事なのでしょうか？
あるいは、設計せずに突貫工事を重ねて、少しの修正をするのにも他の多くの部分に影響が出てしまうものを作ってしまって、後々大丈夫でしょうか？
（納品すれば終わる契約を結んでいるなら、そういった部分に責任を負わなくても良くなってしまうのですが）
とはいえ、スケジュール短縮のための提案をすることもまた責任
開発者は、スケジュールを短縮したいという顧客の望みに貢献するべきです。
その時に行うべき作業は、一つ一つの機能について、「なぜその機能を計画に盛り込みたいのか？」「その機能は誰にどんな価値を提供するためのものか？」という問いを顧客と一緒に繰り返すことだと思います。
完成した機能の64%がほとんど使われないという調査結果もあります（Standish社の2002年のレポート）。
むしろ、スケジュールの短縮を顧客から求められることは、無駄なお金と時間をかけずに価値を提供するにはどうすれば良いかを議論するいい機会とさえ思います。
「100万行のコードを書いて1円しか稼げないのは駄目なプロジェクト、1行のコードを書いて100万円稼げるのは良いプロジェクト」ということを、私はメンターにあたる人からよく言われていました。
信頼できるスケジュールを作ることにフォーカスする
良いスケジュールとは、早く終わる望ましいスケジュールではなく、プロジェクトを取り巻く人たちが信頼できるスケジュールです。
そのスケジュールは、プロジェクトに対する投資判断や、他のチームの意思決定に使われるでしょう。
したがって、期日から逆算して辻褄を合わせたようなスケジュールは使っていいものではありません。
あなたが後ろめたさを感じるべき時は、早く終わる望ましいスケジュールを出せなかった時ではなく、スケジュールの信頼性を上げる努力を怠った時です。