『ソフトウェア体のライフサイクル』を遊べるVisual Novelにする：一回分の完全なイテレーション振り返り
今回やったのは「リーダーに皮だけ被せる」ことではなく、软件体的生命周期.md という完全な本文テキストを、本当に遊べる日本式GALGAME風のビジュアルノベルへ作り替えることだった。そして最初から最後まで、あるハード制約を厳守した：原文は増えるのはOKだが減らすのはNG。どんなテキストの細部も落としてはならない。
プロセスは一発で完成するものではなく、典型的な「まず動くものを作り、その後ひたすら違和感を削る」連続イテレーションだった。振り返ると、だいたい以下の段階に分けられる。
1. 出発点は明確：抜粋の脚色ではなく、全文の忠実変換
最初から目標は硬かった：
- シナリオの元はローカルの
软件体的生命周期.md - 全文をゲームに入れる
- ゲーム化を理由に原文を要約・セリフ化・ライトノベル化して削らない
- 表現は強化してよいが、テキスト内容そのものは縮めない
つまり今回のプロジェクトの土台の発想は「VNシナリオを新規に書く」ではなく、「原文をビジュアルノベルの進行に適した段落構造に切り分けつつ、全文をいつでも見返せる形で保持する」だった。
以後のシステムで、章ナビゲーション、原文総覧、段落単位の位置特定、バックログ、進捗保存などは、実は全部この前提に奉仕している。
2. 初版は動くが、Visual Novelっぽくない
最初に動くものができた後の最大の問題は、機能不足ではなく雰囲気が違うことだった。
テキストの進行、表示、段落分けはできていたが、UIは「操作パネル付きのWebリーダー」に見え、日本式GALGAMEには見えない。ユーザーの第一反応も直球で、**「このUIがそもそも違う。日本式のgalgameみたいなUIにして」**だった。
そこで次の第一回リファクタは機能追加ではなく、まず視覚言語を正すことに集中した：
- ステージ層・前景層・テキストボックス層を再分離
- 章タイトル、タイトルページ、トランジションカードをビジュアルノベル的表現に再設計
- テキストボックスを普通のWebカードではなく、ステージに固定されたVNダイアログに変更
- 発言エリア、ネームプレート、進捗バー、進行ボタンを日本式VNに近いレイアウトに統合
このラウンドの意味は：まず「ゲームっぽく見える」状態にしてから、ゲームらしいインタラクションを補うこと。
3. 立ち絵を補完し、ステージを「画像がある」から「舞台らしい」へ
ユーザーの要求は明確だった：各キャラに立ち絵が必要。
そこで、主役数人に適当に画像を付けるのではなく、立ち絵システムをきちんと構築した：
- 立ち絵データを独立管理
- キャラごとにステージ上の配置と表示スタイルを持たせる
- 単独・複数・多人同台のレイアウトに対応
- 発話キャラは強調、傍聴キャラは弱化
- キャラごとに台詞テキスト色を対応
ただしこの部分も多くの磨き込みを経た。途中で出た典型問題は：
- 下半身しか表示されないキャラがいる
- テキストボックスが大きすぎてステージを塞ぐ
- 多人数同台でステージが窮屈に見える
- セーブのサムネで頭が切れたり脚だけになったりする
これらに対して多くの修正を重ねた：
- ステージ高さと立ち絵スケールのロジック調整
- human / digital / entity の3種で立ち絵サイズを分ける
- ステージ全体の横移動・縦移動・ズームを許可
- 多人数同台のためのより妥当なslot分配
- サムネ構図を修正し、全身をなるべく保持してセーブカード内で崩れないようにする
最終的には「画像を置いただけ」ではなく、明確な舞台感が出てきた。
4. テキストボックスの自由度は、ほぼ調整可能レイアウトシステムになった
このプロジェクトでユーザーに最も詰められたのがテキストボックスで、結果的に最も深掘りした領域でもある。
ユーザーから非常に具体的な要望が連続した：
- テキストボックス位置のユーザー任意設定
- 角をつまんでサイズ調整
- 透明度調整
- 文字速度は最速で即時表示
- キャラごとの文字色対応
- テキストボックスをフル幅固定にしない
- 狭くも広くもできる
- 立ち絵を常に塞がない
- 順時（右側レイアウト）は最右端に置く
そのため、単に「テキストボックスをドラッグできる」だけではなく、段階的に完全なレイアウトシステムへ発展させた：
- テキストボックスのドラッグ移動
- 四辺＋四隅の8方向リサイズ
- 幅・高さの自由調整
- プリセット配置：中央、左下、右下、左上、右上
- 透明度、フォントサイズ、行間の調整
- カスタム後に進捗へ保存し次回復元
- テキストボックス位置変更に連動してステージ側が回避し、キャラの遮りを減らす
ここで重要な転換点があった。
当初はサイズ変更に対応していても、「最小がまだフル幅」「見た目としてロックされている」問題が残った。そこで最小幅・既定幅・カスタム寸法ロジックをさらに直し、ユーザーが求める自由変形をようやく実現した。「調整できそうに見えて実際は動かない」ではなく。
5. タイトル、章間演出、プレースホルダー情報は、何度も引き算した
もう一つの明確なイテレーション方向は、読書を中断する余計なUIを少しずつ削ることだった。
ユーザーの典型的な不満は：
- 左上のこの2つの枠、プレースホルダーを残さず自動で消えない？
- 書名と第x章の大見出しは章切替時に一度だけ出して、毎文で出さないで
- 説明ブロックを常に画面にぶら下げないで
そこで「必要な時だけ出す」収束を数回行った：
- タイトルページ/章タイトルは、実際の章切替時のみ短時間表示へ
- 通常読書状態では大タイトルとプレースホルダー枠を自動非表示
- 立ち絵なしシーンで大きな空プレースホルダーカードを出さない
- 上部HUDは未操作で自動フェードアウト
- 読書ヒントはデスクトップで未操作後に自動退場
- ドラッグヒントやリサイズハンドルは静かな読書時に弱化し、操作時のみ復帰
- 立ち絵の足元ラベルは静かな読書状態で自動フェード、操作やキャラ変化で再点灯
この一連の調整は、実は全部同じことをしている：
「ツール画面感」を押さえ込み、「読書演出感」を引き上げる。
6. 進行方式を補完し、操作体験を本物のビジュアルノベルに近づけた
基本の進行以外にも、よくあるVNの操作習慣をかなり補完した：
- テキストボックス外クリックで進行
- マウスホイールで次/前
- スペース、Enter、方向キーで進行
- オート再生
- 既読スキップ
- 右クリックまたはショートカットでUI非表示
- 空白領域の長押しでUI非表示切替（モバイル）
ここも一発で正解にはならなかった。
たとえば直近で直した問題は、コントロール展開時はホイールが効くのに、折りたたむとホイールが効かないこと。原因は本文エリアが誤って「スクロールを遮断すべき領域」と判定されていたためだった。判定を修正し、さらに自動復帰も追加して、今後は「コントロールを畳んだ後、本文文字の上にマウスを置いてもホイールで前進/後退できる」ことを保証した。
こうした修正は小さいが重要で、長時間読めるVNになるかどうかを直接左右する。
7. セーブ、バックログ、原文総覧：今回は付属ではなく中核機能
本プロジェクトは最初から「原文保真」が要件なので、通常のゲームでは付加要素になりがちな機能が、今回はむしろ主機能だった：
- オートセーブ
- クイックセーブ/クイックロード
- 複数スロットの手動セーブ
- ロード時にテキストボックス位置・サイズ・読書嗜好を復元
- 直近段落のバックログ
- 章ナビゲーション
- 原文総覧と目次
- ゲーム段落から原文行番号を逆引きして位置特定
特に「原文総覧」と「段落→原文行番号対応」は、「ゲーム化」を非常に透明にする仕組みだ。
ゲーム層だけで進めるしかないのではなく、いつでも完全な原文構造へ戻って、今どの行を読んでいるのか確認できる。
8. セーブサムネと読書状態の細部は、イテレーションの微調整でしか出せない
後半になると、時間を食うのは大機能ではなく、「ユーザーが一目で不快になるが、必ずしも一言で言語化できない」大量の細部だった。
例として：
- セーブサムネで立ち絵の頭が切れる
- 立ち絵足元ラベルがデバッグ情報っぽい
- テキストボックスのヒントやドラッグハンドルが目立ちすぎる
- 上部HUDの常駐が主張しすぎる
- 多人数同台で視線がUIに分断される
これらは基本的に「機能を足す」ことで解決せず、リズム制御で解決した：
- 何を常時表示するか
- 何をフェードアウトさせるか
- 何をhoverでのみ出すか
- 何を状態切替時にだけ短く提示するか
これをやり切ると、体験は「機能が多いWeb」から「静かに読み続けられるビジュアルノベル」へ明確に寄る。
9. 自動化検証は、後期に継続イテレーションできる鍵
後半、ユーザーの一言は明確だった：「あなたは不断に自分で強化・最適化・検証して、このサービスの機能を良くしていって」。
そこで以後は見た目だけを直すのではなく、自動検証の導線も一緒に整備した。プロジェクトにはPlaywright風のUI検証スクリプトがあり、以下の要点を繰り返しチェックする：
- タイトルが適切に表示/非表示になるか
- デフォルトのテキストボックスがステージを塞がないか
- テキストボックスのドラッグ/リサイズ/スナップが正常か
- カスタム位置とサイズを保存・復元できるか
- 上部HUDが自動フェードアウトするか
- 読書ヒントとドラッグハンドルがアイドル時に弱化するか
- セーブドロワー、オートセーブ、クイックセーブのサムネが正常か
- 多キャラ同台でデスクトップ/モバイルのはみ出しがないか
- モバイルの長押しでUI非表示が正常か
- コントロール折りたたみ後のホイール進行が正常か
つまり後の最適化は「1箇所直して他が壊れないことを祈る」ではなく、改修しながら回帰できる。
こういう高度にインタラクティブなUIでは非常に重要で、そうでないと終盤に「Aを直したらBが爆発」が起きやすい。
10. 現在のプロジェクト状態
現時点で、この『ソフトウェア体のライフサイクル』GALGAMEプロジェクトは、かなり完成度の高い可玩性と可読性を備えている：
- 原文全文を保持、要約式の改編ではない
- 日本式GALGAME風メインUI
- 全キャラ立ち絵導入
- キャラごとの文字色対応
- 章切替トランジションとタイトルページ表示
- テキストボックスの自由ドラッグ、リサイズ、透明度調整
- 文字速度は即時表示に対応
- テキストボックス外クリックで進行
- ホイールで前/次
- オート再生、スキップ、UI非表示
- オート/クイック/手動セーブ
- バックログ、章ナビ、原文総覧
- デスクトップ/モバイル対応
- 多輪の「脱ツール化」磨き込み
- 自動化検証スクリプトで継続回帰
最初の目標が「mdテキストをゲームにする」だったとすれば、今のより正確な言い方はこうだ：
完全な長文テキストを、読めて、遊べて、遡れて、継続的に磨けるビジュアルノベルシステムにした。
11. 今回のプロジェクトで一番面白い点
自分にとって今回の開発で一番面白かったのは、「GALGAMEページを作った」ことではなく、このプロセス自体が非常に典型的に一つの事実を示していることだ：
ちゃんとした出来にするのは、初版で機能を全部積むことではなく、ユーザーが「どこが変か」を指摘し続け、それをイテレーションで一つ一つ消していくことである場合が多い。
今回のユーザーのフィードバックは非常に具体的で、多くは「もう少し最適化して」みたいな抽象ではなく、こうだった：
- ここが画面を塞いでる
- ここはなぜフル幅でロックされてる
- ここはなぜ毎文で出る
- これは下半身しか出てない
- 左上はなぜ完全に消えない
- このホイールはなぜコントロールを畳むと効かない
こうした具体的な「なんか気持ち悪い」点が、最終的にプロジェクトを「使える」から「ちゃんとしてる」へ押し上げた。
もし今後も続けるなら、さらに磨ける方向としては：
- 立ち絵スタイルのさらなる統一
- 章演出とBGM/SEシステムの精緻化
- CG/背景切替システムの拡充
- スクリプト編成能力の強化
- より正式な配布パッケージ方式
ただ、現時点のこのラウンドだけでも、これはもうデモではなく、かなり完成度の高い、継続イテレーション可能なVNプロトタイプになっている。