これはもう結構（我々の業界では）有名な風刺画。
わかっていても失敗するのは何故か。
結局これは一番初っ端の要件定義がコケているから、
というところに落ち着くんじゃないだろうかと。
つまり、ユーザは本当に作って欲しいものを伝え切れてないし、
開発側はとにかく要求された機能を実現することを考えるから、
ユーザの説いたそのシステムが必要な背景が御座なりになる。
要は、そのシステムが実際にどういう使われ方をするものなのか、
ということの考慮が、結構設計から抜け落ちていたりするのね。
そうしてお互いにすれ違ったまま基本設計、詳細設計に入っていくから、
実際に動くモノができてみたところで、
ユーザから文句や仕変の嵐を食らうことになると。
でも、その最初の（要件定義段階の）合意というのは、
そう上手いことまとまることはないんですよね。
なんべんやっても
「よしっ、客が言いたいのはそういうことダナ！[E:wink]」
と膝を打つことはまずなくて、
「んー、多分こういうことなんだろうなぁ？[E:despair]」
で進んでいくことがほとんど。
まぁそりゃそうで、
最初は実際に動くシステムがない（当然）わけだから、
お互いに「絵に描いた餅」の話をしてることになる。
あと、最近わかってきたことは、
特にこれはWebシステムにいえることだと思うんだけど、
ユーザは機能よりも結構見た目の方を気にする、ということ。
開発者としては、機能さえ満たせばいいじゃん？
という方向に傾いてモノをつくってることが大概なので、
見た目がどうとかいうあたりを実はあまり意識していない。
でも、ユーザとしては、機能は結局裏方でしかなく
見た目に目立つところをかなり指摘してくる。
機能は満たしていて当たり前というところなんでしょうけどね。
制御系やってるときはそんなことはあまりなかったんですが、
やっぱりWebは基本的に見せるもの、だからなんでしょうね。
最近はJSやAjaxでいろんなことができるようになったせいで、
お客さんからも、Web上で何でもできるんじゃないの？
とか思われていて、GUIも単純なフォームじゃなく、
WordやExcelみたいなモノを軽く求められたりする。
ていうかね、血の涙を流しながら力いっぱい苦労した末に
Wordみたいな入力やExcelみたいなスプレッドをやっと実現して、
こっちはもう心の中で親指とか立てながら「どうすか！お客さんっ！[E:good]」
のつもりで見せてるのに、お客さん「ふうん[E:gawk]」的な反応だったりして
ショボーン(´･ω･`)みたいな。
こんなんがエエゆうてたんやないんかいっ！
まぁ、人の欲するところをバッチリ理解できるような能力があれば、
それこそマーケティングの神様にでもなれますわね。
てか、ちょっとでもそういうことができるなら、
もっと世の中上手く渡ってます。
基本的にKY。
神でも仏でもない凡人が開発とかやってるんだから、
結構この業界って無理を通してるところがあるのかもね。
バッチリ上手くいくということはないのなら、
プロジェクトをいかにデスマに導かないかがPLやPMの手腕なのか。
もう私もこの業界10年近くになるけど、
メンバ10人以上の規模のプロジェクトで、万事うまくいったZE！
という経験はほぼ皆無です。
私の運がないのか、ヘボいだけなのかはわかりませんが、
比較的大きめなプロジェクトを順風満帆に、
或いは最後まで平和にやれてるところってあるのかしら。
（1、2人程度のプロジェクトなら、何件か平和にやらせてもらったけど。）
やっぱり、喫茶店開くしかないすね。
（しつこい）
（ → 別バージョンがあった。）
プロジェクト・コメディ
IT・プログラミング
コメント
お久しぶりです。ちょいと、長文失礼 m(_ _)m
私の最近のは小規模ばかりですが、そこそこの人数で成功しうるのか？という事で、最後に関わった大規模プロジェクトの話をすると、2004年10月から1年間、某猫運送のグループ会社の基幹システムを刷新するサブプロジェクトに関わってました。規模は1年で180人月を越えてたぐらいで、実装のピーク時が20人以上、顧客の運用が落ち着くまで常時10人以上が入っていたプロジェクトです。
年賀状作成ソフトで有名な品川の某Ｃ社がそこを一式請け負ってて、当時の私の立場はＣ社への出向社員で、そのプロジェクトでの担当は、技術リーダでした。権限は開発方針や実装方式の口出し以外には特に無く、立場的にはサブリーダの下ですね。
結果から言うと、設計の後半と、本格的な実装の前半は少々ゴタゴタもありましたが、徹夜するような事態は１日たりとも発生せず、運用開始直後は昼夜動くので２交替で夜間監視とかも実施することになりましたが、特に大きなトラブルも無く、順調に実運用まで漕ぎ着けることができましたよ。実装が落ち着いてからは、ゾロゾロと大所帯で定時帰りというのも多かったです。
人数だけで簡単なプロジェクトだったのだろうと思われるかもしれませんが、サーバは Java、DB は 某F の Symfo、クライアントは Biz/Browser という専用のリッチクライアントが既に決定されてて、作る必要のある画面枚数も基幹の大半を刷新するため初期の分析時点で100枚を越えている状態でした。
使ったこともない癖のあるリッチクライアントなわけで、短期間で使えるレベルに到達できない新人が、まともに成果を出せないのも明白だったので、そのプロジェクト専用のフレームワークとドキュメントを私が年末までに作って、設計者にはフレームワークに合わせた実装しやすい設計書を書いてもらって、設計できる人やら、フレームワーク開発に若干負荷が高い状況で望みましたが、結果的には開発終盤の安定さにつながりましたね。
テスト工程での障害発生率が低すぎるから再テストとか、意味不明な労働は何度かさせられましたけどｗ
2006年春の内輪話ですが、上記は2005年度Ｃ社の最優秀プロジェクトでした。
要因を傍目から見ると『たまたま寄せ集めのメンバーが良かった』で結論付けられるかもしれませんが、ある意味その通りの所もあります。結局、プロジェクトをねじ伏せられる能力のある人が揃うかどうかではないでしょうか？開発チームの総力として、渉外、設計、実装、運用、あとは、リーダの内部組織をまとめるといった能力が足りてないと簡単に破綻したでしょう。メンバーのスキル構成のバランスが良く、各能力を持った人の発言を重視するチームだった事も大きいかもしれません。
ただ、別途追加の報酬も無くあの規模を回すのは、一番下と一番上で関わる人の作業比率や濃縮率というか、そういう面で半端ない状況が生まれてて、必要ない外注は、リーダが早いタイミングで退場させていたではあるものの、社員やプロパーは切れないしｗ主要メンバーになればなるほど、プロジェクトに想定でも億近い利益が出てることを知ってただけに、主に金銭的なリターンの面で萎えましたね。ちゃんと休みが取れても、こなしている仕事量と質が違いすぎるので・・・。主要メンバーの報酬に少し色でも付く制度があれば、かなり変わったのでしょうけれど。
私がフリーになったのは、なんだかんだでその時期ですし、Ｃ社のリーダさんも安定稼働後のタイミングで転職しちゃったりで、最終的な保守の工程では初期の主要メンバーは残ってなかったです。デスマーチを回避できても、取り巻く環境が人材に対して相応の価値を認めるなり、ケアが無ければ、プロジェクトは大丈夫でも、当事者が燃え尽きちゃうとか＾＾；別な問題も起こりやすいですよ。安直にデスマを回避したいだけならば、外からの無理な要求に対して No って言い切れるチームに所属することが手っ取り早いと思います。
どうも！参考になります。上手くいくところでは上手くいくのですな。
ちなみに、そのプロジェクトで要件定義の具合（仕様の決まり具合というか）はどうだったですかね。大きなプロジェクトでも、要件定義の段階と、テスト工程の段階での仕様の差があまり大きくなければ、プロジェクト自体もあまり火を噴くことはないのかな、という気がしてます。
技術的なところに起因して問題が発生する、というのは、私もあまり経験ないですね。どちらかというと、仕様がなかなか決まらないとか、ある機能についての解釈がユーザと開発で違っていたとか、ユーザ側と開発側の観点や重視するポイントが違っていたりとか、そういうところから煙が立ってくることがほとんどです。
例えば、ユーザの要求でAとBという機能が欲しい、といわれたとする。（実際はA、Bは単機能でなく機能群ですが）
まず、Aに関しては実現可能だが、Bに関しては期間や難易度の面で厳しい、と開発側で判断された場合、まずBは断る方向で動きます。ユーザも最初はそれを認めて、その時点で要件定義書や仕様書などからその機能群Bは除外されます。
で、Aの実装に重点がおかれるわけですが、このAに関しても、開発側の理解は、それと似て非なるA'だったりする。これは、仕様書上はほとんど同じにみえるから厄介なんですが（というか、ユーザ側と開発側で、それぞれ都合の良いように解釈している）、実際に開発が進んで動くものが出来上がったところで、その解釈の相違が表面化してくる。
この段階で仕様変更なり設計や実装の軌道修正が入るんだけど、当初の設計（や実装）とは別の概念を埋め込んでいかなければならなくなるので、大概これはバグ注入工程になる。かくて、テストでメンバの許容以上の不具合があがってくることになり、炎上、火消しの日々が始まるというパターン。
この時期に来てユーザ側で「やっぱり機能Bも必要だZE！」なんて言い出された日にゃ、デスマーチは必定です。
最後のダメ押しは滅多にないんじゃないか、といえば、ユーザの渉外役（技術部とか）と実際の現場とが別部署だったりする場合、これが結構あったりします。あと、未知の機能Cが浮上とか。
この被害を最小限に抑えるには、とにかくAとA'の差異をなるべく小さくとどめること、なんだろうなと。その要求の本当に意図するところ（真のA）をどこまで聞き取れるか、或いは聞き出せるか、というのが、最初の開発側（PL）の課題（実は最重要）なんだろうと。
あと、おっしゃるとおり、開発メンバのモチベーション維持は大事ですね。これが高いか低いかによって、メンバがどこまでその開発に力を出せるか、きめ細かく気配りができるかが分かれてくる。PL権限では報酬をどうにかするのは難しいですが、それでも上手くメンバを走らせることができるかどうか、というのもPLの腕なんでしょうね。
月影さんの考えには、私も同意ですよ。如何に顧客の真意を理解して作るかは、常に課題でしょうね。大概の人は、自分自身が理解しきっている（自分の中での）常識は明確に問われない限り話しませんから、こちらからはブレない様に解りやすく伝え、顧客から上手く情報を引き出すことがポイントになるでしょうね。それにはお客さんの業務に精通している事とかも必要でしょうし、言うほど簡単ではないですが＾＾；
ご質問の要件定義の件については、１年前の2003年冬から別なメンバーが進めていたのですけれど、春の時点で一度プロジェクトが凍結されて、2004年9月頃、急遽再開が決まったという経緯があって、丁度、他のプロジェクトが片付いた私の所属チームと追加要員とで進めることになったのですが、当時のメンバーは既に逃げててｗ資料の引き継ぎもできず、結局全てやり直しをする事になってしまいました。
ただ、基幹システムのリプレースが目的だったので、最低限のゴールは、今まで汎用機で行っていた全ての業務を新しいシステムで実現できれば良い。というもので、追加の要望もそれなりにあったのですが、どちらかというと、新しい画面でどう操作させるか？というＵＩの部分を中心にとにかく顧客と対話しましたね。
機能自体については、ある程度既存システムの分析をすれば解決したので、分析結果を要約した大まかな流れを顧客に確認してもらった上で、現行の不満、拡張や変更の要望を聞き、提案を進めましたね。
で、顧客の要望と、こちらの作ろうとしているもののブレを少なくするために使った方法はプロトタイピングです。そのため、主要な画面については、本格的な設計に入る段階で（中身が無く、組み方も無茶苦茶だけれども）それっぽいデモが動いていたので、自分達が作ろうとしているモノのイメージは比較的早い段階で統一が図れてましたよ。
上記の実践方法として、まず、要求分析の段階で、メンバーを設計チームと開発チームとの２つに分けて、設計側が渉外と仕様確定、開発側が専用フレームワーク開発と、随時要求に沿ったプロトタイプ作成。という形で、双方密に連携して進めていましたね。当時、私は渉外にほとんど参加せず、フレームワークを作りつつ、設計側から依頼を受けて、それっぽく動くプロトタイプを次回の打ち合せ前までに準備できるよう部下に指示を出してました。
このプロジェクトでは、詳細設計の中盤から実装を開始したのですが、その時のチーム編成は、開発チームに人数を増やすのではなく、リッチクライアント側と、サーバ側それぞれの実装チームを作って（若干メンバーは流動的だけれども）実装対象を明確にしました。設計チームが実装チームに作る対象の指示と成果の確認を随時行い、開発チーム自体は、実装チームを横断的にサポートしつつ、急に必要となったプロトタイプの開発やら、実装の難しい部分を実装チームから引き受けたりと、うまく分業していたとは思います。仕様変更や機能追加、スケジュールの短縮なども発生したのですが、全体が極めて疎結合になるアーキテクチャを取っていたので、個々の開発自体は極めてシンプルで、無茶な要望もちょっと残業する程度でなんとか片付きましたね。疎結合にしておくと楽ですよ。単体テストで問題なければ、結合してもほとんど問題出ませんでしたからね。
まぁ、そんな感じでしたよ。
なるほど。[E:flair]
ユーザと開発のみならず、開発メンバ間の意思疎通もキモだったりしますね。規模が大きくなるとなおさら。
最近はRADの性能が良いので開発もほぼプロトタイプ型なんですが、それもお客さんがちゃんと見てくれて初めて意味があるものなんですよね。開発の初期だと、大体動いていればOKとなることがほとんどで、後になってやっぱり…というケースもよくあったり。[E:wobbly]そこをちゃんと見てもらうような誘導の仕方も工夫がいるんですな。
あと、「ここは問題になるかもなぁ」と感じたとことは、ほぼ100%問題になりますね。些細だし対応も面倒だからと握りつぶしてたりすると、後で痛いことになるので、どんな小さいことでも気になったら問題提起すべき（メンバにもそれを徹底させるべき）ですね。