Test Management and Coordination During the Vera C. Rubin Observatory Commissioning and Early Operations Using Zephyr Scale

ヴェラ・C・ルービン天文台を、チリの山の上に停車している、信じられないほど巨大で複雑な宇宙船だと想像してみてください。その任務は、宇宙の写真を何百万枚も撮影し、究極の宇宙地図を作成することです。しかし、メインミッションを開始する前に、チームはこれを「コミッショニング（試運転）」しなければなりませんでした。つまり、すべてのボタン、ダイヤル、そしてカメラレンズが完璧に動作するかどうかをテストする必要があったのです。

この論文は、50人以上の専門家チームがいかにして、ソフトウェアのテスト用に作られたデジタルツールである「Zephyr Scale」を使い、精神を崩壊させることなく、何百ものテストをやり遂げたかという物語を伝えています。

以下に、その手法をシンプルな概念に分解して説明します。

1. 問題点：多すぎる料理人と、多すぎるレシピ

50人の異なるシェフが、「何を、いつ、どのように作るか」を決定しようとしているディナーサービスを運営している場面を想像してみてください。しかも、キッチン（環境）は常に変化しています。

• 現実: 天文台のチームは、日々の変更、技術的な不具合、そして新しい科学的目標を調整しなければなりませんでした。彼らは「キッチンのスタッフ」（観測スペシャリスト）に対し、毎晩正確に何をすべきかを伝え、そして実際に料理が美味しかったかどうかを記録する方法が必要でした。
• 解決策: 彼らは Zephyr Scale を採用しました。これは、プロジェクト管理アプリ（Jira）の中で動く「デジタル・レシピ本」のようなものです。これは望遠鏡のために設計されたものではありませんでしたが、チームはこれが混沌とした状況を整理するための完璧なツールであることに気づきました。

2. 3つの主要な材料

論文では、彼らのシステムの主要な3つの部分について述べています。これらを「レシピ」「デイリーメニュー」「料理人のログ」と呼ぶことができます。

• テストケース（レシピ）:
  これは、再利用可能な単一の指示セットです。「ケーキの焼き方」というレシピのようなものです。タイトル、手順のリスト、そして期待される結果が含まれています。

  • 比喩: もしテストが「望遠鏡を星に向け、写真を撮る」ことなら、テストケースは「ステップ1：モーターをオンにする。ステップ2：5秒待つ。ステップ3：写真を撮る」と書かれた正式なレシピになります。
  • 複雑さ: レシピには単純なものもあれば、非常に複雑なもの（数百のステップを含むもの）もあります。後者は JSON BLOCK として保存されます。これは、人間がすべての言葉を読み上げなくても、コンピュータがそのまま「プラグイン」して実行できる、パッケージ化された自動調理キットのようなものです。

• テストサイクル（デイリーメニュー）:
  チームは毎日、新しい「テストサイクル」を作成します。これは、その夜のメニューです。その晩に試す予定の特定のレシピ（テストケース）をすべてグループ化します。

  • 比喩: レストランに「火曜日のスペシャルメニュー」があるように、天文台にも「火曜日の夜のテスト計画」があります。
  • ひねり: 彼らはしばしば、実際にできる以上のレシピを計画してしまいます。時には30個のレシピをメニューに追加しても、実際に調理できるのは23個だけということもあります。システムは、何が調理され、何が棚に残されたかを正確に追跡します。

• テスト実行（料理人のログ）:
  人間が実際にレシピのステップを実行すると、システム内でそれを「完了」としてマークします。これが「テスト実行」となります。

  • 比喩: これはシェフがノートに「ケーキを焼いた。うまく膨らんだ。砂糖を少し増やした」と書き込むようなものです。
  • なぜ重要か: たとえ後でレシピが更新されたとしても、このログは時間を止めた状態で保存されます。これは、特定の夜に何が起きたのかを正確に証明するものであり、数年後に科学者が「なぜ写真がこのような結果になったのか」を理解するために不可欠です。

3. チームの連携方法

論文では、彼らの日常の非常に具体的なリズムについて、まるで洗練されたダンスのように説明しています。

1. アイデア: 誰かが新しいテストのアイデアを出します（例：「カメラが熱に耐えられるかチェックしよう」）。
2. チャット: 彼らは Slack（グループチャットアプリ）で話し合います。
3. 形式化: そのチャットのアイデアを、Zephyr内の正式な テストケース（レシピ）に変換します。
4. レビュー: シニア科学者が、そのレシピが安全で明確であることを確認するためにレビューを行います。
5. 計画: 翌朝、「テストプランナー」がデイリーメニュー（テストサイクル）を確認し、承認されたレシピをメニューに追加します。
6. 実行: 実際に望遠鏡の前にいる観測スペシャリストたちが、手順を進めながらチェックを入れていきます。
7. 週次チェック: 週に一度、チーム全体で集まり、「今週の味（重点事項）」を決める会議を行います。「壊れた部品の修理に集中すべきか？ それとも、もっと写真を撮ることに集中すべきか？」 彼らは、最も多くの学びが得られるものに基づいて優先順位を決定します。

4. 良かった点、悪かった点、そしてひどい点

著者は、ツールの強みと弱点について正直に述べています。

良かった点:

• 永続的な記録を作成する: 紙やホワイトボードとは異なり、システムはすべての変更を記憶します。もしレシピが更新されたとしても、システムはどのバージョンのレシピがどの夜に使用されたかを正確に把握しています。
• 点と線をつなぐ: Jira内で動作しているため、テストをバグ報告やエンジニアリングチケットに直接リンクさせることができ、全員が「なぜそのテストが行われているのか」を理解できます。

悪かった点:

• 少し使いにくい: このツールは望遠鏡のために作られたわけではないため、一部の機能が使いにくいです。例えば、2つのバージョンのレシピを並べて比較するのが困難です。
• 情報の鮮度: ある夜に書かれたメモが、誤って翌日のメニューにコピーされてしまい、スタッフを混乱させることがあります。チームは毎日、これらを手動で清掃しなければなりません。
• リンク切れ: レシピのバージョンが変わると、リンクが切れてしまい、後で古い指示を見つけるのが難しくなります。

5. 大きな教訓

論文は、Zephyr Scaleは巨大な望遠鏡のために作られたカスタムツールではないものの、それが機能したのは チームに規律があったからだ と結論づけています。

彼らはソフトウェアを厳格なルールとして扱いました。

• もしレシピが「準備完了（Ready）」とマークされていなければ、メニューには載らない。
• もしステップがチェックされていなければ、それは行われなかった。

著者らは、天文台の「コミッショニング」が完了し、スムーズに稼働し始めたら、このツールを使うのをやめるだろうと考えていたと認めています。しかし、それでもまだこのツールが必要であることに気づきました。なぜでしょうか？ 単なるウェブサイト上のチェックリストでは、規模に対応できないからです。毎晩何百ものステップをチェックしなければならない場合、自動的に新しいクリーンなログを作成してくれるシステムが必要です。そうすることで、何が起きたのかを見失うことがなくなるのです。

要約すると: 彼らは、ソフトウェアのバグ用に設計されたツールを取り、それを巨大な科学機械を動かすために使用しました。これは、十分な規律と優れたワークフローがあれば、「四角い杭」を「丸い穴」に非常にうまく適合させることができるということを証明しています。