一人開発のEstimateは、残り日数より抱えている作業の偏りに使う

「今週は3件進める」と決めても、その3件がメール配信の調査なのか、複数端末にまたがる機能なのかで重さは変わります。件数を揃えただけでは、引き受けた量を比べられません。

個人開発のSquadNoteで使っているPlaneのWork Pointsを読み取り、同じ件数をポイントでも比較しました。集計では、進行中の作業が大きいものへ偏っていました。期限の予測精度は検証していません。ポイントの合計から「あと何日」とは計算していません。

確認日は2026年9月11日。個人Workspaceの非アーカイブWork Itemを52件取得し、一覧の次ページがないことまで確認しました。集計はPython 3.14.5で実行しています。チケットの作成、見積りの変更、状態の更新は行っていません。

先に、ポイントの意味を読む

PlaneのEstimatesには、数値、カテゴリ、時間という種類があります。ここで使われていたのはWork Pointsという数値の尺度で、値は1, 2, 3, 5, 8でした。

Projectの説明では、調査・設計・実装・テスト・PR・配信・実機確認を作業量へ含めています。これはソースコードを書いた時間だけの点数ではありません。5は半日から1日、8は1日から3日という目安もありますが、過去の作業時間を測って換算係数を求めたものではありません。

さらに個人用の起票ルールでは、未着手なら全体、途中まで進んだ移行チケットなら残作業を見積もります。取り込んだチケットと新規チケットで基準時点が違う可能性があるため、保存済みの8ポイントを「今から必ず3日かかる」と読み替えません。

この尺度は、次に取りかかる作業の大きさを尋ねる入口として使えます。優先度は別のフィールドです。小さい作業を先に片付ければ、価値の高い作業が進むとは限りません。

未設定を0として合計しない

集計前に、完了とキャンセルを除いた全件のポイントを調べました。結果は次のとおりです。

状態のグループ	件数	保存済みポイントの合計	未設定
Backlog	11	68	0
Todo	5	32	0
In Progress	6	48	0
合計	22	148	0

完了済みにはポイント未設定が12件、キャンセルには1件ありました。これらは今回の未完了集計から除外しています。完了済みの既知ポイントだけを足しても、一定期間の処理量は分かりません。Cycle履歴、途中追加、見積り変更の履歴を取得していないためです。

次は、取得結果をidentifier / group / pointsへ正規化した後に実行した関数です。groupには表示名ではなくstartedなどのグループ値を渡します。

def summarize_open(items):
    active = [x for x in items if x['group'] not in {'completed', 'cancelled'}]
    missing = [x['identifier'] for x in active if x['points'] is None]
    if missing:
        raise ValueError(f'Missing points: {missing}')
    if any(x['points'] not in {1, 2, 3, 5, 8} for x in active):
        raise ValueError('Unexpected point scale')
    if len({x['identifier'] for x in active}) != len(active):
        raise ValueError('Duplicate work item')
    return {'count': len(active), 'points': sum(x['points'] for x in active)}

実データは通りました。ローカルの入力コピーへ未設定、0、尺度外の13、同一IDの重複をそれぞれ入れると、4ケースとも停止しました。未設定を黙って0へ変える処理は入れていません。

これはローカル集計の確認です。Planeの見積り機能自体を変更したり、実環境の異常値を発見したりしたわけではありません。

同じ3件でも、11ポイントと24ポイントになる

未完了の中から、既存の値を変更せず二組を選びました。比較用の抽出であり、今週の採用計画ではありません。

比較用の組	Work Itemと短い説明	合計
比較的小さい3件	SQN-10 メール配信基盤の検討: 3、SQN-12 モバイルのサイドバー: 3、SQN-13 Google連携追加: 5	11
大きい3件	SQN-9 導入ヒアリング: 8、SQN-30 体験参加者の権限: 8、SQN-39 プラットフォーム別分析: 8	24

件数だけなら同じ3件です。ポイントも見ると、同じ計画枠へ置く前に内容を読み直す理由ができます。24を11で割った値を、所要時間の倍率とは呼べません。ヒアリングには相手の都合があり、複数端末の確認には端末の準備が必要です。待機と能動的な作業時間も混ざります。

In Progressの6件は、すべて8ポイントでした。まず確認したいのは、新しいチケットを何件追加できるかより、この6件のうち何が実装中で、何が確認待ちなのかです。ポイントだけで停止理由は分からないので、説明と残作業へ戻ります。

親と子を合計しても、独立した仕事の総量にはならない

148ポイントは「保存されている値の合計」です。独立した残作業の総量と断言できない理由があります。

たとえばSQN-46はInstagram投稿シリーズ全体の親チケットです。本文には全体が8ポイントを超えることと、子へ分けて進める方針があります。保存値の8はシリーズ全体の精密な見積りではありません。親と今後追加する制作タスクをすべて足すと、同じ制作範囲を二度数える可能性があります。

親を一律に除けば解決するとも限りません。親にしか残っていない運用や振り返りの作業もあり得ます。集計前に、親のポイントが調整作業だけを指すのか、子を含む全体なのかを確認します。今回の実験では自動で差し引かず、その限界を合計と一緒に残しました。

新しく週の記録を始めるなら、開始時に選んだ作業、途中で追加した作業、終えた作業、持ち越した作業を分けて保存します。見積りを途中で変えた場合は変更前の値も残す、という運用案です。現在の一覧だけから過去の週を復元したことにはしません。

次に使うのは、上限より分割の相談

この集計から、週の上限を何ポイントにするかは決まりません。実際に使えた時間と完了した範囲を、同じ基準で数週間記録してから考える必要があります。

今すぐ使えるのは、大きい作業ばかりを同時に進めようとしていないかを確認することです。8のチケットを開き、残っている確認を具体化する。実装と相手待ちが混ざっていれば分けて記録する。追加する小さな作業が、進行中の大きな作業を終える助けになるかを見る。今回のデータでは、その確認先がIn Progressの6件だと分かりました。