要チェック！DXで盛り上がる「アジャイル開発手法」の使いどころ【前編】―アジャイル開発が必要とされる理由とは？

▶ 後編はこちら 要チェック！DXで盛り上がる「アジャイル開発手法」の使いどころ【後編】―開発チームのパフォーマンスを上げる手法は全てのチームのためになる！？

そもそもアジャイル開発とは？

ソフトウェア開発についてあまりご存知ではない方もいらっしゃると思いますので、まずは「アジャイル開発」とは何かから話を始めます。

アジャイル開発の「アジャイル（Agile）」とは、「機敏」「俊敏」といった意味の言葉（英語）で、アジャイル開発とは、ソフトウェアをスピーディーにリリースすることを指しています。また、アジャイル開発で言うアジャイルには、単に開発のスピードを上げるだけではなく、「変化に俊敏に対応する」「顧客の要求をすみやかにかたちにする」といった意味合いも含まれていると言えます。

そんなアジャイル開発の概念が生まれたのは、いまから20年近く前のことです。具体的には、2001年に『アジャイルソフトウェア開発宣言』が世界に向けて発信されたことが始まりです（以下、参照）。

アジャイルソフトウェア開発宣言

私たちは、ソフトウェア開発の実践、あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。この活動を通して、私たちは以下の価値に至った。

プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。

agilemanifesto.org

この宣言のポイントをまとめると、「仕様書や計画に従ってソフトウェアを作り上げることよりも、開発チームのメンバー同士で、あるいは開発チームと顧客（*1）との間でコミュニケーションを密接にとりながら、実際に動くソフトウェアを使って、協調して、スピーディーにソフトウェアを作り上げていくこと、そして、変化に機敏に対応することのほうを重視しましょう」ということです。また、そうすることで良質なソフトウェアが、より早くリリースでき、ビジネスの変化にもすばやく対応できる、というのがアジャイル開発の考え方です。

*1 ここで言う「顧客」とは、IT企業や自社の情報システム部門にソフトウェアの開発を依頼する依頼主のこと。開発するソフトウェアのオーナーと考えればよい。

アジャイル開発が必要な理由

ITをお仕事にされていない方は、先に示したアジャイル開発の宣言を読んで「どうして、このような考え方を、わざわざ発信しなければならなかったのだろう」と不思議に感じるかもしれません。

実を言えば、当時のソフトウェア開発では、「ウォーターフォール型」と呼ばれる手法が主流を成していて、開発工期が総じて長く、かつ、開発の遅延も発生しがちでした。また、相応の期間をかけて完成させたソフトウェアが、顧客の意図や目的、期待にそぐわないこともあったのです。

ウォーターフォール型の開発とは、開発の上流工程でビジネス要件やソフトウェアの仕様をしっかりと固めたうえで、下流工程で仕様書に記された内容を実装（プログラミング）し、のちにテストを行い、リリースに至るといったものです。この手法は、ソフトウェアに求められる機能が長期にわたってほとんど変化せず、また、非常に高い信頼性が求められる大規模システムの開発に適したものとされています。ただし、ウォーターフォール型は、まさしく上流から下流へとシーケンシャルに開発のプロセスが流れ、1つのプロセスが終わらないと次の段階に進めませんので、工期がどうしても長くなりがちです。また、下流工程の段階で要件・仕様に大きな変更が生じると柔軟に対応できず、多くの手戻りが発生します。

こうしたことから、ウォーターフォール型は、商機をとらえるためにスピード感をもってソフトウェアをリリースし、かつ、顧客ニーズの変化に対応するために、絶えず機能の変更や改善をしなければならないような開発には不向きとされています。しかも、ウォーターフォール型の開発では基本的に、プログラミング工程の途中でソフトウェアが動いているところを顧客は確認できず、完成品がどのようなものになるかが想像できません。ですので、仮に自分たちの意図したことと違う方向に開発が進んでいても、ソフトウェアが完成するまでわからないことがあるのです。

ウォーターフォール型が内包するこうした数々の問題を解決すべく打ち出されたのがアジャイルソフトウェア開発宣言だったというわけです。

DXの潮流で日本でもアジャイル開発が本格普及へ

アジャイルソフトウェア開発宣言が出されたのち、米国ではアジャイル開発の採用が進み、今日におけるソフトウェア開発の現場では、アジャイル開発が当たり前のように実践されています。

一方の日本では、アジャイル開発があまり普及してきませんでした。その大きな要因の一つは、日本における非IT系の事業会社（つまりは、IT企業ではない一般の企業）では、米国の事業会社のようにソフトウェアを内製するところがあまりなく、ソフトウェアの開発を外部の協力会社（IT企業）に委託するのが一般的だったからです（現在もそれが一般的です）。

先に触れたとおり、アジャイル開発の基本は、開発チームのメンバー同士、あるいは開発チームと顧客とが、密接にコミュニケーションを取りながら開発を進めるというものです。また、ソフトウェアの開発が完了しても、それはあくまでも通過点の一つで、チームのメンバーは継続してソフトウェアの機能変更や改善に携わっていくことも想定されています。

この方式は、ソフトウェアの内製を前提にしたもので、開発の作業を外部の企業に委託することは想定されていません。ですので、日本の企業ITにおけるソフトウェア開発の方式と、アジャイル開発との親和性はあまり良くなく、それが普及を阻んできたと言えます。

ところが、ここ数年来のデジタルトランスフォーメーション（DX）の潮流もあり、アジャイル開発を採用しようとする事業会社の動きが活発化しています。ご存知のとおり、DXの取り組みの一つは、デジタルテクノロジーを使って、自社の製品・サービスの顧客満足度を高めることです。そのためのソフトウェア（サービス）づくりに終わりはなく、顧客ニーズをとらえながら、アイデアをスピーディーにかたちにして、改善を繰り返していかなければなりません。実際、市場で一定の地位を確保している有力なeコマースサイトやSNSですら、顧客満足度を高いレベルで保ち、市場での競争優位を維持するために、細かな機能追加やサービスの拡張を繰り返しています。

このような短いサイクルの、そして継続的なソフトウェアの改善とリリースは、ウォーターフォール型の開発手法では成しえず、結果としてアジャイル開発に対する関心が日本でも高まったと言えます。こうした関心の高まりを受け、開発を請け負うIT企業も、アジャイル開発の手法を取り込み、受託開発のモデルの中で顧客と密接に連携しながらソフトウェア作りを進めるという、日本式のアジャイル開発を実践しています。

ERPの導入でもアジャイル開発

近年では、基幹業務システムであるERPのアプリケーションパッケージ（以下、ERPパッケージ）の導入に際しても、アジャイル開発的なアプローチで、システムの立ち上げを早期化する動きも見られ始めています。

旧来、ERPパッケージが備える標準機能では自社の業務プロセスにフィットしないという理由から、数多くのカスタムモジュールが開発され、それが開発工期の長期化とコスト増を招いてきました。しかも、企業の事業内容や業務プロセス、さらには組織構造の変化によって、開発したモジュールが不要になるケースも多くあります。

そこで、パッケージを自社の業務にフィットさせるのではなく、自社の業務をERPパッケージにフィットさせ、業務の標準化を図るのが合理的という考え方が広がっています。その流れの中で、例えば、SAPのERP製品に備わっているベストプラクティスのテンプレートを用い、アジャイル開発で言うところの「動くソフトウェア」を使いながら、スピーディーにシステムを作り上げ、運用を始動させてしまうお客様が見られ始めているのです。

しかも、SAPのERP製品には、さまざまな業界のベストプラクティスがテンプレートとして備わっているので、事業構造が変化したり、新事業を立ち上げたりする際にも、アジャイル開発的なアプローチを使ってすぐに基幹業務のシステムが作れます。加えて、SAPのERPのクラウド版では、新技術を取り入れた機能強化が自動的に、かつ短サイクルで行われます。ユーザー企業はなにもしなくても、アジャイル開発がもたらすメリットを享受することができるのです。

以上、アジャイル開発とは何かと、その動向について駆け足でご紹介しました。本稿の冒頭部分でも触れたとおり、このアジャイル開発（ないしは、アジャイル開発を実現するための方法論）は、ソフトウェア開発の業務だけではなく、他の業務を担当するチームの生産性も高められる可能性があります。後編では、その可能性について考察します。

▶後編はこちら 要チェック！DXで盛り上がる「アジャイル開発手法」の使いどころ【後編】―開発チームのパフォーマンスを上げる手法は全てのチームのためになる！？

▶DXの先進事例を読む「どうする、わが社のDX！？」そんな悩みに答える実践ノウハウ＆成功ポイント