デジタルサービスはアジャイル型開発でなければならない理由～一番簡単なアジャイルの話～

IT業界にかかわったことのある方なら、一度はアジャイル型開発という言葉を聞いたことがあるだろう。それもかなり昔にだ。最近、デジタルトランスフォーメーションへの関心が高まるにつれて、ふたたびアジャイル型開発が脚光を浴びるようになっている。なぜ今、アジャイル型開発なのか。アジャイル型開発でなければならないのか。

１．アジャイル型開発で何ができるのか

　昨年のコロナ禍以降、官も民もこぞってデジタルトランスフォーメーション（DX）を掲げるようになった。そして、DXによってデジタルサービスを実現するための方法論として、共創やオープンイノベーション、デザイン思考など様々な概念や手法の必要性が再認識されるようになったが、その一つがアジャイル型開発である。ここ数年、組織を挙げてアジャイル型開発人材の確保・育成に乗り出す企業が相次いでいる。本稿では、なぜデジタルサービスはアジャイル型開発でなければならないのかについて、アジャイル型開発を知らない読者にも理解いただけるよう、可能な限り分かりやすく伝えたい。
　ひと口にアジャイル型開発といっても様々な手法があり、一定の定義はない。しかし、米国でソフトウェア開発業界を代表する人々が2001年にユタ州で発表した「アジャイルソフトウェア開発宣言」では、次のようなことが述べられている。曰く、「プロセスやツールよりも個人と対話を、包括的なドキュメントよりも動くソフトウェアを、契約交渉よりも顧客との協調を、計画に従うことよりも変化への対応を」価値とすると。つまり、開発を行う際には、“対話をしながら、手を動かしながら、協調しながら、柔軟に変化に対応していこう”、ということだ。重要なのは、これらは決して「こうあってほしい」という「理念」にとどまるものではなく、適切に実践することによって、実際に従来よりはるかに短期間で、低コストに、無理なく、優れた機能を持つソフトウェアを作れるという「理論」である点である。これをフレームワークに落とし込んだものの一つが、アジャイル型開発の代名詞ともいうべきスクラムだ。その生産性は、スクラム社によれば、少なくとも２倍。４倍も当然としている。同社がよく用いる事例は、失敗続きで予定コストを大幅に超過した米国海軍F３５戦闘機と同等以上の機能性を持つ戦闘機の開発を、アジャイル型開発によって20％のコストで達成できた、というものである。ほかにもこの手の話は山ほどある。

２．なぜアジャイル型開発が凄いのか

　ではなぜこんなことができるのか。それは一言でいえば、アジャイル型開発を実践することで、従来のやり方の無駄が徹底的に排除され、人間が本来持つ生産性や創造性を引き出せるからである。これだけでは抽象的なので、もう少し具体的な話をしよう。アジャイル型開発とよく対置されるのがウォーターフォール型開発である。ウォーターフォール型による伝統的なシステム開発のセオリーでは、はじめに緻密なプロジェクト計画書を作成する。しかし、ウォーターフォール型開発はスタート時点で既に大きな無駄を抱えている。まず、計画書の作成自体に多大な時間がかかる。その上、実際にプロジェクトが始まるとすぐにスケジュールの遅れが生じ、ガントチャートは見向きもされなくなる。もっと深刻なのは、何もモノがない初期段階では、的確に利用者の課題やニーズを捉えることはほぼ不可能ということである。つまり計画には何ら意味のある根拠はない。その結果、プロジェクト終盤の受け入れ試験の段階で、成果物の認識の差異が顕在化し、プロジェクト名物「ちゃぶ台返し」が発生する。そして、膨大な手戻りが予算とスケジュールを食いつぶす。システム開発のプロジェクトの成功率が２割とか３割とか言われるのは、当然の帰結なのである。
　これに対し、アジャイル型開発では、当初の段階では仕様は決め打ちにしない。もちろん解決すべき課題や達成したいゴールは定めるし、実装したい要件は洗い出して可視化する。何を作るか（What）は明確にするが、どう作るか（How）は決め打ちにせず、柔軟に捉えるのである。そして、動くものを素早く作り、短い間隔で顧客に確認してもらう。フィードバックの中で修正の指摘があっても小さい単位なので、手戻りはほとんどなく、すぐに対応できる。少人数のチーム内でそれぞれが役割を持ち、日々の対話と定期的なミーティングで問題点は常に軌道修正され、協調が維持されるので、見えない問題が知らずに深刻化するようなこともない。こうしたワークを積み重ねながら機能を作り込んでいくと、手戻りなく、顧客が求めるサービスがおのずと完成し、もはや受け入れ試験も必要なくなる、というわけである。もちろんこうしたかたちでプロジェクトを上手く運営するための完成度の高い方法論を、が各手法で構築されている。

３．アジャイル型開発も楽ではない

　もちろん誰しも、そんなに簡単に事が進むならば苦労はしない、と疑いたくなるだろう。実際、こうした方式が成り立つためには、いくつか条件がある。まず、意思決定者がこうしたプロセスを理解し、賛同していなければならない。また、特定の個人に、開発される製品やサービスの水準を決定する権限を与えなければならない。これをプロダクトオーナーというが、日本の組織ではなかなか難しい。日々の対話（スクラム手法ではデイリースクラムという）によるコミュニケーションだけでサービスを作れる良質なIT人材も必要だ。こうしてみると、なかなかハードルが高い。また、アジャイル型開発の適用範囲にも限界がある。データベースの構築をアジャイル型で行うなどちょっと想像がつかない。アジャイル型開発が特に威力を発揮するのは、プロジェクト初期のサービス構想づくりの段階か、UIの開発においてである。ほかにも様々な制約条件があり、それらを解決するための様々な方法論が用意されている。しかし、どのプロジェクトもそれなりに事情はあるわけで、うまくいくかどうかは結局のところ人次第、チーム次第ではある。だからこそ人のありようが決定的に重要となる。
　最大の課題は、アジャイル型開発への心理的抵抗である。アジャイル型開発は、ウォーターフォール型しか知らない人々には、どうしても受け入れがたい。すぐに出てくる反論は、あらかじめ仕様を定めなければ要件が爆発し、コントロールできなくなる、というものである。これは理屈というより恐怖に近い。恐怖は感情であり、理性よりも強い。したがって、こうした人々に言葉での説得は無意味である。なんとか実際のまっとうなアジャイル型開発に参画してもらい、実体験を通じて恐怖の感情を和らげてもらうしかない。

４．それでもアジャイル型開発でなければならない理由

　こうした困難を認識しつつもなお、多くの企業がアジャイル型開発にシフトしようとするのはなぜか。それは、もはやアジャイル型開発でなければ競争に勝てないからだ。デジタル化によって、かつてとは比べ物にならないほどサービスは便利になり、日進月歩で進歩している。こんな時代に、ウォーターフォール型で顧客のニーズに合わないものを作っていては勝負にならない。それが内部向けシステムだとしても、社員に非効率なシステムの利用を次のリプレースまで我慢させ、生産性やモチベーションを削り続けることなど許されない。また、製品ライフサイクルの短期化が進む中、次のリプレースまで５年も同じシステムを使い続けているようでは、とてもではないが変化のスピードについていけない。さらに、サービスのグローバルな競争が激化する中で、システムに余計なコストをかける余裕などない。
　日本企業はこれまで、こと情報システムに関しては、利用者にとって便利なものを、より早く、より低コストで提供するというごく当たり前のことを行わず、現場の我慢の上に、膨大な無駄を積み重ねてきた。しかし、もはや我慢だけでは耐えられなくなり、本来あるべき姿を志向せざるを得なくなったのが現状である。
　こうした無駄の典型が役所のシステムだが、役所も変わり始めている。コロナウイルス禍では、特別定額給付金の支給の遅れが指摘されたが、一部の自治体はきわめて迅速に、簡潔で、機能性の高いサービスをリリースした。例えば、成功事例の一つに加古川市や神戸市のシステムが挙げられるが、それらは多少プログラミングを知っている職員がほんのわずかな時間で作ったものだ。従来のウォーターフォール型であれば、まずプロジェクト計画のドラフトを作るだけで、それだけの時間がかかってしまうだろう。そして、組織内の合意を得て、調達書類をつくり、入札や見積合せの手続きをとり、ようやく受注ベンダーがきまる。そこから要件定義、設計、開発、テストと進み、手戻りを繰り返しながら、ようやくソフトウェアが完成する。その頃には、手作業でも給付金の支給は終わっているだろう。ウォーターフォール型とアジャイル型開発では、これだけの生産性の差が出る。

５．アジャイル型開発についていけない経営者・マネージャがすべきこと

　ウォーターフォール型でなければならないプロジェクトは今後も残り続けるだろう。しかし、アジャイル型開発でも行えるプロジェクトを、あえてウォーターフォール型で行うなど、もはや冗談としても笑えない。今やそんな“贅沢”は許されなくなっていることをすべての経営者は自覚する必要がある。もちろん前述のように、アジャイル型開発を行うことは容易ではない。何よりも経営層、そしてミドルマネージャの意識を変えなければならない。しかし、どうしても意識を変えられない役員やミドルマネージャは一定数必ず残る。そうしたときになすべきことはただ一つ。そうした方々にはDXから手を引き、口出しをしないようにしてもらうことである。こうした変化への不適合は、蒸気機関の登場、コンピュータの導入、インターネットの普及など過去の歴史の変革期でも常に起きてきたことである。やや非情ではあるが、組織が生き残るためには、こうした一種のスクリーニング（ふるい分け）は避けて通れないだろう。
(E.K.)