Ｈ１８−問１　システム要件の確定について

　通常，システム要件定義において，アプリケーションエンジニアはユーザから提示された業務要件に基づいて，システム要件を確定させる作業を行う。 この作業の中で，システム化の規模が明らかに予定を上回っていたり，技術的難易度が高すぎたり，システム化によって得られる効果が目標よりも小さかったりする課題が発生することがある。 このような課題が発生した場合，課題の解決に向けて，アプリケーションエンジニアはユーザに積極的に提案を行い，双方が納得できる内容でシステム要件を確定させることが重要である。
　その際，ユーザに対して，例えば，次のようなアプローチを通して提案を行う。

• 業務要件に基づくシステム化範囲やシステム化規模を可視化したり，参考となるシステムと比較したりして，ユーザにシステムの全体概要を確認してもらい，システム化規模を予定の範囲に収める。
• アルゴリズムや条件の複雑さをユーザに分かりやすく示すことによって，技術的難易度を説明し，簡素化したシステム要件を提案する。
• 業務要件のシステム化によって得られる効果の大きさについて論理的に説明し，効果が小さい業務要件については，ユーザに再検討を依頼する。

Ｈ１８−問２　障害発生時の影響を最小限に抑えるためのシステム設計について

　システムは，企業の業務遂行に重要な役割を担っているので，障害発生時の影響を最小限に抑えることが重要である。そのために，障害発生の予防策とともに，障害発生時の影響を最小限に抑えるための対策を，システム設計の段階から検討しておく必要がある。 その際，アプリケーションエンジニアは，起こり得る障害とその影響を想定した上で，その対策を業務アプリケーションの設計に組み入れる。
　障害発生時の影響を最小限に抑える対策として，例えば，障害発生時の速やかな問題判別，迅速な復旧，業務の部分的再開などが重要である。これらの対策を実現するために，具体的には次のような設計を行う。

• 速やかな問題判別を可能とするために，障害の原因・箇所を特定できるようなログを，適切なタイミングで業務アプリケーションから出力する。
• 迅速な復旧を可能とするために，システムや業務の特徴を考慮して，適切なリスタートボイントやパックアップ手順を定める。
• 業務の部分的再開を可能とするために，業務の特徴や運用形態を考慮して，個々のサブシステムが独立して稼働するようにする。

Ｈ１８−問３　移行計画におけるタイムチャートの事前確認について

　基幹系システムのように，ほかのシステムとのインタフェースが多岐にわたり，データの種類や量が多いシステムの場合は，システム移行に多くのシステム資源を必要としたり，作業時間が長くなったり，作業手順が複雑になったりする。 このような移行に当たっては，計画したタイムチャートどおりの時間や手順で実施できるかどうかを，事前に確認しておくことが重要である。
　その際，本番のシステム移行時と同じシステム資源を用いて，同じタイムチャートで実施することが望ましいが，使用できるシステム資源や作業時間の制約から，本番どおりには実施できない場合がある。 そのような場合には，ほかのシステムや後続作業への影響の大きさ，移行データの種類や量の多さ，各種機器の切替手順の複雑さなどに着目して，タイムチャートのクリティカルな部分を見極め，例えば，次のような幾つかの方法を組み合わせて，クリティカルな部分が計画どおりに実施できることを確認する必要がある。

• 開発用のシステム資源を用いて作業を行い，その結果から類推する。
• 一部の本番データを用いて作業を行い，その結果から類推する。
• 本番と同じ切替手順書を用いてシミュレーションを行い，その結果から類推する。

Ｈ１７−問１　データウェアハウスの設計について

　従来，企業においては，販売や在庫管理といった業務の効率向上，省力化などを目的としたシステムが様々に構築されてきた。近年，それらの各システムに分散していたデータを分析し，経営の意思決定やマーケティングなどをサポートするために，データを集約・蓄積したデータウェアハウスが構築されている。
　データウェアハウスの利用においては，商品の多様化によって商品データの分類方法が変更になるなど，分析ニーズが変化し，分析に必要なデータや分析方法が当初の計画と変わってしまうことが多い。 このような分析ニーズの変化に柔軟に対応できるように，データウェアハウスは，データの鮮度や精度が維持され，ユーザが自在に分析できる利用環境が整っていることが重要である。
　したがって，データウェアハウスの設計に当たっては，データの維持方法，利用方法，ユーザのシステム習熟度などを踏まえ，次のような工夫が必要である。

• データの種類・量の増加や分析ニーズの変化を考慮して，生データや加エデータを適切に保有する。
• 分析二ーズが変化しても，集約・蓄積したデータが正しく利用されるように，データを明確に定義したドキュメントを作成する。
• システムに不慣れなユーザでも自由にデータを利用できるように，検索ツールや分析ツールを導入する。

Ｈ１７−問２　性能要件を満たすシステム構成の設計について

　金融機関における口座振替処理やディーリング，流通業におけるオンライン受発注などの業務システムに対しては，スループットや応答時間などの性能要件が厳しく求められる。
　これらのシステムにおける性能要件を満たすためには，対象業務を分析し，業務処理が集中する日や時間帯とユーザ数，季節変動，例外処理，将来におけるデータ量の増加などを考慮し，更に安全率を掛けてピーク時の処理量を見積もることが重要である。 次に，その処理量に対して，求められる性能要件を満たす適切なソフトウェアやハードウェアの構成を設計する。その際，プログラム処理の多重化，ミドルウェアの採用，サーバやクライアントの仕様などを検討する必要がある。
　このようなシステム構成の設計において，アプリケーションエンジニアは，次のような工夫を行うことが重要である。

• データ処理量や処理パターンなどを，業務特性や利用技術の面から分析・評価し，ソフトウェア構成に反映させる。
• 検討されたソフトウェア構成に基づいて性能を評価し，ハードウェア構成に反映させる。
• 負荷平準化や動的資源割当て機構などに関する新製品や新技術の効果を評価し，システム構成に反映させる。

Ｈ１７−問３　アプリケーションバッケージなどを利用したシステム構築について

　新規事業の立上げや新会社の設立などで，会計・販売・人事などの業務システムを短期間に構築しなければならない場合がある。 この場合，全システムを新規に開発するのではなく，グループ会社で実績のある既存のシステムを導入して業務ごとに組み合わせたり，業務に対する適合性が高いと判断したアプリケーションパッケージ（以下，パッケージという）を新たに導入して，既存のシステムと組み合わせたりすることがある。
　例えば，会計システムには新規事業や新会社の業務に対する適合性が高いパッケージを新たに導入し，販売システムや人事システムには業務プロセスや制度などが類似しているグループ会社の既存のシステムを利用する場合がある。
　このような場合，アプリケーションエンジニアは次のような点に着目し，システムを檎集することが重要である。

• 業務間の連携が損なわれないようにすること
• システム間のデータの整合性が失われないようにすること
• パッケージや既存のシステムの仕様に合わせて業務プロセスを変更すること

Ｈ１６−問１　パイロット開発について

　企業全体に導入されるような大規模システムの開発では，システム全体を一斉に開発したり，関係部門に一斉に導入したりすると大きなリスクを負う場合がある。 このようなシステム開発では，機能・性能・開発規模・実行環境・運用などの面から，本開発での課題を想定し，その開発解決のためにパイロット開発を行い，次のような評価を行ってから本開発に進む方法がある。

• 高い応答性が求められるような業務の場合，最も要求の厳しい処理について開発を行い，求められている機能や性能を実現できるか評価する。
• 開発環境に制約があったり，新しい開発ツールを使用したりするような場合，準備した開発環境や開発ツールが本開発に耐えられるか評価する。
• 全社で使用するシステムを開発する場合，最初に一部の部門にシステムを導入し，運用面で問題がないか評価する。

Ｈ１６−問２　システム間連携の設計について

　企業においては，営業支援システム，カスタマサポートシステム，販売管理システムなどのように，機能別に個別システムが開発され，開発時点の業務用件に基づいて連携されている場合が多い。 昨今，企業を取り巻く事業環境の変化やビジネスのスピードアップに対応するために，システム間連携を強化することで，経営課題や業務課題を解決しようとする場合がある。 このような例としては，顧客との取引状況を把握するために，カスタマサポートシステムに販売管理システムの顧客データをリアルタイムに転送したり，営業支援システムに販売管理スステムの売掛データを発生の都度，転送したりすることがある。
　システム間連携の強化に当たっては，システム全体の修正を最小限に抑えて，システム間の整合性，データの一貫性，要求されたパフォーマンスを確保することが重要である。 そのためには，アプリケーションエンジニアは次のような点を分析し，メッセージキューや中間ファイル，システム間のデータの受け渡しのタイミングなどを設計しなければならない。

• データの属性，ファイルのフォーマットおよびコード体系
• 個別システムのマスタファイル更新，トランザクション処理のタイミング
• 個別システムのトランザクション量とシステム間で受け渡されるデータ量
• システムの利用者数，利用時間帯および運用サイクル(日次・月次など)

Ｈ１６−問３　Webアプリケーションシステムの設計について

　近年，インターネット上で様々な人々が利用するWebアプリケーションシステムの開発が増えている。 このようなシステムの例としては，電子商取引やインターネットバンキング及びインターネットトレーディングなどがある。
　これらのシステムの設計に当たっては，システムの信頼性や応答性を確保し，多くの人に使いやすい，音声・画像・ナビゲーションツールなどを活用したユーザフレンドリなインタフェースを実現することが重要である。 その場合，次のような点を考慮する必要がある。

• 入力されたデータが操作ミスなどによって消失しないように，システムの信頼性を確保する。
• 頻繁に入力データのチェックを行う場合には，サーバ側ではなくクライアント側で処理することで，応答性を確保する。
• 為替レートや株価の変動などをリアルタイムに表示するシステムでは，データの信頼性とともに高い応答性を確保する。

Ｈ１５−問１　システム設計における総合的なセキュリティ対策について

　近年，企業や官公庁では，システムへの不正アクセスによる情報の漏えい・改ざんなどの脅威に対するセキュリティ対策が必須となっている。これらの組織では，リスクの軽減のために，情報の漏えい・改ざんの防止に関するセキュリティ対策基準を設定している。その例としては，次のようなものがある。

• 情報に重要度のランク付けを行い，取扱いを明確にする。
• 利用者の役職や職種に応じたアクセス権限を付与する。
• ユーザIDやパスワードの管理を厳密に行う。
• 情報へのアクセスに対し，アクセスログをすべて取得する。

Ｈ１５−問２　システム化の範囲の確定について

　システム化の範囲の確定は，システム設計の上流工程である要件定義フェーズの重要な作業である。
　システム化の範囲の確定に当たっては，ユーザ要求をすべてシステム化の範囲とすると，開発期間や開発費用の制約を超える可能性があるので，ユーザとの調整が必要である。その際，アプリケーションエンジニアは，業務の標準化や見直し，EUCによる対応，ユーザが対応可能な業務運用の工夫などをユーザに提案することが重要である。その例としては，次のようなものがある。

• 重複した業務や非効率的な業務の廃止や標準化を提案する。
• ユーザが表計算ソフトなどを用いて自由に帳票作成ができるデータ提供の仕組みを提案する。
• 他システムとのインタフェースが大きく変更になり，他システムに大規模な開発が必要になる場合には，ユーザ要求をすべて取り込むのではなく，他システムの変更が最小になるような業務運用を提案する。

Ｈ１５−問３　システムテストの計画立案について

　システムテストは，機能テスト，性能テスト，障害回復テストなどを行うことによって，システム全体の品質を総合的に確認する作業である。その計画立案においては，テスト体制・テストスケジュール・テスト項目・テスト方法などを策定する。
　システムテストでは，システム全体の十分な品質を確保するために，必要なテスト期間を設定し，本番と同じ環境を用いたテストを実施することが望ましい。しかしながら，実際には，テスト期間が限られたり，本番環境と同等のテスト環境を用意できなかったりすることが多い。例えば，次のような制約が発生する。

• 実際の日付での月次処理や期次処理のテストができない。
• 十分な端末台数や回線容量を確保できない。
• 本番と同等の処理能力を確保できない。
• 本番データを全量用いたテストが難しい。
• 起こりうるすべての障害ケースの設定ができない。

Ｈ１４−問１　24時間連続稼働するシステムの開発について

　インターネット利用による企業間取引やグローバルな EDI などのために、24時間連続稼働するシステムが増加している。これらのシステムは、購買業務、受発注業務など、ビジネスの基幹システムとして安定稼働が要求される。
　こうしたシステムを開発する際には、システム設計上、信頼性や保守性の高いシステムにすること、可用性の高いデータベースを設計すること、夜間バッチ処理を削減すること、他業務との連携における日付処理の正当性を確保することなどが重要である。このために、アプリケーションエンジニアが検討する課題としては、例えば、次のような点がある。

• オンライン、バッチのコンカレント処理方式
• リアルタイム処理、ディレード処理などの選択
• DBMS における障害回復時間の短縮
• 日締め処理のタイミングの取り方や他システムとのデータの受渡し方法

Ｈ１４−問２　新技術の導入について

　近年、IT の進歩は著しく、多くの新技術が提供されている。システム開発においても、ユーザ満足度の向上、生産性の向上、外部システムとの連携などのために、開発チームにとって未経験な新技術の導入が必要になるケースが増えている。
　新技術を導入するシステム開発に当たって、アプリケーションエンジニアは、その技術を調査・検討するとともに、新技術に対する開発メンバの適応力を高めるために、次のような取組を行う必要がある。

• 新技術の試行とアプリケーション要件に照らした評価
• 社内外の経験者や専門家からのノウハウのヒアリング
• 開発標準の作成と開発メンバに対する教育カリキュラムの作成
• Q&A 体制の確立

Ｈ１４−問３　外部設計におけるデザインレビューについて

　外部設計は、業務要件で規定されたシステムの外部仕様を実現するための基本の方式設計を行うフェーズであり、そこでのデザインレビュー(以下、レビューという)を繰り返すことによって、信頼性・操作性・性能などシステムの品質を確保することができる。
　外部設計におけるレビューを行うに当たっては、レビューの対象ドキュメントを明確にした上で、業務の特徴を踏まえ、例えば、次のような観点から具体的なチェック項目を設定することが重要である。

• 機能や操作性はユーザニーズに合っているか。
• 機能や操作性の制約は明確になっているか。
• 機能間の整合性はとれているか。
• 性能は妥当か。

Ｈ１３−問１　Web アプリケーションシステムにおけるユーザインタフェース設計について

　近年、Web 技術の普及やネットワーク基盤の拡充を背景に、インターネットやイントラネットを使って、販売や受発注、経費精算といった業務システムを構築する例が増えている。これらの Web 技術を利用したシステムのユーザインタフェース設計においては、不特定多数の利用者も想定し、分かりやすさや入力の容易さなどの高い操作性とともに、応答性の確保が求められる。
　Web アプリケーションシステムにおけるユーザインタフェース設計では、次のような事項について検討し、想定した利用者にふさわしい高い操作性を実現する工夫が必要である。

• テキストボックス、リストボックス、ラジオボタンなどの利用
• 文字やボタンなどの色・形・大きさとその配置
• 画像や動画、音声ガイダンスなどの利用
• マウスやキーの使用
• ナビゲーションツールの利用

Ｈ１３−問２　セキュリティ対策としてのアクセスコントロール設計について

　ネットワークの活用によって、様々な人が情報システムに容易にアクセスできるようになり、利便性が向上している。その反面、情報システムに対する脅威は大きく広がり、セキュリティ対策の重要性が高まっている。種々の脅威に対してセキュリティを確保するためには、アクセスコントロールを堅固にすると同時に、運用負荷を軽減する検討も必要である。
　セキュリティ対策のひとつであるアクセスコントロールの設計においては、権限のある人が、必要なときに、必要な情報を過不足なく利用できることが前提となる。
　そのためには、次のような事項を組み合わせて設計する必要がある。

• 入力、変更、検証、承認などの操作を行うときにユーザ自身が持つユーザ権限
• データの重要度によるランク付け
• 業務の種類、内容によるユーザ ID への制限の付与

Ｈ１３−問３　稼働中のシステムの保守作業について

　システムが本番稼働し、運用が始まると、業務改善や制度変更に伴い、仕様変更や機能追加などのユーザ要求によって、プログラムの保守作業が発生する。プログラムの保守作業にあたっては、稼働中のシステムに悪影響を与えないように十分なテストを行った上でリリースすることが重要である。
　修正プログラムのテストでは、一般にテスト環境を使って機能テスト、性能テストなどを行う。機能テストでは、修正した機能を効率的に漏れなく確認するために、次のような事項を検討することが重要である。

• テスト範囲、テストデータの内容・組合せ
• 本番データを抽出するなどのテストデータ作成方法
• テストツールの使用やテスト結果の確認方法

Ｈ１２−問１　データ中心アプローチ技法によるシステム設計について

　企業における情報化が進むにつれ、全社的なデータ管理の必要性が高まってきている。そこで、データを共有資源と見なし、データ処理を標準化するデータ中心アプローチ技法によるシステム設計が有効となってきた。
　データ中心アプローチ技法では、正規化された新論理モデルをそのまま新物理モデルにすることが望ましい。しかし、実際のシステムにおいては処理効率の悪化、データの管理部門の相違による統合の非現実生、データベース管理の複雑化などの問題点が発生し、作成された新物理モデルが必ずしも現実的であるとは限らない。
　これらの問題点を解決し、現実の業務処理に耐えうる新物理モデルを作成するためには、非正規化が必要となる場合がある。例えば、処理効率を改善するために、参照系の処理では重複データや導出データを保有したり、更新系の処理では細分化されたデータベースを統合して更新回数を削減したりする。反面、重複データの保持やデータベースの統合は、データの整合性やセキュリティの観点から問題となることが多い。したがって、これらの相反する要求を満足するために、非正規化するデータの選定や方法には十分な注意を払わなければならない。
　あなたの経験に基づいて、設問ア〜ウに従って論述せよ。

Ｈ１２−問２　アプリケーションパッケージの活用について

　企業の基幹業務システムの構築手段として、ERP のようなアプリケーションパッケージ(以下、パッケージという)を導入することが多くなっている。
　パッケージを導入してシステムを構築するに当たっては、パッケージの機能の適合率、業務プロセスの変更の程度や現行システムの優位性などを総合的に評価して、パッケージの適用範囲・方法を明確にする必要がある。
　パッケージの適用範囲・方法の検討においては、当該パッケージの標準機能と業務システムが必要とする機能の分析を行い、そのギャップを明確にした上で、パッケージのパラメタ設定によって実現できる機能を確認する。パラメタ設定で実現できない機能については、パッケージのインタフェース機能を利用した外付けプログラムの開発や、独自開発などを検討する。また、パッケージに機能があっても、業務プロセスの変更が困難な場合や、現行システムの優位な機能を適用する場合には、パッケージの一部の機能を使わずに現行システムの使用も検討する。
　あなたの経験に基づいて、設問ア〜ウに従って論述せよ。

Ｈ１２−問３　システム統合について

　企業の合併・買収、製造と販売の統合要求などから、これまで単独で稼働していたシステムを他システムと統合するニーズが多く出てきている。また、事業や組織の再編などによって、これまで個別に構築してきた部門システムを統合する場合もある。このような場合、新しくシステムを構築するには費用と時間がかかり、企業環境の変化のスピードに対応できないことから、いかに既存システムを活用して統合するかを検討する必要がある。
　既存システムの統合には、次のような方法が考えられる。

• どちらか一つのシステムをベースとして、機能を拡張する方法
• システムの入口を別システムに集約し、その別システムの分配機能によって個々のシステムにデータを受け渡しする方法
• 二つのシステム間にメッセージキューや中間ファイルなどを配置して、相互連携をとる方法

• データ体系の違い(主キー、明細・サマリ、グルーピングなど)
• コード体系やけた数の違い
• トランザクションの処理方法の違い(リアルタイム処理・バッチ処理など)
• 運用サイクルの違い(日次・週次・月次など)

Ｈ１１−問１　処理効率面から見たデータベースの設計について

　論理データ構造が明らかになった時点でデータベースの物理設計を行うが、その際、業務の特徴を考慮して処理効率の評価を行い、設計に反映させる必要がある。
　処理効率の評価に当たっては、まず適用業務を分析して評価の対象となる処理と関係するデータベースを特定し、更にその処理内容を明確にしなければならない。分析の観点としては、ピーク時の入力データ量、オンライン処理かバッチ処理かなどの処理形態、更新・参照などの処理方法、データベース構造を考慮したセグメントごとのアクセス回数などが挙げられる。これらの分析を踏まえて、応答時間やバッチ処理時間を計算し、要求を満足しているかどうかを評価する。
　このような適用業務の特徴を考慮した評価が不十分であると、特定のデータベースにアクセスが集中し、レスポンスの悪化を招くなどの問題が発生し、そのシステムに要求される性能を実現できなくなるおそれがある。
　評価の結果、問題が発生した場合、アクセス回数を削減するためのデータの非正規化や導出データの保持、アクセスの集中を防ぐためのデータベースの分割などによる改善を検討する。その反面、データの更新方法や分割したデータベースの整合性を保持することの難しさ、システムの変更に伴う保守負担の増大などのマイナス面が発生するので、その対策も検討しなければならない。また、業務機能や運用方法の一部について制約を設ける検討が必要になることもある。
　あなたの経験に基づいて、設問ア〜ウに従って論述せよ。

Ｈ１１−問２　ネットワークを介した企業間でのデータ受渡しについて

　ネットワークシステムの発達に伴い、ビジネススピードや業務効率の向上を目的として、ネットワークを介して企業間でのデータ受渡しを行うことが多くなっている。
　ネットワークを介した企業間でのデータ受渡し仕様を決定するに当たっては、受渡しのための手続として、全銀手順、JCA 手順、EDIFACT などの標準的なプロトコルの採用、個別の業務データレベルの受渡し項目の決定やデータコードなどの定義、受け渡すデータ量の正確な見積りを行うことが重要である。
　さらに、運用面では、接続先確認やデータ伝送確認の方法、及び1回のデータ伝送時間、1日の伝送回数や伝送開始時刻などの運用スケジュールも取り決めておく必要がある。また、与えられた時間内にデータを受け渡すために、ファイルの分割やデータ伝送処理能力などについて検討し、運用スケジュールが遅れた場合の回復方法などについても検討することが求められる。
　このように、データ受渡し仕様や運用スケジュールを明確に定義し、想定されるトラブルへの対応を検討しておくことが、企業間でのデータ受渡しをスムーズに実現するために必要である。 　あなたの経験に基づいて、設問ア〜ウに従って論述せよ。

Ｈ１１−問３　データ移行について

　システムを再構築し、移行を行う場合、旧システムから新システムへのデータ移行が必要になる。移行仕様の設計に際しては、旧システムと新システムのデータフローやファイル仕様などを参考にして、移行の対象となるデータを決定し、データ交換の必要性を検討する。次に、旧システムでの事前のデータ整備、移行プログラム開発、移行テストなどについて検討し、必要な作業工数を漏れなく見積もらなければならない。さらに、データの移行時期や旧システムと新システムの並行運転の期間・方法なども検討しておくことが重要である。
　データ移行計画の作成では、旧システムから新システムへのデータの移行手順を詳細に検討し、作業時間を見積もることが重要である。また、与えられた期間・時間の中で作業を終了させるために、処理の並列化などによる作業時間の短縮を検討し、作業のクリティカルパスを明らかにしておくことなどが求められる。
　新システムをトラブルなく本番稼働させるためには、データ移行作業が正しく行われていることを確認するためのチェックポイントを設定したり、移行データの検証方法を決めたり、本番稼働判断基準を定めたりすることが必要である。
　あなたの経験に基づいて、設問ア〜ウに従って論述せよ。

Ｈ１０−問１　CASE ツールの適用について

　ソフトウェア開発の品質向上、生産性向上策の一つとして、CASE ツールの適用は有効である。
　昨今、実用化されている CASE ツールには、次のような様々な機能がある。

• DFD や E-R 図によるプロセスやデータのモデリング、リポジトリによる一貫した情報の管理、データベース定義の自動生成、プログラムの自動生成などのシステム開発支援機能
• プロジェクトの計画・見積もりやプロジェクトメンバのスケジュール管理などのプロジェクト管理支援機能
• ドキュメントの更新ルールの設定、バージョンの管理、部署単位・プロジェクト単位の管理帳票出力などのドキュメント管理支援機能

Ｈ１０−問２　プロトタイピングの活用について

　プロトタイピング活用の目的は、プロトタイプを作成して開発すべきシステムの機能を早期に実証することによって、ユーザニーズに合致したシステムをより効率的に開発することである。
　プロトタイピングにおいては、開発者による検証のためにプロトタイプを作成する場合や、開発者とともにエンドユーザが機能を評価する目的でプロトタイプを試用する場合がある。さらにプロトタイプは、評価・検証後に使い捨てにされる場合や、そのまま最終システムの骨格として使われる場合などがある。
　プロトタイピングを活用することによって、一般的に次のような効果が期待できる。

• エンドユーザの潜在的なニーズを掘り起こし、より効果的な機能をもつ情報システムが構築できる。
• システム開発の初期工程でユーザニーズの確認がより正確にできるので、後工程でシステム設計の仕様変更が減少する。
• システムの機能、性能、操作性などが事前に検証でき、開発リスク低減に役立つ。

Ｈ１０−問３　性能改善について

　適用業務システムの性能目標は、業務要件や運用要件に基づいて、スループット、ターンアラウンドタイム、レスポンスタイムなどの具体的な数値として設定される。
　開発が進みテストを行った結果、性能目標が達成できていなければ、ネットワーク監視ツール、パフォーマンスモニタ、トレースツールなどによって原因を調査・分析し、性能改善を実施する。
　具体例としては、次のような性能改善のための対策が挙げられる。

1. チューニング
   • バッファサイズ、実行優先順位、処理多重度などのシステムパラメタの変更
   • データベースのインデックスの見直し、排他制御方式の見直し
   • プログラムロジックの変更
2. 設計レベルの見直し
   • サーバの分割・統合
   • データベースの物理構造の見直し
   • プログラム構造の見直し
3. リソースの追加
   • メモリ、ディスクなどのハードウェアの増設、ネットワークの高速化

Ｈ９−問１　業務システムの分析・設計について

　新業務システムを構築するためには、現行の業務を分析し現状を把握した上で、新しい要件を加味し、新しい業務機能とデータフローを明確にする必要がある。
　はじめに、業務プロセスの調査を行い、現行業務をありのままに表現する現行物理モデルを作成する。次に、現行機能とデータフローに焦点を絞ってまとめた機能階層図を作成し、現行の業務システムが何をしているのかを明確にして、現行論理モデルに展開する。
　この現行論理モデルを利用して、新論理モデル及び新物理モデルへと展開していく。具体的には、無駄な業務を廃止し、類似業務の統合・簡素化を図りながら、ユーザの要求する新機能を追加して、業務に真に必要な機能を表した新機能階層図を作成する。更に、データの正規化、冗長性の排除、データフローの整理などを行う。この結果、無駄な伝票作成のような不要な仕組みの削除、入力機能の集中による重複機能の統合、台帳の統廃合など、機能やデータの簡素化が図られる。
　あなたの経験に基づいて、設問ア〜ウに従って論述せよ。

Ｈ９−問２　分散システムの設計について

　ハードウェア、ソフトウェア技術の発達によって、様々な分野においてワークステーションやパソコンが急速に普及してきている。従来、汎用コンピュータによって集中処理を行っていた大規模システムなども、ワークステーションやパソコンを利用した分散システムによって実現が可能になってきている。
　分散システムの設計においては、汎用コンピュータ、ワークステーション及びパソコンのそれぞれの特徴を十分に考慮し、リソースをどのように分散させるか、また業務機能とデータをそれらの役割に応じてどのように分散させるかがポイントとなる。
　具体的には、業務機能は本社、営業所、工場などにどのように分散しているか、業務処理は全社、部門、個人など、どの範囲で完結しているかといった業務の特性を検討する。
　そして、データの作成方法、入力方法、使用頻度、出力方法、保存期間などのデータの特性を分析する。
　更に、組織変更や仕様変更に対する柔軟性、対象業務の多様化やデータ量の増大に対する拡張性、システムのパフォーマンスの確保、運用の確実性やセキュリティ対策などの観点から検討を行う。
　その上で、システムにおけるリソースの分散、業務機能の分散及びデータの分散を検討することが必要である。
　あなたの経験に基づいて、設問ア〜ウに従って論述せよ。

Ｈ９−問３　システムテスト計画について

　システム開発の最終段階で行われるシステムテストは、システムの機能・性能などの評価項目に対するテストを実施することによって、システムの完成度を総合的に検証する作業である。
　開発したシステムが、要求定義を満足しているか、データのインテグリティ・運用の一貫性を確保しているか、レスポンスタイムやターンアラウンドタイムが性能目標値を満足しているか、などの品質要件の評価を行う必要がある。
　しかしながら、実際には使用可能な端末台数が十分に確保できない、システムの使用開始時期との関係でテスト期間が限られている、またセキュリティ確保の必要から現実のデータが使用できない、などの制約によって、すべての要件を完全に網羅した評価を行うことは困難なことが多い。
　そこで、これらの制約条件を踏まえた上で、いかに効果的なシステムテスト計画を立案するかが重要となる。
　具体的には、テストの目的を明確にし、テスト項目・テスト方法・スケジュール・検証方法などを設定し、効率良く実施する手順・体制・環境を定めることが必要である。
　あなたの経験に基づいて、設問ア〜ウに従って論述せよ。

Ｈ８−問１　システム分析技法について

　アプリケーションエンジニアは、上流の計画フェーズで作成されるシステム開発計画書に基づいて、対象業務の分析、問題点の発見、改善策の提案を行い、新システムの構想を具体的に立案する。そのためには、どのようなシステム分析技法を適用し、その分析技法をどのように活用するかが重要である。
　代表的な技法として、構造化分析技法、データ中心アプローチ技法、オブジェクト指向分析技法などが挙げられる。そこで、これらの各技法の長所・短所を十分に理解したうえで、実際のシステム分析に適用することが大切である。
　また、各分析技法を効果的に適用するために、技法についての事前教育、各技法に対応した CASE ツールの利用などについても検討する必要がある。 　あなたの経験に基づいて、設問ア〜ウに従って論述せよ。

Ｈ８−問２　ソフトウェアパッケージの導入について

　最近、適用業務システムの開発には、ソフトウェアパッケージが多数利用されている。
　ソフトウェアパッケージを導入する目的には、開発期間を短くしたり開発費用を少なくすることばかりでなく、ソフトウェアパッケージに合わせて組織を見直したり、業務プロセスの効率化を図ることなどがある。更に、ソフトウェアパッケージのもつオープン性によって、部門間又は他企業との連携がより容易になることもある。
　しかしながら、ソフトウェアパッケージの機能がユーザ要求をすべて満たすことはまれであり、修正・削除・追加のカスタマイズ作業が必要となることが多い。更に、ユーザ要求の内容、費用・開発期間の制約、ソフトウェアパッケージの仕様などによっては、対応できないユーザ要求が残ることもある。
　あなたの経験に基づいて、設問ア〜ウに従って論述せよ。

Ｈ８−問３　システム間連携の見直しについて

　企業における情報システムは、一般的には個々に構築されたシステムが連携し、統合されたシステムとして機能する。そのため業務の一層の効率化を目的として、個別システム(生産管理システム、販売管理システムなど)を再構築する場合、連携している他システム(購買システム、経理システムなど)についても見直しが必要になる。
　これらの連携したシステムの見直しに際しては、業務の流れとデータの流れから、必要とするデータの受渡し仕様及び項目を決定し、フォーマットの統一やコード体系の整備などの標準化を行う必要がある。
　更に、他システムに要求するデータ受渡しタイミングなどの機能条件、及び処理時間やデータ量などの性能条件を設計目標として設定する必要がある。
　システム間連携の見直しにおいては、統合システムとしての整合性・性能・信頼性の確保が最優先課題である。このため、ときには他システムの大幅な改善が必要となる場合も生じるが、システムの再構築による連携する他システムへの影響を極力少なくするための工夫をすることも重要である。 　あなたの経験に基づいて、設問ア〜ウに従って論述せよ。

Ｈ７−問１　情報セキュリティ対策について

　システムの安全性を確保するには、総合的な情報セキュリティ対策が必要である。
　情報セキュリティ対策の策定に当たっては、現実に発生すれば損失をもたらすリスクが、システムのどこに、どのように潜在しているかを見極め、その影響の大きさを評価したうえでシステムの設計に反映させることが大切である。
　情報セキュリティ対策の役割は、様々なリスクからシステムを保護することである。その中でもシステムへの不正アクセス防止機能は中心的な機能であり、リスクを回避するうえで大きな効果が期待できる。
　アプリケーションエンジニアとしては、情報セキュリティ対策における不正アクセスの防止機能を重視しなければならない。そのためには、システム設計段階から、識別コードやパスワードによる本人確認、パスワードが外部に漏れたときのことを考慮した有効期限の設定、定期的なパスワードの変更などの機能を組み込んでおく必要がある。また、重要なファイルや伝送情報の暗号化、各資源へのアクセス権限の設定、通信相手先確認などの機能の組込みも必要である。 　あなたが実際の開発に参画した経験に基づいて、次の設問ア〜ウに従って論述せよ。

Ｈ７−問２　システムの移行について

　旧システムから新システムへの移行を確実かつ円滑に実施することがトラブルのない本番稼働を迎える条件の一つである。移行計画は基本設計の段階で立案されるが、実際に移行を実施するに当たっては、当初の移行計画を見直し、より詳細で具体的な移行手順を策定することが必要となる。
　移行計画を見直す場合には、時間、投入可能資源、コストなどの制約条件を考慮し、移行日程、開発部門の人員配置、利用部門の協力体制、運用部門の支援体制などの移行体制を確立する。更に、新システムのバグ摘出度、レスポンスタイムやバッチ処理時間の検証、マニュアルや運用体制の整備状況、リハーサルの実施回数などをもとに本番稼働可否の判断基準を設定する。
　しかしながら、移行に当たっては、往々にして計画と現実のギャップや予測できなかった障害などによって様々な問題が発生する。それらの問題を解決して初めて本番稼働を迎えることができる。
　あなたの経験に基づいて、次の設問ア〜ウに従って論述せよ。

Ｈ７−問３　クライアントサーバシステムの構築について

　アプリケーションエンジニアの重要な役割として、現状業務の調査と分析、改善すべき問題点の洗い出しと解決策の策定がある。
　現状の業務を改善する場合、既存の情報システムの見直しが行われたり、見直しだけでは不十分な場合には、新たな情報システムの構築が行われたりする。その際、ハードウェア、ソフトウェア、通信回線などにかかわるコストの削減、開発期間の短縮、ユーザインタフェースの向上などを目的として、クライアントサーバシステムの適用がしばしば検討される。
　しかしながら、実際にクライアントサーバシステムを適用するに当たっては、ネットワークの拡大やデータの分散に伴う応答性、安全性、保守・運用の容易性など、新たな問題に直面することも多い。これらをシステム設計上、十分に考慮しながら、ユーザの要求を満足させるシステムを構築することが大切である。
　あなたの経験に基づいて、次の設問ア〜ウに従って論述せよ。

Ｈ６−問１　データ分析によるファイル設計について

　企業における情報システムの役割はますます重要になっており、そこで扱うデータは多種多様になってきている。ユーザが求めるものは、必要とする情報をタイムリーに提供する情報システムである。そのような情報システムの実現には、データを資源として共有化し、適切に取り出せるようなファイル構造が必要である。このような構造のファイル設計に当たっては、データの役割を明確にし、データの独立性を考慮しつつ、データ分析を行うことが有益である。
　データ分析は、データの標準化に始まり、属性の決定、第1次から第3次までの正規化などの手順で行われる。
　このような手順で、最適解としてのファイル構造が導き出される。しかし、現実には業務特性からの問題、機器構成などがもたらす技術的制約などによって、理想的な最適解をそのまま採用できないことが多く、その矛盾を解決しながらファイル設計を進めることが重要になる。
　あなたの経験に基づいて、設問ア〜ウに従って論述せよ。

Ｈ６−問２　ユーザの特性を考慮したヒューマンインタフェース設計について

　人とコンピュータとの間のインタフェース技術は大きく発展してきている。従来のコマンド応答や汎用ディスプレイ端末で、文字を主体に構成された画面応答インタフェースから、GUI、マルチウィンドウ、音声などを駆使したインタフェースへと多様化してきている。
　アプリケーションエンジニアとしては、これらの高度な技術を利用して、より使いやすいインタフェースを実現することが重要である。しかし、ただやみくもに新しい技術を盛り込んでも、よいインタフェースが実現できるとは限らない。
　例えば、コンピュータに接する機会の少ないユーザには、きめ細かなメニューや音声によるガイダンス又はポップアップ画面による解説などは分かりやすく有益である。しかし熟練したユーザにはかえってわずらわしい存在となることもある。したがって、よいインタフェース設計を行うには、ユーザの特性を分析し、ユーザの習熟度、利用頻度、取り扱うデータの種類などを正しく把握して、最も適切なヒューマンインタフェースを選択する必要がある。
　あなたが開発に参画したシステムにおいて、どのような点を考慮して、ユーザの特性に応じたインタフェース技術を選択・決定し、さらに設計上どのような工夫をしたのか、あなたの経験に基づいて設問ア〜ウに従って論述せよ。

Ｈ６−問３　デザインレビューによるユーザニーズの確認について

　ビジネス環境の変化や情報技術の進歩を背景に、システムに対するユーザニーズはますます複雑化・高度化してきている。
　ユーザニーズに適合したシステムを提供するためには、システム分析・要求定義・外部設計の各フェーズでレビュー工程を設定し、ユーザニーズがそのシステムの設計に的確に反映されていることを確認する必用がある。
　デザインレビューは、これらの各フェーズで作り出される成果物を通して、機能、性能、操作性、信頼性、安全性、運用、保守、移行などの設計がユーザニーズに合っているか、いかに実現されているかをチェックするために実施される。また、ヒューマンインタフェースや性能を評価するには、ドキュメントのレビューだけでは限界があるため、これを補うものとしてプロトタイピングによる評価方法なども用いられる。
　デザインレビューを成功させるためのポイントとしては、次のような事項が挙げられる。

• ユーザと開発部門とが共通の認識をもてるようなドキュメントを作成する。
• 目的に合わせたレビュー方法を選択する(ウォークスルー、インスペクション、ラウンドロビンなど)。
• ユーザと開発部門が一体となった共同作業を実施する。

設問ア	あなたが開発に参画したシステムについて、ユーザニーズの特徴とそのシステムの概要を、800字以内で述べよ。
設問イ	あなたはユーザニーズの実現度合いをチェックするために、どのフェーズのレビューを最も重視し、どのような方法でレビューを実施したのか。レビューを効率的・効果的に実施するために工夫した点を中心に具体的に述べよ。
設問ウ	レビューの結果(指摘された誤り、不明点、改善点など)に関して、どのようにフォローアップしたか、具体的に述べよ。
	論文例　 論文例