はじめに
こんにちは。エンジニアの仕事をしている、たかふみです。
本日はシステム開発はなぜ炎上するのかについて、まとめたいと思います。
炎上する現場の特徴:人を集めれば良いと思っている
駄目なプロジェクトの特徴として、無理に人を集めることが原因です。
プロジェクトが上手く行かないから、人を増やして解決しようとする。
しかし、人が必要じゃないんですよ。優秀な人が必要なんです。
ロクに仕事のできない人間を１００人集めるより、１人の優秀なエンジニアを雇ったほうがいいのです。
人月の神話という本があります。
人月計算でシステム開発はできない、というような内容で
いくら人を集めても、管理コストが増えていくので、システム開発は人を増やすことによりスケジュールが遅延する。
という内容ですが、マネジメントをする方は、必ず読んでほしいですね。
人を増やすことは、炎上の鎮火にはならず、余計に炎を燃やします。
炎上プロジェクトで人を増やすことは、火に油を注ぐような危険行為なのです。
SIerの立場からすれば、人が増えれば増えるほど、利益があがります。
SIerは人を入れたがるし、発注者は人を増やせば解決できると思ってる。
こうしてプロジェクトは炎上し、システム開発は失敗するのです。
無駄に大人数を使って開発させても炎上の元です。
少数精鋭の開発が望ましいですね。
炎上する現場の特徴:誰かに丸投げすれば解決する
とりあえず作っておいてほしい。みたいなスタンスでシステムを発注されても困る。
そりゃ、ちゃんと、ウォーターフォール的な工程で、要件定義し、仕様を詰めて、開発する、という流れだったら良いのですが、期日だけ決められて、なんとなく発注するのは無理である。
具体的にどういうものを作って欲しいのか、RFPやRFIをまとめて発注するべきなのです。
しかし、世の中の多くの一般企業はそういったドキュメントをまとめる能力は無く、適当に発注して大損して、莫大な金額を支払ったことに対して憤怒するのです。
アジャイル開発で小さいシステムをちょっとづつ作っていくような感じで 開発を進めることが理想です。
炎上する現場の特徴:複数の会社で一つの仕事をさせる
一つのプロジェクトを複数のベンダーにお願いしたとします。
たとえば、サーバーサイドと、フロントエンドでA社とB社に分業したとか。
するとどうなるでしょう。
この処理は、そっちがやるべきだ！とか
バグが出たらサーバーサイド側のせいだ！いや、フロントエンドが悪いんだ！などと、お互いを責め合い、憎しみ合っていくのです。
同じ会社で、分業するならまだよかったかもしれません。
一つプロジェクトを、違うベンダーで進めると、お互いが責め合い、自社の利益を主張し、開発はまとまりを欠けて混沌としていきます。
しかし、複数のベンダーを混ぜても成功するケースもあります。
発注者側の会社が、主導権を握り、A社はここまでやって、B社はここまでやってほしいと、ちゃんとベンダーコントロールすれば問題はありません。
問題は、何もしなくてもシステム開発ができると思ってる発注者が多いということです。
会社は利益を求めるものなのだから、自分の主義主張を述べるものです。
しかし、複数の会社が主張しあってても、システムは完成しません。
ベンダー側もかなり疲弊して撤退していく場合もありえます。
システム開発は、請負契約ではなく、業務委託契約を締結して進めることがあります。
請負契約に完成義務はありません。
良心のある管理者の元、作業を進めるのです。
つまり、作業を進めるのが仕事であって、システム開発を納品させることは義務ではないのです。
したがって、発注者側の企業が主体性を持って、仕様を考え、ベンダーをコントロールしなければならないのです。
SIerに責任はありませんからね。よくシステム開発会社に訴訟沙汰が起こったりしますが、しばしば発注者側が負けています。
そりゃ、SIer側は、お金を貰うことが目的であって、システムの完成は二の次だからね（笑）
そうやって企業は痛い目を見て、ベンダーに頼ることを辞め、自社開発を始めていくのです。
まとめ
いかがでしたでしょうか 。
苦い思い出を振り返りながらブログにしました。
皆様の開発のお役に立てたら光栄です。読んで頂いてありがとうございました。
