ITアーキテクト（SIer） → ソリューションアーキテクト
ソリューションアーキテクト: 顧客課題に対して最適な技術ソリューションを設計・提案するアーキテクト。プリセールスから基本設計まで一貫して担当する。
完全プランを見る大手SIerに新卒で入社して20年、Java/Oracleを軸にした業務システム構築のITアーキテクトとして数多くのプロジェクトをリードしてきた。一方でクラウドネイティブな案件への対応は遅れ気味で、近年は『AWSやKubernetesを前提にした提案ができないと案件が取れない』状況に直面している。顧客に対して業務理解とテクノロジーを統合した提案ができるソリューションアーキテクトに進化することで、SIerでの存在価値を再構築したい。資格取得も並行して進める方針。 これまでITアーキテクト（SIer）として現場での運用と改善を積み重ねてきたが、事業のスケールに伴いインフラへの要求は質・量ともに増大し、属人化した知識や場当たり的な対応では限界を感じる場面が増えている。特に信頼性・可観測性・コスト最適化・セキュリティを横断的に設計できる人材の不足を痛感しており、自分が次のステップとしてソリューションアーキテクトを担うことで、組織全体の技術的意思決定に貢献したいという思いが強くなっている。そのために体系的な知識の再学習と、現場で得た経験の言語化を並行して進めている。
「業務理解と要件定義の蓄積を強みに、現代のクラウド技術と組み合わせて、顧客の事業課題に刺さる提案ができるソリューションアーキテクトになる。SIerの中で再びリード役を務め、提案フェーズから実装フェーズまで一貫して任せられる存在を目指す。 日々の運用で見えてきた課題を、その場しのぎではなく根本から設計し直したい。ソリューションアーキテクトとしてアーキテクチャ意思決定の責務を負うには、特定ベンダーや特定スタックに閉じない普遍的な原理原則を自分の言葉で語れるレベルまで引き上げる必要があると考えている。学習を通じて短期的なキャッチアップではなく、長期にわたって判断軸として機能する基盤を築きたい。」
宮本 和夫さん本人の学習設計の語り
まずクラウドの全体像とAWS設計を体系化し、次にIaCとマイクロサービス・Kubernetesで現代的な実装イメージを補強する。最後にアーキテクチャ全体像と提案ドキュメンテーションを押さえ、提案書・設計書に落とせるレベルまで仕上げる。 学習は週末と平日夜の限られた時間で進めるため、最初に全体像を掴んでから各論に入る順序を徹底している。読んだ内容はその週のうちに小さな検証環境で手を動かして確かめ、理解が曖昧な箇所は同僚や勉強会で議論することで定着させている。ソリューションアーキテクトとして通用する判断力を身につけるため、単なる知識の収集ではなく『なぜそう設計するのか』を説明できる状態を毎章のゴールに置いている。挫折しそうになったときは、最初に書き出した転身後の理想像を読み返して軌道修正している。
現在のスキル水準とソリューションアーキテクトに必要な水準を並べ、何を伸ばすべきかを可視化しています。
迷ったらこの順番で読むのが推奨。基礎 → 実践 → 視座を上げる、という流れで構成されています。
なぜこの本か
従来のITアーキ観点をモダンなアーキテクチャ判断の語彙にアップデートする定番書。SIerでも通用する『なぜそう設計したのか』を説明できるようになる。 ソリューションアーキテクトを目指す上で、本書が扱うテーマは現状の自分に決定的に欠けている領域であり、日々の業務で直面する課題を体系立てて理解し直すために最も優先度の高い一冊と判断した。読了後はチーム内で要点を共有し、設計判断の場で参照できるレベルまで落とし込む計画である。
なぜこの本か
業務システムのモジュール化をクラウド前提で再設計するための土台。提案フェーズで『マイクロサービスを採用すべきか否か』を顧客に対して語れるようになる。 ソリューションアーキテクトを目指す上で、本書が扱うテーマは現状の自分に決定的に欠けている領域であり、日々の業務で直面する課題を体系立てて理解し直すために最も優先度の高い一冊と判断した。読了後はチーム内で要点を共有し、設計判断の場で参照できるレベルまで落とし込む計画である。
K8sとIaC、マイクロサービス
全体設計と信頼性、ドキュメント
同じ職種・近いレベル感を目指す他のペルソナです。学習プランや読む順番のバリエーションとして参考にしてください。
宮本 和夫さんの学習プランは「ソリューションアーキテクト」を目指す一例です。 職種全体のロードマップ・必要スキル・代表的な書籍は専用ページで体系的に確認できます。
ソリューションアーキテクトのロードマップを見る →
