DX時代のシステムはなぜ“アジャイル”であるべきなのか

このコラムの第3回（「SoR」「SoE」そして「SoI」の違いを理解しておくべき理由）では、「旧来のまま使われ続けているSoRの運用保守コストが、DX推進の“足かせ”になっている」こと、そしてDXで重要な「SoE」は、SoRで一般的だった「ウォーターフォール型」ではなく、柔軟さとスピードを重視した「アジャイル型」の開発方法で作られるべきであることについて触れました。

• 

  SoRとSoEでは適した開発方法論が異なる（出典元：Ridgelinez）

今回は「ウォーターフォール」と「アジャイル」という、新旧の開発方法の違いについて、より詳しく紹介します。

「ウォーターフォール」ではDX時代のシステムニーズに応えられない

「ウォーターフォール」は、多くの企業がシステム開発に利用してきた方法です。ウォーターフォールでは、最初に「何を作るか」を決め、そこから全体の計画を固め、それに従ってシステムを作っていきます。「ウォーターフォール」は「滝」を意味しますが、滝では水が上から下へ一方向で流れ、逆流することはありません。この呼び名は、計画に沿って一方向に進めていく開発工程を、滝での水の流れになぞらえています。

• 

  「計画の順守」を重要視するウォーターフォール開発モデル（出典元：Ridgelinez）

ウォーターフォール型のソフトウェア開発手法は、もともと「メインフレーム」と呼ばれる大型コンピューターが企業システムの主役だった時代に、開発プロジェクトを失敗なく進めることを意図して適用されるようになりました。

当時は、ビジネスにコンピューターを利用していること自体が、企業にとって差別化の要因になりました。標準的な機能をレディメイドで提供する「パッケージ」としてのアプリケーションは普及しておらず、コンピューター上でビジネスアプリケーションを利用したい場合には、自社のニーズに合わせて一から専用のソフトを作るケースがほとんどでした。ハードウェアも高価で、システムの導入や活用に、非常に多くのコストが必要な時代だったのです。

そのころ、業務に利用するシステムは、一般的に約5年後を目安として、性能や容量を計画的に使い切るように設計されていました。ウォーターフォール型の開発手法は、大きな投資が必要で、かつ、その後5年以上にわたってビジネスを支えることになる重要なソフトウェアの開発プロジェクトが失敗しないよう、各工程でしっかりとしたドキュメントを作り、調整しながら次の工程に受け渡すことで、計画どおりのシステムを確実に作っていくための方法論でした。

最初に述べたように、ウォーターフォールでは、まず「何を作るか」を要件定義で明確にしてから、具体的な開発作業に入ります。そのため、特に大規模なシステムを作る場合には、必要な人員の確保や進捗管理がしやすいというメリットがあります。その反面、進めている途中に「手戻り（やり直し）」が発生すると、大幅な時間のロスが生じてしまうため、最初に決めた要件を開発の途中で変更することが難しいというデメリットがあります。

現在の企業がシステムを作る際、こうしたウォーターフォール型の開発方法だけに頼るのは得策ではありません。最大の理由はウォーターフォールが、基本的に「変化」を容認しにくい開発手法である点です。

DXで企業が目指すのは、市場のニーズやビジネス環境の目まぐるしい変化に適応可能な組織への変革です。変革（トランスフォーメーション）のためにデジタル技術をフル活用し、新しい価値を生みだすことがDXの本質です。変化のスピードが加速している時代には、最初にすべての「要件」を確定し、それからシステムを作っていては間に合いません。完成するころには、要件の前提となっていたニーズや環境のほうが変化しており、せっかく作ったシステムの価値が失われていることも多いためです。

そこで、より短いタイムスパンで、まず仮説を立て、実際に動くシステムでそれを検証しながら次の仮説を立てて、さらに検証するといった「試行錯誤」の中で完成度を上げ、ビジネスに対してシステムが提供する価値を最大化できるような開発の進め方が求められるようになってきました。

明確でない要件を探りながら完成度を高めていく「アジャイル開発」

システム開発に対する、こうしたニーズが一気に高まった契機としては、1990年代後半以降のインターネットの爆発的な普及が挙げられます。Webメディアやネットコマース、コミュニティサイトなど、主に一般消費者を対象とした「B2C」（Business to Consumer）と呼ばれるフロントオフィス領域のWebサービスが増加するのに伴い、それまでの受発注処理や人事・給与のような社内システムとは異なり、エンドユーザーである消費者が、今その時に望んでいる価値や機能といった、あらかじめ定義することが難しい「要件」を備えたシステムを作ることが求められるようになりました。それを実現するためには、刻々と変化するユーザーの要望を聞きながら、システムに随時変更を加えていく必要があります。

そこで登場したのが「アジャイル開発」というコンセプトです。開発方法論としての「アジャイル」が脚光を浴びたきっかけは、2001年に17人のソフトウェア開発手法の専門家たちによって発表された「アジャイルソフトウェア開発宣言」です。

（参考リンク）
・Manifesto for Agile Software Development
・アジャイルソフトウェア開発宣言（日本語訳）

この宣言に関わったメンバーは、いずれも企業における従来のソフトウェア開発のあり方に課題を感じていました。企業が、ソフトウェア開発サイクルの計画と文書化を重視し過ぎるあまり、顧客（ユーザー）を喜ばせるという本来の目的を見失っているのではないかというのが共通した問題意識でした。

宣言の趣旨や、そこで定義されているアジャイル開発の「12の原則」は、非常にシンプルなものなので、ぜひ一度目を通してみてください。これらは、旧来の開発手法の価値を認めながらも、過度な仕組み化をよしとせず、より顧客が求めているものを重視して、開発とビジネスの分業化を避けながら、「計画の順守」より「変化への対応」に重きを置いて開発を行っていくという、ステークホルダー全体で共有すべき「マインドセット」を明文化したものです。この理念を、実際の開発現場で実践可能なフレームワークにしたものが「XP（エクストリームプログラミング）」「リーン」そして「スクラム」といった具体的な開発手法になります。

アジャイル開発手法に共通する特徴としては、最初は「完成形」を決めずに、チームとリリースサイクルからスケジュールを定め、その中でスコープ（開発の対象範囲）を決めて、段階的に開発を行っていきます。また、ウォーターフォールで行っていた「工程ごとに文書ベースで確認して次の工程に引き継ぐ」という作業を排し、開発者自身がリリースする「動作するアプリケーション」上で確認して、次のサイクルに進みます。

• 

  短いタイムスパンで「リリースと改善」を繰り返すアジャイル開発モデル（出典元：Ridgelinez）

アジャイルソフトウェア開発宣言から20年以上が経過したことで、現場での実践知が蓄積され、具体的な方法論についても体系化や改善が進んでいます。また、その間に「ローコード開発ツール」やリリース作業を自動化する「DevOpsツール」など、アジャイル開発と親和性が高い多くの技術が発展し、クラウド環境を中心に広く提供されていることも、アジャイルの普及を後押ししています。

日本企業が「ウォーターフォール」から脱却できない理由

米国では、新興企業を中心に「ウォーターフォール離れ」が進んでおり、特にSoE領域においては「アジャイル」が標準的な開発手段となっています。一方で、日本においては、大企業を中心に、多くの企業が依然として「ウォーターフォール」をシステム開発の標準的な手法と捉えています。

このような状況になっている理由としては、日本企業のシステム開発が伝統的に「外注」で行われてきたことが強く影響しています。その結果、システムの開発や運用が行える技術者のほとんどがユーザー企業ではなく、SIerに所属している状況です。「ユーザー」「開発」「運用」が、それぞれに分断された構造の中で、できるだけ食い違いが生じないよう「文書化」を重視するという文化が強く根付き、そこから脱することが困難になっています。

関連して、ウォーターフォール型の開発プロセスでは各工程が明確に分離されるため、技術者の外部調達や、必要な工数に応じた見積もりも、一般にアジャイル型より容易です。さらに、ウォーターフォール時代に行われてきた「要件定義どおりの成果物を納品する」ことを条件とした「一括請負」と呼ばれる契約形態が、システムを発注する際の標準となっていることも、「完成形を決めずに改善を繰り返す」アジャイル型で開発を進める際のハードルになっています。

日本企業が、アジャイル開発を本格的に実践していくためには、時間をかけて深く根付いた業界の構造や商習慣を、よりアジャイル開発に適した形へ見直していく必要があります。決して容易なことではありませんが、DXの実現においては目を背けることができない課題です。

製造現場のDX事例にみる「アジャイル」の使いどころ

ここまで、開発手法としての「ウォーターフォール」と「アジャイル」の違いについて説明してきました。企業がDXを推進するにあたって「アジャイル」を取り入れていくことが重要なのは間違いありませんが、かといって、DXに関わるあらゆるシステム作りをアジャイルだけで進められるかと言えば、そうとも限りません。

アジャイル開発は、構想の実現性や効果などを確認しながらプロジェクトを進めていく際に特に適した開発手法ですが、その性質上、特に経験の浅いチームで実践した場合には、視野が短期的、狭窄的になりがちです。

組織としてのDXプロジェクトにアジャイルを取り入れる場合には、組織全体を視野に入れて策定された構想とロードマップを考慮しながら、部門横断で調整を行ったり、工程を管理したりといった要素も必要になります。そのため、ウォーターフォールとアジャイル、それぞれの開発特性を踏まえて、自社の状況に合わせた使い分けが求められる場面も出てきます。

• 

  「ウォーターフォール」と「アジャイル」の比較（出典元：Ridgelinez）

最後に、Ridgelinezが支援したDXプロジェクトの事例として「製造現場の品質情報に基づく業務改善分析」の取り組みを紹介します。

• 

  製造現場にアジャイル開発を導入し要望の反映を迅速化（出典元：Ridgelinez）

この取り組みにおいて、データ分析基盤のフロントエンドは、ローコード開発ツールによる現場主体のアジャイル開発で構築しています。そうすることで、製造現場のノウハウや要望を、迅速にシステムへ取り込めるようにしています。

一方で、バックエンドの統合データ分析基盤は従来型の運用スキームで動いていますが、フロントエンドとAPIによる疎結合接続が行えるようにして連携を行っています。この統合データ分析基盤は、全社規模でのデータ活用を進めるDXプロジェクトの主要コンポーネントであると同時に、複数の現場における個別業務のデジタル化、効率化にも利用できるものになっています。

このような「全体最適を意識しながら個別業務の効率化を進める」取り組みは、現状でデジタル人材の確保が十分ではない企業にとっては難しいことかもしれません。DX全体の構想策定支援と合わせて、組織内でアジャイル開発を実践し、定着させていくことが重要です。外部のエキスパートが、ユーザーチームの一員に加わりながらノウハウを転移し、アジャイル開発のプロセス構築や人材育成などをサポートすることも選択肢の一つです。