イノベーションを加速する：競争優位性を生むソフトウェア開発の自動化

従来のソフトウェア開発は遅すぎます。抜本的な再考が必要です。

約3年前、マイクロソフトのサティア・ナデラ氏が「すべてのビジネスはソフトウェアビジネスになる」と有名な発言をしました。今日、5000億ドルのグローバルソフトウェア市場は、2030年までに1兆ドルへ倍増すると予測されています。

J.P.モルガンは、最新の報告書で4万人のソフトウェアエンジニアを抱えていると記録しています（アルファベット社より多い）。すべての大手企業がエンジニア採用競争を繰り広げ、競合を出し抜こうとしています。大きな問題は、従来のソフトウェア開発が遅く、断片的で、無駄が多いことです。

例えば、平均的なソフトウェアエンジニアは毎週、テスト完了待ちに4時間、ビルド待ちに3.5時間、環境管理に3時間を費やしています。勤務時間の4分の1以上が、価値を生み出さない待ち時間です。エンジニアが組織内で最も高給取りであることを考えれば、明らかに深刻な問題です。しかし、状況は変わりつつあります。

主要開発プラットフォームの一つであるCircleCIは、AIと自動化がソフトウェアイノベーションを加速し、エンジニアを重要な仕事に解放する鍵だと判断しました。過去1年で、同社は複数の自動化・機械学習機能を導入し、エンジニアの待ち時間を50%削減しました。これが、Facebook、Spotify、GoPro、InstaCartなどを含む30万人以上の開発者がCircleCIを採用し、開発スピードを上げている理由の一つです。

同社を率いるのは、6度の創業経験を持つジム・ローズ氏です。Google Ventures、Foundation Capital、マーク・アンドリーセンから出資を受けた経験もあります。CircleCI入社から4年余りで、売上を450%以上伸ばし、同社を真にエキサイティングな存在へと成長させました。

ソフトウェア開発の自動化とイノベーション加速について詳しく知りたく、Information Ageはローズ氏にインタビューしました。

現在のソフトウェア市場の状況は？

現在も、多くの企業や個人が様々なプロセスを手作業で行っています。デジタルトランスフォーメーションのプロセスを考えると、それはソフトウェア開発チームを育成しようとすることそのものです。

一つは、ソフトウェアをオンプレミスのデータセンターからクラウドネイティブ環境へ移行し、コンピュートリソースに瞬時にアクセスできるようにすることです。

二つ目は、従来ソフトウェアは主要ビジネスのガイドラインや付随物と見なされてきました。今や銀行から自動車メーカー、小売業者まで、あらゆるビジネスがソフトウェアこそがコアだと気づき始めています。そのため、自分たちが何を保有し、それをどう統合・標準化するかを考えなければなりません。

企業が瞬時のコンピュートアクセスを得て、開発者が働ける構造を整えたとき、その間にあるのは通常、様々なプラットフォームとプロセスの寄せ集めです。

多くの場合、非常に長いウォーターフォール型のソフトウェアリリースプロセスがあり、大量の手作業ステップと手作業スクリプトが含まれます。より先進的なショップでは、第一世代の自動化ソリューションが導入されているかもしれませんが、チームがスピードアップするにつれ、それらが破綻し始めています。

そして今、私たちが企業のナビゲートを支援しているのがこの段階です。ソフトウェアチームがスピードアップし、より多くのソフトウェアを構築し、より速くやろうとする中で、市場機会への対応だけでなく、ネガティブな変化への対応も求められています。ビジネスは、それらすべてのピースをどう組み立てるかを完全に再考する必要があります。

あなたが言及する「スピード」がソフトウェア開発の主なハードルなのか？

企業と開発チームは、市場が加速しているため、自分たちも加速しようとしています。いかに速く働き、機会に対応できるかを模索しています。

そこに到達する唯一の方法は、人間の介入を必ずしも必要としないすべてのステップを自動化することです。分単位、時間単位、日単位かかっていた作業を、秒単位で完了できるからです。

チームが加速し、ソフトウェアが顧客への主要な店舗（店先）になる中で、品質レベルを高く保つ必要があります。クラッシュしない、セキュリティ脆弱性がない、といったことを保証しなければなりません。

アジャイルを考えると、それは品質の観点からもスピードの観点からも、より機敏になろうとすることです。

米国ではすべてがスピードですが、より速く、より小さなチャンクを統合し、より一貫した基準でソフトウェアをリリースすることで、ソフトウェアは本質的に良くなります。デプロイへの恐怖は、週に5回、8回、15回、場合によっては1日100回デプロイするようになれば消え去ります。

デプロイはノンイシュー（問題にならないこと）になります。

品質面では、過去のソフトウェア開発の大きな問題の一つは、四半期に一度しかリリースしない場合、アプリケーションに導入したすべての変更が実際に連携して動くかを確認するのが非常に難しいことです。しばしば「ビッグバンリリース」を行い、その後60〜90日かけて退行・破綻したものを修正する羽目になります。この方式ではソフトウェアサイクルが遅くなるだけでなく、アプリケーション自体の品質も低下します。

アジャイルの観点からは、これが解決すべき課題なのです。

組織はどう変われば、ソフトウェア開発チームを収容・支援・育成できるのか？

いくつかの方法があります。

一つは、開発者の採用が難しいため、開発視点からのすべての時間が、自社固有のソフトウェア構築に専念できるようにすることです。銀行なら優れた銀行アプリ、Eコマースアプリなら優れたEコマースアプリの構築です。私が考えるに、大きく投資不足だった領域の一つは、ソフトウェア開発者は歴史的に「ものを作る」ことしかしなかった点です。それが彼らの仕事です。そのため、開発サイクルはサードパーティアプリの観点からは投資不足でした。

例えば、テスト自動化や継続的デリバリーインフラは、チームが自分たちで構築すべきものではありません。その分野を専門とする他社から調達し、自分たちの得意分野に集中すべきです。コーヒーメーカーを作れと言いながら、銅管、半田、バルブを渡すようなものです。そんなことはしません。しかし歴史的に、開発はそのように扱われてきました。したがって、データセンターからプランニングツールまで、スタックの上から下まで適切なツールとプラットフォームを整えることが極めて重要です。

二つ目は、従来のウォーターフォールモデルでは、ソフトウェア開発は通常「キャッチャー（受け手）」の役割を果たします。アプリケーションはプロセスの早い段階で定義され、開発チームが受け取る頃には、実現可能かどうか、容易かどうか分からない多くの決定がすでに下されています。

「シフトレフト」という概念があり、開発をプランニングサイクルのさらに上流へ押し上げ、開発チームの懸念やニーズがアプリケーションの構築とデリバリーの両方で考慮されるようにします。運用の観点からは、アプリケーションの運用方法をライフサイクルの早い段階で考え抜く必要があります。例えば、クラウドネイティブアプリを構築しようとすれば、非常に特定の方法でアーキテクトする必要があり、その決定に早期から関与する必要があります。

チームがよりソフトウェアファーストのアジャイルプロセスを採用すると、三者の懸念が三角形を形成します。ビジネスオーナーとプロダクトマネージャーが「なぜ作るか」を担い、テクニカルアーキテクトとソフトウェア開発者が「どう作るか」を語り、運用担当者が「最終的に何を実行するか」を決めます。全員が関与する必要があり、これは一部の企業にとって難しい移行です。

AIと自動化は如何にソフトウェアイノベーションを促進・改善できるか？

自動化により、予め決められたタスクと自己学習型タスクの両方を自動化できます。例えば、ソフトウェアをリリースするたびに、サードパーティの決済システムに対するサードパーティテストを行う必要があるとします。過去なら、QAチームを雇って手作業でトランザクション処理を試みさせる必要があり、信じられないほど遅く、エラーと複雑さに満ちていました。

これらはテストスイートで完全に自動化すべきタスクの完璧な例です。繰り返し行うことが分かっているすべてのことを自動化し、決定論的かつ予測可能にし、最終的に高速化します。

開発者がそれらを繰り返し行うことに費やす一分一秒は、時間の無駄であり、率直に言って金の無駄です。

AIと構築中のソフトウェアを見ると、予測的な決定論的ソフトウェアをプッシュするのではなく、モデルをプッシュしています。モデルは、何かがどう動くかという事前の概念のサンドボックスであり、人々がそれを通過し、テストが実行されるにつれて、物事がどう動くか、どう動かないかを学習するにつれてモデルが変化・進化します。これはテストシステムに信じられないほどのプレッシャーをかけます。

AIの失敗例を考えると、無意識のバイアスがAIに組み込まれ、AIが暴走して特定の人々をアプリケーションから締め出したり、システムを停止させたりする状況があります。これらはすべて、テストの観点からは挑戦的な状況です。

ますます複雑になっていますが、同時にずっと速く、レスポンシブになっています。したがって、ソフトウェア開発へのAIと機械学習の導入は増え続けるでしょう。しかし今、それらすべての変化をテストするために必要なフレームワークを整える必要があります。