平成23年度　問2　システムテスト計画の策定について,,,,,, ,,,,,, ,　システムアーキテクトは、システムテストの直前だけではなく、様々な局面でシステムテスト計画についての検討を,,,,, ,求められる。その計画の策定において、対象業務の重要度や業務特性を考慮しながら、障害発生時の対応、オンラ,,,,, ,インやバッチのピーク時処理など、テストの重点確認項目を明確にする。重要度や業務特性を考慮した重点確認項,,,,, ,目には、例えば、次のようなものがある。,,,,, ,,,,,, ,,・銀行のATMでの取引業務や小売業のPOSで売上管理業務など重要度が高く、障害発生時にも一定のサービス,,,, ,,　を継続しなければならない業務の場合、円滑に縮退運転に移行できること,,,, ,,・株式の取引業務など処理量が極端に変動する業務の場合、想定する最大のデータ量を処理できることに加え、,,,, ,,　変動するデータ量にも適切に対応できること,,,, ,,,,,, ,　システムテストでは、本番と同じ構成をテスト環境として構築し、十分なテスト期間を設定することで、システムの品,,,,, ,質を確保することが望ましい。しかし、一般的には期間や費用などの制約があるので、その中で効率よくシステムの,,,,, ,品質を確保するシステムテスト計画を策定することが重要であり、例えば、次のような工夫を行う。,,,,, ,,,,,, ,,・限られた期間で、網羅性の高いテストを行うために、月次処理に続けて年次処理を実施できる日付を設定して、,,,, ,,　テストの準備工数を削減する。,,,, ,,・限られた費用で、多くのテストケースを実行するために、自動化ツールを採用して人件費を削減する。,,,, ,,,,,, ,　あなたの経験と考えに基づいて、設問ア～ウに従って論述せよ。,,,,, ,,,,,, ,設問ア,,,あなたが携わったシステムテストにおいて、対象業務と対象システムの概要、及び期間や費用などの制約,, ,,,,について、800字以内で述べよ。,, ,設問イ,,,設問アで述べたシステムのシステムテスト計画を策定する際に、あなたは、どのようなテストの重点確認項,, ,,,,目を設定したか。考慮した業務の重要度や業務特性とともに、800字以上1600字以内で具体的に述べよ。,, ,設問ウ,,,設問イで述べたシステムテスト計画の策定において、制約のある中で効率よくシステムの品質を確保する,, ,,,,ために、あなたが重要と考え工夫した点について、600字以上1200字以内で具体的に述べよ。,, ,,,,,, 【解説】,,,,,, ,,,,,, ,　システムアーキテクト試験において、高い頻度で出題されるシステムテストに関する問題である。過去問題も多いた,,,,, ,め、サンプル論文も多く作成されている。そのため、サンプル論文のトピックを基にすれば、論述しやすい問題と考え,,,,, ,がちだが、サンプル論文のトピックを単純に流用することで合格レベルの点数を得ることは難しい。過去の類似問題と,,,,, ,の違いをしっかりと把握して、相違点を意識しながら、論文を設計することが重要である。論文設計の際に留意すべ,,,,, ,き点は、次のとおりである。,,,,, ,,,,,, ,（１）システムテスト計画を策定する局面を複数にする,,,,, ,,,,,, ,,　問題文は、「システムアーキテクトは、システムテストの直前だけではなく、様々な局面でシステムテスト計画につ,,,, ,,いての検討を求められる」と記述されている。従って、少なくとも二つ以上の局面を想定して論述するとよい。,,,, ,,　開発局面は、要件定義、システム要件定義、システム方式設計、ソフトウェア設計、プログラミング、ソフトウェア,,,, ,,テスト、システム結合、システムテスト、運用テスト、と続くが、システムテストのテスト要件は、一般的にはシステム,,,, ,,要件定義で最初に作成するので、設問イは、システム要件定義の局面を想定して論述する方法がある。,,,, ,,　設問ウは、システムテスト直前のシステム結合などの局面で論述してもよい。,,,, ,,,,,, ,（２）設問イで問うている重点確認項目は、業務の重要度や業務特性を踏まえて論述する,,,,, ,,,,,, ,,　通常は、業務の重要度や業務特性については、設問アで論述するようにするが、この問題では設問イにおいて「,,,, ,,考慮した業務の重要度や業務特性とともに」と明示されているので、設問イで論述してもよい。「考慮した業務の重,,,, ,,要度」、「業務特性」というキーワードを文章の中で使って明示的に論述することが重要である。,,,, ,,,,,, ,　設問文に従って章立てをすると、次のようになる。,,,,, ,,,,,, ,,第1章　対象業務と対象システムの概要及びその制約,,,, ,,,１．１　対象業務と対象システムの概要,,, ,,,１．２　期間や費用などの制約,,, ,,第2章　テストの重点確認項目の設定,,,, ,,,２．１　考慮した業務の重要度と業務特性,,, ,,,２．２　テストの重点確認項目の設定,,, ,,第3章　システムの品質の確保,,,, ,,,３．１　システムの品質を確保する上で重要と考えた課題,,, ,,,３．２　工夫した点,,, ,,,,,, ,　次に各章、節ごとに論述のポイントを説明する。,,,,, ,,,,,, 第1章　対象業務と対象システムの概要及びその制約,,,,,, ,,,,,, ,〔１．１　対象業務と対象システムの概要〕,,,,, ,,,,,, ,,　対象業務と対象システムの区別を曖昧にせず、明示的に論述することが重要である。「対象業務は～」、「対象,,,, ,,システムは～」などと記述するとよい。,,,, ,,,,,, ,,◆論述例,,,, ,,,,,, ,,,第1章　対象業務と対象システムの概要及びその制約,,, ,,,１．１　対象業務と対象システムの概要,,, ,,,,,, ,,,,　論述の対象とする業務は、電子部品を製造・販売するA社における受注業務である。基幹業務である受注,, ,,,,業務では、一部の商品群に受注が集中しているという業務特性があり、集中している商品群の受注業務は,, ,,,,、可能な限り継続する必要があった。,, ,,,,　そのため、対象システムであるWeb受注システムでは、障害発生時には縮退運転に移行が可能である。W,, ,,,,ebサービスとしては商品別に構成され、販売数が多く利益率の高い商品群に障害が発生した場合は、その,, ,,,,他の商品群サービスを停止して、障害で停止した商品群のサービスを引き継ぐ設計となっている。,, ,,,,　なお、従来は電話による受注が多かったが、近年では、Web経由の受注が受注件数の９０％を占めている,, ,,,,。その利用者のほとんどは特約店であり、業務面で忙しい状況が続くため、Webの応答時間の悪化がA社の,, ,,,,顧客からのクレームの６０％を占めている。,, ,,,,,, ,〔１．２　期間や費用などの制約〕,,,,, ,,,,,, ,,　制約については、システムアーキテクトが努力しても解決できない制約を挙げることが重要である。たとえば、期,,,, ,,間が短いという制約について、プロジェクトマネージャに交渉して納期を伸ばした、あるいは、費用が限られている,,,, ,,という制約について、同様に費用を追加したという論旨展開は避けるようにする。,,,, ,,,,,, ,,◆論述例,,,, ,,,,,, ,,,１．２　期間や費用などの制約,,, ,,,,,, ,,,,　A社の競合他社が新たなサービス機能を持つWeb受注システムをリリースしたため、今回のシステム開発,, ,,,,は、それに対応するためのWeb受注システムの機能アップである。そのため、システム開発プロジェクトの発,, ,,,,足からリリースまでの期間が短いというシステム開発の特徴があった。システムテストの期間も短く設定さ,, ,,,,れ、費用面でも、システムテスト期間の短縮を実現するには十分ではなかった。,, ,,,,　私はA社のシステムアーキテクトの立場で、システム要件定義においてシステムテスト計画を策定し、次に,, ,,,,述べるように直前まで工夫してシステムの品質を確保した。,, ,,,,,, 第2章　テストの重点確認項目の設定,,,,,, ,,,,,, ,〔２．１　考慮した業務の重要度と業務特性〕,,,,, ,,,,,, ,,　設問アで述べた業務やシステムの概要を踏まえて、業務の重要度と業務特性、それぞれについて明示的に論,,,, ,,述するようにし、片方だけ論述するということは避ける。なお、重要度や業務特性の例が問題文に挙がっているの,,,, ,,で、それらと違和感のある用語は用いないようにするのがよいだろう。,,,, ,,,,,, ,,◆論述例,,,, ,,,,,, ,,,第2章　テストの重点確認項目の設定,,, ,,,２．１　考慮した業務の重要度と業務特性,,, ,,,,,, ,,,,　要件定義の段階で収拾した業務情報を基に、私は次のような業務の重要度と業務特性を考慮した。,, ,,,,,, ,,,,（１）受注が集中する商品群に対する業務の重要度,, ,,,,,, ,,,,,　Web受注システムでは、受注の集中する商品群については業務の継続が重視されるので、業務の重, ,,,,,要度が高い。万一受注が停止すると、看板商品の受注が競合他社に切り替わり、商品の受注の挽回が, ,,,,,難しい状況に陥る可能性があるからである。, ,,,,,, ,,,,（２）高い応答性が要求される業務特性,, ,,,,,, ,,,,,　Web受注システムを利用して発注する顧客は、特約店が多いという性質上、業務に追われているという, ,,,,,状況であった。そのため、高い応答性が要求され、応答性が悪化すると、直ちにA社の業務部にクレー, ,,,,,ムの電話が来るという状況であった。, ,,,,,, ,,,,　以上の考慮点を踏まえ、次に述べるような項目を設定した。,, ,,,,,, ,〔２．２　テストの重点確認項目の設定〕,,,,, ,,,,,, ,,　この節を設計する上で留意しなければならない点は、この節で述べた内容を設問ウにつないで論旨展開する必,,,, ,,要があるという点である。なぜならば、設問ウにおいて「設問イで述べたシステムテストの計画の策定において」と,,,, ,,明示されているからである。テストの重点確認項目ごとに、品質を確保するために工夫した点を述べることが求め,,,, ,,られていると考える。,,,, ,,　なお、この節で項目を多く挙げてしまった場合は、設問ウでは重要なものに絞り込んで論述するようにして、時間,,,, ,,切れを防止する。,,,, ,,,,,, ,,◆論述例,,,, ,,,,,, ,,,２．２　テストの重点確認項目の設定,,, ,,,,,, ,,,,　システム要件定義の局面において、考慮点を踏まえて私は、システムアーキテクトとして、テストの重点確,, ,,,,認項目を次のように設定した。,, ,,,,,, ,,,,（１）障害発生時は30秒以内に縮退運転に切り替わること,, ,,,,,, ,,,,,　受注が集中する商品群については業務の重要度が高いため、商品群別サービスのうち、重要度の高, ,,,,,い商品群のサービスに障害が発生した場合、一部の重要度が低い商品群のサービスを停止して、重要, ,,,,,度の高い商品群のサービスを復旧させる。この縮退運転への切り替えが30秒以内に完了する旨の重点, ,,,,,確認項目を設定した。なぜならば、まれに30秒応答時間がなくても、利用者は障害の発生とは思わない, ,,,,,と考えたからである。, ,,,,,　ただし、切り替えについては、通常障害の検知から切替まで自動で行われるが、過去の障害事例から, ,,,,,私は何らかの理由で障害を自動検知しないケースを重視した。そこで万一の場合を想定して、手動での, ,,,,,切り替え手順もテスト項目に加えるようにした。, ,,,,,, ,,,,（２）ピーク時間帯においても処理件数の９５％以上に対する応答時間が4秒以内であること,, ,,,,,, ,,,,,　業務特性から見ると、常時高い応答性が要求されることになるが、インターネットを経由する以上、レス, ,,,,,ポンスが１００％いいという状況を生み出すことは困難である。そこで私は、顧客からのクレームの内容, ,,,,,を踏まえ、処理件数の９５％以上に対する応答時間が4秒以内という確認項目を設定した。要件定義で, ,,,,,は、９５％以上に対する応答時間が6秒以内という設定であったが、システムテストでは、これよりも厳し, ,,,,,い値を設定した。なぜならば、クレームの内容を顧客に確認した結果、顧客のインターネット環境に, ,,,,,よっては、かなりの応答性能の悪化が想定されると考えたからである。, ,,,,,　私は、以上の項目を設定して計画を策定し、システム要件定義を終え、システムテストの直前で、具体, ,,,,,的な計画の修正を行うようにした。, ,,,,,, 第3章　システムの品質の確保,,,,,, ,,,,,, ,〔３．１　システムの品質を確保する上で重要と考えた課題〕,,,,, ,,,,,, ,,　設問文では、”課題”については明示的に問うていないが、工夫した点を論述するまえに課題を明示すると、工夫,,,, ,,した点の妥当性をアピールできるので、このような章立てにしている。この節では課題を明示することが重要であ,,,, ,,る。,,,, ,,,,,, ,,第3章　システムの品質の確保,,,, ,,３．１　システムの品質を確保する上で重要と考えた課題,,,, ,,,,,, ,,,　マスタスケジュール通りではあるが、予定通りシステムテストを実施することが、システムテストの前の局面で,,, ,,,あるシステム結合テストのスタート時点で確定した。システム要件定義段階から、期間と費用の面での制約の,,, ,,,下で重点項目を確認するという課題があった。,,, ,,,,,, ,〔３．２　工夫した点〕,,,,, ,,,,,, ,,　工夫をアピールするためには、「工夫した」と記述しただけではアピールできない。困難な状況や、いろいろな案,,,, ,,を検討した展開を論文の中に盛り込むようにする。,,,, ,,,,,, ,,◆論述例,,,, ,,,,,, ,,,３．２　工夫した点,,, ,,,,,, ,,,,　期間と費用の面での制約の下で重点項目を確認するために私が工夫した点は、次の通りである。,, ,,,,,, ,,,,（１）本番環境を用いたテストの実施,, ,,,,,, ,,,,,　障害発生時は30秒以内に縮退運転に切り替わるということについては、まず、テスト環境でシステムテ, ,,,,,ストを実施することを検討した。しかし、テスト環境のサーバの台数が少ないため、テストの実施が困難, ,,,,,であることはシステム要件定義局面においてわかっていた。そこで私は、本番環境において、縮退運転, ,,,,,への切り替えを確認するというテストを計画した。, ,,,,,　具体的には、ピーク時間帯を避けた夜間の時間帯においてシステムテストを実施する計画とした。まず, ,,,,,、受注が少ない商品群のサービスを二つ利用して、一方から他方へのサービスの切り替えが正しく行わ, ,,,,,れることを確認し、次に受注の少ない商品群のサービスを停止して、受注の多い商品群の新規受注分, ,,,,,以降のサービスを引き継ぐ切り替えが正しく行われることを確認するためのテストを計画した。なぜなら, ,,,,,ば、このように分割して段階的に実施することで、本番環境への影響を極小化できると考えたからである, ,,,,,。, ,,,,,　ただし、最悪のケースでも本番環境に影響を与えないことが課題であった。そこで私は、いずれの商品, ,,,,,群についてもテスト用の架空の商品を設定するように工夫した。, ,,,,,, ,,,,（２）負荷ツールと人手を併用したシステムテストの実施,, ,,,,,, ,,,,,　ピーク時間帯においても処理件数の９５％以上に対する応答時間が4秒以内であることを確認する方, ,,,,,法として、①負荷ツール主体、②負荷ツールと人手の併用、という二つの案を検討した。私は、人件費が, ,,,,,増大するとしても、あえて②を採用した。ただし、システムテストにおける機能テストと性能テストを並行し, ,,,,,て実施し、期間を短縮するように計画した。なぜならば、高負荷時にしか顕在化しないバグをこのテスト, ,,,,,で検出して、システムの品質をより高められると考えたからである。, ,,,,,　こうして私は、期間が短く費用が限られているという制約の中で、業務の重要度や業務特性を踏まえな, ,,,,,がら、前述したようなシステムテスト計画を策定してシステムの品質を確保することができた。, ,,,,,, ,●この問題は、「システムテスト計画の策定について」という題である。従って、実施段階で発生した問題や、その問,,,,, ,題への施策について論じると、問題の趣旨に沿わない。この点に留意して、論文の始めから最後まで論述することが,,,,, ,重要である。,,,,, ,,,,,, 平成２３年度　問２　システムテスト計画の策定,,,,,, ,,,,,, ,　システムアーキテクトは、システムテストの直前だけではなく、様々な局面でシステムテスト計画についての検討を,,,,, ,求められる。その計画の策定において、対象業務の重要度や業務特性を考慮しながら、障害発生時の対応、オンラ,,,,, ,インやバッチのピーク時処理など、テストの重点確認項目を明確にする。重要度や業務特性を考慮した重点確認項,,,,, ,目には、例えば、次のようなものがある。,,,,, ,,・,銀行のATMでの取引業務や小売業のPOSでの売上管理業務など重要度が高く、障害発生時にも一定のサー,,, ,,,ビスを継続しなければならない業務の場合、円滑に縮退運転に移行できること,,, ,,・,株式の取引業務など処理量が極端に変動する業務の場合、想定する最大のデータ量を処理できることに加,,, ,,,え、変動するデータ量にも適切に対応できること,,, ,　システムテストでは、本番と同じ構成をテスト環境として構築し、十分なテスト期間を設定することで、システムの品,,,,, ,質を確保することが望ましい。しかし、一般的には期間や費用などに制約があるので、その中で効率よくシステムの,,,,, ,品質を確保するシステムテスト計画を策定することが重要であり、例えば、次のような工夫を行う。,,,,, ,,・,限られた期間で、網羅性の高いテストを行うために、月次処理に続けて年次処理を実施できる日付を設定し,,, ,,,て、テストの準備工数を削減する。,,, ,,・,限られた費用で、多くのテストケースを実行するために、自動化ツールを採用して人件費を削減する。,,, ,,,,,, ,設問ア,,,あなたが携わったシステムテストにおいて、対象業務と対象システムの概要、及び期間や費用などの制約,, ,,,,について、800字以内で述べよ。,, ,設問イ,,,設問アで述べたシステムのシステムテスト計画を策定する際に、あなたは、どのようなテストの重点確認項,, ,,,,目を策定したか。考慮した業務の重要度や業務特性とともに、800字以上1600字以内で具体的に述べよ。,, ,設問ウ,,,設問イで述べたシステムテスト計画の策定において、制約のある中で効率よくシステムの品質を確保する,, ,,,,ために、あなたが重要と考え工夫した点について、600字以上1200字以内で具体的に述べよ。,, ,,,,,, ■解答例,,,,,, ,,,,,, ,１．１　対象業務と対象システムの概要,,,,, ,,,,,, ,,　A社は全国に約300店舗を出店し、主に輸入食料品の小売販売業を行っている。A社で利用されているPOSシス,,,, ,,テムは6年前に導入されたが、当時の店舗数は100店舗未満であったことから、システムの性能的にも業務適合,,,, ,,度としても限界を迎え、性能向上と新たな業務のシステム化を目的に、再構築が計画された。そして、そのシステ,,,, ,,ムを担当することになったのがB社に所属する私で、システムアーキテクトとして参画した。,,,, ,,　A社の各店舗にはストアコントローラ１台とPOSレジが１～５台（平均3台）導入されている。そして全国300店舗の,,,, ,,売上情報や店舗発注情報を、本部のサーバで受注して発注処理や情報分析を行っている。通信にはインターネ,,,, ,,ットVPNを利用。,,,, ,,,,,, ,１．２　システムテストに対する制約事項,,,,, ,,,,,, ,,　本プロジェクトで実施するPOSシステムの再構築は、A社が新年度から実施する業務改善の一環として計画に,,,, ,,組み込まれていることから、POSシステムの稼働のみを延期することができず、スケジュールについて強い制約,,,, ,,が存在し、10か月後に必ず稼働させる必要があった。そのため、全体的に開発期間が短く、システムテストも1か,,,, ,,月間しか取れなかった。,,,, ,,　この期間で、私の想定しているシステムテストケースを全部こなすには、本番環境とほぼ同じ環境をシステムテ,,,, ,,スト環境とすることが絶対条件だったので、そこは弊社のPMに依頼して用意してもらっている。これにより、本番,,,, ,,環境と開発環境の差については考慮しなくてよくなった分、効率よく試験を実施できるようになったが、それでも1,,,, ,,か月間という期間に余裕はない。効率よく実施する必要があることには変わりはなかった。,,,, ,,,,,, ,２．業務の重要度と業務特性を考慮した重点確認項目,,,,, ,,,,,, ,,　こうした制約の中、私は、システムテストで実施するテストケースの検討に入った。結論から言うと、今回のシス,,,, ,,テムテストで、特に重点的に確認したいのは、本部サーバと店舗のストアコントローラ、店舗POS間の連携処理の,,,, ,,信頼性に関する項目である。,,,, ,,　店舗POSに関しては、冗長構成にしていたり、万が一POSレジが使用できない場合の手作業等による対応策等,,,, ,,も単体テスト等で確認済みである。それに対して、店舗POSと店舗のストアコントローラ、本部サーバの連携試験,,,, ,,は、このシステムテストでの確認項目であるからだ。,,,, ,,,,,, ,２．１　確認する業務とその重要性及び特性,,,,, ,,,,,, ,,　システムテストで重点的に確認する連携に関する業務とは、具体的には、新商品の追加、特売時の売価変更,,,, ,,等が発生したときや、売上情報の集計や本部へのデータ送信、発注処理等に関係するデータ通信処理の部分,,,, ,,である。,,,, ,,　これらの業務は、POSレジでの精算業務の単体RTOに比べれば多少の時間的猶予はあるが、それでも長時間,,,, ,,ストップさせることのできない重要業務に変わりない。実際に、新システムでも、次のような品質目標が与えられ,,,, ,,ている（システム全体）。,,,, ,,,,,, ,,①運用スケジュール,,,, ,,,,,, ,,,オンライン稼働時間　8時～23時　バッチ処理時間　24時～翌7時,,, ,,,,,, ,,②目標復旧水準,,,, ,,,,,, ,,,RPO：障害発生時点　RTO：2時間以内,,, ,,,,,, ,,③稼働率：99.9％以上,,,, ,,,,,, ,２．２　新システムに存在するリスクの考慮,,,,, ,,,,,, ,,　しかも今回は、システムアーキテクチャが変わる。従来は、本部サーバと各店舗のストアコントローラにオフコン,,,, ,,と専用OSを利用していたが、これがPCサーバとWindows OSに変わる。そのため、ハードウェア、OS、データベー,,,, ,,スが変わるので、それを加味した設計にしてはいるものの、本当に信頼性が確保できているかどうかをチェックし,,,, ,,なければならないと考えた。,,,, ,,,,,, ,２．３　テストの重点確認項目の例,,,,, ,,,,,, ,,　上記のような点を考慮して、店舗POS-店舗ストアコントローラ-本部サーバの連携試験を重点確認する計画,,,, ,,にしたが、システムアーキテクトの立場だと、やはり開発アプリケーションに組み込んだ信頼性向上策の部分を重,,,, ,,点的に確認しなければならない。最後にその具体例をいくつかあげる。,,,, ,,,,,, ,,（１）障害発生時の自動切替処理の確認,,,, ,,,,,, ,,,　今回、店舗側ストアコントローラに障害が発生した場合でも、ネットワークさえつながっていれば、店舗POSレ,,, ,,,ジの接続先を、本部で稼働している予備のストアコントローラに自動で切り替えて業務を継続できる仕様にし,,, ,,,ている（一部制約有、縮退運転）。,,, ,,,　その場合、仕様通りに切替プログラムが稼働するかどうか、障害の発生タイミングを事前に設定したパター,,, ,,,ン（無通信時や、各通信処理実行中など）だけテストする。,,, ,,,,,, ,,（２）復旧時の再実行処理の確認,,,, ,,,,,, ,,,　店舗ストアコントローラと本部サーバとが、通信障害等で通信できなくなった場合は、双方で交換できないデ,,, ,,,ータを保持する仕様になっているが、復旧した段階で、双方に滞留していたデータを交換する。そのデータの,,, ,,,引継ぎが正常に実施できるかどうかを確認する。,,, ,,,　現段階のSLAでは、2時間以内の復旧なので、2時間分のデータが、繁忙時間であってもきちんと蓄積され、,,, ,,,正常に引き継がれるかどうかをチェックする。,,, ,,,,,, ,３．制約の中で効率よくシステムの品質を確保するために重要と考え工夫した点,,,,, ,,,,,, ,,　今回のシステムテストは、1か月間しかないという強い制約がある。必須条件として、システムテスト環境を本番,,,, ,,環境と同等にできたので、あとは、私の工夫で必要なテストケースを考えればいい。具体的には、このような計画,,,, ,,を策定した。,,,, ,,,,,, ,,（１）サイクルテストの効率化,,,, ,,,,,, ,,,　今回のシステムテストにおいて、重点確認項目は設問イで述べた試験になるが、システムテストでは、他に,,, ,,,も機能性試験、性能試験等も実施しなければならない。このうち、時間がかかるのは、システム全体の機能を,,, ,,,確認するサイクルテストである。,,, ,,,　本テストは、本部サーバ単体の処理が中心のテストになるが、1か月間の中で、日次処理から月次処理、年,,, ,,,次処理までを確認しなければならない。そのため、システム日付を変更しながら進めていく必要がある。最初,,, ,,,の1週間は1日ずつ進めて、2週間目から1日に1か月進めるなど、1か月の中で「今日は○月×日に設定」とい,,, ,,,うようにだ。それはそれで難しいことではないが、さらに効率よくサイクルテストを進めていくには、システムテ,,, ,,,ストが開始される前までに、サイクルテスト以外の非機能要件のテスト項目などのうち、日付が関連するテスト,,, ,,,ケースかどうかをチェックし、それを考慮して、1か月間に分散して実施する計画にした。,,, ,,,　要するに、サイクルテストで実施する仮想の日付を中心に、適切な日に、性能テストや信頼性テストを割り当,,, ,,,てるようにしたわけだ。これによって、設定変更を繰り返す時間のロスや、混乱を防ぐ効果が期待できると考え,,, ,,,た。,,, ,,,,,, ,,（２）重点確認項目の信頼性確認,,,, ,,,,,, ,,,　また、設問イで述べている通り、システムテストにおける重点確認項目は、信頼性向上施策になる。そう設定,,, ,,,した理由には、リスクが大きいということもある。したがって、その部分の試験を優先して実施しないと、システ,,, ,,,ムテストの後半で発覚しても取り返しがつかない。また、そこで改善したとしても、まだサイクルテストを繰り返,,, ,,,すことも十分考えられる。,,, ,,,　そこで、日付に依存する試験を除いて最優先で重点確認項目の信頼性に関する試験を実施することにした,,, ,,,。（以上）,,, ,,,,,, 平成２３年度　問２　システムテスト計画の策定,,,,,, ,,,,,, ,　システムアーキテクトは、システムテストの直前だけではなく、様々な局面でシステムテスト計画についての検討を,,,,, ,求められる。その計画の策定において、対象業務の重要度や業務特性を考慮しながら、障害発生時の対応、オンラ,,,,, ,インやバッチのピーク時処理など、テストの重点確認項目を明確にする。重要度や業務特性を考慮した重点確認項,,,,, ,目には、例えば、次のようなものがある。,,,,, ,,・,銀行のATMでの取引業務や小売業のPOSでの売上管理業務など重要度が高く、障害発生時にも一定のサー,,, ,,,ビスを継続しなければならない業務の場合、円滑に縮退運転に移行できること,,, ,,・,株式の取引業務など処理量が極端に変動する業務の場合、想定する最大のデータ量を処理できることに加,,, ,,,え、変動するデータ量にも適切に対応できること,,, ,　システムテストでは、本番と同じ構成をテスト環境として構築し、十分なテスト期間を設定することで、システムの品,,,,, ,質を確保することが望ましい。しかし、一般的には期間や費用などに制約があるので、その中で効率よくシステムの,,,,, ,品質を確保するシステムテスト計画を策定することが重要であり、例えば、次のような工夫を行う。,,,,, ,,・,限られた期間で、網羅性の高いテストを行うために、月次処理に続けて年次処理を実施できる日付を設定し,,, ,,,て、テストの準備工数を削減する。,,, ,,・,限られた費用で、多くのテストケースを実行するために、自動化ツールを採用して人件費を削減する。,,, ,,,,,, ,設問ア,,,あなたが携わったシステムテストにおいて、対象業務と対象システムの概要、及び期間や費用などの制約,, ,,,,について、800字以内で述べよ。,, ,設問イ,,,設問アで述べたシステムのシステムテスト計画を策定する際に、あなたは、どのようなテストの重点確認項,, ,,,,目を策定したか。考慮した業務の重要度や業務特性とともに、800字以上1600字以内で具体的に述べよ。,, ,設問ウ,,,設問イで述べたシステムテスト計画の策定において、制約のある中で効率よくシステムの品質を確保する,, ,,,,ために、あなたが重要と考え工夫した点について、600字以上1200字以内で具体的に述べよ。,, ,,,,,, ■解答例,,,,,, ,,,,,, ,（設問ア）,,,,, ,,,,,, ,１．私が開発に携わったシステムの概要,,,,, ,,,,,, ,,　K社は、北日本の地方都市を中心に約150店舗を運営するスーパマーケットである。その当時、大手のスーパマ,,,, ,,ーケットは、インターネットで注文を受け付けて、店舗から顧客が指定する場所に注文商品を配達するネットスー,,,, ,,パ事業を開始していた。K社の経営者層は、経営計画策定時に、ネットスーパ事業への参入とそれに対応するシ,,,, ,,ステム（以下、Nシステムという）の開発を決定した。私は、K社の情報システム部に所属するシステムアーキテク,,,, ,,トであり、当システム開発プロジェクトの設計チームリーダに任命された。,,,, ,,,,,, ,２．Nシステムの対象業務とシステムテストの概要,,,,, ,,,,,, ,,　Nシステムが対象とする主な業務は、会員管理業務・注文受付業務・商品集荷業務・商品引渡業務・店舗運営,,,, ,,管理業務である。システムテストは、各種マスタ設定から運用を想定したテストシナリオに基づき、設計チームと,,,, ,,開発チームによって行われる予定だった。その一環として、負荷テストやペネトレーションテスト等のセキュリティ,,,, ,,関連テストも併せて計画された。,,,, ,,,,,, ,３．システムテストの期間や費用などの制約,,,,, ,,,,,, ,,　システムテストの期間は3か月であり、予備期間は設定されていなかった。その費用は、プロジェクト総予算の,,,, ,,中に含まれており、システムテストだけの費用は明示されていなかった。Nシステムのプロジェクトマネージャは、,,,, ,,システムテストの定量的品質目標として以下の2点を設定した。,,,, ,,,①,テスト項目密度を18件/ｋステップ以上にすること。,, ,,,②,欠陥摘出密度を1.6件/ｋステップ以上にすること。,, ,,　したがって、私にとってはテスト期間と定量的品質目標が、システムテスト計画上の制約になった。,,,, ,,,,,, ,（設問イ）,,,,, ,,,,,, ,１．私が検討したシステムテスト計画,,,,, ,,,,,, ,,　私は、Nシステムの要件定義工程を完了した直後に、システムテスト計画案の立案に着手した。その根拠は、シ,,,, ,,ステムテストによって、要件定義の妥当性を検証するためだった。私は、外部設計終了時に、システムテスト計画,,,, ,,案を見直し、確定させるスケジュールを採用した。私は、システムテスト計画を策定するうえで、対象業務の重要,,,, ,,度や業務特性を考慮しながら、重点確認項目を設定した。,,,, ,,,,,, ,２．私が設定したシステムテストでの重点確認項目,,,,, ,,,,,, ,,　私は、システムテストにおける、以下2点の重点確認項目を設定した。,,,, ,,,,,, ,２．１　障害発生時のサービスの継続,,,,, ,,,,,, ,,　私は、システムテストにおいて検証すべき障害の１つとして、本社と店舗間のIP-VPNが通信不能になる障害（,,,, ,,以下、回線障害という）を想定した。回線障害が発生した場合、,,,, ,,,①,本社サーバに登録されている注文情報を店舗サーバに転送できない。,, ,,,②,店舗サーバに登録されている商品引渡実績情報を本社サーバに転送できない。,, ,,の２つの不具合が発生する。私は、注文を受け付けた商品を会員に引き渡す商品引渡業務が遂行できないこと,,,, ,,は致命的であり、以下の縮退運転への移行機能を重点確認項目に設定した。,,,, ,,,,,, ,２．１．１　回線障害発生時の最終処理,,,,, ,,,,,, ,,回線障害が発生した直後に、,,,, ,,,①,回線障害が発生した店舗の会員の新規注文受付を停止できるか？,, ,,,②,回線障害が発生した旨の電子メールを、本社の情報システム部の運用担当者に送付しているか？,, ,,,③,回線障害発生前に受付済みの注文情報のうち、店舗サーバに転送していないものを抽出し、発注した会,, ,,,,員に電子メールで通知するとともにログに記録しているか？,, ,,,④,本社サーバから店舗サーバに転送される途中であった注文受付情報は、ロールバックされ転送がキャンセ,, ,,,,ルされるか？,, ,,,,,, ,２．１．２　回線障害が回復するまでの処理,,,,, ,,,,,, ,,,①,回線障害が発生していない店舗に関する注文受付業務や本社サーバから店舗サーバへの注文受付情報,, ,,,,の転送処理は、通常通り遂行されるか？,, ,,,②,回線障害が発生した店舗の担当者は、電話によって会員からの注文を受け付け、POS端末の注文画面か,, ,,,,ら注文受付情報を店舗サーバに登録できるか？,, ,,,,,, ,２．２　ピーク時における最大のデータ量の処理,,,,, ,,,,,, ,,　私は、システムテストにおいて検証すべき負荷テストとして、以下2点のピーク時における最大データ量の正常,,,, ,,な処理を重点確認項目に設定した。,,,, ,,,,,, ,２．２．１　オンライン処理のピーク時性能,,,,, ,,,,,, ,,　Nシステムのオンライン処理のうち、ピーク時の性能が問題になるのは、注文受付業務である。私は、Nシステム,,,, ,,の運用開始から1年間の注文受付業務のピーク時性能を、,,,, ,,,①,同時接続会員数は100名,, ,,,①,1秒間に登録される注文受付情報は200トランザクション,, ,,とし、それらが処理可能か？を設定した。,,,, ,,,,,, ,２．２．２　バッチ処理のピーク時性能,,,,, ,,,,,, ,,　Nシステムのバッチ処理のうち、ピーク時の性能が問題になるのは、注文受付情報の月次会員別商品別集計,,,, ,,処理である。私は、Nシステムの運用開始から1年間の当集計処理のピーク時性能を”1時間以内で処理完了”と,,,, ,,し、それが処理可能か？を設定した。,,,, ,,,,,, ,（設問ウ）,,,,, ,,,,,, ,１．効率の良いテストを実行するために工夫した点,,,,, ,,,,,, ,,　私は、システムテストでは、本番と同じ構成をテスト環境として構築し、十分なテスト期間を設定することが望ま,,,, ,,しいと考えた。しかし、私には設問アで述べたテスト期間や定量的品質の制約が課せられていた。そこで、私は、,,,, ,,これらの制約の下で効率のよいシステムテスト計画を策定することが重要だと考え、以下の2点の工夫を行った。,,,, ,,,,,, ,１．１　テストの準備工数の削減,,,,, ,,,,,, ,,　私は、限られたテスト期間の中で、網羅性の高いシステムテストを計画した。具体的には、以下2点のテストの,,,, ,,準備工数を削減する工夫をした。,,,, ,,,①,テスト期間内にNTP（Network Time Protocol）サーバを設置し、テスト用のクライアントPC・Webサーバ・DB,, ,,,,サーバは、NTPサーバから現在日時を取得する。そのNTPサーバの現在日付を日次・月次・年次処理のた,, ,,,,めに適宜変更し、各処理を1日の中で行う。,, ,,,②,負荷テストを効率よく実行するために、端末シミュレータプログラムを開発する。このプログラムは、１台のP,, ,,,,C内に20台の端末を疑似的に生成し、一斉にWebサーバに注文受付情報の登録依頼をする。,, ,,,,,, ,１．２　テスト自動化ツールの採用,,,,, ,,,,,, ,,　私は、テストに係る時間を短縮し、人件費を削減するために、以下の2つのテスト自動化ツールを開発した。,,,, ,,,①,注文受付画面での利用者のキーボードおよびマウス操作を記録する。あるボタンを押すと、記録された操,, ,,,,作が再現され、注文受付画面入力が完了する。,, ,,,②,テスト結果の検証時間を省くために、開発者が想定したテスト結果を登録したテーブルと、処理を実行した,, ,,,,結果を格納しているテーブルを比較し、不一致になっている場合、その旨を画面に表示する。特に、当該プ,, ,,,,ログラムをレグレッションテスト時に活用する。,, ,,,,,, 平成２４年度　問１　業務の変化を見込んだソフトウェア構造の設計,,,,,, ,,,,,, ,　企業を取り巻く環境の変化に応じて、業務も変化する。情報システムには、業務の変化に対応して容易に機能を変,,,,, ,更できるような、ソフトウェア構造の柔軟性が求められる。,,,,, ,　このため、システムアーキテクトは、システム要件定義の段階から、業務の変化が起こり得るケースを想定し、変,,,,, ,化の方向性やシステムに与える影響を予測する。ソフトウェア構造の設計では、その予測に基づいて、業務が変化,,,,, ,してもシステム全体を大きく作り直す必要がないように考慮しなければならない。,,,,, ,　例えば、次のようにソフトウェア構造の設計を行う。,,,,, ,,・,業務フローの制御部分と業務ロジック部分を分離する。,,, ,,・,業務ロジックが互いに疎結合となるように分割する。,,, ,,・,データアクセスコンポーネントを共通化する。,,, ,　その際、そのような設計を行うことによって引き換えに生じた課題に対応するための工夫を行うことが重要である。,,,,, ,例えば、処理時間が長くならないように複数のプロセスを並行して処理したり、処理同士の整合性を確保するために,,,,, ,排他制御の仕組みを用意したりする。,,,,, ,,,,,, ,設問ア,,,あなたがソフトウェア構造の設計に携わったシステムにおける、対象業務の概要及び特徴について、800字,, ,,,,以内で述べよ。,, ,設問イ,,,設問アで述べたシステムについて、どのような業務の変化を想定したか。また、業務が変化してもシステム,, ,,,,全体を大きく作り直す必要がないように、どのようなソフトウェア構造を設計したか。800字以上1600字以内,, ,,,,で具体的に述べよ。,, ,設問ウ,,,設問イで述べたソフトウェア構造の設計において、生じた課題とそれに対応するために重要と考えて工夫し,, ,,,,た内容、及び設計したソフトウェア構造に対するシステムアーキテクトとしての評価について、600字以上12,, ,,,,00字以内で具体的に述べよ。,, ,,,,,, ■ポイント,,,,,, ,,,,,, ,■出題趣旨,,,,, ,,,,,, ,,　企業を取り巻く環境の変化に応じて、業務も変化する。情報システムには、業務の変化に対応して容易に機能,,,, ,,を変更できるようなソフトウェア構造の柔軟性が求められる。,,,, ,,　このため、システムアーキテクトは、システム要件定義の段階から、業務の変化が起こり得るケースを想定し、,,,, ,,変化の方向性やシステムに与える影響を予測する。ソフトウェア構造の設計では、その予測に基づいて、業務が,,,, ,,変化しても、システム全体を大きく作り直す必要がないように考慮しなければならない。,,,, ,,　本問は、業務が変化しても、システム全体を大きく作り直す必要がないように設計したソフトウェア構造の設計,,,, ,,内容、その設計を行うことによって引き換えに生じた課題に対応するために重要と考え工夫した内容、及び設計,,,, ,,したソフトウェア構造に対するシステムアーキテクトとしての評価について、具体的に論述することを求めている。,,,, ,,論述を通じて、システムアーキテクトに必要なソフトウェア構造の設計能力を評価する。,,,, ,,,,,, ,■採点講評,,,,, ,,,,,, ,,　全問に共通して、具体的で、経験に基づいて記述されていることをうかがわせる論述が多かった。一方で、問題,,,, ,,文の引用で文字数を費やし、結果的に期待した内容が書かれていない論述や、問題文に例示した項目と一般論,,,, ,,の組み合わせだけで構成された具体性に欠ける論述も見られた。問題文に記載した項目は事例として挙げたも,,,, ,,のであり、転記を求めているものではないことを理解してほしい。,,,, ,,　また、設問で問うている内容に対応しない論述も散見された。例えば、”対象業務の概要及び特徴”を問うてい,,,, ,,るにもかかわらず、”プロジェクトの概要”や”システムの概要”を述べているような論述が挙げられる。このような,,,, ,,論述では、受験者の能力や経験を正しく評価できない場合があるので、実際の経験に基づき設問に沿って具体,,,, ,,的に論述してほしい。,,,, ,,　問１（業務の変化を見込んだソフトウェア構造の設計について）では、”業務変化によってシステムが受ける影響,,,, ,,”、”ソフトウェア構造の面からの設計”、”業務変化に対応できる理由”、の三つについて、関連付けて論述するこ,,,, ,,とを期待したが、そのような論述は少なかった。,,,, ,,　多くの受験者が、”想定した業務の変化”に対応するソフトウェア構造ではなく、設定値をテーブル化するなど”,,,, ,,汎用化のためのプログラミング方法”や販売管理システムにおいて商品の種類が増加することなど、”当然考慮,,,, ,,すべき業務要件やデータ量の変化”に対応するソフトウェア構造について論述していた。また、”どのようなソフト,,,, ,,ウェア構造を設計したか”と問うているにもかかわらず、”柔軟性を持った構造にした”などの論述にとどまり、具,,,, ,,体的なソフトウェア構造に触れていない論述も見られた。,,,, ,,　業務の変化が激しくなっている状況において、業務を踏まえてソフトウェア構造を設計する能力は、システムア,,,, ,,ーキテクトとして特に必要とされるものである。その重要性を理解し、実践してほしい。,,,, ,,,,,, ,　業務の変化に対応して容易に機能を変更できるような、ソフトウェア構造の設計がテーマの問題である。企業を取,,,,, ,り巻く環境が変化すれば、環境に合わせて企業の業務も変化していく。情報システムには、業務の変化に対応して,,,,, ,柔軟に変化できるようなソフトウェア構造が要求される。業務の変化に柔軟に対応できるソフトウェア構造とするため,,,,, ,には、情報システム開発の上流工程である要求定義の段階から業務の変化を想定し、情報システムがどのように,,,,, ,変化すればよいのか、変化が情報システムにどのような影響を与えるのかなどについて考慮しなければならない。,,,,, ,　柔軟なソフトウェア構造にはマイナスの側面がある。汎用性を高めることによって処理時間が長くなったり、処理を,,,,, ,共通部品と可変部品などに分割することによって処理同士の整合性を確保することが必要になったりする。ソフトウ,,,,, ,ェア構造の柔軟性と処理効率とはトレードオフの関係にあり、設計の落としどころがシステムアーキテクトの腕の見,,,,, ,せ所であるといえる。,,,,, ,,,,,, ,　設問アでは、「ソフトウェア構造の設計に携わったシステムにおける、対象業務の概要及び特徴」を記述する。情報,,,,, ,システムについての記述は求められておらず、対象となる業務に関しての記述だけが要求事項となっている。問題,,,,, ,文の冒頭には「企業を取り巻く環境の変化に応じて、業務も変化する」と説明されている。ただし、題意は業務の変,,,,, ,化に柔軟に対応できる情報システムのソフトウェア構造の設計であるため、「企業を取り巻く環境の変化」そのもの,,,,, ,は記述しなくても良い。設問文には、「対象業務の概要及び特徴」と指示されており、概要と特徴の両方に触れる必,,,,, ,要がある。特徴については、「何がその業務を特徴づけるか」という観点で記述する。例えば、他の業務との違いや,,,,, ,他社の同じ業務との相違などを記述しなければならない。要求事項が一項目だけなので、字数は多くならないかもし,,,,, ,れない。ただし、設問アは800字以内という条件であるため問題はない。,,,,, ,,,,,, ,　設問イでは、「想定した業務の変化」、「業務が変化してもシステム全体を大きく作り直す必要がないソフトウェア構,,,,, ,造の設計」について記述する。「想定した業務の変化」について、「業務の変化が起こり得るケースを想定し、変化の,,,,, ,方向性やシステムに与える影響を予測する」と問題文に説明されている。将来の業務の変化が確定しているのでは,,,,, ,なく、変化する可能性があるという状況を示したい。「変化の方向性」については、「方向性」が意味するところが見え,,,,, ,にくく、どう表現するか悩ましいところである。広い意味で変化の可能性を示しておけば十分ではないかと考えられ,,,,, ,る。問題文には、変化に柔軟に対応できるソフトウェア構造の例が示されており、参考にしたい。例では、変化する部,,,,, ,分と変化しない部分を分ける、ソフトウェアコンポーネントの独立性を高める、特定の処理を共通化するという視点に,,,,, ,なっている。柔軟なソフトウェア構造の設計指針としては一般的な視点であり、多くの事例に該当するのではないか,,,,, ,と考えられる。設問イの要求事項は二つであり、要求事項の一つ「想定した業務の変化」については、業務が変化す,,,,, ,ることの背景に踏み込んで記述しても、記述量はあまり多くならないと考えられる。もう一つの要求事項「業務が変化,,,,, ,してもシステム全体を大きく作り直す必要がないソフトウェア構造の設計」についての記述量を意識しながら書き進,,,,, ,め、設問イの要求字数の下限（800字）を超えるように注意する。,,,,, ,,,,,, ,　設問ウでは、「ソフトウェア構造の設計において生じた課題」、「課題への対応内容」、「ソフトウェア構造に対する自,,,,, ,身の評価」を記述する。問題文に課題そのものについての例は示されていない。ただし、課題に対する工夫の例とし,,,,, ,て「処理時間が長くならないように」、「処理同士の整合性を確保するために」という説明があることから、「処理時間,,,,, ,が長くなった」とか「処理同士の整合性の確保が必要になった」という課題が見えてくる。この問題では、柔軟性のあ,,,,, ,るソフトウェア構造を実現することによって、情報システムの動作にマイナスの影響を及ぼすような要素が課題であ,,,,, ,るといえる。「ソフトウェア構造に対する自身の評価」については、評価の観点を限定するような記述がないため、ど,,,,, ,のような視点で評価しても良い。「ソフトウェア構造の柔軟性が期待通り得られた」のような直接的な評価も可能であ,,,,, ,るし、ソフトウェア構造の汎用性、ソフトウェア構造のシンプルさなどについて評価しても良い。,,,,, ,,,,,, ■見出しとストーリー,,,,,, ,,,,,, ,■設問ア,,,,, ,,,,,, ,,　設問アには、問題文の次の部分が対応する。,,,, ,,,,,, ,,,設問ア,,,あなたがソフトウェア構造の設計に携わったシステムにおける、対象業務の概要及び特徴について ,,,,,,、800字以内で述べよ。 ,,,,,, ,,,　企業を取り巻く環境の変化に応じて、業務も変化する。情報システムには、業務の変化に対応して容易に機,,, ,,,能を変更できるような、ソフトウェア構造の柔軟性が求められる。,,, ,,,,,, ,,　例として次のような見出しとストーリーが考えられる。,,,, ,,,,,, ,,,ア　対象業務の概要と特徴,,, ,,,,,, ,,,,・,衣料品製造・販売のA社における営業支援システムの刷新プロジェクト, ,,,,・,A社は高品質な商品を主力として、ファッションに敏感な婦人層を主要な顧客としている, ,,,,・,直販は行わず代理店販売に限定していることがA社の特徴, ,,,,・,店舗を保有すると、人件費、店舗経費などが固定費となるとともに、売行きの良し悪しが経営環境に大, ,,,,,きな影響を与えるため、創業以来30年が経過するも、代理店販売に特化している, ,,,,・,代理店は現在約50店舗になる, ,,,,・,代理店を支援するため、専任の店舗アドバイザ3名をかかえている, ,,,,・,店舗アドバイザは、小規模な店舗であっても顧客が商品を手に取って確認できる展示の工夫など、店, ,,,,,舗運営のノウハウをもつ, ,,,,・,店舗アドバイザは服飾アドバイザでもあり、定期的に店舗を巡回し、来店中の顧客の相談にも応じてい, ,,,,,る, ,,,,・,高品質な商品と服飾アドバイザの効果で、リピート顧客は、顧客全体の約７割を占めている, ,,,,・,効率的な商品仕入れを目指し、稼働中の営業支援システムを刷新することになった, ,,,,・,自身の立場は、独立系のシステムインテグレータP社に所属するシステムアーキテクト, ,,,,,, ,設問イ,,,,, ,,,,,, ,,　設問イには、問題文の次の部分が対応する。,,,, ,,,,,, ,,,設問イ,,,設問アで述べたシステムについて、どのような業務の変化を想定したか。また、業務が変化してもシ ,,,,,,ステム全体を大きく作り直す必要がないように、どのようなソフトウェア構造を設計したか。800字以 ,,,,,,上1600字以内で具体的に述べよ。 ,,,,,, ,,,　このため、システムアーキテクトは、システム要件定義の段階から、業務の変化が起こり得るケースを想定し,,, ,,,、変化の方向性やシステムに与える影響を予測する。ソフトウェア構造の設計では、その予測に基づいて、業,,, ,,,務が変化してもシステム全体を大きく作り直す必要がないように考慮しなければならない。,,, ,,,　例えば、次のようにソフトウェア構造の設計を行う。,,, ,,,,・,業務フローの制御部分と業務ロジック部分を分離する。, ,,,,・,業務ロジックが互いに疎結合となるように分割する。, ,,,,・,データアクセスコンポーネントを共通化する。, ,,,,,, ,,　例として次のような見出しとストーリーが考えられる。,,,, ,,,,,, ,,,イ　想定した業務の変化とソフトウェア構造の設計,,, ,,,イ―１　想定した業務の変化,,, ,,,,,, ,,,,・,現在は営業担当がモバイルPCに商品のデータを入れて代理店を回っている, ,,,,・,高品質な商品を代理店に提示するためには、精細な画像データや動画が必要となる, ,,,,・,モバイルPCの通信事情を考えると、本社にあるサーバから精細な画像データや動画をダウンロードしな, ,,,,,がら参照することは使い勝手が悪い, ,,,,・,現時点では、高性能なモバイルPCに必要なデータをあらかじめダウンロードしておき、オフラインで使用, ,,,,,している, ,,,,・,タブレットが流通し始めており、処理性能を含め、今後モバイル環境が劇的に変わってくる可能性があ, ,,,,,る, ,,,,・,現在は売り手が顧客に説明するという販売形態である, ,,,,・,商品説明に関する一連の処理をサーバで行えるようにすることによって、顧客のもつスマートフォンやタ, ,,,,,ブレットを利用して自由に商品を確認できるようになる, ,,,,・,将来的には直接販売の形態も視野にあると想定できる, ,,,,,, ,,,イ―２　ソフトウェア構造の設計,,, ,,,,,, ,,,,・,データの保存場所がローカルであったり、サーバであったりするなど、保存場所に処理が左右されない, ,,,,,ような設計が必要, ,,,,・,ユーザインタフェースについても、モバイルPC、スマートフォン、タブレットのように特性の異なるデバイ, ,,,,,スに対応できることが必要, ,,,,・,単に表示領域の大きさが異なるというだけではなく、デバイスに依存する部分も大きい, ,,,,・,決定したソフトウェア構造は、データアクセスコンポーネントを共通に使用できるよう独立させるとともに, ,,,,,、データにアクセスするための通信部分を独立させ、通信速度の差の影響がデータアクセスコンポーネ, ,,,,,ントに及ばないようにする, ,,,,・,表示関係のコンポーネントを共通部分のデバイス依存部分に分け、新しいデバイスに対応させる場合, ,,,,,は、デバイス依存部分のコンポーネントを追加する仕様とした, ,,,,,, ,■設問ウ,,,,, ,,,,,, ,,　設問ウには、問題文の次の部分が対応する。,,,, ,,,,,, ,,,設問ウ,,,設問イで述べたソフトウェア構造の設計において、生じた課題とそれに対応するために重要と考えて ,,,,,,工夫した内容、及び設計したソフトウェア構造に対するシステムアーキテクトとしての評価について、 ,,,,,,600字以上1200字以内で具体的に述べよ。 ,,,,,, ,,,　その際、そのような設計を行うことによって引き換えに生じた課題に対応するための工夫を行うことが重要で,,, ,,,ある。例えば、処理時間が長くならないように複数のプロセスを並行して処理したり、処理同士の整合性を確,,, ,,,保するために排他制御の仕組みを用意したりする。,,, ,,,,,, ,,　例として次のような見出しとストーリーが考えられる。,,,, ,,,,,, ,,,ウ　ソフトウェア構造の設計において生じた課題と対応策、システムアーキテクトとしての評価,,, ,,,ウ―１　ソフトウェア構造の設計において生じた課題と対応策,,, ,,,,,, ,,,,・,データアクセス系、表示系のコンポーネントについて、共通部分と通信部分、共通部分とデバイス依存, ,,,,,部分というように分割した, ,,,,・,分割によってコンポーネント間の通信のオーバヘッドが加わったため、詳細設計において必要な性能が, ,,,,,確保できない可能性が生じた, ,,,,・,机上での評価結果は要件の処理速度に満たないものになった, ,,,,・,性能を確保するため、通信部分についてデータをすべて受信してから次のコンポーネントに渡すのでは, ,,,,,なく、データを細かく分割することによって、順次渡す方式とし、利用者に対する待ち時間の感覚を小さく, ,,,,,する工夫をした, ,,,,・,非常に大きなサイズの画像や動画であれば、分割方式であっても絶対的な時間を要してしまうため、小, ,,,,,さなサイズのデータも準備し、回線速度に応じて使い分けることとした, ,,,,・,衣料品の詳細な部分の情報が欠落する可能性もあるが、例えば小さな画面では確認できる範囲が限ら, ,,,,,れるため、実用に耐え得ると判断した, ,,,,,, ,,,ウ―２　システムアーキテクトとしての評価,,, ,,,,,, ,,,,・,柔軟なソフトウェア構造の設計について、今回の営業支援システムの刷新に関連したユーザ要件は十, ,,,,,分反映できていると判断する, ,,,,・,現時点では代理店方式の間接販売であるが、将来の直接販売にも対応できるソフトウェア構造である, ,,,,・,当初の設計では処理性能が実現できなかった点についても、データの転送方式とデータの保持方式を, ,,,,,工夫することによって性能が確保できた, ,,,,・,私の設計したソフトウェア構造は十分評価できるものと判断する, ,,,,,, ■解答,,,,,, ,,,,,, ,■設問ア,,,,, ,,,,,, ,,ア　対象業務の概要と特徴,,,, ,,,,,, ,,,　私は、独立系のシステムインテグレータP社に所属するシステムアーキテクトである。今回私がソフトウェア構,,, ,,,造の設計に携わったのは、衣料品製造・販売のA社における営業支援システムの刷新プロジェクトである。A,,, ,,,社は高品質な商品を主力として、ファッションに敏感な婦人層を多く取り込み、優良な顧客としている。A社で,,, ,,,は、直販は行わず代理店販売に限定していることが特徴となっている。A社が店舗を保有すると、店舗の人件,,, ,,,費、店舗の運営経費などが固定費となって掛かってくるとともに、売行きの良し悪しが経営環境に大きな影響,,, ,,,を与えるため、創業以来30年が経過するも、代理店販売に特化したまま現在に至っている。,,, ,,,　A社の代理店は、現在約５０店舗にまで拡大している。A社では、代理店を支援するため、専任の店舗アドバ,,, ,,,イザを3名抱えている。店舗アドバイザは、小規模な店舗であっても顧客が商品を手に取って確認できる展示,,, ,,,の工夫など、店舗運営のノウハウも持っている。店舗アドバイザは服飾アドバイザでもあり、定期的に店舗を,,, ,,,巡回し、来店中の顧客の相談にも応じている。,,, ,,,　高品質な商品と服飾アドバイザの効果で、継続的に店舗を訪れる顧客の割合が多いことも特徴となっており,,, ,,,、顧客全体の約7割を占めるまでになっている。A社幹部は、代理店の支援を強化する一環として、代理店が,,, ,,,より効率的な商品仕入れをできるように、稼働中の営業支援システムを刷新することを決定した。,,, ,,,,,, ,■設問イ,,,,, ,,,,,, ,,イ　想定した業務の変化とソフトウェア構造の設計,,,, ,,イ―１　想定した業務の変化,,,, ,,,,,, ,,,　現在は、営業担当がモバイルPCに最新の商品のデータを入れて代理店を回っている。営業担当者は、代理,,, ,,,店のマネージャに高品質な商品を提示する必要があり、モバイルPCには精細な画像データや動画を保存して,,, ,,,おくことが必要である。本社にあるサーバに精細な画像データや動画を格納して置き、営業担当者がサーバ,,, ,,,からダウンロードしながら代理店で参照するという方法も考えられるが、現在のモバイルPCの通信事情を考え,,, ,,,ると、使い勝手が良いとは言えない。,,, ,,,　そのため、現時点では、営業担当者が高性能なモバイルPCに必要な画像や動画などをあらかじめダウンロ,,, ,,,ードしておき、代理店の店頭においてオフラインで使用している。タブレットなどの新しいデバイスが流通し始,,, ,,,めており、私は、今後処理性能面を含め、モバイル環境が劇的にかわってくる可能性があると考えていた。,,, ,,,　現在は売り手（A社）が顧客に説明するという販売形態である。商品説明に関する一連の処理をサーバで行,,, ,,,えるようにすることによって、顧客のもつスマートフォンやタブレットを利用して自由に商品を確認できるように,,, ,,,なり、顧客が主体的に商品情報にアクセスすることが可能になる。私は、A社が将来的には直接販売を開始す,,, ,,,ることを視野に入れているのではないかと考えていた。,,, ,,,,,, ,,イ―２　ソフトウェア構造の設計,,,, ,,,,,, ,,,　想定される業務の変化から、データの保存場所がローカルであったり、サーバであったりするなど、保存場,,, ,,,所に処理が左右されないような設計が必要である。ユーザインタフェースについては、モバイルPCに加え、ス,,, ,,,マートフォン、タブレットなども加味しなければならない。単に表示領域の大きさが異なるというだけではなく、,,, ,,,特性の異なるデバイスに対応できることが必要となる。,,, ,,,　決定したソフトウェア構造は、データアクセスコンポーネントを共通に使用できるよう独立させるとともに、デー,,, ,,,タにアクセスするための通信部分を独立させ、通信速度の差の影響がデータアクセスコンポーネントに及ばな,,, ,,,いようにした。ユーザインタフェースに関しては、表示関係のコンポーネントを共通部分とデバイス依存部分に,,, ,,,分け、新しいデバイスに対応させる場合は、デバイス依存部分のコンポーネントを追加する仕様とした。,,, ,,,,,, ,,ウ　ソフトウェア構造の設計において生じた課題と対応策、システムアーキテクトとしての評価,,,, ,,ウ―１　ソフトウェア構造の設計において生じた課題と対応策,,,, ,,,,,, ,,,　私は、ソフトウェア構造の設計結果として、データアクセス系、表示系のそれぞれのコンポーネントについて、,,, ,,,共通部分と通信部分、共通部分とデバイス依存部分というように分割した。コンポーネントを分割することによ,,, ,,,って,,, ,,,コンポーネント間の通信のオーバヘッドが加わったため、詳細設計において必要な性能が確保できない可能,,, ,,,性が生じた。実際に、机上での評価結果は要件の処理速度に満たないものになった。私は、利用者の立場に,,, ,,,なって、どのような操作感であれば満足度が向上するのかという点に着目した。具体的には、通信部分につい,,, ,,,てデータを全て受信してから次のコンポーネントに渡すのではなく、データを細かく分割することによって、順次,,, ,,,渡す方式とし、利用者に対する待ち時間の感覚を小さくする工夫をした。ただし、非常に大きなサイズの画像,,, ,,,や動画であれば、分割方式であっても絶対的な時間を要してしまうため、私は、小さなサイズのデータも準備,,, ,,,し、回線速度に応じて使い分ける工夫もした。データサイズを小さくすると、衣料品の詳細な部分の情報が欠,,, ,,,落し、ユーザに本来伝えたいことが伝わらなくなる可能性もあるが、例えば小さな画面では確認できる範囲が,,, ,,,限られるため、実用に耐え得ると判断した。,,, ,,,,,, ,,ウ―２　システムアーキテクトとしての評価,,,, ,,,,,, ,,,　私は、今回の、柔軟なソフトウェアの構造の設計について、営業支援システムの刷新に関連したユーザ要件,,, ,,,は十分反映できていると判断している。現在、A社は代理店方式の間接販売だけであるが、将来の直接販売,,, ,,,に進出する場合においても十分対応できるソフトウェア構造であると考えている。当初の設計では処理性能が,,, ,,,実現できなかった点についても、データの転送方式とデータの保持方式を工夫することによって性能が確保で,,, ,,,きた。これらの結果から、私の設計したソフトウェア構造は十分評価できるものと判断する。　以上,,, ,,,,,, 平成２４年度　問２　障害時にもサービスを継続させる業務ソフトウェアの設計,,,,,, ,,,,,, ,　業務におけるシステムの重要性の増大に伴い、システムの障害時にもサービスを継続させることが重要になって,,,,, ,いる。システムアーキテクトは、サービス継続の方針に基づいて、機器の二重化などハードウェア面での対策だけで,,,,, ,なく、障害時に継続運用を可能にする業務ソフトウェアを設計する。,,,,, ,　例えば、小売業で”来店する顧客が通常通り商品を購入できること”、金融業で”決済取引を止めないこと”がサー,,,,, ,ビス継続の方針である場合、システムアーキテクトは、次のように障害時にも継続運用を可能にする業務ソフトウェ,,,,, ,アを設計する。,,,,, ,,・,小売業で本部と店舗のシステムが連携してPOS売上処理を行っている場合、本部システムの障害に備え、PO,,, ,,,S売上処理を店舗システム単独で稼働可能にする。このため、店舗システムにPOS売上データを一時的に保,,, ,,,持する機能を用意しておく。,,, ,,・,金融業で、ネットワークの処理能力が大幅に低下するような障害に備え、障害時に決済取引以外の処理を一,,, ,,,時的に停止する機能を用意しておく。,,, ,　このような、継続運用を可能にする業務ソフトウェアを設計する際、更に次のような継続運用に備えた処理や障害,,,,, ,復旧処理における工夫をする。,,,,, ,,・,通常時に、本部のマスタを更新する都度、店舗のマスタも同時に更新し、いつでも店舗システム単独での稼働,,, ,,,に切り替えられるようにする。また、店舗での欠品を防止するために、復旧後、配送頻度の高い食品などの発,,, ,,,注データを優先的に処理する。,,, ,,・,ネットワークの処理能力の回復後、停止させていた業務を再開するとともに、全業務が利用可能であることを,,, ,,,利用者の画面上に表示する仕組みを用意する。,,, ,,,,,, ,設問ア,,,あなたが開発に携わった、障害時にも継続運用を可能にするシステムについて、対象業務とシステムの概,, ,,,,要、サービス継続の方針について、800字以内で述べよ。,, ,設問イ,,,設問アで述べた方針に基づいて、障害時にもサービスを継続することにした処理は何か。また、継続運用,, ,,,,を可能にするために業務ソフトウェアをどのように設計したか。800字以上1600字以内で具体的に述べよ。,, ,設問ウ,,,設問イで述べた業務ソフトウェアの設計で、継続運用に備えた処理や障害復旧処理においてどのような工,, ,,,,夫をしたか。600字以上1200字以内で具体的に述べよ。,, ,,,,,, ■ポイント,,,,,, ,,,,,, ,■出題趣旨,,,,, ,,,,,, ,,　業務におけるシステムの重要性の増大に伴い、システムの障害時にもサービスを継続させることが重要になっ,,,, ,,ている。システムアーキテクトは、サービス継続の方針に基づいて、機器の二重化などハードウェアの面での対,,,, ,,策だけでなく、障害時に継続運用を可能にする業務ソフトウェアを設計する。,,,, ,,　本問は、対象業務と対象システムの概要及び障害時のサービス継続の方針について述べることを求めている。,,,, ,,また、その方針に基づいて障害時にもサービスを継続することにした処理と、継続運用を可能にするための業務,,,, ,,ソフトウェアの設計を述べ、継続運用に備えた処理や障害復旧処理における工夫について、具体的に論述するこ,,,, ,,とを求めている。論述を通じて、システムアーキテクトに必要な、業務の特徴を踏まえた業務ソフトウェアの設計,,,, ,,能力を評価する。,,,, ,,,,,, ,■採点講評,,,,, ,,,,,, ,,　全問に共通して、具体的で、経験に基づいて記述されていることをうかがわせる論述が多かった。一方で、問題,,,, ,,文の引用で文字数を費やし、結果的に期待した内容が書かれていない論述や、問題文に例示した項目と一般,,,, ,,論の組み合わせだけで構成された具体性に欠ける論述も見られた。問題文に記載した項目は事例として挙げた,,,, ,,ものであり、転記を求めているものではないことを理解してほしい。,,,, ,,　また、設問で問うている内容に対応しない論述も散見された。例えば、”対象業務の概要及び特徴”を問うてい,,,, ,,るにもかかわらず、”プロジェクトの概要”や”システムの概要”を述べているような論述が挙げられる。このような,,,, ,,論述では、受験者の能力や経験を正しく評価できない場合があるので、実際の経験に基づき設問に沿って具体,,,, ,,的に論述してほしい。,,,, ,,　問２（障害時にもサービスを継続させる業務ソフトウェアの設計について）では、サービス継続の方針に基づい,,,, ,,て、サービスを継続する処理と、継続運用を可能にするための業務ソフトウェア設計について論述することを期待,,,, ,,したが、そのような論述は少なかった。多くの受験者が、問題文で除外しているにもかかわらず、機器やデータベ,,,, ,,ースの二重化など業務ソフトウェア面での対策について論述していた。また、”継続運用に備えた処理や障害復,,,, ,,旧処理においてどのような工夫をしたか”と問うているにもかかわらず、”継続運用を可能にするための設計”に,,,, ,,関する工夫を記載している論述も散見された。,,,, ,,　システムは、常に正常に稼働しているとは限らない。システムアーキテクトとして、システム障害時の業務も想,,,, ,,定した設計を心掛けてほしい。,,,, ,,,,,, ,　サービス継続の方針に基づいて、障害時に継続運用を可能にする業務ソフトウェアの設計がテーマの問題であ,,,,, ,る。,,,,, ,　昨今の情報システムは社会を支える大きな構成要素となっており、情報システムの重要性は増大の一途をたどっ,,,,, ,ている。障害時に継続運用を可能にするためには、ハードウェアの対策として機器の二重化など、システムに冗長,,,,, ,性を持たせることが必要である。ハードウェアの冗長性に加えて、稼働する業務ソフトウェアについても耐障害性を,,,,, ,高めなければならない。障害発生時には、例えば、通信環境の切断などが発生するため、短時間に正常稼働時と同,,,,, ,じ業務環境を復旧させることが難しい。システムアーキテクトには、障害発生時であってもすべての業務が停止する,,,,, ,ことのないよう、サービス継続の方針に基づいて最低限の稼働環境が得られるように業務ソフトウェアの設計をする,,,,, ,ことが求められる。,,,,, ,　正常環境への復旧時には、障害時に仮に蓄えておいたデータの処理を進めたり、障害から復帰したことを利用者,,,,, ,に告知したりするなど、障害が取り除かれた場合の後処理についても十分考慮しなければならない。,,,,, ,,,,,, ,　設問アでは、「対象業務とシステムの概要」と「サービス継続の方針」を記述する。記述する事項は二つあるもの,,,,, ,の、「サービス継続の方針」は方針を明確に表現できればよく、簡便な記述になると考えられる。「サービス継続の方,,,,, ,針」の記述量を考えると「対象業務とシステムの概要」については、他の問題の設問アと比較すると詳しく記述できる,,,,, ,。設問アの字数は800字以内という条件だけであり、最低字数の指定はないため、採点者に「対象業務とシステムの,,,,, ,概要」が伝わればよく、無理に記述量を多くする必要はない。ただし、論文で自身のシステムアーキテクトとしての実,,,,, ,力をアピールすることを考えると、相応の記述量は確保したい。,,,,, ,,,,,, ,　設問イでは、「障害時にもサービスを継続することにした処理」と「継続運用を可能にするための業務ソフトウェアの,,,,, ,設計」を記述する。「障害時にもサービスを継続することにした処理」については、設問アで述べた「サービス継続の,,,,, ,方針」と密接に関係している。サービスを提供するための処理が「障害時にもサービスを継続することにした処理」に,,,,, ,該当する。設問イにおける記述の中心は、「継続運用を可能にするための業務ソフトウェアの設計」である。「障害時,,,,, ,にもサービスを継続することにした処理」を実現するために、どのような設計を行ったかということを掘り下げて記述,,,,, ,することになる。問題文には、小売業と金融業における業務ソフトウェアの設計例として、「本部システムの障害に備,,,,, ,え、POS売上処理を店舗システム単独で稼働可能にする」、「障害時に決済取引以外の処理を一時的に停止する機,,,,, ,能を用意しておく」という例が示されている。どちらも、「最悪の場合でもこれだけは稼働しているようにしたい」という,,,,, ,例である。「継続運用を可能にするための業務ソフトウェアの設計」の内容をどの程度まで示せばよいかという点に,,,,, ,おいても参考になる記述になっている。,,,,, ,,,,,, ,　設問ウでは、「継続運用に備えた処理や障害復旧処理における工夫点」を記述する。継続運用に備えた処理にお,,,,, ,ける工夫点、障害復旧処理における工夫点の両方について記述する必要はない。ただし、設計者の立場からは、縮,,,,, ,退運転をどうするのか、障害からどのように復旧するのかはどちらも重要な事項となるため、可能であれば両方につ,,,,, ,いて記述しておきたい。問題文には、小売業の例として、「継続運用に備えた処理」として本部のマスタと店舗のマス,,,,, ,タの両方の更新、「障害復旧処理」として配送頻度の高い食品などの発注データを優先的に処理することが示されて,,,,, ,いる。非常に分かりやすい例となっており、例を参考にして記述内容を検討できる。要求事項が一つになっているた,,,,, ,め、記述量が最低字数の600字を下回らないように注意しながら書き進める必要がある。,,,,, ,,,,,, ■見出しとストーリー,,,,,, ,,,,,, ,■設問ア,,,,, ,,,,,, ,,　設問アには、問題文の次の部分が対応する。,,,, ,,,,,, ,,,設問ア,,,あなたが開発に携わった、障害時にも継続運用を可能にするシステムについて、対象業務とシステ ,,,,,,ムの概要、サービス継続の方針について、800字以内で述べよ。 ,,,,,, ,,,　例えば、小売業で”来店する顧客が通常通り商品を購入できること”、金融業で”決済取引を止めないこと”が,,, ,,,サービス継続の方針である場合、システムアーキテクトは、次のように障害時にも継続運用を可能にする業務,,, ,,,ソフトウェアを設計する。,,, ,,,,,, ,,　例として次のような見出しとストーリーが考えられる。,,,, ,,,,,, ,,,ア　対象業務とシステムの概要、サービス継続の方針,,, ,,,ア―１　対象業務とシステムの概要,,, ,,,,,, ,,,,・,関東地域に根差した会員制のコミュニティセンタを運用するA社の会員予約システムの設計, ,,,,・,コミュニティセンタの各店舗は、簡単なフィットネス施設をもち、カルチャスクールやダンスサークルなど, ,,,,,も運営している, ,,,,・,主な利用者は、時間に余裕のある中高年層、主婦層となっている, ,,,,・,利用者は最寄りの店舗で会員登録し、会員登録した店舗をメイン店舗として利用する, ,,,,・,A社の店舗は鉄道駅の付近に位置し、多くの場合、会員はメイン店舗を利用する, ,,,,・,利用履歴の分析結果から、月に数回は別の店舗を利用する会員も少なからずいる, ,,,,・,A社の店舗はフランチャイズ制となっており、店舗経営者が店舗ごとに独自サービスを展開することが特, ,,,,,色となっている, ,,,,・,独自サービスに対応するため、A社の会員予約システムは店舗ごとのシステムとなっており、店舗サー, ,,,,,バで運営されている, ,,,,・,会員はメイン店舗のWebサイトから予約する, ,,,,・,会員であれば他の店舗の施設も利用でき、施設を利用したい店舗のWebサイトにアクセスして予約する, ,,,,・,予約の情報は、店舗ごとに管理している, ,,,,・,メイン店舗以外でも利用できるように、会員情報と利用履歴は各店舗サーバと接続している本社サーバ, ,,,,,で管理している, ,,,,・,自身の立ち場は、メーカー系のシステムインテグレータに所属するシステムアーキテクト, ,,,,,, ,,,ア―２　サービス継続の方針,,, ,,,,,, ,,,,・,会員は、会員登録したメイン店舗の利用ができること, ,,,,,, ,■設問イ,,,,, ,,,,,, ,,　設問イには、問題文の次の部分が対応する。,,,, ,,,,,, ,,,設問イ,,,設問アで述べた方針に基づいて、障害時にもサービスを継続することにした処理は何か。また、継続 ,,,,,,運用を可能にするために業務ソフトウェアをどのように設計したか。800字以上1600字以内で具体的 ,,,,,,に述べよ。 ,,,,,, ,,,　業務におけるシステムの重要性の増大に伴い、システムの障害時にもサービスを継続させることが重要とな,,, ,,,っている。システムアーキテクトは、サービス継続の方針に基づいて、機器の二重化などハードウェア面での,,, ,,,対策だけでなく、障害時に継続運用を可能にする業務ソフトウェアを設計する。,,, ,,,　例えば、小売業で”来店する顧客が通常通り商品を購入できること”、金融業で”決済取引を止めないこと”が,,, ,,,サービス継続の方針である場合、システムアーキテクトは、次のように障害時にも継続運用を可能にする業務,,, ,,,ソフトウェアを設計する。,,, ,,,,・,小売業で本部と店舗のシステムが連携してPOS売上処理を行っている場合、本部システムの障害に備, ,,,,,え、POS売上処理を店舗システム単独で稼働可能にする。このため、店舗システムにPOS売上データを, ,,,,,一時的に保持する機能を用意しておく。, ,,,,・,金融業で、ネットワークの処理能力が大幅に低下するような障害に備え、障害時に決済取引以外の処, ,,,,,理を一時的に停止する機能を用意しておく。, ,,,,,, ,,　例として次のような見出しとストーリーが考えられる。,,,, ,,,,,, ,,,イ　障害時にもサービスを継続することにした処理と継続運用を可能にするための業務ソフトウェアの設計,,, ,,,イ―１　障害時にもサービスを継続することにした処理,,, ,,,,,, ,,,,・,本社サーバに障害が生じ、本社サーバが使用できない場合や、本社と店舗を接続する回線に障害が, ,,,,,発生し、店舗と本社の通信ができなくなった場合でも、会員はメイン店舗については予約できるようにす, ,,,,,る, ,,,,,, ,,,イ―２　継続運用を可能にするための業務ソフトウェアの設計,,, ,,,,,, ,,,,・,会員情報と利用履歴が本社サーバに一括管理されている, ,,,,・,会員は利用履歴に応じてポイントがたまり、店舗を利用する料金の一部に充当できるようになっている, ,,,,・,本社サーバへアクセスできない状態であってもメイン店舗を利用できるようにするため、店舗サーバにも, ,,,,,会員に関する情報を保持するデータベースを用意する, ,,,,・,メイン店舗ごとに、メイン店舗で会員登録した会員情報と会員が保有するポイントの情報を店舗サーバ, ,,,,,にも保存する, ,,,,・,会員予約システムのソフトウェアは、本社サーバとの通信の不具合を検出した場合、予約画面を別の, ,,,,,画面に切り替え、メイン店舗以外はポイントが一時的に利用できない旨のメッセージを表示する, ,,,,・,別画面からは、店舗サーバの会員情報を参照し、予約を受け付ける, ,,,,・,メイン店舗では、ポイントも利用できる, ,,,,・,店舗サーバには予約情報、ポイントの利用情報、利用履歴などを蓄積する, ,,,,・,登録している会員はA社全体で約１０万人であり、店舗ごとの会員数は約2000人となっている, ,,,,・,データ量の増加予測は、今後5年間で約30％の増加である, ,,,,・,コミュニティセンタの営業時間は午前9時から午後10時まで, ,,,,・,夜間バッチによって本社サーバから各店舗へ店舗ごとの会員に関する情報をダウンロードし、会員の利, ,,,,,用履歴などの統計情報を本社サーバへアップロードしている, ,,,,・,夜間バッチの処理時間は、付帯処理を併せても現在30分程度であり、5年後にも1時間を超えることは, ,,,,,ない, ,,,,・,本社サーバが使用できない場合に、会員がメイン店舗以外の店舗を利用する場合は、会員カードを提, ,,,,,示して予約するものとする, ,,,,・,これまでに蓄積されているポイントは利用できないが、店舗利用によって新たに得られたポイントは蓄, ,,,,,積される, ,,,,,, ,■設問ウ,,,,, ,,,,,, ,,　設問ウには、問題文の次の部分が対応する。,,,, ,,,,,, ,,,設問ウ,,,設問イで述べた業務ソフトウェアの設計で、継続運用に備えた処理や障害復旧処理においてどのよ ,,,,,,うな工夫をしたか。600字以上1200字以内で具体的に述べよ。 ,,,,,, ,,,　このような、継続運用を可能とする業務ソフトウェアを設計する際、さらに次のような継続運用に備えた処理,,, ,,,や障害復旧処理における工夫をする。,,, ,,,,,, ,,,,・,通常時に、本部のマスタを更新する都度、店舗のマスタも同時に更新し、いつでも店舗システム単独で, ,,,,,の稼働に切り替えられるようにする。また、店舗での欠品を防止するために、復旧後、配送頻度の高い, ,,,,,食品などの発注データを優先的に処理する。, ,,,,・,ネットワークの処理能力の回復後、停止させていた業務を再開するとともに、全業務が利用可能である, ,,,,,ことを利用者の画面上に表示する仕組みを用意する。, ,,,,,, ,,,　例として次のような見出しとストーリーが考えられる。,,, ,,,,,, ,,,ウ　障害運用に備えた処理や障害復旧処理における工夫点,,, ,,,,,, ,,,,・,利用頻度が高い会員の場合、午前と午後の1日2回店舗を訪れることがある, ,,,,・,午前と午後で別の店舗を利用する場合もある, ,,,,・,会員が蓄積しているポイントを最大限に活用できるようにするため、メイン店舗以外の店舗を利用した, ,,,,,場合の利用履歴と当該利用によって得られたポイントは、利用の都度本社サーバへ転送する, ,,,,・,店舗サーバが本社サーバの障害や本社との通信障害を検知した場合、以降は、本社サーバとの接続, ,,,,,について一定の間隔で確認する, ,,,,・,本社サーバが復旧したり、通信が回復したりした場合、予約画面を通常の画面に戻し、会員に関するデ, ,,,,,ータの参照先を本社サーバに戻す, ,,,,・,縮退運転処理時メイン店舗に蓄積していた予約情報、ポイントの利用情報、利用履歴などを本社サー, ,,,,,バへ送信し、本社サーバの情報を最新にする, ,,,,・,メイン店舗以外に蓄積していた予約情報、利用履歴、獲得ポイントなどについても、本社サーバへアッ, ,,,,,プロードする, ,,,,,, ■解答,,,,,, ,,,,,, ,■設問ア,,,,, ,,,,,, ,,ア　対象業務とシステムの概要、サービス継続の方針,,,, ,,ア―１　対象業務とシステムの概要,,,, ,,,,,, ,,,　私は、メーカー系のシステムインテグレータP社に所属するシステムアーキテクトである。今回、私が携わった,,, ,,,のは、関東地域に根差した会員制のコミュニティセンタを運営するA社の会員予約システムの設計である。コミ,,, ,,,ュニティセンタの各店舗は、簡単なフィットネス施設をもち、他にカルチャスクールやダンスサークルなども運営,,, ,,,している。コミュニティセンタの主な利用者は、時間に余裕のある中高年層、主婦層である。利用者は最寄りの,,, ,,,店舗で会員登録し、会員登録した店舗をメイン店舗として利用する。各店舗は鉄道駅の近辺に位置し、多くの,,, ,,,場合、会員はメイン店舗を利用している。ただし、利用履歴の分析結果から、月に数回は別の店舗を利用する,,, ,,,会員も少なからずいる。A社の店舗はフランチャイズ制となっており、店舗経営者が店舗ごとに独自サービスを,,, ,,,展開することが特色となっている。,,, ,,,　独自サービスに対応するため、A社の会員予約システムは店舗ごとのシステムとなっており、店舗サーバで,,, ,,,運営されている。会員はメイン店舗のWebサイトから予約する。会員であれば他の店舗の施設も利用でき、施,,, ,,,設を利用したい店舗のWebサイトにアクセスして予約する。予約の情報は、店舗ごとに管理されている。一方、,,, ,,,メイン店舗以外でも利用できるように、会員情報と利用履歴は各店舗サーバと接続している本社サーバで管,,, ,,,理されている。,,, ,,,,,, ,,ア―２　サービス継続の方針,,,, ,,,,,, ,,,　A社から提示されたサービス継続の方針は、「会員は、会員登録したメイン店舗の利用ができること」である。,,, ,,,,,, ,■設問イ,,,,, ,,,,,, ,,イ　障害時にもサービスを継続することにした処理と継続運用を可能にするための業務ソフトウェアの設計,,,, ,,イ―１　障害時にもサービスを継続することにした処理,,,, ,,,,,, ,,,　サービス継続の方針に基づき、障害であってもサービスを継続することにした処理は、本社サーバに障害が,,, ,,,生じて本社サーバが使用できなかったり、本社と店舗を接続する回線に障害が発生して店舗と本社の通信が,,, ,,,できなかったりした場合でも、会員がメイン店舗については予約できるようにするための処理である。,,, ,,,,,, ,,イ―２　継続運用を可能にするための業務ソフトウェアの設計,,,, ,,,,,, ,,,　会員情報と利用履歴は、本社サーバに一括管理されている。顧客囲い込みの一環としてポイントサービスを,,, ,,,展開しており、会員は利用履歴に応じてポイントがたまり店舗を利用する料金の一部に充当できるようになっ,,, ,,,ている。ポイントの情報も本社サーバで管理されている。本社サーバへアクセスできない状態であってもメイン,,, ,,,店舗を利用できるようにするため、店舗サーバにも会員に関する情報を保持するデータベースを用意する。店,,, ,,,舗データベースには、当該店舗で会員登録した会員情報と会員が保有するポイントの情報を店舗サーバにも,,, ,,,保存することとした。,,, ,,,　会員予約システムのソフトウェアは、本社サーバとの通信の不具合を検出した場合、予約画面を縮退運転,,, ,,,用の別の画面に切り替え、メイン店舗以外はポイントが一時的に利用できない旨のメッセージを表示する。,,, ,,,メイン店舗では、障害発生時であっても、縮退運転中の画面から店舗サーバの会員情報を参照し、予約を受,,, ,,,け付けることができる。メイン店舗では、ポイントも利用できる。トランザクションデータとして、店舗サーバには,,, ,,,予約情報、ポイントの利用情報、利用履歴などを蓄積する。,,, ,,,　登録している会員はA社全体で約10万人であり、店舗ごとの会員数は約2000人となっている。データ量の増,,, ,,,加予測は、今後5年間で約３０％の増加である。コミュニティセンタの営業時間は午前9時から午後10時までと,,, ,,,なっており、夜間のバッチ処理によって、新規会員の登録情報と会員の利用履歴などの統計情報を本社サー,,, ,,,バへアップロードしている。夜間バッチの処理時間は、付帯処理を併せても現在30分程度となっており、5年後,,, ,,,にも1時間を超えることはない。本社サーバが使用できない場合に、会員がメイン店舗以外の店舗を利用する,,, ,,,ときは、会員カードを提示して予約するものとする。これまでに蓄積されているポイントは利用できないが、店,,, ,,,舗利用によって得られたポイントは蓄積される。,,, ,,,,,, ,■設問ウ,,,,, ,,,,,, ,,ウ　障害運用に備えた処理や障害復旧処理における工夫点,,,, ,,,,,, ,,,　利用履歴の分析結果から、利用頻度が高い会員では、午前と午後の1日2回店舗を訪れることがあることが,,, ,,,分かっており、午前の利用で得たポイントを午後に使いたいという会員ニーズがある。午後は住まいが離れた,,, ,,,地域の友人などと一緒に利用することもあるため、午前と午後で別の店舗を利用する場合もある。利用頻度,,, ,,,が高い会員は、A社にとって優良顧客であり、A社のプロジェクトオーナから、障害が発生した場合でも、会員,,, ,,,が蓄積しているポイントを最大限に活用できるようにするという要件が与えられていた。そのため、通常運用,,, ,,,時は、メイン店舗、メイン店舗以外に関わらず、店舗を利用したことによって得られたポイントの情報は、利用,,, ,,,の都度本社サーバへ転送する仕様となっている。私は、店舗サーバが本社サーバの障害や本社との通信障,,, ,,,害を検知した場合の処理として、以降、復旧処理の契機とするため、本社サーバとの接続について一定の間,,, ,,,隔で確認する機能を追加した。この機能により、本社サーバが復旧したり、通信が回復したりした場合に、予,,, ,,,約画面を通常の画面に戻し、会員に関するデータの参照先を本社サーバに戻すことを自動的に行わせること,,, ,,,ができる。さらに、縮退運転を行っているときにメイン店舗に蓄積していたポイントの利用情報と利用履歴など,,, ,,,を自動的に本社サーバへ送信し、本社サーバの情報を最新にすることもできる。同様に、メイン店舗以外に蓄,,, ,,,積していた利用履歴などについても、本社サーバへ自動的にアップロードできるようになる。　以上。,,, ,,,,,, 平成２４年度　問２　障害時にもサービスを継続させる業務ソフトウェアの設計,,,,,, ,,,,,, ,　業務におけるシステムの重要性の増大に伴い、システムの障害時にもサービスを継続させることが重要になって,,,,, ,いる。システムアーキテクトは、サービス継続の方針に基づいて、機器の二重化などハードウェア面での対策だけで,,,,, ,なく、障害時に継続運用を可能にする業務ソフトウェアを設計する。,,,,, ,　例えば、小売業で”来店する顧客が通常通り商品を購入できること”、金融業で”決済取引を止めないこと”がサー,,,,, ,ビス継続の方針である場合、システムアーキテクトは、次のように障害時にも継続運用を可能にする業務ソフトウェ,,,,, ,アを設計する。,,,,, ,,・,小売業で本部と店舗のシステムが連携してPOS売上処理を行っている場合、本部システムの障害に備え、PO,,, ,,,S売上処理を店舗システム単独で稼働可能にする。このため、店舗システムにPOS売上データを一時的に保,,, ,,,持する機能を用意しておく。,,, ,,・,金融業で、ネットワークの処理能力が大幅に低下するような障害に備え、障害時に決済取引以外の処理を一,,, ,,,時的に停止する機能を用意しておく。,,, ,　このような、継続運用を可能にする業務ソフトウェアを設計する際、更に次のような継続運用に備えた処理や障害,,,,, ,復旧処理における工夫をする。,,,,, ,,・,通常時に、本部のマスタを更新する都度、店舗のマスタも同時に更新し、いつでも店舗システム単独での稼働,,, ,,,に切り替えられるようにする。また、店舗での欠品を防止するために、復旧後、配送頻度の高い食品などの発,,, ,,,注データを優先的に処理する。,,, ,,・,ネットワークの処理能力の回復後、停止させていた業務を再開するとともに、全業務が利用可能であることを,,, ,,,利用者の画面上に表示する仕組みを用意する。,,, ,,,,,, ,設問ア,,,あなたが開発に携わった、障害時にも継続運用を可能にするシステムについて、対象業務とシステムの概,, ,,,,要、サービス継続の方針について、800字以内で述べよ。,, ,設問イ,,,設問アで述べた方針に基づいて、障害時にもサービスを継続することにした処理は何か。また、継続運用,, ,,,,を可能にするために業務ソフトウェアをどのように設計したか。800字以上1600字以内で具体的に述べよ。,, ,設問ウ,,,設問イで述べた業務ソフトウェアの設計で、継続運用に備えた処理や障害復旧処理においてどのような工,, ,,,,夫をしたか。600字以上1200字以内で具体的に述べよ。,, ,,,,,, ■解答例,,,,,, ,,,,,, ,（設問ア）,,,,, ,,,,,, ,１．私が開発に携わったシステムの概要と対象業務,,,,, ,,,,,, ,,　K社は、北日本の地方都市を中心に約150店舗を運営するスーパマーケットである。日本全体の人口減少やコ,,,, ,,ンビニエンスストアの拡大によって、K社の売上高は微減し続けていた。その当時、大手のスーパマーケットは、イ,,,, ,,ンターネットで注文を受け付けて、店舗から顧客が指定する場所に注文商品を配達するネットスーパ事業を開始,,,, ,,していた。K社の経営者層は、経営計画策定時に、ネットスーパ事業への参入とそれに対応するシステム（以下、,,,, ,,Nシステムという）の開発を決定した。Nシステムが対象とする主な業務は、会員管理業務、注文受付業務、商品,,,, ,,集荷業務、商品引渡業務、店舗運営管理業務である。私は、K社の情報システム部に所属するシステムアーキテ,,,, ,,クトであり、Nシステム開発プロジェクトの設計チームリーダに任命された。,,,, ,,,,,, ,２．Nシステムに関連するサービス継続方針,,,,, ,,,,,, ,,　K社のITサービスマネージャは、事業継続計画を策定・維持している。私は、その事業継続計画書を査読し、N,,,, ,,システムを含むK社のITサービス継続方針を確認した。Nシステムに関連するサービス継続方針は、以下のとおり,,,, ,,である。,,,, ,,,①,本社の建物はすべて耐火・耐震仕様になっており、本社の建物の全損壊を想定しない。,, ,,,②,万一、本社の建物が全損壊した場合は、その復旧までITサービスは停止したままとする。,, ,,,③,本社に設置されるサーバは複数台で構成し、耐障害性を確保する。,, ,,,④,本社は2つのISP（Internet Service Provider）と契約し、いずれか1つを迂回回線とする。,, ,,,⑤,本社と各店舗は、IP-VPNによって接続する。IP-VPNが通信不能になった場合、店舗単独で運用を継続す,, ,,,,る。,, ,,,⑥,各店舗のサーバとPOS端末は複数台で構成し、耐障害性を確保する。,, ,,,⑦,一部の店舗が損壊した場合でも、残りの店舗は運用を継続する。,, ,,,,,, ,（設問イ）,,,,, ,,,,,, ,１．障害時にもサービスを継続することにした処理,,,,, ,,,,,, ,,　私は、ネットスーパ事業がK社にとって重要な新事業であり、障害時にもNシステムが提供するITサービスを,,,, ,,継続させることが重要になっていると考えた。Nシステムが対象とする業務のうち、日常業務として必須の業務は,,,, ,,、注文受付業務、商品集荷業務、商品引渡業務である。私は、これらの3業務を、障害時にもサービスを継続しな,,,, ,,ければならない処理に指定した。,,,, ,,,,,, ,２．継続運用を可能にするための業務ソフトウェア設計,,,,, ,,,,,, ,,　私は、設問アで述べたサービス継続方針を踏まえ、本社と店舗間のIP-VPNが通信不能になる障害（以下、回,,,, ,,線障害という）を想定した。回線障害が発生した場合、,,,, ,,,①,本社サーバに登録されている注文受付情報を店舗サーバに転送できない。,, ,,,②,店舗サーバに登録されている商品引渡実績情報を本社サーバに転送できない。,, ,,の2つの不具合が発生する。私は、回線障害時に業務の継続運用を可能にする、以下の2点のような業務ソフト,,,, ,,ウェアを設計した。,,,, ,,,,,, ,２．１　注文受付処理を一時的に停止する機能,,,,, ,,,,,, ,,　私は、回線障害が発生した店舗番号を本社サーバに登録し、その店舗から商品を配送するWeb注文入力を一,,,, ,,時的に停止する機能を追加した。私は、これによって注文を受け付けたにもかかわらず、商品が店舗から配送さ,,,, ,,れない不具合を解消した。しかし、この機能追加だけでは、回線障害が発生した店舗について、新規注文の受付,,,, ,,が出来なくなる。そこで、私は電話による注文受付が可能である旨の表示を、一時的に注文入力を停止させた注,,,, ,,文画面に表示させることとした。,,,, ,,,,,, ,２．２　店舗システム単独での稼働を可能にする機能,,,,, ,,,,,, ,,　私は、回線障害発生時に、店舗サーバとPOS端末だけで業務が継続できるように下記の設計をした。,,,, ,,,,,, ,２．２．１　注文受付業務,,,,, ,,,,,, ,,　私は、回線障害発生時には、電話によってNシステムの会員（以下、N会員という）からの注文を受け付ける設,,,, ,,計をした。私は、具体的には、POS端末に注文画面を表示し、店舗担当者が注文の電話を受けながら、注文受付,,,, ,,情報を店舗サーバに登録する機能を追加した。,,,, ,,,,,, ,２．２．２　商品集荷業務,,,,, ,,,,,, ,,　私はこの業務を、,,,, ,,,①,本社サーバから店舗サーバに転送された注文受付情報、もしくは２．２．１の機能を使って登録された注文,, ,,,,受付情報を配送予定日の12:00ごろに店舗サーバから印刷する。,, ,,,②,店舗担当者は、①で印刷された注文受付情報に従って店舗内もしくは店舗に付属する倉庫から商品を集,, ,,,,荷して、POS端末でスキャンし、商品集荷情報を店舗サーバに登録する。,, ,,,③,②の商品を店舗内の所定の場所に置く。,, ,,の手続きで設計した。,,,, ,,,,,, ,２．２．３　商品引渡業務,,,,, ,,,,,, ,,　私はこの業務を、,,,, ,,,①,２．２．２で店舗内の所定の場所に置かれた商品をN会員の自宅もしくは指定された場所に配送する場合、,, ,,,,店舗担当者は集荷された商品を宅配会社の担当者に引渡し、POS端末にその完了入力を行う。,, ,,,②,N会員が来店する場合、店舗担当者は集荷された商品を会員に引き渡す。,, ,,,③－１,,,Web注文入力の時点でクレジットカード決済がなされている場合、商品引渡完了入力をPOS端末に ,,,,,,行う。 ,,,③－２,,,Web注文入力時に現金払いを選択している場合、N会員から代金を受領し、POS端末に登録する。 ,,の手続きで設計した。,,,, ,,,,,, ,（設問ウ）,,,,, ,,,,,, ,１．私が実施した継続運用処理や障害復旧処理上の工夫,,,,, ,,,,,, ,,　私は、設問イで述べた業務ソフトウェアの設計で、継続運用に備えた処理や障害復旧処理において、以下の3,,,, ,,点の工夫をした。,,,, ,,,,,, ,１．１　注文受付情報の店舗サーバへの即時転送,,,,, ,,,,,, ,,　N会員がWebブラウザを使って登録した注文受付情報は、本社サーバに格納される。回線障害が発生した後に,,,, ,,、本社サーバに登録された注文受付情報は、店舗サーバに転送できなくなる。そこで、本社サーバに注文受付情,,,, ,,報が格納される都度、商品集荷及び引渡を担当する店舗の店舗サーバに当該注文受付情報を即時に転送する,,,, ,,設計をした。これによって、私は回線障害発生前のすべての注文受付情報を店舗サーバに記録させ、店舗シス,,,, ,,テム単独での稼働が円滑に行われるように工夫した。,,,, ,,,,,, ,１．２　回線障害が発生した場合の代替手段の確保,,,,, ,,,,,, ,,　IP-VPNに回線障害が発生したときに、インターネットは動作している、もしくは宅急便やK社配送網が利用可能,,,, ,,なケースが考えられた。そこで、私は、以下の3つの機能を追加する工夫をした。,,,, ,,,①,本社の運用担当者は、回線障害が発生後に、本社サーバに登録された注文受付情報のうち、回線障害が,, ,,,,発生した店舗の注文受付情報をCSVファイルに抽出する処理を実行し、本社サーバの注文受付情報ファイ,, ,,,,ルの代替転送区分を”転送済”にする。,, ,,,②,CSVファイルを電子メールや宅急便などで、回線障害が発生した店舗の担当者に送付する。,, ,,,③,②のCSVファイルを受け取った店舗担当者は、それを店舗サーバの注文受付情報ファイルに追加し、その,, ,,,,代替受入区分を”受入済”にする処理を実行する。,, ,,,,,, ,１．３　回線障害復旧後の業務再開の告知,,,,, ,,,,,, ,,　私は、回線障害が復旧した後、停止させていた業務を再開するとともに、全業務が利用可能であることをN会員,,,, ,,のログイン画面及び注文画面上に表示する仕組みを用意した。また、私は、回線障害発生のお詫びと業務の再,,,, ,,開を、N会員にお知らせメールで通知する工夫をした。,,,, ,,,,,, 平成２５年度　問１　要求を実現する上での問題を解消するための業務部門への提案,,,,,, ,,,,,, ,　情報システムの開発における要件定義では、業務を担当する部門（以下、業務部門という）からの要求を、どのよう,,,,, ,に情報システムを活用して実現するかを検討する。しかしその過程で、次のような、要求を実現する上での問題が発,,,,, ,生する場合がある。,,,,, ,,・,処理時間が長くなり、求められる時間内に終了しないことが明白である。,,, ,,・,データを必要なタイミングで取得できない。,,, ,,・,コストに見合った効果が得られない。,,, ,　システムアーキテクトは、このような問題を解消または軽減するために、コストや納期と、業務上の効果とを総合的,,,,, ,に検討したうえで、業務部門に、例えば次のような提案をする。,,,,, ,,・,処理時間が長くなる場合、業務に影響の少ない範囲で月次処理の一部を事前に行うなど、業務処理の単位を,,, ,,,見直して、情報システムで対応する。,,, ,,・,経費関連の数値が月次でしか取得できない場合、日次決算では実績から算出したみなしの数値を利用すると,,, ,,,いう業務ルールを提示し、情報システムもこれに対応する。,,, ,,・,コストに見合った効果が得られない場合、一部の業務機能をシステム化の対象から除外し、情報システムに,,, ,,,よらない対応策を提示する。,,, ,　また、提案の際、業務部門が提案の採否を判断しやすいように、コストや納期に加えて、業務の特性及びシステム,,,,, ,化の目的を踏まえた評価項目などを提示し、業務上の効果について、提案を採用する場合としない場合とを対比す,,,,, ,ることも重要である。,,,,, ,,,,,, ,設問ア,,,あなたが携わった情報システムの要件定義について、その概要を、開発の背景、対象の業務、業務部門,, ,,,,からの要求を含めて、800字以内で述べよ。,, ,設問イ,,,設問アで述べた要件定義で、要求を実現する上でどのような問題が発生したか。また、その問題を解消又,, ,,,,は軽減するために、業務部門にどのような提案をしたか。業務や情報システムでの対応を中心に、800字,, ,,,,以上1600字以内で具体的に述べよ。,, ,設問ウ,,,設問イで述べた提案の中で、業務部門が提案の採否を判断しやすいように提示した評価項目などと、提案,, ,,,,を採用する場合としない場合とを対比して評価した業務上の効果、及びその評価結果について、600字以,, ,,,,上1200字以内で具体的に述べよ。,, ,,,,,, ■ポイント,,,,,, ,,,,,, ,■出題趣旨,,,,, ,,,,,, ,,　要件定義では、要求を実現する上で問題が発生する場合がある。システムアーキテクトは、このような場合、業,,,, ,,務部門に対して問題を解消又は軽減するための提案をする。,,,, ,,　本問は、要件定義で提示された要求を実現する上で発生した問題の解消又は軽減のための提案について、具,,,, ,,体的に論述することを求めている。論述を通じて、システムアーキテクトに必要な、相反する要求を認識し、解決,,,, ,,策を見出す能力、提案力、実行力、経験などを評価する。,,,, ,,,,,, ,■採点講評,,,,, ,,,,,, ,,　全問に共通して、具体的で、経験に基づいていることをうかがわせる論述が多かった。また、問題文の引用で文,,,, ,,字数を費やし、内容が薄くなってしまっている論述については昨年度から減少した。一方で、問題文に例示した項,,,, ,,目を抜き出し、一般論と組み合わせて論述を構成する傾向については、昨年度と同様に多く見受けられた。問題,,,, ,,文に記載した項目は事例として挙げたものであり、受験者は設問で求められていることを把握したうえで、問題文,,,, ,,中の事例にとらわれすぎることなく、実際の経験に基づいた具体的な論述をするよう、心掛けてほしい。,,,, ,,　問１（要求を実現する上での問題を解消するための業務部門への提案について）は、多くの解答が経験を踏ま,,,, ,,え、設問に沿って具体的に論述をしていた。本問では、要件定義における問題の解消をシステムアーキテクトとし,,,, ,,て論述することを求めた。しかし、要件定義ではなく、設計段階やテストにおける問題に関する論述や、解消策が,,,, ,,体制面や期間調整などプロジェクトマネジメントの側面からの論述なども散見された。,,,, ,,,,,, ,　要求を実現する上で発生した問題を解消するための、業務部門への提案がテーマの問題である。情報システムの,,,,, ,開発においては、業務部門から様々な要求が示される。しかし、要求通りの内容を情報システムで実現しようとする,,,,, ,と、処理時間が長くなったり、データを必要なタイミングで取得できなかったりするなど、期待した結果が得られない,,,,, ,場合がある。システムアーキテクトは、問題を解消するために、情報システムを開発するためのコストや納期と情報,,,,, ,システムによって得られる業務上の効果とを総合的に検討して、業務部門に解決策を提案する必要がある。,,,,, ,,,,,, ,　設問アでは、「要件定義の概要」、「開発の背景」、「対象の業務」、「業務部門からの要求」を記述する。対象の業,,,,, ,務は、システムアーキテクト試験における定番の要求事項であり、準備しておけば容易に記述できると考えられる。,,,,, ,要件定義の概要についても、受験者が携わった要件定義であればどのような要件定義であっても題材にできる。情,,,,, ,報システムの開発における要件定義では、大なり小なり何らかの問題が発生するため、情報システムの選択に苦労,,,,, ,することはないと考えられる。問題文からは、「何を概要とするか」が読み取れないため、要件定義に関する記述とい,,,,, ,うことが分かれば十分である。,,,,, ,,,,,, ,　設問イでは、「要求を実現する上で発生した問題」と「問題を解消又は軽減するために業務部門に行った提案」を記,,,,, ,述する。「要求を実現する上で発生した問題」について、問題文には、「処理時間が長くなり、求められる時間内に終,,,,, ,了しないことが明白である」、「データを必要なタイミングで取得できない」、「コストに見合った効果が得られない」とい,,,,, ,う要求が実現できない例が示されている。この問題では利用部門の要求をそのまま実現できないため、業務や情報,,,,, ,システムでどのように対応したかということが要求されていることが分かる。「問題を解消又は軽減するために業務,,,,, ,部門に行った提案」についても例が示されている。具体的には、「処理時間が長くなる場合、業務に影響の少ない範,,,,, ,囲で月次処理の一部を事前に行うなど、業務処理の単位を見直して、情報システムで対応する」、「経費関連の数値,,,,, ,が月次でしか取得できない場合、日次決算では実績から算出したみなしの数値を利用するという業務ルールを提示,,,,, ,し、情報システムもこれに対応する」、「コストに見合った効果が得られない場合、一部の業務機能をシステム化の対,,,,, ,象から除外し、情報システムによらない対応策を提示する」となっている。それぞれの提案内容は、「要求を実現する,,,,, ,上で発生した問題」の例に対応しているため、業務部門に行った提案としてどのようなレベルの記述が求められてい,,,,, ,るかが分かる。いずれの提案も平易な内容になっており、情報システムの開発において受験者が行った提案をスト,,,,, ,レートに表現すれば題意を満たすと考えられる。,,,,, ,,,,,, ,　設問ウでは、「業務部門が提案の採否を判断しやすいように提示した評価項目」、「評価した業務上の効果」、「評,,,,, ,価結果」を記述する。設問ウに対応する問題文に、「コストや納期に加えて、業務の特性及びシステム化の目的を踏,,,,, ,まえた評価項目などを提示」とあるため、コストと納期以外に、業務の特性、システム化の目的について評価できる,,,,, ,ような評価項目を記述しなければならない。「評価した業務上の効果」については、「提案を採用する場合としない場,,,,, ,合を対比して」と補足されている。要求を実現する上で発生した問題は、何らかの対応をしなければ利用部門の要求,,,,, ,が実現できないということである。したがって、「提案を採用する場合としない場合を対比する」ということは、１つの提,,,,, ,案を採用するかしないかではなく、複数の提案のどれを採用し、どれを採用しないかということを示していると考えら,,,,, ,れる。設問ウに関しては、問題文に参考となる例がないため、ストーリーを作成するときに記述内容をよく吟味してお,,,,, ,く必要がある。,,,,, ,,,,,, ■見出しとストーリー,,,,,, ,,,,,, ,■設問ア,,,,, ,,,,,, ,,　設問アには、対応する問題文がなく、自身の経験に基づき要求事項を記述する。,,,, ,,,,,, ,,設問ア,,,あなたが携わった情報システムの要件定義について、その概要を、開発の背景、対象の業務、業務部, ,,,,,門からの要求を含めて、800字以内で述べよ。, ,,,,,, ,,　例として次のような見出しとストーリーが考えられる。,,,, ,,,,,, ,,,ア　要件定義の概要、開発の背景、対象の業務、業務部門からの要求,,, ,,,ア―１　要件定義の概要,,, ,,,,,, ,,,,・,電子部品を製造・販売するA社, ,,,,・,A社の主要顧客は複数の大手の家電メーカー, ,,,,・,再構築について、システムインテグレータB社が受注し、システムアーキテクトである私が要件定義を取, ,,,,,りまとめる, ,,,,・,要件定義の期間は2か月、要件定義を担当するのは、私と数名のプロパ社員とA社の品質管理部門、, ,,,,,情報システム部門のメンバの合計10名, ,,,,・,自身の立場は、独立系のシステムインテグレータに所属するシステムアーキテクト, ,,,,,, ,,,ア―２　開発の背景,,, ,,,,,, ,,,,・,昨今の経済情勢から、大手の家電メーカーの値下げ要求が厳しく、生産効率を向上することを検討して, ,,,,,おり、品質管理システムを再構築する, ,,,,・,生産効率の向上とともに、不良品の発生を徹底して削減することも検討している, ,,,,,, ,,,ア―３　対象の業務,,, ,,,,,, ,,,,・,不良品の発生を削減するために、日々の品質状況をチェックする, ,,,,・,過去1か月分の生産データを統計的に処理し、原因分析と対応策を検討することが品質管理部門の重, ,,,,,要テーマ, ,,,,,, ,,,ア―４　業務部門からの要求,,, ,,,,,, ,,,,・,電子部品の生産ラインは8時～22時まで稼働しており、2交代の体制で運用されている, ,,,,・,生産ライン停止後、日次バッチ処理やバックアップ処理などが稼働しており、分析用のデータも夜間に, ,,,,,作成する, ,,,,・,品質管理部門が業務を開始する9時までに分析データを渡してほしい, ,,,,,, ,■設問イ,,,,, ,,,,,, ,,　設問イには、問題文の次の部分が対応する。,,,, ,,,,,, ,,,設問イ,,,設問アで述べた要件定義で、要求を実現する上でどのような問題が発生したか。また、その問題を ,,,,,,解消又は軽減するために、業務部門にどのような提案をしたか。業務や情報システムでの対応を中 ,,,,,,心に、800字以上1600字以内で具体的に述べよ。 ,,,,,, ,,,　しかしその過程で、次のような、要求を実現する上での問題が発生する場合がある。,,, ,,,,・,処理時間が長くなり、求められる時間内に終了しないことが明白である。, ,,,,・,データを必要なタイミングで取得できない。, ,,,,・,コストに見合った効果が得られない。, ,,,　システムアーキテクトは、このような問題を解消又は軽減するために、コストや納期と、業務上の効果とを総,,, ,,,合的に検討したうえで、業務部門に、例えば次のような提案をする。,,, ,,,,・,処理時間が長くなる場合、業務に影響の少ない範囲で月次処理の一部を事前に行うなど、業務処理の, ,,,,,単位を見直して、情報システムで対応する。, ,,,,・,経費関連の数値が月次でしか取得できない場合、日次決算では実績から算出したみなしの数値を利用, ,,,,,するという業務ルールを提示し、情報システムもこれに対応する。, ,,,,・,コストに見合った効果が得られない場合、一部の業務機能をシステム化の対象から除外し、情報システ, ,,,,,ムによらない対応策を提示する。, ,,,,,, ,,　例として次のような見出しとストーリーが考えられる。,,,, ,,,,,, ,,,イ　要求を実現する上で発生した問題、問題を解消または軽減するために業務部門に行った提案,,, ,,,イ―１　要求を実現する上で発生した問題,,, ,,,,,, ,,,,・,分析対象となる部品の種類が多く、過去1か月分では数百万件のデータ処理となる, ,,,,・,処理対象のデータは属性が多く、複雑な統計処理が必要で、計算量も多い, ,,,,・,生産ライン停止後、翌日の生産ライン始動までには10時間のインターバル, ,,,,・,現状ではバッチ処理やバックアップ処理などに約6時間を要しており、処理の異常終了などに対応する, ,,,,,ために2時間程度の余裕を見ている, ,,,,・,分析データ作成を2時間以内に完了させる必要がある, ,,,,・,A社に確認すると、家電製品には季節によって売れ行きの異なるものがあり、製造する部品にも季節変, ,,,,,動が生じる, ,,,,・,処理対象のデータにも変動があり平均値に対してプラスマイナス１０％程度となる見込み, ,,,,・,机上の試算とサンプルデータを用いたプロトタイプで評価すると、データ量の多いときには2時間以内で, ,,,,,処理が終了しないことが判明, ,,,,,, ,,,イ―２　問題を解消又は軽減するために業務部門に行った提案,,, ,,,,,, ,,,,・,前日分のデータを流用することを検討したが、移動平均の期間が長く、当日分のデータを加えた再計算, ,,,,,が必要なために、計算量はあまり少なくならない, ,,,,・,提案は3点, ,,,,,・,分析データを作成する時間と余裕を考慮してデータの提供時刻を12時とする ,,,,,・,計算量を削減するために移動平均の期間を短くする ,,,,,・,計算量を削減するために業務の観点から分析対象とする部品を限定する ,,,,,, ,■設問ウ,,,,, ,,,,,, ,,　設問ウには、問題文の次の部分が対応する。,,,, ,,,,,, ,,,設問ウ,,,設問イで述べた提案の中で、業務部門が提案の採否を判断しやすいように提示した評価項目などと ,,,,,,、提案を採用する場合としない場合とを対比して評価した業務上の効果、及びその評価結果につい ,,,,,,て、600字以上1200字以内で具体的に述べよ。 ,,,,,, ,,,　また、提案の際、業務部門が提案の採否を判断しやすいように、コストや納期に加えて、業務の特性及びシ,,, ,,,ステム化の目的を踏まえた評価項目などを提示し、業務上の効果について、提案を採用する場合としない場,,, ,,,合とを対比することも重要である。,,, ,,,,,, ,,　例として次のような見出しとストーリーが考えられる。,,,, ,,,,,, ,,,ウ　業務部門が提案の採否を判断しやすいように提示した評価項目、評価した業務上の効果、評価結果,,, ,,,ウ―１　業務部門が提案の採否を判断しやすいように提示した評価項目,,, ,,,,,, ,,,,・,評価項目として提示したのは、コストと納期に加え、品質管理部門の業務の特性を踏まえ、システム化, ,,,,,の目的を達成するために必要となるデータ分析の品質, ,,,,,, ,,,ウ―２　評価した業務上の効果,,, ,,,,,, ,,,,・,データの提供時刻を遅らせる場合と対象とする部品を限定する場合の処理は同じ, ,,,,・,移動平均の時間を短くする場合については、計算量は少なくなるものの処理内容は、他の案の場合に, ,,,,,類似, ,,,,・,処理内容を鑑みると、開発のためのコスト、納期については3つの提案についてほぼ同じと考えられる, ,,,,・,データの品質について、データの提供時刻を遅らせる場合は、当初の予定通りとなるが、品質管理部門, ,,,,,の対応が半日遅れることになり業務上の影響が非常に大きい, ,,,,・,移動平均の期間を短くすると、データの品質が低下し、データを用いた判断に誤りが生じる可能性があ, ,,,,,る, ,,,,・,季節変動のある部品について、生産しない期間や生産量が少なくなったりする期間は、当該部品の統, ,,,,,計情報がなくても品質管理部門の業務に与える影響が少ない, ,,,,,, ,,,ウ―３　評価結果,,, ,,,,,, ,,,,・,業務への影響が一番小さいと考えられる対象とする部品を限定する案を採用, ,,,,・,統計処理をしない部品について、統計処理をする前の素データを品質管理部門に提供し、EUCなどによ, ,,,,,って簡易チェックすることで合意, ,,,,,, ■解答,,,,,, ,,,,,, ,■設問ア,,,,, ,,,,,, ,,ア　要件定義の概要、開発の背景、対象の業務、業務部門からの要求,,,, ,,ア―１　要件定義の概要,,,, ,,,,,, ,,,　私は、独立系のシステムインテグレータB社に所属するシステムアーキテクトである。今回、私が携わったの,,, ,,,は、電子部品を製造・販売するA社の品質管理システムの再構築である。A社の主要な顧客は、複数の大手,,, ,,,の家電メーカーである。本案件をB社が受注し、システムアーキテクトである私が要件定義を取りまとめること,,, ,,,となった。要件定義の期間は2か月、要件定義を担当するのは、私と数名のB社プロパ社員、A社の品質管理,,, ,,,部門、情報システム部門のメンバの合計10名である。,,, ,,,,,, ,,ア―２　開発の背景,,,, ,,,,,, ,,,　昨今の経済情勢から、大手の家電メーカーからA社に対する値下げ要求が厳しく、A社では生産効率を向上,,, ,,,することに関連して、不良品の発生を徹底して削減するため、関連する品質管理システムを再構築することと,,, ,,,なった。,,, ,,,,,, ,,ア―３　対象の業務,,,, ,,,,,, ,,,　不良品の発生を削減するためには、日々の品質状況を徹底的にチェックする必要があり、過去1か月分の生,,, ,,,産データを統計的に処理し、原因分析と対応策を検討することが品質管理部門の重要テーマとなっている。,,, ,,,,,, ,,ア―４　業務部門からの要求,,,, ,,,,,, ,,,　電子部品の生産ラインは8時から22時まで稼働しており、2交代の体制で運用されている。現在は、生産ライ,,, ,,,ン停止後、日次バッチ処理やバックアップ処理などが稼働しており、分析用のデータも夜間に作成することに,,, ,,,なる。品質管理部門からは、業務を開始する9時までに分析データを渡してほしいという要求であった。,,, ,,,,,, ,■設問イ,,,,, ,,,,,, ,,イ　要求を実現する上で発生した問題、問題を解消又は軽減するために業務部門に行った提案,,,, ,,イ―１　要求を実現する上で発生した問題,,,, ,,,,,, ,,,　分析対象となる部品の種類が多く、分析データを作成するために過去1か月分では数百万件のデータ処理,,, ,,,が必要である。重ねて、処理対象のデータの属性が多岐にわたるため、統計処理そのものが複雑で、かつ計,,, ,,,算量も膨大になることが考えられた。現在、生産ライン停止後、翌日の生産ライン始動までには10時間のイン,,, ,,,ターバルがあり、日々のバッチ処理やバックアップ処理などに約6時間を要している。バッチ処理やバックアッ,,, ,,,プ処理が異常終了した場合に対応するため、2時間程度の余裕をみている。翌日の生産ラインの始動や品質,,, ,,,管理部門の業務開始時刻を考えると、分析データの作成を2時間以内で完了させる必要がある。A社の関連,,, ,,,部門に確認すると、A社が部品を販売している家電メーカーにおいて、家電製品には季節によって売れ行きの,,, ,,,異なるものがあり、製造する部品にも季節変動が生じることが判明した。分析データを作成するために必要と,,, ,,,なる処理対象のデータにも変動があり平均値に対してプラスマイナス１０％程度となる見込みである。私は、,,, ,,,机上の試算とサンプルデータを用いたプロトタイプでの評価を行った。評価結果によると、データ量の多い時,,, ,,,には2時間以内で処理が終了しないことが判明し、当初の要件では業務部門の要求を実現することが困難で,,, ,,,あった。,,, ,,,,,, ,,イ―２　問題を解消又は軽減するために業務部門に行った提案,,,, ,,,,,, ,,,　私は、分析データの作成に当たり、当日分のデータを流用し、差分として当日分のデータを加えて計算する,,, ,,,方法を検討した。しかし、統計処理のための移動平均の期間が長く、当日分のデータを加えた再計算が必要,,, ,,,なために、計算量はあまり少なくならないことが分かった。業務部門の要求に対応するためには、処理時間の,,, ,,,延長やデータ量の削減など抜本的な見直しが必要であった。具体的には、私は次の3点を業務部門に提案し,,, ,,,た。,,, ,,,（１）分析データを作成する時間と余裕時間を考慮してデータの提供時刻を9時から12時に変更する,,, ,,,（２）計算量を削減するために統計処理のための移動平均の期間を短くする,,, ,,,（３）計算量を削減するために業務の観点から分析対象とする部品を限定する,,, ,,,,,, ,■設問ウ,,,,, ,,,,,, ,,ウ　業務部門が提案の採否を判断しやすいように提示した評価項目、評価した業務上の効果、評価結果,,,, ,,ウ―１　業務部門が提案の採否を判断しやすいように提示した評価項目,,,, ,,,,,, ,,,　私が業務部門に評価項目として提示したのは、コストと納期に加え、品質管理部門の業務の特性を踏まえ、,,, ,,,システム化の目的を達成するために必要となる分析データの品質とした。,,, ,,,,,, ,,ウ―２　評価した業務上の効果,,,, ,,,,,, ,,,○コスト及び納期,,, ,,,,,, ,,,,　今回の提案のポイントは、（１）データの提供時刻を遅らせる、（２）移動平均の期間を短くする、（３）処理,, ,,,,対象の部品を限定するというものである。（１）のデータの提供時刻を遅らせる場合と、（３）の処理対象の,, ,,,,部品を限定する場合について、処理内容は同じである。（２）の移動平均の期間を短くする場合については,, ,,,,、計算量は少なくなるものの、処理内容は（１）と（３）の場合に類似している。したがって、（１）～（３）のいず,, ,,,,れについても処理内容を鑑みると、コスト及び納期については大差はないと判断し、業務部門に提示した。,, ,,,,,, ,,,○データの品質,,, ,,,,,, ,,,,　（１）のデータの提供時刻を遅らせる場合は、当初の予定通りの情報を品質管理部門が得ることができる,, ,,,,。しかし、品質管理部門の対応が半日遅れることになり業務上の影響が非常に大きい。（２）の移動平均の,, ,,,,期間を短くする場合は、データの品質そのものが低下し、データを用いた判断に誤りが生じる可能性があり,, ,,,,、（１）の場合と同様、業務への影響が大きくなる。（３）の対象とする部品を限定する場合は、季節変動のあ,, ,,,,る部品について、生産しない期間や生産量が少なくなったりする期間は、当該部品の統計情報がなくても,, ,,,,品質管理部門の業務に与える影響が少ない。,, ,,,,,, ,,ウ―３　評価結果,,,, ,,,,,, ,,,　業務への影響が一番少ないと考えられる対象とする部品を限定する案を採用することとなった。統計処理を,,, ,,,しない部品については、統計処理する前の素データを品質管理部門に提供し、EUCなどによって簡易チェック,,, ,,,することで合意できた。　以上,,, ,,,,,, 平成２５年　問２　設計内容の説明責任,,,,,, ,,,,,, ,　システムアーキテクトには、システム開発関係者に十分な情報を提供し、設計した内容が適切であることを説明す,,,,, ,る責任がある。そのためには、説明する相手に応じて、理解してほしい項目とその説明の観点を明確にしなければ,,,,, ,ならない。,,,,, ,　例えば、ソフトウェア開発リーダにソフトウェア方式を説明する場合には、ソフトウェア要件定義書に基づき、ソフト,,,,, ,ウェアの最上位レベルの構成及びコンポーネントが果たすべき機能が業務要件と整合していることを理解してもらう,,,,, ,。その際、次のような観点から説明する。,,,,, ,,・,対象業務の機能要件及び非機能要件と、コンポーネント分割の方針との整合性,,, ,,・,コンポーネント分割の方針に従って設計したソフトウェア構造、そのソフトウェア構造の業務変化への対応容,,, ,,,易性などの評価項目と評価結果,,, ,　また、ITサービスマネージャに障害時の対応処理方式を説明する場合には、ITサービス要件で定めた目標に基づ,,,,, ,き、設計したハードウェア構成及びソフトウェア方式によって目標を達成できることを理解してもらう。その際、次のよ,,,,, ,うな観点から説明する。,,,,, ,,・,障害への対応方針と、その方針に従った障害対応処理の設計内容,,, ,,・,設計した障害対応手順などがITサービス要件を満たしていると判断した根拠,,, ,　さらに、限られた時間内で効率よく理解してもらえるように、構成を含めプレゼンテーションを工夫することも重要で,,,,, ,ある。例えば、全体を説明した上で各論を説明するために、全体を俯瞰できる資料及び個別の論点と結論を明確に,,,,, ,した資料を用意する。,,,,, ,,,,,, ,設問ア,,,あなたが設計に携わったシステムとその対象業務、及びあなたが責任を持って説明した設計の概要につ,, ,,,,いて、800字以内で述べよ。,, ,設問イ,,,設問アで述べた設計の内容を、誰に、どのような項目を理解してもらうために、どのような観点から説明し,, ,,,,たか。800字以上1600字以内で具体的に述べよ。,, ,設問ウ,,,設問イで述べた説明を限られた時間内で効率よく理解してもらえるように、どのようにプレゼンテーションを,, ,,,,工夫したか。また、その結果から、プレゼンテーションの内容について改善すべきと考えた点について、600,, ,,,,字以上1200字以内で具体的に述べよ。,, ,,,,,, ■ポイント,,,,,, ,,,,,, ,■出題趣旨,,,,, ,,,,,, ,,　システムアーキテクトには、システム開発関係者に対して十分な情報を提供し、設計した内容が適切であること,,,, ,,を理解してもらえるよう、説明する責任がある。そのためには、説明する相手に応じて理解してほしい項目とその,,,, ,,説明の観点を明確にしなければならない。さらに、限られた時間内で効率よく理解してもらえるように、構成を含,,,, ,,めプレゼンテーションを工夫することも重要である。,,,, ,,　本問は、システムアーキテクトがシステム開発関係者に対して、システム設計の内容が適切であることを、責任,,,, ,,を持って説明する方法について、具体的に論述することを求めている。論述を通じて、システムアーキテクトに必,,,, ,,要な設計内容を説明する能力を評価する。,,,, ,,,,,, ,■採点講評,,,,, ,,,,,, ,,　全問に共通して、具体的で、経験に基づいていることをうかがわせる論述が多かった。また、問題文の引用で文,,,, ,,字数を費やし、内容が薄くなってしまっている論述については昨年度から減少した。一方で、問題文に例示した項,,,, ,,目を抜き出し、一般論と組み合わせて論述を構成する傾向については、昨年度と同様に多く見受けられた。問題,,,, ,,文に掲載した項目は事例として挙げたものであり、受験者は設問で求められていることを把握したうえで、問題文,,,, ,,中の事例にとらわれすぎることなく、実際の経験に基づいた具体的な論述をするよう、心掛けてほしい。,,,, ,,　問２（設計内容の説明責任について）では、設計した内容を、関係者に対して、どのような観点から説明したの,,,, ,,かについて、自らの経験に沿って論述することを期待した。この意図を理解して選択した受験者は、適切な論述,,,, ,,をしていた。ただ、”説明した内容”と”説明の観点”の違いを理解できずに選択したと思われる受験者も多く、この,,,, ,,場合は設計項目を羅列した論述や設計過程を述べただけの論述になっていた。この意味で、全体では題意に沿,,,, ,,った論述と、そうでない論述に二極化しており、後者が多かった。,,,, ,,,,,, ,　システム開発関係者に対する設計内容の説明責任がテーマの問題である。設計内容が、システムアーキテクトの,,,,, ,独善的な考えに基づくものではなく、適切であることを説明する責任をシステムアーキテクトは負っている。システム,,,,, ,開発関係者は多岐にわたり、例えば、ソフトウェア開発リーダとITサービスマネージャでは、設計内容において関心,,,,, ,の事項は異なる。設計内容の説明に際しては、説明する相手に応じて理解してほしい項目と説明の観点を明らかに,,,,, ,しておく必要がある。,,,,, ,　説明するための時間には限りがある。設計内容をシステム開発関係者に効率よく理解してもらうためには、プレゼ,,,,, ,ンテーションに相応の工夫が必要である。プレゼンテーションの内容と質は、説明者の経験の差に左右される。経,,,,, ,験豊富な説明者であっても、説明の順序を入れ替えたほうが良かったなど、プレゼンテーション中やプレゼンテーシ,,,,, ,ョン後に改善点に気づくことがある。プレゼンテーションスキルの向上のためには継続的に研鑽する必要がある。,,,,, ,,,,,, ,　設問アでは、「設計に携わったシステム」、「対象業務」、「責任を持って説明した設計の概要」を記述する。対象の,,,,, ,システムと対象の業務は、システムアーキテクト試験における定番の要求事項であり、準備しておけば容易に記述,,,,, ,できると考えられる。問題文には対象を制約するような記述はなく、どのようなシステムや業務であっても良い。シス,,,,, ,テムと業務の両方が要求事項であるため、例えば、システムの説明に終始することのないように注意したい。責任を,,,,, ,もって説明した設計の概要について、設問アの800字以内という制約の下ではすべてを記述することは難しい。責任,,,,, ,を持って説明した部分を中心に概要をまとめるとよいと考えられる。,,,,, ,,,,,, ,　設問イでは、「誰に」、「どのような項目を理解してもらうために」、「どのような観点から」説明したかを記述する。説,,,,, ,明した相手については、システム開発関係者に限定されていることに注意しなければならない。説明した相手を、相,,,,, ,手の責任者やシステムを利用する部門の担当者などにしてはいけない。問題文には、ソフトウェア開発リーダとITサ,,,,, ,ービスマネージャが例として取り上げられている。ITサービスマネージャは、システムの開発に直接携わることが少,,,,, ,ないが、システムの運用のとりまとめ責任者ということで、システム開発関係者に含めていると考えられる。理解して,,,,, ,もらう項目については、取り上げるシステム開発関係者が、設計内容について知っておくべき項目と考えると分かり,,,,, ,やすい。設計内容を説明する対象者、理解を促す項目、説明の観点とも問題文に詳細な例が示されており、記述す,,,,, ,る範囲や記述内容などの参考にしてほしい。,,,,, ,,,,,, ,　設問ウでは、「プレゼンテーションにおける工夫点」、「プレゼンテーションの内容についての改善点」を記述する。プ,,,,, ,レゼンテーションにおける工夫点については、「限られた時間内で効率よく理解してもらうため」ということを意識する,,,,, ,必要がある。単に、「見やすいプレゼンテーション資料を作成した」とか、「図を多用し、文字を少なくした」などという,,,,, ,工夫点では不十分である。工夫したことによって、プレゼンテーションの聴衆者の理解が効率よく進んだことに言及,,,,, ,する必要がある。問題文には、全体の説明から各論の説明へ展開する場合の工夫点の例が示されている。プレゼ,,,,, ,ンテーションの内容についての改善点については、参考にできる記述がない。システム開発責任者に対して行った,,,,, ,プレゼンテーションの内容に応じて、一般的に考えられる改善点を記述すればよい。ここでの要求事項は「内容につ,,,,, ,いての改善点」であるため、プレゼンテーションの方法や、話し方などの改善点に終始しないように注意しよう。,,,,, ,,,,,, ■見出しとストーリー,,,,,, ,,,,,, ,■設問ア,,,,, ,,,,,, ,,　設問アには、問題文の次の部分が対応する。,,,, ,,,,,, ,,設問ア,,,あなたが設計に携わったシステムとその対象業務、及びあなたが責任を持って説明した設計の概要に, ,,,,,ついて、800字以内で述べよ。, ,,,,,, ,,　システムアーキテクトには、システム開発関係者に十分な情報を提供し、設計した内容が適切であることを説明,,,, ,,する責任がある。,,,, ,,,,,, ,,　例として次のような見出しとストーリーが考えられる。,,,, ,,,,,, ,,,ア　設計に携わったシステムと対象業務、責任を持って説明した設計の概要,,, ,,,ア―１　設計に携わったシステムと対象業務,,, ,,,,,, ,,,,・,小売業A社の販売管理システム, ,,,,・,A社は東京都中央区に本社を置く, ,,,,・,関東一円に小型スーパーを展開, ,,,,・,店舗は約200店, ,,,,・,販売管理システムは、店舗のPOS端末と本社のサーバから構成されている, ,,,,・,店頭での商品販売に必須となるシステム, ,,,,・,主要なデータは商品マスタと売上データ, ,,,,・,売上データは本社サーバにオンラインで転送, ,,,,・,商品マスタは膨大な情報となるためPOSに保持されており、販売の都度本社サーバを参照しない設計, ,,,,・,単価の変更や値引きの情報は1日1回更新され、差分が本社からPOS端末に開店前に転送される, ,,,,・,店舗の営業時間は午前10時から午後10時, ,,,,,, ,,,ア―２　責任を持って説明した設計の概要,,, ,,,,,, ,,,,・,A社にとって販売業務がミッションクリティカル, ,,,,・,販売管理システムの信頼性が重要になるため、ハードウェア及びソフトウェアの信頼性向上がポイント, ,,,,・,信頼性向上の手段として冗長性の確保と本社―店舗間の接続が切断した場合の対応策などを強化し, ,,,,,た, ,,,,・,自身の立場は、独立系のシステムインテグレータP社に所属するシステムアーキテクト, ,,,,,, ,■設問イ,,,,, ,,,,,, ,,　設問イには、問題文の次の部分が対応する。,,,, ,,,,,, ,,,設問イ,,,設問アで述べた設計の内容を、誰に、どのような項目を理解してもらうために、どのような観点から ,,,,,,説明したか。800字以上1600字以内で具体的に述べよ。 ,,,,,, ,,,　そのためには、説明する相手に応じて、理解してほしい項目とその説明の観点を明確にしなければならない,,, ,,,。,,, ,,,　例えば、ソフトウェア開発リーダにソフトウェア方式を説明する場合には、ソフトウェア要件定義書に基づき、,,, ,,,ソフトウェアの最上位レベルの構成及びコンポーネントが果たすべき機能が業務要件と整合していることを理,,, ,,,解してもらう。その際、次のような観点から説明する。,,, ,,,,・,対象業務の機能要件及び非機能要件と、コンポーネント分割の方針との整合性, ,,,,・,コンポーネント分割の方針に従って設計したソフトウェア構造、そのソフトウェア構造の業務変化への対, ,,,,,応容易性などの評価項目と評価結果, ,,,　また、ITサービスマネージャに障害時の対応処理方式を説明する場合には、ITサービス要件で定めた目標,,, ,,,に基づき、設計したハードウェア構成及びソフトウェア方式によって目標を達成できることを理解してもらう。,,, ,,,その際、次のような観点から説明する。,,, ,,,,・,障害への対応方針と、その方針に従った障害対応処理の設計内容, ,,,,・,設計した障害対応手順などがITサービス要件を満たしていると判断した根拠, ,,,,,, ,,　例として次のような見出しとストーリーが考えられる。,,,, ,,,,,, ,,,イ　設計内容を説明したシステム開発関係者、理解を促した項目、説明の観点,,, ,,,イ―１　設計内容を説明したシステム開発関係者,,, ,,,,・,A社の情報システムを取りまとめる情報システム部に所属するITサービスマネージャのB氏, ,,,,・,B氏は情報システムによって提供されるサービスについて、社内の利用部門との間でSLAを締結, ,,,,・,販売管理システムには厳しい目標が設定されており、B氏は設計内容を重視している, ,,,,,, ,,,イ―２　理解を促した項目,,, ,,,,・,設計したハードウェア構成, ,,,,,・,基本的にハードウェアを多重化 ,,,,,・,回線も多重化、回線は自動切り替え ,,,,・,設計したソフトウェア方式, ,,,,,・,サーバを仮想化し、負荷の大きさなどに応じてリソースを動的に配分することで不用意なシステムダ ,,,,,,ウンを防止 ,,,,,・,POSは組込みシステムであり、ソフトウェア方式の考慮外 ,,,,,, ,,,イ―３　説明の観点,,, ,,,,,, ,,,,・,ITサービス要件の達成について, ,,,,,・,年間に認められている停止時間は8時間以内 ,,,,,・,サーバは信頼性99.9％のハードウェアを二重化 ,,,,,・,回線は信頼性99．9％の回線を2本契約 ,,,,,・,POS端末は信頼性99％で、各店舗に最低3台導入されるため、三重化となる ,,,,,・,各構成要素の信頼性はシックスナインとなり、年間の停止時間は8時間を大幅に下回る ,,,,・,障害時の対応方法について, ,,,,,・,信頼性は十分確保できているが、回線が切断した場合、単価の変更や値引き情報が本社から伝わ ,,,,,,らなくなるため、業務が停止してしまう ,,,,,・,店舗単独で業務が継続できるよう、単価の変更や値引き情報の伝送方法を検討 ,,,,,・,データ量は少ないため、メールもしくは社用として支給されているスマートフォン経由で本社から伝送 ,,,,,,する ,,,,,・,伝送時間は最大でも20分程度で、店舗要員の出社時刻は午前9時であり、障害発生時には、メール ,,,,,,もしくはスマートフォン経由で情報を入手すれば、開店時刻の午前10時までに、各店舗ともオフライン ,,,,,,でPOSに反映できる ,,,,,, ,■設問ウ,,,,, ,,,,,, ,,　設問ウには、問題文の次の部分が対応する。,,,, ,,,,,, ,,,設問ウ,,,設問イで述べた説明を限られた時間内で効率よく理解してもらえるように、どのようにプレゼンテーシ ,,,,,,ョンを工夫したか。また、その結果から、プレゼンテーションの内容について改善すべきと考えた点に ,,,,,,ついて、600字以上1200字以内で具体的に述べよ。 ,,,,,, ,,,　さらに、限られた時間内で効率よく理解してもらえるように、構成を含めたプレゼンテーションを工夫すること,,, ,,,も重要である。例えば、全体を説明したうえで各論を説明するために、全体を俯瞰できる資料及び個別の論点,,, ,,,と結論を明確にした資料を用意する。,,, ,,,,,, ,,　例として次のような見出しとストーリーが考えられる。,,,, ,,,,,, ,,,ウ　プレゼンテーションにおける工夫点とプレゼンテーション内容の改善点,,, ,,,ウ―１　プレゼンテーションにおける工夫点,,, ,,,,・,特に障害時の対応方法が新しくなるため、説明の中心とする, ,,,,・,システム全体を俯瞰する図を用いて、信頼性向上の多重化などについて詳細に説明, ,,,,・,回線に障害が発生しても、回線は自動切り替えであるため、運用管理者が気づかない可能性がある, ,,,,・,自動切り替え後の監視端末の画面イメージを説明, ,,,,・,回線切断時の運用手順について、画面や写真を用いた説明資料にすると同時に、動画を用い具体的, ,,,,,な操作が見えるようにする, ,,,,・,単価の変更や値引き情報のPOSへの導入はPOSの基本機能で行えるため、POSに付属する標準手順, ,,,,,書にて説明, ,,,,,, ,,,ウ―２　プレゼンテーション内容の改善点,,, ,,,,・,障害時の対応を中心に説明し、障害時の対応の重要性は理解頂けた, ,,,,・,ITサービスマネージャのB氏からは、障害は頻繁に発生するものではなく、それよりも日々行わなけれ, ,,,,,ばならない正常運用について説明が簡便で分かりにくいという指摘, ,,,,・,運用担当者にとっては、安定稼働を維持することが責務, ,,,,・,通常運用についてケアレスミスが生じたり、担当者の属人性に依存したりすることがないように、プレゼ, ,,,,,ンテーション内容を改善する必要がある, ,,,,,, ■解答,,,,,, ,,,,,, ,■設問ア,,,,, ,,,,,, ,,ア　設計に携わったシステムと対象業務、責任を持って説明した設計の概要,,,, ,,ア―１　設計に携わったシステムと対象業務,,,, ,,,,,, ,,,　私は、独立系のシステムインテグレータP社に所属するシステムアーキテクトである。今回、私は、小売業A,,, ,,,社の販売管理システムについて責任を持って設計内容を説明した。A社は東京都中央区に本社を置き、関東,,, ,,,一円に小型スーパーを展開している。店舗は約200店である。販売管理システムは、店舗のPOS端末と本社,,, ,,,のサーバから構成されており、店頭での商品販売に必須となるシステムである。販売管理システムを使用して,,, ,,,、商品の売り上げ登録が簡単に行えるようになっている。販売管理業務において取り扱う主要なデータは商品,,, ,,,マスタと売上データとなっている。売上データは本社サーバにオンラインで転送する。商品マスタは膨大な情,,, ,,,報となるためPOSに保持されており、販売の都度本社サーバを参照する必要はない。単価の変更や値引き情,,, ,,,報は1日1回更新され、差分が本社からPOS端末に開店前に転送される。店舗は年中無休で、営業時間は午,,, ,,,前10時から午後10時となっている。,,, ,,,,,, ,,ア―２　責任を持って説明した設計の概要,,,, ,,,,,, ,,,　A社にとって販売業務がミッションクリティカルであり、販売管理システムの信頼性が重要になるため、ハード,,, ,,,ウェア及びソフトウェアの信頼性向上がポイントとなる。私は、信頼性向上の手段として、本社サーバ、POS端,,, ,,,末、通信ネットワークについて冗長性を確保した。特に、本社―店舗間の接続が切断した場合であっても、業,,, ,,,務が中断することのないよう、対応策を強化することとした。,,, ,,,,,, ,■設問イ,,,,, ,,,,,, ,,イ　設計内容を説明したシステム開発関係者、理解を促した項目、説明の観点,,,, ,,イ―１　設計内容を説明したシステム開発関係者,,,, ,,,,,, ,,,　今回、私が設計内容を説明したシステム開発関係者は、A社の情報システムを取りまとめる情報システム部,,, ,,,に所属するITサービスマネージャのB氏である。B氏が管掌する情報システム部は、情報システムによって提,,, ,,,供されるサービスについて、社内の利用部門との間でSLAを締結している。販売管理システムには厳しい目標,,, ,,,が設定されており、B氏は信頼性について設計内容を重視している。,,, ,,,,,, ,,イ―２　理解を促した項目,,,, ,,,,,, ,,,　B氏に理解を促した設計項目は、設計したハードウェア構成とソフトウェア方式である。,,, ,,,,,, ,,,（１）ハードウェア構成,,, ,,,,,, ,,,,　基本的にハードウェアを多重化することで信頼性を向上させる。回線も多重化すると同時に、電気通信事,, ,,,,業者の付加サービスを導入し、回線は自動切り替え方式とした。,, ,,,,,, ,,,（２）ソフトウェア方式,,, ,,,,,, ,,,,　私は、サーバについて、ハードウェアを多重化することに加え、仮想化サーバを導入することとした。仮想,, ,,,,化サーバであれば、負荷の大きさに応じてリソースを動的に配分することが可能であり、不用意なシステム,, ,,,,ダウンを防止することができる。POSについては組込み製品であり、ソフトウェア方式の考慮外とした。,, ,,,,,, ,,イ―３　説明の観点,,,, ,,,,,, ,,,（１）ITサービス要件の達成について,,, ,,,,,, ,,,,　年間に認められている停止時間は8時間以内である。営業時間の1日12時間換算で年間の稼働率は99.8,, ,,,,％を確保しなければならない。サーバは信頼性99.9％のハードウェアを二重化、回線は信頼性99.9％の回,, ,,,,線を2本契約（二重化）、POS端末は信頼性99％で、各店舗に最低3台導入されるため、三重化となる。各,, ,,,,構成要素の信頼性はシックスナイン（99.9999％）で、サーバ、POS、回線3要素を合わせた信頼性は99.999,, ,,,,％以上となり、年間の停止時間は8時間を大幅に下回る設計である。,, ,,,,,, ,,,（２）障害時の対応方法について,,, ,,,,,, ,,,,　信頼性は十分確保できているが、回線が切断した場合、単価の変更や値引き情報が本社から伝わらな,, ,,,,くなるため、業務が停止してしまうことになる。私は、店舗単独で業務が継続できるよう、単価の変更や値,, ,,,,引き情報の伝送方法を検討した。単価の変更や値引き情報については、データ量が少ないため、メール,, ,,,,もしくは社用として支給されているスマートフォン経由で本社から伝送することとした。データ量と通信速度,, ,,,,を鑑みると、伝送時間は最大でも20分程度である。店舗要員の出社時刻は午前9時であり、障害発生時,, ,,,,には、メールもしくはスマートフォン経由で情報を入手すれば、開店時刻の午前10時までに、各店舗とも,, ,,,,オフラインでPOSに反映できると考えられる。,, ,,,,,, ,■設問ウ,,,,, ,,,,,, ,,ウ　プレゼンテーションにおける工夫点とプレゼンテーション内容の改善点,,,, ,,ウ―１　プレゼンテーションにおける工夫点,,,, ,,,,,, ,,,　新しい販売管理システムでは、特に障害時の対応方法が新しくなるため、私は障害時の対応方法を説明の,,, ,,,中心とすることとした。具体的には、システム全体を俯瞰する図を活用し、信頼性向上の多重化などについて,,, ,,,、具体的に計算式や数値を用いて詳細に説明した。回線に障害が発生しても、回線は自動切り替えであるた,,, ,,,め、運用管理者が気づかない可能性がある。私は、自動切り替え後の監視端末の画面イメージを中心に説明,,, ,,,をした。回線切り替え時の運用手順については、画面や写真を用いた説明資料にすると同時に、メールやス,,, ,,,マートフォンを使用して対応することになるため、動画を用い具体的な操作が見えるようなプレゼンテーション,,, ,,,を行った。単価の変更や値引き情報のPOSへの導入はPOSの基本機能で行えるため、POSに付属する標準,,, ,,,手順書にて説明することとした。,,, ,,,,,, ,,ウ―２　プレゼンテーション内容の改善点,,,, ,,,,,, ,,,　私がプレゼンテーションを行った障害時の対応中心の説明について、障害時の対応の重要性は理解頂けた,,, ,,,。ただし、ITサービスマネージャのB氏からは、障害は頻繁に発生するものではなく、障害時の対応よりも日々,,, ,,,行わなければならない正常運用について説明が簡便で分かりにくいという指摘をいただいた。運用担当者に,,, ,,,とっては、安定稼働を維持することが責務であり、通常運用についてケアレスミスが生じたり、担当者の属人,,, ,,,性に依存したりすることがないように、継続的にプレゼンテーション内容を改善していく所存である。　以上,,, ,,,,,, 平成26年　問１　業務プロセスの見直しにおける情報システムの活用について,,,,,, ,,,,,, ,　業務プロセスの見直しでは、情報システムを活用することが多い。業務プロセスの見直しを行う際は、業務上の,,,,, ,問題とその原因を明らかにする必要がある。例えば、次のようなものがある。,,,,, ,,・,特定の業務プロセスに時間がかかっていることが原因で全体の時間が延びている。,,, ,,・,顧客への対応手順が支店ごとに異なることが原因でクレームが発生している。,,, ,,・,判断のミスが多いことが原因で発注のロスが発生している。,,, ,　システムアーキテクトは、原因を取り除くために情報システムの活用を検討する。情報システムの活用には、例,,,,, ,えば次のようなものがある。,,,,, ,,・,特定の業務プロセスに時間がかかっていることが原因の場合、原因になっている業務プロセスを情報シス,,, ,,,テムで自動化し、時間短縮を図る。,,, ,,・,顧客への対応手順が支店ごとに異なることが原因の場合、業務プロセスの標準に基づいた情報システム,,, ,,,機能を開発し、必ず対応手順が同じになるようにする。,,, ,,・,判断のミスが多いことが原因の場合、ルール化した判断方法を情報システムに組み込み、人間による判,,, ,,,断を排除する。,,, ,　また、このような情報システムの活用では、例外的な状況でも業務プロセスが実行できるように、次のような対,,,,, ,応を検討しておくことも重要である。,,,,, ,,・,まれに発生する例外データへの対応方法の用意,,, ,,・,情報システムで判断できない場合の人間への判断材料の提示,,, ,,,,,, ,設問ア,,,あなたが携わった業務プロセスの見直しについて、見直しの対象となった業務プロセス、及び関連する情,, ,,,,報システムの概要を含めて、800字以内で述べよ。,, ,設問イ,,,設問アで述べた業務プロセスの見直しは、どのような業務上の問題とその原因に対応するためのものであ,, ,,,,ったか。また、原因を取り除くためにどのように情報システムを活用したか。800字以上1600字以内で具体,, ,,,,的に述べよ。,, ,設問ウ,,,設問イで述べた情報システムの活用で、例外的な状況でも業務プロセスが実行できるように、想定して検,, ,,,,討した、起こり得る状況とその対応を、600字以上1200字以内で具体的に述べよ。,, ,,,,,, ■解説,,,,,, ,,,,,, ,■出題趣旨,,,,, ,,,,,, ,,　業務プロセスの見直しでは、情報システムを活用することが多い。このような見直しでは、業務プロセスの問題,,,, ,,とその原因を分析し、システムアーキテクトが問題とその原因を解消するための情報システムの活用方法を検討,,,, ,,する。,,,, ,,　本問は、業務プロセスの見直しにおける情報システムの活用について、業務プロセスの問題とその原因、原因,,,, ,,を取り除くための情報システムの活用方法、例外的な状況でも業務プロセスが実行できるように想定した状況と,,,, ,,対応を具体的に論述することを求めている。論述を通じて、システムアーキテクトに必要な情報システムの活用,,,, ,,方法を検討する能力、経験などを評価する。,,,, ,,,,,, ,■採点講評,,,,, ,,,,,, ,,　全問に共通して、設問に素直に答えている論述が多かった。また、問題文の引用で文字数を費やし、内容が薄,,,, ,,くなってしまっている論述も少なかった。一方で、問題文に記載してある観点などを抜き出し、一般論と組み合わ,,,, ,,せただけの論述は引き続き散見された。問題文に記載した観点は例示である。自らが実際にシステムアーキテク,,,, ,,トとして、検討し取り組んだことを具体的に論述してほしい。,,,, ,,,,,, ,,　問１（業務プロセスの見直しにおける情報システムの活用について）では、業務プロセスの問題とその原因を明,,,, ,,らかにしたうえで、情報システムをどのように活用したかという具体的な論述を期待した。多くの回答が、業務プロ,,,, ,,セスの問題を解消するための情報システムの活用を論述していた。一方で、問題の原因追及が不足している論,,,, ,,述や、業務プロセスの問題ではなく情報システムの問題を主題にした論述も散見された。システムアーキテクトに,,,, ,,は、業務プロセスと情報システムの両面から対象業務システムを分析することが求められる。そのため、情報シ,,,, ,,ステムだけでなく、業務プロセスの面からの分析能力を高めていってほしい。,,,, ,,,,,, ,■解説,,,,, ,,,,,, ,,　業務プロセスの見直しにおける情報システムの活用がテーマの問題である。,,,, ,,　業務プロセスの見直しを行う際は、時間を要する業務プロセス、対応手順の混乱、手作業によるミスの多発など,,,, ,,、最初に業務上の問題とその原因を明らかにする。システムアーキテクトは、効率よく業務プロセスを見直すこと,,,, ,,ができるよう、原因を取り除くために情報システムの活用を検討する。情報システムの活用において、例外的な,,,, ,,状況であっても、業務プロセスが中断しないようにするための対策を検討しておくことも重要である。,,,, ,,,,,, ,,　設問アでは、「見直しの対象となった業務プロセス」、「関連する情報システムの概要」を記述する。「関連する情,,,, ,,報システムの概要」は、システムアーキテクト試験における定番の要求事項であり、特定の事項についての記述,,,, ,,は要求されていないため、受験者の経験に基づいて記述すれば十分である。「見直しの対象となった業務プロセ,,,, ,,ス」についても、業務プロセスを特定するような問題文の記述はないため、どのような業務プロセスを取り上げて,,,, ,,もよい。記述しやすい設問アであったと考えられる。,,,, ,,,,,, ,,　設問イでは、「業務上の問題とその原因」、「原因を取り除くために活用した情報システム」を記述する。「業務上,,,, ,,の問題とその原因」について問題文に三つの例が示されている。具体的には、「特定の業務プロセスに時間がか,,,, ,,かっていることが原因で全体の時間が延びている」、「顧客への対応手順が支店ごとに異なることが原因でクレー,,,, ,,ムが発生している」、「判断のミスが多いことが原因で発注のロスが発生している」である。平易な例であり受験者,,,, ,,にとって分かりやすかったと考えられる。「原因を取り除くために活用した情報システム」については、問題を発生,,,, ,,させている原因を解消できるような情報システムの活用方法を示せばよい。特定の業務プロセスを情報システム,,,, ,,で効率化したり、自動化したりすることによる時間短縮、業務プロセスの標準化を支援するような情報システムの,,,, ,,開発、判断ルールを情報システムで実現して判断業務の処理を排除などが活用法の例である。設問の要求事項,,,, ,,が「業務上の問題とその原因」、「原因を取り除くために活用した情報システム」の二つであるため、相応に詳細,,,, ,,に記述しなければ、800字以上を満たせなくなる可能性がある。記述量を確保できるよう、ストーリー作成の段階,,,, ,,で記述項目をよく吟味しておく必要がある。,,,, ,,,,,, ,,　設問ウでは、「想定される例外的な状況」、「例外への対応」を記述する。問題文に「まれに発生する例外データ,,,, ,,への対応方法の用意」、「情報システムで判断できない場合の人間への判断材料の提示」という例が示されてい,,,, ,,るので、参考にしたい。通常、情報システムの設計においては、正常処理に加え例外処理についても設計するた,,,, ,,め、例外が発生した場合でも情報システムでハンドリングすることが多い。しかし、この問題では情報システムで,,,, ,,処理できないような場合が想定されている。例外的な状況について、記述上の特段の制約はなく、どのような状,,,, ,,況でも構わない。活用した情報システムが稼働しなかったり、事故によって停止してしまったりということを想定す,,,, ,,ればよい。設問ウは600字以上記述しなければならないため、「想定される例外的な状況」は何点か列挙してもよ,,,, ,,いと考えられる。設問イで記述した情報システムの活用における例外的な状況の記述が要求されているため、設,,,, ,,問イの記述と関連させた記述になるように注意しなければならない。,,,, ,,,,,, ■解答例,,,,,, ,,,,,, ,,ア　見直しの対象となった業務プロセスと関連する情報システムの概要,,,, ,,ア―１　見直しの対象となった業務プロセス,,,, ,,,,,, ,,,　私は、今回の業務プロセスの見直しにおける情報システムの活用について、システム構築などを含め一括,,, ,,,で受注したシステムインテグレータP社に所属するシステムアーキテクトである。業務プロセスを見直すことに,,, ,,,なった対象の顧客は電子部品を販売するA社である。A社には、東京、大阪、名古屋など販売拠点が国内に,,, ,,,複数あり幹部の方針で社員が多くの顧客に接することができるよう、営業拠点間の人員移動が頻繁に行われ,,, ,,,ている。見直しの対象となった業務プロセスは、A社の資産管理業務である。資産管理業務は、社内に存在す,,, ,,,るあらゆる資産を管理する業務で、新たな資産の登録や期に一度の棚卸などを行っている。,,, ,,,,,, ,,ア―２　関連する情報システムの概要,,,, ,,,,,, ,,,　A社の資産管理を支援する情報システムは、資産管理システムである。資産管理システムを維持・運用して,,, ,,,いるのは情報システム部門である。資産管理システムはWebアプリケーションとして構築されており、主たる利,,, ,,,用者は情報システム部門の担当者で、日常業務で常時使用されている。資産管理システムには、資産の登,,, ,,,録、移動、滅却などを記録する機能があり、データベースによって情報は一元管理されている。資産管理シス,,, ,,,テムは稼働後5年経過しているが、大きなトラブルもなく順調に稼働している。,,, ,,,　今回の情報システムの活用について、私が全体を取りまとめることとなった。,,, ,,,,,, ,,イ　業務上の問題とその原因、及び原因を取り除くために活用した情報システム,,,, ,,イ―１　業務上の問題とその原因,,,, ,,,,,, ,,,　業務プロセスを見直す契機となった業務上の問題は資産管理システムで管理している資産の情報と、実際,,, ,,,に存在している現物の資産が、毎回の棚卸で相当数不一致になっていることである。これまでA社では、棚卸,,, ,,,のたびに発生する現物と情報の不一致を、人手によって解消してきた。しかし、次の棚卸においても、また新,,, ,,,たな不一致が再発している状況となっている。,,, ,,,　資産管理システムの管理対象となっているA社の資産は大きく2種類ある。一つは複合機や大型スクリーン,,, ,,,のように物理的な移動が少なく、据え付けや調整にも専門の業者が必要になる資産であり、もう一つは執務,,, ,,,席に配置されているPCや業務用の携帯電話など基本的に個人が占有して使用する資産である。個人が使用,,, ,,,する資産は、個人に紐づいた管理になっており、人事異動などに伴い個人とともに異動先の資産として移され,,, ,,,ることになっている。現在は、資産移動に伴い、資産の管理者が表計算ソフトによって、上長経由で情報シス,,, ,,,テム部門へ移動の申請を行う運用である。情報システム部門が、過去の不一致の事例調査や、現場への聞,,, ,,,き込み調査などを行い、不一致が生じる主な原因は、申請を忘れたり、上長が承認を忘れたり、誤って申請し,,, ,,,たりするなどによることが判明した。,,, ,,,,,, ,,イ―２　原因を取り除くために活用した情報システム,,,, ,,,,,, ,,,　A社では、人事異動や通勤経路の申請などについて、以前よりワークフローシステムが利用されている。ワ,,, ,,,ークフローシステムでは、手続きの流れが事前に登録でき、上長承認機能や、承認者に対して申請があった,,, ,,,旨を伝えるフォローメール送信機能を持っている。資産情報の不一致が生じる主な要因が人事異動に伴うも,,, ,,,のであるため、私は、既存の情報システムを活用し、人事異動のワークフロー申請のデータから資産移動の,,, ,,,データを作成して、資産管理システムの入力データとすることとした。資産移動のデータを自動作成することに,,, ,,,よって、申請忘れや承認忘れを防止でき、現物と情報の不一致の件数は９０％削減できることが見込まれて,,, ,,,いる。,,, ,,,,,, ,,ウ　想定される例外的な状況と例外への対応,,,, ,,ウ―１　想定される例外的な状況,,,, ,,,,,, ,,,　個人が占有して使用する資産は、基本的に個人に紐づいている。ただし、営業職からスタッフ職への異動の,,, ,,,ように職種が変更になる場合や対象の資産が特定の業務専用の資産であって後任の社員が使用する場合な,,, ,,,ど、まれに資産移動を伴わないこともある。,,, ,,,　資産移動を伴わない人事異動の場合、人事異動の情報を基に資産移動を行うと、新たに現物と情報の不一,,, ,,,致を生じさせることになる。異動全体から見れば資産移動を伴わない異動は少数であるが、今後ともゼロには,,, ,,,ならないことが明確になっているため、何らかの対応が必要であった。,,, ,,,,,, ,,ウ―２　例外への対応,,,, ,,,,,, ,,,　私は、資産移動を伴わない人事異動への対応方法として次の２つの案を検討した。,,, ,,,　一つは、本人がワークフローシステムを利用して資産移動が伴わないことの例外申請を行い、人事異動デ,,, ,,,ータを基にした資産移動を回避する方法である。もう一つは移動元の上長が一括で資産移動の停止情報を作,,, ,,,成し、情報システム部門に提出する方法である。どちらの方法においても、本人の申請忘れや上長からの情,,, ,,,報の提出忘れというリスクは残る。各人別に行う本人からの申請件数の方が、一括で行う上長からの情報の,,, ,,,提出件数よりも多くなることから、今回は、異動元の上長が資産移動の停止情報を作成し、情報システム部門,,, ,,,に提出する方法を採用することにした。,,, ,,,　私は、人事異動の際の手続きに関する一連のチェックリストに資産移動に関する項目を追加することで、異,,, ,,,動元上長の提出忘れを極力少なくする工夫をした。加えて人事異動が発生したときに、ワークフローシステム,,, ,,,のフォロー機能を利用して、該当する上長あてに資産移動の停止情報を提出する旨のフォローメールを送信,,, ,,,することとした。　以上,,, ,,,,,, 平成26年　問１　業務プロセスの見直しにおける情報システムの活用について,,,,,, ,,,,,, ６．３　論文作成例,,,,,, ,,,,,, ,　ここでは、平成26年度秋期の午後Ⅱ問１を題材に、6.1の解説に沿ってストーリーと、サンプル論文を作成する。,,,,, ,,,,,, ,問　業務プロセスの見直しにおける情報システムの活用について,,,,, ,,,,,, ,,　業務プロセスの見直しでは、情報システムを活用することが多い。業務プロセスの見直しを行う際は、業務上の,,,, ,,問題とその原因を明らかにする必要がある。例えば、次のようなものがある。,,,, ,,,・,特定の業務プロセスに時間がかかっていることが原因で全体の時間が延びている。,, ,,,・,顧客への対応手順が支店ごとに異なることが原因でクレームが発生している。,, ,,,・,判断のミスが多いことが原因で発注のロスが発生している。,, ,,　システムアーキテクトは、原因を取り除くために情報システムの活用を検討する。情報システムの活用には、例,,,, ,,えば次のようなものがある。,,,, ,,,・,特定の業務プロセスに時間がかかっていることが原因の場合、原因になっている業務プロセスを情報シス,, ,,,,テムで自動化し、時間短縮を図る。,, ,,,・,顧客への対応手順が支店ごとに異なることが原因の場合、業務プロセスの標準に基づいた情報システム,, ,,,,機能を開発し、必ず対応手順が同じになるようにする。,, ,,,・,判断のミスが多いことが原因の場合、ルール化した判断方法を情報システムに組み込み、人間による判,, ,,,,断を排除する。,, ,,　また、このような情報システムの活用では、例外的な状況でも業務プロセスが実行できるように、次のような対,,,, ,,応を検討しておくことも重要である。,,,, ,,,・,まれに発生する例外データへの対応方法の用意,, ,,,・,情報システムで判断できない場合の人間への判断材料の提示,, ,,　あなたの経験と考えに基づいて、設問ア～ウに従って論述せよ。,,,, ,,,,,, ,設問ア,,,あなたが携わった業務プロセスの見直しについて、見直しの対象となった業務プロセス、及び関連する情,, ,,,,報システムの概要を含めて、800字以内で述べよ。,, ,設問イ,,,設問アで述べた業務プロセスの見直しは、どのような業務上の問題とその原因に対応するためのものであ,, ,,,,ったか。また、原因を取り除くためにどのように情報システムを活用したか。800字以上1600字以内で具体,, ,,,,的に述べよ。,, ,設問ウ,,,設問イで述べた情報システムの活用で、例外的な状況でも業務プロセスが実行できるように、想定して検,, ,,,,討した、起こり得る状況とその対応を、600字以上1200字以内で具体的に述べよ。,, ,,,,,, ６．３．１　設問アの論文作成例,,,,,, ,,,,,, ,●設問,,,,, ,,,,,, ,,設問ア,,,あなたが携わった業務プロセスの見直しについて、見直しの対象となった業務プロセス、及び関連する, ,,,,,情報システムの概要を含めて、800字以内で述べよ。, ,,,,,, ,●設問アに対応する問題文,,,,, ,,,,,, ,,設問アには、対応する問題文がなく、自分の経験に基づき要求事項を記述する。,,,, ,,,,,, ,●ストーリー作成のポイント（見出しの検討）,,,,, ,,,,,, ,,　設問アで指示されている要求事項は、,,,, ,,,,,, ,,,・,見直しの対象となった業務プロセス,, ,,,・,関連する情報システムの概要,, ,,,,,, ,,となっている。問題文には見直し対象となった業務プロセスを特徴づける記述がなく、受験者が携わった業務プロ,,,, ,,セスの見直しや情報システムの活用であれば、どのような案件であっても題材の候補となる。問題文に示されて,,,, ,,いる3点の業務上の問題を参考に、取り上げる業務プロセスを検討できる。特定の業務に依存する問題ではない,,,, ,,ため、取り組みやすい問題であったと考えられる。,,,, ,,　本章で紹介しているストーリー作成例は、書籍としての説明上かなり詳細な文章にしている。筆者が推奨する「,,,, ,,問題作成とストーリー作成」のための時間配分25分では、本章で紹介しているようなストーリーを問題冊子の余,,,, ,,白などに書きだすことは困難であると考えられる。本試験においては、受験者が論文の記述の際に分かるストー,,,, ,,リーであればよく、キーワードの列挙、短い箇条書き程度のストーリー作成で十分である。,,,, ,,,,,, ,●ストーリー,,,,, ,,,,,, ,,ア　見直しの対象となった業務プロセスと関連する情報システムの概要,,,, ,,ア―１　見直しの対象となった業務プロセス,,,, ,,,・,対象となる顧客は電子部品を販売するA社,, ,,,・,A社には、東京、大阪、名古屋など販売拠点が国内に複数あり、幹部の方針で社員が多くの顧客に接する,, ,,,,ことができるよう、営業拠点間の人員移動が頻繁に行われる,, ,,,・,見直しの対象となった業務プロセスは、A社の資産管理業務,, ,,,・,資産管理業務は、社内に存在するあらゆる資産を管理する業務で、新たな資産の登録や期に一度の棚卸,, ,,,,などを行っている,, ,,,・,自身の立場は、今回の業務プロセスの見直しにおける情報システムの活用について、システム構築などを,, ,,,,含め一括で受注したシステムインテグレータP社に所属するシステムアーキテクト,, ,,,,,, ,,ア―２　関連する情報システムの概要,,,, ,,,・,A社の資産管理は、資産管理システムによって行われている,, ,,,・,資産管理システムを運用しているのは情報システム部門,, ,,,・,資産管理システムはWebアプリケーションとして構築されており、情報システム部門の担当者が日常業務,, ,,,,で常時利用している,, ,,,・,資産管理システムには、資産の登録、移動、滅却などを記録する機能があり、データベースによって情報,, ,,,,は一元管理されている,, ,,,・,資産管理システムは稼働後5年経過しているが、大きなトラブルもなく順調に稼働している,, ,,,・,今回の情報システムの活用について、私が全体を取りまとめることとなった。,, ,,,,,, ,●ストーリーから論文を作成するポイント,,,,, ,,,,,, ,,　設問アの要求事項は、「見直しの対象となった業務プロセス」、「関連する情報システムの概要」の2点である。,,,, ,,問題の中核が業務プロセスになっており、設問イの要求事項の一つに「業務上の問題とその原因」が挙げられて,,,, ,,いることを踏まえると、業務プロセスの記述をある程度詳しくする必要があると考えられる。情報システムについ,,,, ,,ては、情報システムを活用した問題の解決であるため、処理内容を中心に簡単に触れる程度で要求事項を満た,,,, ,,せばよい。,,,, ,,,,,, ,●解答例　設問ア,,,,, ,,,,,, ,,ア　見直しの対象となった業務プロセスと関連する情報システムの概要,,,, ,,ア―１　見直しの対象となった業務プロセス,,,, ,,,,,, ,,,　私は、今回の業務プロセスの見直しにおける情報システムの活用について、システム構築などを含め一括,,, ,,,で受注したシステムインテグレータP社に所属するシステムアーキテクトである。業務プロセスを見直すことに,,, ,,,なった対象の顧客は電子部品を販売するA社である。A社には、東京、大阪、名古屋など販売拠点が国内に,,, ,,,複数あり幹部の方針で社員が多くの顧客に接することができるよう、営業拠点間の人員移動が頻繁に行われ,,, ,,,ている。見直しの対象となった業務プロセスは、A社の資産管理業務である。資産管理業務は、社内に存在す,,, ,,,るあらゆる資産を管理する業務で、新たな資産の登録や期に一度の棚卸などを行っている。,,, ,,,,,, ,,ア―２　関連する情報システムの概要,,,, ,,,,,, ,,,　A社の資産管理を支援する情報システムは、資産管理システムである。資産管理システムを維持・運用して,,, ,,,いるのは情報システム部門である。資産管理システムはWebアプリケーションとして構築されており、主たる利,,, ,,,用者は情報システム部門の担当者で、日常業務で常時使用されている。資産管理システムには、資産の登,,, ,,,録、移動、滅却などを記録する機能があり、データベースによって情報は一元管理されている。資産管理シス,,, ,,,テムは稼働後5年経過しているが、大きなトラブルもなく順調に稼働している。,,, ,,,　今回の情報システムの活用について、私が全体を取りまとめることとなった。,,, ,,,,,, ６．３．２　設問イの論文作成例,,,,,, ,,,,,, ,●設問,,,,, ,,,,,, ,,設問イ,,,設問アで述べた業務プロセスの見直しは、どのような業務上の問題とその原因に対応するものであった, ,,,,,か。また、原因を取り除くためにどのように情報システムを活用したか。800字以上1600字以内で具体的, ,,,,,に述べよ。, ,,,,,, ,●設問イに対応する問題文,,,,, ,,,,,, ,,　業務プロセスの見直しでは、情報システムを活用することが多い。業務プロセスの見直しを行う際は、業務上の,,,, ,,問題とその原因を明らかにする必要がある。例えば、次のようなものがある。,,,, ,,,,,, ,,,・,特定の業務プロセスに時間がかかっていることが原因で全体の時間が延びている。,, ,,,・,顧客への対応手順が支店ごとに異なることが原因でクレームが発生している。,, ,,,・,判断のミスが多いことが原因で発注のロスが発生している。,, ,,,,,, ,,　システムアーキテクトは、原因を取り除くために情報システムの活用を検討する。情報システムの活用には、例,,,, ,,えば次のようなものがある。,,,, ,,,,,, ,,,・,特定の業務プロセスに時間がかかっていることが原因の場合、原因になっている業務プロセスを情報シス,, ,,,,テムで自動化し、時間短縮を図る。,, ,,,・,顧客への対応手順が支店ごとに異なることが原因の場合、業務プロセスの標準に基づいた情報システム,, ,,,,機能を開発し、必ず対応手順が同じになるようにする。,, ,,,・,判断のミスが多いことが原因の場合、ルール化した判断方法を情報システムに組み込み、人間による判断,, ,,,,を排除する。,, ,,,,,, ,●ストーリー作成のポイント（見出しの検討）,,,,, ,,,,,, ,,　設問イで指示されている要求事項は、,,,, ,,,,,, ,,,・,業務上の問題とその原因,, ,,,・,原因を取り除くために活用した情報システム,, ,,,,,, ,,となっている。「業務上の問題とその原因」について、「特定の業務プロセスに時間がかかっていることが原因で,,,, ,,全体の時間が延びている」、「顧客への対応手順が支店ごとに異なることが原因でクレームが発生している」、「,,,, ,,判断のミスが多いことが原因で発注のロスが発生している」という３つの例が示されている。いずれも分かりやす,,,, ,,い例で、問題点と原因が明確になっている。問題点と原因としてどのような事項が期待されているかを十分理解,,,, ,,したうえで記述したい。,,,, ,,　問題に示されている最初の例であれば、「全体の処理時間の遅延」が問題で、原因は「特定の業務プロセスに,,,, ,,時間を要している」となる。「原因を取り除くために活用した情報システム」についても「原因になっている業務プロ,,,, ,,セスを情報システムで自動化し、時間短縮を図る」、「業務プロセスの標準に基づいた情報システム機能を開発し,,,, ,,、必ず対応手順が同じになるようにする」、「ルール化した判断方法を情報システムに組み込み、人間による判断,,,, ,,を排除する」のように3点例示されている。それぞれ「業務上の問題とその原因」に対応した例になっており、スト,,,, ,,ーリー作成を手助けしてくれる。,,,, ,,　情報システムの内容そのものについては詳しく記述する必要はなく、情報システムをどのように活用したかとい,,,, ,,う観点で記述すればよい。問題文に示されている例であれば、「自動化による時間短縮」、「標準化による対応手,,,, ,,順の同一化」、「判断を自動化することによる属人性の排除」という活用になっている。いずれの例も平易な内容,,,, ,,となっているため、受験者が経験した事例を基に記述すれば、題意を満たすと考えられる。,,,, ,,,,,, ,●ストーリー,,,,, ,,,,,, ,,イ　業務上の問題とその原因、及び原因を取り除くために活用した情報システム,,,, ,,イ―１　業務上の問題とその原因,,,, ,,,,,, ,,,・,業務上の問題は資産管理システムで管理している資産の情報と、実際に存在している現物の資産が、毎,, ,,,,回の棚卸で相当数不一致になっている点,, ,,,・,棚卸のたびに人手によって不一致を解消しているが、次の棚卸においても不一致が再発している,, ,,,・,資産管理システムの管理対象となっている資産は大きく2種類あり、一つは複合機や大型スクリーンのよう,, ,,,,に移動が少なく、据え付けや調整にも専門の業者が必要になる資産、もう一つは執務席に配置されている,, ,,,,PCなど基本的に個人が使用する資産,, ,,,・,個人が使用する資産は、基本的に個人に紐づいており、人事異動などに伴い個人とともに移動先へ移さ,, ,,,,れる,, ,,,・,資産移動に伴い、資産の管理者が表計算ソフトによって、上長経由で情報システム部門へ移動の申請を,, ,,,,行うことになっている,, ,,,・,情報システム部門が、過去の不一致の事例調査や、現場への聞き込み調査などを行い、不一致が生じる,, ,,,,主な原因は、申請を忘れたり、上長が承認を忘れたり、誤って申請したりすることなどによることが判明,, ,,,,,, ,,イ―２　原因を取り除くために活用した情報システム,,,, ,,,,,, ,,,・,A社では、人事異動や通勤経路の申請などについて、以前よりワークフローシステムが利用されている,, ,,,・,ワークフローシステムでは、手続きの流れが事前に登録でき、上長承認機能や、承認者に対して申請が,, ,,,,あった旨を伝えるフォローメール送信機能がある,, ,,,・,資産情報の不一致が生じる主な要因が人事異動に伴うものであるため、人事異動のワークフロー申請の,, ,,,,データから資産移動のデータを作成し、資産管理システムの入力データとすることとした,, ,,,・,資産移動のデータを自動作成することによって、現物と情報の不一致の件数は９０％削減できることが見,, ,,,,込まれている,, ,,,,,, ,●ストーリーから論文を作成するポイント,,,,, ,,,,,, ,,　２つの要求事項のうち、「原因を取り除くために活用した情報システム」については、情報システムの内容を詳,,,, ,,細に記述する必要がないため、記述量は限定的になると考えられる。設問イで要求される最小字数の800字を下,,,, ,,回らないようにするため、もう一点の要求事項である「業務上の問題とその原因」を掘り下げて、字数を意識しな,,,, ,,がら記述を進めたい。,,,, ,,,,,, ,●解答例　設問イ,,,,, ,,,,,, ,,イ　業務上の問題とその原因、及び原因を取り除くために活用した情報システム,,,, ,,イ―１　業務上の問題とその原因,,,, ,,,,,, ,,,　業務プロセスを見直す契機となった業務上の問題は資産管理システムで管理している資産の情報と、実際,,, ,,,に存在している現物の資産が、毎回の棚卸で相当数不一致になっていることである。これまでA社では、棚卸,,, ,,,のたびに発生する現物と情報の不一致を、人手によって解消してきた。しかし、次の棚卸においても、また新,,, ,,,たな不一致が再発している状況となっている。,,, ,,,　資産管理システムの管理対象となっているA社の資産は大きく2種類ある。一つは複合機や大型スクリーン,,, ,,,のように物理的な移動が少なく、据え付けや調整にも専門の業者が必要になる資産であり、もう一つは執務,,, ,,,席に配置されているPCや業務用の携帯電話など基本的に個人が占有して使用する資産である。個人が使用,,, ,,,する資産は、個人に紐づいた管理になっており、人事異動などに伴い個人とともに異動先の資産として移され,,, ,,,ることになっている。現在は、資産移動に伴い、資産の管理者が表計算ソフトによって、上長経由で情報シス,,, ,,,テム部門へ移動の申請を行う運用である。情報システム部門が、過去の不一致の事例調査や、現場への聞,,, ,,,き込み調査などを行い、不一致が生じる主な原因は、申請を忘れたり、上長が承認を忘れたり、誤って申請し,,, ,,,たりするなどによることが判明した。,,, ,,,,,, ,,イ―２　原因を取り除くために活用した情報システム,,,, ,,,,,, ,,,　A社では、人事異動や通勤経路の申請などについて、以前よりワークフローシステムが利用されている。ワ,,, ,,,ークフローシステムでは、手続きの流れが事前に登録でき、上長承認機能や、承認者に対して申請があった,,, ,,,旨を伝えるフォローメール送信機能を持っている。資産情報の不一致が生じる主な要因が人事異動に伴うも,,, ,,,のであるため、私は、既存の情報システムを活用し、人事異動のワークフロー申請のデータから資産移動の,,, ,,,データを作成して、資産管理システムの入力データとすることとした。資産移動のデータを自動作成することに,,, ,,,よって、申請忘れや承認忘れを防止でき、現物と情報の不一致の件数は９０％削減できることが見込まれて,,, ,,,いる。,,, ,,,,,, ６．３．３　設問ウの論文作成例,,,,,, ,,,,,, ,●設問,,,,, ,,,,,, ,,設問ウ,,,設問イで述べた情報システムの活用で、例外的な状況でも業務プロセスが実行できるように、想定して, ,,,,,検討した、起こり得る状況とその対応を、600字以上1200字内で具体的に述べよ。, ,,,,,, ,●設問ウに対応する問題文,,,,, ,,,,,, ,,　また、このような情報システムの活用では、例外的な状況でも業務プロセスが実行できるように、次のような対,,,, ,,応を検討しておくことも重要である。,,,, ,,,・,まれに発生する例外データへの対応方法の用意,, ,,,・,情報システムで判断できない場合の人間への判断材料の提示,, ,,,,,, ,●ストーリー作成のポイント（見出しの検討）,,,,, ,,,,,, ,,　設問ウで指示されている要求事項は、,,,, ,,,,,, ,,,・,想定される例外的な状況,, ,,,・,例外への対応,, ,,,,,, ,,となっている。一つ目の要求事項である「想定される例外的な状況」については、「想定される」ということであるか,,,, ,,ら、題材に苦労することなく容易に記述しやすい事項であるといえる。ただし、業務プロセスを遂行する際に発生,,,, ,,する例外的な状況でなければならず、何を記述してもよいということではない。問題文には「まれに発生する例外,,,, ,,データ」、「情報システムで判断できない場合」という例が示されている。例外的な状況が発生し、設問イで検討し,,,, ,,たような情報システムの活用では業務プロセスが実行できないという事態が想定されていると考えられる。「例外,,,, ,,への対応」に対応した例としては、「対応方法の用意」、「人間への判断材料の提示」とだけ示されており具体的に,,,, ,,はなっていない。詳細な対応方法は記述しなくてもよいが、具体的な対応方法になるようストーリーを作成すると,,,, ,,きに注意する必要がある。,,,, ,,,,,, ,●ストーリー,,,,, ,,,,,, ,,ウ　想定される例外的な状況と例外への対応,,,, ,,ウ―１　想定される例外的な状況,,,, ,,,,,, ,,,・,個人が使用する資産は、基本的に個人に紐づいているが、営業職からスタッフ職への移動のように職種が,, ,,,,変更になる場合や対象の資産が業務専用の資産であって後任の社員が使用する場合など、まれに資産,, ,,,,移動を伴わないこともある,, ,,,・,資産移動を伴わない人事異動の場合、人事異動の情報を基に資産移動を行うと、新たに現物と情報の不,, ,,,,一致を生じさせることになる,, ,,,・,異動全体から見れば資産移動を伴わない移動は少数であるが、今後ともゼロにはならないため、何らかの,, ,,,,対応が必要である,, ,,,,,, ,,ウ―２　例外への対応,,,, ,,,,,, ,,,・,資産移動を伴わない人事異動への対応方法として２つの案が考えられる,, ,,,・,一つは、本人がワークフローシステムで例外申請を行い、人事異動データを基にした資産移動を回避する,, ,,,,方法,, ,,,・,もう一つは、移動元の上長が一括で資産移動の停止情報を作成し、情報システム部門に提出する方法,, ,,,・,どちらの方法においても、申請忘れや情報の提出忘れというリスクは残るが、本人申請のほうが対象の件,, ,,,,数が多くなることから、異動元の上長が停止情報を作成し、情報システム部門に提出する方法を採用,, ,,,・,上長の提出忘れを防止するために、人事異動の際の一連のチェックリストに資産移動に関する項目を追,, ,,,,加する,, ,,,・,加えて、ワークフローシステムの機能を利用して、当該上長へ停止情報提出のフォローメールを送信するこ,, ,,,,とにした,, ,,,,,, ,●ストーリーから論文を作成するポイント,,,,, ,,,,,, ,,　設問ウにおける２つの要求事項である「想定される例外的な状況」、「例外への対応」とも、記述量があまり多く,,,, ,,ならないと考えられるため、注意しておかないと設問ウで要求される最小字数の600字を下回る可能性が否定で,,,, ,,きない。「想定される例外的な状況」では、単に状況を述べるだけではなく、状況が起こり得る背景に触れるなど、,,,, ,,十分な記述量が確保できるように、ストーリー作成の時点から考慮しておく必要がある。,,,, ,,,,,, ,●解答例　設問ウ,,,,, ,,,,,, ,,ウ　想定される例外的な状況と例外への対応,,,, ,,ウ―１　想定される例外的な状況,,,, ,,,,,, ,,,　個人が占有して使用する資産は、基本的に個人に紐づいている。ただし、営業職からスタッフ職への異動の,,, ,,,ように職種が変更になる場合や対象の資産が特定の業務専用の資産であって後任の社員が使用する場合な,,, ,,,ど、まれに資産移動を伴わないこともある。,,, ,,,　資産移動を伴わない人事異動の場合、人事異動の情報を基に資産移動を行うと、新たに現物と情報の不一,,, ,,,致を生じさせることになる。異動全体から見れば資産移動を伴わない異動は少数であるが、今後ともゼロには,,, ,,,ならないことが明確になっているため、何らかの対応が必要であった。,,, ,,,,,, ,,ウ―２　例外への対応,,,, ,,,,,, ,,,　私は、資産移動を伴わない人事異動への対応方法として次の２つの案を検討した。,,, ,,,　一つは、本人がワークフローシステムを利用して資産移動が伴わないことの例外申請を行い、人事異動デ,,, ,,,ータを基にした資産移動を回避する方法である。もう一つは移動元の上長が一括で資産移動の停止情報を作,,, ,,,成し、情報システム部門に提出する方法である。どちらの方法においても、本人の申請忘れや上長からの情,,, ,,,報の提出忘れというリスクは残る。各人別に行う本人からの申請件数の方が、一括で行う上長からの情報の,,, ,,,提出件数よりも多くなることから、今回は、異動元の上長が資産移動の停止情報を作成し、情報システム部門,,, ,,,に提出する方法を採用することにした。,,, ,,,　私は、人事異動の際の手続きに関する一連のチェックリストに資産移動に関する項目を追加することで、異,,, ,,,動元上長の提出忘れを極力少なくする工夫をした。加えて人事異動が発生したときに、ワークフローシステム,,, ,,,のフォロー機能を利用して、該当する上長あてに資産移動の停止情報を提出する旨のフォローメールを送信,,, ,,,することとした。　以上,,,