一度きりではなく体験型で移行する

成功したのに、何が起きたか分からない

ここでいう**移行（migration）**とは、ソフトウェアを別のフレームワークや構成へ移し替えることです。話者は以前、フレームワークを移行する作業を、一度に実行するスクリプトとしてエージェントに任せました。スクリプトは、見たところうまく動きました。

しかし、話者には、そのスクリプトが実際に何をしたのかをつかむ感覚が残りませんでした。移行が完了したように見えても、どの順番で何が変わったのかを十分に理解できなかったのです。これは、移行が必ず失敗したという話ではありません。動く結果と、過程を理解していることは別だという話です。

一度に行う方法では、エージェントが多くの処理をまとめて進めます。人は最後の状態を確認できますが、途中の判断や変化は見えにくくなります。結果だけを見ると、次に似た問題が起きたとき、自分で判断するための材料が足りません。

移行をマイクロワールドにする

そこで話者は、移行を出荷用のスクリプトだけにしませんでした。エージェントに、移行を体験できる小さな環境を作らせました。これは、**マイクロワールド（microworld）**です。マイクロワールドとは、対象を意図的に小さく囲み、その中で操作しながら仕組みを理解する環境です。

この例の環境には、次の仕組みがありました。

1. 古いサイトと新しいサイトを左右に並べます。
2. 「次へ」のボタンで、移行を一段ずつ進めます。
3. その段階で実行されるコマンドを表示します。
4. ファイルツリーの中で、ファイルが動く様子を表示します。

つまり、エージェントは処理を自動で進めますが、人は最後まで待つ必要がありません。ボタンを押すたびに、古い状態、新しい状態、実行された操作を結び付けて見られます。人がすべての移行手順を手作業で行わなくても、移行の流れを追える設計です。

図1　ウェブサイトを移行する画面。移行元と移行先のサイトが左右に表示されています。動画の00:14:15を見る

**図1の根拠。**画面には、端末や進行状況の表示と、移行元・移行先のサイトのプレビューが並んでいます。これは、移行を段階的に確認するという説明を支えます。ただし、この画面だけから、具体的なフレームワーク名や内部処理までは確定できません。

見える反復が理解を作る

この方法は、「自動化するか、理解するか」という二択ではありません。自動化はそのまま使い、作業を小さな段階に分けます。そして、各段階を人に見せます。

たとえば、ある段階でファイルが移動し、その後に別のコマンドが実行されたとします。人は、その操作と、古いサイト・新しいサイトの違いを同時に確認できます。すると、「この操作の後に、この部分が変わった」という対応関係が生まれます。この対応関係を段階ごとに積み重ねると、移行全体についての感覚が育ちます。

図2　端末の進行メッセージと、移行元・移行先のファイルツリーを表示する画面です。ファイルの構成と進行状況を同時に確認できます。動画の00:14:26を見る

**図2の根拠。**移行用の画面に、端末の進行メッセージと、移行元・移行先のファイルツリーが表示されています。したがって、移行の内部をすべて説明する図ではありません。しかし、「実行されたコマンド」と「ファイルの変化」を同じ場面で観察する設計は、はっきり示されています。

段階を分けると、問題が起きたときにも考えやすくなります。最後の状態だけを調べるのではなく、どの段階で状態が変わったのかを見られるからです。これは、前の章のデバッガーがインタープリターの処理をタイムラインで見せたことと似ています。どちらも、見えにくい内部の過程を順番に示します。

ただし、移行用の環境の目的は、バグを調べることだけではありません。大きな移行を、人が理解できる大きさの単位に分けることが目的です。

図3　次の段階へ進む操作と、その段階で実行されるコンテンツ収集のコマンドを表示する画面です。サイトのプレビューを見ながら進行を追えます。動画の00:14:32を見る

**図3の根拠。**移行用の操作画面が次の段階に進み、端末のコマンドとウェブサイトのプレビューが同時に表示されています。この見せ方は、移行を一つの不透明な処理ではなく、順番のある作業として示します。計画では、具体的なコマンドの意味や、正確なファイル操作までは確定していません。

出荷するためか、理解するためか

この例では、ソフトウェアの目的を二つに分けて考えられます。

• 出荷のためのソフトウェアは、利用者に機能を提供できる状態まで移行を完了させます。
• 理解のためのソフトウェアは、人が仕組みを学べるように、状態と過程を見せます。

移行を完成させるコードだけをエージェントに作らせることもできます。しかし、話者が求めたのは、それだけではありません。エージェントには、移行を理解するための一時的なUI（ユーザーインターフェース）も作らせました。

ここでいう「一時的」とは、長期間サポートする製品機能でなくてもよいという意味です。移行を学び、確認し、判断する間だけ役に立てば十分です。そのため、理解に必要な表示を、通常の製品画面より自由に追加できます。エージェントが変更を完成させるだけでなく、人が変更から学べる環境も作るという点が重要です。

例：チームでサイトを移行するなら

これは話者が述べた具体的なチーム手順ではなく、この考え方を示すための例です。

チームがサイトを新しい構成へ移すとします。一つのスクリプトだけを実行すると、最後に新しいサイトが表示されても、途中の判断をチームで共有しにくいでしょう。段階的な環境なら、担当者は「今はこのファイル群を移し、このコマンドを実行した」と確認できます。別の担当者も同じ段階を見て、その場で質問できます。

これは、移行を人の手で遅くする方法ではありません。エージェントが処理を進め、人には重要な段階を見せます。自動化による速さと、反復して見ることによる理解を組み合わせる方法です。

この例が示すこと

一度に実行するスクリプトは、最終結果を得るには便利です。しかし、結果だけでは、何が起きたかを理解する材料が足りない場合があります。古いサイトと新しいサイトの比較、段階ごとのコマンド、ファイルの動き、進行状況の表示がそろうと、人は移行の過程を追跡できます。

この例が示すのは、「移行では自動化を使うな」ということではありません。自動化された変更にも、人がその過程を体験できる道を用意するべきだということです。そうすれば、エージェントに作業を任せながら、人はシステムから離れずに理解を深められます。

これは、前の章のデバッガー用マイクロワールドにもつながります。エージェントは、変更を出荷するコードだけでなく、人がその変更を理解し、次の判断に参加するための環境も書けます。自動化と理解は反対ではありません。見える反復を設計すれば、両方を同時に実現できます。