[本当にアジャイルになるための処方箋]

2024年9月19日(木)保坂 隆太（Gran Manibus CTO兼マネージングディレクター）

アジャイルはどう思われているか

　前回（アジャイルは日本で本当に定着しているか？：第1回）は、日本のソフトウェア開発現場におけるアジャイル活用がなかなかうまくいかない実例として、筆者が実際に体験した、日本でよく見られるアジャイルのアンチパターンを紹介しました。

　北米では業種や規模によらず、アジャイルがスタンダードであり、特にクラウドやAIといった最新技術を活用するためにはプロジェクトの規模によらず不可欠と認識されています。少なくともサービスを提供するコンサルティングファームやSIerなども含め、ウォーターフォールをわざわざ積極的に採用する企業はほぼないと言ってよいでしょう。もちろん北米でもうまくいかない例はたくさんありますが、前回紹介した3つのパターンは少なからず日本のマーケットが抱えるユニークな課題の一端を表していると考えます。

　日本でなかなかアジャイルが浸透しないのはなぜなのか。具体的な統計が手元にあるわけではないのですが、筆者がさまざまな企業との最近の会話をまとめると、企業単位では何かしらのプロジェクトでアジャイルを採用することはあるものの、プロジェクト総数に対するアジャイルの採用は全体の10～20％くらいといったところが、おおむね今現在のアジャイルの浸透度合いのようです。

　前回紹介したアジャイルのアンチパターンは、そんな中でも果敢にチャレンジする組織が直面している課題です。加えて、「アジャイルはまだなんだよね」という組織との会話の中でよく耳にするエピソードをいくつか紹介したいと思います。

エピソード①：アジャイルは大規模開発には向かない

　アジャイルはスタートアップ企業向けの開発手法であり、大企業の基幹業務システム開発には向かない──。これはコンサルティングファームやSIerの幹部と話をすると、必ずと言っていいほど聞くフィードバックです。SAP ERPの導入プロジェクトなどは数年がかりのことが多く、ステークホルダーも多岐にわたるため、ウォータフォール型アプローチのほうが適切であるというロジックですが、はたして本当にそうでしょうか。

　特に幹部レベルになればなるほど、ウォーターフォールへの盲目的な信頼と安心感が存在するように感じています。最近では江崎グリコの基幹システムトラブルなど、大規模で重厚長大なアプローチそのものへの懸念や課題が表面化しています。ときに、重厚長大な仕組みの代表格であるSAPはアジャイルアプローチを率先して取り入れ、自らの製品開発のみでなく、その顧客に対してもアジャイル導入の支援を長く提供しています。例えば、同社が提供する「SAP Activate」はアジャイルをベースとしたアジャイル型のプロジェクトデリバリーを体系化したものです。

エピソード②：アジャイルでは品質の高いものは作れない

　アジャイルでは開発テストに十分な時間が取れないので、高い品質を要求されるソフトウェアの開発には向かない。よってウォーターフォールを採用する──。こうした考えの下、アンチパターンでも紹介したように、アジャイルに取り組む企業でもテストや品質管理についてはウォーターフォールの手法をそのまま使うケースが多く見られます（図1）。

　アジャイルを活用して品質の高いソフトウェアを作るためには、テストやリリースの自動化などの取り組みに加え、品質管理そもそもの考え方やアプローチを根本からデザインし直し、実装できるエンジニアが必要になります。

　しかし、国内では、テストや品質管理などの仕事を専門職と位置づけてエンジニアを育成する企業・組織はごく少数です。テスト・品質管理はうまくいって当たり前という思い込みから成果が目に見えにくく、積極的な投資もされていません。コストの安い外部ベンダーに丸投げするといったケースも頻繁に見られます。

　SAFe（Scaled Agile Framework）は、エンタープライズ規模におけるアジャイル開発モデルとして多くの企業に採用されていますが、その中で品質はプロダクトの常に中心にあるもの（Build-In Quality）と位置づけています。第1回で紹介したアジャイル開発宣言では、“動くソフトウェア”という言葉で表現されていますが、常にビジネスに価値を提供するソフトウェアであるためには、品質は常に最も高い優先度で取り組むべき課題だと、アジャイル開発に成功しているチームは考えています。

　アジャイルは品質の高いプロダクトやサービス作りを実現できる強力な手法ですが、そもそも品質とは何かをもう一度問い直し、ウォーターフォールにおける品質管理手法を持ち込むのではなく、アジャイルに合った、顧客のニーズに合った品質を実現するアプローチを定め、実践する姿勢が求められます。それが実現できれば、これまでにない品質を提供することがきっと実現できるはずです。

エピソード③　顧客がアジャイルを受け入れてくれない

　2010年代前半あたりまで、「新しい技術であるクラウドを顧客がなかなか受け入れてくれない」というぼやき・嘆きを、IT業界の集まりでよく耳にしました。今では一転、クラウドファーストです。しかし提唱から20年以上が経過したアジャイルは、「今もなお顧客がついてこられないので採用に至らない」という言葉をいまだに日常的に耳にします。

　テクノロジーはクラウドを採用し、プロジェクトはウォーターフォールで進める、というパターンが、そこかしこで見られるわけです。米国の大手クラウドベンダーはもちろん自身のプロダクトをアジャイルで開発しており、顧客もそうしていることを前提にサービスを提供しています。

　「顧客のビジネスが成長し、それに伴ってクラウドベンダーの提供するプロダクトやサービスも成長する」というシナリオを前提としたビジネスモデルなので、向こう数年にわたってビジネスのやり方を塩漬けするウォーターフォールアプローチとはそもそも親和性が低いのです。よかれと思って導入したクラウドや最新技術が、かえってビジネスの足を引っ張るようなことになりかねません。

　例えば、クラウドでは一度リリースした機能が、利用者が少ないなどの理由で開発停止になるケースが起こります。顧客がアジャイル開発チームを持っているという前提でクラウドベンダーは製品を育てているので、成長過程で不要と思われる機能などを整理・統合するのは自然なことなのです。

なぜ、アジャイルがうまくいかないのか？

　アジャイルを導入していてもうまくいかず、課題に直面している企業の悩み、そして日本のIT業界関係者の中にある、アジャイルに対する懐疑的な認識や意見をたくさん見てきました。これらは日本において、アジャイルがまだまだ本当の意味で普及、浸透に至っていない現状をよく表していると思います。なぜ今もそうなのか──ここ数年のさまざまな会話を振り返ると、アジャイルに対する思い込み（先入観）が影響しているように感じています。

思い込み①：アジャイルは開発手法である

　アジャイルソフトウェア開発宣言を読んで分かるように、開発宣言と言いながら具体的な開発手法は一切紹介されていません。アジャイルは働き方であり、価値観であり、文化そのものであるからです。そのことをよく理解しているチームや企業では、手法ではなく、マインドセット、文化という言葉の中でアジャイルを理解し、そのうえで具体的な手法を導入しています。

●Next：日本におけるアジャイルの思い込み、残り3つは？