なぜ、SIerはアジャイル開発ができないのか（前編）

仕様が決められない、あるいは仕様書通りに作っても、できあがったときにはもう使えない。そんなことが、しばしば起こるようになりました。多くのSIerがこの現実を認識しています。アジャイル開発が有効であることも知っています。それにもかかわらず、アジャイル開発に対応できずにいる企業は少なくありません。

なぜ、できないのでしょうか。手法を知らないからではありません。スクラムの研修を受け、認定資格を持つ人材を揃えた企業でも、できていないのです。私は、その理由はスキルの問題ではなく、SIerが長年のうちに身につけてきた「常識」の問題だと考えています。

SIerを支配してきた常識

これまでの多くのSIerは、ユーザーが求める業務ニーズに対応し、仕様を確定し、その通りに作ることを仕事にしてきました。何を作ればいいのかはユーザーが示してくれる。自分たちはそれを正確に、期日通りに、予算内で作る。この関係の中で、SIerは技術を磨き、品質を高め、信頼を築いてきました。

この仕事の仕方が成り立ったのは、時代がそれを許したからです。かつて情報システムのユーザーは社内に限られ、定められた事務処理を確実にこなすシステムを作っていればよい時代がありました。業務は安定し、手順は定まっていました。そんな時代であれば「仕様」は確定できましたし、「仕様書通り」に作られたシステムは「使える」システムでもありました。多少の要求変更があっても、「運用で対応」してもらうこともできました。

「何を作るかはユーザーが決め、どう作るかはSIerが決める」。この分業は、当時の合理的な解であり、やがてSIerの常識になりました。契約の形も、見積もりの方法も、プロジェクトの進め方も、人材の育て方も、すべてこの常識を前提に組み立てられています。そして常識とは、疑われないからこそ常識なのです。

時代が求めているのは、別の常識である

しかし、いまは違います。情報システムのユーザーは社外の顧客にまで広がり、そのニーズは予測できません。競合の動き、技術の進歩、規制の変更、顧客の嗜好の移り変わりが、業務のあり方そのものを絶えず揺さぶっています。前提となる業務の内容が流動的なのですから、「何を作るか」もまた、あらかじめ決められません。作ってみて、動かしてみて、初めて何が求められていたのかが分かる。そういう状況が常態になっています。

不確実性が高まる時代にあっては、あらかじめ完全な仕様を確定することはできません。ならば仕様は「仮説」と捉え、実際に動かし、ユーザーの反応を得ながら、売上や利益、ユーザーの期待に応えるシステムへと仕上げていくほかありません。それが、アジャイル開発です。仕様を確定できるのであればウォーターフォール開発でもかまいませんが、確定できない状況で確定したふりをすれば、使えないシステムができあがるだけです。アジャイル開発は選択肢のひとつではなく、時代の要請なのです。

ここで気づいていただきたいのは、この要請がSIerの常識と正面から衝突するということです。「何を作るかはユーザーが決める」という常識は、「何を作るかは誰にも決められない」という現実の前で、拠り所を失います。ユーザーに聞いても答えは返ってきません。ユーザー自身が分からないからです。そのとき、SIerはどうすればいいのか。従来の常識には、この問いへの答えがありません。

アジャイル開発は手法ではなく、関係の組み替えである

アジャイル開発を「開発手法のひとつ」と捉えている限り、この衝突は見えません。スプリントを回し、朝会を開き、バックログを管理する。それらは形式にすぎません。本質は、開発チームが「自分たちはビジネスの不確実性に対処するために存在している」という目的を理解し、ユーザーと一緒になってビジネスを成功させるという明確なビジョンを持って行動することにあります。

これは、ビジネスの現場と開発の現場を切り離し、前者が要求を出し、後者がそれを実装するという旧来の関係では成り立ちません。要求そのものが動き続ける時代には、要求を受け取ってから作る、という順序が成立しないからです。ビジネスの現場と開発の現場が同じ目的を共有し、同じ場で仮説を立て、同じ結果を見て次を決める。そうでなければ、変化に追いつけないのです。

つまりアジャイル開発への転換とは、手法の導入ではなく、ユーザーとSIerの関係を組み替えることです。「指示されたものを作る側」から「何を作るべきかを共に探る側」へ。これは思想の転換であり、企業文化や組織風土の変革です。だからこそ、手法を学ぶだけでは、アジャイルにはならないのです。

見せかけのアジャイル

「我が社はアジャイルに対応できている」という企業は、少なくありません。表面的には、確かにアジャイル的なことをやっています。スプリントがあり、朝会があり、バックログがあり、振り返りもある。ユーザーからアジャイルでの開発を求められれば、応じることもできます。

しかし、中身を見ればどうでしょうか。収益の単位は旧来同様、工数です。契約は請負か準委任で、見積もりは人月で行われます。ユーザーから求められた仕様にしたがってシステムを作ることに終始し、「何を作るべきか」を共に探る関係にはなっていません。ユーザーは発注者であり、SIerは受注者です。企業の文化も風土も、旧来のままです。

これは、見せかけだけのアジャイル開発ではないでしょうか。形式は取り入れたが、常識は何も変わっていない。ウォーターフォールの工程を短く刻んで繰り返しているだけであれば、仕様を仮説として検証しているのではなく、細切れの仕様書通りに作っているにすぎません。それでは、不確実性に対処するというアジャイル開発の目的は果たせず、その真価も発揮できません。もっと本質的な変革なくして、アジャイル開発は根付かないのです。

この見せかけを見分ける手がかりがあります。アジャイル開発をやっていると言いながら、基礎や基本、原理や原則、すなわちソフトウェア工学やコンピュータ・サイエンスをないがしろにしていないか、ということです。なぜ基礎の軽視が見せかけの証拠になるのか。それは、SIerの目の前に迫っているもうひとつの変化、すなわち生成AIによる開発の変容を考えると、はっきりと見えてきます。後編では、この点を述べます。