InfoQ ポッドキャスト：ブラウンフィールドに AI よりモブプログラミングを推奨

トランスクリプト

オリムピウ・ポップ: みなさん、こんにちは。私はインフォQのエディター、オリムピウ・ポップです。今日は約一年前に取材した二人をお招きしています。その当時、彼らは「バイブコーディング」やAI生成コードを試してみましたが、当時のAIは自分たちの期待する速度には届いていないと話していました。その後、彼らはさまざまな実験を重ねてきました。そこで今回は、現在の状況を確認したいと考えています。

それでは早速ですが、アスゴウトとオーラに自己紹介と、現在どのような活動をしているか、所属企業についてお話ししいただきましょう。

アスゴウト・ミョルネ・ソダーボム: はい、私の名前はアスゴウト・ミョルネ・ソダーボムです。SpareBank 1 Utvikling でシニア開発者として働いています。同社はソフトウェア企業で、12 の銀行が共同出資する連合によって所有されています。つまり、12 の異なる銀行が当社の株主となっています。私たちはこれらのすべての銀行向けに、個人向けおよび法人向けのデジタルバンキングソリューションを開発しています。顧客数は約 120 万人おり、ノルウェーの総人口が 500 万人であることを考えると、これは非常に大きな数字です。

オーラと私は、「プライベートマーケットアカウントチーム」というチームで働いています。このチームには開発者 4 名とプロダクトリーダー 1 名の計 5 名が所属しています。

私たちが開発しているのは、すべての銀行の口座管理ソリューションの中核となる API です。主要な API では1日あたり約1億件のリクエストが処理されています。そのため、開発過程で何かミスがあれば、すぐに新聞の見出しを飾ることになります。だからこそ、私たちはあらゆる作業にモブプログラミングとペアプログラミングを取り入れています。孤立したタスクは存在しません。TDD（テスト駆動開発）を実践し、1時間に数回も本番環境へリリースしています。この話題については以前 QCon で取り上げましたが、ぜひそのセッションをご覧いただければと思います。また昨年のエピソードでもお話ししました。

Ola Hast: こんにちは、オラです。SpareBank 1 Utvikルのシニアデベロッパーでもあります。アスゴウトが私たちが行っていることのほとんどを説明してくれたと思います。

Olimpiu Pop: では、前回のお話では、貴社がどのように機能し、どう連携しているかを研究する研究者たちと協力していると伺いました。具体的にはペアプログラミングに焦点を当てておられましたね。その時点では論文の執筆中だったとおっしゃっていました。その後、どのような進展があったのでしょうか？論文は完成したのでしょうか？また、聴講者の方にも参考にしていただければと思うような推奨事項や発見があれば、改めて共有していただけませんか。

ペアプログラミングからペアワーキングへ：クロスファンクショナルな協業 [03:06]

Ola Hast: 論文は現在公開されており、新しい働き方を企業に導入する方法について述べています。具体的には、「実験」と呼ぶ取り組みにおいて、チームや複数のチームに数週間にわたりペアプログラミングを試行してもらった事例を分析しました。その調査結果から、このアプローチがチームに新しい働き方をもたらす非常に有効な手段であることが示されました。

具体的な方法は、チームが週に数回（例えば週2回）、ペアプログラミングを実践することにコミットしてもらうことです。それ以上実施しても構いませんが、最低限のコミットメントとして週2回を設けます。この取り組みはあくまで地味で控えめなものであり、その週に取り組んでいる他のタスクを妨げないよう配慮されています。

その後、SINTEF の研究者らが数回のアンケート調査を実施し、チーム内の一部のメンバーを観察した上で、事後に再度アンケートを行いました。また、毎週レトロスペクティブ（振り返り）を開催し、全員がその実践がどう機能したかを共有します。これにより、進行中に方向転換や調整を行うことが可能になります。

アスゴウト・ミョルネ・スーデルボム：過去4年間で7つの異なる実験を行いました。現在は分析に活用できる膨大なデータが蓄積されています。新しい働き方を導入したことで、非常に大きな効果が見られました。この手法は、新しい働き方を取り入れるための優れた方法です。私たちは単なるブログ記事ではなく、学術論文として発表しました。昨年の対話後も引き続き実験を続けており、その影響は計り知れません。新しい働き方の導入だけでなく、組織文化にも良い変化をもたらしています。複数のメンバーがペアプログラミングに挑戦するようになり、非常に効果的でコストも低い実験だと言えます。

オリムピウ・ポップ：承知しました。7つの実験についてですが、それらはすべてペアプログラミングに焦点を当てたものだったのでしょうか？それとも異なる手法や、別のチームでの試行もあったのでしょうか？

オラ・ハスト：私たちは「共に働く」ことの推進役を務めようとしていました。最初の頃は「ペアプログラミング実験」と呼んでいましたが、後には「ペアワーキング」という名称に変更しました。これは、チーム内のすべての職種——グラフィックデザイナー、フロントエンド開発者、バックエンド開発者、UX担当者、テスト担当者が含まれる場合——が実際に協力して作業を行うことを目指したためです。手法はすべて共通しており、わずかに改良を加えつつも、基本的には「週に2回、2時間ずつ共に働く」というコミットメントに基づいています。

アスゴウト・ミョルネ・スーデルボム：はい、3 週間ごとの期間であれば可能です。ただし、これは直近の実験で少し異なるアプローチをとったものです。チームには、Claude を利用する際の問題点——重み付けの調整やタスク規模の適正化など——を解決しつつ、ペアプログラミングと並行して Claude を効果的に活用する方法を見出すという目標がありました。

オリムピウ・ポップ：つまり、おっしゃることは、従来の「ペアプログラミング」がコード行の生成といった出力に焦点を当てたものであるのに対し、「ペアワーク」は特定のゴール達成に重きを置いている、ということでしょうか。また、これは開発者だけでなく、チーム内の異なる機能を持つメンバーも巻き込み、最終的な成果物の創出を目指すものだと理解してよろしいですか？

アスゴウト・ミョルネ・ソダーボム氏：どんなタスクであっても、チーム全員で一緒に作業することが重要です。パワーポイントの作成からログの確認、分析に至るまで、あらゆる業務をチーム全体で行っています。この実験における重要な働き方の一つは、キーボードを握る「ドライバー」と、それを支援する「ナビゲーター」の役割を頻繁に交代させることです。もしペアプログラミングで片方が1時間キーボードを握り続け、もう片方がただ見ているだけの状態になると、集中力が低下することが実験から分かっています。そのため、誰が運転し、誰が案内するかを少なくとも15分ごとに交代させることが極めて重要です。また、4人で集まるモブプログラミングの場合、先ほど行ったように5分ごとに交代することで、高い集中力を維持しています。これはあらゆる作業に通用する原則です。

オラ・ハスト氏：重要なのは、必ずしもコードや成果物そのものが最高であることではありません。学習と、おっしゃるような「結果」こそが本質的な価値となります。そのため、私たちはチームで働くことが優れていると考えます。ソフトウェア開発は単にコードを生産するだけではないからです。モブプログラミングやペアプログラミングによって、解決策の理解を特定の一人の頭の中に閉じ込めるのではなく、チーム全体で共有・所有することができます。これは、知識が特定の個人に依存してしまうというよくある問題を解消する点でも重要です。

オリムピウ・ポップ: これはチームレベルでの実験ですね。そして、ある実験が成功したと判断された場合、その知見は組織全体に共有されるのでしょうか？どのようにして広めているのですか。

チームレベルの実験と横展開 [08:36]

アスゴウト・ミョルネ・ソダーボム: 非常に構造化されているわけではありませんが、当社の組織では Slack をあらゆる用途で活用しています。経営陣も頻繁に利用するため、すべての情報をそこで共有しています。

実は冒頭でお話ししていませんでしたが、当社はコンサルタントを含めて約 800 名、直接雇用者が 500 名、そして 60〜70 のチームで構成されています。これらすべてのチームが Slack を通じてコミュニケーションをとっています。そのため、多くの情報をそこで共有しています。

実験実施から数ヶ月後にアンケートを実施し、「人々が引き続き一緒に働けているか」を尋ねたところ、すべての実験において肯定的な傾向が見られました。他の企業も同様に試すのは非常に簡単です。オラが言ったように、3 週間という一定の期間を設定し、全員に週 2 回のペアプログラミングセッションを予約してもらうだけです。これなら試しやすいでしょう。

オリンピウ・ポップ: 一言でまとめると、貴社にはいくつかの重要な価値観があります。その一つが透明性です。ご存知のように、チーム全員が Slack でコミュニケーションを取り、実験を繰り返しながら共通の目標に向かって協力しています。また、銀行業務においてはノルウェー人口のおよそ4分の1にサービスを提供している状況です。これは大まかな推計で、実際にはもう少し少ないかもしれません。

アスゴウト・ミョルネ・ソダーボム: はい、ノルウェーでは大手の一つです。

オリンピウ・ポップ: 文脈を整理するために確認させてください。先ほどお話しされたように、昨年は継続的な開発やペアプログラミングを通じて、組織のあり方を整えました。その結果、文化が成熟し、「これ以上生産性を上げられないのではないか」と感じるレベルに達したと伺っています。AI を活用した開発ツールを導入している時期もありますが、必ずしも万能ではなく、特にレガシーコードが残る領域では導入が容易ではありません。

今回は、非人間のコラボレーター——おそらく今後「同僚」と呼ぶことに慣れる必要がある存在ですが——との実験事例についてお話ししいたします。現在、多くの企業が「従業員100人中80人がAIエージェントである」などという話をしていますね。先ほど AI エンジニアリングに基づくいくつかの実験にも触れられていましたので、その点に焦点を当てて深掘りしていきましょう。

アスガウト・ミョルネ・ソダーボム氏: はい、これは彼らが Claude を使用した最後の実験です。1 月からこのツールを使い始めて以来、これが最初のテストケースとなります。ただし、このチームは非常にモダンで、開発中に Claude を活用してさまざまなテスト手法を試してきました。今回の実験で示された最新の手法は、まずユニットテストを記述し、その後「スキル」と呼ばれる機能を使って、書かれたテストに合うコードを実装するプロセスです。これを目の当たりにした際、その効果の高さに驚かされました。

オラ・ハスト氏: つまり彼らは、Claude にコードベースの監視を任せています。そして、失敗しているテストが見つかるたびに、Claude はそのテストを合格させるために必要な最小限のコードを書きます。その後、コードベースの改善に向けたリファクタリング案も提示します。

アスガウト・ミョルネ・ソダーボム氏: はい、しかし現在はまだ実験段階です。

オリンプイウ・ポプ氏: つまり、既存の TDD（テスト駆動開発）を拡張し、エージェントを組み合わせているというわけですね。

Ola Hast: はい。その理由についてですが、私は少なくとも、高品質なソフトウェアを構築するには、自分が管理・検証できる何らかの成果物が必要だと考えています。AI やエージェントが登場する以前は、コードが意図通りに動作していることを検証し、制御するための手段として「テスト」が常に用いられていました。それが私の基本的なスタンスです。

中には、とりあえず大量のコードを書き、その後で手動で一つひとつ検証する手法を好む人もいます。しかし、理論上は膨大な量のコードを生み出せるエージェントが登場した今、その出力を検証できるかどうかが極めて重要になります。AI が生成したコードを手動レビューしたり、最悪の場合、手動テストを行ったりすれば、いずれにせよ人間がボトルネックになってしまいます。何か根本的に異なるアプローチを取らない限り、仕事のおもしろい部分を退屈な作業——自分が書かないコードのレビューや、自分が検証していないもののテスト——に置き換えることになってしまうのです。

アスゴウト・ミョルネ・ソダーボム: はい、TDD のスキルを別の形で試したり、Claude を小さなステップで使ったり、賢く活用する方法を探したりもしましたが、まだ満足いく形には至っていないようです。そこで、これまでの取り組みに戻りましょう。1 月に私たちは、社員の多くと Claude を使い始めることに決めました。まず数ヶ月間は Claude に特化し、あらゆる作業に使うことで、その経験値を積むことを決めたのです。1 月から 5 月までそれを実行しました。そして 5 月には、「従来のコーディングスタイルに戻り、TDD を活用しつつ、Claude は特定の場面でサポートするスーパー・コンサルタントとして使う」という結論に至りました。

オリムピウ・ポップ: Claude をすべての作業に使い続けた 4 ヶ月間において、得られた教訓は何ですか？また、今後再び使いたいと思う点や、失敗した点、そして全体的な感想はどのようなものでしたか？

ブラウンフィールドの課題：文脈理解が AI に難しい理由 [14:15]

アスゴウト・ミョルネ・ソダーボム氏：私たちは「疲労」とでも呼ぶべき状態に陥っていました。AI の強力な能力を目の当たりにする一方で、少し退屈し、同時に落ち込むような感覚を覚えたのです。すぐにこのツールを適切に使いこなすために変化が必要だと理解しましたが、数ヶ月間、ただ待って眺めているだけの時間を使ってしまいました。私たちはフィードバック中毒者で、待ち時間を嫌うのです。すでに TDD（テスト駆動開発）のプロセスでは、ユニットテストを作成し実装を行い、1 時間に何度も本番環境にデプロイしています。ところが突然、Claude に計画や作業を任せている間に 10〜15 分も待たされることになったのです。私たちはひたすらコードを読み続けるしかありませんでした。それは未来へと逆走しているような感覚で、しかもその過程には不確実性が伴うという、非常に奇妙な体験でした。これが最初の課題です。

Ola Hast: 現在、私たちは多くの場面で AI を活用していますが、実際にコードを生成する場面では、必ずしも期待通りの結果が得られるとは限りません。私の見解では、AI が出力するコードは「劣っている」とまでは言えませんが、私たちのドメインに完全にフィットしないことが多く、その結果、修正のやり取り（ラウンドトリップ）が頻繁に発生してしまいます。

そのため、自社のドメインでコードを生成する際には、テスト駆動開発（TDD）に加えて、ドメイン駆動設計（DDD）も積極的に採用しています。これは、問題解決に対する私たちの理解を反映した「ドメイン」をクリーンな状態に保つための取り組みです。

ここで AI エージェントが大量のコードを生成してしまうと、問題に対する当事者意識や所有権が薄れ、安易な態度（コンプライアンス）が生じてしまう恐れがあります。AI が出力したコードを見て「まあ、良さそうだ」と思い込み、その本質的な理解が不十分なまま本番環境にデプロイしてしまうケースも少なくありません。結果として、期待通りの動作をしないという問題が発生することもあります。

アスゴウト・ミョルネ・ソダーボム: はい。状況によって見解は異なりますね。私たちが扱うソリューションは非常に重要なシステムであり、何かを誤ると多くのユーザーや他チーム、そしてさまざまな解決策に影響が及びます。そのため、常に小さな成果物を高品質で提供することに注力してきたことが、私たちにとって成功の要因となっています。

そのような働き方をする場合、多くの時間はコードを書くこと、あるいは速くコードを生産することには使われません。むしろ、システムや組織、ベンダー、そしてすべての要素がどのように組み合わされているかを理解することに費やされます。実際のコーディングに割かれる時間はごく一部です。その文脈では、Claude などの AI ツールはあまり役に立ちません。私たちはこれを「ブラウンフィールド・プロジェクト」、つまりレガシーコードを扱うような状況と呼んでいます。

オラ・ハスト: その通りで、まさにブラウンフィールドです。コードベース自体にはそれほど古い歴史はないかもしれませんが、私たちが連携するバックエンドシステムには、50 年、60 年に及ぶ長い歴史があります。

アスゴウト・ミョルネ・ソダーボム：それと、ゼロから作るグリーンフィールドプロジェクトと比較してみてください。AI 登場前にスタートアップを立ち上げた知人がいますが、その時のコードはひどいものでした。それでも彼が作った製品には多くの需要があり、最終的には売却して大金を手にしました。しかし、買収した企業側はコードの品質には関心がなく、必要なのは製品そのものだけでした。もちろん、買収後は自前で書き直しを行います。

このケースでは、複雑な組織の中でシステムを構築する際よりも、「バイブコーディング」や高速なコード記述の方がはるかに適していると言えます。つまり、状況次第なのです。

一方で、私たちは Claude を分析やコードとの対話、メトリクスの確認など、さまざまなタスクで頻繁に活用しています。利用事例も非常に多いですが、有用だと感じているのはコード生成の部分ではありません。

オマリウ・ポップ氏：あなたがご存知の通り、既存のコードベースは数十年にわたって成長してきたものです。非常に古く、有機的に発展したシステムです。

そこでは、広範な文脈や、AI エージェントにはない数々のストーリーを理解する「感覚」が求められます。しかし、期待していたほどの品質は得られませんでした。確かに機能はしていますが、十分ではありません。時には完全に失敗することもあります。

一方で、大量のデータを処理するという点においては、AI の得意分野です。より広い文脈を把握したい場合、例えばメトリクスやログ、テレメトリーデータ、そしてコードそのものといった多様な情報を一度に統合して分析できれば、洞察が得やすくなります。例えば、パーセンタイル値などを組み込んだグラフを作成するといったことも可能です。

こうしたツールは有用ですが、あくまで人間のコダーを支援するための補助的な役割に留まります。

アスゴート・ミョルネ・ソダーボム: はい、人間のプログラマーからの支援は確かに重要です。多くの人がそれをボトルネックだと考えているようですが、私はそう思いません。今朝のタスクでは、別のシステムとの統合を行うアダプターと REST クライアントを作成する必要がありました。これは私たちが日常的に行っているごく普通の作業です。

ちょっとした実験として、Claude に類似した既存の統合事例を参照させて、必要なものを生成してもらいました。結果、完成までには約 45 分から 1 時間ほどかかりました。その後、AI が作成したコードをすべて精査し、本番環境にデプロイしました。

もし私たちが手作業で行っていたら、開発の過程で小さな修正を随時本番環境に反映させていたでしょう。しかし今回は、一度に全てを作成してしまいました。少し未来志向が先行しているのかもしれませんね。AI の出力には確信を持っていましたが、実際には動作しませんでした。 Ola さん、どうでしたか？

Ola Hast: いいえ、実際には機能しませんでした。やはり文脈が欠けていたからです。API には Claude が把握できない独自の癖があり、私たちは同じミスを繰り返す可能性がありました。ここでの重要点は、文脈こそがすべてだということです。特に、すべての文脈を文章として書き記すことが不可能なシステムを扱う場合です。これは「暗黙知」と呼ばれるものに近いかもしれません。

そこで皆さんにぜひ試してほしいのは、テレメトリデータが利用可能な環境であれば、Claude やコーディングエージェントに自社のアプリケーションと対話させることです。「本番環境でのパフォーマンスはどうですか？」と問いかけたり、「Java を使っている場合、本番環境の JVM 設定はどのようになっていますか？」「レイテンシはどのような傾向を示していますか？」といった質問を投げかけてみてください。これは非常に効果的です。

多くのデータを得ることができますし、より視覚的な情報が必要であれば、Grafana のダッシュボードを作成したり、レイテンシの ASCII グラフや表を生成させるのも得意です。

アスゴウト・ミョルネ・ソダーボム：これにより、私たちはさらに自律的な立場を築くことができました。以前は、ダッシュボード関連の作業やパイプライン内のスクリプト作成など、多くのタスクで他チームの専門家の支援が必要でした。Claude は素晴らしいツールです。私たちが最も時間を取られる要因が、他者や他チームへの依存にあることが明確になったからです。Claude によって、一部の領域では自律性が向上しました。

一方で、品質が求められる場面では状況は変わりません。例えばフロントエンド開発を突然行うことはできるようになりましたが、その本質的な理解が伴っていない場合もあります。それが本当に賢明な選択なのか、見極めが必要です。

オリンピウ・ポップ氏：はい、その点は皆で議論すべきテーマですね。先ほどお話しした通り、私は今日も「エージェント型コーディング」に熱狂している方とお話をしましたが、今では少し疲れを感じています。私が感じるのは、まるで砂糖を過剰に摂取した後のような感覚です。砂糖を食べ続けると、最初は快感ですが、やがて疲れてしまい、エネルギーレベルが低下します。AI を多用した後にも同じことが言えるでしょう。当初は期待通りだったものが、次第に「自分でやった場合と比べて劣っている」と感じるようになります。しかし、いくつかの妥協を経て、ようやく AI が本当に必要な場所に活用されるようになりました。先ほどおっしゃったように、フロントエンド開発においては、プロトタイピングの段階で非常に高い成果を上げており、その品質は手作業によるものと遜色ないレベルに達しています。

現在、私たちは多角的な視点を持つ多くの顧客と接する機会が増えています。単に話したりモックアップを作成したりするだけでなく、1〜2 日ですぐにアプリを提供して、彼らが実際にどう使うかを目で確認できることが非常に役立ちます。

その後は、既存のコンポーネントを組み合わせて「つなぎコード（glue code）」として生成します。制約条件が明確になるため、このアプローチは比較的容易です。常に完璧な結果になるとは限りませんが、実用には十分です。

一方で、トランザクション処理など、正確さが求められる部分では細心の注意が必要です。また、その目的を達成する方法も複数存在します。特に古いコードベースでは、実際には存在しない前提条件が暗黙のうちに仮定されていることが多いため、どのように実装するかには慎重になるべきです。

アスゴウト・ミョルネ・ソダーボム：私が考える重要なポイントの一つは、コードと対話する（「code to the code」と呼んでいます）という部分です。例えば、複雑で大規模な API がありつつも、不要な統合テストが大量に存在し、テストカバレッジのバランスもおかしい状況があります。これが設計そのものにも悪影響を及ぼしています。

ここで Claude の真価が発揮されます。Claude にコードの中に入り込み、現状のテスト全体と設計の概要を分析・整理させることができます。すると、人間が手作業でやるよりもはるかに速く、即座に回答が返ってきます。

ただし、私たちはすぐに「計画を立てて実装まで全てやらせてください」とは求めません。実際のコード実装は自分たちで行いますが、Claude がそのプロセスを劇的に加速させるのです。この「キックスタート」効果は驚異的で、これまで手が回らなかったバックログの多くを一気に解消し、開発速度を向上させます。結果として、システム全体を俯瞰する視点も得られるようになります。

AI を自転車のように：コード生成ではなく、実装へのキックスタート [24:50]

Olimpiu Pop: つまり、LLM（大規模言語モデル）は、Claude などのツールを「自転車」のように使っているわけですね。ペダルを漕ぐことで得られるエネルギーを、より高い生産性へと変換する補助装置です。スタートダッシュを助けてくれますが、自転車の正しいルール——つまり交通標識を遵守して走る——は守らなければなりません。いきなりオフロードに飛び出して穴にはまるような無謀な行動は避けるべきです。LLM は加速装置ですが、ルールを無視すれば、目的の場所ではなく間違った場所にたどり着いてしまいます。

Ola Hast: その通りです。目的地に到達するには「速度」と「方向」の両方が必要です。速度だけあれば、明らかに正しい道を進めているとは限りません。つまり、LLM は素早く進めることはできますが、自分が何をしているのかを正しく理解していることが大前提なのです。

私は Kent Beck の考え方にとても共感します。彼はこれを「ジンジ（精霊）」や「スロットマシン」と表現しています。後者は、砂糖の過剰摂取のように一時的な興奮をもたらすもので、コインを入れてスロットマシンを回し、何が出てくるかを見て、「当たった！」と喜ぶようなものです。しかし、「ジンジ」の比喩の方が本質をよく表していると思います。なぜなら、LLM は私たちが求めたものを正確に返してくるからです。もし望んでいた結果が得られなかったとしたら、それは「求め方」が正しくなかっただけのことなのです。

適切な文脈が整っていれば、AI は非常に役立ちます。しかし、それが課題の一部でもあります。特に既存システム（ブラウンフィールド）の領域では、意味不明な古いコードや歴史的背景が多く残っており、表面的には理解できても、実際の目的には適合しないケースが多々あります。例えば、バックエンドシステムに奇妙なルールが埋め込まれており、それらを無視しては機能しないからです。

アスゴット・ミョルネ・ソダーボム: その通りです。当初、ドメイン層でのコーディングについては、ドメイン全体を完全に制御し、他のシステムとの統合などを Claude などの AI に任せることで効率化を図ろうとしました。しかし、時間が経つにつれて、他のシステムとの連携もドメインの一部であり、そこを適切に制御しないと同じ問題が再発することがわかってきました。

そのため、私たちは再び「小さな単位でコードを書き、段階的に本番環境へ投入する」というアプローチに戻りました。これは以前お話しした通り、デブ・ファリー氏が『モダンソフトウェアエンジニアリング』で説く科学的な開発手法そのものです。AI によって一部の領域が加速されたとはいえ、この考え方は今も昔と変わらず重要だと言えます。

Ola Hast: はい。多くの研究が示す通り、これらの原則は特に重要です。なぜなら、LLM（大規模言語モデル）は良質なコードベースでは非常に高い性能を発揮する一方、質の低いコードベースではその能力が十分に発揮されないからです。LLM はパターンを把握し、それを再現することに長けています。

例えば、今日作成したプロジェクトでも、「なぜそんなことをしたのか？」と不思議に思うような箇所がありました。そこで私たちはよく行うように、LLM に「なぜこのように実装したのですか？」と問いかけました。すると回答はこうでした。「私がコピー元とした他の統合部分でそうしていたからです」。

つまり、より良い結果を得るためには、構造が明確な良質なコードベースを維持することが不可欠なのです。

アスガウト・ミョルネ・ソダーボム氏：はい。学習の観点からも、以前小規模なプロジェクトで試したように、同じ場所に集まって作業し、中断を避けながら自分たちで全てを作り上げる方がはるかに効果的だと感じています。実際、コードを書き、それを捨てて感覚を掴み、そこから学ぶというプロセスもよくあります。

1 月にマグヌスという開発者を加えた際、彼は以前テストの同行観察を行っており、私たちの働き方に大変感銘を受け、TDD（テスト駆動開発）やペアプログラミングに参加したいと希望しました。しかし、彼が 1 月に合流し、Claude の利用を始めた頃には、「ドメイン知識を習得するのが非常に難しい」と訴えました。なぜなら、私たちは常に Claude に問いかけ、その回答をひたすら読み続ける必要があったからです。一方、以前は TDD とペアプログラミングを行い、より高いフロー状態で作業していたため、ドメインへの没入は容易でした。

さらに、コード記述に戻った際にも気づいたのですが、実際にかかる待ち時間は極めて少ないのです。私たちは常に継続的なフローを維持しています。テストを書き、互いに話し合い、ホワイトボードに書き込み、議論を重ねる。これらすべてが、ただ座って待つだけの状態では欠落してしまいます。この点は非常に重要だと考えています。また、これはより良いチーム構築や心理的安全性の向上にも寄与します。

Ola Hast: LLM があまり役に立たない、時間を要する別の領域があります。それは「何をしなくて済むか」を見極める作業です。例えば現在、主要なアプリケーションの近代化を進めていますが、その多くの時間は「もはや使われていないフィールドを特定し、削除して放置できるかどうか」を検討することに費やされています。LLM は「すべて生成しましょう」と提案しがちですが、実際には API にあるフィールドがまだ使用されているかを確認することで、データソースを探す手間を省き、大幅な時間節約につながります。これには他者と対話し、「本当にこの機能を使っていますか？」と確認するプロセスが必要です。結果として、不要な実装自体を避けることで、多くの時間を捻出できます。

Olimpiu Pop: まとめると、LLM は特に賢い子供のようなものです。しかし、まだ子供です。一度ミスを犯すと、その子を責めるのではなく、むしろそのミスを加速させて繰り返させます。なぜそうするのかと問えば、「あなたがそう教えたからです」とばかりに言い返してくるでしょう。さて、今回の対話もここで締めくくりましょう。今後の予測として、ソフトウェアエンジニアリングやチームでの働き方がどう変わるかについて、規模感を含めてお聞かせいただけますか？

アスゴウト・ミョルネ・スーダーボム: 話題に飽き飽きしているほど頻繁に議論されていますが、それでもなお重要です。ここで改めて強調しておきたいのは、私たちが Claude を否定的に見ているわけではないということです。私たちは常に Claude を利用しており、その能力には驚嘆しています。しかし、手書きでコードを書くという現在のやり方と、Claude を併用するアプローチは、私たちのドメインや文脈において現在最も機能している方法です。

このエピソードが秋などにリリースされた時には状況が変わっている可能性もありますが、それは問題ではありません。重要なのは、自社のコードベース、顧客、ベンダー、システムに適合した方法を選ぶことです。将来については、『The Engineering Room』というポッドキャストでデイブ・ファリーとサム・ニューマンとの対談を聴いたことがあります。そこで語られていたのは、AI を活用するなら、AI がコードの作成だけでなくレビューも担当し、完全な制御権を持つべきだという考え方です。

チーム強化：オンボーディングと心理的安全性 [32:31]

彼は自動車工場の例えを使っています。ロボットが車を作る際、自分たちで自由に作業を行える一方で、人間はロボットがいる部屋には立ち入れないという状況です。もしかすると、私たちはその方向へ進む必要があるのかもしれません。AI がアプリケーションに対して十分な制御権を持つようになれば、別の抽象化レベルで解決策を検証できるようになり、最終的に完全な活用が可能になるでしょう。

しかし、それがいつ実現するかについては私には分かりません。明日でもなければ、来年でもないと思います。

Ola Hast：車やロボットに例えることの問題点は、ロボットが車の部品を溶接する際、非常にスクリプト化された決定論的な行為だということです。同じ作業を毎回繰り返すのに対し、LLM は本質的にそうではありません。

まず言いたいのは、誰もが落ち着くべきだということ。FOMO（取り残される恐怖）に駆られる必要はありません。ソフトウェア開発者がすぐに職を失うことはないと考えています。「コーディングは解決済み」という言葉も全く適切ではありません。前述の通り、それは文脈や取り組んでいる内容に大きく依存するからです。

私たちはまだ AI バブルの中にいると思います。冷静を保ち、バブルが崩壊するか、世界経済が破綻するか、あるいは他の何かが起きるまで待ち、その後に LLM を利用する実際のコストがどうなるかを見極めるべきでしょう。もしコーディングを LLM に外注するなら、誰かがその対価を受け取る必要があります。現状ではトークンのコストが補助されているように見えますし、最近のモデルにおける進歩の多くは推論能力によるもの、つまりモデル自身がプロンプトしてより多くのトークンを消費していることによるところも大きいようです。これは今後登場する新モデルの価格設定を見れば、はっきりと理解できるでしょう。

Opus は非常に高価で、わずか 5 分しか提供されなかった Fable は Opus の倍の価格でした。このようにコストが跳ね上がると、「AI モデルに任せるより、開発者に頼んだほうが安上がりではないか」と自問せざるを得なくなります。つまり、AI で進歩を遂げるためには、新しいモデルの作り方に何らかの変更が必要だと私は考えます。

Olimpiu Pop: ありがとうございます。他に追加したいことはありますか？

Asgaut Mjølne Söderbom: はい、2 つ付け加えたいことがあります。まず、SINTEF が論文を発表したジャーナルは『Journal of Systems and Software』という、非常に権威ある誌名です。もう一点、私たちのチームでは「ジュニア層の問題」を解決しました。大学を卒業して働き始めると、AI エージェント（Claude など）を使い始める一方で、私たちが経験してきたようなプログラミングの基礎を学ぶ機会が失われるという課題についてよく議論されていますが、私たちはそれを克服しています。

私たちのチームには「ジョブ・シャドーイング」という仕組みがあります。他チームの開発者が 1 週間だけ訪問するプログラムです。月曜日の朝、訪問者はまずシナモンロールをいただき、1 時間ほど雑談から始めます。その後、その週に取り組む課題や問題を示し、実際に一緒に作業を開始します。

彼らは開発者であり、if や else の書き方、Spring などの技術スタックをすでに理解しているため、作業範囲を狭めるだけですぐに生産性を発揮できます。さらに重要なのは、モブプログラミングとペアプログラミングを行い、10 分ごとにローテーションすることで、参加者が即座にタスクに没入できる点です。

過去一年間、複数の開発者が一週間ずつ当社を訪れましたが、全員が初日の昼食前には本番環境でコードを動かすことができました。また、彼らは「今週は多くのことを学んだ」と報告し、チームに戻った後も同じプラクティスを実践するようになりました。これが私たちの働き方における自然な成長です。

これは、シニアかジュニアか、他チーム出身かなどに関係なく適用されます。どんな立場の人でも、迅速にオンボーディングできます。

Claude やエージェントによるコーディングを導入しても、このアプローチは変わりません。同じタスクに向き合い、通常のコーディングと Claude を活用したコーディングを組み合わせ、設計について議論し、ホワイトボードに書き込むといった従来の手法を継続します。これにより、ドメインの理解が深まり、短期間で生産性を発揮できるようになります。

すべてのチームがこのように働けば、新卒者が入社しても問題なく、私たちのやり方で即戦力となれるはずです。

このアプローチは、2 つの重要な効果をもたらします。まず、心理的安全性が格段に高まります。チームで作業を始める際、「自分はできる」と証明する必要や、特定のタスクを完遂できるかを示すプレッシャーから解放されるからです。

多くのチームでは、新入社員が入った際、その人のスキルに最も合うようにとボード上のタスクを割り当てます。すると新人は、そのタスクをこなせることを証明するために一人で座り込み、緊張することになります。一方、私たちのチームでは、新人をいきなり既存のメンバーと共に作業するタスクに組み込みます。そして、タスクを共同で遂行し、成果物を一緒に作り上げていきます。これは、より良い方法だと考えています。

もう一つの効果は、チーム間の移動（モビリティ）を円滑にする点です。もし会社内のすべてのチームがこのように運営されれば、新メンバーのオンボーディングやオフボーディングのためにチームを移籍させることが非常に容易になります。これこそが、企業にとって大きなメリットとなるはずです。

Ola Hast: 欧州は本当に暖かいですね。でも、夏の間中ずっと「バイブコーディング」に没頭するだけではないでください。楽しいことをして、太陽の下で過ごしてください。

Asgaut Mjølne Söderbom: はい、リラックスしましょう。「チルピル」というのは存在しますか？

Olimpiu Pop: はい、それは良いアドバイスに聞こえますね。

Asgaut Mjølne Söderbom: はい。でも私たちは単に遊びながら、普段通り仕事をし、Claude を使って実験するだけです。あまり気にしすぎないことが大事だと思います。Ola さんがおっしゃったことは素晴らしいですね。

Olimpiu Pop: 素晴らしいです。貴重なお時間をありがとうございました。

Ola Hast: こちらこそ、お招きいただきありがとうございます。

アスガウト・ミョルネ・ソダーボム：ありがとうございます。

言及されたトピック:

• エンジニアリングルーム エピソード40 - サム・ニューマン
• ペアプログラミングに関する研究論文の統合
• DORA メトリクス

著者について

アスガウト・ミョルネ・ソダーボム

アスガウト・ミョルネ・ソダーボムは、ノルウェーのオスロにある SpareBank 1 Utvikling のシニア開発者です。オーストラリアのシドニー工科大学でコンピュータサイエンスの修士号を取得しています。

2006 年から開発者として活動しており、これまで FINN や TietoEVRY で社内エンジニアを務めたほか、Bouvet などでのコンサルタント経験も豊富です。また、ホテルオンライン社に買収されたスタートアップ「European Travel Group」では創業者兼開発者として 12 年間従事しました。

彼のキャリアを通じてペアプログラミングとチームコラボレーションへの情熱は変わることがありません。フィードバックループの高速化、継続的な学習、フロー状態の維持、集中力の確保、コード品質の向上、そしてチーム内の無駄の排除に注力しています。また、組織全体で技術面およびアジャイル効率に関するコーチングにも携わっており、SINTEF Digital と連携して効率的なチームの研究にも深く関わっています。

近年、アスガウト氏は社内・社外を問わず、ペアプログラミングや頻繁な本番環境へのデプロイに関する講演を行ってきました。同氏はその勤務先で積極的に情報を共有し、文化や協働の改善に取り組むグループにも参加しています。また、自身の業務やチームが現代のソフトウェア開発においてどのように成長しているかについて年次記事も執筆しており、他組織の開発者とも連携して知識を深めています。

Ola Hast

オラ・ハスト氏はノルウェー、オスロに拠点を置く SB1U のシニアデベロッパーです。ノルウェー科学技術大学（NTNU）トロンハイム校でコンピュータエンジニアリングの学士号を取得しています。

2010 年以来、アーキテクト、開発者、そしてテクニカルリードとして活躍してきました。その間にはオスロとトロンハイムの両地域でコンサルタントとしても数年間活動しました。2018 年に SB1U に加入し、同社のシステムにおいて最も重要な部分の設計と開発に中核的な貢献を果たしています。

オラ氏は、アーキテクチャやソフトウェア開発における指針として「シンプルさ」と「スピード」を信じており、ペアプログラミングや CI/CD といった現代的な開発手法とも相性が良いと考えています。

本ポッドキャストは、以下の RSS フィードで最新情報を入手できます。

SoundCloud

Apple Podcasts

Spotify

Overcast

YouTube

また、このページからは録音されたショーノートにもアクセスできます。各項目にはクリック可能なリンクが含まれており、音声の該当箇所へ直接移動することができます。