こんにちは。ノバセルの新開です。
この記事はノバセル テクノ場 出張版2025 Advent Calendar 2025の19日目の記事です。
はじめに
生成AIの普及により、ソフトウェア開発における実装スピードは大きく向上しました。 一方で、「実装は速くなったものの、価値提供のスピードはあまり変わっていない」と感じているエンジニアも少なくないのではないでしょうか。
特に3〜5年程度の経験を積むと、基本的な改修や機能追加は安定してこなせるようになります。 しかしその反面、重要な設計判断や方針決定は先輩エンジニアが担い、自分は"決まったことを正しく作る役割"に留まっている、という感覚を持つ場面も増えてくるように思われます。
本記事では、こうした状態を「守破離」という観点で構造から整理しつつ、 生成AI時代において3〜5年目エンジニアがどこに注力し、何を手放すべきかについて考察していきます。
静かに起きる停滞
3〜5年目になると、仕事は安定してきます。 レビューで大きな指摘をされることも減り、タスク遂行に困ることも少なくなります。
一方で、自分がプロジェクトを前に進めているという実感が薄れていくことがあります。 気づけば判断は常に先輩が行っており、自分が不在だとしても物事は変わらず一定に進んでいる、という感覚です。
大きな失敗をしているわけではありません。 そのため、この違和感は見過ごされやすいものです。
しかし実装スピードが平均化されつつある生成AI時代において、 判断に関与できない状態が続くと、相対的な成長が鈍化していく可能性が高いと考えています。
守破離で見る、3〜5年目エンジニアの立ち位置
この状況を整理するために有効だと感じたのが、守破離という考え方です。 ここでは年次でなく、判断への関与度合いという観点で捉えます。
守：決められたことを正しく進める段階
設計や方針が明確な状態で、実装を正確に進めるフェーズです。 この段階は非常に重要であり、誰もが通る必要があります。
破：判断を一部引き取る段階
要件がまだ抽象的で、解決策が一つではない状況です。 ここでは完璧な設計よりも、 "今回はここまでやる"、"これは後回しにする"といった仮の判断を置くことが求められます。
離：価値提供を設計できる段階
何を作らないかを判断し、進め方そのものを設計できる状態です。 これは「破」の経験を積んだ結果として到達する段階だと考えています。
なぜ判断に踏み出しにくいのか
判断を引き取れない背景には、個人の能力とは別の構造的な要因があると思われます。
3〜5年目になると、業務理解がある前提で見られることが増えます。 そのため、仮の判断を出してズレていた場合の心理的な負担が大きくなります。
また、指示通り進めていれば責任は発生しにくく、 判断を避ける選択は短期的には合理的に見えます。
さらに、 過去に「十分に理解してから動く」ことで評価されてきた成功体験や、 生成AIを活用することで充分な考えなくある程度形になるものを作れてしまう環境も、 判断を後回しにしやすい要因となってしまっているのではないでしょうか。
判断を引き取れないときに起きがちなパターン
業務改善や機能追加の場面において、 「一部から出せば価値が出そうだ」という方向性が共有されていることが多くあります。
一方で、将来的な拡張や他チーム要望も見えており、 どこまでを最初に扱うかが切られていない状態も少なくありません。
このような状況で、 "後回しにする範囲"を明示しないまま設計をまとめてから確認しようとすると、
- レビューのタイミングが遅れる
- 「ここは最初にいらなかった」という指摘が後から出る
- 一部を考え直すことになる
といった流れが起きやすくなります。
致命的な失敗ではないものの、 仮の判断を早く置いていれば防げたケースだと感じることも多いのではないでしょうか。
どうやって"後回しを決めて、先に見せる"のか
重要なのは正解を提示することではなく、 確認を前に進めるための仮の判断を置くことだと思われます。
実践としては、次の3点が有効です。
- 今回は扱わない範囲を先に決める
- 完成形ではなく、判断が返ってくる最小ラインを意識する
- 生成AIを活用して叩き台を作り、選択肢付きで見せる
"今回はこの案で進めたいと考えています"と差し出すことで、 判断に関与する経験を積みやすくなります。
「今回は扱わない範囲」を決める際の判断軸として有効なのが、 Amazonで知られている Type 1 / Type 2 の意思決定フレームワークです。
Type 1（後戻りできない決定）
後から覆すコストが非常に高い判断 （例：データモデルの根本設計、強い外部依存）
Type 2（後戻りできる決定）
間違っても修正や撤回が可能な判断 （例：UI仕様、一部機能の有無、暫定的な構成）
「今回は扱わない範囲」に含めてよいのは、基本的に Type 2 の判断です。 Type 1 は最小限に、Type 2 は仮で置いて先に進める、という線引きを意識します。
実務では、
"これは後からの変更が容易（可逆性が高い）なので、方向性に問題がないかだけを先に確認したいです"
と説明できると、合意形成が進めやすくなります。
価値提供のスピードは、どこで決まるのか
ここまで、判断を引き取ることの重要性について述べてきましたが、 「それがどのように価値提供のスピード向上につながるのか」が 分かりづらかったかもしれません。
価値提供のスピードは、 実装速度そのものではなく、次の3つの時間の合計で決まると考えられます。
- 何を作るかが決まるまでの時間
- 作ったものが確認されるまでの時間
- フィードバックを受けて次に進むまでの時間
生成AIによって②の実装時間は大きく短縮されました。 一方で①と③、つまり判断と確認のサイクルが遅いままだと、 価値提供全体のスピードは変わりにくいでしょう。
「後回しを決めて、先に見せる」という行動は、 この①と③を意図的に短縮するためのものです。
- 何を作らないかを先に決めることで判断を早める
- 最小ラインで見せることにより確認を前倒しする
その結果、 価値の発生する確認ポイント自体が前にずれ、 価値提供が早まっていくと考えられます。
なぜ生成AI時代に、この動きが有効なのか
生成AIの登場により、実装や修正のコストは大きく下がりました。 不確実性も、考え続けるより形にして確認した方が早く減るようになっています。
つまり、 "今回はやらない"という判断が致命的になりにくい時代になったと言えます。
生成AIが得意なのは作業の高速化です。 何を扱わないか、どこで確認するかを決めることは、人間に残された役割だと考えられます。
生成AI時代の設計力とは、 未来の変化に耐えることではなく、 変化を前提とした推進力だと思われます。
判断が増えて逆に遅くならないのか
一つ想定される反論として、 次のような見方があると思われます。
昔は作ったものを捨てるコストが高かったが、 AIが作ったコードなら気軽に捨てられる。 その分スコープを小さくすると、 人間が判断する回数が増え、逆に遅くなるのではないか。
この指摘は一部正しいと思われます。 実際、AI時代では判断の回数自体は増えます。
ただし重要なのは、 判断1回あたりの重さが大きく変わっているという点です。
従来は、
- 一度決めた設計を覆すコストが高く
- そのため一回の判断に多くの時間をかける必要がありました
しかし生成AI時代では、
- 仮の判断で進めるコストが低く
- 判断を修正する前提で進めることが可能です
その結果、 判断を細かく分割し、軽く回す方が全体として速くなる という構造に変わっています。
スコープを小さくすることは、 判断を増やすためではありません。
1回あたりの判断を軽くし、 早い段階で間違いに気づくための手段となります。
この動きができるようになると
判断への関与ができるようになると、 実装依頼だけでなく方針相談が増え、 プロジェクトの初動から関われる場面が増えていきます。
また、誰も決められずに止まっている状況で、 前に進める役割を担えるようになります。
3〜5年目エンジニアにとっての壁は、 技術力そのものではなく、どこまで判断に関与できているかにあるのではないでしょうか。
次のタスクで、まず一つ。
"今回は扱わないこと"を決めて、先に提示してみてください。
その小さな判断が、 "正しく作れるエンジニア"から "価値を前に進められるエンジニア"への一歩になると信じています。
