2026年度版　ALL IN ONE パーフェクトマスター　システムアーキテクト　情報処理技術者試験

2026年度版　ALL IN ONE パーフェクトマスター　システムアーキテクト　情報処理技術者試験

雑多なメモff

システム設計において、システム化対象と手作業のまま残す範囲を明確に切り分けることが重要
H27にはソフトウェア化する作業について以下の指針
- 指針
  - 業務上のミス型の業務に大きな影響を与える作業
  - 実施頻度が高い作業
- 補足
  - 共通機能はパッケージを用いて工数・期間糖を短縮することも示されている
  - 手作業でも業務上大きな問題にならない作業はシステム化対象としないことも示されている

JIS X 0160:2021

ISO/IEC/IEEE 12207をベースに策定された、システムのライフサイクルに関する規格
情報処理技術者試験におけるライフサイクルはこれに準拠している
ライフサイクルプロセス
- 調達
  - システムを入手する
  - 外部から入手する場合に適用する
- 開発
- 移行
- 運用
  - システムが稼働し続けるために必要な活動
- 保守
  - 機能の維持・改善
  - バグの修正や機能追加
- 廃棄
廃棄プロセス
- 3つのアクティビティ
  - 廃棄の準備
  - 廃棄の実施
  - 廃棄の確実化
    - 実施すべきタスク：「廃棄後の、ヒトノア健康、安全性、セキュリティおよび環境への有害な状況が識別されて対処されていることを確認する」
- 修正プロセス
  - ライフサイクルモデルの目的および成果を達成するためにライフサイクルプロセスのしゅうせまたは新しいライフサイクルプロセスを定義すること
- シミュレーション：
  - データをもとに現実の場面を想定してモデル問題を作り、事態の変化や進展を分析・予測する
- 統治（Governance）：
  - 企業や組織を支配、まとめ上げて管理すること
- ベンチマーキング：
  - 経営や業務を改革するために、他社の事例等からベストプラクティスを探り、それに向かって自社のプロセスを変革していく手法

要件定義

3段階がある
- 利害関係者要件定義
  - 利害関係者が必要とするサービスを提供する観点の要件を定義
- システム要件定義
  - 利害関係者要件を実現するための技術的な要件を定義
- ソフトウェア要件定義
  - システム要件を定義するソフトウェアの要件を定義
ソフトウェアシステム図方法論
- 7つのステージで利害関係者の合意をとる
要件
- 機能要件
  - 機能として識別できる
- 非機能要件
  - 機能とは識別できない要件。性能や信頼性等
- BCP
- DR
- RPO
- RTO
- BABOK
  - ビジネスアナリシスのベストプラクティスを体系化したもので、要件定義に有用な考え方
    - ビジネスアナリシス：ユーザー要求を引き出して定義すること
  - この考えそのものを問う試験はまず出てこないが、要求引き出しや優先順位の付け方等で論述試験に使える。

利害関係者要件定義

下記のような工程

利害関係者の識別
要件の識別
要件の評価　
要件の合意
要件の記録

システム化計画（システム企画）の後に始まる工程

ソフトシステムズ方法論

利害関係者間で目的を共有するのに使う。下記ステップのイメージ

問題状況の認識
課題・論点の明確化
基本定義
概念モデルの作成
現実と概念モデルの比較
行動の決定
行動の実勢

システム要件定義

利害関係者要件をシステムでどのように解決するか優先順位をつけて、利害関係者承認を経て、ベースラインを設定する

ソフトウェア要件定義

各ソフトウェア品目が満足するべきソフトウェア要件を定義する。例えば下記

機能および能力の使用
外部IF
妥当性確認の要件
安全性使用
セキュリティしよう
人間工学仕様
データの定義およびDBの要件
導入および受け入れに関する要件
利用者用文書の要件
利用者の運用要件および実行要件
利用者の保守要件

利害関係っ者による評価・レビューを経て承認されて、ベースラインを設定する

機能要件と非機能要件

機能要件の識別には下記のような分析をおこなう

機能間のデータの流れを明確にする
- DFDとか
  - 後でモデル化手法としてまとめる
利用者の要求をもとに、情報管理の観点や単位、形式等を分析する
他のシステムとのインタフェースを定義する

非機能要件の抽出にはJIS X 25010:2013におけるシステム/ソフトウェアの品質特性を参考にできる。製品としての品質特性だけでなく、利用者視点の品質特性も定義されている

機能適合性
- 業務に必要な機能をもれなく実装できているか
性能効率性
- 必要な性能を満足しつつ、プロセッサ、メモリ、利用者の認知負荷等の資源を効率的に使用しているか
互換性
- 部品や製品を置き換えても問題なく動作するか
使用性
- 使いやすく、習得も容易であること
信頼性
- 可用性が高く、障害の影響を受けにくいこと
セキュリティ
- 不正アクセスや改竄等を受けないこと
保守性
- 修正が容易であること
移植性
- 他の環境への移植が容易であること

BAGOK

論述試験の考え方に有効なものを取り上げる。

ビジネスアナリシス活動を6つの知識エリアに整理している。基礎コンピ天使を加えた7つの知識エリアとすることも多い
- 戦略アナリシス
  - 組織のAsisとTobeの定義
- 要求アナリシスとデザイン定義
  - AsIsとTobeのギャップからニーズを引き出し、要求としてモデリング
  - 解決策をベースに業務・システム設計を提議
- ソリューションと評価
- 引き出しとコラボレーション
  - 潜在的なニーズや要求を引き出す
- 要求のライフサイクルマネジメント
  - 要求の引き出しから実現までの全過程をマネジメントする
- ビジネスアナリシスの計画とモニタリング
  - BA活動を計画・モニタリング・フィードバック
- 基礎コンピテンシー
  - ビジネス知識や問題解決スキル等、基礎的な能力
ユーザー要求を4つに分類。各要求は連鎖しているので、追加変更等の際には一貫性や生合成を都度評価する。
- ビジネス要求
  - 経営者による経営戦略上の要求
- ステークホルダー要求
  - ユーザー部門・運用部門等の関係者による要求
- ソリューション要求
  - システムの実装に関する要求。機能要求や非機能要求
- 移行要求
  - 新システムへの移行に必要なデータ変換やユーザー教育等
要求の優先順位をつける観点。各観点でマトリクスを作って判断の参考にすることもある。
- 便益
  - ビジネス上の価値
- 規制・ポリシー
  - 法規制や社内規定等
- コスト
- リスク
  - 実現できない可能性
- 依存性
  - 要求間の依存関係
- 安定性
  - 変更の可能性
ユーザー要求は増えることはあっても減ることはまずないので、どこかでユーザー要求を絞り込む必要が出てくる。
- プロマネ等と協力してトリアージする。開発期間や予算等の制約も考慮する必要がある

要件の評価

システムアーキテクトの業務は利害関係者要件定義から始まっている。経営戦略に合わないソフトウェアを構築する恐れがあるため。

p99までノートなし

設計手法

GoF

SOLID原則

オブジェクト指向向けの設計原則
- Single Responsibility principe（単一責任の原則）
  - クラスに持たせる役割は一つだけにするべき
- Open-Closed principle（開放閉鎖の原則）
  - クラスは拡張に対して解放されており、修正に対して閉鎖している
- Liskov Substituion principle（リスコフの置換原則
  - 上位クラスの処理を下位クラスで置き換えることができる。
- Interfaace Segregation principle（インターフェース分離の原則）
  - クラスを利用するクライアントごとに異なるメソッドが必要な場合、インターフェースを分ける
- Dependancy inversion principle（依存性逆転の法則）
  - 上位モジュールは下位モジュールに依存しない

ユースケース駆動開発

ユースケース（ユーザーから見たシステムの機能）に注目したシステム開発方法論。
ICONIXが草分け的存在らしい。
ユースケースから動的な振る舞いを分析し、静的な構造を導出する。
- ICONIXでは4種類のUML図を提案している。
  - 動的な分析
    - ユースケース図
    - ロバストネス図
    - シーケンス図
  - 静的な構造
    - クラス図

ICONIXの例

下記手順でシステム開発する
- ①要件定義
  - ドメインモデリング
    - ほぼ大まかなクラス図のこと。メンバとかメソッドとかがない、名前だけくらいのもの
    - 後工程で詳細化する
  - ユースケース図
- ②分析・設計
  - ロバストネス分析
    - BCEモデルのオブジェクトに割り当てる
      - Boundary（境界オブジェクト）
        
        画面操作・表示
      - Control（制御オブジェクト）
        
        業務処理の実行制御
      - Entity（実態オブジェクト）
        
        データの実態
    - ユースケースとオブジェクトの関連付けができる
- ③詳細設計
  - シーケンス図作成
    - システムに必要なオブジェクトやメソッドがわかる
  - クラス図作成
- ④実装
- レビュー
  - 各ステップの終了時のレビューを定めている
  - 要求レビューでユースケースがユーザー要求を満たしているか
  - 設計レビューでロバストネス図・ドメインモデル・ユースケース記述の整合性

デザイン思考

ユーザー視点で問題解決に取り組む方法論。

開発管理

開発ライフサイクルモデル

開発工程のモデルのこと。

ウォーターフォールモデル

上流工程から下流工程まで一方向に進めるモデル。
原則として工程は後戻りしない
情報処理技術者試験では一番出題されるモデル
工程の後戻りを防ぐ基本はレビューとテストで品質を確保すること

スパイラルモデル

4つのフェーズを繰り返す
- 目的、代替案、制約の決定
- 代替案とリスクの評価
- 開発と検証
- 計画

2026年度版 ALL IN ONE パーフェクトマスター システムアーキテクト 情報処理技術者試験