【技術学習】 山の日に個人開発の "標高" を測る

完成度ではなく、 僕が到達点で進捗を見る

デイリーノートに、こう並ぶ。

数字は冷静だ。
なのに胸は、減点される。

10% は、ほとんど何もしていないように聞こえる。
分母が完成した理想の Vault だからだ。

結論を先に一行で書きます。

個人開発の進捗は、完成度の % ではない。
いま立っている到達点——標高で測る。

今日は山の日。
山頂までの残りを数える日ではなく、途中の地点をログする日にする。

% は客観的に見えて、 残酷なことがある

みなさんは、個人開発の進捗をどう測っていますか。

タスク消化率。
Issue のクローズ数。
完成までの感覚的な %。

どれも便利だ。
便利なまま、自分を傷つけることもある。

分母を理想の完成形に置くと、分子がいくら増えても足りない。
設計書を書いた。
境界を切った。
README の入口を置いた。
——それでもまだ 10% なら、手は止まっていく。

8 月の種②は、こう置いた。

種まきの宣言と、前倒しの実験で、一手は残した。

今日は、その一手を進捗としてどう名付けるかの話だ。

既存の8割主義は、出してよい完成度の話だ。

今日は、まだ出さない山の途中を、どう認めるかの話だ。
レイヤーが違う。

完成度で測ると、 いつも麓にいる気がした

かつての僕の個人開発は、だいたいこう採点されていた。

城としての個人開発は好きだ。
時間と情熱を注ぐ理由も、何度も書いてきた。

好きなのに、採点が完成度だと、好きが減点に変わる。
受託ならクライアントと動くの定義を握れる。
個人開発は、自分が高すぎる山頂を勝手に置く。

Vault サンプルも同じだった。
配布設計書を書き、Include / Exclude を切り、成功条件を並べた。
それでもデイリーには 10% が残る。
設計が進んでいるのに、数字だけが麓を指す。

——それは進捗の欠如ではなく、物差しの選択ミスだった。

山頂までの残りではなく、 いまの標高を書く

転機は、派手なリリースではなかった。

山の日の朝、Vault の設計書を開いて、こう問い直した。

今、どこに立っている？
次の標高は何か？
山頂（v1.0 の理想）までの % は、今日は見ない。

達成率で 7 月を閉じない、と書いたときの感覚に近い。
手応えで測るとも同型だ。

数字を捨てるのではなく、分母を変える。

地点があれば、登っていないのではなく、途中にいる。
途中にいると分かれば、次の一手は全部ではなく、次の標高になる。

技術選定の記事で、流行を見限って積み上がる判断に寄せたのも同じ向きだ。
学び続けたものと見限ったものは、何を積むかの仕分け。

今日は、積んだ途中をどう測るかの仕分けだ。

ここから先は、測り方の設計です。

【定義】 標高とは何か

この記事で言う標高は、次の意味に絞る。