軽量なツールの設計は「何をしないか」から始まる — Yomogi の具体例で考える

はじめに

自作のドット絵エディタ Yomogi を開発していて、一番時間をかけたのは機能の実装ではありませんでした。「この機能は入れない」と決めることに、もっとも頭を使いました。

レイヤーは何枚にするか。キャンバスの上限はいくつか。タイルサイズは自由入力にするかプリセットにするか。こうした問いに対して「増やさない」「広げない」と決断するたびに、コードは単純になり、UI は分かりやすくなりました。

この記事では、Yomogi で実際に設けた制約を具体例として挙げながら、「制約を決めることも立派な設計である」という考え方を整理します。

「制約の設計」とは

設計というと「拡張性を担保する」「変更に強い構造にする」という方向がまず思い浮かびます。チーム開発や長期運用のプロダクトでは、その方向が正解になることも多いでしょう。

しかし、個人開発の軽量ツールでは事情が異なります。ユーザーは限られ、開発者は自分一人、スコープは狭い。このような環境で拡張性を追うと、使われない抽象化のためにコードが膨れ上がり、結果として開発もメンテナンスも止まります。

さらに、ユーザ視点に立ってみます。高機能なものは既製品を使う方が良いという場合が多いと思います。私自身、自分のやりたいことに対して、機能が多すぎてわかりづらいと感じることがこれまでも多くありましたから、そのような体験をできる限り減らしたいということも考えています。

以前の記事では、個人開発でオーバーエンジニアリングをした経験を書きました。あの記事は「技術のコスト」を知るという話でした。今回はその逆の視点で、コストを払わないために制約を先に決めるというアプローチについて書きます。

オーバーエンジニアリングの記事はこちら⬇️

銀の弾丸を求めて迷走した私の失敗談。個人開発でオーバーエンジニアリングして気づいた「技術のコスト」の話本や記事で学んだ「理想の設計」を試すと思ったようにいかないことが多いです。実務で失敗すると多大なコストを支払うことになりますが、個人開発であれば安心して試せます。安心して試すことで技術の限界を学ぶことができ、結果的に実務で活かせる経験となります。