アジャイル開発の外部委託契約で失敗しないための注意点とリスク対処方法

プロジェクトファシリテーターのじゅんです。

2020/03/31に、IPAよりアジャイル開発版「情報システム・モデル取引・契約書」が公開されました。

私は、普段企業向けにCIO代行というサービスを行っており、企業個別に守秘義務契約を結んでいるため、これまで事例を紹介したくても公開することができないということが多くありました。

企業間のプロジェクトを実施する際の契約に関しては、あとで揉めることを防ぐために事前に合意することはとても重要なことです。弁護士を交えてチェックするのは当然ですが、実務となると弁護士の方でもわからない場面が出てきます。そんなときに契約書上で、実務で抑えるべき点を入れてもらい後のトラブルを防ぐことが重要です。

今回公開された資料はとても参考になるので、事業会社がアジャイル開発をITベンダに依頼する場合などにお役立てください。

なお、記事の内容は、IPAの以下のサイトより資料がダウンロードできます。

https://www.ipa.go.jp/ikc/reports/20200331_1.html

この記事は私自身が迅速にお客様に提示したり、確認したりできるように書いたものです。

（PDFとかエクセルをダウンロードして開くのってちょっとした手間ですけど面倒ですよね・・・）

スポンサーリンク

アジャイル開発の外部委託契約で失敗しないためのチェック項目とリスク対処方法

資料の中には契約締結前に抑えておくべきポイントがまとめてあります。

また、エクセルの資料の中には、チェックポイントの詳細説明とチェック項目が満たされなかった場合のリスク、そして、そのリスクに対する対応方法が書かれています。

本記事ではその内容すべてを書かせていただきます。実際のプロジェクトを行う際は、エクセルファイルを使用してそれぞれのチェック項目が満たされているかをチェックすることをおすすめします。

※IPAサイトより 契約前チェックリストのチェックポイント

1. プロジェクトの目的・ゴールのチェック

チェックポイントの説明

ユーザ企業が、開発対象プロダクトにより達成しようとするプロジェクトの目的（少なくとも当面のゴール）を明確にして、ユーザ企業内の関連事業部のみならず上層部等も含めたステークホルダーの間で認識を共有すべき

クリアできない場合のリスク

・目的が不明確なままだと、開発対象プロダクトのビジョンが明らかにならず、作業が滞るおそれ
（関係者を含め、無駄な動きが増えるため、コストに応じたアウトプットを得られなくなるおそれ）

・ステークホルダーと認識が共有されていないと、プロジェクトの途中で方向性が変わるおそれ

リスクを回避するための対応

・ユーザ企業内で問題分析や検討を行い、社内での認識合わせを行う
（どのような技術的な対応策がありうるかについては、ベンダ企業にアドバイスを求める）

・ユーザ企業の内外における、プロジェクトのステークホルダーの範囲を確認する

・インセプションデッキ等のツールを活用する

2. プロダクトのビジョンのチェック

チェックポイントの説明

ユーザ企業が、プロジェクトの目的を達成するための開発対象プロダクトのビジョンを明確にして、ユーザ企業内の関連事業部のみならず上層部も含めたステークホルダーの間で認識を共有すべき

クリアできない場合のリスク

・ビジョンが不明確なままだと、開発対象プロダクトの方向性が示されず、作業が滞るおそれ（関係者を含め、無駄な動きが増えるため、コストに応じたアウトプットを得られなくなるおそれ）

・ステークホルダーと認識が共有されていないと、プロジェクトの途中で方向性が変わるおそれ

リスクを回避するための対応

・どのような技術的な対応策がありうるかについては、ベンダ企業にアドバイスを求めながら、ユーザ企業内において検討を行い、社内での認識合わせを行う

・インセプションデッキ等のツールを活用する

3. アジャイル開発に関する理解のチェック

チェックポイントの説明

プロジェクトの関係者（スクラムチーム構成員及びステークホルダー）がアジャイル開発の価値観を理解しているか

「アジャイルソフトウェア開発宣言の読みとき方」(IPA）https://www.ipa.go.jp/files/000065601.pdf

等を用いて、アジャイルソフトウェア開発宣言とその背後にある原則を理解すべき

プロジェクトの関係者がスクラムを理解しているか

本契約が前提とする開発手法はスクラムであるため、プロジェクトの関係者は、以下のような資料を用いて、スクラムにおける構成員の役割や、開発の進め方について理解すべき

「スクラムガイド」（Ken Schwaber and Jeff Sutherland、日本語版もウェブで公開されている）
https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf

「アジャイル開発の進め方」（IPA）
https://www.ipa.go.jp/files/000065606.pdf

クリアできない場合のリスク

・アジャイル開発（及びスクラム開発）に対する基礎的な理解がなければ、開発のプロセスが適切に進まず、失敗するおそれ

【ベンダ企業側に理解がない場合】
・ユーザ企業とのコミュニケーション不足により、開発が停滞し、ユーザ企業のビジョンと異なるアウトプットを出してしまうおそれ
・開発チームが自律的に動けず、パフォーマンスが向上しない

【ユーザ企業側に理解がない場合】
・ユーザ企業が積極的に関与せずとも開発が進むとの誤解のもと、開発が停滞し、ユーザ企業のビジョンと異なるアウトプットが出てきてしまうおそれ
・生産性向上、開発コスト削減を目的としてアジャイル開発を選んだ場合、過剰な期待により初期のスクラムチームのパフォーマンスに失望し、アジャイル開発が真価を発揮しないままプロジェクト打ち切りという事態になるおそれ

リスクを回避するための対応

・チェックポイントの説明の資料等を用いて理解を行う

・スクラムに関する研修を受講する

・プロジェクトの最初にプロセスを理解するための試行期間を置く

4. 開発対象のチェック

開発対象プロダクトがアジャイル開発に適しているか

以下のような場合はアジャイル開発に適していることが多い

・複雑、不確実で変動対応性が多く、試行しながらの開発が求められる場合
・エンドユーザの要求や市場環境の変化に伴い、開発対象を柔軟に追加・変更することが求められる場合
・継続的なリリースを行い、顧客・市場からのフィードバックを得ながらソフトウェアを改善させる必要がある場合

クリアできない場合のリスク

・変動要素が少ない場合（仕事がパターン化されて単純なタスクの場合や、当初から開発対象が明確でありかつ固定されている場合）は、アジャイル開発を適用するとかえって非効率となるおそれ

・開発対象プロダクトがストーリーに分割しづらい場合は、アジャイル開発になじまず、かえって開発が滞るおそれ

リスクを回避するための対応

・開発を検討しているプロダクトがアジャイル開発に適しているか、ベンダ企業からアドバイスを得る

・プロダクトオーナー研修を受講し、アジャイル開発が適切か否かを判断できるノウハウを得る

１チーム（最大で10名程度）の継続的対応にて、開発可能な規模であるか

本契約では、複数チームへのスケールやハイブリッドは対象としていない

クリアできない場合のリスク

複数チームの場合は、チーム間の調整を含む、もう一段上のレベルでの調整を行わなければ、プロジェクト全体が混乱するおそれ

リスクを回避するための対応

複数チームの進捗や連携等を管理・調整するための連絡協議会等を設置する

5.初期計画のチェック

プロジェクトの初期計画が立案されているか

プロジェクト開始にあたり、アジャイル開発を実施するための初期計画を立案すべき

１．プロジェクト計画策定
２．マスタースケジュールの調整やマイルストーンの調整
３．リリース後の継続的な運用環境の計画

クリアできない場合のリスク

アジャイル開発がスムーズに進行しないおそれ

リスクを回避するための対応

プロジェクト立ち上げ時に関係者が一同に会して初期計画を立案し、その後も適宜直しを継続的に行う

プロジェクトの基礎設計が行われているか

プロジェクト開始にあたり、アジャイル開発を実施するために、代表的な初期の要求事項とアーキテクチャの分析／設計及び開発環境の設計を行うべき

　１．初期の要求事項とアーキテクチャの分析／設計
　２．開発環境の設計

必要があれば、スパイクを実施して検証を行ってから進めるべき

クリアできない場合のリスク

アジャイル開発がスムーズに進行しないおそれ

リスクを回避するための対応

ベンダ企業のアドバイスを受けながら、必要な基礎設計を行う

完了基準、品質基準が明確になっているか

・ストーリーとタスクの細分化について認識を合わせる（ユーザーストーリーの詳細化のイメージを合わせる）べき
・全バックログに共通する、ストーリーの出口条件となる完了基準を明確にすべき
・直近、数スプリント分のプロダクトバックログの完了基準を明確にすべき

クリアできない場合のリスク

・ストーリーが完了しているか否か判定できず、プロセスが停滞するおそれ

・不十分なものが完了と扱われると、後で追加作業が必要となるおそれ

リスクを回避するための対応

ベンダ企業のアドバイスを受けながら、明確な基準を設定する

十分な初期バックログがあるか（関係者間で初期のスコープの範囲が合意できているか）

案件により異なるが、最初のリリース計画時にリリース1.5～2回分程度のバックログは用意しておくべき

クリアできない場合のリスク

・バックログ不足で作業が中断するおそれ

・スコープの変更管理でスムーズに進まないおそれ

リスクを回避するための対応

・ベンダ企業のアドバイスを受けながら、事前に価値探索、仮説検証を行う

・ユーザストーリーマッピングなどでスコープを価値単位で合意する

6.本契約に関する理解のチェック

チェックポイントの説明

本契約を用いる前提として、以下のことを理解すべき

・最初にスコープを決めるのではなく柔軟に変えることで価値の最大化を図るのがアジャイル開発の特徴であり、スコープが固定される請負契約での対応は難しいため、本契約は準委任を前提としていること

・準委任契約においては、ベンダ企業はプロダクトの完成義務や契約不適合責任を負わず、ITの専門家として要求される水準の注意を払って業務を行う義務（善管注意義務）を負うこと

クリアできない場合のリスク

契約に基づく権利義務関係について、トラブルが生じるおそれ

リスクを回避するための対応

本契約の内容について、十分な認識合わせを行う

7.体制（共通）のチェック

チェックポイントの説明

・役割分担： 開発対象プロダクトの方向性や内容決定は、当該プロダクトを必要としているユーザ企業が責任を持つ体制とすべき

・具体的な体制： 開発対象プロダクトの開発のために必要な人員（アジャイル開発のほか、業務要件、システム要件（インフラ含む）、利用予定技術、品質管理などに関する経験も考慮）を配置すべき

クリアできない場合のリスク

ユーザ企業が開発対象プロダクトの方向性や内容決定までベンダ企業に丸投げするような役割分担になっていると、ユーザ企業が真に求める価値が実現できないおそれ

リスクを回避するための対応

アジャイル開発の特徴及びプロジェクトの内容に応じた適切な体制を確保する

8.ユーザの体制のチェック

適切なプロダクトオーナーを選任し、権限委譲ができるか

主に以下のようなことを行うために必要な能力、権限を有し、かつ十分な稼働時間を確保できるプロダクトオーナーを選任し、必要な権限委譲を行うべき

(i) ユーザ企業内のステークホルダーの要求を整理して開発対象プロダクトのスコープと優先順位を判断できる
(ii) 開発されたプロダクトについて、事前に定めた完了基準や品質基準を満たしているかどうか、リリース可能かどうかについて判断できる
(iii) スプリントプランニングとスプリントレトロスペクティブ（ふりかえり）に参加でき、開発チームにユーザとしての意思決定を伝えることができる
(iv) 開発チームから情報提供又は意思決定の要請があった場合には、速やかに回答することができる

クリアできない場合のリスク

・要求が明確にならず、作業が滞るおそれ

・作業が完了せず、リリースが遅延するおそれ

・開発チームとのコミュニケーションが不足し、問題発生時の処置が遅れるおそれ

・ステークホルダーとの認識の相違が後から発覚することにより、作業遅延や手戻り等が生じるおそれ

ユーザ企業としてプロダクトオーナーへの協力ができるか

ユーザ企業の関係者（ステークホルダーを含む）は、アジャイル開発チームが価値の最大化をできるよう、プロダクトオーナーが開発対象プロダクトに関する最終意思決定機関であることを理解し、プロジェクト成功のために、プロダクトオーナーの迅速な意思決定を積極的にサポートすべき

クリアできない場合のリスク

ユーザ企業内での意見統一やステークホルダー等関係者からのフィードバックが十分に得られず、プロダクトが目的とする価値が提供できないおそれ

リスクを回避するための対応

・プロダクトオーナー研修を受講する

・試行期間を導入する

・ベンダ企業又は第三者から、プロダクトオーナ補佐（コンサルタント／アドバイザリー）を選任し、プロダクトオーナーを補助する

・複数名でプロダクトオーナーチームを構成し、役割を分担し対応する（ただし最終決定者１名をあらかじめ決めておく）

9.ベンダの体制のチェックポイント

アジャイル開発の経験を有するスクラムマスターが選任できるか

スクラムを円滑に実施するため、十分な経験・実績を有するスクラムマスターを選任すべき

クリアできない場合のリスク

・スクラムの各種イベントが正しく実施できないおそれ

・開発チームが成熟せず、パフォーマンスが上がらないおそれ

・課題が解消されず残るおそれ

必要な能力を有する開発チームを構成できるか

開発に際しては、設計・実装・インフラなど、複数の技術が常に必要となるため、必要な能力やスキルセットを満たすよう開発チームを構成すべき

クリアできない場合のリスク

作業が遅延するおそれ

開発チームを固定できるか

開発メンバーを固定することで、アジャイル開発の習熟度が高まり、また自律性も高まるため、人員変更はなるべく避けるべき

クリアできない場合のリスク

チームが自律的に動けないおそれ

リスクを回避するための対応

プロジェクトの内容や期間を考慮の上、適切な人選を行う

本日の提案｜アジャイル開発はIPAのチェックポイントを活用して失敗しないようにしましょう！

・アジャイル開発は、ビジネス環境の変化が読めないから計画を立てなくて良いという意味ではない

・ユーザ企業、ITベンダ企業共にアジャイル開発の特徴を理解した上で協働する必要がある

・IPAのアジャイル開発におけるチェックポイントを活用することで認識のズレをなくし、考慮ポイントの抜け漏れを防ぐことができる

・実際にチェックを行う際は、IPAからダウンロードできるエクセルを使ってもれなくチェックしましょう

出典：IPA　情報処理推進機構

アジャイル開発版「情報システム・モデル取引・契約書」
～ユーザ／ベンダ間の緊密な協働によるシステム開発で、DXを推進～https://www.ipa.go.jp/ikc/reports/20200331_1.html

投稿者プロフィール

じゅんプロジェクトファシリテーター

フリーランスのITコンサルタント として、CIO代行サービスで多くの企業をサポートしています。
企業のIT戦略 立案・実行支援を行い、
ITを活用した情報システム の導入・マネジメント支援しています。
IT利活用 に関して気軽な相談から経営に関わる支援まで幅広く受け付けています。

普段私が仕事をする時にお客様やプロジェクトチームの方々に実際に話している内容をたくさんの方々に届けます。

DX（デジタルトランスフォーメーション）が好きすぎるので「DX王子」と呼ばれています。

最新の投稿

この著者の記事一覧

• 仕事術2024年8月29日面談前に職務経歴書などの提出をお願いする理由を解説します！
• フリーランス2024年3月22日フリーランス年収1000万を目指すなら「誰の言葉か？」が重要
• 仕事術2024年3月19日なぜオンラインミーティングを録画するのか！？メリットしか無いからです！
• フリーランス2024年3月4日50歳以上のエンジニアに送る！あなたに仕事がない理由