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

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

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

SIerを支配してきた常識

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

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

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

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

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

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

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

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

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

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

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

見せかけのアジャイル

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

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

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

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

AI駆動開発が、逃げ道を塞ぐ

要求を伝えればAIがコードを書き、テストを生成し、修正案まで示してくれる。こうした「AI駆動開発」は一時の流行ではなく、今後の標準になるでしょう。

人手でコードを書いていた時代、「仮説を試す」ことには大きな時間と費用がかかりました。だからこそ手戻りが起きないよう事前に仕様を固めようとしたのであり、それがSIerの常識を支えてもいました。しかし、コードを書き直す費用が限りなく小さくなれば、「まず作って、動かして、確かめる」ことが最も合理的な進め方になります。クラウドが環境構築の手間を取り除き、そこにAIによるコード生成が加わって、構想から検証までの一巡りは数日、あるいは数時間で回せるようになりました。仕様を仮説とみなす考え方が、ようやく現実的な費用構造を得たのです。

さらに、コードを書く負担が小さくなれば、業務を最もよく知る人たちが自らシステムを作り、育てていくことができます。ユーザー企業の内製化が進み、「指示されたものを作る」仕事は、外注に頼る必然性を失っていきます。工数需要の減少は、もはや避けられません。旧来の常識の上に成り立っていた仕事そのものが消えていくのですから、工数を収益の単位とする見せかけのアジャイルは、その土台を失います。

AIが「書く」ほど、人間には「判断」が残る

では、SIerに何が残るのでしょうか。「AIがコードを書いてくれるのだから、エンジニアはもう基礎を学ばなくてもいい」と考えるのは誤りです。実際はその逆で、AI駆動開発が標準になるほど、基礎や基本、原理原則の重要性は増していきます。

理由は単純です。コードを「書く」という手段がAIに移るほど、人間に残るのは「判断」だからです。何を作るべきか。できあがったものは正しいか。全体にどう組み込むか。AIは選択肢を大量に、速く提示してくれますが、そのどれを選ぶかを決めるのは人間です。

そして判断とは、責任を引き受けることでもあります。AIが生成したコードを採用すると決めた瞬間、その結果に対する責任はAIではなく、決めた人間に帰属します。動かなかったとき、遅かったとき、脆かったとき、意図と違ったとき、「AIがそう書いたので」という言い訳は通用しません。判断を下すとは、その帰結を引き受けると宣言することなのです。

ここに、旧来の常識との決定的な違いがあります。「指示されたものを作る」という仕事は、何を作るかの責任をユーザーに預ける仕事でした。「何を作るべきかを共に探る」という仕事は、その責任を引き受ける仕事です。見せかけのアジャイルに留まるSIerに欠けているのは、手法ではなく、この責任を引き受ける構えなのです。

ならば、責任を引き受けるための判断基準を、自分の中に持っていなくてはなりません。基準のない判断は、判断ではなく賭けです。そして、その判断基準こそが、基礎や基本、原理原則にほかなりません。

たとえば、AIに意図通りのコードを生成させるには、要件を明確に理解し、あいまいさを排して正確に指示しなくてはなりません。そのためには問題の本質を見極め、技術的な要件へと落とし込む力が要ります。「何を作るべきか」を判断する基準は、ソフトウェアがどう動くかについての原理の理解なしには持てません。

また、生成されたコードは必ずしも最適とは限りません。動いてはいるが遅い、動いてはいるが脆い、動いてはいるが意図と少し違う。AIは自信をもって誤ったコードを示すことがあります。その流暢さに惑わされず「これは違う」と気づけるのは、「正しいコードとはどういうものか」という基準を身につけた人だけです。

さらに、生成されたコードを既存のシステムに統合するには、アーキテクチャやデータの流れについての知識が欠かせません。どのAIツールを開発プロセスのどこに組み込むかという判断にも、システム開発全般についての包括的な理解が必要です。

手段が豊富になればなるほど、選び、評価し、責任を引き受ける側の基準が問われます。コードを書く力ではなく、書かれたコードに責任を持てる力。その力の源泉が基礎なのです。

常識が、基礎を軽視させてきた

ところが、私はSIerの新人研修や人材育成に関わっていますが、コンピュータ・サイエンスやソフトウェア工学に時間をかけている企業はほとんどありません。時間をかけて丁寧に教えるのは、プログラム・コードの書き方やシステムの設定方法です。「余計な知識の獲得に時間を割く必要はない。それよりもJavaの文法とお作法を早く覚えなさい」というわけです。

これもまた、旧来の常識の帰結です。何を作るかはユーザーが決めてくれるのだから、作る手段さえ身につければよい。判断は求められないのだから、判断基準も要らない。工数で稼ぐ要員を即席で育てるという育成方針は、「指示されたものを作る」という常識と完全に整合しています。整合しているからこそ、疑われずに続いてきたのです。

先に、基礎の軽視は見せかけのアジャイルを見分ける手がかりだと述べました。その理由がここにあります。仕様を仮説と捉え、動かして確かめ、次を判断するという営みは、判断基準なしには成り立ちません。基礎を軽視したまま形式だけを回している企業は、実のところ判断をしていない、つまり常識が変わっていないということです。基礎の軽視は偶然ではなく、常識が変わっていないことの最も正直な証拠なのです。

「コンピュータ・サイエンスやソフトウェア工学」という言葉は大仰に聞こえるかもしれません。ならば、ソフトウェアが動く原理、有用なソフトウェアが持つ特性や構造、その構築・維持・管理に関わるプロセスについての基礎知識と理解していただければと思います。

世間で「優秀」と評されるエンジニアは、この基礎をしっかりと持っています。ここでいう「優秀」とは、目的を実現する上で最もふさわしいやり方を迅速かつ適切に見出し、そのプロセスを描き、実践できる能力のことです。彼らは新しい手段に直面したとき、基礎に立ち返り、原理原則から従来との違いを把握し、迅速に正しいやり方へ移ることができます。判断基準を持っているからです。そして彼らは、アジャイル開発にもAI駆動開発にも抵抗がありません。

こうした優秀なエンジニアたちは、その知識やスキルを会社に頼ることなく自助努力で身につけています。しかし、会社がその力を活かす機会を与えていないように見えます。「優秀」であるがゆえにプロジェクト管理に忙殺され、トラブル対応に駆り出され、新しいことに取り組む機会を奪われているのです。旧来の常識で動く組織にとって、判断し責任を引き受けようとする人材は、活かし方の分からない存在なのです。これは彼らが望む成長の機会を奪っているわけで、結果として転職を促しているようなものです。

常識を書き換える

SIerがアジャイル開発をできないのは、スキルがないからではありません。「何を作るかはユーザーが決める」という常識に支配され、不確実性に対処するという時代の要請に応える別の常識を持っていないからです。これは思想の問題であり、文化や風土の問題です。だからこそ、手法を学ばせるだけでは変わらず、形式を整えるだけでは見せかけに終わるのです。

工数需要が細っていく中で、SIerは「工数を売る」ことから「技術を売る」ことへと転換しなくてはなりません。内製化支援などはそのひとつです。そして技術を売るとは、判断を売り、責任を引き受けることです。そのためには、コンピュータ・サイエンスやソフトウェア工学を磨くほかありません。

もし「アジャイルのお作法を早く覚えなさい」「AIツールの使い方を早く覚えなさい」と、工数ビジネスと同じ発想で手段を学ばせることに終始すれば、常識は何も変わりません。手段はAIによってどんどん置き換わります。手段だけを学んだ人材は、その置き換えとともに価値を失っていきます。

アジャイル開発の土台にあるのは、自律と不断の改善です。たとえ最初は未熟でも、基礎の大切さを理解し、学ぶ習慣を持っていれば、優れたチームに育つでしょう。工数作業者ではなく、判断し、責任を引き受ける真のエンジニアを育てる必要があるのです。

そのための現実的なアプローチは、新入社員のときから、旧来の常識に染まる前に、基礎の大切さに気づかせ、学びの機会を提供することです。ソフトウェア工学の学習を徹底し、その上にプログラミングやUXデザインを学ばせ、XPやスクラムを実践させる。そして、AIを使いこなしながら、AIの出力を評価し、責任を引き受けられるエンジニアへと育てる。そこに取り組んではどうでしょうか。

「工数を稼げる即戦力」ではなく、「次代を担う変革人材」としての期待を、新入社員に託すべきです。常識を書き換えるのは、常識に染まっていない人たちだからです。工数需要に伸び代がなくなりつつあることに真摯に向き合い、新入社員の育成のあり方も見直すべきではないでしょうか。