はじめに
高度情報処理試験が制度改定により、論文形式の試験は今年度で最後だと言われています。ITストラテジスト試験も改定により別の試験区分へ移行するため、現行の形式で受験できるチャンスは2026年11月が最後です。
「このチャンスに挑戦しよう」と決めて、私はITストラテジスト試験の対策を始めました。前年にシステムアーキテクト（SA）試験に合格していたこともあり、「SA合格の経験を活かせるはずだ」という手ごたえもありました。実際に論文対策を進めてみると色々と違いが見えてきたので、この時点の気づきを共有したいと思います。
SAは「技術的にどう設計したか」を問うのに対して、STは「経営上の判断としてITをどう活かしたか」を問われます。SA論文で鍛えた構成力は活きますが、語る主体をアーキテクトからCIOへシフトしなければなりません。
重要 SAとSTは「論文の文体」ではなく「語る主体の視点」が違います。技術判断を語るアーキテクトから、経営判断でITを動かすCIO視点へシフトできた人が合格すると思っています。
🎯 対象読者
- ITストラテジスト（ST）の受験を考えている方
- 高度情報処理試験の午後２（論文）で「何を書けばいいのかわからない」と詰まっている方
🧭 この記事で得られること
| Before | After |
|---|---|
| SA論文と同じ感覚でST論文を書いてしまっている | SA/STの視点の違いを構造的に理解できる |
| 実務経験をそのまま書いて「技術寄り」と評価される | 同じ経験を事業視点に変換する具体的な方法がわかる |
| ST論文の準備をどこから始めればいいかわからない | 今日から始められる準備の手順が具体的にわかる |
午前1、2、午後1対策については本記事では取り扱いません。
これらは過去問をいっぱい解きましょう！
2025年にシステムアーキテクト試験へ合格した
私は、2025年のSA試験に合格しました。
準備として取り組んだのは、論文対策の参考書を購入し、掲載されている合格想定論文を問1から問3まで何度も写経することです。最初は「なぜこう書くのか」がよくわからないまま手を動かしていましたが、回数を重ねるうちに、合格するために「必要なこと」が少しずつ見えてきました。
また、SA論文は問1・問2・問3をそれぞれ約20分ちょっとで書き切る必要があります。そのため、写経と並行して時間内に書き切る練習も繰り返しました。内容よりも先に「20分で論文1本分を完結させる感覚」を体に叩き込んでおくことが、本番でのパニックを防いでくれました。
SA論文を通して気づいたのは、「論文試験は文章力より構造力だ」ということです。問われていることに対して、課題→判断→結果の流れを崩さず書ければ高評価につながります。この気づきがST対策にも直接つながっていると感じています。
2026年はITストラテジスト試験に挑戦する
SA合格後、次のステップとして選んだのがITストラテジスト試験です。
選んだ理由はシンプルで、技術だけでなく事業視点を持てるエンジニアになりたいからです。システムを正しく設計する力はSAで鍛えられましたが、「そもそもこのシステムは経営上どこに価値をもたらすか」「競合に対してどんな優位性を作るか」を語れる力が、今後必要だと感じています。
また、IPA（情報処理推進機構）の試験制度が再編の動きを見せているという背景もあります。試験区分の整理や形式の変更が予定されているため、現行の形式で受験できる機会は今年度で最後だと思います。（最新情報はIPA公式サイトで確認してください）。
これらが重なって、2026年は「STに挑む年」と決めました！
SAとSTでは論文の視点が違う
最初は「論文の書き方はわかった。同じ要領でSTも行ける」と思っていました。実際に過去問を解いてみるまでは・・
ST論文の問題文を読んだとき、問われているのが「設計の判断」ではなく「経営の判断」だとすぐに気づきました。この差はかなり大きかったです。
| 観点 | システムアーキテクト（SA） | ITストラテジスト（ST） |
|---|---|---|
| 語る主体 | システム設計者・アーキテクト | CIO・IT戦略リーダー |
| 判断の軸 | 技術的に正しいか、非機能要件を満たすか | 事業目標にITが貢献できるか |
| 課題の捉え方 | システムの性能・可用性・保守性 | 市場競争力・顧客価値・経営効率 |
| 解決策の表現 | 「マイクロサービス化で可用性を担保した」 | 「DXで顧客接点を拡大し売上を20%改善した」 |
| 成果の評価基準 | SLAの達成・障害件数の削減 | KPI達成・事業上の価値創出 |
SA合格者が陥りがちなのは、「技術的に正しい判断をした話」を書いてしまうことでした。ST論文でそれをやると、どれだけ詳細に書いても「事業視点が弱い」という評価になってしまいがちです。
実務経験を「技術視点」から「事業視点」へ変換する
同じ業務経験でも、語り方によってSA論文にもST論文にもなり得ます。変換のポイントは、「技術の話」を「経営へのインパクトの話」に置き換えることです。
変換パターンを具体的に見ると、違いがわかります。
| 技術視点（SA寄り） | 事業視点（ST寄り） |
|---|---|
| 「レスポンスタイムを3秒から0.5秒に改善した」 | 「顧客離脱率の低下により、コンバージョン率が15%向上した」 |
| 「クラウド移行でインフラコストを削減した」 | 「IT固定費の変動費化により、事業規模に応じた投資配分が可能になった」 |
| 「マイクロサービスに分割して開発速度を上げた」 | 「新機能リリースサイクルを短縮し、競合より3ヶ月早く市場投入できた」 |
| 「認証基盤を刷新してセキュリティリスクを低減した」 | 「情報漏洩リスクの低減により、顧客信頼の維持と法的リスクを回避した」 |
変換の流れは以下のように意識しています。
技術的な事実 → それによって何が変わったか（ユーザー・売上・コスト・リスク）
ST論文では「それによって何が変わったか」が主役になります。技術の話は、その判断をした根拠として1〜2文あれば十分だと思います。
ITストラテジスト午後2に向けて私がやっていること
ST対策でもSAと同じく、論文対策の参考書を購入して合格想定論文を写経することから始めました。
SAの時との大きな違いは、写経しながら意識する視点を「システムアーキテクト」から「ITストラテジスト」に切り替えることです。同じ「論文を手で写す」という作業でも、「この人は今、経営者として何を判断しているのか」を意識しながら書くと、SAの写経とはまったく別の気づきがあります。
SAの写経では「なぜこの設計を選んだか」の論理を追っていましたが、STの写経では「なぜ経営上この投資判断をしたか」という別の思考回路が求められます。この視点の切り替えこそが、ST論文攻略の重要ポイントだと実感しています。
写経と並行して意識しているのが、**「事業成果まで言い切る」**ことです。午後2論文でよくある失敗パターンは、解決策は書けているのに「その結果どうなったか」の記述が薄いことです。「〜を導入した」で文章が終わると、判断の妥当性が評価者に伝わりません。
妥当性を判断してもらいやすいような文章作りを意識しています。
また視点の切り替えを体感するための練習として、以下を行っています。
- 自分の実務経験（または架空プロジェクト）を1つ選ぶ
- それをSA視点で200字書く（技術判断中心）
- 同じ内容をST視点で200字書き直す（事業インパクト中心）
- 2つを見比べて、何が変わったかを言語化する
この繰り返しで、「ITストラテジスト視点の語彙」が少しずつ理解出来てきました。
SA合格経験をどう活かすか
SA合格で得た力は、ST論文でも十分に活きます。
まず、論文の「構造」は共通です。「課題の把握→解決策の立案→実施→評価」の流れはSAもSTも同じです。SA論文で身につけた「論理的に流れを崩さない書き方」は、そのままSTでも使えます。
次に、IT全般の知識が土台になります。ST論文では「なぜその技術的選択肢を選んだか」を経営視点で説明する場面があります。そのとき、SAで身につけたアーキテクチャの知識が「なぜそれが事業に有効か」の根拠として機能すると感じています。
SA合格者がSTに取り組む際の強みをまとめると、次のとおりです。
- 論文の構成力（問題提起→解決→評価の流れ）
- IT知識の深さ（技術選定理由の裏付け）
- 論文試験の感覚（時間配分・字数感覚）
午後2で気をつけること
気をつけていることは「技術起点の論文にならないようにする」 ことです。SA論文では「この非機能要件を満たすためにこの設計を選んだ」が正解です。しかし同じ論理でST論文を書くと、「技術の話に終始していて事業判断が見えない」という評価になってしまいます。
⚠️ ST論文で「マイクロサービスを採用した理由はスケーラビリティの確保のため」と書くと、技術論文になってしまいます。「事業の成長に合わせたサービス拡張を可能にするため、スケーラビリティを確保できるアーキテクチャを選定した」と書くと、事業判断の論文になります。書いた後に「経営的な理由が主語になっているか」を必ず確認するようにしています。
もう一つは 「IT部門の内側の話になること」 です。ST論文は「経営者・事業部門にIT活用を提言する立場」で書くことが多く、「エンジニアとして実装した話」は論文の主体としてズレます。「経営陣や事業部門長に説明している場面をイメージできるか」を確認すると、視点のズレに気づきやすくなると意識しています。
まとめ
SAとSTの論文の差は、「難しいかどうか」ではなく 「語る視点が違うこと」 です。SA合格者がSTを受ける場合、論文の書き方を一から学ぶ必要はありません。ただ、「自分が語る主体はアーキテクトではなくCIOだ」という意識の切り替えが鍵になると考えています。
この記事の要点は以下のとおりです。
- 視点の違いを理解する SAは技術判断、STは経営判断で語る
- 変換練習をする 自分の実務経験を事業視点で書き直す練習を1つやってみる
- 事業成果まで言い切る 解決策だけでなく「それで何が変わったか」を必ず書く
まずは過去に関わったプロジェクト1件を選んで「ST視点で200字書く」ところから始めましょう😼
一緒に今年の試験も楽しみましょう！
出典
- IPA 情報処理推進機構 - ITストラテジスト試験 — 試験要綱・過去問
- IPA 情報処理推進機構 - 試験制度 — 制度改編の最新情報