IT業界で数年経験を積んで、「そろそろ上流に行きたい」「設計レビューで毎回”戻し”が入る理由が分からない」と感じているPG・若手SEの方へ。
AIがコードを書き、設計書も自動生成する時代になっても、設計が破綻するプロジェクトは減りません。理由は明確です。「技術的整合性」と「運用を見据えた設計」という2つの視点が欠けているからです。
この記事では、現場の破綻例をもとに、AI時代のSEが越えるべき「上級SEの壁」を2つに整理して解説します。
【壁1】技術的整合性という壁
なぜ設計はバラバラに壊れるのか
大規模なプロジェクトでは、アプリチーム・インフラチーム・DBチームなど、複数のチームがそれぞれの担当領域を個別に設計します。各チームの設計はそれぞれ正しくても、チームとチームの「継ぎ目」の部分で矛盾が起きることがあります。
具体的な破綻事例を3つ紹介します。
タイムアウト値の設計は、オンライン処理を前提に決められることが多く、同じAPIやロジックをバッチ処理からも呼び出すケースが見落とされがちです。バッチはオンラインより長時間の処理を伴うことが多いため、オンライン向けのタイムアウト値では処理が間に合わずエラーが多発します。
IT語り部このパターンは実際の現場でもよく見かけます。多くの場合、本番稼働後ではなく結合テストの段階で発覚しますが、それでも手戻りのコストは決して小さくありません。
少人数のプロジェクトであれば暗黙の了解で揃うこともありますが、大人数になると必ずログの出力基準にズレが生じます。
IT語り部例えば、あるサブシステムでは「個人情報を画面に表示した」という事実だけをログに残す一方、別のサブシステムでは「表示した上で、どの項目を参照したか」まで記録している、というケースがあります。監査や障害調査の場面でこの粒度の違いが致命的な問題になります。
データベース設計は基本的に正規化を目指しますが、すべてのデータに正規化を適用すればよいわけではありません。
IT語り部例えば注文履歴のデータまで商品マスタと正規化してしまうと、後で商品の価格が変更された際に、過去の注文履歴の金額まで書き換わってしまいます。「今の状態」を表すデータと「その時点の記録」を残すべきデータを見極めることが、正規化における重要な設計判断です。
この壁を越える人＝境界線を管理する人
こうした破綻を防ぐために必要なのが、システム全体の技術的整合性を守る役割です。この役割を担う人材は、ITアーキテクト（ITA）と呼ばれます。
ITAの本質は、単なる技術スペシャリストではなく、チームとチームの「境界線」を管理することにあります。
IT語り部アーキテクトとして複数のプロジェクトに関わる中で意識してきたのは、アプリチームとインフラチームのように、担当が分かれるチーム同士の境界線です。どちらのチームの担当にも明確に属さない処理は、放置すると誰も設計しないまま現場に持ち越されます。そうした処理は「共通処理」として明確に切り出し、責任の所在を最初にはっきりさせておくことが、後々の手戻りを防ぎます。
この技術的整合性の甘さは、設計段階だけの問題では終わりません。運用フェーズに入ってから、より深刻な形で表面化することがあります。
IT語り部あるプロジェクトで、運用設計書に「監視方式は別紙で検討」という記載がありました。しかし監視方式を後回しにすると、ログ出力形式などの実装に手戻りが発生します。さらに「ネットワークの疎通品質を監視してほしい」と要求したところ、「それはリソース監視（トラフィック量）に含まれる」という回答がありました。しかしトラフィック量だけでは、サーバーは正常に稼働していてもユーザーが実際には使えないという「サイレント障害」を見逃します。設計段階での「監視とは何を指すか」という定義の曖昧さが、そのまま運用フェーズでの検知漏れに直結する典型例です。
【壁2】「作って終わり」ではないという壁
運用・DevOps・SREの違いを理解する
運用を考慮した設計をするには、まず「運用」「DevOps」「SRE」という3つの言葉の違いを整理しておく必要があります。レストランの厨房に例えると分かりやすくなります。
- 運用：決まったレシピ通りに、毎日同じ味を作り続ける調理スタッフ
- DevOps：料理人とホールスタッフが情報を共有し、注文から提供までのスピードと質を高める厨房の仕組み
- SRE：仕込みや温度管理を自動化する調理器具を導入し、そこから得られるデータをもとにレシピや調理工程そのものを継続的に改善していく体制。人はメニュー開発と品質管理・改善提案に集中する
運用を考慮する設計のポイント
上級SEが設計時に押さえておくべきポイントは以下の通りです。
- 環境設定の外部化：環境ごとの差異をコードに埋め込まず、設定として切り離す
- ログの構造化：後から機械的に分析できる形式でログを出力する
- デプロイの自動化：手作業によるリリースミスを排除する
- 監視項目の計画：何を異常とみなすか、検知ポイントをあらかじめ明確にする
設計の責任は、システムが廃棄されるまで続きます。
AI時代におけるこの2つの壁の重要性
ここまで見てきた2つの壁（技術的整合性・運用を考慮した設計）は、AIが設計やコードを生成する時代においてさらに重要性を増します。
AIはクラス図、DBスキーマ、API定義など、教科書的に正しい設計書を高速に生成できます。しかしAIの限界は「インプットの曖昧さ」にあります。入力が曖昧であれば、AIが出す設計も曖昧になります。これはAIに限らず、システム開発全般に共通する原則です。
AIは理想的な正規化やAPI設計を提案できますが、現場では、既存システムが複雑すぎて理想論が適用できなかったり、バッチの制約で非正規化せざるを得なかったりします。こうした「理想を破る判断」は、経験豊富なSEにしか行えません。
SEには、「どこまで自動化するのか」「この操作は誰がいつ行うのか」「例外はどう処理するのか」といった曖昧な要求がそのままPGに渡らないよう、事前に潰しておく役割があります。AIの活用が進むにつれて、上流工程の精度がそのままアウトプットの品質を左右する場面は増えていくはずです。
まとめ：2つの壁の先にあるキャリア
AIがコードを書き、設計を補助する時代に価値を持つのは、技術的整合性と運用まで見据えた設計ができるSEです。
この2つの壁を越えた先にあるキャリアパスが、ITアーキテクトです。曖昧さをつぶし、チームとチームの境界をつなぐSEこそが、ITAへの最短ルートといえます。
