zuKao


プロフィール

zuKao

Author:zuKao



最近の記事



最近のコメント



カテゴリー



月別アーカイブ



リンク

このブログをリンクに追加する



エドワード・ヨードン著「デスマーチ なぜソフトウエア・プロジェクトは混乱するのか」
Title: Death March
Sub Title: The Complete Software Developer's Guide to Surviving "Mission Impossible" Projects
Author: Edward Yourdon

●現実のソフトウエア・プロジェクトで、次の1つ以上が発生したものをデスマーチという。
・プロジェクトのスケジュールが、常識的に見積もった期間の半分以下に圧縮されたプロジェクト。~(以下、略)(p.2)

●最後に、実現が非常に難しいプロジェクトと、原則的に実現不可能なプロジェクトの違いを明確にしておく。Crunch Modeの著者であるJohn Boddieは、次のように述べている。優れた技術者、力のある経営者、優秀な設計者、理性的でモラルの高いユーザーがそろったとしても、日程が非常に厳しいプロジェクトを成功させるのは難しい。一方、世の中には、絶対に成功しないプロジェクトというものがあり、毎日のように生まれている。どうしようもないプロジェクトは開発の最初からわかる。このタイプのプロジェクトが作るものには、「理解不足のシステム」と「複雑度の高いシステム」の2種類がある。(p.6)

●プロジェクトが複雑、巨大で、政治力がすべてを決める場合、このプロジェクトはデスマーチと断じてよい。デスマーチ・プロジェクトの定義を思い出して欲しい。「開発日程、予算、人員、その他開発資源が通常の50%から100%少ないプロジェクト」。なぜ、こんなばかげた条件がプロジェクトに課せられるのだろう。以下に述べるように、いろいろな原因があるが、大部分は「政治」という非常に単純な言葉で説明できる。(p.8)

●天真爛漫(らんまん)な将来展望は、経験不足から来ることが多い。これから開発するシステムにどれだけの時間と工数が必要か全くわかっていない人が、非現実的な約束をするのはよくあることだ。(p.9)

●問題は、「最初の見積もり通りには絶対にシステムが完成しないと判明したとき、楽観主義者の連中は、どう反応するだろう」である。(p.9)

●しかし、大部分のデスマーチ・プロジェクトでは、このように冷静に軌道修正することはあり得ない。例えば、会社上層部が顧客に楽観的な見積もりを出し、何が何でもこの予定で開発すると決めた場合は、「冷静な軌道修正」は起こり得ない。(p.9)

●いつ事件や事故が起きるかを正確に予知できても、デスマーチ・プロジェクトになる場合もある。というのは、会社上層部はぎりぎりまで動こうとしないためだ。そうでないと、目前に迫っている西暦2000年問題で企業の情報処理部門がパニックになっているのを説明できない。ずっと前から西暦2000年の1月1日が来ることはわかっているし、その日がデッドラインで絶対に延期が利かないことも承知している。どんな性格の問題かも明らかだし、Javaみたいに最先端の技術も不要。しかし、本書を書いている1996年夏の時点で、2000年対策関係のデスマーチ・プロジェクトが発生しており、さらに1997年、1998年、1999年にはもっと悲惨なプロジェクトが生まれることは確実だ。(p.17)

●初めに書いたことを覚えていれば、どう対処すべきかだいたい予想できるだろう。問題から一歩下がってデスマーチ・プロジェクトが1回だけの例外か、大量発生の最初なのか自問してみることだ。デスマーチ・プロジェクトに参加し、個人的には大成功しても、会社が戦いに破れてしまう場合もある。頑張って最初のデスマーチ・プロジェクトを成功させても、会社がわずかな期間、延命したため第二のデスマーチ・プロジェクトが生まれるという皮肉な結果になることもある。この決断は個人の問題だ。(p.31)

●自分の水晶玉で未来を見る前に、できるだけ多くの人の意見を聞くことだ。特に、デスマーチ・プロジェクトと何も利害関係のない人のアドバイスを求めるとよい。同じ会社には公正な目を持ち、客観的に判断できるマネージャが何人かいるはずだ。その人たちと一緒に、デスマーチ・プロジェクトが成功、失敗したらどうなるか、本音で話し合うとよい。ただし、そのマネージャも自分の経歴や給料を心配している一人であり、エゴや政治的な本能があるため、本当に必要な情報を流してくれない可能性があることは覚悟すべきだ。(p.32)

●以降の章では、読者が合理的に判断した結果、デスマーチ・プロジェクトに参加することに決めたと仮定して話を進める。もちろん、何度も繰り返し述べているように、プロジェクトを辞める選択肢はいつでもとれる。(p.35)

●「自滅」型プロジェクト-このプロジェクトでは、メンバー全員が破滅する運命にあり、悲惨な結果を迎える。メンバーとプロジェクト・マネージャがプロジェクトに参加するのは、そうしないとクビになるためだ。そして全員、プロジェクトは絶対成功しないと最初から承知している。辞めることもできず、スーパーマンもおらず、引くカード引くカードすべてが悪いものばかり……。(p.56)

●プロジェクトのメンバーがどの程度の貢献を約束できるかは、プロジェクト全体のスタイルに大きく影響される。例えば、すでに述べたように、プロジェクトのメンバー全員が「自滅」型プロジェクトへ入れられたことに気付くと、必要最小限の労力と関心しか示さないだろう。プロジェクト・マネージャが、長時間、強制的に働かせようとしても、深夜や土日には(すなわち、長時間残業を命令した会社上層部の連中がいないことが確実な時間帯)、私用の電話をかけたり、家族に手紙を書いたり、コーヒーの自動販売機のまわりにたむろして、バカ話に興じるだけなのだ。(p.60)

●しかし、大きな会社には、プロジェクトでスケジュールを決め、プロジェクトで予算を見積もり、また、この条件下ですべての機能を漏れなく実現できると自信たっぷりのプロジェクトが何十もある。しかし、そんなプロジェクト・チームも、自分の仕掛けた地雷で吹き飛ばされ、いつまでたっても何もリリースできないのだ。したがって、自然の成りゆきとして、会社では、ユーザー・グループや会社上層部は、交渉を重ねても無駄と見切りをつけ、代わりに、「やるか死ぬか」式のスケジュールや予算を押し付けるようになった。これがデスマーチ・プロジェクトの始まりとなる。(p.68)

●第2章で「自滅」型と呼んだプロジェクトが示す兆候の1つに、投げやりな態度がある。プロジェクト・マネージャが最初に示し、メンバー全員に浸透する。(p.69)

●SPR社の社長で、ソフトウエア・メトリクスの大家、Capers Jonesによると、市販のプロジェクト計画用ツールは50以上あるとのこと。完全なものはないし、使う場合にもいろいろ頭を絞らねばならない(この分野でも、「ゴミを入れたらゴミが出る」の法則は生きている)。しかし、うまくいくと、誤差が±50%でも、政治ゲームで押し付けられるものよりずっとよい。上から強制される条件は、1,000%以上の誤差があるのだから。(p.69)

●大半のベテランのプロジェクト・マネージャには、疲労がたまると生産性(例えば、1日当たり設計したファンクション・ポイント数、時間当たりのコーディング・ステップ数等で測る)がだんだん低下することは常識だ。また、疲れると、バグの作り込みが増えるので、テストやデバッグ工程が大きな影響を受けることも明らかだ。さらに、長時間残業が長期間続くと、疲れのためプロジェクト・チーム全体がつぶれてしまう。(p.70)

●著作者であり、コンサルタントでもあるJohn Boddieは、最近送ってくれたメールの中で、プロジェクトには1つだけではなく、いくつかのシナリオがあることをプロジェクト・メンバー全員が認識することが不可欠であると述べている。~(中略)~「ウチのチームのメンバーは、品質の良いものを作りたいと考えていますし、性能の良いものにしたいとも思っています。また、安く作ろうとも考えています。でも、会社の提示した条件では3つのうち、2つしか実現できないのが明らかです。どの2つにしますか?」重要なことは、デスマーチ・プロジェクトに要求を出す連中が別案を検討しないならば、不条理に見えるようにすることです。問題解決の選択肢が2つ以上あることを認めないのなら、交渉は起こり得ません。プロジェクト・マネージャは、「我々ができる限りのことをするつもりですが、成功する保証はありません」と言えばよいのです。(p.71)

●しかし、Fred Brooksが20年前の著書、The Mythical Man-Monthでも述べているが、ソフトウエア・プロジェクトでは、時間と人数の関係は線形ではない。このため、人月という言葉(英語ではman-monthというが、政治的に正しい表現が必要な組織ではstaff-monthを使う)は神話であるとたたかれた。プロジェクトの主要なパラメータ間の関係は、どれも線形にはならず、時間軸の影響を受ける。管理者の下す決定による「フィードバック効果」により、1つのパラメータが変化(例えば、プログラマーの増員)すると、時間の経過にともないほかのパラメータ(例えば、生産性)に影響するだけではなく、元のパラメータにも影響を及ぼす。例えば、人数を増やすと士気が低下し、その代わりにプロジェクト内の退職率が上昇するため、最終的には人員は減るというもの。(p.72)

●「入札」型-多くの会社で外部発注という開発形態が増えたため、この交渉パターンは今では、よく見かける。顧客システムを受注するために、ソフトウエア開発会社が他社と競争する場合もよくあるパターン。戦略は明快だ。顧客(あるいは、ソフトウエア開発会社の営業部門の部長)がプロジェクト・マネージャに、「他社はもっと短い日程でもっと安いコストでやるそうだ」と言う。マネージャ氏はプレッシャーを感じ、他社の提示条件(本当である保障はどこにもない)と同じものを出すだけではなく、受注の可能性を上げるため、相手よりさらに良い条件を提示しようとする。(p.76)

●プロジェクト・メンバー全員(とマネージャにも)の鼻先に巨額の札束をぶら下げれば、やる気問題を解決できるにしても、この問題は非常に難しい。しかし、Frederick Herzbergは、金がすべてではないと、次のように述べている。給料、福利厚生、快適さなどは、プロジェクトの「公衆衛生」のようなものだ。存在しないと不満を感じるが、あるからといって仕事を楽しいと感じることはない。やる気を起こすのは、達成感、良い仕事をしているというプライド、責任感、向上心、自己成長欲なのだ。鍵は、仕事を魅力的なものにすることにある。正常なプロジェクトでは、これは正確な評価だが、デスマーチ・プロジェクトでは金が物をいう。(p.97)

●当たり前だが、1日18時間のペースで永久に働けるわけがない。やろうとしても、すぐに疲れる。疲れるとイライラして気が短くなるので生産性が落ちるし、間違いが増える。このどれもがプロジェクト全体の進捗に大きな影響を及ぼす。したがって、プロジェクト・マネージャは、いつガス抜きをして、いつハッパをかけて残業させるかの判断を的確に下す必要がある。3か月から6か月のプロジェクトでは、これはそれほど重要ではないし、若くてエネルギーたっぷりのプロジェクト・チームが初めから終わりまで一本調子で一挙に仕上げてしまう場合もある。しかし、プロジェクトの期間が長くなると、残業時間を注意して管理しなければならない。長期間にわたり長時間残業をする悪影響は、表面にはなかなか現れないが、極めて実害が大きい。(p.103)

●プロジェクトのためを思って一生懸命、自分を犠牲にして頑張っても、プロジェクト・マネージャが重要な情報を教えてくれなかったり、メンバーの後ろで何やら政治ゲームを演じていることがわかると、非常に幻滅する。デスマーチ・プロジェクトは緊張の度合いが高く、動きも速いので、プロジェクト・マネージャが重大情報を操作したり、政治的な茶番劇があると、メンバーが気付く可能性は、正常なプロジェクトに比べ、かなり高い。(p.105)

●多くの人は、triageの医療上の意味はよく知っているだろうが、デスマーチ・プロジェクトについての我々の議論に関係が深いのは、辞書の2番目の定義、つまり、乏しい商品(最も乏しいものは、通常、時間である)を、それから最大の効果を引き出すようなやり方で割り当てることである。または、Stephen CoveyがFirst Things Firstで述べているように、「重要なことが本当に重要なことであるかを確かめることが最も重要なことなのだ」。(p.123)

●第5.1節の"triage"の観点から、1つの大きな問題がある。それは、我々が要求項目を管理する組織化された方法を持っていない、ということである。ある瞬間に、我々はどうやって、どの要求項目が「やらねばならぬ」区分に入り、どの要求項目が「やったほうがいい」区分に入り、そして、どの要求項目が「やれればやる」区分に入っているかを知ることができるのだろうか。(p.130)

●時間遅れ、フィードバック・ループ、などの、プロセスのダイナミックな性格を無視する。今週プロジェクト・チームがたくさんの残業をすれば、生産性は上がりプロジェクト全体は進捗するが、これは翌週にたくさんのバグとなって現れ(これは、エンドユーザーや会社上層部は気付かないだろう)、翌週の生産性を(生産的な出力、という点から)低下させ、恐らくプロジェクトをさらに遅らせるだろう。(p.141)

●プロジェクト・チーム員や、チームのまわりにいるいろいろなレベルのユーザーやマネージャのいずれもが、目隠しをして断固として深刻なプロジェクトのリスクを無視するのは、一般的な現象である。プロジェクト・マネージャとチーム員が、「内部の」リスクに極端な真面目さで努力を傾注するが、前述のように、しばしばチームが制御できない「外部の」リスクには、彼らが関係する組織またはビジネスが権限の範囲外にあるために努力を傾注しないのは、決して不合理なことではない。(p.157)

●今をさかのぼる1992年の夏、筆者はMicrosoft社の中間レベルのマネージャのなごやかなグループと、食事を共にした。議論している間、筆者は、Microsoft社ではプロジェクト・チームが構造化分析、またはオブジェクト指向設計のような方法論を用いるのが一般的かどうかを尋ねた。その答えは、「ときどき」から、「うーん、多分使っていると思います」、「一貫して使ってはいません」、「それって何ですか?」までの幅があった。さらに筆者が(その時点でその産業の全体では十分によく知られていた)CASEツールの利用について尋ねたとき、そのようなツールは「道の向こうにいる人たち」のためのものだというのが、Microsoft人の共通した見解であるという答えが返ってきた。(p.167)

●そして、最後に、筆者はデスマーチ・プロジェクト・チームの環境に、どんなものでも、全く新しいツールを導入してはならないと警告したい。(p.169)
スポンサーサイト

この記事に対するコメント

この記事に対するコメントの投稿












管理者にだけ表示を許可する


この記事に対するトラックバック