情報Ⅰを勉強している高校生に「システム開発モデルの違い」を聞かれたらどう答えるか??のサムネイル
デジタルテクノロジー

情報Ⅰを勉強している高校生に「システム開発モデルの違い」を聞かれたらどう答えるか??

高校では2022年度から「情報Ⅰ」が必履修科目となっています。「情報Ⅰ」は2025年度の大学入学共通テストから、新たに出題科目として設定され、多くの国立大が受験を必須としています。文部科学省の<【情報編】高等学校学習指導要領(平成30年告示)では、「情報システムの開発のプロセス」について、以下のように教育内容を定めています。
<ウォーターフォール,プロトタイピング,アジャイル,スパイラルなどの開発モデルを取り上げ,情報システムの開発の各工程における内容や特徴,作業手順及び情報システムのライフサイクルなどを扱う>
https://www.mext.go.jp/a_menu/shotou/new-cs/1407074.htm

では、具体的に開発モデルがどう違って、どう使い分けられているのか…?
今回は、開発モデルの違いを高校生にも分かるように具体的に説明してみようと思います。

まずはシステム開発手法の「よくある誤解」を紹介

最初に「教科書的な説明をそのまま受け取るとどのような誤解が発生し得るか?」を考えてみます。

最近、LTSが制作したホワイトペーパーの中でIT産業の変遷に触れており、その中でウォーターフォールとアジャイルの開発モデルの違いが説明されていました。

LTS発行のホワイトペーパーより抜粋して図を作成

その説明をもとに、IT業界初心者の広報担当Tさんに「ウォーターフォールとアジャイル開発の特徴」をまとめてもらいました。

●アジャイル
「アジャイル(agile)」は「素早い・機敏な」という意味です。システムを開発する際、後述する「ウォーターフォール(Waterfall)」では、機敏な対応はできませんでした。そこで仕様・設計変更は発生すること、不確実であることを前提に2000年代初期から普及し始めました。仕様は厳密に定めず設計、開発、テスト、リリースといった工程を1週間から2カ月間の単位で繰り返し、徐々に開発を進めていきます。

▽主なメリット
・変化に柔軟なITシステムをつくれる
・開発コストを抑制できる
▽主なデメリット
・厳密な仕様を決めないため、開発の方向性がブレやすい
・仕様変更に柔軟に対応できるため、かえって変更・追加が増えてしまいがち

●ウォーターフォール
アジャイルとよく比較されるのが「ウォーターフォール(Waterfall)」です。技術進化が緩やかだった1980~1990年代に中心だった手法です。仕様から基本・詳細設計、コーディング、テストと上から下に水が流れるように進むため、こう呼ばれました。仕様が確定していて、長期間をかけて開発する基幹系など大型システム開発に向いています。
日本の企業は、自社の業務プロセスに合うようにシステム開発をする傾向があります。ERPパッケージを導入する場合でも、自社の業務プロセスに合うようなカスタマイズします。そのため開発は複雑かつ大規模となり、綿密な設計と工程管理が可能なウォーターフォールが支持されました。また、開発を受注した元請け企業が基本設計を行い、詳細設計、プログラミングといった後工程を下請け・パートナー企業に発注する分業・多重下請け構造の要因ともなりました。
今後、ERPはじめ多くのシステム、ソフトウェアがクラウドに移行すると、必要なエンジニアの数も減る可能性が高く、ウォーターフォールを使うケースは減少するとみられています。

▽主なメリット
・仕様が明確なため、開発の方向性はブレにくい
・予算や計画が明確で、一定以上の品質が期待できる
▽主なデメリット
・仕様が見直しとなった場合、コストが大幅に増え納期が遅れる
・品質を重視するため開発期間が長期化する
・新しい機能の実装など事業環境の変化には対応しにくい

分かりやすくまとまっていますが、IT業界の経験がある人が読むと気になるところがいくつかありますね。
問題は、以下の2つのように感じます。

  1. 現在の企業IT開発の状況から振り返る形でアジャイルとウォーターフォールの違いにフォーカスしている(結果ありきになっている)
  2. 企業の基幹システムの特徴と開発手法の特徴が混同されている

この説明の問題点をいくつか挙げてみます。

  • 時系列でいえばウォーターフォールから説明すべきだがアジャイルから説明している→「ウォーターフォールは過去の開発手法で、現代はアジャイルが主流。今後はウォーターフォールからアジャイルへ変化する」という誤解がありそう
  • アジャイルなら開発コストを抑制できる…かどうかは分からない。ウォーターフォールに大規模開発が多くアジャイルは小~中規模での開発が多いため、前提のコストが異なり単純比較は難しい
  • 自社業務に合わせてカスタマイズして大規模になるからウォーターフォールが選択される…のではなく、もともと業務システム開発が大規模開発のため必然的にウォーターフォールが選択される
  • ウォーターフォールは「仕様が明確なため開発の方向性がブレない」とあるが、設計と開発など各工程を分業することが前提のため「仕様を(無理にでも)明確にしないと先の工程に進めない(次の工程が着手できない)」が実態。ウォーターフォールによって仕様の明確さが担保される訳ではない
  • 「品質重視のために開発期間が長期化」とあるが、これはウォーターフォールという開発手法の問題ではなく、企業の基幹システムという業務の特性が間違いを許容できないから
  • 「新しい機能の実装など事業環境の変化に対応しにくい」とあるが、これはビジネスモデルの定まっている大きな企業は機能別組織が形成されているため、全く新しい環境への適応が難しいという一般的な大企業の特徴であって、開発手法の問題ではない

高校生に説明する開発モデルのストーリーテリング

それでは、「高校生に分かるように開発モデルの違いを説明する」には、どのような説明がよいか考えてみましょう。

システム開発はITの歴史と歩みを同じくして進化してきました。また、前述の説明の問題点を考慮すると、結果からの説明では誤りが発生し得るので時系列での説明がよさそうです。ですので、

  1. ITの歴史をなぞりつつ「システムがどのように作られて使われてきたか?」をストーリー立てて説明する
    さらに、企業システムでは例として難しいと思いますので、
  2. 高校生にも分かりやすいようにゲーム開発を例にウォーターフォールとアジャイルを解説する
    の流れで書いてみようと思います。

コンピューターの進化とシステム開発

業務用コンピュータでの大規模開発の時代

1960年代から、ITシステムが企業の業務(売上計算の一括処理等)に使われるようになりました。
初期の業務用コンピュータはメインフレームやオフコン(オフィスコンピュータ)と呼ばれる巨大な計算装置で、企業の事務処理に特化した装置でした。
大規模な業務用コンピュータは、例えば銀行業務や鉄道旅券の予約発券などの業務に使われました。巨大な業務のシステム開発は長い時間と費用をかけて実現されました。
このように、巨大な設備や機械(ビルや自動車など)を組み立てるように、設計・開発・組み立て・テストなどの複数の工程(フェーズ)を経て、長い時間をかけて完成に至る大規模なシステム開発の手法を「水が上流から下流に流れること」に例えられる「ウォーターフォール手法」と呼ばれます。ウォーターフォールは現在でも長期間・大規模で複雑なシステムを開発する一般的な手法として用いられています。

パソコンの登場とソフトウェア開発手法の多様化

次第に、個人用のコンピュータ(パーソナルコンピューター:パソコン・PC)が普及しました。パソコンは特定の処理だけを目的としたオフコンとは違い、汎用的に多様な目的で使えます。それを実現したのは「パソコンにソフトウェアをインスト―ルして使う」という今でも一般的な利用方法です。
高価なオフコンを買えない(買うほどの規模ではない)中小企業でも、家電量販店で購入したパソコンに会計ソフトをインスト―ルすることでシステムを業務利用することができるようになりました。

インターネットの登場によるシステム利用の変化

また時代が流れ、今度はインターネットが普及します。この頃から「ソフトウェアを購入してパソコンにインストールする」方法からさらに進化した「インターネット上でITサービス企業が提供しているWebサービスを使う」というモデルに変化していきます。パソコンとインターネットがあれば、ソフトウェアのインストールという手間も不要になったのです。

インターネット上のWebサービスとして提供されるシステムを使う利点は他にもあります。例えば、消費税の税率は2014年に5%から8%になりました。さらに2019年から商品によって8%と10%の消費税が混在しています。消費税5%の頃に買ってきてインストールした会計ソフトでは消費税8%に対応できませんし、その先の8%と10%の混在に対処するのはもっと難しいでしょう。しかし、ITサービス企業がインターネット上で提供する会計システムなら、提供元がシステムを改修してくれるので、そのまま使い続けられます(実際はそんなに簡単ではないですがWebサービスのほうが楽なのは間違いありません)。

このように、顧客(ユーザー)が使っている状態のソフトウェアを状況・要望に応じて定期的に改善・変更してリリースしていく開発モデルを「アジャイル」と呼びます。

ゲーム開発の変遷から見たウォーターフォールとアジャイル

この流れはゲーム開発の歴史にも例えられます。昔は「ゲーム機本体とゲームソフトを買って家のテレビでゲームをする」のが普通でしたが、インターネットとパソコン・スマートフォンの普及により「インターネット経由で提供されるゲームをパソコンやスマホで楽しむ」モデルに替わりました。

従来の「ゲームソフト」は発売日に向けて設計・開発・テストを経て製品化(発売)されるモデルで「ウォーターフォール開発」で作られます。一度発売されたソフトは買った人の手元にあるので、あとから改善する・追加開発することは基本的にはできません。続編を制作することになったとしても、また同じように設計・開発・テストを経て発売されるのでウォーターフォールです。

対してインターネット経由で提供されるゲームは、ゲームの企画・開発・テストを最初のリリースまでは実施するものの(なので最初は小規模なウォーターフォール開発と言えます)、最低限遊べる状態まで作ってリリースした後は、機能やシナリオの追加・改善を繰り返すという開発手法になります。
このようにリリース後の状況に合わせて開発を定期的に繰り返すモデルは「アジャイル開発」です。売り切り型ではないので最初のリリース後も利用料や課金という形で収益を得ます。そのため、ウォーターフォールとアジャイルは開発手法が異なるだけではなく、収益を上げる仕組みやタイミング、リリース後の運営費用の有無、サービス開発・運営する人の必要スキルや働き方も異なります。

まとめ

アジャイルだけで完結するシステム開発は多くありません。最低限の機能を開発してリリース、という表現が誤解を招くのですが、多くの場合「最低限の機能」といっても一定規模のシステム開発が必要になります(特に企業の業務システムの場合)。最低限の機能の開発までは実質「ウォーターフォール」で行われます。
逆に、ウォーターフォールで開発された企業の業務システムも、最初は最低限の機能でリリースし、使い始めてから機能を追加するケースは多いです。この場合、導入後の運用フェーズがアジャイル的になります。

おまけ1:ウォーターフォールとアジャイルの違い

ここからはさらに私見になります。
ウォーターフォールとアジャイルの違いですが、私はIT産業の歴史と発展に強い関連があると思っています。ITが産業化される中で、開発ルールの整備、専門性の分化、開発期間の短縮化、開発の大規模化が進んだ結果、開発フェーズごとの分業体制が当たり前になりました。
要件定義ができる人はシステム開発プロジェクトの要件定義だけ担当して、そのプロジェクトが開発フェーズに進む頃には別のプロジェクトの要件定義に移ります。プログラミング技術で開発を担当するエンジニアも同様です。最初から最後まで見ているのは全体を管理しているプロジェクトマネージャーくらいです。
この分業制により、多くのシステム開発プロジェクトが同時並行で進められるようになりました。しかしその一方で、役割による分断が起き、炎上する開発プロジェクトも増えていきます。
このような状況への対応のひとつの形として「分業で起きていた責任の限定化をなくす」「全員が1チーム・全員が同じ目標を持って開発する」アジャイルの手法が生まれた……と考えています。

この分野を専門としていない人間の私見なので、気になる方は専門的な解説も参照してみてください。

おまけ2:プロトタイピングとスパイラル

プロトタイピングとスパイラルという開発手法も高校の必修科目「情報Ⅰ」で扱う(名前だけ出てくる?)ようです。
プロトタイピングはその名の通りプロトタイプを作って使ってみて評価する手法ですが、あくまで初期開発時の評価アプロ―チとして使われることが多い印象です。前述のウォーターフォールやアジャイルのような開発方法論と同列にすべきではないのでは?…と思います。
スパイラルは正直なところ経験がなく事例も知らないのでよく分からないのですが、ChapGPTに聞いてみたところ「スパイラルは医療、宇宙開発、軍事など、ミスや間違いが許されない場面で、かつ機能を評価しつつ機能単位で精緻化させるような手法」とのことなので、一般的な業務システム開発とは切り離して考えてよさそうです。

忰田 雄也(LTS マーケティング&セールス部 部長代行)

SE・テクニカルライターを経て、LTS入社。ERP導入や業務改革におけるユーザー向け広報・教育企画および業務文書改善など組織コミュニケーションに関連するコンサルティングに従事。2017年よりLTSコンサルティング事業のマーケティングを担当。2021年より本サイト「CLOVER Light」の立ち上げ~運営・編集長を務める。(2024年1月時点)