AIがコードを生成し、テストを通し、レビューまで担う時代。
それでも、現場の「ズレ」はなかなか解消されません。
その正体は、設計の意図が実装に伝わらないことです。そしてその根っこには、SEとPGが持つ「思考の時間軸」の違いがあります。
どれほどAIが優秀になっても、この構造的なズレは消えません。この記事では、業界30年の現場SEとして見てきた実例をもとに、SEとPG、それぞれが時間軸を越えるために何をすべきかを語ります。
SEとPGの違いは「思考の時間軸」にある
「SE＝設計、PG＝実装」という分業は、表面上は成立しています。しかし現場での本質的な違いは、時間の見方にあります。
- SEは「未来」を考える。保守性・拡張性・運用コストを見据えて設計する。
- PGは「現在」を考える。品質・納期・確実性を重視して実装する。
ただし、これは理想論です。
実際には、SEがスケジュールとコストの圧力に追われて「未来」を見失い、PGが「設計書通りに動けばいい」という現在思考のまま実装する。その両方が重なったとき、現場に技術的負債が積み上がっていきます。
SEが「未来」を見失う二つの圧力
圧力1：スケジュールとコストの評価軸
SEの評価軸は、保守性より「納期までに要件を満たす設計書が出せるか」です。
そのため、将来の運用コストより目先の開発効率が優先されます。後の「ツケ」を見ない設計が生まれ、それが設計負債となって跳ね返ってきます。
圧力2：運用現場から隔離された設計者
自分が設計したシステムが動いている現場を知らないSEは、悪意なく負債を生みます。
「夜中に復旧する現場」を知らないことが、そのまま設計の穴になる。具体的には次のような形で現れます。
- ログ設計の不在：ログのレベル定義が曖昧で、トラブル時に何を見ればいいかわからない。ログがノイズになり、障害対応が長引く。
- 設定の外部化の怠り：調整が必要な値をコードに直書きし、小さな変更のたびにリリース作業が必要になる。
- 異常系設計の中途半端さ：バッチ処理が異常終了した際に単純リランできない。再実行のたびに手作業のオペレーションが発生する。
IT語り部悪意のある設計者はいません。運用現場を知らないまま設計書を書いてしまう構造的な問題です。SEの皆さんには、一度でいいので夜間障害の対応現場を見てほしいと思います。
PGが「現在」だけを見ることで生まれる負債
設計書が簡略化されるほど、PGには設計の意図を読み取り補完する力が求められます。しかし「設計書通りに動けばいい」という現在思考のままでは、実装の中に別の技術的負債が生まれます。
データが少ないうちは発見されにくいですが、数万件・数十万件と増えるにつれSQL発行回数が線形に増加し、処理速度が破綻します。バッチ処理であれば夜間に終わらない、画面処理であればタイムアウトが頻発するといった深刻な問題に発展します。
理論上の正しさを追求するあまり、運用効率とのトレードオフを考えない。テーブルが細分化されすぎると、ちょっとした改修でも複雑なSQLの組み直しが必要になります。
APIのレスポンス加工を最初の画面仕様に決め打ちで実装してしまった結果、別画面からの呼び出し要件が追加されたときにAPI改修が必要になった。最初から汎用的な形で設計していれば、不要だったコストです。
IT語り部「今動けばいい」という判断が、数年後に数倍のコストになって返ってくる。これはPGを責めているのではなく、未来を意識する習慣がなかっただけです。その習慣は、今日から変えられます。
AIレビューでも拾えない「意図の空白」
AIはコードの品質を評価できます。しかし「なぜその設計なのか」は理解できません。
AIは「今ある構造に似たコード」を生成するのは得意です。しかし「将来の拡張性を考慮して、あえて分離しておくべきか」という未来への判断はできません。設計意図を考えること、運用まで含めた最適解を出すことは、いまも人間の領域です。
そしてAIレビューが機能しない場面の多くは、AIの能力の問題ではありません。要件定義や基本設計のコンテキストがそもそも共有されていないこと、そして共有されていても仕様の言語化が不十分なことが原因です。
たとえば「セキュリティ対策を施す」程度の記述しかなければ、AIが想定する対策と現場が求める対策の間にズレが生まれます。「意図の空白」は、AIとの間にも同じ構造で発生するのです。
SEとPGの両方が時間軸を越えなければ、AIをいくら使っても現場のズレは解消されません。
SEが今日からできること
運用現場の声を設計に持ち込む
現実には開発チームと運用チームは別部隊であることが多く、場合によっては別会社になることもあります。
だからこそ意識的に接点を作ることが重要です。設計に反映すべきリアルな声は、日々の運用で困っていることの中にあります。
「誰が、いつ、何のために使うか」を設計書に書く
仕様の羅列ではなく、設計の意図を一行添える。
たとえばログ仕様に「夜間障害時に運用チームが原因特定するために使用」と書くだけで、PG側の実装判断が変わります。
運用コストを設計レビューの評価軸に入れる
「この設計で、1年後の改修コストはどうなるか」をレビュー時に問う文化を作ることが、設計負債の発生を構造的に防ぎます。
PGが今日からできること
設計書を仕様の羅列として読むのではなく、設計者の意思が込められた構造図として読む訓練をします。過去のバグ票や修正履歴を設計書と照らし合わせ、「なぜここを直したのか」を逆算する習慣が、設計の意図を読む力を育てます。
不明点を「これはどうすればいいですか？」と質問するだけでは実装者のままです。「こう実装しようと思いますが、意図と合っていますか？」という提案型に切り替えましょう。たとえばログ設計が曖昧なとき、「エラー内容・対象データID・発生時刻を含める形で出力しようと思いますが、いかがでしょうか？」この一言が設計の意図を引き出し、認識ズレを防ぎます。
実装時に「この構造は1年後も変えずに済むか」を問いかける習慣を持ちましょう。特に画面（Presentation）と業務ロジック（Business）の分離を意識したコードは、UI変更やIF追加が発生しても局所的な修正で済みます。結合度を下げる意識が、そのまま将来の運用保守コストを下げることに直結します。
実装前に確認する「未来コスト」チェックリスト
詳細設計書がない場合に、実装開始前に確認すべき最小限の問いです。
- データ増量の予測：「このテーブルのデータは1年後にどれくらい増えますか？」
- 更新頻度の確認：「このマスタデータはどれくらいの頻度で更新されますか？」
- トランザクションの粒度：「この一連の処理の中で、どこまでを必ず一貫させる必要がありますか？」
まとめ――時間軸を越えられる人が、AI時代の現場を支える
AIはコードを書く。テストも通す。しかし、設計の意図を読み、未来コストを想像する力は、人間にしかありません。
SEは未来を見て設計し、PGは今を正確に実装する。その理想は変わりません。しかし現実には、SEが未来を見失い、PGが現在だけを見ている。その両方が時間軸を越えたとき、はじめてズレは解消されます。
「設計書通りにやりました」「納期に間に合えばいい」から一歩踏み出すこと。
それが、技術的負債を生まない現場エンジニアへの、最初の一歩です。
IT語り部SEとPGどちらが悪いという話ではありません。時間軸の違いを互いに理解した上で歩み寄れるチームが、AI時代の現場で本当に強いチームです。
