- ベストアンサー
こんなプロジェクトは火を噴く
皆様の経験から学んだことを教えてください。 ちなみに私は ・マネージャークラスの人間がソースを読んでいない ・会議が多い ・抽象的 ・流行の業界？用語、手法を使う ・製造より設計 ・外注依存 かなと思っています。 私自身が一流企業に行った事が無いのでレベルが低いのかもしれないのですが、、、
- その他([技術者向] コンピューター)
- 回答数6
- ありがとう数5
- みんなの回答 （6）
- 専門家の回答
質問者が選んだベストアンサー
No.5訂正 ANo.4に追加->No.3に追加 10)連携不足 a)責任範囲が明確にされてなく、各人が自分の担当外 だと思っている所に抜けが発生する。 b)自分の担当範囲以外は見ない。 c)各人が自分のやりたい事しかやりたがらない。 各人が自分の役割を果たしつつ、他の人の援護も同時 に行い目的達成を目指す。 そういった事をする為に最も適した組織は存在の善し 悪しは別として、軍隊だと思っています。 ＃上記の様な事をしていたら自分の命にかかわります。 小人数での開発でなら、個人の能力次第でなんとかでき ますが、大きな開発プロジェクトでは、そういった組織的 行動がとれる様にしていかなければ火を吹く以外の選択肢 は無い様に思います。 11)現状を変えようとしない。 プログラムにバグがあればデバッグするのは当然の 事なのだから、仕事の進め方にバグが有るならこれも 改善(デバッグ)していくべきでは？ しかし、ネットで検索をしても、同じ様な事が良く あるのでしょうがない事だとして諦めるケースが多い 様に見えます。 もともと技術者は、今までに無い物を作るのが本業 なのですから、自らの灰色の脳細胞を駆使して、新たな 対処方を考える様でなければ技術者失格とも言える様に 思います。
その他の回答 (5)
- don_go
- ベストアンサー率31% (336/1059)
ANo.4に追加 8)仕様の未確定と仕様変更の区別をつけていない。 現時点で仕様が確定できずに保留にしている作業項目 は、スケジュール内に対処する為の時間を考慮しておく 必要があります。 でないと、突然に仕様の追加変更作業が湧いて出たか の様な事態になり混乱します。 9)人員配置、作業分担が不適切 メンバーのスキルが異なるっているのに、それを考慮 せずに一律に同じ仕事が割り振られている。 皿洗いをシェフがやって、メインディッシュを新人に 調理させるのと同様な事が、当然の如く行われている。
- Wr5
- ベストアンサー率53% (2173/4061)
すでにたいてい書かれていますが… 最近遭遇したものだと。 ・最初からスケジュールに無理がある。 機能追加だから、ということなのかスケジュールが短めに設定されていたようです。 いろいろ問題が噴出して結果２ヶ月程度遅れました。 ・不具合修正が場当たり的 不具合の報告をして修正されても、原因などの調査を行う時間がなかったのか、場当たり的な修正で後から別の不具合を盛り込んでしまい、不具合の発生件数が増えていく。 そして修正件数より発生件数の方が多くなって破綻する。 # プログラマーなどに連日の徹夜などを強いて、思考能力低下していたのかも知れませんが。 ・仕様理解していないまま作業する 火の噴いたプロジェクトに追加人員投入して火消しをもくろんでも、追加された人員が仕様を正しく理解していないと不具合増産するだけです。 マネジメントの方がこの辺理解していないと、往々にして発生する…らしいですが。 # 昔、ゲームのCGで「1枚1日でできるなら、外注100人使えば100枚が1日で終わるよな。」とおっしゃられた社長がいましたけど。 他に、不具合報告ほかも含み1日に400通超のメールがメーリングリストで流れる現場に行ったことあります。 まともにメール処理していたらそれだけで半日以上費やしそうな勢いでした。 そのためメール見ない人もそれなりに……。 数日休むとメールボックスがパンクするっていうのはちょっと……。
お礼
スケジュールに無理があるというのは 上の人間がコードを読んでいないのに原因があると思います。 不具合修正が場当たり的に関しては、私もあります。 結局作り直したほうがいいんじゃないかと思ったり。。。
- don_go
- ベストアンサー率31% (336/1059)
1)マネージャークラスの人間がソースを読んでいない マネージャークラスがソースを読む必要性は無いと 思います。 しかしPGのすぐ上の所にはソースレビューができる 人を配置する事は重要です。 優秀なPGが１人で作れるプログラム本数には限度が 有ります。 それより、そのPGをソースレビューに回して駄目な プログラムの発生を抑える方が効果的。 ＃その優秀なPGには、他のPGでは難しい所にしぼって ＃プログラムを作ってもらいましょう。 コーディング規約に合っていない物や、下手なプロ グラムは早期発見、早期治療が重要。 でないと、駄目プログラムが大量増殖します。 そうなってからでは手遅れ。 ＃他人数での開発でソースのレビューを複数人で行う ＃場合は、複数のソースレビューの担当者を同席して ＃レビューを行う事で、各人の意識統一を図る事も ＃必要です。(初期及び随時) 2)会議が多い 「無駄な」会議は不要 但し、各人の思い違いをなくす為の意見交換は重要 3)抽象的 ↑自体が何を指しているのか不明 4)流行の業界？用語、手法を使う 火を吹く直接的な原因では無いと思います。 自分の力量を知らない、又は客先の要望を認識できて いない。 ＃客先が望んでいるのは新技術ではなく、日常の業務で ＃使える物のはず。 5)製造より設計 何を意図しているのか不明です。 a)製造より設計を重視する事が火を吹く原因 b)製造より設計を重視すべきである c)その他 議事録や仕様書でも表現が曖昧で、意味がどちらとも とれる様な場合、火を吹く可能性が高くなります。 a)、b)共に「設計」「製造」のどちらが重要かという より前段階としての「施工設計」部分が抜けている事の 方が問題でしょう。 6)外注依存 外注を使う事自体ではなく使いかたが下手。 スキルの高い人間ばかり集めようとしますが、星付き シェフばかりを集めてレストランを開こうとしている様 な物。(まず第一に十分な数の人間を集めるのが困難) それに、頭数を集めるだけで、勝手気ままにするのに まかせるだけでは、例えスキルの高い人間が集まっても 単なる烏合の衆にしかなりません。 ----------------------------------------------- 7)ドキュメントの不良 大勢の人間が参照するドキュメントは短時間で参照でき 且つ理解しやすい物にする事で作業効率及び精度を上げる 効果が高いのに、いい加減にしている所が多い様です。 a)ドキュメントの記述内容が曖昧・記述不足 ドキュメントの記述だけでは、処理内容や使用方法 が良くわからない。 制限事項等の記載洩れ モジュールのソースが公開されていれば、それを解析 できるが、時間がかかる。 b)具体的な使い方の記述が不十分 処理の開始・終了を１組にして使わなければいけない モジュールの説明を別のドキュメントに記述していたり すると終了処理の記述を入れるのに気付かない様な事が 発生しやすくなる。 c)必要としている機能が、どこ(ファイル)に有るかが 見付けづらい。 ＃結局、各人が同じ様な処理をあちこちに作る事になる。 d)ドキュメントが無い 論外....
お礼
色々指摘してくださいましてありがとうございます。
- ryo872
- ベストアンサー率51% (37/72)
プログラム関連のカテなのでソフト開発のプロジェクトの事を仰っているのでしょうか。小生自身はプログラマーでもなく、ソフト開発の企業で働いた事もないので良く判りませんが、ごく一般的に「プロジェクトの破綻」と言うのであれば（ソフト開発にもある程度当てはまると思いますが）最も危険なのは、収入（の予測）、支出（の予測）、及び技術的な問題点（リスクの事。支出が予想以上に大きくなり、収入と支出の差である利益を圧迫する事になる）をきちんとプロジェクトの初期段階で押さえない、と言う点でしょう。 リスクは考えれば考えるほど出て来るので「考えうる全てのリスク」は理想であり、現実的とは言えません。しかし、発生する問題の可能性が大きいものは少なくとも考慮し、リスクをとれるだけの利益が出るようにプロジェクトを組めば良い訳です（当然それらのリスクを事前に認識する為には想像力が必要でしょう）。 マネージャーの資質、会議が好きな社内の風土、など色々ありますが、そのような問題はどこの会社にもある筈で、ちゃらんぽらんな会社でも上記のリスクの認識やコストマインドがあれば結果的に利益が出ます。利益が出れば御の字では？あとは効率化の問題でしょうか。
お礼
ソフト開発の目的は"実際に動くモノ"を作ることだと思います。 やはり、上の人間が製造工程まで全てを知らなければいけないと思います。
- tohru999
- ベストアンサー率49% (76/154)
基本的に、プログラム設計書がしっかりしていないと駄目ですね。 後は、プロジェクトマネージャー(まとめ役)のスケジュール管理能力が低いと、 開発規模に対して、無茶なスケジュールとなる場合がある。 また、納期が決定しているのにもかかわらず、仕様変更が多々ある。 ぐらいですかね。
お礼
そもそもスケジュールや見積もりなんて 完全に全仕様と全ソースを理解した人じゃないと難しいのでしょうね
お礼
皆様たくさんの回答ありがとうございました。