社内向けのWEBアプリケーションを構築します。JAVAで1年程度のプロジェクトです。現在の人数は10人程度です。

色々なものが絡み合って火をふくと思うのですが、強いてあげれば、

・顧客の仕様（文章も絵もあった）を正確に理解できず、こういう場合はどうするか、などといった確認を怠った。

ー＞仕様を各メンバがなんとなくしかわかってない（全くわからないわけではない）。

・コーディング規約が破られる。他に、iTempなんてネーミングを付けてくれる人が出始める。

10人のプロジェクトの場合だと確かに危険ですね＞全く文章にしない項目がある。

これが許されるのはXPがちゃんとワークする、かなりできるプログラマが4名程度のチームでかつ対象がWebアプリのように開発サイクルが速いものに限られるでしょう。つまり「拳と拳で語り合う(ソース読んでお互いに理解している)」状況だけです。

それに付随して、危険な予兆は例えば

• 忙しいんだからということでミーティング(会議体)が行われなくなる、または行われても「特に問題はありません」であっさり終わるか、逆にまとまりのない報告の連続だけで終わってしまう。

これでお互いの意思の疎通ができなくなり、各人が思い込みで作業を進めることになるでしょう。

• 作業の記録が残らない

自分の、ではないんですが、ソース管理・用件管理・進捗管理が全くまともに行われていないプロジェクトを見たことがあります。どれが最新の正しいソースかもわからない状態でもう悲惨の一語でしたね。たとえ管理ツールを使っていてもモジュールなどを更新するときのルールを決めておかないといとも簡単にこういう状況に近いところまで落ちます。

なんか、当たり前のことなんですが、始める前にこういう決め事をちゃんとしておくかしておかないか、というのが大事かと思います。

経験年数が浅いので大きな事は言えませんが、自分の思うところを。

当然、工程にもよると思いますが、上流工程でいえば顧客との打合せにおいて、

下流工程では設計SEとプログラマにおいて、

業務や仕様の理解がお互いに進まないと、デスマーチになる恐れがあると思います。

この点において最も大事なところは、仕様や業務への理解を曖昧にしないことですね！

という意味では、プロジェクト内のコミュニケーションはとても重要です。

そこでつまづくと、デスマーチの可能性がかなり高まってしまうと思います……。

また、単純に「納期」までの時間も重要な要素だと思います。

あまりに短納期での開発のせいで、私はデスマーチに突入した経験があります。

適正なスケジュール引き、定期的なレビューからリスケジュールを繰り返すことで、

うまくプロジェクトマネジメントを行う必要があると思います。

大変だと思いますが……応援しています！

デスマーチが起きる理由 - ３つの指標

デスマーチとは

予定の開発期間を過ぎても、まだまだ終わらないプロジェクトのこと。エドワード・ヨードンは、著書の中でデスマーチの定義として４つの項目を挙げています。

* １．与えられた期間が、常識的な期間の半分以下である。

* ２．エンジニアが通常必要な半分以下である。

* ３．予算やその他のリソースが必要分に対して半分である。

* ４．機能や性能などの要求が倍以上である。

前兆ではありませんが、間違いなくデスマーチなのは

「納期遅れの挽回対策」として「ソフト開発者が増員される」場合です。

プロジェクト途中で人を増やすと、新しく来た人に説明の手がとられて逆に効率が下がります。上の人の顧客に対する言い訳に過ぎないのです。

デスマーチの予感としては、担当者の能力（経験）不足な場合がありますね。開発案件ではなく社内システムの開発でしたがデータベースの設計一つ見ても背筋がゾワゾワしました。正規化以前の話で案の定デスマってます。

デスマーチが発生するのは「納期は固定なのに仕様が決まらず」ずるずると開始が送れた場合に良く発生します。

心配ですね。

ソフトウェアは目に見えないので、さまざまなステークホルダーに無理なスケジュール、予算を押し付けられても反論することが難しく、現場ではいやな雰囲気がただよい不安はつきないと思います。

デスマーチの始まりを語れるほど経験はありませんが...

・打ち合わせや会議が増える

・結局なにも決まらなかった打ち合わせや会議が増える

・スケジュールがない(不明確、あっても形だけ)

・スケジュールがあっても明確なマイルストンがない

私の貧弱な経験より下記を参照するのが良いと思います。

デスマーチ 第2版 ソフトウエア開発プロジェクトはなぜ混乱するのか

• 作者: エドワード・ヨードン
• 出版社/メーカー: 日経BP社
• メディア: 単行本

「外部設計書に各画面の機能（画面に何を出すか、検索画面で何を検索の母数にするのかなど）を全く文章にしない事がチーム内で決定されましたので、「デスマーチ」の始まりでは？？　と恐れております。」

と言われてますが、これ、まちがいなくアウトです。

あとで「おれはこういうつもりだったんだ」「でもそういう作りにはなってません」となるのは間違いないです。

よかったら、この辺読んであげてください。

http://d.hatena.ne.jp/ksh/20060920/1158763911

あと、経験上、こういうふうになるとまずだめです。

・定時後や休日に出席必須の会議が入る。それが定例になると確定。

・「とりあえず」決めて、最終結論先送りが普通になる。先送りアイテムリストを作らなくなると確定。

・みんな無理だと思うスケジュールなのにとりあえずやる。中間目標がなく、上が決定した完了日以外のスケジュールがなくなると確定。

・想定外作業が普通に割り込むが、その影響で延びるはずの期限が修正されない。想定外作業の割合が減っていかないと確定。

・作業を減らすという名目で議事録を作るのをやめる。「仕様書なんか作ってる時間がない」という状況になれば確定。

・日曜日にプライベートなスケジュールが入れられない。

・病気以外の理由で休めない。

まだまだあるような気がしますがとりあえず気付いたところまで。

>２．効率の良い方法を少しずつ取り入れる（会議の進め方など）

会議の進め方は、いろいろな人が参加するので良い方法があっても受け入れてもらえない場合もあると思います。

会議の目的、議題、議事録(アクションアイテム)は、必須だと思います。

下記の本の"ムダな会議の減らし方"-"航空管制プロジェクトの大会議"のようなやり方が簡単に受け入れれらるとは思いませんが、会議に参加する人の心理や主催者側で配慮することは参考になります。

わたしは、この本を読むと、いつも勇気づけられます。

デッドライン―ソフト開発を成功に導く101の法則

• 作者: トム デマルコ
• 出版社/メーカー: 日経BP社
• メディア: 単行本

質問者さんの状況を読ませてもらいましたので、それを読んだ感想を書かせていただきます。

>今は逆に会議ばかりです。議題に関係なく10人全員が参加しており、

>関係のない人は時間を無駄にしていますが、それを口にすることが

>できにくい状態です。

>また、その会議は、ゴールもアジェンダも存在せず、何が

>決定したのかが曖昧になり、効率はよくありません。

>時間も平気で5，6時間続くことがあり、それが週に3回ほどあります。

議題に関係なく全員が参加、というのはかなりまずいですね。

「ゴールもアジェンダも存在せず」なため、会議に参加が必要な人をしぼることができないのでしょう。

＃このへんは

デッドライン―ソフト開発を成功に導く101の法則

• 作者: トム デマルコ
• 出版社/メーカー: 日経BP社
• メディア: 単行本

でも載ってます。

＃結構おもしろい＆ところどころ参考になるのでお勧めしておきます。

>上記に述べたように、会議で決定した内容が残りません。

>（残ったとしても一部。また残しただけのものもある）

会議で決定した内容が残らないため、参加しなければ情報収集ができない状況なわけですね。

残しただけ、でもまだマシな状況ではあります。後から読めますから。究極に悲惨な状況では残す以前に作りませんので。

私としては、質問者さんが率先して議事録を作成して、決定事項・未確定事項を明確に残し、全員に配布するようにされることをお勧めします。そうすれば、

・「あれはどういう経緯で決まったんだっけ？」が無くなる

・決定事項が覆る場合、その責任の所在を明確にできる

という状況にできると思います。

デスマーチとは「いつ終わるかわからないプロジェクト」であり、その原因は「何をやれば終わるかがわからない」からですが「やるべきこと」さえ管理されていれば「いつかは終わるプロジェクト」にすることができます。

>メンバー間の仲が悪いわけではありません。

>逆に仲が悪くならないように、上の人（または声の大きな人）に

>遠慮しているという状態です（私や一部の人は提案はしますが、

>却下されるとそれ以上強く言わないという状態）。

私の場合ですが、一見仲が悪そうでも忌憚無く自分の言いたいこと（ここを決めてくれないと後工程はやりません、とか）をいう現場のほうが、後々問題ないので、そういう空気を作る努力をしています。

提案を却下された場合は、ちゃんと記録にしましょう。

私は「kshさんが却下したせいで、ここで問題が出てます」と明確に文句をいうよう、チームメンバに常々言っています。

プロジェクトにおいてリスクを感じた場合、「ここでこれを解決しなければ、この後が大変になるんじゃないですか？」と声を上げることは、立場の上下に関わらず大切なことだと思います。もちろん簡単なことではありませんが…。

いずれにしても、現状に危機感を感じ、ご自身で解決するために模索される質問者さんのスタンスはすばらしいと思います。そういうことは、スキルも経験もあるのにできない人間がたくさんいます。

ご自身が納得できるゴールにたどり着けることを祈っております。

何か出来たような気分・・・ですね。

画面だえが出来ている雰囲気にもみえますが

データフロー、キャパシティプランは大丈夫なのかな・・

ある程度出来ているなら早めに部内・関係部門と

レビュー等を行い細部の抜け・整合性確認していないと

後で仕様見直しパターンですね。

社内だとデスマーチなるまえに仕様見直しとかいって

先送になる気がします。

＞外部設計書に各画面の機能・・文章にしない

　標準化された画面構成でもあれば

　ある程度省略できそうな気もします。

　最終的に利用ガイド作成時何か必要ですが。

==========================================

もしかして後は一括外注では？

うーむ、基本的にPLって悪役になれないと厳しいかなあ。

少なくとも仕事上は冷徹に作業を進めるマシーンである必要があります。精神的なフォローはその後ですね。

１．私がチーム内で改善点を提案できないのは、経験が少ないため（上流工程や実装技術）、

実装技術は知っていれば確かに細かい突っ込みはできるんですけど、それはオプショナルですよ。

知り合いでプログラムのプの字も知らない女性でPLだかPMだかをやらされたけど、何とかプロジェクトを立ち上げるところまでやったひとがいます(その後メンテチームに引き継いだらしい)。

なので、システム開発・プロジェクト管理を徹底的に学ぶ。これによって自信をつけて、冷静に改善策を提案する。（交渉力も学ぶ）

これじゃ間に合わないのでできるところから少しずつやりましょう。まだ敗戦が確定したわけじゃないし「火消し」とか「ソフトランディング」も立派なPLの仕事ですよ。

例えば会議の議事録は必ずメールで共用する、次回までにやることの一覧を箇条書きにして担当者(責任者)と進捗(だいたい何パーセント完了したか、でもいいし、仕様検討段階、仕様設計段階、試作、実装、実装完了、単体テスト、システムテスト…、もしくはよく使われるCC,CF,FF,RC,GMみたいな用語で表してもよい)を管理する、ぐらいはすぐに始められると思います。実作業者側からするとこれは嫌でも何でもなくて、むしろそういうことができていない現状の方が自分の仕事がどこまで終わっているか、人の役に立っているかなどがわからない宙ぶらりんな気持ちで気分悪いはずです。

MS ScheduleでもExcelでもいいのでグラフ化して、もしくはその時間もなければ箇条書きのままでいいのでミーティングの始めにまずこれの確認からスタートするのがお勧め。

次にミーティングのやり方を変えましょう。朝、今日やることの確認、昼休み明けに進捗、夜に今日やったこと、やり残したこと、明日やることの確認　これらを全て１０～１５分、立ったままやります(スタンダップミーティング)。これでだらだらしなくなる。PLはそのために作業進捗状況を把握しておく必要があるので大変ですけど一回回りだすと差分の把握で済みます。

座ってやる定例は週の頭と終わりの２回ぐらいでいいでしょう。その他、そのときどきで出てきた懸案はすぐにメールでチーム全員に投げるようにする。で、問題が解決できそうにないときに定例での議題にします。

…とかかな。

非常にまずい状況ですね。

このままの状況だと確実にデスマーチになります。

懸念する状況は

・外部設計書に各画面の機能（画面に何を出すか、検索画面で何を

　検索の母数にするのかなど）を全く文章にしない事がチーム内で決定

　→　何故、そういうことが決定してしまったのでしょう？

　　　全員ということはあなたも出席しているはずで

　　　あなたはその理由を理解していないことになります

　　　これ以外にもあなたが理解していない決定事項や、

　　　他のメンバが理解していない決定事項が存在するという懸念があります

・その会議は、ゴールもアジェンダも存在せず、何が決定したのかが曖昧になり、

　効率はよくありません。時間も平気で5，6時間続くことがあり、それが週に3回ほどあります。

　→　会議が5,6時間って何してるんですか？

　　　人間の集中できる時間はせいぜい1,2時間です

　　　多分、会議時間が長すぎるから集中力がなくなり、上記のように

　　　経緯のわからない決定事項が出てきてしまうと思われます

　　　会議をするからには「何を議論するのか」「何が決定したのか」

　　　の記録を残しましょう。

　　　かなり面倒ですが、持ち回りで議事録を書き、それを全員に配布すれば

　　　上記の懸念はかなり払拭されると思います。

　　　後工程で嵌ってしまうのは上流工程で決定事項を曖昧にして

　　　見切り発車をしてしまうからです

・メンバー間の仲が悪いわけではありません。

　逆に仲が悪くならないように、上の人（または声の大きな人）に遠慮しているという状態です

　→　最大の懸念は上や声の大きい人に振り回されている状況です

　　　会社は「仲良しクラブ」ではありません。

　　　納得できないことはたとえ上に煙たがられても言うべきです

　　　というか、実はこの人達のせいで何も決まらないんじゃないですか？

まず、やらなければならないことは決定したことと、決定していないこと、不明点のリストアップです

そして、決定していないことはいつの会議で決定し、不明点は誰にいつまでに回答をもらうのか

というスケジュールを決めることです。これにより、

> 現在外部設計書を作成しておりますが、上手く進んでいません

という漠然とした不安感ではなく、具体的な危機感を共有できます。

けれど、その危機感を安易に回避するために決定しなければいけない事項を

後工程に先送りにするケースもありますのでそれはあなたが断じて拒否してください。