システム開発プロセスを代表的な2つのモデルで解説

コラムカテゴリー：ITコンサルティング, プロジェクトマネジメント, 開発プロセス

はじめに：このコラムで得られること

本コラムは、発注側担当者・PM・開発リーダー向けに、システム開発プロセスをどのように選択すればよいかをつかむためのガイドです。

システム開発プロセスには、例えば代表的なものにウォーターフォール／アジャイル／スパイラルなどのモデルがありますが、本コラムではこれらのモデルがどういったものであるかの説明は行いません。すでに良い説明記事がインターネット上で多く見つけられますし、探すのが大変であればAIチャットに聞いてみるのも良いでしょう。この部分はそちらに譲り、これらのモデルについて基本的な知識がある前提で、本コラムでは、実際にはこれらのモデルをどのように選択するのかという部分に焦点を当てて説明しようと思います。

そもそも何が問題でこれらのモデルが必要とされるのかを明らかにし、ウォーターフォール／アジャイルの２つのモデルを例に、それぞれのモデルがこの問題にどう対処するのかを示し、最後に具体的に実際のプロジェクトではどう選択されているのかを見てみるといった流れで進みたいと思います。

システム開発プロセスの問題とは何か？

何のためにシステムを開発するのかと言えば、もちろん「ビジネス価値を生むため」です。ビジネス価値とは、売上・効率・リスク低減・顧客体験・学習（知見化）などのことで、システム開発はこれらに寄与することが目的です。

では、開発プロセスの目的は何か。真の目的がビジネス価値の創出にあるので、プロセスの目的は基本的には「最適なルートでそこへ至ること」だと言えます。

しかし、ここで問題になるのが、「最適なルート」というのは多くの場合一意に決まらないことです。理由は、システム開発には常に「複数の不確実性」が絡み合い、かつ、しばしばこれらはトレードオフの関係にあるからです。例えば、機能を多く盛り込んだり、パフォーマンスを高く保つ必要があったり、あるいは、多くの利害関係者と丁寧に合意を取りながら進める必要があったりすれば、システムを提供できるタイミングは遅くなってしまいますし、コストも上がってしまうわけです。どれを重要と考え、どの順序で何を確定するかが「最適」な選択肢を変化させます。システム開発プロセスの問題は、この最適なルートを設計・実行することにあるのです。

開発プロセスモデルとは、この問題に対するアプローチです。共通していることは、不確実性を計画的に減らす方法を教えてくれることです。そして違いは、どの不確実性を重要と考えるか、どの順番で決めていくかが違うのです。

開発プロセスモデルの「心」を例で理解

この章では、代表的な開発プロセスモデルである「ウォーターフォール」「アジャイル」の２つのモデルを取り上げ、その「心」=どの不確実性を重要と考え、どう対処しようとしているのかを掴みたいと思います。ここでは厳密性はある程度犠牲にして、カレー作りに例えて感覚的に理解できるように試みます。

ウォーターフォールの心：先に確約

ウォーターフォールの心は、「何を作るのか」「いつできるのか」「いくらでできるのか」を「先に確約する」ことにあります。これは、通常の買い物と似ているので直感的で掴みやすいですね。作られるシステムがどんなもので、いつ使い始められて、そしていくらなのかが事前にわかると買うかどうかの意思決定もしやすいですし、システムを使った別の計画も立てやすくなります。

カレー作りで感覚を掴む：

父：「今日は、18:00におじいちゃんとおばあちゃんが遊びに来ます。一緒に夕飯を食べようと思っているのですが、せっかくなので家族みんなで手作りしてもてなそうと思います。」
兄：「さっきおじいちゃんに電話してみたら、辛い物が好きと言っていたので、グリーンカレーを作るのはどうかな？」　
みんな：「賛成！」
母：「では、17:30には出来上がるようにしましょうか。予算は奮発して、1万円まで良しとします。」
妹：「じゃあ、私はお昼に出かける用事があるから、帰りについでにスーパーへ行って材料を買ってくるね。」
父：「では、他のみんなでお部屋と料理の準備をすることにしようか。」

強み：

• 作ったカレーでおもてなし会を行うなど、他の計画との連携が必要なものに有効。
• カレーパーティーイベントなど、１回しか行われないものに有効。
• 大量のカレーを皆で協力して作るなど、多人数で協働する必要があるものに有効。

トレードオフ：

「事前に確約する」部分にポイントがあるため、

• 途中の計画変更に弱い。後段になるにつれ、計画変更の影響が大きくなる傾向にある。
• 「作り始めてみないとわからない」や「使ってみないとわからない」といった類のものには不向き。

向いている案件の性質と具体事例：

• 性質：やり直せない、関係者が多い、締切・予算が固定のもの
• 事例：基幹システムの導入・更新、規制／監査対応の改修

アジャイルの心：早く出して学ぶ

アジャイルの心は、「なぜ作るのか」「何を作るのか」を「早い段階から実測で学ぶ」ことにあります。どんなに完璧に計画通りに作り上げても、作ろうとしているものがそもそも間違っていたら意味がないわけです。そして、「なぜ」や「何を」は言語化が難しく、形のないシステムというものを対象とする場合は特に問題となりやすいのです。アジャイルはこの部分を重要視し、「早く出して学ぶ」という戦略のもと、簡単なものから小さく作って実際の場面で提供して不確実性を減少させていくことを短いスパンで繰り返す方法を取ります。

カレー作りで感覚を掴む：

父：「今後の我が家の食卓を豊かなものにするため、『我が家の究極カレー』のレシピを開発したいと思います。」
みんな：「賛成！」
母：「わたしはスープカレーが結構好き。でも、キーマカレーも捨てがたい。」
兄：「辛けりゃ何でもうまい！」
妹：「そもそもどんなカレーがあったっけ？」

（後日）
父：「この前は意見をありがとう。聞いた内容からちょっと作ってみました。まずはルーだけなんだけど、どうかな？」
母：「うん、これ好き」
兄：「確かに辛くていいんだけど、このココナッツミルクの感じは嫌い」
妹：「食べたことなかった味だけど、これおいしくて好き」

（後日）
父：「ルーを少し変えて、メインの具を入れてみたよ。どうだろうか？」
（・・・続く）

強み：

• 「究極のカレーとは何か？」「自分は何が好きなのか？」など、ゴールの形を誰もわかっていないものに有効。仮説が外れても、小さく試しているので、痛みが小さい。

トレードオフ：

• 最終的にどんなカレーになるのかあらかじめ見通すことが難しいため、他の計画との連携がとりづらい。
• 頻繁に機能変更が入るため、利用者側の学習コストがかかる。

向いている案件の性質と具体事例：

• 性質：学習速度が価値、Why / What / How の不確実性が大、スコープ可変にできるもの
• 事例：新規プロダクトのMVP (Minimum Viable Product：実用最小限の製品)、利用者の反応で変わりやすいUI / UX

実際のプロジェクトでの選択例

実際のプロジェクトでは、すべてがきれいにどれかの開発プロセスモデルに分類できるわけではありません。ですので、多くの場合、多かれ少なかれ「ハイブリッド型」のモデルを採用することになります。

例えば、大企業における基幹系システムの開発を行う場合をあげてみたいと思います。大企業の基幹系システムですので、かなり多くのユーザーが想定されます。また、単純に数が多いだけでなく、事業ごとに事業の特性を反映した業務フローになっていたり、中央集約的に業務を代行するような部署があり、大量操作が必要だったりと、様々な使われ方がされたりします。そして、基本的には流量が多いので、それぞれ運用の最適化が進んでいます。まとめると、傾向として下記のような力学が働きやすいです。

1. マニュアル変更や運用変更などの学習コストが高いため、変更を嫌がる
2. 規模が大きいので、「作ったけど使えませんでした。」は避けたい
3. 業務の統一が難しく、一定の個別最適された業務フローは残す判断となる

「1」の要求からはウォーターフォールが最適なのですが、「2」の要求からはアジャイルで対応したい。つまり、きれいにどちらかを選ぶことができません。そこで、例えば「3」の性質に注目し、中央集約部署の運用だけをスコープとした開発を「フェーズ1」として行い、その利用実績を分析後に「フェーズ2」「フェーズ3」として違う部署や違う運用パターンをスコープに後続開発していき、全社に広げていくといった方法を取ったりします。これにより、「1」の変更の影響を最小にしつつも、「2」の実際に利用できるものであるかのテストも行えるようにするのです。

この時の開発プロセスモデルは、それぞれのフェーズだけをみればウォーターフォールモデルとなっていて、すべてのフェーズを俯瞰してみると、フェーズ単位でリリースを繰り返すアジャイルモデルとなっている、「ハイブリッドモデル」となっています。

まとめ

システム開発プロセスとは、不確実性を計画的に減らす仕組みです。しかし、不確実性は多くの場合、複数がトレードオフの関係で存在しているため、最適ルートを一意には決められません。ウォーターフォール／アジャイル／スパイラルなどといった開発プロセスモデルは、それぞれが重要と考える不確実性を持っており、その不確実性を優先して減らす開発プロセスを提供してくれます。ですので、どのモデルを選択するかは、それぞれのモデルの「心」を理解しないとできません。

本コラムでは、「ウォーターフォール」と「アジャイル」について取り上げましたが、同様の考え方で他のモデルも読み解いていただけると、様々なケースに適したハイブリッドモデルを効果的に構築できるのではないかと思います。

関連サービス

2025年09月22日 (月)

青山システムコンサルティング株式会社

宿谷大志