「アジャイル（Agile）」の必要性と必然性は、テクノロジー関連の仕事に携わる人々の間で認知されているが、その実践・活用となると十分に進んでいるとは言いがたい。アジャイルはこれからの社会を築く中核であり、進化するテクノロジーを活用する唯一の方法であり、その定着は極めて重要である。本連載では、北米と日本の経験を基に、日本でアジャイルを定着させる方法と、真のアジャイルになるために必要なことを5回にわたって解説する。
筆者はコロナ禍の少し前から、複数の日本企業と「アジャイル」や「デジタルプロダクト」をテーマにした取り組みを行ってきました。いくつかは企業やビジネスに大きな変化をもたらし、文字どおりのデジタルトランスフォーメーション（DX）につながりました（関連記事：なぜ地方の中堅メーカーがDXを軌道に乗せつつあるのか？）。
このケースに限らず、コロナ禍による働き方・ビジネスのあり方の変化やそれによるさまざまな経験を通じて、少なくともテクノロジー関連の仕事に携わる人たちにおいてはアジャイルの必要性と必然性は、認知されてきたと思われます。一方でアジャイルの実践や活用が、まだ道半ばであることも事実ではないでしょうか？
アジャイルはこれからの社会づくりを進めるための中核になる考え方であり、働き方であり、そして急速に進化するテクノロジーをうまくための活用する唯一の方法でもあります。その定着は極めて重要です。北米と日本という2つの地域における筆者の経験や実体験を基に、日本で本当にアジャイルを定着させるにはどうすればいいか、本当にアジャイルになるためにどんなことが必要なのかを、これから5回にわたってお伝えします。
アジャイルのアンチパターンを知る
実際のところ、アジャイルはどの程度、普及しているのでしょうか。IPA（情報処理推進機構）が年次で発行している「DX白書」にそれを示すデータがあります（図1）。先行する米国に比べるとまだまだ低い浸透度ですが、年次の比較ではゆっくりとですが着実に浸透しつつあります。
図1：アジャイルの浸透度の日米の違い（出典：IPA「DX白書 2023年度版」）拡大画像表示
特に日本企業のIT部門に限れば、2021年から2022年の1年間に「全面的に取り入れている」が2.8％増加し、「一部取り入れている」は13.5％増加しています。2022年における「全面的に」と「一部」の回答を合計すると49％であり、IT部門のほぼ半分が何らかの形でアジャイルを取り入れているという結果になりました。「もう半分、されど半分」という格好です。
同様にここ数年、筆者が現場で見聞きするアジャイルへの意見は、ポジティブなものとネガティブなものが半々といった印象です。ネット企業におけるアプリ開発などでは定着しているにせよ、一般企業では「アジャイルをやってみたが、あまり効果がなかったのでウォーターフォールに戻した」というケースをいくつか聞きました。本来の意味でのアジャイルではない取り組みをそう称しているケースにも、実際に遭遇したことがあります。
こういった中で、非常に印象に残ったエピソードがいくつかあります。そこから望ましくない、よくない結果を導いてしまうケースを3つ紹介します。アジャイルを実践するうえでのアンチパターン（Anti-pattern）です。いずれも北米ではあまり見聞きしたことがないパターンであり、アジャイルが日本でなかなか浸透しない理由や、解決策を探るヒントになると考えます。
①半年の要件定義の後にアジャイル開発する
SIやコンサルティングサービスの提案でよく見受けられる、長期間の要件定義フェーズを経た後、開発フェーズをアジャイルで行うパターンです（図2）。大手企業でクラウドの仕組みを開発する機会があり、あるSI企業のコンサルティングサービス部門との共同提案において実際に見られたものです。
図2：開発フェーズだけをアジャイルにする提案拡大画像表示
なぜこれがアンチパターンなのか、お分かりの読者は少なくないでしょう。アジャイルの大きな価値の1つはタイムリーにマーケット・顧客価値の高いサービスを提供することにあります。要件定義に長期間（上記のケースは半年）をかけてしまっては、開発がアジャイルであっても、実際に顧客に提供される頃には、期待した価値が提供できないサービスになる可能性が高くなるのです。
このSI企業の方と議論をすると、「会社としてはアジャイル開発を推進しているが、プロジェクトのGo/No Goを判断する品質管理部門の基準がウォーターフォール型のモデルしか想定していないので、こうせざるをえない」という回答でした。内製開発がまだまだ浸透しない日本ではSI/コンサルティングファームとの協業が現状ではどうしても必要不可欠ですが、サービス提供者側もさまざまなチャレンジを抱えているようです。
②テストは次のスプリントで別チームが実施する
アジャイルでは、ワーキングプロダクト（使える、実際に動くソフトウェア）を継続的にリリース（提供）し、改良や追加開発を通じて、品質や機能を向上させます。具体的には工程を短く区切って一定量の作業を完了させ、改善や改良を繰り返します。この一定量の作業をこなすことをスプリントと呼び、通常はコード作成とテストを1つのスプリントで実施します。
ところが日本では、同一スプリントの中でテストができず、テストとリリースに複数のスプリントを要してしまうパターンがあります（図3）。ある程度は内製化を実現したものの、コストの関係などでテストまで手が回らず、テストプロセスを外注しているようなケースです。このパターンではリリースする頻度が単純に減るだけではなく、コーディングとテストが分断されているために、いつまでもプロダクト品質が向上しない結果につながります。
図3：開発プロセスを複数のスプリント・チームにまたいで実施するパターン拡大画像表示
このパターンはすでに大規模にアジャイル開発を実践し、ビジネスそのものにテクノロジーが広く活用されているリテールやメディア関連企業に多く見られます。現場で担当している人は課題意識を持ってアジャイルの理想的なモデル作りに取り組んでいますが、組織の壁や経営からの理解がなかなか得られないといった状況に直面し、仕方なくこうなっている、という場合が少なくありません。
●Next：ウォーターフォールとアジャイルの決定的な違いとは？
会員登録（無料）が必要です
- 1
- 2
- 次へ ＞
