平成２６年度　問２　データ交換を利用する情報システムの設計,,,,,, ,,,,,, ,　ビジネスのスピード向上や業務運用の効率向上を目的として、企業間や企業内システム間でデータ交換を利用す,,,,, ,る情報システムを構築する企業が増加している。データ交換では、運用時間帯、データ送信順序などの制約事項が,,,,, ,、あらかじめ決まっている場合が多い。システムアーキテクトは、これらの制約事項を踏まえて、データ交換を利用す,,,,, ,る情報システムを設計しなければならない。,,,,, ,　例えば、データ交換を利用する受発注システムの場合、次のように情報システムの設計を行う。,,,,, ,,・,大量の入力データがある場合でも、データ送信開始時刻に間に合わせるために、送信側で送信データの作成,,, ,,,を多重で処理できるように設計する。,,, ,,・,受注データとマスタデータの送信順序が保証されない場合、データの整合性を維持するために、受信側で全,,, ,,,ての受信データを一時保管した上で、その中からマスタデータを先に反映するように設計する。,,, ,　さらに、次のように、データ交換に伴う異常を想定して、情報システムでの対応方法を用意しておくことも重要であ,,,,, ,る。,,,,, ,,・,一部の受信予定データが届かない場合、その後の処理全体が滞ることを避けるために、事前の取り決めに従,,, ,,,って、後続処理を開始できるようにする。,,, ,,・,受注データの受信から加工までの処理を自動化する場合でも、受注数量が過去実績に比べて極端に多いな,,, ,,,どの業務上の異常データが発生したときには、処理を中断して人手による確認ができるようにする。,,, ,,,,,, ,設問ア,,,あなたが構築に携わった情報システムにおいて、データ交換を利用する目的を、対象業務、および対象の,, ,,,,情報システムの概要を含めて、800字以内で述べよ。,, ,設問イ,,,設問アで述べた情報システムの構築において、どのような制約事項を踏まえて、どのように情報システム,, ,,,,を設計したか。800字以上1600字以内で具体的に述べよ。,, ,設問ウ,,,設問アで述べた情報システムの構築において、データ交換に伴うどのような異常を想定し、情報システム,, ,,,,でどのような対応方法を用意したか。その対応が必要になる理由とともに、600字以上1200字以内で具体,, ,,,,的に述べよ。,, ,,,,,, ■ポイント,,,,,, ,,,,,, ,■出題趣旨,,,,, ,,,,,, ,,　ビジネスのスピード向上や業務運用の効率向上を目的として、企業間や企業内システム間でデータ交換を利用,,,, ,,する情報システムを構築する企業が増加している。データ交換では、運用時間帯、データ送信順序などの制約事,,,, ,,項が、あらかじめ決まっている場合が多い。システムアーキテクトは、これらの制約事項を踏まえて、データ交換,,,, ,,を利用する情報システムを設計しなければならない。,,,, ,,　本問は、データ交換を利用する情報システムの構築において、どのような制約事項を踏まえ、どのように情報シ,,,, ,,ステムを設計したか、また、どのような異常を想定し、情報システムでどのような対応方法を用意したか、具体的,,,, ,,に論述することを求めている。論述を通じて、システムアーキテクトに必要なデータ交換を利用する情報システム,,,, ,,の設計能力を評価する。,,,, ,,,,,, ,■採点講評,,,,, ,,,,,, ,,　全問に共通して、設問に素直に答えている論述が多かった。また、問題文の引用で文字数を費やし、内容が薄,,,, ,,くなってしまっている論述も少なかった。一方で、問題文に記載してある観点などを抜き出し、一般論と組み合わ,,,, ,,せただけの論述は引き続き散見された。問題文に記載した観点は例示である。自らが実際にシステムアーキテク,,,, ,,トとして、検討し取り組んだことを具体的に論述してほしい。,,,, ,,　問２（データ交換を利用する情報システムの設計について）では、設計内容が具体的に論述されているものが,,,, ,,多かった。データ交換を利用する情報システムの設計を実際に経験した受験者が、論述したことがうかがえる。,,,, ,,システムアーキテクトとして、引き続き、様々な制約事項を考慮した情報システムの設計能力を高めていってほし,,,, ,,い。,,,, ,,,,,, ,　企業間や企業内システム間でデータ交換を利用する情報システムの設計がテーマの問題である。一般に、データ,,,,, ,交換では運用時間帯の問題などの制約事項があり、システムに求められる要件の一つとして、制約事項を踏まえた,,,,, ,情報システムを設計しなければならない。制約事項には、運用面以外に処理面や性能面など様々な側面が考えら,,,,, ,れる。システムアーキテクトは、制約事項の特性をよく理解しておく必要がある。複数のシステムが関連するデータ,,,,, ,交換においては、データ量の突発的な増大など想定外の事態が発生する。システムアーキテクトには、異常事態を,,,,, ,想定したシステムを設計することが求められる。,,,,, ,,,,,, ,　設問アでは、「データ交換を利用する目的」、「対象業務の概要」、「対象システムの概要」を記述する。「対象業務,,,,, ,の概要」、「対象システムの概要」は、システムアーキテクト試験における定番の要求事項であり、特定の事項につ,,,,, ,いての記述は要求されないため、受験者の経験に基づいて記述すれば十分である。「データ交換を利用する目的」,,,,, ,については、問題文の冒頭にある「ビジネスのスピード向上や業務運用の効率向上を目的として」という記述を参考,,,,, ,にできる。データ交換であるから、少なくとも２つの情報システムが関連することになる。複数の情報システムを新規,,,,, ,に構築するときにデータ交換を利用する案件、新規に構築する情報システムが既存の情報システムとの間でデータ,,,,, ,交換を利用する案件など題材の制約は少ないと考えられる。,,,,, ,,,,,, ,　設問イでは、「具体的な制約事項」、「情報システムの設計内容」を記述する。制約事項に関する問題文の例は「運,,,,, ,用時間帯」、「データ送信順序」だけである。情報システムの設計内容に反映できるようにするには、詳細な記述が,,,,, ,必要である。例えば、運用時間帯の制約であれば、データ交換に利用できる時間、データ交換を行うタイミング、デ,,,,, ,ータ交換で発生するデータ量の変動幅などを具体化しなければならない。ただし、問題文には「大量の入力データが,,,,, ,ある場合でも、データの送信開始時刻に間に合わせるために、送信側で、送信データの作成を多重で処理できるよ,,,,, ,うに設計する」、「受注データとマスタデータの送信順序が保証されない場合、データの整合性を維持するために、受,,,,, ,信側で全ての受信データを一時保管したうえで、その中からマスタデータを先に反映するように設計する」という例が,,,,, ,示されている。必要なことは、「制約事項に対応して、どのような処理内容としたか」が記述されていることである。設,,,,, ,問イでは「800字以上」の記述が要求されている。設問の要求事項が、制約事項と情報システムの設計内容の２つで,,,,, ,あるため、相応に詳細に記述しなければ、800字を満たせなくなる可能性がある。記述量を確保できるよう、ストーリ,,,,, ,ー作成の段階で記述項目をよく吟味しておく必要がある。,,,,, ,,,,,, ,　設問ウでは、「想定したデータ交換に伴う異常」、「情報システムでの対応方法と対応が必要になる理由」を記述す,,,,, ,る。「想定したデータ交換に伴う異常」については、業務プロセスにおける例外処理が考えられる。問題文の例では「,,,,, ,一部のデータが届かない場合」、「受注数量が過去実績に比べて極端に多いなどの業務上の異常データが発生した,,,,, ,とき」が示されている。情報システムの設計においては、正常処理に加え、例外処理についても設計するため、受験,,,,, ,者の経験に基づいて記述すれば題意を満たすと考えられる。ただし、要求事項が「データ交換に伴う異常」であるた,,,,, ,め、「応答速度の低下」や「ハードウェアの故障」などデータ交換に直接関連しない異常を記述しないように注意しな,,,,, ,ければならない。「情報システムでの対応方法と対応が必要になる理由」については、問題文に分かりやすい例が,,,,, ,示されている。具体的には、「一部の受信予定データが届かない場合、その後の処理全体が滞ることを避けるため,,,,, ,に、事前の取り決めに従って、後続処理を開始できるようにする」、「受注データの受信から加工までの処理を自動,,,,, ,化する場合でも、受注数量が過去実績に比べて極端に多いなどの業務上の異常データが発生したときには、処理,,,,, ,を中断して人手による確認ができるようにする」となっている。情報システムでの対応方法であるから、「運用で対応,,,,, ,する」では題意を満たさない。対応方法だけを記述して、「対応が必要になる理由」を書き忘れないように注意してお,,,,, ,きたい。,,,,, ,,,,,, ■見出しとストーリー,,,,,, ,,,,,, ,■設問ア,,,,, ,,,,,, ,,　設問アには、問題文の次の部分が対応する。,,,, ,,,,,, ,,設問ア,,,あなたが構築に携わった情報システムにおいて、データ交換を利用する目的を、対象業務、及び対象, ,,,,,の情報システムの概要を含めて、800字以内で述べよ。, ,,,,,, ,,,　ビジネスのスピード向上や業務運用の効率向上を目的として、企業間や企業内システム間でデータ交換を,,, ,,,する情報システムを構築する企業が増加している。データ交換では、運用時間帯、データ送信順序などの,,, ,,,制約事項が、あらかじめ決まっている場合が多い。システムアーキテクトは、これらの制約事項を踏まえて、,,, ,,,データ交換を利用する情報システムを設計しなければならない。,,, ,,,,,, ,,　例として次のような見出しとストーリーが考えられる。,,,, ,,,,,, ,,,ア　対象の業務と対象の情報システムの概要、及びデータ交換を利用する目的,,, ,,,ア―１　対象の業務と対象の情報システムの概要,,, ,,,,,, ,,,,・,対象の業務は近畿県内A市の市民向けの広報業務, ,,,,・,A市が提供する広報には、市政報告、市内の医療情報、市主催のイベント情報、市立カルチャーセンタ, ,,,,,ーのスケジュール、ごみ収集カレンダーなど日常市民が利用する情報など多くのものが掲載されている, ,,,,・,A市では市域の振興と地産地消を進める一つの手段として、市内に複数存在する商店連合会のイベン, ,,,,,ト情報などを広報に掲載することになった, ,,,,・,40年を超える歴史を有する商店連合会もあり、地元に根付いた商店の集まりとして市民に親しまれてい, ,,,,,る, ,,,,・,市内には大手交通機関が運営するバス路線が充実しており、市内で別の地域に転居してもバスを利用, ,,,,,して長年のなじみのある商店へ買い物に出向く市民も多い, ,,,,・,高齢者向けにはバス運賃の補助制度があり半額でバスが利用できるようになっている, ,,,,・,A市の広報はWebで市民に公開されており、パソコンのほかスマートフォンやタブレットからも利用できる, ,,,,・,最近は高齢者であってもスマートフォンやタブレットを利用する市民が多い, ,,,,・,自身の立場は、今回の情報システムの設計を請け負ったシステムインテグレータP社に所属するシステ, ,,,,,ムアーキテクト, ,,,,,, ,,,ア―２　データ交換を利用する目的,,, ,,,,,, ,,,,・,多くの商店連合会では独自のWebサイトを立ち上げており、日替わりの特売メニューの情報や、特産品, ,,,,,の販売などの情報を掲載している, ,,,,・,Webサイトを持たない商店連合会であっても、広告用や管理用に自前で様々な情報をサーバで管理し, ,,,,,ている, ,,,,・,A市広報部は、市内の商店連合会の情報を一元で市民に提供できるよう、Webサイトを日々更新するこ, ,,,,,とを検討している, ,,,,・,各商店連合会も売上拡大のよい機会ということで積極的に協力する旨の同意が得られている, ,,,,・,A市のWebサイトと商店連合会が管理する情報は別のシステムであり、データ交換によってA市に集め, ,,,,,ることとした, ,,,,,, ,■設問イ,,,,, ,,,,,, ,,　設問イには、問題文の次の部分が対応する。,,,, ,,,,,, ,,設問イ,,,設問アで述べた情報システムの構築において、どのような制約事項を踏まえて、どのように情報システ, ,,,,,ムを設計したか。800字以上1600字以内で具体的に述べよ。, ,,,,,, ,,,　ビジネスのスピード向上や業務運用の効率向上を目的として、企業間や企業内システム間でデータ交換を,,, ,,,利用する情報システムを構築する企業が増加している。データ交換では、運用時間帯、データ送信順序など,,, ,,,の制約事項が、あらかじめ決まっている場合が多い。システムアーキテクトは、これらの制約事項を踏まえて、,,, ,,,データ交換を利用する情報システムを設計しなければならない。,,, ,,,　例えば、データ交換を利用する受発注システムの場合、次のように情報システムの設計を行う。,,, ,,,,・,大量の入力データがある場合でも、データの送信開始時刻に間に合わせるために、送信側で、送信デ, ,,,,,ータの作成を多重で処理できるように設計する。, ,,,,・,受注データとマスタデータの送信順序が保証されない場合、データの整合性を維持するために、受信側, ,,,,,で全ての受信データを一時保管したうえで、その中からマスタデータを先に反映するように設計する。, ,,,,,, ,,　例として次のような見出しとストーリーが考えられる。,,,, ,,,,,, ,,,イ　データ交換における制約事項、及び設計した情報システム,,, ,,,イ―１　データ交換における制約事項,,, ,,,,,, ,,,,・,A市には商店連合会が10か所程度存在する, ,,,,・,A市と各商店連合会との間でやり取りするデータ量は、一つの商店連合会当たり、多くても十数Mバイト, ,,,,,程度, ,,,,・,A市のWebサイト更新作業は、窓口業務との関係で平日の毎日15時から18時の間に行われる, ,,,,・,一方、各商店連合会で翌日の特売メニューや特産品の販売を検討するのは、早いところで10時から11, ,,,,,時の間ぐらいに行われるが、遅い商店連合会では15時30分から16時30分ぐらいの間となることが分か, ,,,,,っている, ,,,,・,A市のWebサイトにおいては、当日分の情報を前日の午後に反映しなければならないため、最も短い場, ,,,,,合で16時30分から18時の90分間にデータ交換とWebサイト更新を完了させなければならない, ,,,,・,A市と各商店連合会を接続する通信環境は十分な余裕があり、データ交換による負荷は大きなもので, ,,,,,はない, ,,,,・,一方、A市のWebサイトを管理するサーバは導入後10年が経過し、若干リソース不足の状況であり、特, ,,,,,にプロセッサの能力が限界に近くなっている, ,,,,・,予算の関係でサーバの増強は難しい, ,,,,,, ,,,イ―２　設計した情報システム,,, ,,,,,, ,,,,・,各商店連合会からは所定の様式で必要な情報をA市へ伝送してもらうこととする, ,,,,・,商店連合会からの情報は自動的に受信される, ,,,,・,A市では1日分の窓口業務の後処理として17時から一連のバッチ処理が実行される, ,,,,・,所定の様式を受け取った後、データチェックを行いWebサイトの更新をするバッチジョブを起動する, ,,,,・,サーバのプロセッサの能力が厳しいため、商店連合会用のWebサイトの更新は同時に多くの処理をす, ,,,,,ることが難しい, ,,,,・,商店連合会は10か所程度なので、当面はA市の職員が手作業でバッチジョブを起動しWebサイトの更新, ,,,,,をすることとする, ,,,,・,午前中から伝送してくる商店連合会の情報など15時の時点で届いている情報はすみやかに処理し、以, ,,,,,降随時処理を進める, ,,,,・,17時以降のWebサイトの更新ジョブを極力少なくする運用とする, ,,,,,, ,設問ウ,,,,, ,,,,,, ,,　設問ウには、問題文の次の部分が対応する。,,,, ,,,,,, ,,,設問ウ,,,設問アで述べた情報システムの構築において、データ交換に伴うどのような異常を想定し、情報シス ,,,,,,テムでどのような対応方法を用意したか。その対応が必要になる理由とともに、600字以上1200字以 ,,,,,,内で具体的に述べよ。 ,,,,,, ,,,　さらに、次のように、データ交換に伴う異常を想定して、情報システムでの対応方法を用意しておくことも重要,,, ,,,である。,,, ,,,,・,一部の受信予定データが届かない場合、その後の処理全体が滞ることを避けるために、事前の取り決, ,,,,,めに従って、後続処理を開始できるようにする。, ,,,,・,受注データの受信から加工までの処理を自動化する場合でも、受注数量が過去実績に比べて極端に, ,,,,,多いなどの業務上の異常データが発生したときには、処理を中断して人手による確認ができるようにす, ,,,,,る。, ,,,,,, ,,　例として次のような見出しとストーリーが考えられる。,,,, ,,,,,, ,,,ウ　想定したデータ交換に伴う異常、及び情報システムでの対応方法と対応が必要になる理由,,, ,,,ウ―１　想定したデータ交換に伴う異常,,, ,,,,,, ,,,,・,想定される異常は次の二点, ,,,,,・,通信回線の不具合などで更新情報が届かない ,,,,,・,伝送された情報の様式が適切でなく、そのままWebサイトに掲載できない ,,,,,, ,,,ウ―２　情報システムでの対応方法と対応が必要になる理由,,, ,,,,,, ,,,,・,異常が発生した場合、Webサイトの更新が行えないため、何らかの対処が必要, ,,,,・,想定される異常のどちらの場合でも、Webサイトを更新する翌日分のデータが存在しないことになる, ,,,,・,Webサイトを更新する情報の格納場所を商店連合会ごとに準備し、データチェックを行いWebサイトの更, ,,,,,新をするバッチジョブの中で情報が存在しない場合の別処理をスクリプトによって組み込む, ,,,,・,更新できない場合の対処方法として次の方法を準備し、各商店連合会に事前に選択してもらうこととす, ,,,,,る, ,,,,・,対処方法は、①Webサイトを更新せず、古い情報のまま掲載を継続する、②「本日分の情報がない」旨, ,,,,,の固定メッセージを準備しておき、Webサイトには固定メッセージを掲載する, ,,,,・,①、②いずれの方法も当日伝送される情報が欠落していても対応できるため、Webサイトの運営には影, ,,,,,響が出ないと考えられる, ,,,,,, ■解答,,,,,, ,,,,,, ,■設問ア,,,,, ,,,,,, ,,ア　対象の業務と対象の情報システムの概要、及びデータ交換を利用する目的,,,, ,,ア―１　対象の業務と対象の情報システムの概要,,,, ,,,,,, ,,,　私は、今回の情報システムの設計を請け負ったシステムインテグレータP社に所属するシステムアーキテク,,, ,,,トである。対象の業務は近畿圏内A市の市民向けの広報業務である。A市が提供する広報には、市政報告、,,, ,,,市内の医療情報、市主催のイベント情報、ごみ収集カレンダーなど、日常市民が利用する多くの情報が掲載さ,,, ,,,れている。A市では市域の振興を進める一つの手段として、市内に複数存在する商店連合会のイベント情報,,, ,,,などを広報に掲載することとなった。A市内には40年を超える歴史を有する商店連合会もあり、地元に根付い,,, ,,,た商店の集まりとして市民に親しまれている。市内には大手交通機関が運営するバス路線が充実しており、,,, ,,,別の地域に転居してもバスを利用してなじみのある商店へ買い物に出向く市民も多い。高齢者向けにはバス,,, ,,,運賃の補助制度があり半額でバスが利用できるようになっている。A市の広報はWebで市民に公開されており,,, ,,,、パソコンのほかスマートフォンやタブレットからも利用できる。,,, ,,,,,, ,,ア―２　データ交換を利用する目的,,,, ,,,,,, ,,,　多くの商店連合会では独自のWebサイトを立ち上げており、日替わりの特売メニューの情報や、特産品の販,,, ,,,売などの情報を掲載している。Webサイトを持たない商店連合会であっても、販売に関する情報を自前のサー,,, ,,,バで管理している。A市広報部は、市内の商店連合会の情報を一元で市民に提供できるよう、Webサイトを日,,, ,,,々更新することを検討している。各商店連合会も売り上げ拡大のよい機会と言うことで積極的に協力する旨の,,, ,,,同意が得られている。A市のWebサイトと商店連合会が管理する情報は別のシステムであり、データ交換によ,,, ,,,ってA市に集めることとした。,,, ,,,,,, ,■設問イ,,,,, ,,,,,, ,,イ　データ交換における制約事項、及び設計した情報システム,,,, ,,イ―１　データ交換における制約事項,,,, ,,,,,, ,,,　A市市内には商店連合会が10か所程度存在している。A市と各商店連合会との間でやり取りするデータ量は,,, ,,,、一つの商店連合会当たり、多くても十数Mバイト程度である。A市のWebサイト更新作業は、窓口業務との関,,, ,,,係で平日の毎日15時から18時からの間に行われる。一方、各商店連合会において、翌日の特売メニューや特,,, ,,,産品の販売を検討するのは、早いところで10時から11時の間ぐらいに行われ、遅い商店連合会では15時,,, ,,,30分から16時30分ぐらいの間となることが分かっている。,,, ,,,　A市のWebサイトにおいては、当日分の情報を前日の午後に反映しなければならないため、最も短い場合で,,, ,,,16時30分から18時の90分間にデータ交換とWebサイト更新を完了させなければならない。A市と各商店連合会,,, ,,,を接続する通信環境は十分な余裕があり、データ交換による負荷は大きなものではない。一方、A市のWebサ,,, ,,,イトを管理するサーバは導入後10年が経過し、若干リソース不足の状況で、特にプロセッサの能力が限界に,,, ,,,近くなっている。ただし、予算の関係でサーバの増強は難しい状況である。,,, ,,,,,, ,,イ―２　設計した情報システム,,,, ,,,,,, ,,,　各商店連合会からは所定の様式で必要な情報をA市へ伝送してもらう仕様とした。データ交換の処理をA市,,, ,,,側で常時起動しておくことにより、商店連合会からの情報は自動的に受信できる。A市では1日分の窓口業務,,, ,,,の後処理として17時から一連のバッチ処理を実行している。商店連合会から所定の様式を受け取った後、デ,,, ,,,ータチェックを行いWebサイトの更新をするバッチジョブを起動しなければならない。サーバのプロセッサの能,,, ,,,力が厳しいため、同時に多くの商店連合会用のWebサイトの更新処理をすることが難しい。商店連合会は10,,, ,,,か所程度なので、当面はA市の職員が手作業でバッチジョブを起動しWebサイトの更新をすることとする。午前,,, ,,,中から伝送してくる商店連合会の情報など15時の時点で届いている情報は速やかに処理して、以降随時処理,,, ,,,を進めることにより、17時以降のWebサイトの更新ジョブを極力少なくする運用とした。,,, ,,,,,, ,■設問ウ,,,,, ,,,,,, ,,ウ　想定したデータ交換に伴う異常、及び情報システムでの対応方法と対応が必要になる理由,,,, ,,ウ―１　想定したデータ交換に伴う異常,,,, ,,,,,, ,,,　想定される異常は次の2点が存在する。一点は通信回線の不具合など通信できないことに起因する更新情,,, ,,,報が届かないという異常、もう一点は伝送されたWebサイトを更新するための情報の様式が適切でなく、伝送,,, ,,,されたデータをそのままWebサイトに掲載できないという異常である。,,, ,,,,,, ,,ウ―２　情報システムでの対応方法と対応が必要になる理由,,,, ,,,,,, ,,,　想定した異常が発生した場合、Weｂサイトの更新が行えないため、何らかの対処が必要である。これらの異,,, ,,,常についてどちらが発生した場合であっても、Webサイトを更新するための翌日分のデータが存在しないこと,,, ,,,になる。私は、データが存在しない場合であっても何らかのアクションがとれるように、Webサイトを更新する情,,, ,,,報の格納場所を商店連合会ごとに準備し、データチェックを行いWebサイトの更新をするバッチジョブの中でW,,, ,,,ebサイトを更新するための情報が存在しない場合の別処理をスクリプトによって組み込むこととした。,,, ,,,更新できない場合の対処方法として次の方法を準備し、各商店連合会に事前に選択してもらうこととする。具,,, ,,,体的には、①Webサイトを更新しないで、古い情報のまま掲載を継続する方法、②当該商店連合会の情報とし,,, ,,,て「本日分の情報がない」旨の固定メッセージを準備しておき、Webサイトには固定メッセージを掲載するという,,, ,,,方法である。①、②いずれの方法も当日伝送される情報が欠落していてもバッチジョブで対応できるため、We,,, ,,,bサイトの運営には影響が出ないと考えられる。　以上,,, ,,,,,, 平成27年度　問1　システム方式設計について,,,,,, ,,,,,, ,　システムアーキテクトは、情報システムの開発で、ハードウェア、ソフトウェアおよび人手による作業をどのように組,,,,, ,み合わせてシステム要件を実現するかを総合的に検討し、システム方式を設計する。総合的な検討の視点としては,,,,, ,、業務プロセスへの効果、実現可能性などがある。業務プロセスへの効果としては、情報システムの稼働後の業務,,,,, ,の処理時間短縮、品質向上、運用コスト削減などがある。実現可能性の判断のためには、適用技術、開発コスト、開,,,,, ,発期間、セキュリティリスク、運用性、保守性などを考慮する。,,,,, ,　このようなシステム方式設計には、例えば次のようなものがある。,,,,, ,,・,業務の品質向上という要件を実現するために、業務上のミスが他の業務に大きな影響を与えるような重要な,,, ,,,作業は、すべてソフトウェア開発の対象に含めた。,,, ,,・,低コストでの業務の効率化という要件を実現するために、実施頻度が高い作業をソフトウェア開発の対象にし,,, ,,,、開発すると費用が掛かるが手作業で実施しても業務運用上大きな問題にならない作業は、人手で実施する,,, ,,,ことにした。,,, ,,・,開発期間を短くするために、外部との通信などの共通機能には、ソフトウェアパッケージを活用した。,,, ,　また、システム方式設計の結果は、利用者に説明しなければならない。そのため、情報システム稼働後の業務の,,,,, ,全体像を示して業務部門の役割分担を明確にしたり、業務担当者の利用するシステム機能を業務フローに明示して,,,,, ,情報システムの利用局面を示したりするなど、利用者の理解度を高める工夫をすることも必要である。,,,,, ,　あなたの経験と考えに基づいて、設問ア～ウに従って論述せよ。,,,,, ,,,,,, ,設問ア,,,あなたがシステム方式設計に携わった、対象の業務と情報システムの概要を、それぞれの特徴を含めて、,, ,,,,800字以内で述べよ。,, ,設問イ,,,設問アで述べた情報システムで、どのようなシステム要件を実現するために、どのようなシステム方式を設,, ,,,,計したか。業務プロセスへの効果、実現可能性などの決定理由を含めて、800字以上1600字以内で具体的,, ,,,,に述べよ。,, ,設問ウ,,,設問イで述べたシステム方式設計の結果を説明する際に実施した、利用者の理解度を高める工夫を、実,, ,,,,例を含めて、600字以上1200字以内で具体的に述べよ。,, ,,,,,, ■ポイント,,,,,, ,,,,,, ,■出題趣旨,,,,, ,,,,,, ,,　システム方式設計は、システム開発におけるシステムアーキテクトの重要な役割の一つである。システム方式,,,, ,,設計では、業務プロセスへの効果と実現可能性などを総合的に検討しなければならない。また、システム方式設,,,, ,,計の結果を利用者に説明し、理解してもらうことが必要であり、そのための工夫をすることも重要である。,,,, ,,　本問は、システム方式設計について、設計効果とその決定理由、利用者の理解度を高めるための工夫を具体,,,, ,,的に論述することを求めている。論述を通じて、システムアーキテクトに必要なシステム方式設計の能力と経験な,,,, ,,どを評価する。,,,, ,,,,,, ,■採点講評,,,,, ,,,,,, ,,　全問に共通して、設問に素直に答えている論述が多かった。また、問題文の引用で文字数を費やし、内容が薄,,,, ,,くなってしまっている論述も少なかった。一方で、問題文に記載してある観点などを抜き出し、一般論と組み合わ,,,, ,,せただけの論述は引き続き散見された。問題文に記載した観点や事例は、例示である。自らが実際にシステムア,,,, ,,ーキテクトとして、検討し取り組んだことを具体的に論述してほしい。,,,, ,,　問１（システム方式設計について）では、システム要件をハードウェア、ソフトウェアおよび人手による作業をどの,,,, ,,ように組み合わせて実現したかというシステム方式の設計結果を具体的に論述することを期待した。システム要,,,, ,,件をどのように実現したかについては多くの受験者が論述していた。しかし、システム方式そのものではなく、既,,,, ,,に設計されたシステム方式を前提としたソフトウェア方式やソフトウェアの機能設計に関する論述が散見された。,,,, ,,システムアーキテクトには、業務を情報システムの視点から整理する役割が求められることを認識してほしい。,,,, ,,,,,, ,■解説,,,,, ,,,,,, ,,　システム方式設計がテーマの問題である。情報システムの開発では、ハードウェア、ソフトウェア、及び人手に,,,, ,,よる作業を適切に組み合わせてシステム要件を実現する。システム要件を実現するためにはシステム方式の設,,,, ,,計が必要であり、システムアーキテクトには、業務プロセスへの効果、実現可能性などを視点として、ハードウェ,,,, ,,ア、ソフトウェア、及び人手による作業の組み合わせを、総合的に検討することが求められる。,,,, ,,　また、システムアーキテクトは、システム方式設計の結果を利用者に説明しなければならない。説明においては,,,, ,,、利用者の理解度を高める工夫をすることが重要になる。,,,, ,,,,,, ,,　設問アでは、「対象の業務とその特徴」、「情報システムの概要とその特徴」を記述する。記述する対象が業務,,,, ,,と情報システムの概要のみであり、システムアーキテクト試験における定番の要求事項なので、受験者の業務経,,,, ,,験に基づいて容易に記述できたと考えられる。後続の設問イでは情報システムによって実現する要件と具体的な,,,, ,,システム方式を記述するため、情報システムによって実現する要件に関連するような、業務とその特徴を記述し,,,, ,,ておくことが必要である。,,,, ,,　開発対象の情報システムの規模について記述上の制約となる事項はないが、システム方式設計がテーマとな,,,, ,,っているため、ある程度の規模を持つ情報システムを取り上げるほうが記述しやすかったと考えられる。,,,, ,,,,,, ,,　設問イでは、「設計したシステム方式」、「実現すべき要件」、「業務プロセスへの効果、実現可能性などの決定,,,, ,,理由」を記述する。システム方式として何を記述すればよいか迷うところであるが、問題文に3点例示されている,,,, ,,内容を参考にすることができる。示されている例のうち2点は実現すべき要件も含んでおり、要件の例としても活,,,, ,,用できる。具体的には、「業務の品質向上」という要件に対して、「業務上のミスが他の業務に大きな影響を与え,,,, ,,るような重要な作業は、全てソフトウェア開発の対象に含めた」、「低コストでの業務の効率化」という要件に対し,,,, ,,て、「実施頻度が高い作業をソフトウェア開発の対象とし、開発すると費用が掛かるが手作業で実施しても業務運,,,, ,,用上大きな問題にならない作業は、人手で実施することにした」という例が示されている。記述すべきシステム方,,,, ,,式、実現すべき要件をどの程度まで掘り下げて記述すべきであるかのガイドとしても活用できる。,,,, ,,,,,, ,,　設問ウでは、「利用者の理解度を高める工夫」を記述する。システムアーキテクトは、システム方式設計の結果,,,, ,,を利用者に説明しなければならない。説明する際には、利用者の立場にたって設計内容が理解できるようにする,,,, ,,必要がある。設問文には、「実例を含めて」と条件が付けられているので、図解したとか、専門用語の解説を加え,,,, ,,たなどの一般的な分かりやすくする工夫では不十分であったと考えられる。問題文には、「情報システム稼働後,,,, ,,の業務の全体像を示して業務部門の役割分担を明確にする」、「業務担当者の利用するシステム機能を業務フロ,,,, ,,ーに明示して情報システムの利用局面を示す」という例が示されているので、期待されている実例の説明として,,,, ,,参考にできる。この設問ウは要求事項が1点であるため、最低記述字数の600字を上回るように注意しながら書き,,,, ,,進める必要がある。,,,, ,,,,,, ■見出しとストーリー,,,,,, ,,,,,, ,■設問ア,,,,, ,,,,,, ,,設問ア,,,あなたがシステム方式設計に携わった、対象の業務と情報システムの概要を、それぞれの特徴を含め, ,,,,,て、800字以内で述べよ。, ,,,,,, ,,　設問アには、対応する問題文がない。自身の経験に基づき要求事項を記述する。,,,, ,,　見出しとストーリーの例を次に示す。,,,, ,,,,,, ,,,ア　対象の業務と特徴、情報システムの概要と特徴,,, ,,,ア―１　対象の業務と特徴,,, ,,,,,, ,,,,・,対象となる顧客は人材派遣会社のA社, ,,,,・,A社は、本社を東京に置き、大阪と名古屋に中核となる支店、その他全国の主要都市に営業拠点を持, ,,,,,つ, ,,,,・,A社に登録している人材は特定の業種に対応した人材ではなく、多くの業種・職種に対応している, ,,,,・,人材の派遣を希望する企業からの要求・条件が様々である, ,,,,・,業務の特徴は、要求・条件にマッチした人材を抽出するために、登録されている人材が持つ資格、経歴, ,,,,,、技能など非常に多くの属性項目を管理しなければならない点, ,,,,・,自身の立場は、今回のシステム方式設計を含め、構築を一括で受注したシステムインテグレータP社に, ,,,,,所属するシステムアーキテクト, ,,,,,, ,,,ア―２　情報システムの概要と特徴,,, ,,,,,, ,,,,・,構築する情報システムは、人材管理システム, ,,,,・,稼働中のサーバ機器の保守期限切れに伴い、Webシステムとして全面構築, ,,,,・,旧システムもWebシステムであったため、インタフェースは基本的に変更しない, ,,,,・,本社にサーバなどの中核機器とクライアントを設置し、支店や営業所にもクライアントを配置する, ,,,,・,データ量、性能面においては、刷新前のシステムにおいて問題は発生しておらず、今回構築するシステ, ,,,,,ムにおいても懸念事項ではない, ,,,,・,人材に関する多くの属性情報を管理することに加え、人材が登録時に入力する経歴や自己PRなどの定, ,,,,,性的な情報を管理している点が特徴, ,,,,・,今回のシステム方式の決定について、私が全体を取りまとめることになった, ,,,,,, ,■設問イ,,,,, ,,,,,, ,,設問イ,,,設問アで述べた情報システムで、どのようなシステム要件を実現するために、どのようなシステム方式, ,,,,,を設計したか。業務プロセスへの効果、実現可能性などの決定理由を含めて、800字以上1600字以内, ,,,,,で具体的に述べよ。, ,,,,,, ,,　設問イには、問題文の次の部分が対応する。,,,, ,,,,,, ,,,　システムアーキテクトは、情報システムの開発で、ハードウェア、ソフトウェアおよび人手による作業をどのよ,,, ,,,うに組み合わせてシステム要件を実現するのかを総合的に検討し、システム方式を設計する。総合的な検討,,, ,,,の視点としては、業務プロセスへの効果、実現可能性などがある。業務プロセスへの効果としては、情報シス,,, ,,,テムの稼働後の業務の処理時間短縮、品質向上、運用コスト削減などがある。実現可能性の判断のために,,, ,,,は、適用技術、開発コスト、開発期間、セキュリティリスク、運用性、保守性などを考慮する。,,, ,,,　このようなシステム方式設計には、例えば次のようなものがある。,,, ,,,,・,業務の品質向上という要件を実現するために、業務上のミスが他の業務に大きな影響を与えるような, ,,,,,重要な作業は、全てソフトウェア開発の対象に含めた。, ,,,,・,低コストでの業務の効率化という要件を実現するために、実施頻度が高い作業をソフトウェア開発の対, ,,,,,象にし、開発すると費用が掛かるが手作業で実施しても業務運用上大きな問題にならない作業は、人, ,,,,,手で実施することにした。, ,,,,・,開発期間を短くするために、外部との通信などの共通機能には、ソフトウェアパッケージを活用した。, ,,,,,, ,,　見出しとストーリーの例を次に示す。,,,, ,,,,,, ,,,イ　実現したシステム要件、設計したシステム方式、及び業務プロセスへの効果、実現可能性などの決定理由,,, ,,,イ―１　実現したシステム要件,,, ,,,,,, ,,,,・,業務要件は、「人材の派遣を要求する企業のニーズにマッチした人材を詳細に検索できること」として与, ,,,,,えられている, ,,,,・,派遣された要員のスキル不足に関するクレームが派遣先から寄せられている, ,,,,・,新しく追加された業務要件に「詳細な人材の検索」があり、人材を検索する専任者を本社に置き、定性, ,,,,,的な情報を踏まえて適切な人材を抽出することが想定されている, ,,,,・,実現するシステム要件は次の通り, ,,,,,, ,,,,（１）ソフトウェア要件,, ,,,,,, ,,,,,・,特定の基本ソフトウェアは指定しないが、ベンダのサポートが受けられること ,,,,,・,ユーザインタフェースは旧システムに準ずるが、使いやすさを考慮して変更しても良い ,,,,,・,現行の他システムとの連携は維持できること ,,,,,・,パッケージの適用は任意である ,,,,,, ,,,,（２）ハードウェア要件,, ,,,,,, ,,,,,・,旧システムと同等以上の性能・信頼性が確保されていること ,,,,,, ,,,,（３）ネットワーク要件,, ,,,,,, ,,,,,・,本社と支社及び営業時間のネットワークは二重化すること ,,,,,, ,,,イ―２　設計したシステム方式,,, ,,,,,, ,,,,・,旧システムで実現されていた、属性指定による汎用的な人材検索機能については、同等機能の実現と, ,,,,,いうことでソフトウェア開発の対象とする, ,,,,・,企業が派遣を希望する人材を定性的な情報から抽出することをシステムの機能として実現することは, ,,,,,難しいため、この部分は定性的な情報の検索機能を新たにシステムに持たせ、抽出結果は専任者が判, ,,,,,断し、最終的な人選に結び付ける, ,,,,・,人選の結果通知はシステム化せず、検索の依頼者にメールで通知する方式, ,,,,・,旧システムの機能を基本はそのまま実現するため、基本ソフトウェアの構成は変更しない, ,,,,,, ,,,イ―３　業務プロセスへの効果、実現可能性などの決定理由,,, ,,,,,, ,,,,（１）業務プロセスへの効果,, ,,,,,, ,,,,,・,抽出結果を専任者のノウハウを生かして最終的な人材の選択につなげられるため、企業のニーズ ,,,,,,にマッチした人材が派遣できるという品質の向上に大きく寄与できる ,,,,,・,定性的な情報の検索に、テキストデータを検索対象にできる汎用の簡易開発ツールを提供すること ,,,,,,によって、専任者の判断作業を効率化できる ,,,,,, ,,,,（２）実現可能性の検討,, ,,,,,, ,,,,,・,旧システムとソフトウェア的に同等の構成で構築するため、顧客要望の限られた6カ月という期間で ,,,,,,十分構築可能 ,,,,,・,専任者はIT環境に明るいため、本番前の教育・訓練を通じて簡易開発ツールを十分活用できるよう ,,,,,,になる ,,,,,, ,■設問ウ,,,,, ,,,,,, ,,設問ウ,,,設問イで述べたシステム方式設計の結果を説明する際に実施した、利用者の理解度を高める工夫を、, ,,,,,実例を含めて、600字以上1200字以内で具体的に述べよ。, ,,,,,, ,,　設問ウには、問題文の次の部分が対応する。,,,, ,,,,,, ,,,　また、システム方式設計の結果は、利用者に説明しなければならない。そのため、情報システム稼働後の業,,, ,,,務の全体像を示して業務部門の役割分担を明確にしたり、業務担当者の利用するシステム機能を業務フロー,,, ,,,に明示して情報システムの利用局面を示したりするなど、利用者の理解度を高める工夫をすることも必要であ,,, ,,,る。,,, ,,,,,, ,,　見出しとストーリーの例を次に示す。,,,, ,,,,,, ,,,ウ　システム方式設計の結果説明において利用者の理解度を高める工夫と説明で使用した実例,,, ,,,ウ―１　システム方式設計の結果説明において利用者の理解度を高める工夫,,, ,,,,,, ,,,,・,旧システムと基本的には同じ機能を提供するため、新たな業務タスクを担う本社の専任者にフォーカス, ,,,,,を当てた説明を実施, ,,,,・,専任者に対して、あらかじめ詳細な検索の条件をヒアリングし、簡易開発ツールを活用し検索結果が得, ,,,,,られるようにしておく, ,,,,・,専任者に対して説明会を開催する, ,,,,・,専任者へは、①検索の具体的な手順、②簡易開発ツールの使い方の2回に分けて説明会を実施し、混, ,,,,,乱を防止する, ,,,,・,検索の具体的な手順については、従来の機能とのハンドリングを含めた詳細な手順書を作成し、具体, ,,,,,的に操作をしていただく, ,,,,・,簡易開発ツールの使い方については、簡易開発ツールを提供するベンダの講習会に参加していただく, ,,,,・,簡易開発ツールの基本を習得した上で、新システムにおける操作に関する点を中心に質疑応答を行う, ,,,,,, ,,,ウ―２　説明で使用した実例,,, ,,,,,, ,,,,・,P氏の社内で実際に行われた派遣社員の要求の実例を使用, ,,,,・,「COBOLのプログラミング経験を有する」という条件で、「プログラミング経験」の属性から該当する人材, ,,,,,を抽出, ,,,,・,抽出された人材について、経験の部分の度合いを業務経歴や自己PRのテキスト部分から抽出した情, ,,,,,報の一覧を付加した結果を提示, ,,,,,, ■解答,,,,,, ,,,,,, ,ア　対象の業務と特徴、情報システムの概要と特徴,,,,, ,ア―１　対象の業務と特徴,,,,, ,,,,,, ,,　私は、今回のシステム方式設計を含め、構築を一括で受注したシステムインテグレータP社に所属するシステム,,,, ,,アーキテクトである。私がシステム方式設計に携わった顧客は、人材派遣会社のA社である。A社は、本社を東京,,,, ,,に置き、大阪と名古屋に中核となる支店、その他全国の主要都市に営業拠点を持っている。A社に登録している,,,, ,,人材は特定の業種に対応した人材ではなく、多くの業種・職種を希望する人材がA社に登録している。当然、人材,,,, ,,の派遣を希望する企業からの要求・条件が様々となっている。,,,, ,,　業務の特徴は、要求・条件にマッチした人材を抽出するために、登録されている人材が持つ資格、経歴、技能,,,, ,,など非常に多くの属性項目を管理しなければならない点である。,,,, ,,,,,, ,ア―２　情報システムの概要と特徴,,,,, ,,,,,, ,,　今回構築する情報システムは、人材管理システムである。現行のシステムで稼働中のサーバ機器の保守期限,,,, ,,切れに伴い、Webシステムとして全面再構築することとなった。旧システムもWebシステムとして構築しているため,,,, ,,、インタフェースは基本的に変更しない方針である。システム構成としては、本社にサーバなどの中核機器とクラ,,,, ,,イアントを設置し、支店や営業所にもクライアントを配置する。データ量、性能面については、刷新前のシステムに,,,, ,,おいて問題はなく、新システムにおいても同等の規模で構築する。,,,, ,,　人材に関する多くの属性情報を管理することに加え、人材が登録時に入力する経歴や自己PRなどの定性的な,,,, ,,情報を管理している点が特徴である。,,,, ,,　今回のシステム方式の決定について、私が全体を取りまとめることになった。,,,, ,,,,,, ,イ　実現したシステム要件、設計したシステム方式、及び業務プロセスへの効果、実現可能性などの決定理由,,,,, ,イ―１　実現したシステム要件,,,,, ,,,,,, ,,　今回のシステム開発において基本的な業務要件は「人材の派遣を要求する企業のニーズにマッチした人材を,,,, ,,詳細に検索できること」としてA社から与えられている。新しく実現する業務要件として、「詳細な人材の検索」が加,,,, ,,わっている。人材不足という環境下において、顧客から「派遣された要員が適切なスキルを有していない」というク,,,, ,,レームが寄せられることが多く、競合他社に派遣元を切り替えられる事態も発生している。A社が考えている「詳,,,, ,,細な人材の検索」とは、人材を検索する専任者を本社に置き、定性的な情報を踏まえて適切な人材を抽出するこ,,,, ,,とである。検討の結果、実現するシステム要件は次のようになった。,,,, ,,,,,, ,,（１）ソフトウェア要件,,,, ,,,,,, ,,,・,ベンダのサポートが受けられれば、基本ソフトウェアは指定しない。,, ,,,・,ユーザインタフェースは旧システムに準ずるが、使いやすさを考慮して変更しても良い。,, ,,,・,現行の他システムとの連携は維持できること。,, ,,,・,パッケージの適用は任意である。,, ,,,,,, ,,（２）ハードウェア要件,,,, ,,,,,, ,,,・,旧システムと同等以上の性能・信頼性を確保する。,, ,,,,,, ,,（３）ネットワーク要件,,,, ,,,,,, ,,,・,拠点間のネットワークは二重化する。,, ,,,,,, ,イ―２　設計したシステム方式,,,,, ,,,,,, ,,　旧システムで実現されていた、属性指定による汎用的な人材検索機能については、同等機能の実現ということ,,,, ,,でソフトウェア開発の対象とする。,,,, ,,　企業が派遣を希望する人材を定性的な情報から抽出することをシステムの機能として実現することは難しいた,,,, ,,め、定性的な情報から抽出する部分は定性的な情報の検索機能を新たにシステムに持たせ、抽出結果は専任,,,, ,,者が判断し、最終的な人選に結び付けることとする。人選の結果通知はシステム化せず、手作業で検索の依頼,,,, ,,者にメールで通知する方式とする。,,,, ,,,,,, ,イ―３　業務プロセスへの効果、実現可能性などの決定理由,,,,, ,,,,,, ,,　今回のシステム方式設計に当たり、検討した業務プロセスへの効果、実現可能性は次の通りである。,,,, ,,,,,, ,,（１）業務プロセスへの効果,,,, ,,,,,, ,,,　抽出結果を専任者のノウハウを生かして最終的な人材の選択につなげることが可能なため、企業のニーズ,,, ,,,にマッチした人材が派遣できるという品質の向上に大きく寄与できると考えられる。,,, ,,,　定性的な情報の検索に、テキストデータを検索対象にできる汎用の簡易開発ツールを提供することによって,,, ,,,、専任者の判断作業を効率化できる。,,, ,,,,,, ,,（２）実現可能性の検討,,,, ,,,,,, ,,,　旧システムとソフトウェア的に同等の構成で構築するため、顧客要望の限られた6カ月という期間で十分構,,, ,,,築可能である。,,, ,,,　専任者はIT環境に明るいため、本番前の教育・訓練を通じて簡易開発ツールを十分活用できるようになると,,, ,,,考えられる。,,, ,,,,,, ,ウ　システム方式設計の結果説明において利用者の理解度を高める工夫と説明で使用した実例,,,,, ,ウ―１　システム方式設計の結果説明において利用者の理解度を高める工夫,,,,, ,,,,,, ,,　新しいシステムでは、旧システムと基本的には同じ機能を提供するため、私は新たな業務タスクを担う本社の,,,, ,,専任者にフォーカスを当てた説明を実施することとした。説明を効率よく、かつ効果的に実施するため、専任者に,,,, ,,対して、業務で必要となる可能性のある詳細な検索の条件をあらかじめヒアリングした。ヒアリング結果を基に、,,,, ,,簡易開発ツールを活用した検索結果が得られるようにしておき、説明会を開催した。,,,, ,,　新しい業務要件となるため、①検索の具体的な手順、②簡易開発ツールの使い方の2回に分けて専任者へ説,,,, ,,明会を開催し、混乱を防止することに努めた。,,,, ,,　検索の具体的な手順については、従来の機能とのハンドリングを含めた詳細な手順書を作成し、デモ環境にお,,,, ,,ける具体的な操作によって新しいシステム方式を理解していただいた。簡易開発ツールの使い方については、簡,,,, ,,易開発ツールを提供するベンダの講演会に参加して簡易開発ツールの基本を習得して頂いた上で、新システム,,,, ,,における操作に関する点を中心に質疑応答を行った。,,,, ,,,,,, ,ウ―２　説明で使用した実例,,,,, ,,,,,, ,,　私は説明において、具体的な実例を用いることで一層の理解が深まると考え、自社において派遣社員の要求を,,,, ,,した実例として使用することとした。具体的には、「COBOLのプログラミング経験を有する」という条件で、「プログ,,,, ,,ラミング経験」というあいまいさを属性から該当する人材を抽出する検索である。,,,, ,,　抽出された人材について、経験の部分の度合いを業務経歴や自己PRのテキスト部分から抽出した情報の一覧,,,, ,,を付加した結果を提示することによって、専任者に業務機能を実現するシステム方式を実感いただけたと考えて,,,, ,,いる。　以上,,,, ,,,,,, 平成27年度　問2　業務の課題に対応するための業務機能の変更又は追加,,,,,, ,,,,,, ,　システムアーキテクトは、業務の課題に対応するために、情報システムの業務機能を変更したり追加したりする。,,,,, ,　例えば、通信販売業で、受注量や納品場所などの変更を出荷指示直前まで受付、受注当日中に出荷したいという,,,,, ,業務の課題に対応するためには、次のような業務機能の変更又は追加が必要となる。,,,,, ,,・,翌日以降分だけが可能であった受注内容の変更を、出荷指示直前まで受け付け、変更内容を作業計画や作,,, ,,,業指示に反映する。そのため、受注から出荷指示までの既存の各業務機能を、日次起動方式から随時起動,,, ,,,方式に変更する。,,, ,,・,出荷作業時間を短縮するために、既存の出荷指示機能に、出荷作業者の倉庫内の移動距離が最短となるピ,,, ,,,ッキング順序を指示する機能を追加する。,,, ,　このような業務機能の変更又は追加では、既存機能の活用や既存の情報システムへの影響の最小化のために、,,,,, ,例えば次のような工夫をすることも重要である。,,,,, ,,・,既存の出荷指示のロジック部分をそのまま利用し、処理方式を随時起動方式に変更することで、受注内容が,,, ,,,変更される都度、出荷指示内容に反映できるようにする。,,, ,,・,出荷機能に影響を与えないよう、ピッキング順序を最適化する機能を新たに開発し、既存の情報システムから,,, ,,,利用する方式にする。,,, ,　あなたの経験と考えに基づいて、設問ア～ウに従って論述せよ。,,,,, ,,,,,, ,設問ア,,,あなたが携わった情報システムにおいて、業務機能の変更又は追加を必要とするような業務の課題はど,, ,,,,のようなものであったか。対象となった情報システムの概要、及び業務の概要とともに、800字以内で述べ,, ,,,,よ。,, ,設問イ,,,設問アで述べた業務の課題に対応するために、どのような業務機能の変更又は追加が必要となったか。,, ,,,,業務の課題に対応できると考えた理由とともに、800字以上1600字以内で具体的に述べよ。,, ,設問ウ,,,設問イで述べた業務機能の変更又は追加の際、既存機能の活用や既存の情報システムへの影響の最小,, ,,,,化のために、どのような工夫をしたか、600字以上1200字以内で具体的に述べよ。,, ,,,,,, ■ポイント,,,,,, ,,,,,, ,■出題趣旨,,,,, ,,,,,, ,,　システムアーキテクトは、業務の課題に対応するために、情報システムの業務機能を変更したり追加したりする,,,, ,,。このような業務機能の変更又は追加では、既存機能の活用及び既存の情報システムへの影響を最小限に抑え,,,, ,,るための工夫をする。,,,, ,,　本問は、システムアーキテクトが業務の課題に対応するために必要となった業務機能とそれが必要となった理,,,, ,,由、それに対応するために情報システムを変更したり追加したりした内容とその工夫について、具体的に論述す,,,, ,,ることを求めている。論述を通じて、システムアーキテクトに必要な情報システムの業務機能の変更又は追加に,,,, ,,関する能力を評価する。,,,, ,,,,,, ,■採点講評,,,,, ,,,,,, ,,　全問に共通して、設問に素直に答えている論述が多かった。また、問題文の引用で文字数を費やし、内容が薄,,,, ,,くなってしまっている論述も少なかった。一方で、問題文に記載してある観点などを抜き出し、一般論と組み合わ,,,, ,,せただけの論述は引き続き散見された。問題文に記載した観点や事例は、例示である。自らが実際にシステムア,,,, ,,ーキテクトとして、検討し取り組んだことを具体的に論述してほしい。,,,, ,,　問2（業務の課題に対応するための業務機能の変更又は追加について）では、業務課題とその解決のために必,,,, ,,要になった情報システムの業務機能の変更又は追加の内容を、具体的に論述することを期待した。情報システ,,,, ,,ムの変更又は追加の内容については具体的に論述されているものが多かった。しかし、情報システムの変更が,,,, ,,業務にどのような効果をもたらすかまでは言及していないなど、業務の課題を認識できていないと思われる論述,,,, ,,が散見された。システムアーキテクトには、対象業務や業務目的を正しく理解し、情報システム開発に反映する,,,, ,,能力が求められることを認識してほしい。,,,, ,,,,,, ,　業務の課題に対応するために、情報システムの業務機能を変更・追加することがテーマの問題である。例えば、翌,,,,, ,日出荷を当日出荷に変更する、法人に加え個人も顧客に追加する、会員向けサービスの一部を非会員にも提供す,,,,, ,るなどの業務課題に対応するためには、受注から出荷指示までの業務機能の変更、個人顧客に特有の属性の管理,,,,, ,機能の追加、会員と非会員を識別してサービスの使用可否を判断する機能の追加などが必要となる。システムアー,,,,, ,キテクトには、変更・追加する情報システムの業務機能によって、業務の課題に的確に対応できることを判断できる,,,,, ,能力が要求される。,,,,, ,,,,,, ,　設問アでは、「業務の概要」、「情報システムの概要」、「業務機能の変更又は追加を必要とする業務の課題」を記,,,,, ,述する。「業務の概要」、「情報システムの概要」は、システムアーキテクト試験の設問アにおける定番の要求事項で,,,,, ,あり、受験者の経験を棚卸するなど、試験の準備をしておけば容易に記述できると考えられる。「業務機能の変更又,,,,, ,は追加を必要とする業務の課題」については、課題の大小は問われておらず、どのような業務の課題であっても取り,,,,, ,上げることができる。ただし、後続の設問イで記述する情報システムの業務機能の変更・追加の内容と齟齬が生じな,,,,, ,いようにしなければならない。情報システムの業務機能の変更・追加によって業務の課題に対応するため、運用によ,,,,, ,って対応できるような業務の課題は適切ではない。,,,,, ,,,,,, ,　設問イでは、「情報システムの業務機能の変更又は追加の内容」、「変更又は追加した情報システムの業務機能,,,,, ,が業務の課題に対応できると考えた理由」を記述する。問題文には、「受注量や納品場所などの変更を出荷直前ま,,,,, ,で受け付け、受注当日中に出荷したい」という業務の課題の例が示されている。示された業務の課題に対応するた,,,,, ,めの業務機能の変更又は追加についての例が、「受注から出荷指示までの既存の各業務機能を、日次起動方式か,,,,, ,ら随時起動方式に変更する」、「既存の出荷指示機能に、出荷作業者の倉庫内の移動距離が最短となるピッキング,,,,, ,順序を指示する機能を追加する」となっている。一つの課題に対して、複数の業務機能を変更又は追加する例であ,,,,, ,る。変更・追加する業務機能は複数である必要はないが、設問イの要求事項が「情報システムの業務機能変更又は,,,,, ,追加の内容」、「変更又は追加した情報システムの業務機能が業務の課題に対応できると考えた理由」の2点だけで,,,,, ,あるため、設問イの最低字数800字を超えるように注意して記述したい。問題文には「変更又は追加した情報システ,,,,, ,ムの業務機能が業務の課題に対応できると考えた理由」についての例がないため、追加または変更した情報システ,,,,, ,ムの業務機能の記述だけではなく、業務の課題に対応できると考えた理由の明確な記述を忘れないようにしなけれ,,,,, ,ばならない。,,,,, ,,,,,, ,　設問ウでは、「既存機能の活用や既存の情報システムへの影響の最小化のための工夫点」を記述する。見かけ上,,,,, ,要求事項は一つであるが、「既存機能の活用における工夫点」と「既存の情報システムへの影響の最小化のための,,,,, ,工夫点」に分けて記述できる。問題文の例では「既存の出荷指示のロジック部分をそのまま利用し、処理方式を随時,,,,, ,起動方式に変更する」が示されている。工夫点はこの程度を記述すればよいことが分かる。設問イと同様に記述量,,,,, ,があまり多くならないと予想されるため、設問ウの最低字数600字を超えるように記述を進めてほしい。,,,,, ,,,,,, ■見出しとストーリー,,,,,, ,,,,,, ,■設問ア,,,,, ,,,,,, ,,設問ア,,,あなたが携わった情報システムにおいて、業務機能の変更又は追加を必要とするような業務の課題は, ,,,,,どのようなものであったか。対象となった情報システムの概要、および業務の概要とともに、800字以内, ,,,,,で述べよ。, ,,,,,, ,,,　システムアーキテクトは、業務の課題に対応するために、情報システムの業務機能を変更したり追加したり,,, ,,,する。,,, ,,,　例えば、通信販売業で、受注量や納品場所などの変更を出荷指示直前まで受け付け、受注当日に出荷した,,, ,,,いという業務の課題に対応するためには、次のような業務機能の変更又は追加が必要となる。,,, ,,,,,, ,,　例として次のような見出しとストーリーが考えられる。,,,, ,,,,,, ,,,ア　業務の概要、情報システムの概要、及び業務機能の変更又は追加を必要とする業務の課題,,, ,,,ア―１　業務の概要,,, ,,,,,, ,,,,・,顧客は、中古PCの販売、レンタル業を営むA社, ,,,,・,A社は都区内に3店舗を展開, ,,,,・,販売用、レンタル用のPCについて、業者からの入手ルート以外に、個人からの買い取りも行う, ,,,,・,PCは都区内に1か所ある物流倉庫に保管し、倉庫にはA社社員の保守部隊が在勤, ,,,,・,PCの基本ソフトウェアやブラウザの更新頻度が高く、アプリケーションの動作環境として古い基本ソフト, ,,,,,ウェアを搭載した中古PCもニーズあり, ,,,,・,販売やレンタルは倉庫から出庫、レンタルPCの返却も倉庫, ,,,,・,自身の立場は、業務機能の変更又は追加をとりまとめたシステムインテグレータP社に所属するシステ, ,,,,,ムアーキテクト, ,,,,,, ,,,ア―２　情報システムの概要,,, ,,,,,, ,,,,・,現状のPC管理システムを使用して、販売、レンタルの業務処理を行う, ,,,,・,システムの構成は、各店舗と倉庫にクライアント数台、サーバは本店内に設置, ,,,,・,性能、リソース面で問題は生じておらず、業務機能の変更又は追加に際してハードウェアと基本ソフトウ, ,,,,,ェアの変更は不要, ,,,,,, ,,,ア―３　業務機能の変更又は追加を必要とする業務の課題,,, ,,,,,, ,,,,・,通常使用するPCとしてノート型PCが普及したことに伴い、個人の利用者から、中古でも人気のあるPC, ,,,,,を購入する場合は、店頭で実物を見て判断したいというニーズに応える, ,,,,・,現在は前日までに予約して翌日朝に発送という業務フローであるが、緊急に必要なときは店頭で当日, ,,,,,に申し込み・借用をしたいというニーズに応える, ,,,,・,人気機種は数十台の単位で保有しており、店舗にも一部のPCを置くこととする, ,,,,,, ,■設問イ,,,,, ,,,,,, ,,　設問イには、問題文の次の部分が対応する。,,,, ,,,,,, ,,,設問イ,,,設問アで述べた業務の課題に対応するために、どのような業務機能の変更又は追加が必要となっ ,,,,,,たか。業務の課題に対応できると考えた理由とともに、800字以上1600字以内で具体的に述べよ。 ,,,,,, ,,,　例えば、通信販売業で、受注量や納品場所などの変更を出荷指示直前まで受け付け、受注当日中に出荷し,,, ,,,たいという業務の課題に対応するためには、次のような業務機能の変更又は追加が必要となる。,,, ,,,,・,翌日以降分だけが可能であった受注内容の変更を、出荷指示直前まで受け付け、変更内容を作業計, ,,,,,画や作業指示に反映する。そのため、受注から出荷指示までの既存の各業務機能を、日次起動方式, ,,,,,から随時起動方式に変更する。, ,,,,・,出荷作業時間を短縮するために、既存の出荷指示機能に、出荷作業者の倉庫内の移動距離が最短と, ,,,,,なるピッキング順序を指示する機能を追加する。, ,,,,,, ,,　例として次のような見出しとストーリーが考えられる。,,,, ,,,,,, ,,,イ　情報システムの業務機能の変更又は追加の内容、及び変更又は追加した情報システムの業務機能が業,,, ,,,務の課題に対応できると考えた理由,,, ,,,イ―１　情報システムの業務機能の変更又は追加の内容,,, ,,,,,, ,,,,　業務の課題に対応するために必要となる業務機能は以下の通り。,, ,,,,,, ,,,,（１）店頭貸出に対応する機能,, ,,,,,, ,,,,,・,既存の倉庫の在庫管理機能に「店舗在庫」を管理する機能を追加することで対応する ,,,,,・,貸出予約画面に、「貸出場所」を追加する ,,,,,・,A社からの要件として、店舗から貸し出したPCは同じ店舗に返却する業務運用ルールを追加する ,,,,,, ,,,,（２）店頭販売に対応する機能,, ,,,,,, ,,,,,・,店頭販売はWebから申し込んだ翌日以降とする ,,,,,・,店頭販売PCを倉庫から出庫する場合、既存のレンタルPCの送付先を店舗として出庫指示を出す ,,,,,・,店頭販売が成立しなかったPCについては、当該店舗にて一定期間保管する ,,,,,・,店舗の保管スペースには限りがあるため、店舗から倉庫への移送指示を出す機能を追加する ,,,,,・,店舗から倉庫への移送は、不定期に随時実行するため、処理の自動化は不要 ,,,,,・,倉庫から店舗へ移送したPCの戻し処理を倉庫側からも起動できるものとする ,,,,,・,移送の途上PCは店舗から出庫済の扱いとし、倉庫に到着した時点で倉庫在庫とする ,,,,,, ,,,イ―２　変更又は追加した情報システムの業務機能が業務の課題に対応できると考えた理由,,, ,,,,,, ,,,,（１）当日貸出に対応する機能,, ,,,,,, ,,,,,・,店舗在庫のみが当日貸出の対象となり、利用者が当日貸出という条件で検索するときに店舗在庫 ,,,,,,を検索対象とすることで実現できる ,,,,,・,店舗へ返却された日にPCのチェックなどを行うため、同日に同じPCを貸し出すことはなく、PCが動作 ,,,,,,しないなどのトラブルが生じることはない ,,,,,, ,,,,（２）店頭販売に対応する機能,, ,,,,,, ,,,,,・,夜に倉庫から出庫すれば、翌日朝には店舗にPCが到着するため、Webから申し込んだ翌日以降で ,,,,,,あれば、店舗にて欠品になることなく販売が可能である ,,,,,・,店舗に返却されたPCを販売する場合、返却日の翌日以降の店頭販売申し込みとなるため、万が一 ,,,,,,返却PCに不良が発生しても倉庫から補充することによって、店舗にて欠品が生じることなく販売が可 ,,,,,,能である ,,,,,, ,■設問ウ,,,,, ,,,,,, ,,　設問ウには、問題文の次の部分が対応する。,,,, ,,,,,, ,,,設問ウ,,,設問イで述べた業務機能の変更又は追加の際、既存機能の活用や既存の情報システムへの影響 ,,,,,,の最小化のために、どのような工夫をしたか、600字以上1200字以内で具体的に述べよ。 ,,,,,, ,,,　このような業務機能の変更又は追加では、既存機能の活用や既存の情報システムへの影響の最小化のた,,, ,,,めに、例えば次のような工夫をすることも重要である。,,, ,,,,・,既存の出荷指示のロジック部分をそのまま利用し、処理方式を随時起動方式に変更することで、受注, ,,,,,内容が変更される都度、出荷指示内容に反映できるようにする。, ,,,,・,出荷機能に影響を与えないよう、ピッキング順序を最適化する機能を新たに開発し、既存の情報システ, ,,,,,ムから利用する方式にする。, ,,,,,, ,,　例として次のような見出しとストーリーが考えられる。,,,, ,,,,,, ,,,ウ　既存機能の活用や既存の情報システムへの影響の最小化のための工夫点,,, ,,,,,, ,,,,（１）既存機能の活用について,, ,,,,,, ,,,,,・,倉庫から店舗への出庫については、既存の出庫機能について、一般顧客における貸出先（PCの送 ,,,,,,付先）を店舗にすることで既存機能がそのまま利用できる ,,,,,, ,,,,（２）既存の情報システムへの影響の最小化について,, ,,,,,, ,,,,,・,既存の在庫検索画面に「貸出場所」を選択するリストボックスを付加するだけで実現できる ,,,,,・,在庫場所の属性をデータベースに追加し、各PCの在庫場所を各店舗、倉庫として把握できるように ,,,,,,する ,,,,,・,既存のプログラムは、ビューを活用すれば変更不要である ,,,,,・,当日貸出の案件については、在庫場所が指定された店舗の在庫だけが検索されるようSQLを修正 ,,,,,,するだけで実現できる ,,,,,・,店舗から倉庫へ移送する業務機能は、新規に追加し、店舗、倉庫の両方から利用できるようにする ,,,,,, ■解答,,,,,, ,,,,,, ,ア　業務の概要、情報システムの概要、及び業務機能の変更又は追加を必要とする業務の課題,,,,, ,ア―１　業務の概要,,,,, ,,,,,, ,,　私は、今回の業務機能の変更又は追加を取りまとめたシステムインテグレータP社に所属するシステムアーキ,,,, ,,テクトである。対象となる顧客は、中古PCの販売・レンタル業を営むA社である。A社は都区内に3店舗を展開して,,,, ,,おり、販売用・レンタル用のPCは都区内に1か所ある物流倉庫に保管し、倉庫にはA社社員の保守部隊が在勤し,,,, ,,ている。PCの基本ソフトウェアやブラウザの更新頻度が高く、アプリケーションの動作環境として古い基本ソフトウ,,,, ,,ェアを搭載した中古PCも十分ニーズがある。販売したPCの出庫、レンタルPCの入出庫は全て倉庫から行われる,,,, ,,。,,,, ,,,,,, ,ア―２　情報システムの概要,,,,, ,,,,,, ,,　PC管理システムを使用して、販売、レンタルの業務処理を行っている。システムの構成は、クライアントは各店,,,, ,,舗と倉庫に、サーバは本店内に設置している。PC管理システムは、性能、リソースは十分で、業務機能の変更又,,,, ,,は追加に際してハードウェアと基本ソフトウェアの変更は不要である。,,,, ,,,,,, ,ア―３　業務機能の変更又は追加を必要とする業務の課題,,,,, ,,,,,, ,,　通常使用するPCとしてノート型PCが普及したことに伴い、個人の利用者から、中古でも人気のあるPCを購入す,,,, ,,る場合は、店頭で実物を見て判断してもらうというニーズに応える必要があった。レンタルPCについて、現在は前,,,, ,,日までに予約して翌日朝に発送という業務フローであるが、緊急に必要なときは店頭で当日に申し込み・借用を,,,, ,,したいというニーズもある。A社では、人気機種は数十台の単位で保有しており、店舗にも一部のPCを置くことは,,,, ,,可能である。,,,, ,,,,,, ,イ　情報システムの業務機能の変更又は追加の内容、及び変更又は追加した情報システムの業務機能が業務の,,,,, ,課題に対応できると考えた理由,,,,, ,イ―１　情報システムの業務機能の変更又は追加の内容,,,,, ,,,,,, ,,　業務の課題に対応するために必要となる業務機能は以下の通りである。,,,, ,,,,,, ,,（１）店頭貸出に対応する機能,,,, ,,,,,, ,,,　既存の倉庫の在庫管理機能に「店舗在庫」を管理する機能の追加が必要である。ユーザインタフェースとし,,, ,,,て現状の貸出予約画面に、「貸出場所」を追加することで実現できる。A社にヒアリングした結果、店舗から貸,,, ,,,し出したPCは、PCの運用管理上、同じ店舗に返却する業務運用ルールで対応することになった。,,, ,,,,,, ,,（２）店頭販売に対応する機能,,,, ,,,,,, ,,,　店頭販売は、Webから申し込んだ翌日以降に販売することでA社の要望を確認している。店頭販売するPCを,,, ,,,倉庫から出庫する場合、既存のレンタルPCの送付先を店舗として出庫指示を出すことで対応する。顧客が実,,, ,,,物を見て、店頭販売が成立しなかったPCについては、当該店舗にて一定期間保管する。店舗の保管スペー,,, ,,,スには限りがあるため、店舗から倉庫への移送指示を出す機能が必要である。店舗から倉庫への移送は、不,,, ,,,定期に行うことをA社に確認済で、処理の自動化は不要で、PCの移送処理は倉庫側から出庫済の扱いとし、,,, ,,,倉庫に到着した時点で倉庫在庫とする。,,, ,,,,,, ,イ―２　変更又は追加した情報システムの業務機能が業務の課題に対応できると考えた理由,,,,, ,,,,,, ,,（１）当日貸出に対応する機能,,,, ,,,,,, ,,,　店舗在庫のみが当日貸出の対象となるため、当日貸出を希望する利用者が、当日貸出という条件で検索す,,, ,,,るときに店舗在庫を検索対象とすることで実現できる。店舗へ返却された日の顧客受け付け業務終了後にPC,,, ,,,のチェックを行い、店舗在庫として登録するため、返却日に同じPCを貸し出すことはなく、「PCが動作しない」,,, ,,,などのトラブルが生じることはない。,,, ,,,,,, ,,（２）店頭販売に対応する機能,,,, ,,,,,, ,,,　夜に倉庫から出庫すれば、翌日朝には店舗にPCが到着するため、Webから申し込んだ翌日以降であれば、,,, ,,,店舗にて欠品になることなく販売が可能である。店舗に返却されたPCを販売する場合、返却日の翌日以降の,,, ,,,店頭販売申し込みとなるため、万が一返却PCに不良が発生しても倉庫から補充することによって、店舗にて,,, ,,,欠品が生じることなく販売が可能である。,,, ,,,,,, ,ウ　既存機能の活用や既存の情報システムへの影響の最小化のための工夫点,,,,, ,,,,,, ,,（１）既存機能の活用について,,,, ,,,,,, ,,,　私は、倉庫から店舗への出庫業務に対応することについては、既存の出庫機能をそのまま活用できると考,,, ,,,えている。一般顧客における貸出先（PCの送付先）をA社の各店舗にすることで実現可能である。具体的には,,, ,,,、データベースで管理している顧客情報として、既存機能と同様の属性でA社の3店舗の情報をデータベース,,, ,,,に登録することにより対応できる。,,, ,,,,,, ,,（２）既存の情報システムへの影響の最小化について,,,, ,,,,,, ,,,　私は、既存の情報システムへの影響を最小にするために、次のように検討した。利用者がPCの在庫を検索,,, ,,,する場合のユーザインタフェースとして、既存の在庫検索画面に「貸出場所」を選択するリストボックスを付加,,, ,,,するだけで実現できると考えられる。現在は倉庫に一元管理されているため、倉庫内の保管場所の情報は保,,, ,,,持されているが、「倉庫に保管している」という情報は保持されていない。店舗に在庫しているPCを管理できる,,, ,,,ようにするために、在庫場所の属性を新たにデータベースに追加し、各PCの在庫場所を各店舗、倉庫として,,, ,,,把握できるようになる。データベースが変更されることになるが、既存のプログラムについては、ビューを活用,,, ,,,すれば検索先のテーブル名を修正するだけで、処理内容そのものは変更することなく利用できる。ただし、当,,, ,,,日貸出しの案件については、在庫場所が指定された店舗の在庫だけが検索されるようSQLを修正する必要が,,, ,,,ある。店舗から倉庫へ移送する業務機能だけは、新規に作成しなければならず、店舗、倉庫の両方から利用,,, ,,,できるようにする。　以上,,, ,,,,,, 平成２８年度　問１　業務要件の優先順位付けについて,,,,,, ,,,,,, ,　情報システムの開発における要件定義において、システムアーキテクトは利用者などとともに、提示された業務要,,,,, ,件を精査する。その際、提示された業務要件の全てをシステム化すると、コストが増大したり、開発期間が延びたり,,,,, ,するおそれがある。そのため、システムアーキテクトは、業務要件のシステム化によって得られる効果と必要なコスト,,,,, ,や開発期間などから、例えば次のような手順で、提示された業務要件に優先順位を付ける。,,,,, ,,1,業務の特性や情報システムの開発の目的などを踏まえて、組織の整備や教育訓練などの準備の負荷、業務,,, ,,,コスト削減の効果及び業務スピードアップの度合いといった業務面での評価項目を設定する。また、適用する,,, ,,,技術の検証の必要性、影響する他の情報システムの修正を含む開発コスト及び開発期間といったシステム面,,, ,,,での評価項目を設定する。,,, ,,2,業務の特性や情報システムの開発の目的などを踏まえて、評価項目ごとに重みづけをする。,,, ,,3,業務面、システム面でのそれぞれの評価項目について、業務要件ごとに定量的に評価する。このとき、定性,,, ,,,的な評価項目についても、定量化した上で評価する。,,, ,,4,評価項目ごとに付与された重みづけを加味して総合的に評価し、実現すべき業務要件の優先順位を付ける。,,, ,　あなたの経験と考えに基づいて、設問ア～ウに従って論述せよ。,,,,, ,,,,,, ,設問ア,,,あなたが要件定義に携わった情報システムについて、その概要を、情報システムの開発の目的、対象の,, ,,,,業務の概要を含めて、800字以内で述べよ。,, ,設問イ,,,設問アで述べた情報システムの要件定義で、業務要件をどのような手順で評価したか。その際、どのよう,, ,,,,な評価項目を設定し、どのような考えで重みづけをしたか。800字以上1600字以内で具体的に述べよ。,, ,設問ウ,,,設問イで述べた評価手順に沿って、どのような業務要件をどのように評価したか。また、その結果それらの,, ,,,,業務要件にどのような優先順位を付けたか。いくつかの業務要件について、600字以上1200字以内で具体,, ,,,,的に述べよ。,, ,,,,,, ■解説,,,,,, ,,,,,, ,■出題趣旨,,,,, ,,,,,, ,,　情報システムの開発における要件定義において、システムアーキテクトは利用者などとともに、提示された業務,,,, ,,要件を精査する。その際、業務要件のシステム化によって得られる効果とコストや開発期間などを総合的に評価,,,, ,,し、業務要件の優先順位を付ける。,,,, ,,　本問では、業務要件の優先順位付けをするための手順と評価の方法について、具体的に論述することを求め,,,, ,,ている。論述を通じて、システムアーキテクトに必要な、業務要件を分析して評価する能力と経験を評価する。,,,, ,,,,,, ,■採点講評,,,,, ,,,,,, ,,　全問に共通して、自らの体験に基づき設問に素直に答えている論述が多かった。一方で、問題文に記載してあ,,,, ,,るプロセスや観点などを抜き出し、一般論と組み合わせただけの表面的な論述も引き続き見られた。問題文に記,,,, ,,載したプロセスや観点は例示である。自らが実際にシステムアーキテクトとして、検討し取り組んだことを具体的,,,, ,,に論述してほしい。,,,, ,,　問１（業務要件の優先順位付けについて）では、どのような評価のプロセスと評価項目で業務要件の優先度を,,,, ,,評価したか、また情報システム開発の目的に沿った重みづけをしたか、を具体的に論述することを期待した。,,,, ,,評価のプロセスと評価項目については、多くの受験者が論述できていた。一方で、情報システムの開発の目的と,,,, ,,評価項目・重みづけの間の関連が分からない論述や、業務要件ではなくシステム要件を評価している論述も多,,,, ,,かった。システムアーキテクトには、情報システムの開発目的を理解した上で、業務要件と情報システムの両面,,,, ,,から分析することが求められる。情報システムだけでなく、業務要件と情報システムの両面からの分析能力を高,,,, ,,めてほしい。,,,, ,,,,,, ,■解説,,,,, ,,,,,, ,,　業務要件の優先順位付けがテーマの問題である。,,,, ,,　システム開発において、顧客から提示された業務要件をすべて取り込むと、コストが増大してプロジェクトが赤,,,, ,,字になったり、開発期間が延長になって予定通りの本番稼働が出来なかったりする可能性がある。,,,, ,,　システムアーキテクトには、業務要件のシステム化によって得られる効果、開発に必要となるコスト、設定されて,,,, ,,いる開発期間などを基に、提示された業務要件に優先順位を設定することが求められる。例えば、開発期間がタ,,,, ,,イトであれば、優先順位の低い業務要件のシステム化を見送ることも必要である。業務要件の優先順位付けが,,,, ,,テーマであるため、提示された業務要件をすべてシステム化したような事例を題材にすることは適切ではない。,,,, ,,業務要件を取捨選択したような事例を取り上げる必要がある。,,,, ,,,,,, ,,　設問アでは、「情報システムの概要」、「情報システム開発の目的」、「対象の業務の概要」を記述する。「情報,,,, ,,システムの概要」と「対象の業務の概要」は、システムアーキテクト試験の設問アにおいて、定番となっている要,,,, ,,求事項であり、受験者の経験をたな卸して、事例を整理しておけば容易に記述できると考えられる。「情報システ,,,, ,,ム開発の目的」についても、受験者が開発に携わった案件であれば、なぜ開発するのか、何を目的に開発する,,,, ,,のかなどは自明であると考えられる。この問題の設問アは20分程度で完成させたい。,,,, ,,,,,, ,,　設問イでは、「業務要件の評価手順」、「業務要件を評価する際の評価項目」、「評価項目の重みづけ」を記述す,,,, ,,る。問題文には、具体的な評価手順が示されており、どの程度詳細な評価手順の記述が要求されているかを推,,,, ,,察できる。「業務要件を評価する際の評価項目」については、問題文に「業務の特性や情報システムの開発の目,,,, ,,的などを踏まえて、組織の整備や教育訓練などの準備の負荷、業務コスト削減の効果及び業務のスピードアップ,,,, ,,の度合いといった業務面での評価項目を設定する。また、適用する技術の検証の必要性、影響する他の情報シ,,,, ,,ステムの修正を含む開発コスト及び開発期間といったシステム面での評価項目を設定する」と指示されている点,,,, ,,を踏まえると、業務面の評価項目とシステム面の評価項目の両方に言及しなければならない。「評価項目の重み,,,, ,,づけ」については、「業務の特性や情報システムの開発の目的などを踏まえて、評価項目ごとに重みづけをする」,,,, ,,と補足されており、設問アの記述内容と矛盾しないように注意が必要である。業務の特性は、設問アの要求事項,,,, ,,として明示されておらず、設問アの記述に含めておくか、設問イにおいて補足的に記述する必要がある。,,,, ,,,,,, ,,　設問ウでは、「業務要件の評価結果」、「業務要件に設定した優先順位」を記述する。「業務要件の評価結果」に,,,, ,,ついては、設問イで記述した業務面の評価項目、システム面での評価項目それぞれについて、評価結果を記述,,,, ,,する。最終的には優先順位を設定することになるので、評価結果は定量的に表現できるようにしておく必要があ,,,, ,,る。設問イの要求事項「業務要件の評価手順」で示しておきたい。「業務要件に設定した優先順位」では、評価結,,,, ,,果に基づいた優先順位を記述するだけになるので、設問ウで要求される最低字数の600字を超えるように「業務,,,, ,,要件の評価結果」を手厚く記述することを心掛ける。問題文には「いくつかの業務要件について」と指示されてお,,,, ,,り、すべての業務要件の評価結果を記述する必要はないが、複数の業務要件を取り上げなければならない。,,,, ,,,,,, ■解答,,,,,, ,,,,,, ,ア　対象の業務と概要、情報システムの開発の目的、及び情報システムの概要,,,,, ,ア―１　対象の業務と概要,,,,, ,,,,,, ,,　私は、情報システムの構築を一括で受注したシステムインテグレータP社に所属するシステムアーキテクトであ,,,, ,,る。論述の対象とする顧客は化学工業のA社で、本社支店、国内数か所の工場と研究所をもつ企業である。A社,,,, ,,の製品は、石油化学製品、機能材料、農業関連製品、医薬品など多岐にわたっており、対象とする業務は、A社,,,, ,,の人材のスキルや経歴を管理する業務である。,,,, ,,　A社は事業部門ごとに専門スキルが要求されるが、属人性が高く定量的に把握することが難しかった。これまで,,,, ,,は、表計算ソフトで本人申告のスキルを管理していた。,,,, ,,,,,, ,ア―２　情報システムの開発の目的,,,,, ,,,,,, ,,　構築する情報システムは、スキル管理システムである。本システムによって、社員のスキルを定量的に把握す,,,, ,,ると同時に、業務上必要な資格などの情報も管理することを目的としている。A社人事では、社員の成長度合い,,,, ,,を分析し、かつ履歴として管理することを考えている。今回の要件定義について、私が全体を取りまとめることに,,,, ,,なった。,,,, ,,,,,, ,ア―３　情報システムの概要,,,,, ,,,,,, ,,　A社では、情報システムは更新時期に順次クラウドシステムに変更していく方針である。本案件もクラウドシステ,,,, ,,ムとして構築することになった。A社情報システム部門が事前調査をした結果、B社のクラウドシステム環境を適,,,, ,,用し、プライベートクラウドとして開発することが決定されている。新年度の4月からシステムを適用するため開発,,,, ,,期間は9カ月であり、P社の過去の事案と比較すると開発期間が短くなっており、すべての顧客要件を実現するの,,,, ,,は難しいと考えられる。ただし、コスト面では多少の余裕をもったプロジェクトである。,,,, ,,,,,, ,イ　業務要件の評価手順、評価項目、及び評価項目に対する重みづけの考え方,,,,, ,イ―１　業務要件の評価手順,,,,, ,,,,,, ,,　私は、今回の業務要件の評価において、評価項目の設定、評価項目の重みづけ、業務要件ごとに定量的に評,,,, ,,価、評価結果を総合的に判断し業務要件に優先順位を付けるという手順で進めることにした。評価項目をきめ細,,,, ,,かく設定することも可能であるが、評価をする目的が業務要件の優先順位付けであるため、業務に大きく影響す,,,, ,,るような項目を優先して、評価することを基本方針とした。,,,, ,,　評価項目の重みづけについては、業務への影響度とシステム化のための難易度や負荷によって高中低とし、,,,, ,,高＝３、中＝２、低＝１と数値化する。定性的な評価になる部分についても、実現できないと業務への影響が大き,,,, ,,い評価項目、実現できなくても業務への影響が小さい評価項目、その中間の評価項目という判断基準で評価し、,,,, ,,評価値を順に3、1、2とすることにした。ただし、定性的な評価項目については、属人的な判断にならないようにす,,,, ,,るため、利用部門と協議の上、定量的な評価値を決定する。業務要件ごとに、評価項目の評価値×重みづけの,,,, ,,値を合計し、数値の大きい順に優先順位を決定する。単純な数値計算で優先順位を決定できない部分もあると,,,, ,,考えられるため、検討した優先順位を利用部門に提示し、利用部門に優先順位を確認していただく必要がある。,,,, ,,,,,, ,イ―２　評価項目,,,,, ,,,,,, ,,　私は、業務要件の優先順位を決定するに当たり、業務面とシステム面の両側面から検討できるように評価項目,,,, ,,を次のように設定した。まず、業務面の評価項目では、業務コストの削減の効果、業務スピードアップの度合い、,,,, ,,準備の負荷を取り上げた。理由は、表計算ベースで行っている業務のシステム化であるため、業務効率が向上,,,, ,,すると予想されることと、新しいシステムであるため、教育訓練などの準備にも負荷がかかると考えたからである,,,, ,,。次に、システム面での評価項目については、適用する技術の検証の必要性、開発期間、影響する情報システ,,,, ,,ムを取り上げた。理由は、新たにクラウドシステムとして構築する点、納期が厳密に定められている点、新規シス,,,, ,,テムである点がポイントになると考えたからである。,,,, ,,,,,, ,イ―３　評価項目に対する重みづけの考え方,,,,, ,,,,,, ,,（１）基本的な考え方,,,, ,,,,,, ,,,　評価項目に対する重みづけについて、開発期間が限定されているため、期限までにシステムが稼働できる,,, ,,,ことがポイントになり、期間に関する評価項目には重きを置くこととした。一方、コスト的には若干余裕があるた,,, ,,,め、コストの追加でクリアできる評価項目は重みを少なくする。,,, ,,,,,, ,,（２）重みづけ結果,,,, ,,,,,, ,,,　イ―２で述べた各評価項目についての重みづけ結果は次の通りである。業務コスト削減の効果：手作業から,,, ,,,システム化できるため、重みは大（３）とする。業務スピードアップの度合い：システムに慣れるまでの間は短期,,, ,,,的なスピードアップ効果は小さいと考えられるため、重みは中（２）とする。準備の負荷：複雑なシステムでは,,, ,,,ないため、教育訓練などの準備の負荷について重みは小（１）とする。適用する技術の検証の必要性：新しい,,, ,,,技術を適用する部分は少ないと考えられるため、重みは中（２）とする。開発期間：稼働開始時期を延期するこ,,, ,,,とはできないため、重みは大（３）とする。影響する情報システム：新規システムであるため、旧管理データから,,, ,,,の移行程度にとどまるため、重みは小（１）とする。,,, ,,,,,, ,ウ　評価した業務要件、評価結果、及び業務要件に設定した優先順位,,,,, ,ウ―１　評価した業務要件,,,,, ,,,,,, ,,　今回のシステム構築に際し、優先順位を付けるべく検討した業務要件は、「社員が持つスキルを定量的に管理,,,, ,,できること」、「社員が持つ資格を適切に管理できること」、「社員のスキル向上度合いを評価できること」の3点とし,,,, ,,た。1点目は従来の手作業をシステム化するという要件でありシステム化の目的そのものである。2点目について,,,, ,,は、これまでは社員が自発的に資格登録をしていたため、データに不整合が生じており、データの整備も含めて,,,, ,,実現しようとするものである。3点目はシステムが導入されることを受けて新しく検討している業務である。,,,, ,,,,,, ,ウ―２　評価結果,,,,, ,,,,,, ,,（１）スキルの定量的管理,,,, ,,,,,, ,,,　スキルを定量的に管理することについて、設問イで説明した手順で評価した。評価結果は、業務コスト削減,,, ,,,の効果3×重み3、業務のスピードアップの度合い2×重み2、準備の負荷1×重み1、適用する技術の検証の,,, ,,,必要性3×重み2、開発期間3×重み3、影響するシステム1×重み1となり、総合評価値は30である。,,, ,,,,,, ,,（２）資格の適切な管理,,,, ,,,,,, ,,,　資格を適切に管理することについても同様に評価を行い、業務コスト削減の効果2×重み3、業務のスピード,,, ,,,アップの度合い2×重み2、準備の負荷1×重み1、適用する技術の検証の必要性2×重み2、開発期間3×重,,, ,,,み3、影響するシステム1×重み1と判断した。総合評価値は25である。,,, ,,,,,, ,,（３）スキル向上度合いの評価,,,, ,,,,,, ,,,　資格を適切に管理することの評価は、業務コスト削減の効果1×重み3、業務のスピードアップの度合い1×,,, ,,,重み2、準備の負荷1×重み1、適用する技術の検証の必要性2×重み2、開発期間1×重み3、影響するシステ,,, ,,,ム1×重み1となった。総合評価値は14である。,,, ,,,,,, ,ウ―３　業務要件に設定した優先順位,,,,, ,,,,,, ,,　総合評価値を基に決定した業務要件は次の通りである。スキルの定量的な管理については、必須の要件とし,,,, ,,て実現する。資格の適切な管理については、管理対象の資格の取り扱いを明確化する必要があるが、現状の管,,,, ,,理レベルを維持するという前提で要件として実現する。スキル向上度合いの評価については、評価手法や評価ノ,,,, ,,ウハウをシステムに持つことが必要であるが、具体的な手法やノウハウが未成熟であるため、本番稼働時期を,,,, ,,鑑み、第一段階では見送り、継続検討とする。,,,, ,,　私は、利用部門に優先順位を提示し、合意が得られたため、当該業務要件を実現すべく作業を継続することと,,,, ,,した。　以上,,,, ,,,,,, 平成２８年度　問１　業務要件の優先順位付けについて,,,,,, ,,,,,, ,　情報システムの開発における要件定義において、システムアーキテクトは利用者などとともに、提示された業務要,,,,, ,件を精査する。その際、提示された業務要件の全てをシステム化すると、コストが増大したり、開発期間が延びたり,,,,, ,するおそれがある。そのため、システムアーキテクトは、業務要件のシステム化によって得られる効果と必要なコスト,,,,, ,や開発期間などから、例えば次のような手順で、提示された業務要件に優先順位を付ける。,,,,, ,,1,業務の特性や情報システムの開発の目的などを踏まえて、組織の整備や教育訓練などの準備の負荷、業務,,, ,,,コスト削減の効果及び業務スピードアップの度合いといった業務面での評価項目を設定する。また、適用する,,, ,,,技術の検証の必要性、影響する他の情報システムの修正を含む開発コスト及び開発期間といったシステム面,,, ,,,での評価項目を設定する。,,, ,,2,業務の特性や情報システムの開発の目的などを踏まえて、評価項目ごとに重みづけをする。,,, ,,3,業務面、システム面でのそれぞれの評価項目について、業務要件ごとに定量的に評価する。このとき、定性,,, ,,,的な評価項目についても、定量化した上で評価する。,,, ,,4,評価項目ごとに付与された重みづけを加味して総合的に評価し、実現すべき業務要件の優先順位を付ける。,,, ,　あなたの経験と考えに基づいて、設問ア～ウに従って論述せよ。,,,,, ,,,,,, ,設問ア,,,あなたが要件定義に携わった情報システムについて、その概要を、情報システムの開発の目的、対象の,, ,,,,業務の概要を含めて、800字以内で述べよ。,, ,設問イ,,,設問アで述べた情報システムの要件定義で、業務要件をどのような手順で評価したか。その際、どのよう,, ,,,,な評価項目を設定し、どのような考えで重みづけをしたか。800字以上1600字以内で具体的に述べよ。,, ,設問ウ,,,設問イで述べた評価手順に沿って、どのような業務要件をどのように評価したか。また、その結果それらの,, ,,,,業務要件にどのような優先順位を付けたか。いくつかの業務要件について、600字以上1200字以内で具体,, ,,,,的に述べよ。,, ,,,,,, ■見出しとストーリー,,,,,, ,,,,,, ,■設問ア,,,,, ,,,,,, ,,設問ア,,,あなたが要件定義に携わった情報システムについて、その概要を、情報システムの開発の目的、対象, ,,,,,の業務の概要を含めて、800字以内で述べよ。, ,,,,,, ,,　設問アには、対応する問題文がなく、自身の経験に基づき要求事項を記述する。,,,, ,,,,,, ,,□ストーリー作成のポイント（見出しの検討）,,,, ,,,,,, ,,,　設問アの要求事項は、,,, ,,,,,, ,,,,・,対象の業務と概要, ,,,,・,情報システムの開発の目的, ,,,,・,情報システムの概要, ,,,,,, ,,,となっている。問題文には要件定義を行った業務や情報システムを特徴付ける記述がなく、どのような案件で,,, ,,,あっても論文の題材にできる。特定の業務に依存する問題ではないため、取り組みやすい問題であったと考,,, ,,,えられる。業務要件に関する記述が中心になるため、情報システムの概要は簡単に触れる程度でも良い。た,,, ,,,だし、業務要件の優先順位を付ける問題であるため、複数の業務要件を取り扱う案件を取り上げる必要があ,,, ,,,る。,,, ,,,,,, ,,□ストーリー,,,, ,,,,,, ,,,ア　対象の業務と概要、情報システムの開発の目的、及び情報システムの概要,,, ,,,ア―１　対象の業務と概要,,, ,,,,,, ,,,,・,対象となる顧客は化学工業のA社, ,,,,・,A社は、本社を東京と大阪に置き、名古屋に支店、国内数か所に工場と研究所をもつ, ,,,,・,A社の製品は、石油化学製品、機能材料、農業関連製品、医薬品など非常に幅広く多岐にわたってい, ,,,,,る, ,,,,・,対象となる業務は、A社の人材のスキルや経歴を管理する業務, ,,,,・,A社は事業部門ごとに専門スキルが要求されるが、属人性が高く定量的に把握できないことが懸案事, ,,,,,項, ,,,,・,これまでは、表計算ソフトで本人申告のスキルを管理していた, ,,,,・,自身の立場は、今回の業務要件の定義を含め、情報システムの構築を一括で受注したシステムインテ, ,,,,,グレータP社に所属するシステムアーキテクト, ,,,,,, ,,,ア―２　情報システムの開発の目的,,, ,,,,,, ,,,,・,構築する情報システムは、スキル管理システム, ,,,,・,社員が保有するスキルを定量的に把握する, ,,,,・,他に社員が保有する業務上必要な資格などの情報も管理する, ,,,,・,社員の成長度合いを分析し、かつ履歴としても管理する, ,,,,・,今回の要件定義について、私が全体を取りまとめることになった, ,,,,,, ,,,ア―３　情報システムの概要,,, ,,,,,, ,,,,・,A社の方針として、社内で稼働している情報システムは更新時期に順次クラウドシステムに変更していく, ,,,,,ことが決まっている, ,,,,・,スキル管理システムは新規開発のシステムであり、クラウドシステムとして構築することが決定されてい, ,,,,,る, ,,,,・,A社情報システム部門が事前調査をして、B社が提供しているクラウドシステム環境を適用する, ,,,,・,適用できる範囲の多い適切なパッケージがないため、今回のシステムにおいてはプライベートクラウドと, ,,,,,して開発する, ,,,,・,新年度の4月からシステムを適用するため開発期間は9カ月であり、P社の過去の事案と比較すると開, ,,,,,発期間が90％と短くなっており、すべての顧客要件を実現するのは難しいと考えられる, ,,,,・,コスト面では多少の余裕があるプロジェクト, ,,,,,, ,,□ストーリーから論文を作成するポイント,,,, ,,,,,, ,,,　設問アの要求事項は、「対象の業務と概要」、「情報システムの開発の目的」、「情報システムの概要」の3点,,, ,,,である。いずれの事項ともシステムアーキテクト試験の設問アとしてよく出題される事項であるが、設問イの要,,, ,,,求事項が業務要件についての優先順位付けであるため、対象の業務や情報システム開発の目的については,,, ,,,、業務要件に結び付くような記述をするとよい。また、優先順位付けにおいて、業務面とシステム面の両方で,,, ,,,評価項目を記述するため、情報システムの概要についても、評価項目に関連するような記述をしておきたい。,,, ,,,,,, ,■設問イ,,,,, ,,,,,, ,,設問イ,,,設問アで述べた情報システムの要件定義で、業務要件をどのような手順で評価したか。その際、どのよ, ,,,,,うな評価項目を設定し、どのような考えで重みづけをしたか。800字以上1600字以内で具体的に述べよ, ,,,,,。, ,,,,,, ,,□設問イに対応する問題文,,,, ,,,,,, ,,,　そのため、システムアーキテクトは、業務要件のシステム化によって得られる効果と必要なコストや開発期間,,, ,,,などから、例えば、次のような手順で、提示された業務要件に優先順位を付ける。,,, ,,,,1,業務の特性や情報システムの開発の目的などを踏まえて、組織の整備や教育訓練などの準備の負荷, ,,,,,、業務コスト削減の効果及び業務スピードアップの度合いといった業務面での評価項目を設定する。ま, ,,,,,た、適用する技術の検証の必要性、影響する他の情報システムの修正を含む開発コスト及び開発期間, ,,,,,といったシステム面での評価項目を設定する。, ,,,,2,業務の特性や情報システムの開発の目的などを踏まえて、評価項目ごとに重みづけをする。, ,,,,3,業務面、システム面でのそれぞれの評価項目について、業務要件ごとに定量的に評価する。このとき、, ,,,,,定性的な評価項目についても、定量化した上で評価する。, ,,,,4,評価項目ごとに付与された重みを加味して総合的に評価し、実現すべき業務要件の優先順位を付ける, ,,,,,。, ,,,,,, ,,□ストーリー作成のポイント（見出しの検討）,,,, ,,,,,, ,,,　設問イで指示されている要求事項は、,,, ,,,,,, ,,,,・,業務要件の評価手順, ,,,,・,評価項目, ,,,,・,評価項目に対する重み付けの考え方, ,,,,,, ,,,となっている。業務要件そのものは設問ウで記述するようになっている。要求事項として明示されていないが、,,, ,,,一般的な業務要件の評価手順や評価項目ではなく、システムアーキテクトが携わった具体的な案件における,,, ,,,業務要件の評価手順や評価項目を記述しなければならないため、設問イにおいてもある程度は業務要件そ,,, ,,,のものに言及しても良い。,,, ,,,,,, ,,,　問題文の大半を割いて業務要件の優先順位付け手順が説明されているので、この問題の出題者が期待し,,, ,,,ている手順は容易に理解できたものと考えられる。具体的には、業務面とシステム面での評価項目の設定、,,, ,,,評価項目の重みづけ、評価項目ごとの評価、評価結果を基にした優先順位の設定という手順になっている。,,, ,,,説明されている手順のそれぞれにおいて、記述の参考にできる例や記述に関する制約などが示されており、,,, ,,,特に制約は見落とさないように注意しなければならない。制約としては、業務面とシステム面の両方で評価項,,, ,,,目を設定する、業務の特性や情報システム開発の目的を踏まえる、定性的な評価項目も定量化する、総合的,,, ,,,に評価するという点が挙げられる。重みづけには例が示されていないため、重要度合いによって高中低などで,,, ,,,もよいが、最終的に定量的に評価できるようにしておかなければならない。,,, ,,,,,, ,,□ストーリー,,,, ,,,,,, ,,,イ　業務要件の評価手順、評価項目、及び評価項目に対する重みづけの考え方,,, ,,,イ―１　業務要件の評価手順,,, ,,,,,, ,,,,・,評価手順は、評価項目の設定、評価項目の重みづけ、業務要件ごとに定量的に評価、評価結果を総, ,,,,,合的に判断し業務要件に優先順位を付けるという手順, ,,,,・,評価項目をきめ細かく設定することも可能であるが、目的が業務要件の優先順位付けであるため、業, ,,,,,務に大きく影響するような項目を評価することを基本方針とする, ,,,,・,評価項目の重みづけについては、業務への影響度とシステム化のための難易度や負荷によって高中, ,,,,,低とし、高＝3、中＝2、低＝1と数値化する, ,,,,・,定量的な評価については、実現できないと業務への影響が大きい評価項目、実現できなくても業務へ, ,,,,,の影響が小さい評価項目、その中間の評価項目というように評価し、評価値を順に3、1、2とする, ,,,,・,定性的な評価項目について、属人的な判断にならないようにするために、利用部門と協議の上、定量, ,,,,,的な評価に合わせて1～3に数値化する, ,,,,・,要件ごとに、評価項目の評価値×重みづけの値を合計し、数値の大きい順に優先順位を設定する, ,,,,・,ただし、単純な数値計算では表現できない場合があるため、優先順位を利用部門に最終的に確認する, ,,,,,, ,,,イ―２　評価項目,,, ,,,,,, ,,,,（１）業務面での評価項目,, ,,,,,, ,,,,,・,業務コストの削減の効果 ,,,,,・,業務スピードアップの度合い ,,,,,・,準備の負荷 ,,,,,・,評価項目の選択理由は、表計算ソフトウェアで行っていた業務のシステム化、新システムのための ,,,,,,教育の必要性などによる ,,,,,, ,,,,（２）システム面での評価項目,, ,,,,,, ,,,,,・,適用する技術の検証の必要性 ,,,,,・,開発期間 ,,,,,・,影響する情報システム ,,,,,・,評価項目の選択理由は、新システムをクラウドシステムとして構築すること、納期が厳密に決まって ,,,,,,いることなどによる ,,,,,, ,,,イ―３　評価項目に対する重みづけの考え方,,, ,,,,,, ,,,,（１）基本的な考え方,, ,,,,,, ,,,,,・,開発期間が限定されているため、期限までにシステムが稼働できることがポイントになり、期間に関 ,,,,,,連する評価項目には重きを置く ,,,,,・,コスト的には若干余裕があるため、コストの追加でクリアできる評価項目は重みを少なくする ,,,,,, ,,,,（２）重みづけ結果,, ,,,,,, ,,,,,・,業務コストの削減の効果：手作業からシステム化できるため、重みは大（３）とする ,,,,,・,業務スピードアップの度合い：システムに慣れるまでの間は短期的なスピードアップ効果は小さいと ,,,,,,考えられるため、重みは中（２）とする ,,,,,・,準備の負荷：複雑なシステムではないため、教育訓練などの準備の負荷について重みは小（１）とす ,,,,,,る ,,,,,・,適用する技術の検証の必要性：新しい技術を適用する部分は少ないと考えられるため、重みは中（ ,,,,,,２）とする ,,,,,・,開発期間：稼働開始時期を延期することはできないため、重みは大（３）とする ,,,,,・,影響する情報システム：新規システムであるため、旧管理データからの移行程度にとどまるため、重 ,,,,,,みは小（１）とする ,,,,,, ,,□ストーリーから論文を作成するポイント,,,, ,,,,,, ,,,　設問イで記述すべきは業務要件の優先順位付け手順である。業務要件の評価項目は、業務面とシステム,,, ,,,面の両方が要求されており、題意から考えると最低でもそれぞれ2項目ずつ、合計で4項目は評価項目が必要,,, ,,,であると考えられる。業務要件の評価結果は設問ウの要求事項であるため設問イでの記述は不要であるが、,,, ,,,設問イで記述すべき事項を鑑みると、相応の記述量になると予想される。記述できる字数は1600字までと十,,, ,,,分余裕がある一方、記述に割り当てられる時間の制約が大きく、設問ウの記述時間を確保することを意識しな,,, ,,,がら書き進める必要がある。,,, ,,,,,, ,■設問ウ,,,,, ,,,,,, ,,設問ウ,,,設問イで述べた評価手順に沿って、どのような業務要件をどのように評価したか。また、その結果それ, ,,,,,らの業務要件にどのような優先順位を付けたか。, ,,,,,いくつかの業務要件について、600字以上1200字以内で具体的に述べよ。, ,,,,,, ,,□設問ウに対応する問題文,,,, ,,,,,, ,,,　設問ウには、対応する問題文がなく、自身の経験に基づき具体的に業務要件を優先順位付けした事例を記,,, ,,,述する。,,, ,,,,,, ,,□ストーリー作成のポイント（見出しのポイント）,,,, ,,,,,, ,,,　設問ウで指示されている要求事項は、,,, ,,,,,, ,,,,・,評価した業務要件, ,,,,・,評価結果, ,,,,・,業務要件の優先順位, ,,,,,, ,,,となっている。,,, ,,,　一つ目の要求事項である「評価した業務要件」は、設問文に「いくつかの業務要件について」と補足されてい,,, ,,,る通り、対象となる情報システムで実現するすべての業務要件を記述する必要はない。ただし、業務要件の優,,, ,,,先順位付けをするということであるから、取り上げるべき業務要件は最低でも3項目は必要である。設問ウで,,, ,,,述べる業務要件について、取り上げた理由は記述しなくても良いが、優先順位付けによって開発対象として,,, ,,,取捨選択することになるので、利用者側が実現必須と考えているような業務要件や、実現できなくても代替手,,, ,,,段のあるような業務要件など、優先順位が明確になるような業務要件を取り上げる必要がある。設問イで記,,, ,,,述した評価手順に従った評価内容を示せばよいので、記述しやすい設問ウであると考えられる。,,, ,,,,,, ,,□ストーリー,,,, ,,,,,, ,,,ウ　評価した業務要件、評価結果、及び業務要件に設定した優先順位,,, ,,,ウ―１　評価した業務要件,,, ,,,,,, ,,,,・,システム化の主要な目的、データ整備の重要性、新しく検討する業務などの観点から次の3項目を取り, ,,,,,上げる, ,,,,・,社員が持つスキルを定量的に管理できること, ,,,,・,社員が持つ資格を適切に管理できること, ,,,,・,社員のスキル向上度合いを評価できること, ,,,,,, ,,,ウ―２　評価結果,,, ,,,,,, ,,,,（１）スキルの定量的管理,, ,,,,,, ,,,,,・,スキルを定量的に管理することについて、業務コスト削減の効果3×重み3、業務のスピードアップの ,,,,,,度合い2×重み2、準備の負荷1×重み1、適用する技術の検証の必要性3×重み2、開発期間3×重 ,,,,,,み3、影響するシステム1×重み1と判断し、総合評価は30 ,,,,,, ,,,,（２）資格の適切な管理,, ,,,,,, ,,,,,・,資格を適切に管理することについて、業務コスト削減の効果2×重み3、業務のスピードアップの度合 ,,,,,,い2×重み2、準備の負荷1×重み1、適用する技術の検証の必要性2×重み2、開発期間3×重み3、 ,,,,,,影響するシステム1×重み1と判断し、総合評価値は25 ,,,,,, ,,,,（３）スキル向上度合いの評価,, ,,,,,, ,,,,,・,資格を適切に管理することについて、業務コスト削減の効果1×重み3、業務のスピードアップの度合 ,,,,,,い1×重み2、準備の負荷1×重み1、適用する技術の検証の必要性2×重み2、開発期間1×重み3、 ,,,,,,影響するシステム1×重み1と判断し、総合評価値は14 ,,,,,, ,,,ウ―３　業務要件に設定した優先順位,,, ,,,,,, ,,,,・,スキルの定量的な管理については、必須の要件として実現する, ,,,,・,資格の適切な管理については、管理対象の資格の取り扱いを明確化する必要があるが、現状の管理, ,,,,,レベルを維持するという前提で要件として実現する, ,,,,・,スキル向上度合いの評価については、評価手法や評価ノウハウをシステムに持つことが必要であるが, ,,,,,、具体的な手法やノウハウが未成熟であるため、本番稼働時期を鑑み、第一段階では見送り、継続検, ,,,,,討とする, ,,,,・,利用部門に優先順位を提示し、合意が得られる, ,,,,,, ,,□ストーリーから論文を作成するポイント,,,, ,,,,,, ,,,　要求された事項を淡々と記述すればよい。本ストーリーでは、対象とした業務要件、評価結果、業務要件に,,, ,,,設定した優先順位という節構成にしているが、業務要件ごとに評価結果と優先順位を記述する構成も考えら,,, ,,,れる。業務要件に設定した優先順位は評価結果を述べるだけであり、記述量は多くならないため、評価結果,,, ,,,の部分を手厚く記述するようにしたい。設問イで評価項目を相応に記述しているため、設問ウの字数条件であ,,, ,,,る「600字以上」は容易に達成できるであろう。また、業務要件に設定した優先順位を、単独の節として記述し,,, ,,,にくければ、評価結果に含めて記述してもよい。,,, ,,,,,, ■解答,,,,,, ,,,,,, ,ア　対象の業務と概要、情報システムの開発の目的、及び情報システムの概要,,,,, ,ア―１　対象の業務と概要,,,,, ,,,,,, ,,　私は、情報システムの構築を一括で受注したシステムインテグレータP社に所属するシステムアーキテクトであ,,,, ,,る。論述の対象とする顧客は化学工業のA社で、本社支店、国内数か所の工場と研究所をもつ企業である。A社,,,, ,,の製品は、石油化学製品、機能材料、農業関連製品、医薬品など多岐にわたっており、対象とする業務は、A社,,,, ,,の人材のスキルや経歴を管理する業務である。,,,, ,,　A社は事業部門ごとに専門スキルが要求されるが、属人性が高く定量的に把握することが難しかった。これまで,,,, ,,は、表計算ソフトで本人申告のスキルを管理していた。,,,, ,,,,,, ,ア―２　情報システムの開発の目的,,,,, ,,,,,, ,,　構築する情報システムは、スキル管理システムである。本システムによって、社員のスキルを定量的に把握す,,,, ,,ると同時に、業務上必要な資格などの情報も管理することを目的としている。A社人事では、社員の成長度合い,,,, ,,を分析し、かつ履歴として管理することを考えている。今回の要件定義について、私が全体を取りまとめることに,,,, ,,なった。,,,, ,,,,,, ,ア―３　情報システムの概要,,,,, ,,,,,, ,,　A社では、情報システムは更新時期に順次クラウドシステムに変更していく方針である。本案件もクラウドシステ,,,, ,,ムとして構築することになった。A社情報システム部門が事前調査をした結果、B社のクラウドシステム環境を適,,,, ,,用し、プライベートクラウドとして開発することが決定されている。新年度の4月からシステムを適用するため開発,,,, ,,期間は9カ月であり、P社の過去の事案と比較すると開発期間が短くなっており、すべての顧客要件を実現するの,,,, ,,は難しいと考えられる。ただし、コスト面では多少の余裕をもったプロジェクトである。,,,, ,,,,,, ,イ　業務要件の評価手順、評価項目、及び評価項目に対する重みづけの考え方,,,,, ,イ―１　業務要件の評価手順,,,,, ,,,,,, ,,　私は、今回の業務要件の評価において、評価項目の設定、評価項目の重みづけ、業務要件ごとに定量的に評,,,, ,,価、評価結果を総合的に判断し業務要件に優先順位を付けるという手順で進めることにした。評価項目をきめ細,,,, ,,かく設定することも可能であるが、評価をする目的が業務要件の優先順位付けであるため、業務に大きく影響す,,,, ,,るような項目を優先して、評価することを基本方針とした。,,,, ,,　評価項目の重みづけについては、業務への影響度とシステム化のための難易度や負荷によって高中低とし、,,,, ,,高＝３、中＝２、低＝１と数値化する。定性的な評価になる部分についても、実現できないと業務への影響が大き,,,, ,,い評価項目、実現できなくても業務への影響が小さい評価項目、その中間の評価項目という判断基準で評価し、,,,, ,,評価値を順に3、1、2とすることにした。ただし、定性的な評価項目については、属人的な判断にならないようにす,,,, ,,るため、利用部門と協議の上、定量的な評価値を決定する。業務要件ごとに、評価項目の評価値×重みづけの,,,, ,,値を合計し、数値の大きい順に優先順位を決定する。単純な数値計算で優先順位を決定できない部分もあると,,,, ,,考えられるため、検討した優先順位を利用部門に提示し、利用部門に優先順位を確認していただく必要がある。,,,, ,,,,,, ,イ―２　評価項目,,,,, ,,,,,, ,,　私は、業務要件の優先順位を決定するに当たり、業務面とシステム面の両側面から検討できるように評価項目,,,, ,,を次のように設定した。まず、業務面の評価項目では、業務コストの削減の効果、業務スピードアップの度合い、,,,, ,,準備の負荷を取り上げた。理由は、表計算ベースで行っている業務のシステム化であるため、業務効率が向上,,,, ,,すると予想されることと、新しいシステムであるため、教育訓練などの準備にも負荷がかかると考えたからである,,,, ,,。次に、システム面での評価項目については、適用する技術の検証の必要性、開発期間、影響する情報システ,,,, ,,ムを取り上げた。理由は、新たにクラウドシステムとして構築する点、納期が厳密に定められている点、新規シス,,,, ,,テムである点がポイントになると考えたからである。,,,, ,,,,,, ,イ―３　評価項目に対する重みづけの考え方,,,,, ,,,,,, ,,（１）基本的な考え方,,,, ,,,,,, ,,,　評価項目に対する重みづけについて、開発期間が限定されているため、期限までにシステムが稼働できる,,, ,,,ことがポイントになり、期間に関する評価項目には重きを置くこととした。一方、コスト的には若干余裕があるた,,, ,,,め、コストの追加でクリアできる評価項目は重みを少なくする。,,, ,,,,,, ,,（２）重みづけ結果,,,, ,,,,,, ,,,　イ―２で述べた各評価項目についての重みづけ結果は次の通りである。業務コスト削減の効果：手作業から,,, ,,,システム化できるため、重みは大（３）とする。業務スピードアップの度合い：システムに慣れるまでの間は短期,,, ,,,的なスピードアップ効果は小さいと考えらられるため、重みは中（２）とする。準備の負荷：複雑なシステムでは,,, ,,,ないため、教育訓練などの準備の負荷について重みは小（１）とする。適用する技術の検証の必要性：新しい,,, ,,,技術を適用する部分は少ないと考えられるため、重みは中（２）とする。開発期間：稼働開始時期を延期するこ,,, ,,,とはできないため、重みは大（３）とする。影響する情報システム：新規システムであるため、旧管理データから,,, ,,,の移行程度にとどまるため、重みは小（１）とする。,,, ,,,,,, ,ウ　評価した業務要件、評価結果、及び業務要件に設定した優先順位,,,,, ,ウ―１　評価した業務要件,,,,, ,,,,,, ,,　今回のシステム構築に際し、優先順位を付けるべく検討した業務要件は、「社員が持つスキルを定量的に管理,,,, ,,できること」、「社員が持つ資格を適切に管理できること」、「社員のスキル向上度合いを評価できること」の3点とし,,,, ,,た。1点目は従来の手作業をシステム化するという要件でありシステム化の目的そのものである。2点目について,,,, ,,は、これまでは社員が自発的に資格登録をしていたため、データに不整合が生じており、データの整備も含めて,,,, ,,実現しようとするものである。3点目はシステムが導入されることを受けて新しく検討している業務である。,,,, ,,,,,, ,ウ―２　評価結果,,,,, ,,,,,, ,,（１）スキルの定量的管理,,,, ,,,,,, ,,,　スキルを定量的に管理することについて、設問イで説明した手順で評価した。評価結果は、業務コスト削減,,, ,,,の効果3×重み3、業務のスピードアップの度合い2×重み2、準備の負荷1×重み1、適用する技術の検証の,,, ,,,必要性3×重み2、開発期間3×重み3、影響するシステム1×重み1となり、総合評価値は30である。,,, ,,,,,, ,,（２）資格の適切な管理,,,, ,,,,,, ,,,　資格を適切に管理することについても同様に評価を行い、業務コスト削減の効果2×重み3、業務のスピード,,, ,,,アップの度合い2×重み2、準備の負荷1×重み1、適用する技術の検証の必要性2×重み2、開発期間3×重,,, ,,,み3、影響するシステム1×重み1と判断した。総合評価値は25である。,,, ,,,,,, ,,（３）スキル向上度合いの評価,,,, ,,,,,, ,,,　資格を適切に管理することの評価は、業務コスト削減の効果1×重み3、業務のスピードアップの度合い1×,,, ,,,重み2、準備の負荷1×重み1、適用する技術の検証の必要性2×重み2、開発期間1×重み3、影響するシステ,,, ,,,ム1×重み1となった。総合評価値は14である。,,, ,,,,,, ,ウ―３　業務要件に設定した優先順位,,,,, ,,,,,, ,,　総合評価値を基に決定した業務要件は次の通りである。スキルの定量的な管理については、必須の要件とし,,,, ,,て実現する。資格の適切な管理については、管理対象の資格の取り扱いを明確化する必要があるが、現状の管,,,, ,,理レベルを維持するという前提で要件として実現する。スキル向上度合いの評価については、評価手法や評価ノ,,,, ,,ウハウをシステムに持つことが必要であるが、具体的な手法やノウハウが未成熟であるため、本番稼働時期を,,,, ,,鑑み、第一段階では見送り、継続検討とする。,,,, ,,　私は、利用部門に優先順位を提示し、合意が得られたため、当該業務要件を実現すべく作業を継続することと,,,, ,,した。　以上,,,, ,,,,,, 平成２８年度　問１　業務要件の優先順位付けについて,,,,,, ,,,,,, ,　情報システムの開発における要件定義において、システムアーキテクトは利用者などとともに、提示された業務要,,,,, ,件を精査する。その際、提示された業務要件の全てをシステム化すると、コストが増大したり、開発期間が延びたり,,,,, ,するおそれがある。そのため、システムアーキテクトは、業務要件のシステム化によって得られる効果と必要なコスト,,,,, ,や開発期間などから、例えば次のような手順で、提示された業務要件に優先順位を付ける。,,,,, ,,1,業務の特性や情報システムの開発の目的などを踏まえて、組織の整備や教育訓練などの準備の負荷、業務,,, ,,,コスト削減の効果及び業務スピードアップの度合いといった業務面での評価項目を設定する。また、適用する,,, ,,,技術の検証の必要性、影響する他の情報システムの修正を含む開発コスト及び開発期間といったシステム面,,, ,,,での評価項目を設定する。,,, ,,2,業務の特性や情報システムの開発の目的などを踏まえて、評価項目ごとに重みづけをする。,,, ,,3,業務面、システム面でのそれぞれの評価項目について、業務要件ごとに定量的に評価する。このとき、定性,,, ,,,的な評価項目についても、定量化した上で評価する。,,, ,,4,評価項目ごとに付与された重みづけを加味して総合的に評価し、実現すべき業務要件の優先順位を付ける。,,, ,　あなたの経験と考えに基づいて、設問ア～ウに従って論述せよ。,,,,, ,,,,,, ,設問ア,,,あなたが要件定義に携わった情報システムについて、その概要を、情報システムの開発の目的、対象の,, ,,,,業務の概要を含めて、800字以内で述べよ。,, ,設問イ,,,設問アで述べた情報システムの要件定義で、業務要件をどのような手順で評価したか。その際、どのよう,, ,,,,な評価項目を設定し、どのような考えで重みづけをしたか。800字以上1600字以内で具体的に述べよ。,, ,設問ウ,,,設問イで述べた評価手順に沿って、どのような業務要件をどのように評価したか。また、その結果それらの,, ,,,,業務要件にどのような優先順位を付けたか。いくつかの業務要件について、600字以上1200字以内で具体,, ,,,,的に述べよ。,, ,,,,,, ■解答例,,,,,, ,,,,,, ,（設問ア）,,,,, ,,,,,, ,１．私が要件定義に携わった情報システムの概要,,,,, ,,,,,, ,,　B社は、大手食品メーカの関連会社で倉庫業を中心に、地方都市に12拠点の倉庫を設置し、事業を展開してき,,,, ,,た。日本の人口減少に伴い、B社の売上高は、微減傾向にあった。B社の経営者層は、打開策を模索し、現時点,,,, ,,から4年前に、倉庫業の業務改革を行うことを決断した。具体的には、B社の収益基盤を拡大するために、食品メ,,,, ,,ーカからコンビニエンスストアやスーパマーケットなどへの物流の途中にある在庫機能以外に、インターネット上,,,, ,,のショッピングモールからの受注を受け、消費者に配送される商品の在庫・出荷機能を追加するものだった。これ,,,, ,,に伴い、出荷指示情報から人手を介さず、ピッキングや段ボール箱への梱包作業を自動的に実行する自動倉庫,,,, ,,の導入が決定された。また、B社の経営者層は、旧基幹システムから新システム（以下、Nシステムという）への刷,,,, ,,新を計画した。,,,, ,,,,,, 平成２８年度　問２　情報システムの移行方法,,,,,, ,,,,,, ,　情報システムの機能強化のために、新たに開発した情報システム（以下、新システムという）を稼働させる場合、現,,,,, ,在稼働している情報システム（以下、現システムという）から新システムへの移行作業が必要になる。,,,,, ,　システムアーキテクトは、移行方法の検討において、対象業務の特性による制約条件を踏まえ、例えば、次のよう,,,,, ,な情報システムの移行方法を選択する。,,,,, ,,・,多数の利用部門があり、教育に時間がかかるので、利用部門ごとに新システムに切り替える。,,, ,,・,移行当日までに発生したデータを当日中にすべて処理しなければ、データの整合性を維持できないので、全,,, ,,,部門で現システムから新システムに一斉に切り替える。,,, ,,・,障害が発生すると社会的な影響が大きいので、現システムと新システムを並行稼働させる期間を設けた上で,,, ,,,、障害のリスクを最小限にして移行する。,,, ,　また、移行作業後の業務に支障が出ないようにするために、例えば、次のような工夫をすることも重要である。,,,,, ,,・,移行作業が正確に完了したことを確認するために、現システムのデータと新システムのデータを比較する仕組,,, ,,,みを準備しておく。,,, ,,・,移行作業中に遅延や障害が発生した場合に移行作業を継続するかどうかを判断できるように、切り戻しのリ,,, ,,,ハーサルを実施し、所要時間を計測しておく。,,, ,　あなたの経験と考えに基づいて、設問ア～ウに従って論述せよ。,,,,, ,,,,,, ,設問ア,,,あなたが移行に携わった情報システムについて、対象業務の概要、現システムの概要、及び現システムか,, ,,,,ら新システムへの変更の概要について、800字以内で述べよ。,, ,設問イ,,,設問アで述べた情報システムにおいて、対象業務の特性によるどのような制約条件を踏まえ、どのような,, ,,,,移行方法を選択したか。選択した理由とともに、800字以上1600字以内で具体的に述べよ。,, ,設問ウ,,,設問イで述べた情報システムの移行において、移行作業後の業務に支障が出ないようにするために、ど,, ,,,,のような工夫をしたか。想定した支障の内容とともに、600字以上1200字以内で具体的に述べよ。,, ,,,,,, ■ポイント,,,,,, ,,,,,, ,■出題趣旨,,,,, ,,,,,, ,,　情報システムの機能強化のために、新たに開発した情報システムを稼働させる場合、移行作業が必要になる。,,,, ,,システムアーキテクトは、対象業務の特性による制約条件から、情報システムの移行方法を検討する。,,,, ,,　本問では、対象業務の特性による制約条件を踏まえて選択した移行方法と、移行作業後の業務に支障がでな,,,, ,,いようにするための工夫について、具体的に論述することを求めている。論述を通じて、システムアーキテクトに,,,, ,,必要な、情報システムの移行に関わる設計能力と経験を評価する。,,,, ,,,,,, ,■採点講評,,,,, ,,,,,, ,,　全問に共通して、自らの体験に基づき設問に素直に答えている論述が多かった。一方で、問題文に記載してあ,,,, ,,るプロセスや観点などを抜き出し、一般論と組み合わせただけの表面的な論述も引き続き見られた。問題文に記,,,, ,,載したプロセスや観点は例示である。自らが実際にシステムアーキテクトとして、検討し取り組んだことを具体的,,,, ,,に論述してほしい。,,,, ,,　問2（情報システムの移行方法について）では、対象業務の特性による制約条件を踏まえ、どのような移行方法,,,, ,,を選択したか、移行作業後の業務に支障が出ないようにするためにどのような工夫をしたか、を具体的に論述す,,,, ,,ることを期待した。多くの受験者が業務特性を明確に論述していた。一方で、業務特性の記述がなくシステム上,,,, ,,の制約条件を考慮しただけの論述や、対象業務の特性ではなく情報システムの開発プロジェクトの制約を業務,,,, ,,特性としていた論述も見られた。システムアーキテクトには、情報システムが業務でどのように使われているのか,,,, ,,を正しく理解することが求められる。情報システムの設計、開発に当たっては常に業務を意識してほしい。,,,, ,,,,,, ,■解説,,,,, ,,,,,, ,,　稼働中の情報システムから新たに開発した情報システムへの移行がテーマの問題である。,,,, ,,　例えば、法人対象の販売管理システムを個人にも適用できるようにするなど、情報システムの機能を強化した,,,, ,,り、新しく情報システムを開発したりする場合に、現行システムからの移行作業が発生する。移行に際しては、移,,,, ,,行対象の業務の特性に起因する制約条件を踏まえて移行方法を選択することが必要になる。,,,, ,,　システムアーキテクトには、制約条件を踏まえ、一斉以降、段階移行など、様々な方法から最適な移行方法を,,,, ,,選択することが求められる。テーマが移行に限定されているため、移行作業に携わった経験が少ない受験者は、,,,, ,,自身の経験内容を踏まえて慎重に選択する必要がある。,,,, ,,,,,, ,,　設問アでは、「対象業務の概要」、「現システムの概要」、「現システムから新システムへの変更の概要」を記述,,,, ,,する。「対象業務の概要」、「現システムの概要」は、システムアーキテクト試験の設問アにおいて、よく出題される,,,, ,,事項であり、受験者の経験を棚卸するなどしておけば容易に記述できると考えられる。「現システムの概要」であ,,,, ,,るので、新システムについては概要を記述しなくても良いが、「現システムから新システムへの変更の概要」にお,,,, ,,いて触れておいてもよい。,,,, ,,　「現システムから新システムへの変更の概要」については、移行内容について記述するのではなく、システムの,,,, ,,変更内容について記述することに注意が必要である。システムの変更内容そのものは軽く触れておくだけでも十,,,, ,,分であるが、移行方法の選択に関連する部分は適切に記述しておく必要がある。,,,, ,,,,,, ,,　設問イでは、「対象業務の特性による制約条件」、「選択した移行方法と選択した理由」を記述する。問題文には,,,, ,,、複数の例が示されており、制約条件としては、「多数の利用部門がある」、「障害が発生すると社会的な影響が,,,, ,,大きい」となっている。選択した理由としては、「教育に時間がかかる」、「移行当日までに発生したデータを当日中,,,, ,,に全て処理しなければ、データの整合性を維持できない」、「現システムと新システムを並行稼働させる期間を設,,,, ,,ける」を読み取ることができる。移行方法の例としては、「利用部門ごとに新システムに切り替える」、「全部門で現,,,, ,,システムから新システムに一斉に切り替える」、「障害のリスクを最小限にして移行する」である。いずれの受験者,,,, ,,にとっても分かりやすい例となっており、記述しやすかったと考えられる。制約条件、移行方法の選択理由、移行,,,, ,,方法は相互に関連する事項であるため、明確に分けて書きにくければ、採点者が分かるように工夫してまとめて,,,, ,,記述してもよい。,,,, ,,,,,, ,,　設問ウでは、「移行作業後の業務に支障が出ないようにするための工夫」、「想定した支障の内容」を記述する,,,, ,,。設問ウについても問題文に例が示されており、「移行作業が正確に完了したことを確認するために、現システム,,,, ,,のデータと新システムのデータを比較する仕組みを準備しておく」、「移行作業中に遅延や障害が発生した場合に,,,, ,,移行作業を継続するかどうかを判断できるように、切り戻しのリハーサルを実施し、所要時間を計測しておく」とな,,,, ,,っている。工夫点の例は、「データの比較手段を準備する」、「切り戻しのリハーサルを実施して、所要時間を計測,,,, ,,する」が示されている。移行作業において一般的に準備しておく事項であり、要求されている記述内容が明確で,,,, ,,記述しやすかったと考えられる。,,,, ,,　支障の内容の例は、「移行作業中に遅延や障害が発生する」である。問題文に示されている前者の例では支障,,,, ,,の内容が具体的に示されていないため、原因も含めて明確に記述したい。,,,, ,,　要求されている事項が二項目であり、設問ウの最低字数600字を超えるように注意しなければならない。,,,, ,,,,,, ■見出しとストーリー,,,,,, ,,,,,, ,■設問ア,,,,, ,,,,,, ,,設問ア,,,あなたが移行に携わった情報システムについて、対象業務の概要、現システムの概要、及び現システ, ,,,,,ムから新システムへの移行の概要について、800字以内で述べよ。, ,,,,,, ,,　設問アには、対応する問題文がない。自身の経験に基づき要求事項を記述する。,,,, ,,　見出しとストーリーの例を次に示す。,,,, ,,,,,, ,,,ア　対象業務の概要、現システムの概要、及び現システムから新システムへの変更の概要,,, ,,,アー１　対象業務,,, ,,,,,, ,,,,・,対象となる顧客は機械製造業のA社, ,,,,・,A社は、本社を大阪に置き、東京と名古屋に支店、その他主要都市に営業拠点、北近畿に設計拠点と, ,,,,,工場を持つ, ,,,,・,対象となる業務は、A社製品の設計・製造に携わる従業員が携わった様々な作業について工数を把握, ,,,,,し、作業に対する原価を管理する業務, ,,,,・,自身の立場は、今回の移行方法の検討を含め、構築を一括で受注したシステムインテグレータP社に, ,,,,,所属するシステムアーキテクト, ,,,,,, ,,,ア―２　現システムの概要,,, ,,,,,, ,,,,・,移行対象となるシステムは、工数管理システム, ,,,,・,現行のシステムはWebシステムとして構築されている, ,,,,・,サーバは本社情報処理部門が管理し、全社を接続するネットワークシステムを経由して、実績の工数を, ,,,,,入力する社員が利用している, ,,,,・,旧システムもWebシステムであったため、インタフェースは基本的に変更しない, ,,,,・,負荷の高いシステムではないため、現システムでは、データ量、性能面において問題は発生していない, ,,,,・,新システムにおいても、リソースに関連した懸念事項は存在しない, ,,,,・,今回の移行について、制約条件の整理、移行方法の検討、移行手順の作成など、私が全体を取りまと, ,,,,,めることになった。, ,,,,,, ,,,ア―３　現システムから新システムへの変更の概要,,, ,,,,,, ,,,,・,現システムは週単位で工数を管理していたが、工数管理の精度を向上させることを目的に日単位に管, ,,,,,理単位を変更, ,,,,・,日単位に変更すると同時に、工数の情報を勤務管理システムとも連携させる, ,,,,・,勤務管理システムと連動させるため、工数管理システムを使用する社員を全社に拡大する, 、,,,,,, ,■設問イ,,,,, ,,,,,, ,,設問イ,,,設問アで述べた情報システムにおいて、対象業務の特性によるどのような制約条件を踏まえ、どのよう, ,,,,,な移行方法を選択したか。選択した理由とともに、800字以上1600字以内で具体的に述べよ。, ,,,,,, ,,　設問イには、問題文の次の部分が対応する。,,,, ,,,,,, ,,,　システムアーキテクトは、移行方法の検討において、対象業務の特性による制約条件を踏まえ、例えば、次,,, ,,,のような情報システムの移行方法を選択する。,,, ,,,,・,多数の利用部門があり、教育に時間がかかるので、利用部門ごとに新システムに切り替える。, ,,,,・,移行当日までに発生したデータを当日中に全て処理しなければ、データの整合性を維持できないので、, ,,,,,全部門で現システムから新システムに一斉に切り替える。, ,,,,・,障害が発生すると社会的な影響が大きいので、現システムと新システムを並行稼働させる期間を設け, ,,,,,た上で、障害のリスクを最小限にして移行する。, ,,,,,, ,,　見出しとストーリーの例を次に示す。,,,, ,,,,,, ,,,イ　対象業務の特性による制約条件、選択した移行方法と選択した理由,,, ,,,イ―１　対象業務の特性による制約条件,,, ,,,,,, ,,,,・,A社では業績管理が期単位になっており、主管部門からの要望により、新システムの稼働時期は年度, ,,,,,替わりの4月に決定されている, ,,,,・,新システムを利用する範囲が全社に拡大され、一部の部門は現システムを利用しておらず、新システ, ,,,,,ムから利用することになる, ,,,,・,旧システム、新システムとも24時間稼働のシステムではないが、移行作業は夜間に限定される, ,,,,・,勤務管理システムとの連動もあり、運用面の負荷が大きく、新旧のシステムを並行稼働させることは難, ,,,,,しい, ,,,,・,業務プログラムはすべて入れ替えとなり、データベースの移行も必要になるが、基本ソフトウェアの構成, ,,,,,の変更は不要, ,,,,,, ,,,イ―２　選択した移行方法と選択した理由,,, ,,,,,, ,,,,・,移行方法の選択に際し、検討した事項は次の通り, ,,,,,・,全社員に使用範囲を拡大するという点 ,,,,,・,新旧データを保持することが難しいという点 ,,,,,・,新旧データを保持するためには、旧データと新データ間の整合性を確保しなければならず、新たな業 ,,,,,,務プログラムが必要になるという点 ,,,,,・,年度替わりでシステムを切り替えるため、トランザクション系のデータは移行不要 ,,,,,・,マスタ系のデータのみ移行が必要である点 ,,,,・,システムの切替は全社一斉移行とする, ,,,,・,移行時期は年度末の3月31日深夜～4月1日早朝, ,,,,・,夜間バッチ終了後の22時～翌４時までの6時間が移行期間, ,,,,・,移行作業終了後、翌営業開始時刻までに複数の現場で新システムのテストを実施する, ,,,,・,年度末の処理に関連して、旧システムのデータは参照専用として1カ月程度保持する, ,,,,,, ,■設問ウ,,,,, ,,,,,, ,,設問ウ,,,設問イで述べた情報システムの移行において、移行作業後の業務に支障が出ないようにするために、, ,,,,,どのような工夫をしたか。想定した支障の内容と共に、600字以上1200字以内で具体的に述べよ。, ,,,,,, ,,　設問ウには、問題文の次の部分が対応する。,,,, ,,,,,, ,,,　また、移行作業後の業務に支障が出ないようにするために、例えば、次のような工夫をすることも重要であ,,, ,,,る。,,, ,,,,・,移行作業が正確に完了したことを確認するために、現システムのデータと新システムのデータを比較す, ,,,,,る仕組みを準備しておく。, ,,,,・,移行作業中に遅延や障害が発生した場合に移行作業を継続するかどうかを判断できるように、切り戻, ,,,,,しのリハーサルを実施し、所要時間を計測しておく。, ,,,,,, ,,　見出しとストーリーの例を次に示す。,,,, ,,,,,, ,,,ウ　想定した支障の内容と移行作業後の業務に支障が出ないようにするための工夫,,, ,,,ウ―１　想定した支障の内容,,, ,,,,,, ,,,,・,移行作業において想定される支障としては、何らかの理由によって移行作業が遅延し、予定していた時, ,,,,,刻に移行が終了しないこと, ,,,,・,移行作業が完了しないと、翌日からの業務に直接影響する部分があるため、利用部門による確認テス, ,,,,,ト完了を待つ必要がある, ,,,,・,確認テストの時間は最大でも1時間程度とみているが、早朝に行う利用部門の作業のため2時間の枠を, ,,,,,確保している, ,,,,,, ,,,ウ―２　移行作業後の業務に支障がでないようにするための工夫,,, ,,,,,, ,,,,・,移行時のトラブルを少なくするため、新システム用のマスタデータについては、マスタデータの変更を移, ,,,,,行本番の1週間前に凍結する, ,,,,・,本番稼働の2週間前にリハーサルを行い、作業手順の確認と机上で見積もった移行作業時間の確認を, ,,,,,行う, ,,,,・,ユーザテストを除く移行時間の見積りは6時間で、うち1時間は余裕時間として確保してある, ,,,,・,切り戻しには、移行開始から切り戻し開始までの時間に相応する時間が必要と考えられるため、移行開, ,,,,,始から3時間経過後の時点で30分以上遅延していれば移行を中止し、切り戻しを行う, ,,,,・,移行作業手順、切り戻し手順ともに詳細なチェックリストを作成し、複数人体制で移行作業を進める, ,,,,・,切り戻し作業についても、手順通り作業ができることを確認するため、休日を活用してダミーの移行作, ,,,,,業を行い、切り戻し作業も問題なく実施できることを確認する, ,,,,・,併せて切り戻しのための時間についても計測しておく, ,,,,,, ■解答,,,,,, ,,,,,, ,ア　対象業務の概要、現システムの概要、及び現システムから新システムへの変更の概要,,,,, ,ア―１　対象業務,,,,, ,,,,,, ,,　私は、今回の移行方法の検討を含め、構築を一括で受注したシステムインテグレータP社に所属するシステム,,,, ,,アーキテクトである。今回、システムの移行方法を検討した顧客は、機械製造業のA社である。A社は、本社を,,,, ,,大阪位に置き、東京と名古屋に支店、その他主要都市に営業拠点、北近畿に設計拠点と工場を持っている。,,,, ,,対象となる業務は、A社製品の設計・製造に携わる従業員が携わった様々な作業について工数を把握し、作業,,,, ,,に対する原価を管理する業務である。,,,, ,,,,,, ,ア―２　現システムの概要,,,,, ,,,,,, ,,　移行対象となるシステムは、工数管理システムである。現行のシステムはWebシステムとして構築されていて、,,,, ,,サーバは本社情報処理部門が管理し、全社を接続するネットワークシステムを経由して、実績の工数を入力する,,,, ,,社員が利用している。A社の社員が利用するシステムは大半がWebシステムであり、新システムもユーザインタフ,,,, ,,ェースはWebシステムとするため、操作性の面で社員が戸惑うことはないものと予想される。,,,, ,,　今回の移行について、制約条件の整理、移行方法の検討、移行手順の作成など、私が全体を取りまとめること,,,, ,,になった。,,,, ,,,,,, ,ア―３　現システムから新システムへの変更の概要,,,,, ,,,,,, ,,　現システムは週単位で工数を管理していたが、工数管理の精度を向上させることを目的に日単位に管理単位,,,, ,,を変更する。日単位に変更すると同時に、工数の情報を勤務管理システムとも連携させ、工数管理システムを使,,,, ,,用する社員を全社に拡大する。,,,, ,,,,,, ,イ　対象業務の特性による制約条件、選択した移行方法と選択した理由,,,,, ,イ―１　対象業務の特性による制約条件,,,,, ,,,,,, ,,　A社では業務管理を期単位で行っており、新システムの稼働時期について、主管部門からの要望により年度替,,,, ,,わりの4月に決定されている。新システムを利用する範囲が、設計・製造部門の社員から全社員に拡大されること,,,, ,,になった事により、現システムを利用していない設計・製造部門以外の社員は、新システムから利用することにな,,,, ,,る。,,,, ,,　勤務管理システムとの連動が予定されており、運用面の負荷が大きいため、新旧のシステムを並行稼働させる,,,, ,,ことは難しいと運用部門からの意見が上がっている。業務プログラムはすべて入れ替えとなり、データベースの移,,,, ,,行も必要になるが、基本ソフトウェアの構成の変更は不要である。,,,, ,,,,,, ,イ―２　選択した移行方法と選択した理由,,,,, ,,,,,, ,,　私が移行方法を選択することに際し、検討した事項および理由は次の通りである。,,,, ,,,・,全社員に使用範囲を拡大するという点,, ,,,・,新旧データを保持することが難しいという点,, ,,,・,新旧データを保持するためには、旧データと新データ間の整合性を確保しなければならず、新たな業務プ,, ,,,,ログラムが必要になるという点,, ,,,・,年度替わりでシステムを切り替えるため、トランザクション系のデータは移行不要である点,, ,,,・,マスタ系のデータのみ移行が必要である点,, ,,　私はこれらの制約条件を踏まえ、システムの切替は全社一斉移行とした。移行時期は年度末の3月31日深夜,,,, ,,～4月1日早朝とし、移行に割り当てる時間帯は、夜間バッチ終了後の22時～翌4時までの計6時間とした。移行,,,, ,,作業に加え、移行作業終了後、翌営業開始時刻までに複数の現場で新システムのテストを実施する必要がある,,,, ,,。,,,, ,,　旧システムについて、年度末の処理に関連して、旧システムのデータは参照専用として1カ月程度保持すること,,,, ,,が利用部門の要求で決定された。,,,, ,,,,,, ,ウ　想定した支障の内容と移行作業後の業務に支障が出ないようにするための工夫,,,,, ,ウ―１　想定した支障の内容,,,,, ,,,,,, ,,　私が想定した移行作業における支障としては、何らかの理由によって移行作業が遅延し、予定した時刻に移行,,,, ,,が終了しないことである。移行作業の完了が確認できず所定の時刻に新システムが稼働しないと、翌日からの業,,,, ,,務に直接影響する部分があるため、利用部門による確認テスト完了を待つ必要もあった。確認テストの時間は最,,,, ,,大でも1時間程度と想定しているが、早朝に行う利用部門の作業のため万一のことを考え2時間の枠を確保して,,,, ,,いる。,,,, ,,,,,, ,ウ―２　移行作業後の業務に支障が出ないようにするための工夫,,,,, ,,,,,, ,,　私は、移行時のトラブルを少なくするため、新システム用のマスタデータについては、マスタデータの変更を移行,,,, ,,本番の1週間前に凍結することとし、利用部門と合意した。また、本番稼働の2週間前にリハーサルを行い、作業,,,, ,,手順の確認と机上で見積もった移行作業時間の確認を行う対策を盛り込んだ。,,,, ,,　ユーザテストを除く移行時間の見積りは6時間で、うち1時間は余裕時間として確保してある。切り戻しには、移,,,, ,,行開始から切り戻し開始までの時間に相応する時間が必要と考えられるため、移行開始から3時間経過後の時,,,, ,,点で30分以上遅延していれば移行を中止し、切り戻しを行うことにした。,,,, ,,　私は、移行作業手順、切り戻し作業手順ともに詳細なチェックリストを作成し、複数人体制で移行作業を進め、ミ,,,, ,,スの防止に努めるようにした。切り戻し作業についても、手順通り作業ができることを確認するため、リハーサル,,,, ,,日以前の休日を活用してダミーの移行作業を行い、手順書に従って切り戻し作業も問題なく実施できることを確,,,, ,,認することとした。併せて、切り戻しのための必要となる時間を計測し、移行本番のスケジュールに影響が出ない,,,, ,,ことを確認し、移行作業が滞りなく終了できることの見極めを行った。　以上,,,, ,,,,,, 平成２９年度　問１　非機能要件を定義するプロセスについて,,,,,, ,,,,,, ,　情報システムは、非機能要件の考慮漏れによって重大な障害を引き起こすことがある。非機能要件とは、信頼性,,,,, ,を含む品質要件、運用・操作要件など、機能要件以外の要件のことである。利用者は非機能要件を明確に認識して,,,,, ,いないことが多いので、システムアーキテクトは、利用者を含む関連部門へのヒアリングによって必要な情報を収集,,,,, ,する。収集した情報を基に、業務及び情報システム両方の視点から非機能要件を検討し、検討結果を意思決定者,,,,, ,に提示し、判断してもらう。,,,,, ,　例えば、信頼性要件の場合、次のようなプロセスで検討する。,,,,, ,,・,リスクを洗い出し、想定される損失並びに事業及び業務への影響を分析する。,,, ,,・,分析結果に基づき、目標とすべき復旧時間を設定する。,,, ,,・,設定した復旧時間を達成するための情報システムの実現方式を具体化する。,,, ,　その際、前提となるシステム構成、開発標準、システム運用形態など、非機能要件を定義するに当たって制約とな,,,,, ,る事項を示したうえで、例えば次のように、意思決定者に判断してもらうための工夫をすることも必要である。,,,,, ,,・,複数のシステム構成方式について、想定される損失と、対策に必要なコストの比較を示す。,,, ,,・,信頼性を向上させるためにデュアルシステム方式にすると効率性の指標の一つであるスループットが下がる、,,, ,,,といった非機能要件間でのトレードオフが生じる場合、各非機能要件の関係性を示す。,,, ,,,,,, ,設問ア,,,あなたが要件定義に携わった情報システムについて、対象業務の概要と情報システムの概要を、800字以,, ,,,,内で述べよ。,, ,設問イ,,,設問アで述べた情報システムについて、どのような非機能要件を、業務及び情報システム両方のどのよう,, ,,,,な観点から、どのようなプロセスで検討したか。検討した結果とともに、800字以上1600字以内で具体的に,, ,,,,述べよ。,, ,設問ウ,,,設問イで述べた非機能要件の検討の際、意思決定者に判断してもらうためにどのような工夫をしたか。600,, ,,,,字以上1200字以内で具体的に述べよ。,, ,,,,,, ■解説,,,,,, ,,,,,, ,■出題趣旨,,,,, ,,,,,, ,,　情報システムは、非機能要件の考慮漏れがあると、本稼働後に重大な障害を引き起こすことがある。システム,,,, ,,アーキテクトは、非機能要件を適切に定義しなければならない。,,,, ,,　本問は、システムアーキテクトが、非機能要件を業務及び情報システム両方のどのような視点から、どのような,,,, ,,プロセスで検討したか、また、意思決定者に判断してもらうためにどのような工夫をしたのかを、具体的に論述す,,,, ,,ることを求めている。論述を通じて、システムアーキテクトに必要な非機能要件を定義する能力と経験、意思決定,,,, ,,者へ説明する能力を評価する。,,,, ,,,,,, ,■採点講評,,,,, ,,,,,, ,,　全問に共通して、自らの体験に基づき設問に素直に答えている論述が多く、問題文に記載してあるプロセスや,,,, ,,観点などを抜き出し、一般論と組み合わせただけの表面的な論述は少なかった。一方で、実施事項だけの論述,,,, ,,にとどまり、実施した理由や検討の経緯が読み取れない論述も見受けられた。自らが実際にシステムアーキテク,,,, ,,トとして、検討し取り組んだことを具体的に論述してほしい。,,,, ,,,,,, ,■解説,,,,, ,,,,,, ,設問ア,,,あなたが要件定義に携わった情報システムについて、対象業務の概要と情報システムの概要を、800字以,, ,,,,内で述べよ。,, ,,,,,, ,,●設問アに対応する問題文,,,, ,,,,,, ,,,　設問アに対応する問題文はない。論述する事例に基づき要求事項を記述する。,,, ,,,,,, ,,●ストーリー作成のポイント,,,, ,,,,,, ,,,　設問アの要求事項は、,,, ,,,,,, ,,,,・,対象業務の概要, ,,,,・,情報システムの概要, ,,,,,, ,,,となっている。問題文には要件定義を行った業務や情報システムを特徴づける記述がなく、どのような事例,,, ,,,であっても論文の題材にできる。特定の業務に依存する問題ではないため、取り組みやすい問題であったと,,, ,,,考えられる。この問題は、業務要件を定義するプロセス記述が中心になるため、情報システムの概要は簡単,,, ,,,に触れる程度でもよい。ただし、対象の要件が非機能要件であることには注意が必要である。,,, ,,,,,, ,,●ストーリー,,,, ,,,,,, ,,,ア　対象業務の概要、情報システムの概要,,, ,,,ア―１　対象業務の概要,,, ,,,,,, ,,,,・,対象となる顧客は中古パソコンをリサイクルして販売するA社, ,,,,・,A社は大阪に本社と整備工場を置き、東京と名古屋に営業拠点を構えている, ,,,,・,A社は買い取ったパソコンを、リソースの増強・掃除などを行って一般顧客に販売, ,,,,・,買取も販売も基本的にWeb環境で行い、パソコンの運搬は大手業者に委託, ,,,,・,対象とする業務は、中古パソコンの販売業務, ,,,,・,自身の立場は、今回のシステム開発を取りまとめる情報システム部門に所属するシステムアーキテクト, ,,,,,, ,,,ア―２　情報システムの概要,,, ,,,,,, ,,,,・,対象となる情報システムは販売管理システム, ,,,,・,Webサイトのレスポンスが悪いという利用者からの意見が増えてきて、リソースの増強を含めたシステム, ,,,,,の刷新を行うこととなった, ,,,,・,販売管理システムは外部のデータセンタに配置し、リモートで管理・運用を行う, ,,,,・,中古パソコンの買い取り部門が使用する商品管理システムとデータ連携をする, ,,,,・,Webシステムで構成され、アプリケーションサーバ、データベースサーバ、クライアントで構成, ,,,,,, ,,●論文作成のポイント,,,, ,,,,,, ,,,　設問アの要求事項は、「対象業務と概要」「情報システムの概要」の2点である。いずれの事項ともシステム,,, ,,,アーキテクト試験の設問アとして定番に要求される事項である。一般的な設問アでは、定番に要求される事項,,, ,,,以外にも要求事項があるが、この設問では定番の要求事項のみとなっている。事前に準備しておくことができ,,, ,,,る部分となっていて、設問アを記述する時間の短縮が可能である。設問イの要求事項が非機能要件の検討で,,, ,,,あり、性能や信頼性などの非機能要件がポイントになるような事例を取り上げたい。非機能要件は広範囲に,,, ,,,わたるため、設問イで記述する非機能要件を踏まえて設問アを記述するとよい。,,, ,,,,,, ,設問イ,,,設問アで述べた情報システムについて、どのような非機能要件を、業務及び情報システム両方のどのよう,, ,,,,な観点から、どのようなプロセスで検討したか。検討した結果とともに、800字以上1600字以内で具体的に,, ,,,,述べよ。,, ,,,,,, ,,●設問イに対応する問題文,,,, ,,,,,, ,,,利用者は非機能要件を明確に認識していないことが多いので、システムアーキテクトは、利用者を含む関連,,, ,,,部門へのヒアリングによって必要な情報を収集する。収集した情報を基に、業務及び情報システム両方の視,,, ,,,点から非機能要件を検討し、検討結果を意思決定者に提示し、判断してもらう。,,, ,,,　例えば、信頼性要件の場合、次のようなプロセスで検討する。,,, ,,,,・,リスクを洗い出し、想定される損失並びに事業及び業務への影響を分析する。, ,,,,・,分析結果に基づき、目標とすべき復旧時間を設定する。, ,,,,・,設定した復旧時間を達成するための情報システムの実現方式を具体化する。, ,,,,,, ,,●ストーリー作成のポイント,,,, ,,,,,, ,,,　設問イの要求事項は、,,, ,,,,,, ,,,,・,対象となる非機能要件と検討の視点, ,,,,・,非機能要件の検討プロセス, ,,,,・,検討した結果, ,,,,,, ,,,となっている。非機能要件は、「使いやすい」とか「動作が速い」のように定性的に表現されることが多く、利用,,, ,,,者も「大体このような感じ」という意識でいることがある。システムアーキテクトは、設計・実装フェーズのインプ,,, ,,,ットとなるような形式で、非機能要件を定義しなければならない。,,, ,,,　問題文には「利用者を含む関連部門へのヒアリングによって必要な情報を収集する」と示されており、利用,,, ,,,部門へのヒアリング結果は必ず記述しなければならない。非機能要件の検討については、「業務及び情報シ,,, ,,,ステム両方の視点から非機能要件を検討し」と指示されていて、複数の側面からの検討が必要である。問題,,, ,,,文に示されている非機能要件の検討プロセスの例の中に、「目標とすべき復旧時間を設定」、「情報システム,,, ,,,の実現方式を具体化」という記述があり、非機能要件を検討する視点の参考にできる。非機能要件の検討プ,,, ,,,ロセスについては、問題文に箇条書きで例が示されているので、検討プロセスとして出題者が要求している粒,,, ,,,度と記述すべきレベルの参考にしたい。,,, ,,,,,, ,,●ストーリー,,,, ,,,,,, ,,,イ　対象となる非機能要件と検討の視点、非機能要件の検討プロセス、検討した結果,,, ,,,イ―１　対象となる非機能要件と検討の視点,,, ,,,,,, ,,,,・,対象となる非機能要件は性能, ,,,,・,取り扱う中古パソコンは、大手メーカ系のパソコンの他BTOなどによってカスタマイズしたパソコンも含ま, ,,,,,れる, ,,,,・,大手メーカのパソコンのコモディティ化が進み、メーカにこだわりのある顧客を除き、中古パソコンの購, ,,,,,入を希望する顧客は価格対性能比を重視する, ,,,,・,A社は独自に中古パソコンのリソースを増強して販売しており、業務面の検討事項としては、利用する顧, ,,,,,客にとって希望する中古パソコンを素早く検索できることが重要, ,,,,・,システム面の検討事項としては、顧客が不満を抱かない応答速度を実現することが必要, ,,,,・,ただし、具体的な数値として多くの一般顧客の声を収集することは難しい, ,,,,,, ,,,イ―２　非機能要件の検討プロセス,,, ,,,,,, ,,,,・,A社の中古パソコンはカスタマイズされたものであるため、顧客がメーカの製品であっても名称とか型名, ,,,,,で商品を検索することは少なく、仕様に対する条件検索が行われることが大半, ,,,,・,顧客のアクセスログを解析すると、どのような操作で最終的に希望するパソコンを発見したかが分かる, ,,,,・,ただし、インタラクティブな操作を伴うため、操作手順が不明確な場合もある, ,,,,・,顧客の速度感には主観的な部分もあるため、要件として数値化するために顧客へのアンケートも併用, ,,,,,する, ,,,,・,現行の販売管理システムを併用してA社から中古パソコンを購入する顧客、もしくは購入を検討している, ,,,,,顧客のアンケートを収集する, ,,,,・,アンケートに回答した顧客に対しては、中古パソコンを購入する際に利用できる割引クーポンを発行す, ,,,,,ることで、アンケート回収率の向上を図る, ,,,,・,割引クーポンについては、営業部門の了解を得ておく, ,,,,・,応答速度は時々刻々変化するため、現行システムの運用管理部門に応答速度の管理レポートの提示, ,,,,,を受けるとともに、ヒアリングを行い応答速度が低下した要因の分析結果を確認する, ,,,,・,業務面からの対応：主に性能面で不満を感じた操作について、アンケート結果とアクセスログを突き合, ,,,,,わせることによって、顧客が不満を抱く応答速度の範囲を明確化する, ,,,,・,システム面からの検討：顧客が満足する応答速度を確保できるようにするためのリソースの増強計画を, ,,,,,立てる, ,,,,,, ,,,イー３　検討した結果,,, ,,,,,, ,,,,・,顧客が満足する応答速度は3秒以下であることが明確になる, ,,,,・,あらゆる負荷条件下で応答速度を3秒以下にすることは困難であるため、全トランザクションの98％の, ,,,,,範囲で応答速度を3秒以下とする, ,,,,,, ,,●論文作成のポイント,,,, ,,,,,, ,,,　設問イ全体で800字以上記述しなければならない。「検討した結果」については、記述量が多くならないと考,,, ,,,えられるので、「対象となる非機能要件と検討の視点」と「非機能要件の検討プロセス」の部分を手厚く記述す,,, ,,,る必要がある。,,, ,,,　「対象となる非機能要件と検討の視点」について、検討の中核とする非機能要件をまず明示する。非機能要,,, ,,,件を複数取り上げることも可能である。ただし、多くの非機能要件を取り上げると、内容が発散してしまう恐れ,,, ,,,があるため、記述する非機能要件は一つに絞る方が良いと考えられる。ヒアリングの結果を先に示し、ヒアリ,,, ,,,ングの結果を基に、業務面と情報システム面の両側面からの検討の視点を述べる。利用部門に対するヒアリ,,, ,,,ングの結果は業務面、情報システム部門に対するヒアリングの結果は情報システム面のように記述するとよ,,, ,,,い。,,, ,,,　「非機能要件の検討プロセス」については、問題のテーマとなっており、この問題では中核になる部分である,,, ,,,。問題文に箇条書きで示されているプロセスを参考に、掘り下げて記述するようにしたい。,,, ,,,,,, ,設問ウ,,,設問イで述べた非機能要件の検討の際、意思決定者に判断してもらうためにどのような工夫をしたか。600,, ,,,,字以上1200字以内で具体的に述べよ。,, ,,,,,, ,,●設問ウに対応する問題文,,,, ,,,,,, ,,,　その際、前提となるシステム構成、開発標準、システム運用形態など、非機能要件を定義するに当たって制,,, ,,,約となる事項を示したうえで、例えば次のように、意思決定者に判断してもらうための工夫をすることも必要で,,, ,,,ある。,,, ,,,,・,複数のシステム構成方式について、想定される損失と、対策に必要なコストの比較を示す。, ,,,,・,信頼性を向上させるためにデュアルシステム方式にすると効率性の指標の一つであるスループットが, ,,,,,下がる、といった非機能要件間でのトレードオフが生じる場合、各非機能要件の関係性を示す。, ,,,,,, ,,●ストーリー作成のポイント,,,, ,,,,,, ,,,　設問ウの要求事項は、,,, ,,,,,, ,,,,・,非機能要件を意思決定者に判断してもらうための工夫, ,,,,,, ,,,となっている。意思決定者の立場によって判断する内容も変わってくると考えられるので、意思決定者につい,,, ,,,ても明示する必要がある。工夫といっても奇をてらう必要はなく、問題文に示されているように、判断材料とな,,, ,,,る複数案の比較結果の提示、トレードオフが生じる場合の関係性の提示などで十分と考えられる。一般的な,,, ,,,工夫としては、わかりやすく説明するための図表の活用、比較が容易になるようにするための数値による比較,,, ,,,なども考えられる。取り上げる非機能要件に合わせて使い分ければよい。,,, ,,,　問題文には「前提となるシステム構成、開発標準、システム運用形態など、非機能要件を定義するに当たっ,,, ,,,て制約となる事項を示したうえで」と示されており、明示的に制約事項を述べる必要もある。,,, ,,,,,, ,,●ストーリー,,,, ,,,,,, ,,,ウ　非機能要件を意思決定者に判断してもらうための工夫,,, ,,,,,, ,,,,・,非機能要件を判断してもらう意思決定者は、CIOと情報システム部門長, ,,,,・,検討結果の「98％のトランザクションについて応答速度3秒以下」を直接示しても、意思決定者の理解度, ,,,,,は低い, ,,,,・,工夫点の一つ目は、利用者の声であることを提示, ,,,,・,アンケート結果をグラフ、表などにまとめ、多くの利用者が期待する応答速度であることを示す, ,,,,・,応答速度3秒以下を達成するトランザクションが、100％でなく98％であることについては、3秒以上の応, ,,,,,答速度になった事例を示し、3秒以上になることをゼロにするのが実現困難であることを示す, ,,,,・,工夫点の二つ目は、3秒以下の応答速度と5秒程度の応答速度の差を具体的に提示する, ,,,,・,提示方法としては、画面遷移のみを確認できるプロトタイプを作成する, ,,,,・,応答速度が3秒以下のものと5秒程度の二つのプロトタイプを作成し、応答速度の差を体感いただく, ,,,,・,最も応答速度が悪くなる可能性のある画面遷移について、顧客がどのような場面で利用する画面であ, ,,,,,るかを説明することによって、必要性を強調する, ,,,,・,工夫点の三つめは、運用管理部門のメンバに支援を要請し、リソースの増強の必要性について、増強, ,,,,,しない場合とする場合の差を明示してもらうことによって、意思決定者の了解を得る, ,,,,・,提案した性能に関する非機能要件「98％のトランザクションについて応答速度3秒以下」は意思決定者, ,,,,,に承認を得ることができ、後続の工程に進む事ができた, ,,,,,, ,,●論文作成のポイント,,,, ,,,,,, ,,,　非機能要件を複数取り上げる場合、非機能要件ごとに工夫点を示すことができるのであれば、意思決定者,,, ,,,に判断してもらうための工夫点を記述してもよいし、最終的には全体として意思決定者に非機能要件の定義,,, ,,,内容の承認を受けるため、非機能要件を分割せず、全体的な判断を仰ぐための説明上の工夫点を述べても,,, ,,,よい。非機能要件を一つだけ取り上げる場合は、設問ウの要求事項が一つだけであるため、設問ウで最低限,,, ,,,記述すべき600字を超えるように注意しなければならない。,,, ,,,,,, ■解答例,,,,,, ,,,,,, ,ア　対象業務の概要、情報システムの概要,,,,, ,アー１　対象業務の概要,,,,, ,,,,,, ,,　私は、中古パソコンを修理・リサイクルして販売するA社の情報システム部門に所属するシステムアーキテクトで,,,, ,,ある。A社は大阪に本社と整備工場・流通センタを置き、東京と名古屋に営業拠点を構えている。A社のリサイク,,,, ,,ルは、顧客や法人から買い取った中古パソコンを修理し、パソコンのリソースを最新のソフトウェアが稼働できる,,,, ,,ようにリソースの増強を行い、掃除して一般顧客に販売している。中古パソコンの買取も販売も基本的にWeb環,,,, ,,境で行っており、実際の引き取りや配送などは大手の物流会社に委託している。私は今回のシステム開発を取り,,,, ,,まとめることとなった。,,,, ,,,,,, ,アー２　情報システムの概要,,,,, ,,,,,, ,,　論述の対象とする情報システムは、中古パソコンの販売管理システムである。最近、Webサイトのレスポンスが,,,, ,,悪いという利用者からの意見が増加傾向にある。中古パソコンの販売は、低価格を維持することが重要で、利益,,,, ,,率は低い。競合他社との差別化も難しい面があり、リソースの増強を含めシステムの刷新を行うことになった。,,,, ,,現状の販売管理システムは外部のデータセンタに置いており、リモートでシステムの管理・運用を行っている。,,,, ,,刷新する販売管理システムも同様の運用を継続する予定である。販売管理システムは、中古パソコンの買取部,,,, ,,門が使用する商品管理システムとデータ連携を行っている。販売管理システムは、Webシステムとして構築されて,,,, ,,おり、主な構成機器は、アプリケーションサーバ、データベースサーバ、クライアントなどである。,,,, ,,,,,, ,イ　対象となる非機能要件と検討の視点、非機能要件の検討プロセス、検討した結果,,,,, ,イー１　対象となる非機能要件と検討の視点,,,,, ,,,,,, ,,　対象となる非機能要件は性能である。取り扱う中古パソコンは、大手メーカ系のパソコンに加え、主に通販専門,,,, ,,ショップが販売するパソコンも含まれ、通販専門ショップのパソコンはBTOなどによってカスタマイズされていること,,,, ,,が多い。大手メーカのパソコンについては、コモディティ化が進んでおり、特定のメーカにこだわりを持つ顧客を除,,,, ,,き、中古パソコンの購入を希望する顧客はコストパフォーマンスを重視する傾向が強い。A社は独自に中古パソコ,,,, ,,ンのリソースを増強してから販売する点が他社との差別化になっている。業務面の検討事項としては、Webサイト,,,, ,,を利用する顧客にとって、希望する中古パソコンを素早く検索できることが重要である。システム面の検討事項と,,,, ,,しては、顧客が不満を抱かない応答速度を実現することが必要不可欠といえる。ただし、具体的な数値として多く,,,, ,,の一般顧客の声を収集することは難しいのが現状である。,,,, ,,,,,, ,イー２　非機能要件の検討プロセス,,,,, ,,,,,, ,,　A社が販売する中古パソコンは、リソースの増強などカスタマイズされたものであるため、大手メーカの製品であ,,,, ,,っても、顧客が名称とか型名などで商品を検索することは少ない。購入を希望する顧客は、仕様に対して条件検,,,, ,,索をすることが大半であることが、過去の実績で明確になっている。顧客のアクセスログを解析すると、どのよう,,,, ,,な操作で最終的に希望する中古パソコンを発見したかを調査することができる。ただし、中古パソコンの検索はイ,,,, ,,ンタラクティブな操作を伴うため、操作手順が不明確な場合もあり、すべての購入までの手順が明確になるもので,,,, ,,はない。,,,, ,,　非機能要件の性能について、顧客の速度感には主観的な部分もあるため、私は要件として数値化するために,,,, ,,顧客へのアンケートも併用することとした。現行の販売管理システムを利用してA社から中古パソコンを購入する,,,, ,,顧客、もしくは購入を検討している顧客にアンケートの協力を仰ぎ、性能に関する情報を収集する。アンケートに,,,, ,,協力いただけた顧客に対しては、中古パソコンを購入する際に利用できる割引クーポンを発行することで、アンケ,,,, ,,ートの回収率の向上を図る施策を導入した。割引クーポンについては、情報システム部門の一存で発行できない,,,, ,,ため、事前に営業部門の了解を得ておいた。応答速度は時々刻々変化するため、現行システムの運用管理部門,,,, ,,に応答速度の管理レポートの提示を受けるとともに、ヒアリングを行い応答速度が低下した要因の分析結果を確,,,, ,,認することとした。,,,, ,,,,,, ,,（１）業務面からの検討,,,, ,,,,,, ,,,　主に性能面で不満を感じた操作について、アンケート結果とアクセスログを突き合わせることによって、顧客,,, ,,,が不満を抱く応答速度の範囲を明確化する。,,, ,,,,,, ,,（２）システム面からの検討,,,, ,,,,,, ,,,　顧客が満足する応答速度を確保できるようにするためのリソースの増強計画を立てる。,,, ,,,,,, ,イー３　検討した結果,,,,, ,,,,,, ,,　顧客が満足する応答速度は3秒以下であることが明確になった。ただし、あらゆる負荷条件下で応答速度を3秒,,,, ,,以下にすることは困難であるため、全トランザクションの98％の範囲で応答速度を3秒以下とする。,,,, ,,,,,, ,ウ　非機能要件を意思決定者に判断してもらうための工夫,,,,, ,,,,,, ,,　今回、非機能要件を判断してもらう意思決定者は、A社のCIOと情報システム部門長である。検討した結果であ,,,, ,,る「98％のトランザクションについて応答速度3秒以下」を意思決定者に直接示しても、意思決定者の理解度は低,,,, ,,いと予想される。私は次のような工夫をすることとした。,,,, ,,　工夫点の一つ目は、利用者の声であることを提示することである。顧客が回答したアンケート結果をグラフ、表,,,, ,,などにまとめ、3秒という応答速度は多くの利用者が期待する応答速度であることを示す。応答速度3秒以下を達,,,, ,,成するトランザクションが、100％でなく98％であることについては、3秒以上の応答速度になった事例を示し、応,,,, ,,答速度が3秒以上になるトランザクションをゼロにすることが実現困難であることを示す。,,,, ,,　工夫点の二つ目は、3秒以下の応答速度と5秒程度の応答速度の差を具体的に提示することである。提示方法,,,, ,,としては、画面遷移のみを確認できるプロトタイプを作成する。具体的には、応答速度が3秒以下のものと5秒程,,,, ,,度の二つのプロトタイプを作成し、応答速度の差を体感いただく。最も応答速度が悪くなる可能性のある画面遷,,,, ,,移について、顧客がどのような場面で利用する画面であるかを説明することによって、5秒程度の応答速度となる,,,, ,,トランザクションの必要性を強調する。,,,, ,,　工夫点の三つめは、運用管理部門のメンバに支援を要請し、リソースの増強の必要性について、増強しない場,,,, ,,合とする場合の差を明示してもらうことである。このことによって、意思決定者の了解を得る。,,,, ,,　提案した性能に関する非機能要件「98％のトランザクションについて応答速度3秒以下」は意思決定者に承認を,,,, ,,得ることができ、後続の工程に進む事ができた。　以上,,,, ,,,,,, 平成２９年度　問２　柔軟性を持たせた機能の設計,,,,,, ,,,,,, ,　販売管理システムにおける販売方法の追加、生産管理システムにおける生産方式の変更など、業務ルールがた,,,,, ,びたび変化する情報システムや業務ソフトウェアパッケージの開発では、様々な変化や要望に対して、迅速かつ低,,,,, ,コストでの対応を可能にする設計、言い換えると柔軟性を持たせた機能の設計が求められる。,,,,, ,　システムアーキテクトは、情報システムの機能に柔軟性を持たせるために、例えば、次のような設計をする。,,,,, ,,,,,, ,,・,”商品ごとに保管する倉庫が一つに決まっている”という多対1の業務ルールを、”商品はどの倉庫でも保管で,,, ,,,きる”という多対多の業務ルールに変更できるように、商品と倉庫の対応を関係テーブルにしておく。,,, ,,・,多様な見積りロジックに対応できるように、複数の見積りロジックをあらかじめ用意しておき、外部パラメタの設,,, ,,,定で選択できるようにしておく。,,, ,,,,,, ,　また、このような柔軟性をもたせた機能の設計では、処理が複雑化する傾向があり、開発コストが増加してしまうこ,,,,, ,とが多い。開発コストの増加を抑えるためには、例えば、次のように対象とする機能や項目を絞り込むことも重要で,,,,, ,ある。,,,,, ,,,,,, ,,・,過去の実績、事業環境の変化、今後の計画などから変更の可能性を見極め、柔軟性を持たせる機能を絞り,,, ,,,込む。,,, ,,・,業務の特性などから、変更可能な項目を絞り込むことで、ロジックを簡略化する。,,, ,,,,,, ,設問ア,,,あなたが設計に携わった情報システムについて、対象業務の概要、情報システムの概要、柔軟性を持た,, ,,,,せた機能の設計が必要になった背景を、800字以内で述べよ。,, ,設問イ,,,設問アで述べた情報システムで、機能に柔軟性を持たせるために、どのような機能に、どのような設計をし,, ,,,,たか。柔軟性の対象にした業務ルールを含めて、800字以上1600字以内で具体的に述べよ。,, ,設問ウ,,,設問イで述べた設計において、開発コストの増加を抑えるために実施した機能や項目の絞り込みについて,, ,,,,、その絞り込みが適切であると考えた理由を、600字以上1200字以内で具体的に述べよ。,, ,,,,,, ■ポイント,,,,,, ,,,,,, ,■出題趣旨,,,,, ,,,,,, ,,　情報システムの開発では、柔軟性を持たせた設計をすることがある。システムアーキテクトは、このような場合、,,,, ,,機能の構造やデータの構造などによって柔軟性を持たせるための設計をする。,,,, ,,　本問は、情報システムの機能に柔軟性を持たせるための設計と、設計の結果、開発コストの増加を抑えるため,,,, ,,に実施した機能や項目の絞り込みとその理由を、具体的に論述することを求めている。論述を通じて、システム,,,, ,,アーキテクトに必要な情報システムの設計能力、業務や情報システムの分析能力、経験を評価する。,,,, ,,,,,, ,■採点講評,,,,, ,,,,,, ,,　全問に共通して、自らの体験に基づき設問に素直に答えている論述が多く、問題文に記載してあるプロセスや,,,, ,,観点などを抜き出し、一般論と組み合わせただけの表面的な論述は少なかった。一方で、実施事項だけの論述,,,, ,,にとどまり、実施した理由や検討の経緯が読み取れない論述も見受けられた。自らが実際にシステムアーキテク,,,, ,,トとして、検討し取り組んだことを具体的に論述してほしい。,,,, ,,　問２（柔軟性を持たせた機能の設計）では、柔軟性を持たせるための設計と、対象にした業務ルールについて,,,, ,,の具体的な論述を期待した。多くの論述は、柔軟性を持たせるための機能の設計内容を具体的に論述していた,,,, ,,。一方で、要求事項又は設計方針だけにとどまり、具体的な設計内容が不明な論述も見受けられた。また、その,,,, ,,設計に当たって、開発コストを抑えるために実施した機能や項目の絞り込みについての論述を期待したが、設計,,,, ,,内容と絞り込みとの関連が薄い論述も見受けられた。システムアーキテクトには、様々な変化や要望に対して、,,,, ,,迅速かつ低コストで対応できる情報システムを設計する能力が求められる。現在の要望だけでなく、将来の変化,,,, ,,も意識した設計を心掛けてほしい。,,,, ,,,,,, ,■解説,,,,, ,,,,,, ,,　柔軟性を持たせた機能の設計がテーマの問題である。,,,, ,,　販売管理システムにおける販売方法の追加、生産管理システムにおける生産方式の変更、在庫管理システム,,,, ,,における在庫管理単位の変更など、業務ルールが変化することが想定される情報システムや業務ソフトウェアパ,,,, ,,ッケージの開発に携わる場合がある。,,,, ,,　システムアーキテクトには、業務ルールの変化が想定される情報システムの開発において、迅速かつ低コスト,,,, ,,で様々な変化に対応できるような設計をすることが求められる。例えば、外部パラメタの設定で業務ロジックを変,,,, ,,更できるようにするなど、機能に柔軟性をもたせる工夫をする。,,,, ,,　柔軟性を持たせた機能の設計について記述できれば良いので、要求される字数の制約を満たすことが出来れ,,,, ,,ば、設計内容を記述する機能は一つであってもよい。数多くの機能について記述しようとすると、内容が発散して,,,, ,,しまう可能性もあるため、ストーリー作成の際によく検討しておく。ただし、設問ウで機能や項目の絞り込みに言及,,,, ,,するため、設問ウで機能の絞り込みを取り上げる場合は、詳細な記述は不要であるが、機能を何点か列挙するこ,,,, ,,とが必要である。,,,, ,,,,,, ,,　設問アでは、「対象業務の概要」、「情報システムの概要」、「柔軟性をもたせた機能の設計が必要になった背景,,,, ,,」を記述する。「対象業務の概要」、「情報システムの概要」については、システムアーキテクト試験の設問アにお,,,, ,,いて、定番となっている要求事項である。受験者の経験をたな卸して、事例を整理し、記述内容を準備しておけば,,,, ,,、容易に記述できると考えられる。「対象業務の概要」と「情報システムの概要」を一つの項目にまとめて記述する,,,, ,,場合は、情報システムの概要の記述に終始しないように注意する。「柔軟性を持たせた機能の設計が必要になっ,,,, ,,た背景」については、システムアーキテクトとして携わる開発工程より前の工程で議論されたり検討されたりする,,,, ,,ことも多いため、論述の対象として取り上げる題材について、背景をよく理解していることの見極めが必要である,,,, ,,。,,,, ,,,,,, ,,　設問イでは、「柔軟性を持たせた機能」、「機能の設計結果」、「柔軟性の対象にした業務ルール」を記述する。,,,, ,,「柔軟性を持たせた機能」と「機能の設計結果」については、取り上げる機能の数に比例して記述量が増えるため,,,, ,,、設問イに割り当てることのできる時間(約40分）を鑑み、機能を取捨選択しよう。「柔軟性を持たせた機能」と「機,,,, ,,能の設計結果」を分割して記述しにくければ一つの項目にまとめて記述してもよい。「柔軟性の対象にした業務ル,,,, ,,ール」については、業務ルールと機能とを一対一に対応させる必要はなく、業務ルールと機能の対応関係が明確,,,, ,,になっていれば、一つの業務ルールを実現するために複数の機能が対応していてもよい。機能と業務ルールの,,,, ,,記述が一組であっても、設問イの要求字数800字以上は記述できると考えられる。,,,, ,,,,,, ,,　設問ウでは、「開発コストの増加を抑えるために実施した機能や項目の絞り込み」、「絞り込みが適切であると考,,,, ,,えた理由」を記述する。開発コストの増加を抑えるために実施した機能や項目の絞り込みについては、機能と項,,,, ,,目の両方について言及する必要はなく、どちらか一方を取り上げればよい。設問の要求事項ではないが、機能や,,,, ,,項目を絞り込む際の判断基準や優先順位などについても触れておきたい。「絞り込みが適切であると考えた理由,,,, ,,」については、システムアーキテクトとしての判断で「絞り込みが正しかった」ということが示されていればよく、理,,,, ,,由そのものを詳細に記載しなくても題意は満たされるものと考えられる。,,,, ,,,,,, ■見出しとストーリー,,,,,, ,,,,,, ,略,,,,, ,,,,,, ■解答,,,,,, ,,,,,, ,ア　対象業務の概要、情報システムの概要、柔軟性を持たせた機能の設計が必要になった背景,,,,, ,アー１　対象業務の概要,,,,, ,,,,,, ,,　私は独立系のシステムインテグレータに所属するシステムアーキテクトである。論述の対象とする顧客のA社は,,,, ,,設備機器メーカで、厨房機器を主力製品としている。A社は東京に本社を置き、主に全国の道府県庁所在地に営,,,, ,,業拠点を構えている。A社の工場は北関東に1か所である。対象とする業務は、A社製品の生産管理業務であり、,,,, ,,部品の管理を行ったり、生産計画を立案したりするなど、製品を効率よく生産することを目的としている。,,,, ,,,,,, ,アー２　情報システムの概要,,,,, ,,,,,, ,,　論述の対象とする情報システムは生産管理システムである。生産管理システムを構成するハードウェアの陳腐,,,, ,,化に伴い、システムの刷新を行うこととなった。生産管理システムはA社の工場で使用されており、営業部門が使,,,, ,,用する受注管理システムと連動する。生産管理システムはWebシステムであり、アプリケーションサーバ、データ,,,, ,,ベースサーバ、クライアントなどから構成されている。現行の生産管理システムの処理能力には余裕があり、新,,,, ,,システムでも同等のリソースとする。,,,, ,,,,,, ,アー３　柔軟性をもたせた機能の設計が必要になった背景,,,,, ,,,,,, ,,　厨房機器に対する顧客のニーズは様々であり、ニーズにきめ細かく対応できるように、A社では従来受注生産,,,, ,,にきめ細かく対応できるように、A社では従来受注生産方式で製品を生産していた。一方、競合他社に対する優,,,, ,,位性を確保するため、営業部門から納期短縮の強い要求がある。新生産管理システムでは、納期短縮を見据え,,,, ,,、製品を構成する一部の部品について、見込み生産方式を採用する。見込み生産方式では対象となる部品が変,,,, ,,更になったり、生産数を求めるロジックが変更になったりする可能性がある。,,,, ,,,,,, ,イ　柔軟性の対象にした業務ルール、柔軟性を持たせた機能と設計内容,,,,, ,イー１　柔軟性の対象にした業務ルール,,,,, ,,,,,, ,,　柔軟性の対象にした業務ルールは、「見込み生産と受注生産の変更を容易にする」と「見込み生産数を導くロジ,,,, ,,ックを容易に変更できるようにする」の二つである。,,,, ,,　「見込み生産と受注生産の変更を容易にする」は、見込み生産する部品を固定とするのではなく、見込み生産,,,, ,,の対象となる部品を追加したり、削除したりすることができるようにするというルールである。納期重視の戦略をと,,,, ,,るのであれば、見込み生産の範囲を拡大し、多くの部品を在庫することになる。逆に部品在庫の削減の戦略をと,,,, ,,るのであれば、従来から行われている受注生産の範囲を拡大する。競合他社や市場の情勢などを鑑み、見込み,,,, ,,生産の範囲の変更を容易にすることとする。,,,, ,,　「見込み生産数を導くロジックを容易に変更できるようにする」というルールについては、見込み生産による納期,,,, ,,短縮を実現するために、見込み生産の導入に際して必須となるルールである。ただし、A社では見込み生産を初,,,, ,,めて取り入れるため、見込み生産のためのノウハウが十分蓄積できていない。したがって、ノウハウの蓄積に伴,,,, ,,い、見込み生産数を求めるロジックも変更していくことが予定されている。,,,, ,,,,,, ,イー２　柔軟性を持たせた機能と設計内容,,,,, ,,,,,, ,,　「見込み生産と受注生産の変更を容易にする」については、対象となる部品を外部のテーブルに登録しておき、,,,, ,,テーブルを更新することで、対象となる部品について見込み生産と受注生産の範囲を容易に変更可とする。,,,, ,,　「見込み生産数を導くロジックを容易に変更できるようにする」については、見込み生産数を導くためのロジック,,,, ,,を細分化しておき、モジュールの組み合わせで実現できるようにすることで対応する。どのモジュールをどのよう,,,, ,,に組み合わせるかを決定するパラメタを外部のテーブルに登録しておき、テーブルを更新することで、見込み生,,,, ,,産数を導くロジックの変更を可能にする。,,,, ,,,,,, ,ウ　開発コストの増加を抑えるために実施した機能や項目の絞り込み、絞り込みが適切であると考えた理由,,,,, ,ウー１　開発コストの増加を抑えるために実施した機能や項目の絞り込み,,,,, ,,,,,, ,,　私が、開発コストの増加を抑えるために絞り込んだ機能は、モジュールの組み合わせを実現するための機能で,,,, ,,ある。当初はモジュールの組み合わせを任意に行えるように検討していた。しかし、自由にモジュールを組み合,,,, ,,わせられるようにするためには、多くのモジュールについて、モジュール間のインタフェースの統一が必要になる,,,, ,,。また、モジュールの組み合わせを指定するためのロジックが複雑になるというデメリットが生じる。私は、開発コ,,,, ,,ストの圧縮をすることと開発期間を短縮することを目的に、モジュールの組み合わせを限定することを決定した。,,,, ,,具体的には、モジュールごとの機能によってモジュールを数種類に分類し、各分類のモジュールを組み合わせて,,,, ,,見込み生産数を求めるロジックを決定する方式とすることとした。,,,, ,,,,,, ,ウー２　絞り込みが適切であると考えた理由,,,,, ,,,,,, ,,　私は機能の絞り込みについて、顧客の了解を得ることを目的として、顧客に対して絞り込みが必要となった理由,,,, ,,、絞り込みを行った後の機能などについて説明した。設計後のレビュ,,,, ,,ーで顧客から、絞り込んだ機能で十分と評価いただけた。,,,, ,,　顧客からの評価に加え、私は絞り込みによる効果を定量的に測定し、計画通りの開発工数削減が実現できる,,,, ,,かどうかを評価した。過去のプロジェクトの事例を参考に削減できる工数を算出すると、モジュールの組み合わせ,,,, ,,方法を限定することで、設計工程において2人月の工数削減ができると考えられた。さらに、後続の実装工程にお,,,, ,,いても3人月の工数削減が見込めることが考えられ、私は、機能の絞り込みによる効果は十分なものと判断した。,,,, ,,以上,,,,