はじめに
私はエンジニアをしていて、こう感じる瞬間が頻繁にありました。
- 最近、成長してる気がしない
- 自分のスキルが伸びている感覚がない
- 何をすれば伸びるのか分からない
何度もこの状態に陥っています。
そして私がたどり着いた結論は、めちゃくちゃシンプルです。
PDCA を回そう。
しかし実際に何度かやってみると…
- 目標をどう設定するか
- 計測のめんどくささ
- がんばらないと続かない
…等々でつまづいて続けられませんでした。
最近、これらを打破してようやくPDCAが回るようになり、今は習慣の一部となっています。
この記事では、サイクルを止めないための具体的な手順やアドバイスを書きます。
ちなみに、こちらの本を大いに参考にしています。
そもそも「PDCA をちゃんと回してみよう」と思い直せたのもこのマンガがきっかけでした。
一読をおススメします。
まんがでわかる鬼速PDCA
用語：PDCA とは
Plan / Do / Check / Act の略。目標を立て、行動し、結果を確認し、次の改善につなげるサイクル。
なお、本記事が参考にした 鬼速PDCA では Act の代わりに Adjust（調整） を採用しています。本記事でも考え方は Adjust 寄りです。
PDCA が止まる原因（著者のパターン）
私の感覚では 何のためにやっているか分からなくなる からです。
一歩踏み込むと どこを目指しているか分からなくなる から。
さらに、何かを目指しているとしても 自分の現在地と目指す場所のギャップが見えていない & どれくらいギャップが埋まったか分からない からです。
この状態が続くと 前進している気持ちよさがなく、めんどくささが積もる ため、止めていました。
また、ギャップが見えても 何をすればいいか分からない と足踏みしてしまう。
やるべき行動を見つけても 計測を忘れてしまう。
私の場合、これらがサイクルを止めてしまった原因です。
以下、これをなんとか抜け出した5ステップです。
Step 1. 「どうなりたいか」という目標を決める（KGI）
用語：KGI とは
Key Goal Indicator の略。
最終的に達成したい目標を示す指標。
例
- 半年でビジネスサイドの人の意見を、プロダクトに即反映できる人になる
- 3か月で AtCoder 緑になる
- 1年で〇〇さんのようなエンジニアになる
とりあえずはこれくらいざっくりで構いません。
ただし 期限は必ず入れましょう。
本当は 客観的指標で true/false で判断できる内容 が良いです。
（例では「AtCoder 緑になる」しかありません。）
参考までに、マンガでは「Nか月後の試合でライバルチームにX点差で勝つ」というような内容でした。
定量化できるとStep 2以降が楽なので、強くおススメします。
ただ、私の場合は「1年で〇〇さんのようなエンジニアになる」で開始してしまいました。
（代わりに、以降のStep 2～4 で目標に落とし込む際は、必ず客観的指標にしています。）
この始まりでも「成長してる気がしない」という感覚は消せました。
ポイント：仮置きでOK！とにかくスタートを切る
ここで何時間も何日も考えてはいけません。
「どうなりたいか」という問いは正解/不正解が存在しない問題です。
それに、あとでアップデートできます。
完璧主義は捨てて進みましょう。
「本当の理想」は走り出すまで見えてこないです。
KGI は改善と成長の過程を経て育てていくイメージの方が、私はしっくり来ています。
（本当にそれで良いのかは分からないですが…。ただ、止まっているよりはマシだと信じています。）
Step 2. 現状とゴールのギャップを把握する
ギャップ＝乗り越えるべき課題を、分解して書き出します。
まだ目標にする必要はありません。まずは課題を具体的に書きだします。
例：「1年で〇〇さんのようなエンジニアになる」を分解すると…
自分と〇〇さんとのギャップ
- モックを作るのが早い
- issue消化を1日平均12件する（自分は平均3件）
- PR作成数が1日平均6件ある（自分は平均1.5件）
- 世の中の情報キャッチアップができる
- インフラ・バックエンド・フロントエンドの知識が豊富
- レビューでテスト観点を指摘できる
特に大事なことは 観察 だと思っています。
「要素を全部満たしたのに、目指している姿じゃなかった」なんてことにならないように、的確に漏らさず書きだしましょう。
ただし、ここも最初から100点満点を目指さないようにしましょう。
あとから付け足したり修正したりします。
Step 3. 絞り込む
「全部やる」は何も達成できません。
Step 2の中から2,3個に課題を絞ります。
効果・時間・気軽さで選びます。
マンガに絞り込み方法のアドバイスがあるので参考にしてください。
私の場合、最初はこの2件にしました。
- PR作成数が1日平均6件ある（自分は平均1.5件）
- インフラ・バックエンド・フロントエンドの知識が豊富
ポイント：初回はイージーなものを選んでリズムに乗る
いきなり難しい課題に挑むと「PDCAを回す」ことと「課題をクリアすること」の両方に気を使うことになります。
PDCAを回すこと自体が、最初は負荷になります、
なので、クリアが簡単そうな課題を1つは入れたほうがいいです。
これで成功体験を積みやすいですし、PDCAを回すこと自体にも慣れます。
Step 4. 課題を定量化する（KPI）
Step 3で絞り込んだ課題を計測可能な客観的指標である KPI にします。
用語：KPI とは
Key Performance Indicator の略。
KGI を達成するために日々計測する中間指標。
- PR作成数が1日平均6件ある（自分は平均1.5件）
→ 1日必ず2件PRを出す 別例：AM11時までに最初のPRを出す - インフラ・バックエンド・フロントエンドの知識が豊富
インプットをほとんどしていない。インプットしても素早く頭から引き出せない。
→ 毎日17時に暗記カードを作る & 通勤時間で暗記カードを1周する
ポイント：絶対に定量化する
Step 1 の KGI では「本当は 客観的指標で true/false で判断できる内容 が良いです」と書きましたが、Step 4 の KPI では絶対です。
定量化したときのメリット
- 計測時、思考がいらない
「計測がめんどくさいから先延ばし」が減る。地味にかなり効きました。 - 成長が見やすい
100日、PR数を計測したとします。最初は0~3だったのに、右肩上がりに2~5、4~6 と増えて行くのを見るとテンションが上がります。
bool値だとしても、達成率を眺めるのは楽しいです。（GitHubの草と同じ感覚のはず。）
Step 5. 毎日、計測結果を記録する
ここで現代のエンジニアの利点を全力で使いましょう。
ポイント：AI 等に計測を任せる
会社がAI利用を許可しているなら、強力な武器が使えます。
MCPです。
用語：MCP とは
Model Context Protocol の略です。
AI ツールから GitHub や Notion などの外部サービスに接続し、情報取得や操作をしやすくする仕組みです。
- GitHub MCP → PR数・Issue数・コミット数を自動集計
- Backlog / Jira / Notion MCP → チケット数等を自動集計
- 自作スクリプトを cron で走らせる → 何でも計測可能
Claude / ChatGPT に 「前日のPR数を集計して」 と頼むだけ。
「手動集計がめんどくさくて止まる」というのはなくなりました。
ここが最重要ポイントです！仕組化をがんばりましょう！
日々の記録をとにかく楽にしましょう。
アドバイス：人目につく場所に投稿する
これは拘束力が生まれて良いです。
成長したいと思うような人なら、きっとできるでしょう。
- 相談した上司がいる Slack チャンネル
- チームの分報チャンネル
- 仲間内の Discord
一人だと人間はどうしても甘くなります。
「今日できなかった」「明日はどうしてみる」をシェアする相手がいるだけで、ほんの少しがんばれます。
あとは繰り返そう
ここまでやれば、あとは繰り返すだけです。
日々、計測している値が少しずつ伸びていく感覚。
これが成長している感覚として実感できるはずです。
まとめ
成長してる気がしないのは、止まっているからではない。
進んでる方向と速度が見えていないだけ、というのが私の結論です。
計測可能な指標を1つだけ、決めて始めてみてください。
最後に まんがでわかる鬼速PDCA が圧倒的に分かりやすいのでぜひお読みください。
私はこの本でPDCAの回し方を学び直しました。
まんがでわかる鬼速PDCA
※アフィリエイトではありません
Discussion