【技術学習】 山の日に個人開発の "標高" を測る
完成度ではなく、 僕が到達点で進捗を見る
デイリーノートに、こう並ぶ。
Obsidian Vault サンプル
進捗: 10%
数字は冷静だ。
なのに胸は、減点される。
10% は、ほとんど何もしていないように聞こえる。
分母が完成した理想の Vault だからだ。
結論を先に一行で書きます。
個人開発の進捗は、完成度の % ではない。
いま立っている到達点——標高で測る。
今日は山の日。
山頂までの残りを数える日ではなく、途中の地点をログする日にする。
% は客観的に見えて、 残酷なことがある
みなさんは、個人開発の進捗をどう測っていますか。
タスク消化率。
Issue のクローズ数。
完成までの感覚的な %。
どれも便利だ。
便利なまま、自分を傷つけることもある。
分母を理想の完成形に置くと、分子がいくら増えても足りない。
設計書を書いた。
境界を切った。
README の入口を置いた。
——それでもまだ 10% なら、手は止まっていく。
8 月の種②は、こう置いた。
Vault は届く一歩まで近づける。まるごと完成させない。
今日は、その一手を進捗としてどう名付けるかの話だ。
既存の8割主義は、出してよい完成度の話だ。
今日は、まだ出さない山の途中を、どう認めるかの話だ。
レイヤーが違う。
完成度で測ると、 いつも麓にいる気がした
かつての僕の個人開発は、だいたいこう採点されていた。
1️⃣ 頭のなかに、完成形の山がある
2️⃣ 今日の作業を、その山の斜面に乗せる
3️⃣ 斜面が長いので、% はほとんど動かない
4️⃣ 進んでいないと判断する
5️⃣ ついでにリファクタや別機能が増える
6️⃣ 山がさらに高くなる
城としての個人開発は好きだ。
時間と情熱を注ぐ理由も、何度も書いてきた。
好きなのに、採点が完成度だと、好きが減点に変わる。
受託ならクライアントと動くの定義を握れる。
個人開発は、自分が高すぎる山頂を勝手に置く。
Vault サンプルも同じだった。
配布設計書を書き、Include / Exclude を切り、成功条件を並べた。
それでもデイリーには 10% が残る。
設計が進んでいるのに、数字だけが麓を指す。
——それは進捗の欠如ではなく、物差しの選択ミスだった。
山頂までの残りではなく、 いまの標高を書く
転機は、派手なリリースではなかった。
山の日の朝、Vault の設計書を開いて、こう問い直した。
今、どこに立っている？
次の標高は何か？
山頂（v1.0 の理想）までの % は、今日は見ない。
達成率で 7 月を閉じない、と書いたときの感覚に近い。
手応えで測るとも同型だ。
数字を捨てるのではなく、分母を変える。
完成度の分母:
👉️ 理想の全部
標高の分母:
👉️ なし
（地点の列挙）
地点があれば、登っていないのではなく、途中にいる。
途中にいると分かれば、次の一手は全部ではなく、次の標高になる。
技術選定の記事で、流行を見限って積み上がる判断に寄せたのも同じ向きだ。
学び続けたものと見限ったものは、何を積むかの仕分け。
今日は、積んだ途中をどう測るかの仕分けだ。
ここから先は、測り方の設計です。
【定義】 標高とは何か
この記事で言う標高は、次の意味に絞る。
