大学生のころ、僕は「アーキテクチャ設計」という言葉に、とんでもない神々しさを感じていました。 「ゴリゴリのエンジニアが、最初に完璧な構成を描き、プロジェクトはその図の通りに進む」――そんなイメージです。

でも、SIerに入社して数年働いてみると、現実はかなり違います。

結論から言うと、SIer現場でアーキテクチャを“完璧に”考えてくれるスーパーマンはいない。 むしろ普通の社員たちが、都度調査しながら、手探りで最適解を寄せ集めていきます。 これは良い悪いの話ではなく、構造としてそうなっているのです。

この記事では、

  • SIerでは誰がアーキテクチャを考えているのか
  • アーキテクトが希少人材と言われる理由
  • 正社員とフリーランスで求められるスタンスの違い
  • AI時代に求められるアーキテクチャ観

を、現場経験ベースで解説します。

SIerではアーキテクチャ設計を誰が担当するのか？

最初に結論です。 SIerのアーキテクチャは「特定の誰かが全部決める」ものではなく、複数の職種が少しずつ寄せて作っている場合が多いです。

実際の担当例は以下のように分かれます。

  • アーキテクト（専任がいる場合）：全体構成や非機能要件
  • SE：業務要件と実装の橋渡し
  • ベンダー（外部開発会社）：技術的な実装案の提示
  • PLやPM：最終判断

つまり、「一人の天才による完璧な設計」ではなく、 平凡な人たちの組織的な共同作業で成り立っているわけです。

強いて言えば、ベンダーの中の技術色が強い人がアーキテクチャとして、 その人主導で作っていくことが多いと思います。

SIerの中で、専任のアーキテクトがいるPJの方が希少と思われます。

そして、PLやPMが最終判断を下すものの、 そもそもその人たちはシステムのスペシャリストではないため、 その判断が優れている保証はどこにもありません。

現場のリアル：アーキテクチャは“調べながら作る”のが普通

実際のSIerでは、アーキテクトと呼ばれる人でも、 常にすべての技術を理解しているわけではありません。

その場で都度ググったり、チームで議論しながら決める、ベンダーに問い合わせて判断する、過去のPJの構成を参考にする、 ということが多いです。

こういった小さな判断の積み重ねで最終的な構成が出来上がります。

しかし、これは悪いことではありません。 なぜなら、SIerは「正社員を育成する前提」で成り立つ組織だからです。 言い換えると、SIerは“教育機関”として機能している。

そしてだからこそ、若手SEでも大規模開発のアーキテクトのような非常に重要な工程に携わることができるのです。 Web系企業だとこうはいかないでしょう。

SIerがアーキテクトの重要性を理解してないがために、こういったことが新人が担当できてしまうのかもしれませんが、、、

正社員とフリーランスで異なる「アーキテクチャに対する責任」

正社員では、調査しながら成長していくことが許され、チーム全体で知識を補完し合えます。 そして、時間と人を分散することにより、責任も分散します。

しかし、フリーランスでは、「調べながら成長」は許されないでしょう。 即決・即断・即アウトプットが求められ、失敗はそのまま信用問題になります。

この差が、 “雇用形態によってアーキテクチャに対するプレッシャーが全く違う” という現場の本音につながっていると思います。

今振り返れば、大学時代に私が想像していたのは、「フリーランスのアーキテクチャ」だったんだと思います。

個人開発では「作り直せばいいや」が通用する

僕自身、このブログや個人アプリを作るときに一番悩むのはアーキテクチャです。 「保守しやすいのはどの構成だろう…」と悩みながら、経験値の少なさもあって、その場で一番マシそうな選択をしているのが実情。

当然、あとになって「やっぱこれ使いにくいな…」と気づいて、大幅に作り直したこともあります。 個人開発ならまあなんとかなるんですが、会社のPJだったらそうはいかない。

リリース済みのシステムで「やっぱ構成変えます！」なんて言い出した日には、 影響範囲の確認と調整だけで地獄が待っています。

SIerでアーキテクトが希少人材になる理由

SIerで「アーキテクト的な存在」が少ない理由は大きく3つあります。

1. 責任が重い割に評価されにくい

最近は変わってきているとは聞くものの、やはりSIerは、管理できる人が評価されます。 もっと言えば、上手く管理はできなくとも、管理経験がある人が評価されるとでも言うのでしょうか、、、

それに対して、アーキテクチャは非常に専門性が強いため、管理とは真逆にある仕事とも言えます。 責任も重い割には評価されにくいのです。

それに、技術者にリスペクトのある人たちの中で作るアーキテクトにはやりがいもあることでしょうが、 SIerの上の方の人たちで、技術自体に興味がある人は少数派です。

課長クラスであればめっちゃスペシャリストもいますが、部長以上ともなれば少し外れるのが実態な気がします。

そういう環境の中で、熱心にアーキテクチャを考えても、非常に冷めたふうに対応されます。 そんな中で、アーキテクチャが育つでしょうか？

いえ、そう言う人は技術が強い会社に転職していきます。

2. 本来の役割より“管理業務”が多すぎる

議事録、調整、ベンダー管理、会議に追われ、 アーキテクト業務に割ける時間が圧倒的に足りない。

仮にアーキテクトとして自分で動いて、管理業務が疎かになると 上司は間違いなく、「そういったことはベンダーにやらせろ」と言うはずです。

新人時代は、「自分でやってみたい！」「（自信過剰ですが、、）俺でもできるのでは？」 と思っていましたが、私もこの文化に染まってきまいた。

それに、アーキテクトを自分で立案してしまうと、何かあった時に、真っ先に自分に矢先が向けられてします。 しかも、そこにリスペクトは一歳ないのです。

減点方式とでも言うのでしょうか？

仕組みを考えた人は、何もしてない人より圧倒的に偉いはずなのに、 それで何かあったときは槍玉に挙げられる。

3. 人材が抜けやすい構造（属人化リスク）

プロジェクト途中で人が抜けることが普通で、 「全体を把握している人が常にいる」とは限らない。

つまり、 “アーキテクチャを考えるべき人が、アーキテクチャを考えられる環境にいない” という構造的な問題があるわけです。

AI時代：アーキテクチャ設計はAIが担うのか？

近年、AIはコード生成・リファクタリング・テスト自動化を高速化しています。 この流れの先には、「AIによるアーキテクチャ設計」が確実に存在します。

「非機能要件の自動分析」、「DB構成の自動提案」、「マイクロサービス化の可否判断」、「過去の障害履歴から最適構成を提示」 などなど、こういったことは、AIなら圧倒的に上手いかもしれない。

ではその時、人間の価値はどこに残るのか？

  • 組織の政治的判断
  • 予算・納期・人員を踏まえた現実的判断
  • 顧客と合意形成する能力
  • セキュリティと運用のリアルを踏まえた判断

結局、「現場の制約の中で最適解を出す能力」は人間が担う必要があります。

まとめ：完璧な設計より“柔軟に直せる構成”を

アーキテクチャ設計は、神々の専売特許ではありません。 現場のエンジニアが手探りで積み上げた判断の集合体です。

だからこそ、SIerのアーキテクチャは不完全であることを前提に考えるべきであり、 完璧さよりも、柔軟に変更できる構成が求められます。

そしてAI時代になっても、 「制約の中で最適を選ぶ力」 は間違いなく人間の価値として残るはず。

不安と希望のあいだで揺れながら、 僕らも学び続けるしかない――そんなテーマの記事でした。