私は「修正がほとんど発生しない状態」を成功と定義した
この基準に変えてから、案件の終わりが明確になり
成長のために必要な インプットとアウトプットの量 を増やせるようになった
なぜこの記事を書いたか
多くの現場で次のような問題が起きている
- 仕様が決まらない
- 決めたはずの仕様が変わる
- 一人の意見で方向が揺れる
- レビュー担当が毎回違う
- ゴールが存在しない
これらの共通点は
成功の定義が存在していない
ということ
成功が決まっていないと案件は終わらない
終わらない案件では経験値が増えない
そしてエンジニアは成長しない
終わらない案件にはパターンがある
私が経験した終わらない案件には共通点があった
- 納品後の「少しだけ修正」が終わらない
- 関係者ごとに指示が違う
- 初回レビューで方向転換が起きる
- 完成した機能が翌日には不要になる
これらを繰り返すうちに気づいた
案件が終了したら成功という考え → 終わりが生まれない
つよつよエンジニアを目標にした瞬間、無駄に振り回されることが減った
成果物の良し悪しではなく、プロセスが正しく進んだ証拠を成功とする
修正がほとんどない状態は、次のような条件が揃っているサインになる
- 要件が事前に固まっている
- 期待値が一致している
- 想定ケースを潰している
- 関係者の意思統一ができている
- 品質基準が共有されている
つまり
低修正率 ＝ プロセスが成功した定量指標
つよつよエンジニアを目指すと案件の見方が変わる
エンジニアとしての成長は、インプットとアウトプットの量で決まる
- 仕様が決まらない
- レビューが進まない
- 関係者の意見が揺れる
こういった停滞に時間を使っても
経験値は貯まらない
私はつよつよエンジニアを目標にしたことで
停滞する案件に余力を使わない
→ 成長につながるタスクに集中できる
という状態に切り替わった
実際に使っているチェック項目
（Excelで十分）
| タスク | 担当 | 期限 | 状態 | コメント |
|---|---|---|---|---|
| 入力項目の確定 | 依頼者 △△ | 12/12 | 完了 | 決まらないと実装不可 |
| API仕様更新 | バックエンド□□ | 12/13 | 進行中 | 変更点の確認中 |
| フロント画面実装 | あなた | 12/15 | 進行中 | ラフ確定待ち |
| レビュー | 全員 | 12/16 | 未着手 | 午後まとめて実施 |
最後に
つよつよエンジニアは
曖昧な現場に合わせて消耗する側ではなく
自分の基準で動ける側 だと私は考えている
だから成功の定義は
誰かに委ねるのではなく
自分の成長速度のために、自分で決める