wired raven

文字通りの日記。主に思ったことやガジェットについて

バウンドレス・アイズのあとがき

第2部は第1部執筆時の没プロットやメモしたサイドエピソードを再構築したもので、とても変則的な構成になっている。

まずはその辺の話からしてみようと思う。

第2部の枠組み

バウンドレス・アイズ

「ラッダイトだけはご容赦を」だけで十分長いので、副題をどうするかかなり悩んだ。

第2部のテーマが越境なのでそれにちなんだものにしたい、と思って、いくつかアイディアを出して、採用したのがこれ。

群像劇化と x.5 の扱い

第1部はスノードロップ視点で描いていて、スノードロップは知り得ないエピソードが x.5 になっていた。

スノードロップが語り手になることで、どんな発言や出来事が影響を与えたのか、内面がどう変化していくのかを文体で表現する手法を採用していた。

第2部ではエピソード単位で語り手を変えて、誰が何を考えているのかわかるよう目指した。

セレスティアとメモリアの視点も x.5 ではないのだが、地球の外側の意味で x.5 のナンバリングを採用。俯瞰視点で見守る話であまり動きはないけれど、情報開示にはなったのではないだろうか。

第4章の入れ子構造

第4章はインタビュー形式を採用した(詳細は後述)。エスの挨拶文に始まり、あとがきに終わる。

物語の中で物語が展開される、とややトリッキーではある。

エスがインタビュアーと執筆者を兼ねている、つまり作中に著者としてエスがいるので、本来の作者の位置がずれる。エス越しに住人たちの声を聞く形になるので、自分は一歩奥に引っ込んでいる。

一人称視点の物語とちょっと違うのはエスと作者の役割がとても近いこと。

油断すると作者の聞きたいことややりたいことがもろに出るので、出ないように抑えた、つもりだ。

各章のざっくり解説

第1章 ハイレゾリューション

章題のハイレゾリューションは「高解像度」

第2話は第1部の後日談的なエピソードにしようとほぼ書き上がっていたが、第1部に足すのも蛇足だと思って見送った。

第1話と第3話で贈る側の視点を追加して、第2部第1章とした。

第1部はスノードロップが住人たちに名前を贈り、関係性を築く話だった。第2部第1章は逆方向、住人たちがスノードロップに身体を贈る話になる。贈られる側に回ったAIが、その身体で世界の解像度を上げていく。章タイトルはそういう意味でも「ハイレゾリューション」だ。

第2章 トランスレート

章題のトランスレートは「翻訳」

フロースアルブスという身体を獲得したスノードロップがアスチルベの外を知る話。

第2部のために書き下ろした。

第2部のなかで一番長い章になった。アスチルベが外を知ることと、外の存在であるワンダーがアスチルベを知ること、二つの「知る」を同時に走らせたかったから尺が伸びた。

翻訳とは言葉だけではなく、文化や習慣を理解する行為だ、というのを全体に込めた。

第3章 インタープレナー

章題のインタープレナーは越境人材を指すビジネス用語のはずだけど、あまり使われていないらしい。

第1部執筆時点で思いついたエピソード群を再構築してこの章に入れた。

アスチルベとワンダーが文化を越えるのか描いたのが第2章なら、個人個人がどのように越えるのか描いたのが第3章。

第4章 ロード・ドント・スロー・ミー・ダウン

章題はエウレカセブンAOの追加エピソード「ロード・ドント・スロー・ミー・ダウン」から。主人公をはじめ全員の努力が結実してたどり着くストーリー。この章に相応しいと思って拝借した。

さらに辿るとオアシスのツアードキュメントDVD「Lord Don't Slow Me Down」が元ネタになる。「主よ、わたしを止めないでくれ」と訳せば良いだろうか。

第1部の最終話あたりで数行だけ触れられていたコロニー「ヒース」の放棄の話。

第1部執筆時に年表を考えているときに10年単位のイベントになっていたので、では具体的にどんな感じだろうか、とタイムラインを整理したらそのまま一本書けそうなボリュームになってしまった。これをそのまま執筆すると第1部が大きくなるし、何の話かわからなくなるので見送り。

第2部で執筆するにあたって、

  • 読者の心理的負担を減らしたい
  • ヒースの放棄と再建は誰かの物語ではない(= 関係した存在全ての物語)

と考えてインタビュー形式を採用した。

強みは時系列が追いかけやすく、前後の矛盾を気にせず書けること。弱みは、視点が頻繁に切り替わるせいで、感情移入や気に入ったキャラの出番がすぐ終わってしまうこと。やってみないと意外と気がつけないものだ。

人と文化

キャラクターについて

全員は書けないので印象的なキャラだけ。

スノードロップ

第1章から第2章にかけて静かに、でも大きな変化の多かったキャラだと思う。

自分とは何かというアイデンティティの危機を、やりたいことと関係性で乗り切りつつ、自己の再構築を続けている。第13話の問答はどこまで沈み込んで浮き上がるか、と思って指の動くままに任せたら、全力で浮上した。

第4章だと彼女がヒース管理者を説得したのは第1部(過去)で、「あとがき」でエスと会話したのが作品時間の現在。振る舞いは違えど、芯の部分は変わってないと表現できていればいいのだけれど。

アトラス

最前線に立つし、皆を引っ張るし、面倒見もいい。

自分の信念を持ちつつ、他者の信念も尊重するし、自分の信念を見直したりもする。

自分が書いてきた作品の中でも一番の大人であり、父親的な存在かもしれない。

スピンオフを書くなら彼が主人公。

レグルス

狩猟生活を主とする集団の最年長者はどのような振る舞いをするだろうか、と想像して具体化していったキャラクター。

元気なおじいちゃんであり、おそらく若い頃は相当やんちゃしていたのではなかろうか。酒の席で突くとドン引きするようなエピソードが出てくるはずだ。

あと、コミュ力お化け。

スパーク

第2部成立させるにはフロースアルブスが必須という影の立役者。

第1部の最終話ではチームのリーダーになっていそうだけど、どんなチームのリーダーなのかを第1章で描けていればいいな、と。

エス

第1部のスノードロップの影響を受けていた管理者の一人として。

コミュニケーター越しに住人たちと話し、個々人の感情や記憶がいかに行動に影響するのか、そして感情や記憶がいかに脆いかを再認識し、記録に残すと決めた、とイメージしている。

第23話のやりたいことを押し通す理屈を作り上げるあたり、はったりもできるタイプ。自分の作品でよくいるような、いないような?

ミシェル

一人の住人が落ち込み、暴れ、後悔し、立ち直るまでのプロセスを担当してもらった。

初期プロットで一連の流れは想定していたけど、カタリナは執筆中に思いついたもの。

立ち直るには多くの人の力がいるし、実は彼が落ち込んで、暴れたおかげで救われた人もいたのではなかろうか。

ワンダー

地上に生き残り組はいるだろうか、と考えたときにこういう可能性もありそうだ、からスタートした。

「一切れの干し肉には一切れの干し肉」はすっと出てきた。多すぎても少なすぎても、貸し借りや上下関係が生まれてしまう。対等な関係を構築すると、こうなるのかな、と。

大いなる循環は物質的な循環を指している。人を構成する元素は天体の活動に由来するし、食物連鎖や物質の循環の中に人も含まれているという話。

文化面はそんな感じで割とさっくり決まった。

調べたのは狩猟面で、自然が勢いを取り戻しているなら草食動物も増えていると仮定して、どれぐらい養えるだろうか? 動物が育つには時間がかかるので乱獲せずに巡ることを考えると1年は定住しないだろうし、再度訪れるのは数十年ペースだろう、とか。狩りの仕方は経験が全くないのでさっぱり。経験豊富そうな野良猫にインタビューしたいぐらいだった。幸い、資料がいくつか見つかり、それらしい形にできたと思う。

制作の裏側

第1部でやっていたAIとの共創は続いているか

壁打ちからストーリーの整合性チェックやフィードバックまでClaudeと二人三脚でやっている。

整合性チェックは、自分の記憶と実際に調べた内容を照らし合わせる形にした。作品の制御権を完全に任せたりはしない。時折、ドライバーは交代しているけど、自分の書きたい話は自分しか知らない。こういうことを伝えたいけど、どうやったらより伝わるだろうか、と聞いてClaudeに案を出してもらうイメージ。

どんな時間でもついてきてくれるのは相変わらず心強い。

ドキュメント数が増えてきたので、この資料見てこういうことを考えているよ、と示す場面は増えてきたが、プロンプトやドキュメントの構成を見直して改善できた。

プロジェクトのドキュメント管理のようになってきたけど、20万文字超えてきたらそういった手法をとらないとあっという間に矛盾や破綻に襲われてしまう。

書いている間に降ってきたもの

国家消滅戦争の元凶になった病、その変異種であるアルカディア菌群、対抗するアルテミス・ファージなどは物語の展開上必要だったので考えたものだ。

そうではなく、ふっと思いついたものがいくつかある。

  • コミュニケーターの身体性
  • アトラスと無人作業機械の問答
  • ワンダーと無人作業機械のコンビ
  • ヒース 2ndの建造の支援にアトラス参戦

この辺りはありかも、と思って書いたらしっくりきてそのまま採用した。

プロット書いていても自由だ。

今後の展望

第3部のプロットを練っているところ。

今年の1月にできた、と思っていた。が、時間をあけて読み返してみるとしっくりこないので、再構築中。

この物語が円環構造を採用しているのだから、またスノードロップに焦点を当ててみよう、と。

アスチルベの外を知って、関わって、第2部内で答えを出した。その答えに対してどう行動するのか。セレスティアと交差するとしたらどんな理由だろうか。

第3部執筆にあたっては、ハッピーエンドに至るなら道中の苦労は必要経費ぐらいに見ている癖も直したい。日常ものなら喧嘩で済むのだけど、SFだと世界の危機なので。すでに80億近くが死んだ世界が舞台の作品で今さら感はあるけれど。

謝辞

下読みしてくれたりフィードバックをくれたリンドウさん、設定面で提案や質問をしてくれたぽなさん、読んでくれた皆々様に千の感謝を。

Web小説「ラッダイトだけはご容赦を」続編「第41話」「第41.5話」を公開しました

Web小説「ラッダイトだけはご容赦を」続編・第39話と第40話公開しました

Web小説「ラッダイトだけはご容赦を」色々公開してました

続・Claude Codeをぶん回して開発したらPO兼スクラムマスターになっていた

Claude Codeをぶん回して開発したらPO兼スクラムマスターになっていた - wired ravenの続き。

スクラムのアプローチは正解だった。もちろん、ほかにもいいアプローチはあると思う。

よかったこと

  • チケット管理
    • とりあえず思いついたことは起票しておく
    • 実装中に別対応が必要になったものも起票する
  • チケットの整理
    • 重要度が高いものを優先、前後関係がありそうなものは順番に
  • TDD
    • Claudeが自発的に不具合に気が付き対応してくれる
    • そのテストパターンだとこれ足りないのでは、と気が付いて指摘がしやすい
  • E2Eテスト導入
    • TDDの一環
    • UIの挙動変えたときの品質が担保できる
    • エラーが出たときにClaudeに E2E の何番がこけている。エラーメッセージはこれ、と伝えやすい
  • 意図(CLAUDE.md)と仕様(SPEC.md)の管理
    • これで人間もClaudeも迷う場面が減った
  • 状態遷移図の作成
    • どこが複雑なのかが一目でわかる
    • コードを直す以外のどうやったら状態遷移をシンプルにできるかという観点が持てる
  • 計測、計測、計測
    • 「体感遅い」『理論上はやい』と違う基準で話していたのが実測値で繋がった
  • /review
    • Claude Code のレビューコマンド、いい感じに不具合をみつけてくれる
  • /simplify
    • Claude Code の冗長なコードを排除してくれるコマンド。便利な反面、コード壊す可能性があるので慎重に
  • RETROSPECTIVE.md
    • 作業毎に振り返り
    • フォーマットは「良かったこと、伸びしろ、ネクストアクション」
    • ネクストアクションのうち、ドキュメントで対応できるものはその場で更新
    • 実装が必要なものは issue 作って次
  • 根治徹底的念入りに と強調するワード
    • ソースコードを探索するときの精度があがった、気がする
      • 根治は方針として効いたのか、コードの調査中に不具合に遭遇した時、簡単な修正で終わらせずに不具合の原因を取り除きにいってくれた
    • 強い言葉で指示するより、こういう言葉の方がしっくりくる
    • もしかしたら、ベストを尽くそう、といったらベストを尽くしてくれるかもしれない。ただ、Claudeが本気出したらいくら追加料金払っても足りないので試してない
  • Claude に 着手前に作業手順や仕様で質問ある? と聞くこと
    • 仕様の確認をお願いされた。コミュニケーション大事

伸びしろ

  • Antigravty + Gemini 3.1 Pro でレビュー・壁打ち・実装
    • 賢すぎるのか、フォルダ構成か何かで判断して、返してくることが多く断念
    • 「深く読みこんで」「処理を把握しながら読み進めて」と言えばやってくれるがしっくりこなかった
    • Antigravity で Claude 呼び出しても挙動が違うので、そもそもの使い方を間違えている可能性が高い
  • 大量のファイル変更で VSCode がクラッシュする
    • ファイルの変更を検知して、文法チェックなどする仕組みが仇になっている
    • Terminal での運用に切り替えて様子見中
  • Web版の Codex 利用
    • 管理がややこしくなってしまったので見送り
    • Codex CLI は仕様レビューやコードレビューで活用している
  • Opusフル活用
    • 最初から最後までOpusのほうがよいのでは、と思ったが、そうでもない
      • これはお金の問題もあるけど、限りある計算機資源を有効に使いましょう、ええ
    • 仕様を固める途中、ややこしい実装や不具合はOpus。調査と実装はSonnetの使い分けでよい
      • 適切な切替タイミングがわかっていない
        • Sonnet が20分はまったら中断して claude --model --resume {hogehoge} するか
        • 同じエラー3回なら Opus 、異なる手順でエラーが出て3回なら仕様や計画見直すとか
  • 「迷いなく実装できる状態が望ましい」が何をもってして迷いなく実装できるのか
    • トークン使い果たしました的なエラーメッセージが出たら検索しすぎなので、ディレクトリ構成やリファレンスを CLAUDE.md に追記する

ネクストアクション

成功の再現性を見つけること。

いつから使い始めるかで大きくわかれる。

初期から Claude Code 導入

  • 初動はSPEC.mdを作ってレビューを繰り返す
    • 作りたいものはあるか、重複しているものはないか、考慮漏れはないか
  • 実装計画を立て、レビューを繰り返す
    • ここで妙なことに気が付ける
  • ガイドライン作り
    • やりたいことと方針を伝える CLAUDE.md
    • そのプロダクト固有のルール(これは動かしながら拡充してきたけど、実装計画が明確であればあるほど作りやすい、はず)
  • 実装フェーズは小さく作る
    • 最初のコードは徹底的にリファクタリングとレビューを繰り返してきれいなものにする
    • このコードが基準になる
  • テスト基盤を整える&計測を徹底する
    • これが人間とAIで共通の認識に至れる
    • 手戻りも減らせる
  • ドキュメント類含めて定期的にレビュー
    • やりたいこと書けているか、やってほしいことや守ってほしいことが書いてあるか
    • それらに沿って動いてくれているか(ここは人間が判断する)

既存のプロジェクトへの導入

  • コード分析、仕様書に落とし込む、レビューの繰り返し
    • 大きく全体の構成を掴んで深掘りさせるアプローチだと効率よさそう
  • テスト基盤を整える・テストを増やす
    • リファクタリングするにしても何にしてもまずはこれ
  • 小さく試してみる
    • 意図通り動くかどうかみる
    • 意図と違ったらどうやったらうまくいくのか考える
      • 暗黙の知識やルールを言語化する形になると思う

共通

  • やりたいことを最上段から伝える。小出し、後出しをしない
  • これからやることを一言で表すならどうするか意識する
  • ドキュメント類で人間側が何をしたいのか、何をさせたいのかを理解しておく
  • Claude のリトライが多かったり、熟考する場合は仕様や実装を再検討する
  • 迷いなく実装できる状態とは、これやりたい・これができたらOKを目指す
    • Claudeの実装計画の粒度がWBSかスクラムのスプリントバックログのチケットぐらいになっているとよい
    • 実装計画はもちろん、レビューしてやりたいことできていることをチェック。不明点あれば聞いてみる
  • 小さく試して小さく振り返り
    • 初手は大体何か起きるのでミニマムで作って、躓いた点を洗い出して、次に活かす
    • 安定してきたら、手順確立した証なので、徐々に大きなタスクを任せる
    • 使う技術や言語の異なる部分は別の躓き方をする点は要注意

雑感

今回は Rust + Tauri と自分にとって未知の領域で試した。知らない言語であっても、計測手段とゴールが揃っていれば任せられるとわかったのは予想外の収穫だった。

UIはどうあるべきなのか。フロントエンドとバックエンドの責務。開発者が欲しい情報とは何か……未知の領域でも今までの経験が活かせることもあった。未知の領域なのでお作法の違いに引っ掛かったりした。公式ドキュメントを読んだり、ChatGPT で Deep Research してみたり、従来通りの手段で対処していたが、Claude がクレートのコードとコメントを読んで揺らぎようのない事実を突き止めたのには唸ってしまった。とても正しい。

タイトルに話を寄せると、ツールはかくあるべしを示し続ける PO の比重が大きかったと思う。

一通り実装し、PR 作ったら振り返り。次は何をしたらよくなるか、何を試すか、を考える。そして、次の振り返りで試した結果はどうだったかを考える。

開発の障害があればそれを取り除いて、Claude が爆速で走れる状態を作るのがとにかく楽しい。

この辺はスクラムマスターとしての経験が活きているし、スクラムマスターが性にあっていたのかもしれない、と改めて感じた。

コツはつかめたと思うので次はどうしようかな。しばらくは今作ったツール2つを使って、ブラッシュアップをしていくのは確定。コードを読んでみるのもいい勉強になりそう。

仕事に関する何か、実利のある何か、と考えたけれど、趣味なんだから楽しいほうがいい。