6割以上の企業がアジャイル開発を導入
コロナ禍以降、大企業はこぞってDXを推進している。急速な社会の変化の中で企業の生産性や顧客満足度を向上しコストを削減していくためにはデジタル化は不可欠の要素だからだ。
そうしたDX戦略の要となるシステム開発は、インターネットの普及やクラウド化などの影響で開発手法も大きく変わろうとしている。
これまでは要件の定義から設計、開発、テストといった具合に滝のように流れるウォーターフォールという手法でシステム開発が進められてきた。
ところが最近では開発の単位を細かく区切り、それぞれで実装とテストを反復しつつ開発を進めていくアジャルという開発手法に注目が集まっている。
世界屈指のテクノロジー調査会社、ガートナーが２０２３年７月１０日～１２日にかけて行ったアジャイルの採用状況の調査（対象は４００件）によると、「全てアジャイル開発」と答えた企業は１７．５％、「一部アジャイル開発」と答えた企業は４４．３％、すでに６割以上の企業がアジャイル開発を導入していることが明らかになっている。
「数年前からアジャイル的な開発は増えてきています。大企業では多くの開発案件が存在するのでどこかの案件でアジャイル開発が行われているということも珍しくはなくなりました。ビジネス環境の変化に迅速に対応する必要があるからです。アジャイル開発でより早くより安く開発したいという思いがあるのだと思います。ただ今までウォーターフォールで開発してきたものをいきなりアジャイルで開発するのは難しい。新しく作る部分や新しいアプリなどでそうした手法が注目されているのだと感じています。一方でアジャイル開発には向かないと思われていた領域でもアジャイル開発の採用が検討されるケースも出てきています」
ガートナージャパンのシニアディレクターアナリストの片山治利氏はこう解説する。
「アジャイル開発とは何か」
そもそもアジャイル開発とは何か。片山氏は「正解がわからない状態で、正解に近づくためのアプローチ（開発手法）」であるという。
Incremental（少しづつ）とIterative（繰り返し）を行い試行錯誤の中でValue（ビジネス価値）を実現していくのが大きな特徴だ。
ウォーターフォールとの違いについて片山氏は「従来のウォーターフォール型開発では外注にお願いしてプロジェクトを進め、いったんプロジェクトが完了すればチームが解散する。後どうなっているのかがわからない。それに対してアジャイル開発では正解に近づくために少しずつ、繰り返しながら進めていく開発なので、成果を確認しながらやっていくことができます。作りっぱなしにならないというのが大きな特徴だと思います」と語る。
片山氏はアジャイルを４つのパターンに類型化している。
1番目は短期間のうちに開発を繰り返していくやり方。1週間から2週間（期間は案件で決められる）を基準にタイムボックスという期間を構築し、そのタイムボックスごとに仕様設計や開発、リリースを行うスプリントを固め、この工程を何度も繰り返して開発を行う手法だ。製造の工程から無駄を省き必要なものだけを残すリーン開発（トヨタの生産方式が応用されたもの）などでよく利用されている。
2番目は上流工程を少しずつ繰り返すパターン。要件定義の部分を繰り返して議論を重ね、開発工程をウォーターフォールで進める手法だ。ユーザーの視点に立ってサービスやプロダクトの本質的な課題・ニーズを発見し、ビジネス上の課題を解決するデザインシンキングなどで利用されている。
3番目は、要件定義・設計をやった後にプロトタイプを作成し、ユーザーが試したフィードバックを受けつつ改善を繰り返す手法だ。パッケージソフトウエアなどを採用する際に利用される手法で、大手航空会社が海外で利用されている予約・発券システムを導入する際に活用された。
4番目は最初に要件定義やグランドデザインを決め、機能単位、稼働単位で五月雨式に開発する手法だ。基幹系のシステム開発など大規模な開発などで活用されている。大手不動産会社がマンション管理や販売管理などの業務システム群の統合と改善をおこなったときにこの手法を利用したほか、大手損害保険会社でも自賠責保険のシステムを再構築した時に活用している。
「議論の中には、１番は本物だけれども２番から４番は偽物なんだという意見もありますが、現場で案件を進める立場からすると、本物も偽物もない。案件の特徴によって合理的な手法を選択すればいいわけです。最近はローコード、ノーコードなどの開発も進んでいます。こうした開発手法では2番と3番を一緒にしたような開発手法も珍しくないようです」（片山氏）
アジャイルは「安い」「早い」というイメージが持たれているが必ずしもそうではない。
「アジャイルは試行錯誤の中で開発を進めますが、ウォーターフォールは段取りよく進めていくわけですから、ある程度の規模をもつシステムを開発する場合、アジャイル開発の方がウォーターフォールよりも工数もかかりますし、期間が延びたりすることもあります。（ゴールが明確でプロセスの予測可能性が高い場合などでは）ウォーターフォールをアジャイル的なやり方に変えただけでは、逆にコストが高くなってしまうということもあるのです」（片山氏）
アジャイル開発を始めるときに抑えておくべきポイント
ではアジャイル開発を進めていく際にどのようなことに注意すればいいのだろうか。片山氏は６つのポイントを挙げている。
「なぜアジャイルか？」について共通認識を持つ
品質をおろそかにしない
迅速な意思決定の仕組みを整える
外部（案件の外側）の阻害要因を克服する
他チーム（ウォーターフォールなど）との調整を図る
未経験者の育成の仕組みを整える
ではそれぞれ見ていくことにしよう。
アジャイルは非常によく知られた概念だが、実はさまざまな解釈がある。解釈によってとらえ方が違う。開発者側、ユーザー側などのステークホルダーの間でアジャイルに対して全く違うイメージを抱いていれば、おのずと求められる結果も違ってくる。
「安い」「早い」を求めている人と、「必要なもの」を求めている人ではおのずと求められる結果は異なる。「アジャイル的なことをやり、結果として必要なものができても、安くも早くもないので、会社としてはいったんアジャイルによる開発を中止する、なんて話も聞いたことがあります」（片山氏）
期限についても同じことが言える。アジャイルが「正解がわからない状態で正解に近づくためのアプローチ」であり、少しずつ繰り返しながら価値を実現するものであるとするなら、どこで期限を切るのか、という問題が出てくる。
ウォーターフォールはプロジェクトが終了すれば製品化してプロジェクトは解散されるが、アジャイルはプロジェクトというよりも製品を継続してブラッシュアップしていく商品開発のようなものであるという考え方だ。案件の認識についても共通認識としてしっかりと押さえておかなければならない。
ステークホルダーの間で同床異夢の開発にならないためにはアジャイルに対する共通の認識を持つことが重要だ。
アジャイルは「正解がわからない状態で正解に近づくためのアプローチ」だから、多少の失敗は起こりうる。
しかし品質をおろそかにしてもいいということではない。
「アウトプットされているソフトウエアはきちんと動かなければならないし、バグがたくさんあるような状態でリリースしてもいけない。短い時間で品質を管理しなければならないので、ウォーターフォール以上に品質管理は難しい」（片山氏）
既存の商慣習がアジャイルの難敵に
次に「迅速な意思決定の仕組みを整える」という点について考えてみることにしよう。アジャイルでソフトなどを開発するときには、それを利用するビジネス側の意思決定権者と開発者側リーダー（自社もしくは外部）、そしてビジネス、IT全体の上部管理者が常に課題を共有し、機敏に意思決定していかなければならない。時機を逃さないことが重要だ。
「アジャイルでは短期間で開発を進めていくので、どんどん意思決定していかなければならない。ウォーターフォールの場合は、毎週ミーティングがあって、ステークホルダーとのミーティングが月一回あって、大きな課題の意思決定は月一回ということも多いと思います。月一のミーティングもメンバーの調整がつかなければ翌月に持ち越しても問題はなかった。そうして意思決定が遅れていくことがよくあったのです。最近はビデオカンファレンスなどツールがそろってきているので、上位者たちの意思決定を迅速にすることは可能ですし、迅速化することが重要なのです」（片山氏）
アジャイル開発ではプロジェクトの外部にさまざまな阻害要因がある。これまで日本のシステム開発は外部のベンダーなどに頼ってきたことからこれが慣例化し、従来のウォーターフォールを前提とした社内ルールを設けている会社も少なくない。
「会社の中にはさまざまな開発に関するルールがあります。ルールの中には純粋なウォーターフォール的なやり方を想定している場合があるのです。それに合っていないと、会社がそのプロジェクトを認めてくれない。予算や稟議書などの決まり事に合わないとプロジェクトを立ち上げることすらできない。会社としてアジャイル開発を推進していくときには整理しておかなければならない問題です」（片山氏）
「調達」部門が、請負しか開発を認めないという会社もあれば、アジャイル開発のような要件変更は「予算」上NGという会社もある。
会計でもアジャイルに特化した会計はない。したがって既存の会計基準に従って会計処理しなければならないが、ソフトウエアの資産計上のタイミングや範囲が難しい。
そのほか人事ではいままでのIT部門の人事基準がアジャイル人材の評価体系に合わないという問題も出てくる。
「ある会社の方は、アジャイル開発の一番の壁は外注との契約を担当する調達だとおっしゃっていました。これまでのウォーターフォールと違うからダメだといわれてしまう。そしてアジャイル開発を認めてもらうまで3か月もかかり、これだけの時間をかければすでにシステムができていたのに、という話も耳にします。会社の既存のルールとどう調整を図っていくのかということが重要になります」（片山氏）
丸投げ体質を克服できるのかが成功のカギ
調整が必要なのは既存の社内ルールだけではない。「他チーム（非アジャイル）との調整を図る」ことも重要だ。システム開発といってもアジャイル・チームだけでは完遂できない事案が多い。ところがお互いの価値観、手法が異なり協力できない、両方の統括ができるリーダーがいないといった問題もある。結果的には目まぐるしく変化する環境に対して組織が機敏に対応できるようにするアジリティ的手法の成果を発揮できない場合があるのである。
例えばウォーターフォールは品質や堅牢性を重視するが、アジャイルはスピードや流動性を重視する。非アジャイル・チームとの調整が図る必要があるというわけだ。
お互いのビジネス目標を共有化させ、お互いを認めてコミュニケーションを図る。そのためにはお互い丁寧に説明し、事情を理解し、アジャイルを押し付けないで受け入れることが重要だ。
「未経験者の育成の仕組みを整える」ことも重要だという。
開発チームは事業部などでの経験のあるアジャイル未経験者を取り込み、実際の実務がどうなっているのかをしっかりと把握する必要がある。それを踏まえた上でシステムやソフトウエアの開発をする。だから未経験者の育成は必須条件となる。
しかし最初のうちは未経験者が足かせになることもある。
ではどのように育成すればいいのか。誰がどういう立ち位置で育成するのか。ベンダー側の未経験者の育成をどう考えるのか。
「どのような会社でもアジャイルの経験者がたくさんいるわけではないので、未経験者をどう育てていくのかというのは重要な課題となります。研修やOJTなどやり方はいろいろあると思いますが、ちゃんとやっていかないと人は育ちません。アジャイルは経験者でプロフェッショナルが集まって進められていくことを期待されるところがありますが、そこにベンダー側であれユーザー側であれ、未経験者を入れていかなければならないのです。未経験者の存在はそれ自体がプロジェクトの足を引っ張ることになります。誰が面倒みるのかというのも難しい問題です。だからこそ、上手に育てていくことが必要なのです」（片山氏）
ではCIOがアジャイル開発を進めていくためには何が必要なのだろうか。
「最近はCIOの方の認識も変わってきているとは思いますが、こうした問題点をしっかりと勉強しておいてほしいと思います。昔は現場の人が『アジャイルでやりますよ』といったときに、CIOのような立場の人が、『失敗したらどうするんだ』ということが多かったと聞きます。うまくいかなかったら、IT部門のせいにされるんじゃないかといった具合に。悪い意味での保守的な気持ちが強かった。それで現場はアジャイル的な開発をやろうとしても活気がなくなる。CIOもまた、アジャイル開発の本質を自ら理解し、関係者間でも共有する。そしてアジャイル推進は長丁場になることを認識するべきです。企業文化の最大の問題は丸投げ体質を克服できるのかどうかです。アジャイル開発を実践しようとするITリーダーはその点をしっかりと認識する必要があると思います」（片山氏）
Agile Development