このドイツ語の記事は、codecentric のシリーズを締めくくるもので、シリーズの前半の回ではコーディングループの中で AI 統合を機能させることを扱っていた。記事の出発点となる主張は、技術的なコード生成は話の一面にすぎないというものである。コード生成が劇的に加速すると、システムの残りの部分に大きな圧力がかかる。左側では、要件定義が、ますます短くなるサイクルの中で、何を正確に作るべきか、それが正しいものなのかという問いに直面する。右側では、素早く生み出された成果を、同じくらい素早く確実に実地で確かめなければならないという圧力がかかる。記事は、この両端を使いこなせなければ、得られた速度はコーディングのサイロの中で失われてしまうと論じる。
記事は シフトレフト を、開発ライフサイクルのより早い段階で品質と明確さを確保することと定義し、その決定的なてことして仕様を挙げる。また シフトライト を、品質ゲートとテストの実行を実際の実行時コンテキストへ移すことと定義する。記事は、どちらの概念も DevOps とプロダクトの世界から来たものだと指摘したうえで、AI がその両方を増幅すると論じる。だからこそ、記事の説明では、AI をコーディングループの中だけで使うと、その潜在力の多くが使われないまま残り、新たなボトルネックが生まれるのだという。
要点
- 記事によれば、AI は仕様に対して 2 つのレベルで働く。人が書いた仕様を AI の支援で検査できるうえ、AI が要件を積極的に補完し、矛盾を指摘し、適切なテストケースを提案することもできる。
- 運用の側では、かつて手作業だった仕事を AI がスケールさせると記事は述べる。自動トリアージ、ログ分析、パターン認識が今では自動で行われている。
- 記事は、実際には作業時間の配分が変わると報告している。独立した専門分野としての仕様策定であるスペックエンジニアリングがはるかに大きな比重を占めるようになり、純粋なコーディングの割合は目に見えて縮小する。
- エンジニア、デザイナー、プロダクトマネージャーが互いの仕事にますます入り込むようになり、速度が上がったことで並行作業が求められるため、開発者が要求工学やデザインにも責任を負うようになると論じている。
- 保険会社の顧客プロジェクトから匿名化した例を 1 つ挙げている。LLM 支援による仕様レビューのために 2 週間の一度きりのセットアップを行った後、機能あたりのコーディングループの反復回数が平均 4.2 回から 2.1 回に減少した。
- 仕様を増やすのはウォーターフォールのように聞こえるという反論に対しては、シフトレフトとは、次のコーディングサイクルに入る前にそのサイクルのための仕様を研ぎ澄ますことであり、最初に一度だけ固定するのではなく継続的に洗練していくものだと答えている。
- 本番環境向けの AI 支援 ── 自動トリアージ、根本原因分析、異常検知、そしてパフォーマンス低下時のロールバックのような自動修復 ── は技術的には今日すでに利用可能だが、使っているチームは少ないと記事は述べる。その理由は技術の不足ではなく、そのための具体的なパイプラインのステップが構築されていないことだという。
- 記事が報告する経験では、ほとんどの AI 施策はシフトライトでつまずく。学習のループが構造的に根付いていない ── 本番データを評価する定期的な場がなく、インシデントの傾向をロードマップの変更につなげるリズムもない ── ためであり、その結果、記事が「シフトライト劇場」と呼ぶ状態、つまりデータは存在するのに使われない状態が生まれる。
- ドイツにおける両方の動きの成熟度は、まだ始まったばかりだと評価している。
背景
記事は、2 つの動きが合わさって閉じた学習システムを形づくると論じる。シフトレフトは何を作るべきかという像を研ぎ澄まし、シフトライトは作ったものが実際に機能するかどうかを持ち帰る。そして片側だけを確立するのは堂々巡りに等しいという。記事は両者を、AI 統合を持続的に役立つものにするための必要条件として提示し、どちらにも新しい役割、それに合わせたインフラ、新しい仕事のリズムが必要だと述べる。また、純粋に技術的な安全確保として扱うシフトライトを、利用者にとって正しい問題を解いているかを問うプロダクトレベルの学習ループとは区別している。記事は、支援を求める組織に codecentric への問い合わせを呼びかけて締めくくられ、Red Hat、Sequoia Capital、Codacy による関連文献を推薦している。