第7回（2023／7／14）デジタル座談会
テーマ「ITプロジェクトの失敗学～なぜ同じ失敗を繰り返すのか？ ～失敗事例を紐解く～第2弾」
今回はITプロジェクトの失敗学の第2回目となる。そして、今回はアジャイル開発にまつわる係争事例を取り上げ議論した。
◆ アジャイル開発宣言
まずは、Kent Beckらによって2001年に策定されたアジャイル宣言を確認した。
その要点は、
✔ プロセスやツールよりも個人との対話を、
✔ 包括的なドキュメントよりも動くソフトウェアを、
✔ 契約交渉よりも顧客との協調を、
✔ 計画に従うことよりも変化への対応を、
価値とする、である。
◆アジャイル開発の係争事例
- 事例1
クラウドのパッケージソフトを利用した新販売管理システムの刷新プロジェクトである。20億を超える規模の開発であった。
当初は、設計・開発フェーズをいくつかのスプリントに分けて実際に動く画面を確認しながら進行する予定であった。しかし、実際にはウォーターフォール型開発方式が用いられることになった。
また、パッケージソフトにもかかわらずカスタマイズ・アドオンが多く発生し、動く画面でレビューすることが一部にとどまった。つまり、画面レイアウトや遷移は、紙面上か動かない画面ショットをもとに行われた。
当事例においては、原告がユーザ企業で被告がITベンダとなる。上述のような、開発手法の誤りや、不適切なプロジェクト・マネージメントを採用した被告（ITベンダ）に賠償義務があるとの判決が下った。（ITベンダ側の敗訴）
- 事例2
次の事例は係争の規模は、100～200万円と大きくはない。
そして、こちらも原告がユーザ企業で、被告がITベンダである。
この事例では、原告のユーザ企業はウォーターフォール型開発と想定しており、その想定のもと「請負契約」を締結していた。
被告のITベンダが実際に行った方式はアジャイル方式であった。請負契約書で定めた引渡期限は、あくまで目安に過ぎないと主張する。
この裁判の結果もITベンダの敗訴となった。開発方式の共通認識がなされなかったことは不明であるが、あくまで契約書というものは裁判において重要であるとわかる。
つまり、アジャイル開発方式であるからといって契約書を軽視してはいけないということだ。
- 事例3
この事例は、既存のアプリケーションの修正・追加の事例となる。
原告はユーザ企業で被告はITベンダである。そして、ユーザとITベンダが握った開発は、見積書に6項目と記載され合意もされていた。
しかしながら、その6項目の開発内容についての情報や要求は曖昧なもので、開発及びフィードバックを繰り返していくうちにアジャイル開発方式のように進行した。特にその中で、実装の必要性を失った項目もあった。
裁判所の判断は、6項目実装の合意はあった、とした。こちらもベンダ側の敗訴であったが、開発対象から除外するか否かは重要な事項であるから、当事者間で共有できる紙面契約等の合意を形成すべきということがいえる。
ここから、実質アジャイル開発だからといって、締結された契約を無視した作業が認められるわけではない、ということがわかる。
- 事例4
開発方式はアジャイル開発であることが合意されていた。しかし、ITベンダは、画面イメージをユーザに提供するにとどまり、要件定義書や基本設計書はなかった。その理由が、アジャイル開発方式だから、とベンダは主張する。
この事例の裁判結果もITベンダの敗訴となった。
裁判所は、アジャイル開発方式であってもソフトウェアの機能や性能についてユーザ側の確認をとった資料は必要、とした。
つまり、少なくともユーザとベンダの合意を記録した紙面が大事、ということがいえる。
- 事例5
次の事例は、あるユーザ企業が基幹システムの刷新をITベンダに依頼して行ったものである。
この事例でも、ユーザ企業はアジャイル開発方式、ベンダはウォーターフォール方式と、そもそも合意がとれていない。
この裁判ではユーザ企業が敗訴している。そのユーザ企業においては、「業務効率アップ」「CRMの基礎作り」「経営の可視化」などをうたうが、どれも抽象的なものであり、ベンダがその達成を請け負うことのできる性質のものではなかった。
◆ディスカッション
- 事例1について
役割分担が明確でなかったのではないでしょうか？また、それらが契約なり書面なりで明確になると良かったと思います。
また、この案件では、パッケージソフトをかなりカスタマイズしている。これも日本でありがちな話で大きな問題です。
アジャイルだからドキュメントがない、ということは必ずしも正しくない。しかし、ドキュメントに重きを置かないことは事実でしょう。
しかし、ドキュメントがなかったとしても、最初のイテレーションで何らかの動くアプリケーションが存在しなければならない、と思います。
当該事例はまさにそこが問題で、動くソフトウェアは無く紙芝居でレビューが行われたことが問題でしょう。
または、正常系の一本道を作成することがいいかもしれません。つまり、エラー処理などは最初のスプリントでは考えません。その後、随時機能を追加することがいいと思います。
- 事例2について
請負契約であれば、あくまでウォーターフォールにしかなりませんね。
しかし、実質アジャイルとベンダは主張していますが、プロジェクトの不備についてアジャイルを言い訳の言葉に使っているようにも感じます。
そもそも、アジャイル開発と請負契約は水と油です。
はい、IPAもそう言っていますね。
しかし、ユーザ企業がベンダに責任を負って欲しい、という甘えが消えません。
また、アジャイル開発がそのもの何なのか？ということの認識も甘いですね。
少し余談ですが、この事例についても100万程度という少額なものです。弁護士費用のほうが高いかもしれません。それでも裁判を起こすという場合、かなり感情的なもつれが大きいのではないかと思います。
- 事例3について
「アジャイルのようなやりかた」、この言葉、ベンダでもユーザでもよく聞きます。
このような発言はほとんどアジャイル開発方式のことがわかっていないのでしょう。
このような曖昧な理解は危ないと感じています。
その通りだと思います。
とりあえず動くソフトウェアを作ってみて、という点は間違っていませんが、アジャイル開発で最も大事なのはスプリントです。そのスプリントで、ストーリ、ストーリポイント、チケットなどに還元してベロシティを測る、このような要素還元ができていないといけません。
顧客目線で価値を作る、ということにおいて、またDXという言葉もあります。そこで、アジャイル開発のことがわかっていないようでは問題です。
- 事例5について
この事例について、まず思ったことは、何故ベンダはこのような曖昧な要求で仕事を受けたのか？ということです。
そもそも、要件定義ができないユーザ企業が多いことも問題です。
ここの事例は、アジャイルとかウォーターフォールは関係ないでしょう。
ITベンダも仕事を欲しているのでしょう。ITベンダの営業の思惑と、実務部隊の思惑が異なる場合も多いと思います。
- その他全般について
アジャイル開発において向き不向きはあるのでしょうか？
処理方式や計算方法が決まっている領域、例えば会計などは、ウォーターフォールのほうがいい、という話があります。
対して、情報系やAI領域など、不確定要素が多い場合はアジャイル開発が向いているということも言われます。
しかし、果たしてそうでしょうか？
前者のような処理方式が決まっている分野、つまり会計や販売などの基幹業務においては、多くはパッケージソフトがあります。そして、それをカスタマイズしないということは大前提です。
パッケージソフトは出来上がったソフトウェアです。いきなり使ってみることができるものです。
であれば、いきなり打鍵ができます。
打鍵シナリオは、ストーリと呼ばれます。これをスプリント内で打鍵してみて、どのくらいこなせたか測定すればいいです。
つまり、パッケージソフトは最もアジャイル方式に向いています。
逆に、出来上がったソフトウェアをそのまま使う場合、何を要件定義するのか？何を設計するのでしょうか？
パッケージソフトのカスタマイズも大きな問題です。
パッケージソフト自体は、ベストプラクティスの結晶です。そして、多くの企業が日々使っているので高品質です。
カスタマイズした部分は、後から追加したプログラムですので品質が低い可能性があります。そして、カスタマイズしたいとう部分はベテラン社員が、今こうやっている、というこだわりとか、現状バイアスによるものでしょう。
アメリカでカスタマイズしないということは、トップからの指令で、これが大きいです。
◆ アジャイル開発版 情報システム・モデル（IPAより）の解説
IPAでは、非常に詳細に取引、契約についての取り決めをしています。しかし、あまり周知されていないのでしょうか。
特に、アジャイル開発においては、（請負契約ではなく）準委任契約である、と明記しています。
また、ベンダ企業に丸投げすると、ユーザ企業が真に求める価値が実現できない、とも明言されています。
適切なプロダクト・オーナの選任という項目においても、実際の利用者の参画について書かれています。
これらが、周知されればアジャイル開発の現場も変わるかもしれません。
以上、第7回デジタル座談会の要約になります。
（ファシリテータ 熊野憲辰）
