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

■山本大＠株式会社クロノス東京(http://www.kronos-jp.net/)
ナレッジボックス

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

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

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

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

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

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

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

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

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

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

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

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

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

人はみな、自分の靴のサイズで物事を計る（ドイツのことわざ）
（アインシュタインにきいてみよう勇気をくれる150の言葉からの引用）

スケジュール上実現が無理で、トラブるのが目に見えているなら
「トラブりますよどうしますか？」と相談しにいきます。

マネージャーさんに普通の良識があれば、メンバーが根拠と自信を持って「無理だ」といっているものを強引に進めたりはしません。
強引に押し通してきたら、問題対私たちの構造を利用して、解決策の提示を求めれば良いのです。

残業しろとか、日曜出勤しろとかいう馬鹿な策しか出てこなければ、
「はじめから残業や休出をあてにするマネージメントは３流以下だ」という正論を
やんわりと言ってやることにしています。

・・・なんか、あんまりTB先に対して真正面で返答してないような感じですみません。