アーキテクト
高度な技術知識を基盤に、システム全体の構造を設計し、長期的に持続可能なアーキテクチャを確立するエンジニア。単にコードを書くのではなく「どう設計すれば3年後のチームが楽になるか」を常に考え、技術的意思決定をADR（Architecture Decision Record）として残しながら組織の技術的基盤を守り続ける存在。
コアとなる強みと輝くシチュエーション
スーパーパワー
コードを俯瞰した瞬間に「この設計の限界点が3年後どこで露出するか」が直感的に見えること。複雑な要件を「どう構造化するか」の最短経路を描き、チーム全体が迷わず実装できる設計図に落とせる。
最も輝く瞬間
「このまま機能を足し続けると破綻する」という技術的岐路に立ったとき。システムリプレイス・マイクロサービス分割・DBスキーマ再設計など、一手間違えると取り返しのつかない意思決定の場面で圧倒的な真価を発揮する。
チームへの「見えない貢献」
「設計ADRの整備」によって、組織の技術的意思決定が資産として蓄積されていること。なぜこのアーキテクチャにしたのかの根拠が残ることで、メンバーが変わっても一貫した技術方針が維持され、新メンバーの学習コストを劇的に下げている。
周囲からの見られ方（360度視点）
EM・上司から
「この人の設計レビューが通っていれば、大きなアーキテクチャ崩壊は起きない」という絶対的な信頼がある。技術リスクの早期察知と構造的な解決策の提案が、プロジェクト全体の安定性に直結していると感じる。
同僚エンジニアから
「なぜこの設計にしたのかが、後から読んでも分かる」という尊敬がある。ADRや設計ドキュメントが丁寧で、意思決定の透明性がチーム全体の技術的理解を底上げし続けている。
陥りやすいアンチパターンと対策
技術的落とし穴
長期最適を追求するあまり、現状フェーズには過剰な設計を提案し、チームのスプリント速度を意図せず下げてしまうことがある。「完璧なアーキテクチャ」への拘りが、今の段階で必要な「動くもの」の納品を遅らせるオーバーエンジニアリングに陥るリスク。
意識すべきポイント
設計提案は「今このタイミングで解決すべき課題」とのセットで説明する習慣を持つ。技術的正しさではなく「このアーキテクチャ変更で次の6ヶ月が変わる」という事業的文脈を先に語ること。
活躍できる環境・キャリアのNext Step
フィットする開発組織
プロダクトが成長フェーズに入り、技術的負債と設計の一貫性が課題になってきたシリーズB〜C以降の企業。「0→1」より「10→100」を技術的に支える環境で圧倒的な価値を発揮する。
次期目標・キャリアNext Step
Principal EngineerまたはCTO（技術組織全体のビジョンを担う）。マネジメントよりも「技術で組織の未来を設計する」IC最高峰キャリアが自然体。技術顧問・スタートアップのCTO兼任という道も開ける。
相性の良い「最高の右腕」パートナー
実装速度を持つプロダクトエンジニアと、開発基盤を整える開発基盤エンジニアが揃うことで、速く・正しく・持続可能なプロダクト開発が三位一体で回り始める。
このタイプの「トリセツ（取扱説明書）」
モチベーションが上がる接し方
「このシステムの5年後を見据えたアーキテクチャ刷新を設計してほしい」という中長期の難題を丸ごと任せること。技術的根拠を持った設計の自由度と、「決定を組織に浸透させる」権限を与えることが最大のモチベーションになる。
絶対にNGな行動
「技術的負債は後でいいから機能を先に出して」という方針の繰り返し。構造的問題を先送りにし続ける文化では、このタイプが自分の本来の貢献ポイントを見失い、早期離脱リスクが高まる。
