はじめに
「タスクは終わっているのに、なぜか信頼されていない気がする」という経験、ありませんか。原因の多くは技術力ではなく、締め切りに対する感覚のズレにあります。約束した期日にきっちり出すことはもちろん大切ですが、信頼されるエンジニアはそれだけにとどまらず、「相手が安心できるタイミングで状況を見える化する」ことを習慣にしています。
この記事では、新人〜中堅エンジニアが意識したい締め切り感覚を、具体的なワークフローやコード例を交えてまとめます
この記事で分かること
- なぜ「期日に出す」だけでは信頼が積み上がらないのか、その構造的な理由
- 締め切りを逆算してタスクを設計するための具体的なフレームワーク
- 進捗を見える化するためのコード例(GitHub ActionsとSlack通知)
- 締め切り感覚が崩れる典型的なアンチパターンと、対処のチェックリスト
なぜ「期日に間に合えばOK」では不十分なのか
多くの新人エンジニアは、「依頼された期日までに完成させればOK」と考えがちです。しかし、依頼者の本音はこうではないでしょうか。
- 期日の前に「進んでいるのか」「ハマっているのか」を知りたい
- ズレが分かった時点で早めに調整したい
- 当日に「実は遅れます」と言われるのが一番つらい
つまり締め切りはゴールではなく、共有のためのアンカーとして機能しています。期日厳守はスタートライン、信頼を得るには「途中の見え方」を設計する必要があるわけです。
締め切りを逆算する3つのチェックポイント
筆者が現場でよく使うのは、着手日・1/3地点・2/3地点・前日の4タイミングで状況を棚卸しする方法です。とくに重要なのが次の3つです。
1. 着手直後の「分解と見積もり」
タスクを受けた当日中に、最低でも3〜5個のサブタスクに分解します。このとき「やること」だけでなく「確認すべき相手・依存する成果物」も書き出すのがコツです。
2. 1/3地点での「想定外の早期共有」
進捗が3割を超えるあたりで、必ず一度立ち止まります。「想定通り」「ペース遅め」「方針転換が必要」のいずれかを必ず明文化し、遅めの兆候があればこの段階で共有してしまいます。
3. 前日の「未着手リスクの洗い出し」
提出前日にやるのは仕上げではなく、着手していない作業の発見です。レビュー依頼やドキュメントの整備など、技術以外の作業が漏れがちな部分にあたります。
進捗を可視化する小さな仕組みを持つ
口頭やテキストだけで進捗を伝えると、忙しい依頼者には届きません。そこでGitHub Actionsを使い、自分のPR状態を定期的にSlackへ通知する仕組みを作っておくと便利です。
下のYAMLでは、毎営業日の朝9時に「自分がアサインされている未マージのPR」を集計し、Slack Webhookへ流す例を示しています。
name: daily-pr-status
on:
schedule:
- cron: "0 0 * * 1-5" # 平日 09:00 JST
workflow_dispatch:
jobs:
notify:
runs-on: ubuntu-latest
steps:
- name: Fetch my open PRs
env:
GH_TOKEN: ${{ secrets.GITHUB_TOKEN }}
run: |
gh pr list --search "is:open assignee:@me" \
--json number,title,url,updatedAt \
> prs.json
- name: Post to Slack
env:
WEBHOOK: ${{ secrets.SLACK_WEBHOOK }}
run: |
jq -r '.[] | "<\(.url)|#\(.number)> \(.title) (updated: \(.updatedAt))"' prs.json \
| (echo "今日の自分のPR:"; cat) \
| curl -X POST -H 'Content-type: application/json' \
--data "{\"text\":\"$(cat -)\"}" "$WEBHOOK"
ポイントは assignee:@me のクエリで自分担当のPRを絞り込んでいるところです。チームに見せるならここを team: などに変えるとチームメンバー全員のステータスダッシュボードに発展させられます。自動化で「思い出す負担」を消すことが、締め切り感覚を維持する裏技です。
タスクの所要時間を素直に記録する
感覚的な見積もりに頼ると、毎回ズレます。シンプルなログを取って、後から振り返るだけでも精度が上がります。Pythonで標準入力からタスク開始・終了を記録する小さなツール例です。
from datetime import datetime
from pathlib import Path
import json, sys
LOG = Path("task_log.jsonl")
def record(action: str, task: str) -> None:
entry = {
"ts": datetime.now().isoformat(timespec="seconds"),
"action": action, # "start" or "end"
"task": task,
}
with LOG.open("a", encoding="utf-8") as f:
f.write(json.dumps(entry, ensure_ascii=False) + "\n")
print(f"recorded: {entry}")
if __name__ == "__main__":
# usage: python tracker.py start "API設計レビュー"
action, task = sys.argv[1], sys.argv[2]
record(action, task)
注目したいのは、開始と終了を別行で記録している点です。後でJSONLを集計すれば、自分が「30分」と見積もったタスクが本当は何分かかったのかが分かります。1〜2週間続けると、見積もりの癖(楽観バイアス・特定種類のタスクで遅れがち、など)が浮かび上がってきます。
やりがちなアンチパターンと対処
| アンチパターン | 起きること | 対処 |
|---|---|---|
| 「もう少しで終わる」を繰り返す | 共有のタイミングを失う | 1/3地点で必ず一度報告する |
| 完成まで隠して仕上げる | レビューが直前に集中する | WIPでPRを早めに開ける |
| 依頼者の前提を確認しない | 期日の解釈がズレる | 着手時に「いつまでに何を渡すか」を1行で復唱 |
| 想定外を全部自分で抱える | 個人で詰まり進捗が止まる | 30分悩んだら相談、を明示ルール化 |
どれも「個人の能力」ではなくワークフローの設計で防げる課題です。仕組み化しておけば、忙しい日でも自然と信頼が積み上がります。
まとめ
- 締め切りは「ゴール」ではなく、共有のためのアンカーとして設計する
- 着手直後・1/3地点・前日の3点でタスクを棚卸しすると、遅れに早く気づける
- GitHub ActionsやJSONLログのような小さな自動化で、見える化の負担を減らす
- アンチパターンは個人の努力ではなく、ワークフローの設計で潰す
次のステップとしては、自分のタスクログを1週間分集計して、「見積もりと実績の差」を可視化してみることをおすすめします。数値で振り返るだけでも、来週の段取りの精度がぐっと上がるはずです。