なぜ、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の出力を評価し、責任を引き受けられるエンジニアへと育てる。そこに取り組んではどうでしょうか。

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

。