システム開発の開発モデルごとの法律上のメリット・デメリットとは

システム開発プロジェクトの進め方には、一定の方法論があります。通常、システム開発にまつわる法律問題について書籍などで学習を進める際には、ウォーターフォールモデルと呼ばれるもっとも古典的な手法を前提としていることが多いものです。しかし、システム開発を進めていくための方法論・モデルにあたるものは、なにもウォーターフォールモデルだけではありません。たとえば最近ではアジャイル開発モデルという手法が選択されることも多くなっています。

本記事では、ウォーターフォールモデルとアジャイル開発モデルの二つを、法的なリスク・紛争予防などの観点から比較しながら解説していきます。

開発モデルとは

ウォーターフォールモデルとは

システム開発の進め方として、もっとも一般的かつ古典的な進め方は、以下のようなものです。

• 要件定義：これから作るシステムが持っているべき機能、必要な仕様についての洗い出し
• 基本設計：画面設計・画面遷移など、主にシステムを操作するユーザー側の目線にたったシステムの全体像の設計
• 詳細設計：プログラムファイル同士のつながりなど、主にシステムを開発するベンダー側の目線にたったシステムの全体像の設計
• プログラミング実装：設計書に沿ったプログラムのコーディグ
• テスト：仕様通りのものができているかの検証を行い、ユーザーにも確認を依頼

このように、下っていく川の上流→下流へと、極力手順の前後や手戻りが起きないように進めていく開発手法は、「ウォーターフォールモデル」と呼ばれます。こうした流れ自体は、動くシステムを作るために必須なわけではありません。しかし、大勢の人手・長期にわたる期間をつぎ込んで進めるプロジェクトとなりがちなシステム開発では、計画性が重要になります。それゆえ、各工程の切り分け、役割の整理、各担当者の責任範囲の明確化といった事項も重要視される傾向もあるのです。

アジャイル開発モデルとは

一方、開発業務の進めかたは、いつでも「上流→下流」へと一気通貫させていくかのような手法が適するとは限りません。たしかに業務の性質上、計画性や見立ての技術が重要な点は、勿論いうまでもありません。しかし、そもそも新しいモノづくり・作品づくりにかかわる仕事である以上、完璧な意味での計画立案など最初から不可能である場合も多いのです。こうした点を重視するなら、一度たてた計画に沿って業務を進めることだけでなく、事後の修正・仕様の変更に柔軟に対応しやすくすることや、トライアンドエラーの反復回数を増やすことなどを重視したやり方もあってよいはずです。こちらの考え方を反映した開発手法は、「アジャイル開発モデル」と呼ばれます。アジャイル開発モデルでは、詳細な計画や設計書などを用意することには極力手間をかけず、ごく小さなプログラムを実装してはテストを繰り返し、徐々に大きなプログラム・システムへとつくり変えていくというような流れになるのが一般的です。

法律問題を学びやすいのはウォーターフォールモデル

なお、両開発モデルの比較に行く前に、前提として、それぞれの開発モデルに付随する法律問題について、情報収拾のし易さ・法律学習の行い易さについて触れておきます。

参考書籍の多くはウォーターフォールモデルを基本に書かれている

システム開発に関連する法律問題や、法律知識を勉強しようとする際、情報収拾のやり易さではウォーターフォールモデルに軍配があがります。システム開発について論じた法律書は多くの場合、ウォーターフォールモデルを前提として書かれています。古典的・一般的なシステム開発はウォーターフォールモデルに沿って行われるものであるため、そこではアジャイル開発は補足的な位置付けで、軽い紹介にとどまることが多いのです。したがって、システム開発に関連する法律問題について、書籍から情報を得ようとする場合には、ウォーターフォールモデルの方が学習が進めやすいといえます。

裁判例の蓄積が多いのもウォーターフォールモデル

また、ウォーターフォールモデルが、古典的・一般的なシステム開発の手法であることからは、過去に実際に起きた紛争事例の蓄積も豊富であるということもいえます。法律の議論では、条文もさることながら、過去の裁判例の知識も重要な意味を持ちます。条文の文言を読み解くだけでは「白」とも「黒」とも言いかねる事案に対しても、過去の裁判例から知見を得ることにより、条文の内容を補完することができる場合があるからです。

なお、明文化された法律でないとしても、裁判所が示してきた判断の蓄積は、あたかも条文と同じように判断基準として確立されていく場合があります。こうしたものは、「判例法理」と呼ばれます。システム開発などの話に限らず判例法理の蓄積がすでにある領域であれば、たとえ未知の紛争であっても、最終的な紛争の行く末を予想するのが比較的容易になる場合があります。こうした点で多くのメリットが見込めるのが、ウォーターフォールモデルに基づくシステム開発なのです。

それぞれの開発手法のメリット

上記の内容を踏まえて、以下、それぞれの手法を比較しながら、メリット・デメリットを整理していきます。前半がウォーターフォールモデルのメリットを中心とした整理となっており、下にいくほどアジャイル開発のメリットがわかりやすくなるように整理しています。

計画性・見通しの立てやすさでの比較　

計画性や見通しの立てやすさといった点では、ウォーターフォールモデルに軍配があがるといってよいでしょう。作るシステムがどれほど大規模であろうと、それは「上流→下流」へと下っていく各工程に必ず細分化されます。各工程ごとに締め切りを設定すれば、その進捗は比較的計画的に管理しやすくなります。

一方アジャイル開発は、事前の計画の立案や全体構想にあまり多くのコストや労力を割かない手法であるため、ともすれば場当たり的なアプローチになりがちだといえます。

個々の役割・責任範囲の明確化のしやすさでの比較

またウォーターフォールモデルでは工程がそれぞれ細かく細分化されることにより、個々のプロジェクトメンバーの役割を明確にできるというメリットがあります。

一方アジャイル開発では、工程の区分が曖昧になりがちなので、不測のトラブルなどに対し、誰が責任をとるのかといった点についても曖昧になりやすい傾向があります。

大規模開発のやりやすさでの比較　

計画性や役割整理の点で優れたウォーターフォールモデルは、大規模開発ほどメリットが大きくなります。多数の人員を組織しながらであっても、工程を細分化して分業を促進しておけば、人間関係の調整にかかるコストは小さくすることができます。

一方アジャイル開発モデルは、大規模開発にはあまり適していないとされています。計画性や役割整理よりも、着手までのスピード感を重視するアプローチであるだけに、最終的な納期のズレなどが懸念される場面には適用しにくいのです。

スピード感・効率性での比較

アジャイル開発のほうが着手は早い

ユーザー側が何か機能の要望を抱いてから、それが実際に実装されるまでのスピード感では、アジャイル開発モデルに軍配が上がります。なぜなら、ウォーターフォールモデルでは、上流工程と下流工程で担当者が明確に分離するのが通常であり、ベンダー側内部でのコミュニケーションの手間が多くなりがちだからです。こうしたコミュニケーションの手間が多くかかりがちな点は、事後の仕様変更リクエストに弱くなりやすい点ともつながるところです。

一方アジャイル開発モデルは、あえて仲介役を立てることなくスピード感をもって着手・実行に移っていくことが期待できます。このことは、事後の仕様変更への対応が容易であるという、アジャイル開発モデルの最大のメリットとも密接に関連するところです。もっとも、たとえアジャイル開発モデルであっても、仕様変更・追加開発のリクエストになし崩し的に応じ続けてしまえば、それはプロジェクトを「炎上」させかねないリスクともなります。この意味でも、アジャイル開発モデルによるシステム開発は、「変更管理」をいかにして行うかが成功の鍵となります。変更管理についての詳細な説明は、以下の記事にて行なっています。

ウォーターフォールモデルの方が途中で頓挫はしにくい

一方、スピード感・効率という観点からの比較において、長期的な時間軸で検討することも重要でしょう。プロジェクトが途中で炎上し、途中から進捗がなくなってしまうようなリスクを考えた場合には、ウォーターフォールモデルに軍配があがります。プロジェクトが途中で頓挫してしまうという事態を引き起こす最大のリスクは、ユーザーとベンダーのコミュニケーション不全です。両者の役割分担を明確にし易いウォーターフォールモデルは、この点でメリットがあります。

検収段階でスムーズに進めやすいのはアジャイル開発　

しかし、検収段階における話の進め易さという観点からは、ややアジャイル開発モデルに分があると言えます。なぜなら、ユーザーとベンダーで、システム開発の途中経過でも細かく情報共有を行うことが前提となるからです。最終的に出来上がった成果物を見て、両者の認識の齟齬が一気に顕在化するといったリスクを小さくすることが期待できます。なお、システム開発の検収というステップに関する解説と、それに付随する法律問題は以下の記事にて詳細に扱っています。

まとめ　

このように比較していくと、全体的に、管理の徹底に資するのはウォーターフォールモデルであり、着手や実行に至るまでのスピード感を重視するのがアジャイル開発モデルであるというように整理できます。なお、アジャイル開発モデルに基づくシステム開発に付随する法律問題については、以下の記事にて詳細に扱っています。

どちらの開発モデルが適するかは、法律という観点もさることながら、プロジェクトの規模・予算・目的なども踏まえて、総合的に判断すべきものであると考えられます。