公共・自治体×システムアーキテクト論文の書き方
システムアーキテクト（SA）の論文では『要件定義から方式設計までの一貫性』が問われます。公共・自治体を題材にすると、業種特有の調達手続き・規制・住民影響など、論文に厚みを出す要素が多く揃います。本記事では公共・自治体×SA 論文で説得力を高める題材パターンを解説します。
本記事は過去問AI が独自にまとめた解説です。
公共・自治体の業種特性
- 調達手続きの厳格性（地方自治法・契約事務規則）
- 住民への影響の広範性
- 議会・監査委員会など外部統制
- マイナンバー法・個人情報保護法への準拠
- 自治体クラウド・標準化準拠の要請
- レガシーシステムの長期利用
SA 論文で問われる典型テーマ
- 業務要件と非機能要件のバランス
- 既存システムとの連携設計
- 移行・カットオーバー設計
- アーキテクチャ選択の合理性
題材パターン 1: 自治体システムの標準化対応
骨子：
- 背景: 政府の自治体システム標準化方針、20 業務の標準準拠期限
- 課題: 既存パッケージのカスタマイズ依存、独自業務フローとの整合
- 施策: ガバメントクラウド前提のアーキテクチャ再設計
- SA の判断: 標準仕様準拠と独自要件の切り分け、データ移行設計
業種特有の論点：
- 標準仕様への準拠と独自業務継続の両立
- 他自治体との比較・横展開可能性
- 議会説明・住民周知のリードタイム
題材パターン 2: マイナンバー連携システム
骨子：
- 背景: 住民票・税・社会保障の業務横断連携要請
- 課題: 既存基幹系の分散構造、マイナンバー法による厳格な情報連携制限
- 施策: 中間サーバ経由の連携アーキテクチャ、ログ取得の網羅
- SA の判断: 情報連携の最小化、監査要件の充足
業種特有の論点：
- 特定個人情報保護評価（PIA）の対応
- 情報連携ネットワーク（コアシステム）の制約
- 漏洩リスクの最小化設計
題材パターン 3: 災害情報配信システム
骨子：
- 背景: 災害発生時の住民への情報伝達を迅速化
- 課題: 既存の防災行政無線・メール配信が分散、住民登録率が低い
- 施策: マルチチャネル配信基盤（防災アプリ・SNS・緊急速報メール統合）
- SA の判断: 可用性設計、非常時の代替系統
業種特有の論点：
- 非常時の電源・通信途絶への耐性
- 高齢者・要支援者への配慮
- 自治体間連携（広域災害時）
採点者が見るポイント
- 業務要件と非機能要件（性能・可用性・セキュリティ）の対応関係
- アーキテクチャ選択の根拠が業種特性に基づくこと
- 既存システムとの連携の現実性
- 段階移行・並行運用の設計
ありがちな失敗
- 公共を題材にしながら、内容は一般 SI プロジェクトと同じ
- 議会・監査・住民影響などの公共特有のステークホルダーが出てこない
- 調達手続き・法規制への言及がない
- 災害・障害時の影響評価が抽象的
業種特有のキーワード集
- ガバメントクラウド・自治体システム標準化
- マイナンバー法・特定個人情報保護評価（PIA）
- 自治体情報セキュリティクラウド
- 地方自治法・契約事務規則
- 公開調達・総合評価方式
- 住民基本台帳ネットワーク（住基ネット）
過去問AI の業種別事例集
過去問AI では SA 論文向けの業種別事例集を提供しています。公共の事例は システムアーキテクト 過去問 と 業種別 論述事例集 からアクセス可能です。
まとめ
- 公共・自治体×SA 論文は『標準化・規制対応・住民影響』が三大論点
- 題材パターンは自治体標準化、マイナンバー連携、災害情報配信
- 業種特有のキーワードと登場人物を必ず織り込む
- AI 添削と業種別事例集で完成度を上げる
業種別 論述事例集 で他の題材パターンも確認できます。