このページについて

炎上してたり、うまく回っていなかったりなプロジェクトを色々見てきて、
こんなことやってるから上手くいかないんじゃないの？と思ったことを書いていくページです。

何事にも期限がない

日々のタスク、課題、QAなど、すべてにおいて期限がないプロジェクト。
どうやって説明しているのか不明ですが、こういうプロジェクトも存在します。
この場合、期限がないため能力的にコーディングが遅かろうが、不具合多発で修正に時間がかかろうが、
残業する理由がないため、残業してまで頑張ってくれるようなエンジニアは希少種なもんで、
確実に工程が後ろに倒れていき失敗します。

どんなものにも期日は必ず設定（少し厳しめの方がパフォーマンスは上がる）しましょう。

仕様が二転三転する

アジャイルであれば、変更を受け入れながら開発する（変更する場合は、他の機能を切り捨てるなどの交渉が発生する）ので、対象外。
ここではウォータフォールが対象です。
仕様が二転三転すると何が起こるかというと、仕様を決定する側の信用がなくなる&開発者のモチベーションが下がります。
後者は生産性に直結し、前者については、開発者が言うことを聞かなくなる可能性をはらんでいます。
特に問題なのが前者の信用をなくすというもので、
プロジェクト失敗の槍玉にあげられるなどの二次的被害が発生し、精神的な問題でプロジェクトから退場する可能性が上がるように感じています。
プロジェクトから退場することで、仕様を曲がりなりにも抑えていたお方を失うことになり、
引き継ぎもままならぬ状態で代役を立てないといけなくなるため、さらなる泥沼化になる可能性があります。（変わった人が超有能で立て直すパターンもありますが、それは稀）

仕様が二転三転すると色々な箇所に火種が生まれるので、基本的には仕様が確定する前は作業させないのが吉です。
（そうもいかないことがあることも承知していますが）

YESマン

顧客に言われたことは絶対なのか、単にソフトの作りが判っていないのか不明ですが、
顧客に言われたことをすべて飲んでしまうような調整をすると破綻します。

顧客と仕様の調整をする人は、ソフトウェアがどのような作りか把握しておく（開発者へのヒアリングでも良いでしょう）ことは必須です。
現状のソフトの作りと１８０°違うような仕様変更を受け入れれば開発者の怒りを買い、信用&やる気低下による生産性低下を招きます。
客も鬼ではない場合がほとんどなので、ソフトの作り的に工数がかかる場合は、交渉しましょう。
交渉した結果、時間がかかりすぎる場合は、しょうがないからこのまま行くかということもありますし、
MUSTだから工数上乗せしてでもやってくださいということになります。

意思決定者がいない

誰も仕様を決めない、決めれない、責任を取る気がないのか、自信がないのか不明な状態です。
上記ができないようなオーナーは害悪なので、正直退場していただきたいですね。

使ったことのないフレームワークを使う

個人的には使ったって良いと思うけど、それは業務外で十二分に勉強したらです。
たいていのものは初見だとハマりポイントがあり、リリースまでに地雷をほぼすべて踏むと思います。
（僕もこれをやって、ほぼ全部地雷を踏みました。。規模大きくなかったから何とかなったけど大規模なら死亡してたよ確実に。。。）

実戦投入したことのないフレームワークは一通り使ってから実戦投入しましょう。
（最初に試せる工数を確保できるなら、それでもOK。ただ、本当の地雷は本気で使い込むような状況（仕事）でないとなかなか判らないです)

環境作れる人がいない

特にUnix系。
環境を作れる人が一人でもいると開発者のレベルがう〜ん。。な感じでも割となんとかなってしまうというのがあります。
これは、WindowsならWindowsのソフトばかりやってきた技術者、LinuxならLinuxばかりやってきた技術者、OSごとにある程度ハマりポイントが同じなため地雷を踏むことを防げるからです。
※アプリを作る人はインフラ周りはとりあえず、環境を作れる人のアドバイスをもらいながら（ハマりポイントが分かっているから）組めば、あまり事故なくものが作れてしまう。
逆にアプリを乗っけるOSに環境構築できる人間がいないと、結合テストや総合テストで思わぬ事故に遭う確率が上がります。

ある一定以上のプログラマに普段やらないようなコードを書かせるような方式設計をしている

これは地雷を踏む可能性が格段に上がると思っています。
（自分で言うのもナンですが、Javaだったらそれなりのレベルです！と思ってます）
ある程度のレベルのプログラマは地雷を無意識のうちに避けながらプログラムを書いています。
（一流の人は、ほとんど地雷を知ってて避けている感じがしますが。）
そのレベルの人たちに、この方法はヤバいんじゃないかな〜？と思わせるようなものを書かせることは、
単体、結合レベルでは問題なくても、システムテストで負荷をかけた時に大概よくない結果を招きます。

数値で示せとか、問題が出てから考えるという人がおられますが、
こう言う部分は結果云々よりも彼らの経験に耳を傾けた方が良いと思います。
（たいてい問題が発生するので）

その他

何か他にもあったら（思い出したら）書きます。