システムアーキテクト機能追加の業務要件分析と設計【論文の書き方】（令和3年春問2）

更新：2022/7/27

本記事ではシステムアーキテクトの午後II（論文）対策として、

令和3年問2で出題された過去問を分析します。

実際に論文を書く上での考え方を整理し

論文骨子を設計するところまでやっていきます。

問題（令和3年問2）

過去問は試験センターから引用しています。

表題：『情報システムの機能追加における業務要件の分析と設計について』

設問文は以下の通り。

問われている箇所を分析する

問題文が配られたら初めに問われている箇所を分析します。

始めに各設問が何を問うているかを把握します。

設問ア・イ・ウと問題文の文章を対照させるイメージで

問題文と設問文に書き込みを行います。

本記事では黒線で書き込みを行っています。

設問アで「機能追加が必要になった背景」が問われているので

論述の題材としては新規のシステム開発案件ではなく、

既存のシステムに対する改修案件にする必要があるでしょう。

設問イに「業務要件をどのような視点でどのように分析し」という

文がありますが、対応する問題文に3点に分けて説明されている

箇所があります。

簡単に説明しなおすと次の通りです。

【業務要件の分析の手順】

契約条件や業務プロセスや関連システムから分析する
影響範囲の機能を特定する
対象の機能への改修内容を設計する

設問イの「どのように分析し」という点は上記のステップを

踏まえる必要があるでしょう。

設問ウではフェーズが少し進み、

システム方式設計というよりソフトウェア方式設計に

入っています。

「設問イで述べた機能追加における設計において」という

指定があるので設問イの設計に対して

施したソフトウェア実装面の工夫を論述するのがよいでしょう。

まとめると問われていることは次の通りです。

設問ア

　対象の情報システムと業務の概要

　機能追加が必要になった背景と対応が求められた業務要件

設問イ

　業務要件の分析　←　業務要件の分析の手順の1.～2.

　設計した内容　←　業務要件の分析の手順の3.

設問ウ

　機能追加における設計に対する工夫

設問イは【業務要件の分析の手順】の1.～3.を

含められればよいです。

1. と 2. は分けて論述すると冗長になりそうなので、

本記事においてはまとめて論述する設計としています。

出題要旨と採点講評からの分析

試験センターから公表されている出題要旨と採点講評を確認して

出題の意図と論述のNG例を把握します。

出題要旨

採点講評

出題要旨から読み取れる意図は

「業務要件の分析の視点と分析方法」と「設計で工夫したこと」

とあり、前者は設問イ、後者は設問ウが対応しています。

採点講評からは次のNG論述例が書かれています。

業務要件の分析の視点がない
分析結果に基づく設計ということが説明されていない

上記のようなケースはNG例であることが言われているので、

分析の視点を盛り込めば合格圏内に大きく近づけると思います。

論文を設計する

問われていることの概略を把握したら

自身の経験や用意してきた論文パーツに当てはめて

どのように論述を展開するかを設計します。

本記事では上記の筆者の論文事例マップを基に

論文の設計を行います。

論文事例マップ自体の説明は本記事では割愛します。

設問アの設計

設問アに対応する問題文には

「法改正、製品やサービスのサブスクリプション化などを背景に」

という一文があります。

私の場合はスーパーマーケットのECサイトの事例が

サブスクリプション化が題材でしたので論述対象に選択しました。

また「対応が求められた業務要件」も記載が必要ですが、

のちに設問イや設問ウで設計を選択する根拠にできるような

業務要件が望ましいので、

「機能追加による既存システムの応答性を下げてはならない」

という点を挙げることにしました。

のちにどの部分の伏線になるかは説明いたします。

設問イの設計

問題文で指定されている【業務要件の分析の手順】の1. は、

「契約条件や業務プロセスや関連システムから分析する」と

書かれています。

設問では「どのような視点で」を問われているので、

たとえば「業務プロセスや関連システムから分析した」と

記載すれば解答したことになると思います。

本問のような指定が無かったとしても、

業務プロセスの視点無しで分析はできないと知識として

知っておくべきです。

さらに本問は既存システムの改修が前提なので、

当然既存の関連システムの視点も必須でしょう。

次に【業務要件の分析の手順】の2. と 3. を中心に

どのような機能を対象にどのような設計をしたかを

論述していきます。

私の場合は月額サブスクサービスの提供を題材にしていたので

課金請求機能の改修　月額での課金ができること
在庫引当機能の改修　月に一度発送する商品を在庫から引き当てること

ができる設計について論述することとしました。

「どのような機能」は上記でよいですが「どのような設計」は

さらに展開を練る必要があります。

問題文には

契約形態の項目に新サービス用のコード値を追加する
新たなコンポーネントを追加し新サービスではこのコンポーネントを呼び出す

といった例示があります。

この例示に共通しているのは改修の範囲を限定していることと、

将来の拡張に備えた設計になっていることです。

採用した設計も上記の点を踏まえる必要があります。

具体的には複数の案を列挙して、案の採用理由時に

上記の点を根拠とするのが分かりやすい論述になると思います。

たとえば課金請求機能の改修ですと次のような具合です。

案1. 通常商品の課金請求モジュールを継承してサブスクリプション型サービスのモジュールを新設する

案2. サブスクリプション商品の有無のみを根拠に処理を分岐し課金請求機能自体は既存のモジュールを共有する

私は案1. を採用した。

理由は、案2. はバグ混入時の影響が既存の業務にも影響を与えてしまうためである。

上記のように展開することで、題意に沿いながら、

システムアーキテクトとしての主体的な活動・判断をアピールできます。

また、案1. を採用した理由に、設問アで触れた

「既存の業務に影響を与えない」という業務要件が

利いていることも確認してください。

設問ウの設計

設問イでの設計をもとに設問ウで工夫した点を論述します。

設問イの設計でのデメリットを挙げて、それでもその設計を

採用するためにデメリットを押し下げる工夫や、

設問イの設計では生じる課題を挙げて、それを工夫によって

解決するといった骨子で論述するのがよいでしょう。

設問イでは、改修の範囲を限定している設計、

将来の拡張に備えた設計採用しているので、

デメリットとしてはモジュールやロジックを分割したことによる

ソフトウェアの難読性・処理スピードダウンを挙げられます。

上記の展開は多くのシステムアーキテクトの論文で利用できる

王道パターンだと思います。

デメリットを回避するには保守性の向上を図ることと、

そもそも求められる処理スピードについて評価を加えるなどが

考えられます。

私の場合はO/Rマッピングツールで保守性を向上させたことと、

業務要件に照らして評価（設問アの条件を持ち出し、

"条件外"であることを示す。つまり処理スピードが新業務において

既存業務より低いことは問題にならない）したことを

工夫点として論述しました。

論文骨子

以上を踏まえ、論文骨子は次のようになりました。

1. 私が携わった情報システムの機能追加について
　1-1. 対象の情報システムと業務の概要
　　スーパーマーケットのECサイト。統合販売管理システムの改修。
　　注文受付機能の他、在庫引当機能、課金請求機能を持つ。
　1-2. 機能追加が必要になった背景、対応が求められた業務要件
　　競争力強化でサブスクリプション型のメニューの開始
　　機能追加による既存のオンライン注文の応答性を下げてはならない。
2. 業務要件の分析と設計した内容
　業務プロセスと関連する情報システムの機能の視点から改修範囲を分析。
　2-1. 業務要件の分析
　　(1)課金請求機能　月額での課金請求ができること
　　(2)在庫引当機能　月に一度発送する商品を在庫から引き当てること
　2-2. 設計した内容
　　(1)サブスクリプション型サービスの課金請求モジュールの新設
　　　案①通常商品の課金請求モジュールを継承する
　　　案②サブスクリプション商品の有無のみを根拠に処理を分岐し
　　　　　課金請求機能事態は既存のモジュールを共有
　　　案①を選択。案②はバグ混入時の影響が既存の業務にも
　　　影響を与えてしまうため。
　　(2)サブスクリプション型サービスの商品を選択する在庫引当ロジックの分離
　　　案①在庫引当機能の中に商品引当ロジックを記述する
　　　案②商品引当ロジックを分離する
　　　案②を選択。季節や流行、在庫状況からロジックが変わることが予想され、
　　　分離しておけば入れ替えが容易のため。
3. 機能追加における設計で生じた課題と工夫
　3-1. 設計で生じた課題
　　(1)プログラムの複雑化
　　　類似の記述が複数個所に書かれ、コードが複雑化、保守性が落ちる恐れ。
　　(2)処理オーバーヘッド
　　　単一処理の既存プログラムに比べ、読み出しのオーバーヘッドが生じ
　　　効率性が落ちる。
　3-2. 工夫した施策
　　(1)O/Rマッピングツールで保守性向上
　　　データストアにアクセスする部分のコードを自動生成。
　　　モジュールやロジックを分離することは一貫させつつ、
　　　信頼性の高いプログラムで保守性を維持。
　　(2)業務要件に照らして評価
　　　オーバーヘッドは通常商品のオンライン注文時に発生するものではない。
　　　テストにてサブスクリプション型サービスの処理中に
　　　通常商品の注文を行っても応答性に変化はなかった。