スケジュールを作って、「問題対私たち」の構図に持ち込もう

スケジュールを作るプログラマが一番効率が良い。 - 山本大の日記のエントリに
プログラマが作ったスケジュールはいつも壊される - @katzchang.contextsでトラックバックを頂いたので返答します。
すべてに返答差し上げたいところですが、長くなるので部分的に。

id:katzchangの言ってる状況は、昔僕もよく経験しましたし納得できますね。
僕の場合はそういった状況に陥らないために、自分がマネジメントをする立場になりたいと考えるようになり、現在はやばそうなプロジェクトに１SEとして入っても、そうそうトラブらなくなったので、ある程度の結果は出ていると思います。

好きなプログラミングの仕事に集中したいなら、プログラミングスキルと共にマネジメントスキルをツールとして持っておくことは大事だと思います。
とは言え「マネージャになれ」というのは解決策としては遠回り過ぎるので、もう少し現実的な対策を考えます。
その中でも今回はスケジュールだけにフォーカスを当てます。

第１に、心構えとして必要なのは「受託開発の極意」という本で書かれている以下の言葉に表れていると思います。

最終的に目指したい関係は、「問題対私たち」の構図です。
しばしばお客様と開発者は敵対関係に陥ります。しかし、お客様は敵ではありません。解決すべき問題に対して一丸となって臨む姿勢とムード作りをしなくてはならないのです。
(受託開発の極意―変化はあなたから始まる。現場から学ぶ実践手法 (WEB+DB PRESS plusシリーズ)より引用)

お客様やマネージャーと対決する構図に持ち込むのではなく、「問題対私たち」という構図に持ち込むために、問題となっている敵の姿を現さなくてはならないのだと思っています。
プロジェクトの問題の多くはスケジュール表に現れます。

問題の存在を示して、問題と対決するためにマネージャや顧客と団結するという構図を取れるかどうかが大事です。

僕がマネジメントをやるようになって知ったのは、
本当は顧客やマネージャーといった人たちが、非協力的でワガママという状況は、そんなに多くないということです。
実際に、無茶苦茶なプロジェクトになったら一番困るのは彼らであり、
作業を担当するメンバーよりも大きな不安やプレッシャーを抱いているからです。

状況を正しく理解していないだけのことが多いようです。
もしくは、正しいやり方で成果がでるということを知らないだけかもしれません。

そういった人たちに現場のリアルな状況を知らせ、
相談という名の交渉に持ち込むためにも
実作業者であるプログラマが作る「スケジュール」は必要だと思います。

デスマな状況で僕の対処法は、まず小さな成果で自分の実力を見せ付けて、
それから相手の予想を上回る見積りなどで根拠を提示して「無理なものは無理ですよね」と言うことです。

例えば、マネージャさんがろくにスケジュールを作らずに進めようとしていたら、僕ならシメシメだと考えます。
ビシッと明確なスケジュールを計画してWBSを示すことで、そのマネージャーさんに自分を認めさせることができるからです。
完璧なスケジュールなどそもそも理想論だから、直近のスケジュールが正しければ良いのです。
こちらの示したとおりに物事が進むので、だんだんマネージャさんもこちらを認め大人しくなってきます。

直近のスケジュールを見積もる時には、自分が２時間でできる仕事を1つの単位として積み上げるようにしています。
２時間なら、ほぼ正確に出来る出来ないが示せるからです。