前回は、テキストベースでモデリングを扱いたくて、このツールを作り始めた背景を書いた。
今回はその続きとして、当初考えていた独立ツール構想から、Obsidianプラグインへ切り替えた理由を整理しておきたい。
全部入りを目指した初期開発
最初に考えていたのは、Markdownベースの定義ファイルを読み込み、一覧・詳細・図表示までを一体で扱える独立ツールだった。
単なる図ビューアではなく、構造化されたテキストを横断的に扱える作業環境を目指していた。
ただ、試作を進める中で、問題の中心は図の描画そのものではないことが見えてきた。
実際に重かったのは、ファイル管理、編集、リンク解決、検索といった周辺基盤の方だった。
そこで途中から発想を切り替えた。
Markdownファイルの保管と編集はObsidianに任せ、自作部分は「構造の解釈」と「表示体験」に集中する。
今回は、その判断に至った理由と、独立ツールとして進めていた試作が、なぜ結果的にObsidian版の近道になったのかを書いてみる。
最初に作ろうとしていたのは、図ツールではなく作業環境だった
当初の構想は、ER図やクラス図を表示するだけのものではなかった。
テキストで定義したモデルを一覧から選び、個別オブジェクトの詳細を見て、関連先へ移動し、必要に応じて図として俯瞰する。そうした一連の操作を、一つの環境で完結させる前提で考えていた。
つまり、目指していたのは「図を描くツール」というより、テキストで持った構造を扱うための作業環境だった。
Electronエディタを内蔵し、ファイル管理とプレビューを実装した。
デザインは後で調整する予定だったが、機能的に実装できる手ごたえはあった。
この段階で、画面の役割分担はある程度決まっていた。
左側で対象ファイルやオブジェクトを選び、中央で定義内容を確認・編集し、右側で選択中オブジェクトの詳細や関連先を確認する。今のObsidian版にもつながるこの基本導線は、独立ツールを考えていた時点ですでに見えていた。
実際に重かったのは、描画よりもファイル管理だった
ところが、実装を進めると、描画ロジックそのものより手前の問題が一気に重くなる。
定義ファイルをどこに置くのか。
どう一覧化するのか。
ファイル間リンクをどう解決するのか。
変更をどう反映するのか。
編集UIを持つのか、それとも既存エディタ前提にするのか。
たとえば、IDベース参照をファイル名とどう結びつけるか、wikilinkをどこまで許容するか、編集結果の再読み込みをどう扱うか、といった論点は、描画以前に詰めないと全体が安定しない。
しかも、この議論は表示体験そのものより、周辺基盤の設計に寄りやすい。
ここで、自分が解きたい問題はファイルマネージャやMarkdownエディタの再実装ではないと、かなりはっきりしてきた。
本当に詰めたいのは、ER図やクラス図をどう見せるか、関連オブジェクトをどう辿りやすくするか、右ペインに何を出せば使いやすいか、といった体験の部分だった。
Obsidianを土台にした方が、責務の分離がきれいだった
そこで改めて見直したのが、普段から使っていたObsidianだった。
Obsidianは、Markdownファイルの保管、編集、検索、wikilinkによる参照、Vault単位での管理といった基盤機能をすでに持っている。
今回のように、複数ファイルにまたがる構造定義を扱う用途とも相性がいい。
そう考えると、独立ツール側で作ろうとしていたもののかなり大きな部分は、すでにObsidianが担えることになる。
ならば、土台はObsidianに任せた方がいい。自作側は、その上で動く構造可視化レイヤーとして設計すればいい。
この切り分けができたことで、実装対象はかなり絞れた。
Markdownの管理ではなく、そこに書かれた構造をどう読み取り、どう見せるかに集中できるようになった。
役割を絞ったことで、データモデルの設計も整理しやすくなった
Obsidianを前提にすると、ファイルそのものの扱いよりも、各ファイルに何を持たせるかが重要になる。
ここでやっと、フォーマット設計に意識を集中できるようになった。
ER側では、er_entity にColumns、Indexes、Relationsを持たせ、er_diagram では対象entityを束ねる構成にした。relationの正本はentity側に置き、diagram側ではそれを集約して図を作る形だ。
一方でclass側では、class ファイルにAttributes、Methods、Relationsを持たせ、class_diagram 側で対象objectと関係をまとめて図として表現する。
同じ「図」でも、ERとclassでは自然な責務の置き場所が少し違う。
ERはrelationの正本をentity側に持つ方が自然で、classはdiagram側でも複数relationをまとめて扱いやすい。
この違いを無理に揃えなかったことが、結果的に設計の安定につながった。
ビュー設計は、独立ツール時代の試作がそのまま活きた
Obsidianプラグインに切り替えたとき、一番大きかったのは、表示体験のイメージがすでにできていたことだった。
独立ツール版では、一覧から対象を選び、右ペインに詳細を出し、関連先を辿るという導線を先に考えていた。
そのため、Obsidian版へ移行しても、UI設計をゼロからやり直す必要がなかった。
実際、図を見るだけで終わらず、そのままRelated Objectsから別のオブジェクトへ飛べる体験は、この初期設計があったから早く形にできた。
最初からObsidianプラグインだけを前提にしていたら、ファイルの読み込みやView登録といった実装都合に引っ張られて、体験設計が弱くなっていたかもしれない。
一度、独立したツールとして全体像を考えたからこそ、一覧、右ペイン、diagram、Related Objectsの関係を比較的早く固められたのだと思う。
結果として、Obsidian版はかなり近道できた
振り返ってみると、独立ツールからObsidianプラグインへ移ったのは、単なる方向転換というより責務の整理だった。
Markdownの管理はObsidian。
構造の解釈と表示はプラグイン。
この分離ができたことで、開発対象はかなり細くなった。
その分、ER図、クラス図、関連表示、右ペイン設計、ズームやレイアウト調整といった、本当に詰めたい部分に時間を使えるようになった。
実際、Obsidian版ではER図とクラス図の表示に加えて、個別オブジェクトの詳細表示や、Related Objectsからの遷移までかなり形になってきている。
最近はむしろ、表示そのものより、右ペインの密度やFitの挙動、Relation一覧の見せ方といった「使い勝手の詰め」の方が大きなテーマになってきた。
これは、最初から全部入りを抱え続けていたら、もっと遠回りになっていたと思う。
これは後退ではなく、実装対象を絞る判断だった
個人開発では、つい必要そうなものを全部自分で持ちたくなる。
でも実際に手を動かしてみると、全部を持つことと、使えるものを早く作ることは別問題だとわかる。
今回やったのは、何かを諦めたというより、どこを自作し、どこを既存基盤に任せるかを整理しただけだった。
その結果、ツールの中心機能はむしろはっきりした。
自分で持つべきなのは、構造化されたMarkdownをモデルとして解釈し、それを「読める図」と「辿れる詳細」に変換する部分だ。
そこに集中できるようになったことが、Obsidian版へ切り替えた一番の意味だったと思っている。
次回は、今の実装でどこまでできているかを書いてみたい
方針が整理できたことで、今はようやく「何を作っているのか」を具体的に見せやすい段階に入ってきた。
次回は、ER図とクラス図をどう扱っているのか、個別オブジェクト表示とRelated Objectsをどう設計しているのか、そして実際に使ってみて見えてきたUI上の課題を整理してみたい。
特に、右ペインの密度、Relationセクションの扱い、高解像度環境での余白、Fitと100%の挙動のように、実装して初めて見える論点が増えてきた。
次回はそのあたりに踏み込むつもりだ。
コメント