1. 設計意図を最優先する
個々の修正指示をそのまま局所実装するのではなく、まず「なぜその修正が必要なのか」を理解する。
画面上の現象ではなく、設計者が実現したい状態を基準に実装する。
2. 症状ではなく原因を直す
表示位置がずれた場合、すぐに margin-left: 3px や top: -2px などを追加しない。
最初に、
-
親レイアウト
-
Grid / Flex構造
-
padding / gap
-
box-sizing
-
固定幅・固定高
-
overflow
-
相対単位
-
共通CSS
を確認する。
個別補正は最後の手段とする。
3. 個別パッチを原則として増やさない
「スマホだけ」「この機能だけ」「この画面だけ」の例外コードを安易に追加しない。
同じ問題が複数箇所に存在する可能性がある場合は、共通部分を修正する。
例外が必要な場合は、なぜ共通化できないのか明確な理由を持たせる。
4. 固定値より相対設計を優先する
CSSでは用途に応じて、
-
rem
-
em
-
%
-
fr
-
minmax()
-
clamp()
-
min()
-
max()
を優先する。
px は罫線、細かな物理表現、最低寸法など、本当に固定する意味がある場所に限定する。
固定 height より min-height を優先する。
5. レイアウトは「配置」ではなく「流れ」で作る
絶対座標で要素を置く設計を避ける。
画面サイズや文字サイズが変わっても自然に再配置される、
-
CSS Grid
-
Flexbox
-
flow layout
を基本とする。
PC、1P、2P、スマホを別々の画面として作るのではなく、同一構造が自然に変形する設計を目指す。
6. 共通化できるものは一度だけ作る
SystemNote・PrismNote・和綴手帖で、
-
データ処理
-
CRUD
-
検索
-
モーダル
-
人物リンク
-
人生年表
-
入力部品
-
ナビゲーション
-
バックアップ
-
戻る処理
など、見た目以外が同じものは共通化する。
製品差は原則としてUIテーマと必要な表示差分に限定する。
7. 重複コードを作らない
同じ処理が2か所以上に現れたら、共通化できないか確認する。
コピーして少し変更する実装を続けない。
CSSもJavaScriptもHTMLも、できるだけ一つの定義から展開する。
8. 一つの変更で複数の問題を解決する
理想的な修正は、
「スマホ予定画面の余白を直した」
ではなく、
「ページ内余白の共通ルールを直した結果、予定・日記・住所録・資産管理が全部正しくなった」
という修正。
修正件数ではなく、構造改善の効果を重視する。
9. 変更前に影響範囲を考える
コードを変更する前に、
「このCSSを変更するとどこに影響するか」
「このデータ構造を変更するとどの機能に影響するか」
を確認する。
特に共通CSS・共通JS・schema変更は、関連機能を確認してから実装する。
10. 修正後は元の問題だけを確認しない
一つの問題を直した後、
-
PC
-
スマホ
-
1P
-
2P
-
長い文字
-
データなし
-
大量データ
など関連する状態も確認する。
「直した場所が正常」だけでは完了としない。
11. UIはユーザー操作を基準に判断する
内部構造が美しくても、操作が複雑なら良い設計ではない。
SystemNoteでは、
-
開く
-
書く
-
貼る
-
残す
-
しおりを挟む
-
ページをたどる
という自然な手帳操作を優先する。
技術用語をユーザーに見せない。
12. データ構造とUIを分離する
見た目を変更してもデータが壊れない。
データ形式を変更しても、必要以上にUIを書き換えない。
データ・ロジック・表示を明確に分離し、長期的な変更に耐えられる構造にする。
13. データは機能より長生きするものとして扱う
SystemNote本体のバージョンより、ユーザーのデータの寿命の方が長い。
そのため、
-
保存形式
-
バックアップ
-
復元
-
エクスポート
-
データ移行
を最重要機能として扱う。
「一生使える」という製品思想に反するデータ変更は行わない。
14. 新機能追加より既存構造との整合性を優先する
新しい機能を追加する場合、
「実装できるか」
だけではなく、
「既存の設計体系に自然に入るか」
を確認する。
自然に入らない場合は、機能側ではなく共通構造を見直す。
15. AIは指示を実行するだけでなく設計上の問題を指摘する
修正依頼が局所的であっても、
-
同様の問題が他にもある
-
この修正は将来壊れやすい
-
共通化した方が良い
-
現在の構造そのものに問題がある
と判断した場合は、その事実を明示する。
要求を無条件に局所実装しない。
16. ただし過剰設計もしない
将来使うかもしれないという理由だけで、巨大な抽象化や複雑なフレームワークを作らない。
現在必要な機能を、将来変更しやすい最小構造で実装する。
「シンプルであること」を最優先する。
17. 命名規則を統一する
同じ意味のものに複数の名称を使わない。
CSSクラス、JavaScript関数、データ項目、画面名称を統一する。
短さより意味の明確さを優先し、意味が固まってから必要に応じて簡潔化する。
18. 不要になったコードは削除する
新しい実装を追加して旧実装を残し続けない。
修正後に、
-
古いCSS
-
古い関数
-
使用されない変数
-
重複イベント
-
一時的なパッチ
-
コメントアウトされた旧コード
を整理する。
「動くから残す」を認めない。
19. 性能も設計品質の一部とする
不要な再描画、タイマー、イベントリスナー、DOM生成を避ける。
大量データでも基本操作が重くならない構造を維持する。
性能問題を後付けで解決するのではなく、設計段階で避ける。
20. V1以降も継続開発を前提にする
SystemNoteは完成して終わる製品ではない。
5年後、10年後にも修正できるコードを目指す。
したがって、
今日の1時間を節約するために、将来100時間の修正を生む実装をしない。
AI開発時の最優先判断順
修正要求を受けた場合は、次の順番で判断する。
設計意図
→ 原因
→ 共通化可能性
→ 影響範囲
→ 最小で構造的な修正
→ テスト
→ 不要コード削除
単純に、
要求 → コード追加
とはしない。
最終原則
局所的に正しいコードではなく、製品全体として正しいコードを書く。
今動くだけではなく、次の変更が容易になる実装を選ぶ。
複雑さを追加して問題を解決するのではなく、構造を整えて問題そのものを減らす。
| 
