引っ越したいだけで、住所変更したいわけじゃない 〜宣言的プログラミングで先延ばし人間を救いたい〜

引っ越したい。でもやる気が出ない。

なぜか。引っ越し業者の手配、住所変更、荷造り……やるべきことが多すぎて、ゴールまでの過程がブラックボックスになっているからだと思う。

怠惰が悪いんじゃない。ブラックボックスが悪い。

---

「引っ越したい」 = 「引っ越した状態になりたい」 = 理想の状態の宣言。

ふと気づいた。これ、React みたいな宣言的 UI の思想と同じ構造じゃないか？

// 手続き的：状態が変わるたびにDOMを自分で操作
if (isLoading) {
  button.disabled = true;
  button.textContent = "送信中...";
} else {
  button.disabled = false;
  button.textContent = "送信";
}

// 宣言的：この状態のときこうあってほしいを書くだけ
<button disabled={isLoading}>
  {isLoading ? "送信中..." : "送信"}
</button>

開発者は DOM を操作したいわけじゃない。What だけ宣言して、How はフレームワークに任せる。

React で <Button> と書くとき、「理想の状態を定義している」と強く意識することは少ない。ただ「ここにボタンを置きたい」と書いた結果、宣言になっている。日常の「〜したい」も同じ構造のはずだ。自然な入力が、そのまま理想の状態の宣言になる。

なら、AI に How を任せる設計が成り立つ。

---

宣言するだけで、裏側をいい感じにやってくれないかな。

さすがに全部やってくれる魔法はない。でも本当の敵は「作業そのもの」ではなく、「何をすればいいかわからないこと」だった。

ブラックボックスを開けるだけなら、AIにできる。これでループ抜けられる。

---

そこで、宣言するだけのタスク管理アプリ Declara を作った。

	既存Todo	Declara
入力	タスクを自分で書く	宣言するだけ
初動	Howを要求される	Whatだけでいい
頭の使いどころ	分解・整理	やりたいことに向き合う

技術スタックは Flutter + Riverpod。永続化に Drift（SQLite）、タスク生成に Claude API を使い、Presentation / Domain / Data の3層で分離した。

---

「宣言 → AI がタスク生成」で終わりではなく、宣言してから達成するまでの気持ちの変化に沿って UI を作った。

フェーズ	感情	UI方針
停滞	何すれば…	出発点として受け止める
宣言	ポンと入力	入力UIを極小化
開封	これだけでいい	タスクを見やすく提示
実行	進んでる	進捗可視化 + 完了演出
達成	やりきった	小さく祝う

---

実際にユーザーに使ってもらうと「ちょうどいい理想状態の抽象度を考えるのがむずくない？ 汎用的に使えないし、メモ帳でよくない？」と言うフィードバックをもらえた。

使ってもらって初めて、「〜したい」が理想の状態の宣言として成り立つのは、抽象度が絶妙な場合だけだと気づいた。

抽象度	例	問題
高すぎ	幸せになりたい	分解できない
ちょうどいい	引っ越したい	ここだけ刺さる
低すぎ	食器を洗いたい	分解不要

---

エンジニアは「状態」を点として扱いがちだ。React の state のように、ある時点で確定した一つの値として捉える。

Declara の「宣言」もその感覚でモデリングしていた。つまり、宣言の抽象度も一つだと無意識に決めつけていた。

加えて、自分自身が想定ユーザーだったので、自分の粒度でしか検証していなかった。

ユーザーによって、宣言したい粒度は違う。

この反省以降、アプリの妥当性を確かめる観点として「違う抽象度の入力を想定したとき、このアプリは成り立つか？」を意識するようになった。

---

抽象度の高い理想状態にも対応できるように、宣言を再帰的に分解できる形にしたい。

• ルート宣言: 引っ越したい
• 子宣言: 住所変更したい
• 孫宣言: 転出届を出したい