アジャイル開発の受託案件失敗の要因と対策について

受託開発が失敗する要因と対策みたいなものをお伝えできればと思います。
 あくまで、ミッションクリティカルなガチガチのウォーターフロー型ではなく、アジャイルの要素を取り入れた開発のお話を想定しています。

発注企業側の要因
（A）よくある要因

【組織要因】
プロジェクトマネージャーが優秀ではない
自信過剰の割に、業務やゴールが分かっておらず、しかも 社内での人望が薄く、巻き込み力もない。
また、個人の主観で、仕様変更を繰り返すため、受入テストの段階で、現場責任者からダメだしの連発が発生する。

プロジェクトを遂行するだけのチームができていない
名ばかりの責任者はいて、何も判断できないが、定例会議にだけ出てきて、好き勝手言うセクション責任者はいるなど、
結果として、何が正しい仕様のかよく分からない状態になり開発が進まない。

【リソース/期間】
プロジェクトオーナー(中小企業なら代表取締役、大企業なら部長や執行役員などの、予算決定者)が、システム開発のQCDを理解しておらす、
結果として、無茶な仕様追加によりQCDを担保できなくなり、大抵炎上する。

（B）受託企業側が採るべき対策

優秀なプロジェクトマネージャーがいる場合
当然だが、プロジェクトマネージャーの信頼を得るのが重要。 大抵、そのようなプロジェクトマネージャーはハードワークかつアウトプットのクオリティーも高いので、まずはハードワークかつレスポンスの速さで勝つ。

また、そのようなマネージャーは社内調整で圧倒的に苦労しているので、信頼を得たら、寄り添い、一緒に考え、プロジェクトメンバーやプロジェクトオーナーのハンドリングを一緒に考える。
ここまでやると、基本的にプロジェクトはうまく回るが、それでも月一回は必ずプロジェクトオーナーに直セル報告する機会を持つ。

優秀なプロジェクトマネージャーがいない場合
大抵、プロジェクトオーナーの力が強すぎ、セクショナリズムが強い企業で発生する状態。
プロジェクトオーナーを握りに行き、任せてもらえる状態を作り、自らが、プロジェクトリーダーとなり、各セクションの責任者や現場の責任者を巻き込んだチーム組成を行う。

業務要件定義から入り、各責任者の想いが強い要件もしっかり入れることで、圧倒的に仲良くなり、チャットで気軽にコミュニケーションをとれる状態にする。せめて1か月に1回は、プロジェクトメンバー＋プロジェクトオーナーに報告する場を作り、根回しも済ましたうえで、しっかり決めていく。

受託企業側の要因
（A）よくある要因

【組織要因】
プロジェクトマネジャーの能力不足
プロジェクトマネージャーが優秀ではなく、QCDの肌感覚がなかったり、技術に疎かったりで、適切な意思決定ができない

機能分化
QCD的に、無茶な条件での案件獲得 セールスやトップ営業は売上最大化のために、無茶な条件でも獲得してしまい、またそれが無茶な条件であることにも気付いていない。発注側も、それが無茶な条件かどうかを把握できていない。

開発メンバー側も、仕様全体像を把握しようとせず、行間を読まないまま、使えないシステムを開発する。 こういった商流の多さによるコミュニケーションロスが主な原因となる。

【技術力】
言語やフレームワークの経験、或いは、業種システムの経験などだけで判断してしまう。
結果として、新技術へのキャッチアップなど含め、やり遂げられない状態が生じる。

（B）発注企業側が採る対策

企業規模などや、ホームページに載ってる実績などで安易に判断しない。
準委任だろうが受託だろうかにかかわらず、プロジェクトメンバー全員と会う。
QCDに対する質問に、適切に回答できるかどうかなどから、プロジェクトマネージャーが、優秀かを確認する。
プロジェクトメンバーが、仕事を全うできるだけのコミット力がありそうか確認する。 *プロダクトを確認する。
開発実績がある実際のプロダクトをデモしてもらう。
実際の開発者にも立ち会ってもらい、自社が作りたいシステムも作れそうか確認する。
以上です！！参考にしてもらえれば幸いです。