下記、前回記事の続きです。アジャイル開発モデルの弱点・アンチパターンを挙げていきます。

製造業の大量生産プロセスに関連するプロジェクト

自動車・自動車部品・電子製品などの組み立て系、もしくは化学製品・金属・鉄鋼・紙・パルプ・薬品・ガラス等のプロセス系（流体・ガス・粉体など形が一定ではない材料を主に扱い、反応や合成といった工程を使って製品製造）の製造業では、生産工程の微調整を行うだけで、生産ラインにかかわる工作機器の設定変更・テスト、原材料の配合比率の変更・検証、サプライチェーンをまたがる内示・発注・物流・在庫管理プロセスの変更調整等、大きな変更対応コストが発生するケースがあります。

試作ラインで変更検証するにしても、原材料が高価であり、試作自体のコストが高い業種もありえます。

当該業界・業種に関連するシステムの開発プロジェクトでは、短サイクルで変更を繰り返すことによりユーザーが求める機能を精度高く作り上げていくアジャイル開発モデルは、費用対効果が見合うか、採用前に効果検証が必要です。

法律対応などの期日までの開発完了が必須なプロジェクト

EUのGDPR（General Data Protection Regulation：一般データ保護規則）対応、インボイス対応など、期日までに対応が必須となるシステム開発プロジェクトには、発注側としては請負契約と組み合わせたウォーターフォール開発モデルの方が適している可能性があります。

通常、アジャイル開発モデルは、アウトプットなる成果物をユーザーからのフィードバックに基づいて柔軟に変更していく手法であるため、準委任契約となるケースが多いです。

準委任契約は状況の変化に応じて柔軟に対応できるメリットがありますが、業務委託によって作成する成果物を完成させる必要がなく（履行割合型準委任契約の場合。2020年4月１日に施行された改正民法で登場した「成果完成型準委任契約」では「成果物を納品後に報酬を支払う」となります。ただし、成果物作成自体を完成させる義務は、両者ともにありません。）、善管注意義務を果たしていれば、納期内の完成責任もありません。

発注元企業側がアジャイル開発に積極的にコミット・参画できないプロジェクト

アジャイル開発は、実際に動くシステムをユーザーに使ってもらい、改善のフィードバックを得て、短サイクルで変更を繰り返すことで、価値を創出する開発手法です。

発注元のユーザー企業が、プロジェクトに時間を取れず積極的に検証・改善のフィードバックを開発側にできないのであれば、アジャイル開発モデルはうまく機能しません。

アジャイル開発であるのに、ユーザー企業側が請負契約に固執する場合も、うまくいかないケースが多いです。請負契約の場合、開発側は期限内での成果物完成責任を負うため、ユーザー企業は好んで選択しますが、アジャイル開発モデルでは作成する成果物がプロジェクトの状況によって柔軟に変更していく手法であるため、請負契約とは相性が悪いです。

発注元企業に予算制約がある場合も、工夫が必要です。アジャイル開発モデルで開発する機能を追加・変更していき、予算を超えそうになる場合は、事前に発注元・開発側で協議する等のプロセスが必要になるでしょう。

最後に、ChatGPTの回答を記載しておきます。

サマリ

製造業の大量生産プロセスに関連するプロジェクト、法律対応などの期日までの開発完了が必須なプロジェクト、発注元企業側がアジャイル開発に積極的にコミット・参画できないプロジェクトでは、アジャイル開発モデルの適用には工夫が必要です。