平成１７年度　問３　アプリケーションパッケージなどを利用したシステム構築について,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,　新規事業の立ち上げや新会社の設立などで、会計・販売・人事などの業務システムを短期間に構築しなければな,,,,,,,,,,,,,,,,,, ,らない場合がある。この場合、全システムを新規に開発するのではなく、グループ会社で実績のある既存システムを,,,,,,,,,,,,,,,,,, ,導入して業務ごとに組み合わせたり、業務に対する適合性が高いと判断したアプリケーションパッケージ(以下、パッ,,,,,,,,,,,,,,,,,, ,ケージという）を新たに導入して、既存のシステムと組み合わせたりすることがある。,,,,,,,,,,,,,,,,,, ,　例えば、会計システムには新規事業や新会社の業務に対する適合性が高いパッケージを新たに導入し、販売シス,,,,,,,,,,,,,,,,,, ,テムや人事システムには業務プロセスや制度などが類似しているグループ会社の既存のシステムを利用する場合,,,,,,,,,,,,,,,,,, ,がある。,,,,,,,,,,,,,,,,,, ,　このような場合、システムアーキテクトは次のような点に着目し、システムを構築することが重要である。,,,,,,,,,,,,,,,,,, ,,・,業務間の連携が損なわれないようにすること,,,,,,,,,,,,,,,, ,,・,システム間のデータの整合性が失われないようにすること,,,,,,,,,,,,,,,, ,,・,パッケージや既存のシステムの仕様に合わせて業務プロセスを変更すること,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,設問ア,,,あなたが開発に携わったシステムの概要と、パッケージや既存のシステムを組み合わせて、短期間にシス,,,,,,,,,,,,,,, ,,,,テムを構築しなければならなかった背景について、800字以内で述べよ。,,,,,,,,,,,,,,, ,設問イ,,,設問アで述べたシステム構築において、あなたはパッケージや既存のシステムを組み合わせて、どのよう,,,,,,,,,,,,,,, ,,,,にシステムを構築したか。あなたが特に重要と考え、工夫した点を中心に、800字以上1600字以内で具体,,,,,,,,,,,,,,, ,,,,的に述べよ。,,,,,,,,,,,,,,, ,設問ウ,,,設問イで述べたシステム構築について、あなたはどのように評価しているか。また、今後、改善したい点は,,,,,,,,,,,,,,, ,,,,何か。600字以上1200字以内で、それぞれ簡潔に述べよ。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ■解説,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,■出題趣旨,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　新規事業の立ち上げや新会社の設立などで、会計・販売・人事などの業務システムを短期間に構築しなければ,,,,,,,,,,,,,,,,, ,,ならない場合、新規システムの開発を極力避けて、業務に対する適合性が高いアプリケーションパッケージを新,,,,,,,,,,,,,,,,, ,,たに導入したり、グループ会社で実績のある既存のシステムと組み合わせたりして、システムを構築することがあ,,,,,,,,,,,,,,,,, ,,る。,,,,,,,,,,,,,,,,, ,,　このような場合、業務間の連携、システム間のデータの整合性、パッケージや既存システムの仕様に合わせた,,,,,,,,,,,,,,,,, ,,業務プロセスの変更の観点で検討を行うことが重要である。,,,,,,,,,,,,,,,,, ,,　本問は、このような検討結果をどのように反映してシステムを構築したか、工夫した点を具体的に論述すること,,,,,,,,,,,,,,,,, ,,を求めている。,,,,,,,,,,,,,,,,, ,,　本問では、論述を通じて、アプリケーションエンジニアに必要な業務分析力、パッケージ活用経験、システム間,,,,,,,,,,,,,,,,, ,,連携に関する設計能力、経験を評価する。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,■問題の読み方,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,▲,本問は、珍しく問題全体の説明がありません。その代わりに例が書かれています。アプリケーションパッケー,,,,,,,,,,,,,,,, ,,,ジは、会計・販売・人事に限らず、業務システムならば何でも構いません。,,,,,,,,,,,,,,,, ,,★,最後の”～場合がある”に注目してください。この表現は”単なる例を示しています。これに沿わなくても減点さ,,,,,,,,,,,,,,,, ,,,れません”と解釈してください。したがって、必ずしも”会計システムに、新規事業や新会社の業務に対する適,,,,,,,,,,,,,,,, ,,,合性が高いパッケージを新たに導入する”内容にしなくても構いません。●の最後の”～ことがある”も、”～,,,,,,,,,,,,,,,, ,,,場合がある”と同様の表現であり、単なる例示を示しており、拘束力はありません。,,,,,,,,,,,,,,,, ,,・,これに対し、◆の最後の”～が重要である”は、”これに沿わないと減点します”という採点基準を示す強い表,,,,,,,,,,,,,,,, ,,,現です。,,,,,,,,,,,,,,,, ,,■,2つの業務名を書きます。そうでないと業務間の連携をかけません。,,,,,,,,,,,,,,,, ,,▼,2つのシステム名を書きます。そうでないとシステム間の整合性が書けません。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,■論文構成（解答下書き）,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,（設問ア）,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,１．私が開発に携わったシステムの概要,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,・,K社は、北日本の地方都市を中心に約150店舗を運営するスーパマーケット,,,,,,,,,,,,,, ,,,,・,K社と同じ商圏を持つ競合他社は、ネットスーパ事業の開始を検討,,,,,,,,,,,,,, ,,,,・,K社の経営者層は、ネットスーパ事業への参入とNシステムの開発を決定,,,,,,,,,,,,,, ,,,,・,私は、システムアーキテクトである設計チームリーダ,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,２．短期間のシステム構築が必要となった背景,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,・,ネットスーパ事業の売上高が損益分岐点を超えるには、試行錯誤を伴う,,,,,,,,,,,,,, ,,,,・,K社の経営者層は、以下の経営方針を採用,,,,,,,,,,,,,, ,,,,,,①：約30店舗はNシステムの本番稼働時期に、ネットスーパを開始,,,,,,,,,,,,, ,,,,,,②：4か月後に、①の店舗の損益状況を分析,,,,,,,,,,,,, ,,,,,,③：残った店舗のうち、収益性が見込める店舗だけ、ネットスーパを開始,,,,,,,,,,,,, ,,,,・,各店舗のネットスーパ事業に関わる損益計算書が必要,,,,,,,,,,,,,, ,,,,・,旧会計システムは、店舗別事業別の損益計算書を出力できない,,,,,,,,,,,,,, ,,,,・,Nシステムの設計、既存システムの改造、新会計システムの短期間構築,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,（設問イ）,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,１．私が実行したシステム構築手法,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,・,Nシステムの開発工数は約80人月、新会計システムの開発工数は5人月程度,,,,,,,,,,,,,, ,,,,・,そこで、新会計システムをアプリケーションパッケージによって開発する,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,１．１　新会計システムの要件定義,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,・,私とR氏が、新会計システムの要件定義書を作成,,,,,,,,,,,,,, ,,,,・,その要件定義書にはK社独自の要件は含まれていない,,,,,,,,,,,,,, ,,,,・,新会計システムは、アプリケーションパッケージによって対応可能,,,,,,,,,,,,,, ,,,,・,要件定義書に最も適合しているWパッケージを選定,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,１．２　Wパッケージのカスタマイズ要件の定義,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,・,少ない開発工数を考慮して、Wパッケージのカスタマイズ要件を極小化,,,,,,,,,,,,,, ,,,,・,Wパッケージのカスタマイズ要件と優先順位を一覧表に記入,,,,,,,,,,,,,, ,,,,・,高優先順位の要件,,,,,,,,,,,,,, ,,,,,,①：売上実績情報からの自動仕訳機能,,,,,,,,,,,,, ,,,,,,②：仕入実績情報の自動仕訳機能,,,,,,,,,,,,, ,,,,,,③：スーパマーケットとネットスーパの人件費自動仕訳機能,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,２．私が特に重要と考え、工夫した点,,,,,,,,,,,,,,,, ,,,２．１　業務間連携の維持,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,・,本社の店舗設備担当者は、設備更新業務を遂行,,,,,,,,,,,,,, ,,,,・,旧会計システムでは、勘定科目の内訳を分類する補助科目コードが存在,,,,,,,,,,,,,, ,,,,・,Wパッケージには、補助科目コードがない,,,,,,,,,,,,,, ,,,,・,設備更新業務と会計業務の連携が損なわれる,,,,,,,,,,,,,, ,,,,・,Wパッケージの摘要コードの上位2桁に、旧会計システムの補助科目コード,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,２．２　システム間のデータの整合性,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,・,Wパッケージには、CSVファイルを会計仕訳として取り込むT機能有り,,,,,,,,,,,,,, ,,,,・,T機能によって、Wパッケージは、借方と貸方の合計額の一致を確認,,,,,,,,,,,,,, ,,,,・,固定資産管理システムは、T機能によって新会計システムと連携,,,,,,,,,,,,,, ,,,,・,同一CSVファイルを2度、Wパッケージに取り込んでもエラーなし,,,,,,,,,,,,,, ,,,,・,システム間のデータの整合性が損なわれる可能性あり,,,,,,,,,,,,,, ,,,,・,1週間以内に、同一の仕訳をT機能によって取り込もうとするとエラー出力,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,(設問ウ）,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,１．設問イで述べたシステム構築についての私の評価,,,,,,,,,,,,,,,, ,,,１．１　事業共通費の配賦手続きの煩雑さ,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,・,旧会計システムの共通費配賦基準は、勘定科目別補助科目別店舗別に設定,,,,,,,,,,,,,, ,,,,・,Wパッケージの共通費配賦は、勘定科目別事業別もしくは勘定科目別部門別のみ,,,,,,,,,,,,,, ,,,,・,例えば、店舗の電気代をスーパマーケットとネットスーパに配賦する場合,,,,,,,,,,,,,, ,,,,,,①：店舗別月別電気代をCSVファイルに出力,,,,,,,,,,,,, ,,,,,,②：①のCSVファイルの電気代を、面積を基準にして按分,,,,,,,,,,,,, ,,,,,,③：②の電気代を振替仕訳に置き換え、T機能によって取り込む,,,,,,,,,,,,, ,,,,・,これらの作業に毎月1日程度の工数　→　新システムの機能改善要望,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,１．２　年次決算処理において出力されたエラー,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,・,年次決算において、CSVファイルの取り込み時にエラー出力,,,,,,,,,,,,,, ,,,,・,原因は（借方）固定資産除去損（貸方）設備備品のような同一年次仕訳,,,,,,,,,,,,,, ,,,,・,経理担当者は、エラーになった仕訳を、振替伝票画面から手入力,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,２．今後、改善したい点,,,,,,,,,,,,,,,, ,,,２．１　事業共通費の配賦手続きの煩雑さ,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,・,経理担当者の作業不可よりも、それに付随して発生する誤りを懸念,,,,,,,,,,,,,, ,,,,・,保守時対応として、以下の設計,,,,,,,,,,,,,, ,,,,,,①：指定された事業共通費を集計する,,,,,,,,,,,,, ,,,,,,②：設定された配賦基準マスタに従って、事業別配賦する仕訳を作成,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,２．２　年次決算処理において出力されたエラー,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,・,年次決算時に、同一店舗内で2以上の設備備品の廃棄は、正常な処理,,,,,,,,,,,,,, ,,,,・,以下の変更を実施,,,,,,,,,,,,,, ,,,,,,①：T機能の同一仕訳判定条件に”摘要名”を追加,,,,,,,,,,,,, ,,,,,,②：CSVファイルの”摘要名”に廃棄する固定資産番号を設定,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ■解答例,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,（設問ア）,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．私が開発に携わったシステムの概要,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　K社は、北日本の地方都市を中心に約150店舗を運営するスーパマーケットである。その当時、大手のスーパマ,,,,,,,,,,,,,,,,, ,,ーケットは、インターネットで注文を受け付けて、店舗から顧客が指定する場所に注文商品を配達するネットスー,,,,,,,,,,,,,,,,, ,,パ事業を開始していた。経済記事に特化した新聞は、K社と同じ商圏を持つ競合他社がネットスーパ事業の開始,,,,,,,,,,,,,,,,, ,,を検討している、と報じていた。K社の経営者層は、競合他社よりも先にネットスーパ事業を開始すべきだと判断,,,,,,,,,,,,,,,,, ,,した。そこで、K社の経営者層は、ネットスーパ事業への参入とそれに対応するシステム（以下、Nシステムという）,,,,,,,,,,,,,,,,, ,,の開発を決定した。私は、K社の情報システム部に所属するシステムアーキテクトであり、当システム開発プロジ,,,,,,,,,,,,,,,,, ,,ェクトの設計チームリーダに任命された。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．短期間のシステム構築が必要となった背景,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　K社の経営者層は、ネットスーパ事業の売上高が損益分岐点を超え、利益を計上できるまでには試行錯誤を伴,,,,,,,,,,,,,,,,, ,,うと考えていた。そこで、K社の経営者層は、,,,,,,,,,,,,,,,,, ,,,①,K社の約３０店舗はNシステムの本番稼働時期に合わせて、ネットスーパ事業を開始する。,,,,,,,,,,,,,,, ,,,②,Nシステムの本番稼働日から4か月後に、①の店舗の損益状況を分析する。,,,,,,,,,,,,,,, ,,,③,②の分析に基づいて、残りの約120店舗のうち、収益性が見込めると判断された店舗だけがネットスーパ,,,,,,,,,,,,,,, ,,,,事業を開始する。,,,,,,,,,,,,,,, ,,という経営方針を採用した。したがって、各店舗別のネットスーパ事業に関わる損益計算書が必要になった。しか,,,,,,,,,,,,,,,,, ,,し、当時運用されていた会計システムは、店舗別事業別の損益計算書を出力できなかった。,,,,,,,,,,,,,,,,, ,,　私は、Nシステムの設計と同時に、K社が運用してきたPOS端末を含む販売管理システム（以下、既存システム,,,,,,,,,,,,,,,,, ,,という）の改造と、新会計システムを短期間に構築しなければならなかった。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,（設問イ）,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．私が実行したシステム構築手法,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　Nシステムの開発工数は、プロジェクト計画時点で約80人月と見積もられ、新会計システムに費やせる開発工,,,,,,,,,,,,,,,,, ,,数は5人月程度と考えられた。したがって、当プロジェクトのプロジェクトマネージャは、新会計システムをアプリケ,,,,,,,,,,,,,,,,, ,,ーションパッケージによって開発することを当プロジェクトの制約条件にしていた。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．１　新会計システムの要件定義,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、新会計システムの利用者代表であるK社の経理課長R氏とともに、新会計システムの要件定義書を作成,,,,,,,,,,,,,,,,, ,,した。その要件定義書にはK社独自の要件は含まれておらず、店舗別を部門別と解釈し、事業別部門別の損益,,,,,,,,,,,,,,,,, ,,計算機能は管理会計機能の一部であると考えれば、アプリケーションパッケージによって対応可能だった。私と,,,,,,,,,,,,,,,,, ,,R氏は、要件定義書に最も適合している会計アプリケーションパッケージ（以下、Wパッケージという）を選定した。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．２　Wパッケージのカスタマイズ要件の定義,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、少ない新会計システムの開発工数を考慮して、Wパッケージのカスタマイズ要件を極小化すべきだと考え,,,,,,,,,,,,,,,,, ,,た。私は、この制限をR氏に伝達し、R氏にWパッケージのカスタマイズ要件と優先順位を一覧表に記入させた。R,,,,,,,,,,,,,,,,, ,,氏は、高優先順位の要件として、以下3点の機能を挙げた。,,,,,,,,,,,,,,,,, ,,,①,Nシステムと既存システムからの売上実績情報からの自動仕訳機能,,,,,,,,,,,,,,, ,,,②,既存システムからの仕入実績情報の自動仕訳機能,,,,,,,,,,,,,,, ,,,③,給与システムからのスーパマーケット事業とネットスーパ事業の人件費自動仕訳機能,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．私が特に重要と考え、工夫した点,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、Wパッケージを使ったシステム構築時に、下記の3点を着目し、工夫した。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．１　業務間連携の維持,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　本社の店舗設備担当者は、例えば、店舗の蛍光灯をLED照明に変更した場合の電気代の減少傾向を比較しな,,,,,,,,,,,,,,,,, ,,がら、照明設備時期や範囲を決定するといった設備更新業務を遂行している。電気代は、勘定科目のうちの水道,,,,,,,,,,,,,,,,, ,,光熱費の一部であり、勘定科目別に表示される損益計算書では電気代だけを把握できない。旧会計システムで,,,,,,,,,,,,,,,,, ,,は、勘定科目の内訳を分類する補助科目コードが存在した。,,,,,,,,,,,,,,,,, ,,　しかし、Wパッケージにはそれがなかったので設備更新業務と会計業務の連携が損なわれそうだった。,,,,,,,,,,,,,,,,, ,,　そこで私は、Wパッケージの摘要コードが6桁ある点に着目し、その上位2桁に旧会計システムの補助科目コー,,,,,,,,,,,,,,,,, ,,ドを充てるコード体系変更をした。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．２　システム間のデータの整合性,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　Wパッケージは、CSV（Comma Separated Values）ファイルのデータを会計仕訳として取り込む機能（以下、T機,,,,,,,,,,,,,,,,, ,,能という）を保有している。T機能によってCSVファイルのデータが取り込まれるとき、Wパッケージは、1つの仕訳,,,,,,,,,,,,,,,,, ,,の借方金額と貸方金額の合計額の一致を確認する。例えば、固定資産管理システムが出力する減価償却費仕,,,,,,,,,,,,,,,,, ,,訳は、T機能によって新会計システムにデータ連携され、データの整合性が保証される。しかし、T機能によって同,,,,,,,,,,,,,,,,, ,,一CSVファイルを2度、Wパッケージに取り込んでもエラーメッセージは出力されずシステム間のデータの整合性,,,,,,,,,,,,,,,,, ,,が損なわれる可能性があった。,,,,,,,,,,,,,,,,, ,,　そこで私は、1週間以内に｛借方事業コード、貸方事業コード、借方勘定科目コード、貸方勘定科目コード、借方,,,,,,,,,,,,,,,,, ,,部門コード、貸方部門コード、金額、日付｝が同一の仕訳をT機能によって取り込もうとするとエラーメッセージを出,,,,,,,,,,,,,,,,, ,,力して、当該仕訳データを取り込まなくする機能を追加した。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,（設問ウ）,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．設問イで述べたシステム構築についての私の評価,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私が実行したシステム構築手法やその工夫は、有効に機能し、Nシステム及び新会計システムは順調に稼働し,,,,,,,,,,,,,,,,, ,,ている。その意味では、私は正しいシステム構築を実施したと評価できる。しかし、下記の2つには不十分な点が,,,,,,,,,,,,,,,,, ,,あり、改良の余地があると考えられる。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．１　事業共通費の配賦手続きの煩雑さ,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　旧会計システムの共通費配賦基準は、勘定科目別補助科目別店舗別に設定できた。しかし、Wパッケージの共,,,,,,,,,,,,,,,,, ,,通費配賦は、勘定科目別事業別もしくは勘定科目別部門別にしか設定できない。そこで、例えば、使用面積を配,,,,,,,,,,,,,,,,, ,,賦基準にして、店舗の電気代をスーパマーケット事業とネットスーパ事業に配賦しようとする場合、,,,,,,,,,,,,,,,,, ,,,①,｛勘定科目コード、摘要コード｝と店舗番号を指定して、その店舗別月別電気代をCSVファイルに出力する。,,,,,,,,,,,,,,, ,,,②,①のCSVファイルを表計算ソフトウェアに読み込み、面積を基準にして電気代を按分する。,,,,,,,,,,,,,,, ,,,③,②の按分された電気代を振替仕訳に置き換え、T機能によって新会計システムに取り込む。,,,,,,,,,,,,,,, ,,　本社の経理担当者は、これらの作業に毎月1日程度の工数を費やしていたので、新システムの機能改善を要,,,,,,,,,,,,,,,,, ,,望した。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．２　年次決算処理において出力されたエラー,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　年次決算において、経理担当者がT機能を使って、CSVファイルを取り込もうとすると、エラーメッセージが数検,,,,,,,,,,,,,,,,, ,,出力された。このエラーメッセージは、設問イの２．２で述べた追加機能によって出力されたものだった。,,,,,,,,,,,,,,,,, ,,　私が調査してみると、その原因は、（借方）固定資産除去損（貸方）設備備品のような同一の年次仕訳データを,,,,,,,,,,,,,,,,, ,,複数取り込んだためだった。経理担当者は、やむなく、エラーメッセージが出力された仕訳10件を、振替伝票画面,,,,,,,,,,,,,,,,, ,,から手入力した。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．今後、改善したい点,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は上記の評価に対し、以下の改善を実行する。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．１　事業共通費の配賦手続きの煩雑さ,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、経理担当者の作業負荷よりも、それに付随して発生する誤りを懸念する。そこで、私は保守時対応として,,,,,,,,,,,,,,,,, ,,、以下の設計を行う。,,,,,,,,,,,,,,,,, ,,,①,指定された｛勘定科目コード、摘要コードの上位2桁｝をキーにして、事業共通費を集計する。,,,,,,,,,,,,,,, ,,,②,設定された配賦基準マスタにしたがって、①の集計金額をスーパマーケット事業とネットスーパ事業に配賦,,,,,,,,,,,,,,, ,,,,する仕訳を作成する。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．２　年次決算処理において出力されたエラー,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　年次決算時に、同一店舗内で2以上の設備備品を廃棄することは、正常な処理である。そこで、私は以下の変,,,,,,,,,,,,,,,,, ,,更を実施する。,,,,,,,,,,,,,,,,, ,,,①,T機能の同一仕訳判定条件に”摘要名”を追加する。,,,,,,,,,,,,,,, ,,,②,経理担当者に対し、作成するCSVファイルの”摘要名”に廃棄する固定資産番号を設定する依頼をする。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, 平成１８年度　問１　システム要件の確定について,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,　通常、システム要件定義において、アプリケーションエンジニアはユーザから提示された業務要件に基づいて、シ,,,,,,,,,,,,,,,,,, ,ステム要件を確定させる作業を行う。この作業の中で、システム化の規模が明らかに予定を上回っていたり、技術,,,,,,,,,,,,,,,,,, ,的難易度が高すぎたり、システム化によって得られる効果が目標よりも小さかったりする課題が発生することがある,,,,,,,,,,,,,,,,,, ,。このような課題が発生した場合、課題の解決に向けて、アプリケーションエンジニアはユーザに積極的に提案を行,,,,,,,,,,,,,,,,,, ,い、双方が納得できる内容でシステム要件を確定させることが重要である。,,,,,,,,,,,,,,,,,, ,　その際、ユーザに対して、例えば、次のようなアプローチを通して提案を行う。,,,,,,,,,,,,,,,,,, ,,・,業務要件に基づくシステム化範囲やシステム化規模を可視化したり、参考となるシステムと比較したりして、ユ,,,,,,,,,,,,,,,, ,,,ーザにシステムの全体概要を確認してもらい、システム化規模を予定の範囲に収める。,,,,,,,,,,,,,,,, ,,・,アルゴリズムや条件の複雑さをユーザに分かりやすく示すことによって、技術的難易度を説明し、簡素化した,,,,,,,,,,,,,,,, ,,,システム要件を提案する。,,,,,,,,,,,,,,,, ,,・,業務要件のシステム化によって得られる効果の大きさについて論理的に説明し、効果が小さい業務要件につ,,,,,,,,,,,,,,,, ,,,いては、ユーザに再検討を依頼する。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,設問ア,,,あなたが開発に携わったシステムの概要と、システム要件の確定において発生した課題について、800字,,,,,,,,,,,,,,, ,,,,以内で述べよ。,,,,,,,,,,,,,,, ,設問イ,,,設問アで述べた課題の解決に向けて、あなたはユーザに対してどのようなアプローチを行い、どのような提,,,,,,,,,,,,,,, ,,,,案をしたか。特に重要と考えた点を中心に、具体的に述べよ。,,,,,,,,,,,,,,, ,設問ウ,,,設問イで述べた提案について、あなたはどのように評価しているか。また、今後改善したい点は何か。それ,,,,,,,,,,,,,,, ,,,,ぞれ簡潔に述べよ。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ■解説,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,■出題趣旨,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　システム要件定義において、システム化の範囲や規模が、明らかに予定を超えてしまったり、技術的難易度が,,,,,,,,,,,,,,,,, ,,高すぎたり、システム化の効果が目標より小さかったりする課題が発生することがある。このような場合、アプリ,,,,,,,,,,,,,,,,, ,,ケーションエンジニアは、ユーザ及び開発サイド双方が納得できるシステム要件を設定するための提案を、,,,,,,,,,,,,,,,,, ,,ユーザに対して行うことが重要である。,,,,,,,,,,,,,,,,, ,,　本問は、システム要件の確定において、発生した課題をどのように認識し、その課題をどのように解決したかを,,,,,,,,,,,,,,,,, ,,具体的に論述することを求めている。,,,,,,,,,,,,,,,,, ,,　本問では、論述を通じて、アプリケーションエンジニアに必要なシステム要件定義の能力を経験を評価する。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,■採点講評,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　問１（システム要件の確定について）は、多くの受験者がシステム要件の確定作業を経験しているからか、選択,,,,,,,,,,,,,,,,, ,,率が最も高かった。システム要件を確定するために、ユーザに対してどのようなアプローチを行い、どのような,,,,,,,,,,,,,,,,, ,,提案をしたかについて論述することを期待したが、題意と異なり、設計や実装での解決策についての論述が,,,,,,,,,,,,,,,,, ,,おおかった。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ■論述例,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．１　開発に携わったシステムの概要,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　論述の対象とするシステムは、工業用重機販売会社A社の販売管理システムである。,,,,,,,,,,,,,,,,, ,,　A社では、10年前より販売管理システムを稼働させていたが、最近、利用者からの変更要求に対して、システム,,,,,,,,,,,,,,,,, ,,上の制約で実現できないケースが多くなっていた。そこで今回、環境変化にも柔軟に対応できるシステムに刷新,,,,,,,,,,,,,,,,, ,,することになった。,,,,,,,,,,,,,,,,, ,,　今回再構築するシステム化の範囲は、受注・売上・請求・入金・発注・購買・支払などの一連の管理業務から、,,,,,,,,,,,,,,,,, ,,財務会計、在庫管理業務になる。東京にある本社にサーバを配置し、全国の営業所に設置されているパソコン,,,,,,,,,,,,,,,,, ,,（200台）からインターネットVPN経由でアクセスさせる。保守性を考慮して、システムへのアクセスはWebブラウザ,,,,,,,,,,,,,,,,, ,,を使う。,,,,,,,,,,,,,,,,, ,,　ちなみに私は、名古屋にあるSIベンダに勤務しているシステムエンジニアだが、わが社がこのA社販売管理シス,,,,,,,,,,,,,,,,, ,,テムを開発することになり、チームリーダとして参画することになった。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．２　発生した課題,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　プロジェクトが立ち上がり、システム要件定義工程で問題が発生した。全国の営業所の代表者から、今回のシ,,,,,,,,,,,,,,,,, ,,ステム化に関するヒアリングが一巡したので開発工数を試算したところ、当初想定していた100人月の予算を大,,,,,,,,,,,,,,,,, ,,幅に上回り120人月になった。,,,,,,,,,,,,,,,,, ,,　予想を大幅に上回った原因は、ユーザインタフェース部分に対する要望を予測していなかったことである。,,,,,,,,,,,,,,,,, ,,元々100人月という見積もりは、これまで現場から上がってきていた要望のうち、実現できなかった機能を実装す,,,,,,,,,,,,,,,,, ,,ると仮定して積算したもので、ユーザインタフェースについては、契約に至るまでの提案段階では、話題にならな,,,,,,,,,,,,,,,,, ,,かったので、深く詰めていなかった。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．１　課題の解決に向けたアプローチ,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　最近は、誰もが普通にパソコンを使う。しかもインターネット上のサイトには、高度な技術を使った興味深いユー,,,,,,,,,,,,,,,,, ,,ザインタフェースが色々ある。A社のシステムを利用する人たちも、そういうところに目の肥えた人がいて、かなり,,,,,,,,,,,,,,,,, ,,複雑で高度な操作性を要求してくる人がいた。しかし我々は、提案段階では旧システムと同等程度の操作性を想,,,,,,,,,,,,,,,,, ,,定しており、ユーザのとりまとめの立場であるBにしてみても想定外の要求であった。,,,,,,,,,,,,,,,,, ,,　具体的には、例えば売り上げ登録画面において得意先を入力したら、次に入力する商品コードについて入力さ,,,,,,,,,,,,,,,,, ,,れそうな候補を動的にいくつか提案して画面の端に表示し、クリックだけで入力できるようにすることで入力の手,,,,,,,,,,,,,,,,, ,,間を省くような機能が欲しいというような、動的に入力を補助する要望が、数人の利用者からそれぞれの業務の,,,,,,,,,,,,,,,,, ,,画面ごとに出されていた。,,,,,,,,,,,,,,,,, ,,　しかしながら、これらの要望をすべて実現すると、試算からは20人月という大幅な費用超過が予想されるうえ、,,,,,,,,,,,,,,,,, ,,技術的難易度も高く、製造時に不具合が作りこまれ、品質低下につながる可能性もある。また、全てを実現すれ,,,,,,,,,,,,,,,,, ,,ば確かに入力は早くなるものの、実際に短縮される時間は短く、効果が低いことが予想された。,,,,,,,,,,,,,,,,, ,,　そこで私はまず、動的な入力補助を実現した場合の工数と、キーボード入力や、全てのマスたちの中からプル,,,,,,,,,,,,,,,,, ,,ダウンで選択するといったこれまで通りの操作性を実現した場合の工数について、先行して詳細見積もりを実施,,,,,,,,,,,,,,,,, ,,し、詳細な作業ごとに工数を一覧化して資料にまとめた。,,,,,,,,,,,,,,,,, ,,　また、動的な入力補助によってどの程度の操作時間短縮が見込めるのかを算出するため、旧システムの利用,,,,,,,,,,,,,,,,, ,,ログから、各画面の利用頻度を確認した。これに1画面ごとの想定短縮時間をかけ合わせることで、想定される短,,,,,,,,,,,,,,,,, ,,縮時間を算出し、それらを資料にまとめていった。,,,,,,,,,,,,,,,,, ,,　これによって費用対効果を根拠とともに明示することができ、要望を見直す必要があることを論理的に説明でき,,,,,,,,,,,,,,,,, ,,ると考えた。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．２　ユーザに対しての提案,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　作成した資料を基に、B氏と打ち合わせを実施し、費用と効果について具体的な数字とその根拠を提示していっ,,,,,,,,,,,,,,,,, ,,た。,,,,,,,,,,,,,,,,, ,,　要望通り全ての画面に動的入力補助機能を実現した場合と、旧システムと同等の操作性を実現した場合の工,,,,,,,,,,,,,,,,, ,,数の差はトータルで約30人月であり、対して、短縮される時間の想定値は、前ユーザ、全画面の合計でも年間約,,,,,,,,,,,,,,,,, ,,1人月程度であった。つまり、効果が出るのに30年以上かかる予定だ。,,,,,,,,,,,,,,,,, ,,　これを提示したところB氏は即座に納得し、動的な入力補助機能は実現しないことを決意していただいた。,,,,,,,,,,,,,,,,, ,,　しかし、要望を実際に出してきた利用者に対しても実現しないことを伝え、代替案であるこれまで同等の操作性,,,,,,,,,,,,,,,,, ,,を実現する案を提案し、了承してもらう必要があった。,,,,,,,,,,,,,,,,, ,,　そこでB氏に提示した資料を簡易にまとめた資料を作成した上で、B氏とプロジェクトマネージャに掛け合い、A,,,,,,,,,,,,,,,,, ,,社側の経営陣のレベルで、動的入力補助機能は実現しないことを決めていただいた。,,,,,,,,,,,,,,,,, ,,　その決定の事実とともに、要望を出してきた利用者たちに順番に代替案を提案していったところ、代替案でも業,,,,,,,,,,,,,,,,, ,,務が止まることはなく、費用対効果が出ないならば確かに会社としては代替案の方が良いだろうと、全員に納得,,,,,,,,,,,,,,,,, ,,していただく事ができた。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,３．１　提案に対する評価,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　今回私が採用した費用対効果を根拠とともに明示して論理的に説明するアプローチは、操作性が向上して便利,,,,,,,,,,,,,,,,, ,,になるといった曖昧な効果が費用に見合った内容になっているかどうかを明確にし、素早く適切な判断がA社内,,,,,,,,,,,,,,,,, ,,でなされたことから、成功であったと評価している。,,,,,,,,,,,,,,,,, ,,　また、要求を出してきた利用者たちへの提案時に、あらかじめA社経営陣の了承を得て、A社としてどちらの判,,,,,,,,,,,,,,,,, ,,断が望ましいかを明確にしたうえで代替案を提示したことにより、B氏や我々が一方的に利用者に代替案を押し,,,,,,,,,,,,,,,,, ,,付ける形にはならず、利用者としても納得した形で要件定義を終えられたことが、その後のテストなどの協力を得,,,,,,,,,,,,,,,,, ,,ていくという意味でも効果的であったと判断している。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,３．２　今後の改善点,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　今回、費用対効果を算出するために、動的な入力補助を実施するとした場合の詳細見積もりを実施したが、高,,,,,,,,,,,,,,,,, ,,度な技術が必要となる内容であまり経験がないこともあり、見積もり自体にも2週間、約1人月を費やしてしまった,,,,,,,,,,,,,,,,, ,,。,,,,,,,,,,,,,,,,, ,,　インターネット上に高度なユーザインタフェースがあふれている現状から考えると、今後のシステム開発におい,,,,,,,,,,,,,,,,, ,,ても、エンドユーザへのヒアリングを実施すると同様の要望が出てくる可能性が高い。よって、今回の見積り内容,,,,,,,,,,,,,,,,, ,,を活かすことで、今後はより短時間に費用対効果を算出できるよう、見積もり資料を共有し、自社内で活かしてい,,,,,,,,,,,,,,,,, ,,きたい。,,,,,,,,,,,,,,,,, ,,　また、現場利用者にとってのユーザインタフェースの重要性を少々軽く見ていたところは否定できない。特にA社,,,,,,,,,,,,,,,,, ,,のようにスクラッチ開発をしてきた企業はなおさらだ。次回のシステム構築の時には、そのあたりを加味してしっ,,,,,,,,,,,,,,,,, ,,かりと要件定義フェーズに対応する計画を立てた上で挑みたい。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, 平成１８年度　問３　移行計画におけるタイムチャートの事前確認について,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,　基幹系システムのように、ほかのシステムとのインタフェースが多岐にわたり、データの種類や量が多いシステム,,,,,,,,,,,,,,,,,, ,の場合は、システム移行に多くのシステム資源を必要としたり、作業時間が長くなったり、作業手順が複雑になった,,,,,,,,,,,,,,,,,, ,りする。このような移行に当たっては、計画したタイムチャート通りの時間や手順で実施できるかどうかを、事前に確,,,,,,,,,,,,,,,,,, ,認しておくことが重要である。,,,,,,,,,,,,,,,,,, ,　その際、本番のシステム移行時と同じシステム資源を用いて、同じタイムチャートで実施することが望ましいが、使,,,,,,,,,,,,,,,,,, ,用できるシステム資源や作業時間の制約から、本番通りには実施できない場合がある。そのような場合には、ほか,,,,,,,,,,,,,,,,,, ,のシステムや後続作業への影響の大きさ、移行データの種類や量の多さ、各種機器の切り替え手順の複雑さなど,,,,,,,,,,,,,,,,,, ,に着目して、タイムチャートのクリティカルな部分を見極め、例えば、次のようないくつかの方法を組み合わせて、クリ,,,,,,,,,,,,,,,,,, ,ティカルな部分が計画通りに実施できることを確認する必要がある。,,,,,,,,,,,,,,,,,, ,,・,開発用のシステム資源を用いて作業を行い、その結果から類推する。,,,,,,,,,,,,,,,, ,,・,一部の本番データを用いて作業を行い、その結果から類推する。,,,,,,,,,,,,,,,, ,,・,本番と同じ切り替え手順を用いてシミュレーションを行い、その結果から類推する。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,設問ア,,,あなたが移行に携わったシステムの特徴と、移行計画の概要について、800字以内で述べよ。,,,,,,,,,,,,,,, ,設問イ,,,設問アで述べた移行計画のタイムチャートにおけるクリティカルな部分は何か。クリティカルと見極めた理,,,,,,,,,,,,,,, ,,,,由とともに簡潔に述べよ。また、本番のシステム移行時に、クリティカルな部分が計画通りに実施できること,,,,,,,,,,,,,,, ,,,,を、事前にどのように確認したか。特に工夫した点を中心に、具体的に述べよ。,,,,,,,,,,,,,,, ,設問ウ,,,設問イで述べた確認方法について、あなたはどのように評価しているか。また、今後改善したい点は何か。,,,,,,,,,,,,,,, ,,,,それぞれ簡潔に述べよ。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ■解説,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,■出題趣旨,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　基幹系システムのように、他システムとのインタフェースが多岐にわたり、移行データの種類や量が多い場合は,,,,,,,,,,,,,,,,, ,,、多くのシステム資源を必要としたり、作業時間が長くなったり、移行手順が複雑になったりする。このため、計画,,,,,,,,,,,,,,,,, ,,したタイムチャートどおりに移行できるかを事前に確認しておく必要がある。しかしながら、移行作業について、本,,,,,,,,,,,,,,,,, ,,番の移行時と同じ環境、同じ手順、同じタイムチャートで確認を行うことは、資源的、時間的制約から難しい場合,,,,,,,,,,,,,,,,, ,,がある。このため、タイムチャートのクリティカルな部分を見極め、移行作業が計画通りに実施できることを事前に,,,,,,,,,,,,,,,,, ,,確認する方法を工夫することが求められる。,,,,,,,,,,,,,,,,, ,,　本問は、タイムチャートのクリティカルな部分について、どのように見極め、本番のシステム移行作業の実現可,,,,,,,,,,,,,,,,, ,,能性を事前にどのように確認したかについて具体的に論述することを求めている。,,,,,,,,,,,,,,,,, ,,　本問では、論述を通じて、アプリケーションエンジニアに必要なシステム移行計画の立案における分析・設計能,,,,,,,,,,,,,,,,, ,,力と経験を評価する。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,■採点講評,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　問３（移行計画におけるタイムチャートの事前確認について）では、多くの受験者が移行計画策定や移行作業を,,,,,,,,,,,,,,,,, ,,経験していることがうかがえた。策定したタイムチャートにおけるクリティカルな部分の見極めと、その事前確認に,,,,,,,,,,,,,,,,, ,,おいて工夫した点を論述することを期待したが、題意と異なり、移行データ量や作業時間の見積り、移行データ不,,,,,,,,,,,,,,,,, ,,備への対応策など、移行計画の内容に終始する論述が多かった。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ■解答例,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．１　移行に携わったシステムの特徴,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　今回、論文の対象とするシステムは、産業用セラミック製品などを製造・販売しているA社における人事・給与計,,,,,,,,,,,,,,,,, ,,算システムである。数年前に、当該システムの再構築を行ったが、その作業を担当したのが、SIベンダB社に所,,,,,,,,,,,,,,,,, ,,属する私だった。担当フェーズは、要件定義工程からシステムテスト、移行完了まで。システムアーキテクトの立,,,,,,,,,,,,,,,,, ,,場での参画となった。,,,,,,,,,,,,,,,,, ,,　再構築する人事・給与計算システムは、前システムの時から、他のシステムとのデータ交換が非常に多い。相,,,,,,,,,,,,,,,,, ,,手先システムは、財務会計システムや販売管理システム、生産管理システムなどの基幹系システムから、アカウ,,,,,,,,,,,,,,,,, ,,ント管理システムのような重要システム、交通費計算システムのような付随的なシステムまで、交換先は大小重,,,,,,,,,,,,,,,,, ,,軽多岐にわたる。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．２　システム移行計画の概要,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　今回は、このうち移行計画について論述する。移行作業は、納品前日の4日間（96時間）を使用して実施。,,,,,,,,,,,,,,,,, ,,今回は、ハードウェアもリプレイスするので、新サーバへのデータ移行が主要作業になる（具体的な作業内容と想,,,,,,,,,,,,,,,,, ,,定時間は下記参照）。,,,,,,,,,,,,,,,,, ,,,①,新サーバへの現地搬入・設定作業,,,,,,,,,,,,,,：,事前実施 ,,,②,旧サーバからのデータエクスポート,,,,,,,,,,,,,,：,8時間 ,,,③,新サーバへのデータのインポート,,,,,,,,,,,,,,：,12時間 ,,,④,上記結果の確認（チェック）,,,,,,,,,,,,,,：,24時間 ,,,⑤,他システムの連携先変更・接続試験,,,,,,,,,,,,,,：,8時間 ,,,⑥,他システムからのデータ取込み,,,,,,,,,,,,,,：,12時間 ,,,⑦,上記結果の確認（チェック）,,,,,,,,,,,,,,：,24時間 ,,,⑧,余裕時間（予備、バッファ）,,,,,,,,,,,,,,：,8時間 ,,　また、移行作業は、B社の要員16名で実施する。上記①から⑦までで、リスクに配慮して並行作業は考えていな,,,,,,,,,,,,,,,,, ,,い。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．１　移行計画のタイムチャートにおけるクリティカルな部分,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　今回の移行作業の余裕時間の割合は、全体の時間の10％以下である。したがって、少しの見積り時間のブレ,,,,,,,,,,,,,,,,, ,,があると移行は終了しない。そこで私は、移行計画におけるタイムチャートを事前確認することにした。,,,,,,,,,,,,,,,,, ,,　本来なら、移行本番時と全く同じ4日間16人体制で実施するべきかもしれないが、与えられた工数は3人日（3人,,,,,,,,,,,,,,,,, ,,で1日の作業を実施）。その工数の中で見極めるようにプロジェクトマネージャからは指示された。その工数で,,,,,,,,,,,,,,,,, ,,チェックするには、リスクが高いクリティカルな部分を見極めたうえで、その部分のシミュレーションから類推する,,,,,,,,,,,,,,,,, ,,のが最適であると考えた。,,,,,,,,,,,,,,,,, ,,　前述した移行作業の想定時間において、②③⑥のデータ移行時間は計算で求められる。問題は、人手による,,,,,,,,,,,,,,,,, ,,移行結果のチェックの部分である。④と⑦だ。ひとまずどちらも、過去の経験やデータ件数から算出しているが、,,,,,,,,,,,,,,,,, ,,その量はあまりにも多くクリティカルだと判断した。それと⑤他システムの連携先変更・接続試験も一部クリティカ,,,,,,,,,,,,,,,,, ,,ルな作業がある。切替手順が複雑なので、想定外の時間が発生する可能性があった。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．２　事前確認方法,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、3人のメンバで1日かけて移行計画の中のこれらクリティカルな部分を事前確認することとした。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,（１）データのチェック作業時間,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,　今回④と⑦の作業は、A社（顧客）側要員が不足していることから、B社（つまり私の会社）が要員を派遣して,,,,,,,,,,,,,,,, ,,,実施する（契約は、派遣契約）。その作業時間は、それぞれ24時間と見積もっている。④と⑦の作業内容も,,,,,,,,,,,,,,,, ,,,データ件数もほぼ同じなので、一人当たりの生産性も同じで考えていい。,,,,,,,,,,,,,,,, ,,,　工数は、5人×1人日（1日＝8時間で計算）×３交代制で合計15人日（120人時）。1人時あたりの確認データ,,,,,,,,,,,,,,,, ,,,件数を、1分間で5件ぐらい、すなわち300件ぐらいだろうとアバウトな想定の下での見積りである。,,,,,,,,,,,,,,,, ,,,　しかし、当然だが、チェックするテーブルの属性の数によってもばらつきはあるだろうし、15人のメンバが全員,,,,,,,,,,,,,,,, ,,,、その生産性で作業可能かどうかわからない。かなりデータの種類も量も多いので、生産性のブレが出てくる,,,,,,,,,,,,,,,, ,,,ことは間違いない。,,,,,,,,,,,,,,,, ,,,　そこで、シミュレーションで確認するファイルは、属性の多いものを中心にピックアップして、それを基準に時,,,,,,,,,,,,,,,, ,,,間をシミュレーションする。また、人選は、最も不慣れなメンバ1人と比較的慣れているメンバ1人を選び、生産,,,,,,,,,,,,,,,, ,,,性の人による違いを確認する。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,（２）他システムの連携先変更・接続試験の時間,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,　次に、もう一人が⑤の作業が8時間で完了するかどうかを確認する。,,,,,,,,,,,,,,,, ,,,　この切替作業は、サブシステムに分かれて、8人で分担して実施する。そのため切替手順もそれぞれ異なる,,,,,,,,,,,,,,,, ,,,ので、「切替手順書」も8つ作成している。ゆえに本来であれば、8人がそれぞれの「切替手順書」に基づいて、,,,,,,,,,,,,,,,, ,,,8時間かけて実施すべきである。しかし、今回の制約上、それはできない。,,,,,,,,,,,,,,,, ,,,　そこで、あらかじめレビューを十分に実施した上で、リスクの大きい順に優先順位を付けて、そこから確認す,,,,,,,,,,,,,,,, ,,,る。例えば、最も複雑でトラブルになる可能性の高い原価計算システムとの接続から順次、問題ないかどうか,,,,,,,,,,,,,,,, ,,,を確認する。なお、ここでは、人による生産性（時間）の違いを確認するのではなく、あくまでも、その切替手順,,,,,,,,,,,,,,,, ,,,書通りに滞りなく作業が進むかどうかをチェックする。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,３．１　確認方法に対する評価,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　これらのシミュレーションによる確認の結果、④と⑦では予想通り人によって６～９時間という作業時間の差があ,,,,,,,,,,,,,,,,, ,,ることが分かった,,,,,,,,,,,,,,,,, ,,　また、8人で分担する⑤の作業時間はデータ交換しているファイル数に大きく影響を受ける。ファイル数が最も大,,,,,,,,,,,,,,,,, ,,きいのは原価計算システムだったが、結果は9時間強かかった。,,,,,,,,,,,,,,,,, ,,　これらの結果から、最悪の状況で計算した場合でも、予備時間の範囲内に収まることが確認できて一安心でき,,,,,,,,,,,,,,,,, ,,たので、自信をもって顧客に受入試験の準備をしておくように伝えることができた点は良かったと考えている。顧,,,,,,,,,,,,,,,,, ,,客に安心を与えることができたからだ。,,,,,,,,,,,,,,,,, ,,　また、私自身、今回のシミュレーションで取得したデータを使って、移行作業をしている4日間、時間単位でしっか,,,,,,,,,,,,,,,,, ,,りとしたマネジメントができたと評価している。メンバの生産性やファイル数の違いを加味した上での作業割り当て,,,,,,,,,,,,,,,,, ,,をして、それに合わせてタイムチャートに見直しをかけたことで、本番の移行時には全員の作業が想定時間通り,,,,,,,,,,,,,,,,, ,,に終了し、高い精度で見積もることができたことを証明できた。,,,,,,,,,,,,,,,,, ,,　あと一つは、リハーサルとしての問題点抽出効果も認識している。今回の事前シミュレーションで出た、作業の,,,,,,,,,,,,,,,,, ,,しにくさ、マニュアルの不備等を事前に把握することができ、それを修正して移行本番に挑めた点も高く評価して,,,,,,,,,,,,,,,,, ,,いる。,,,,,,,,,,,,,,,,, ,,　以上に加えて、とにもかくにも、移行作業全体としてもほぼタイムチャート通りに完了したため、作業時間が変動,,,,,,,,,,,,,,,,, ,,しやすいクリティカルな工程を見極め、そこに3人日をかけて見積精度を上げるという判断が妥当であったと評価,,,,,,,,,,,,,,,,, ,,している。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,３．２　この後の改善点,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　今回のシミュレーションによる確認では、8時間の作業であれば疲れによる作業効率低下よりも、慣れによる作,,,,,,,,,,,,,,,,, ,,業効率向上が上回り、全体として作業効率の低下は見られないという結果が得られた。,,,,,,,,,,,,,,,,, ,,　そこで、今後別プロジェクトの移行シミュレーションで8時間以内の作業を実施する場合は、8時間の作業全てを,,,,,,,,,,,,,,,,, ,,シミュレーションするのではなく、短縮した内容を実施し、そこから全体の作業時間を見積もる方法をとることで、,,,,,,,,,,,,,,,,, ,,より効率的に作業時間の見積りを実施できないかを検討した上で、計画を立てていきたい。　以上,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, 平成１８年度　問３　移行計画におけるタイムチャートの事前確認について,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,　基幹系システムのように、ほかのシステムとのインタフェースが多岐にわたり、データの種類や量が多いシステム,,,,,,,,,,,,,,,,,, ,の場合は、システム移行に多くのシステム資源を必要としたり、作業時間が長くなったり、作業手順が複雑になった,,,,,,,,,,,,,,,,,, ,りする。このような移行に当たっては、計画したタイムチャート通りの時間や手順で実施できるかどうかを、事前に確,,,,,,,,,,,,,,,,,, ,認しておくことが重要である。,,,,,,,,,,,,,,,,,, ,　その際、本番のシステム移行時と同じシステム資源を用いて、同じタイムチャートで実施することが望ましいが、使,,,,,,,,,,,,,,,,,, ,用できるシステム資源や作業時間の制約から、本番通りには実施できない場合がある。そのような場合には、ほか,,,,,,,,,,,,,,,,,, ,のシステムや後続作業への影響の大きさ、移行データの種類や量の多さ、各種機器の切り替え手順の複雑さなど,,,,,,,,,,,,,,,,,, ,に着目して、タイムチャートのクリティカルな部分を見極め、例えば、次のようないくつかの方法を組み合わせて、クリ,,,,,,,,,,,,,,,,,, ,ティカルな部分が計画通りに実施できることを確認する必要がある。,,,,,,,,,,,,,,,,,, ,,・,開発用のシステム資源を用いて作業を行い、その結果から類推する。,,,,,,,,,,,,,,,, ,,・,一部の本番データを用いて作業を行い、その結果から類推する。,,,,,,,,,,,,,,,, ,,・,本番と同じ切り替え手順を用いてシミュレーションを行い、その結果から類推する。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,設問ア,,,あなたが移行に携わったシステムの特徴と、移行計画の概要について、800字以内で述べよ。,,,,,,,,,,,,,,, ,設問イ,,,設問アで述べた移行計画のタイムチャートにおけるクリティカルな部分は何か。クリティカルと見極めた理,,,,,,,,,,,,,,, ,,,,由とともに簡潔に述べよ。また、本番のシステム移行時に、クリティカルな部分が計画通りに実施できること,,,,,,,,,,,,,,, ,,,,を、事前にどのように確認したか。特に工夫した点を中心に、具体的に述べよ。,,,,,,,,,,,,,,, ,設問ウ,,,設問イで述べた確認方法について、あなたはどのように評価しているか。また、今後改善したい点は何か。,,,,,,,,,,,,,,, ,,,,それぞれ簡潔に述べよ。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ■解説,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,■出題趣旨,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　基幹系システムのように、他システムとのインタフェースが多岐にわたり、移行データの種類や量が多い場合は,,,,,,,,,,,,,,,,, ,,、多くのシステム資源を必要としたり、作業時間が長くなったり、移行手順が複雑になったりする。このため、計画,,,,,,,,,,,,,,,,, ,,したタイムチャートどおりに移行できるかを事前に確認しておく必要がある。しかしながら、移行作業について、本,,,,,,,,,,,,,,,,, ,,番の移行時と同じ環境、同じ手順、同じタイムチャートで確認を行うことは、資源的、時間的制約から難しい場合,,,,,,,,,,,,,,,,, ,,がある。このため、タイムチャートのクリティカルな部分を見極め、移行作業が計画通りに実施できることを事前に,,,,,,,,,,,,,,,,, ,,確認する方法を工夫することが求められる。,,,,,,,,,,,,,,,,, ,,　本問は、タイムチャートのクリティカルな部分について、どのように見極め、本番のシステム移行作業の実現可,,,,,,,,,,,,,,,,, ,,能性を事前にどのように確認したかについて具体的に論述することを求めている。,,,,,,,,,,,,,,,,, ,,　本問では、論述を通じて、アプリケーションエンジニアに必要なシステム移行計画の立案における分析・設計能,,,,,,,,,,,,,,,,, ,,力と経験を評価する。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,■採点講評,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　問３（移行計画におけるタイムチャートの事前確認について）では、多くの受験者が移行計画策定や移行作業を,,,,,,,,,,,,,,,,, ,,経験していることがうかがえた。策定したタイムチャートにおけるクリティカルな部分の見極めと、その事前確認に,,,,,,,,,,,,,,,,, ,,おいて工夫した点を論述することを期待したが、題意と異なり、移行データ量や作業時間の見積り、移行データ不,,,,,,,,,,,,,,,,, ,,備への対応策など、移行計画の内容に終始する論述が多かった。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ■解答例,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,（設問ア）,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．私が移行に携わったシステムの特徴,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　K社は、北日本の地方都市を中心に約150店舗を運営するスーパマーケットである。日本全体の人口減少やコ,,,,,,,,,,,,,,,,, ,,ンビニエンスストアの拡大によって、K社の売上高は微減し続けていた。その当時、大手のスーパマーケットは、イ,,,,,,,,,,,,,,,,, ,,ンターネットで注文を受け付けて、店舗から顧客が指定する場所に注文商品を配達するネットスーパ事業を開始,,,,,,,,,,,,,,,,, ,,していた。K社の経営者層は、経営計画策定時に、ネットスーパ事業への参入とそれに対応するシステム（以下、,,,,,,,,,,,,,,,,, ,,Nシステムという）の開発を決定した。Nシステムの特徴は、①：データの種類や量が多い、②：システム移行に多,,,,,,,,,,,,,,,,, ,,くのシステム資源を必要とし、作業時間が長く、作業手順が複雑になる　の2点だった。私は、K社の情報システム,,,,,,,,,,,,,,,,, ,,部に所属するシステムアーキテクトであり、Nシステム開発プロジェクトの設計チームリーダに任命された。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．移行計画の概要,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　K社の経営者層は、①：K社の約30店舗（以下、試行店舗という）はNシステムの本番稼働時期に合わせて、ネッ,,,,,,,,,,,,,,,,, ,,トスーパ事業を開始する。②：Nシステムの本番稼働日から4か月後に、試行店舗での改善点を織り込んで残りの,,,,,,,,,,,,,,,,, ,,約120店舗のネットスーパ事業を開始する。という2段階の段階移行の方針を決定した。私は、試行店舗の移行計,,,,,,,,,,,,,,,,, ,,画を策定し、これを残りの店舗の移行にも適用することとした。その移行計画の概要は、以下の通りだった。,,,,,,,,,,,,,,,,, ,,,-1,,会員マスタをネットスーパ用に変換するなど、データ変換プログラムを実行してデータ移行を行う。,,,,,,,,,,,,,, ,,,-2,,K社が運用してきた販売管理システム（以下、既存システムという）のうち、試行店舗のPOS端末,,,,,,,,,,,,,, ,,,,,プログラムを更新する。,,,,,,,,,,,,,, ,,,-3,,本社と試行店舗間のIP-VPN帯域を増すために、ルータを新機種に刷新する。,,,,,,,,,,,,,, ,,,-4,,本社サーバと試行店舗サーバ間のレプリケーション設定を変更する。,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,（設問イ）,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．移行の事前確認の重要性,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、Nシステムの特徴から、計画したタイムチャート通りの時間や手順で実施できるかどうかを、移行の事前確,,,,,,,,,,,,,,,,, ,,認（以下、移行リハーサルという）によって検証することが重要だと考えた。そこで、私は以下の検討を開始した。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．クリティカルな部分とそれを見極めた理由,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は移行リハーサルをする際、本番のシステム移行時と同じシステム資源を用いて、同じタイムチャートで実施,,,,,,,,,,,,,,,,, ,,することが望ましいと考えた。しかし、使用できるシステム資源や作業時間の制約から、移行リハーサルを本番通,,,,,,,,,,,,,,,,, ,,りには実施できなかった。そこで、私は以下の3点に着目して、移行計画のタイムチャート上のクリティカルな部分,,,,,,,,,,,,,,,,, ,,を見極めた。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．１　他システムや後続作業への影響の大きさ,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　本社と試行店舗間のIP-VPN回線は、既存システムで使われており、Nシステムでも使用される。特に、本社サー,,,,,,,,,,,,,,,,, ,,バに記録されたネットスーパの注文受付情報は、即時に店舗サーバに転送しなければならず、迂回回線は用意さ,,,,,,,,,,,,,,,,, ,,れないのでIP-VPN回線は重要である。したがって、既存システムや後続作業への影響の大きさの観点から、IP-,,,,,,,,,,,,,,,,, ,,VPNルータを新機種に刷新し、その設定をする作業は、クリティカルな部分に該当した。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．２　移行データの種類や量の多さ,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　ネットスーパ事業は、K社にとって新規事業であり、Nシステムは新規導入システムである。既存システムから,,,,,,,,,,,,,,,,, ,,移行すべき主なデータは、会員マスタ、商品マスタだった。商品マスタには、商品大分類マスタ・商品中分類マス,,,,,,,,,,,,,,,,, ,,タ・商品小分類マスタ・SKU（Store Keeping Unit）マスタなど多数の関連マスタがあり、データ量も多かった。した,,,,,,,,,,,,,,,,, ,,がって、移行データの種類や量の多さの観点からは、商品マスタのデータ移行作業は、クリティカルな部分に該当,,,,,,,,,,,,,,,,, ,,した。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．３　機器の切替手順の複雑さ,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　本社サーバに記録されたネットスーパの注文受付情報は、DBMS（DataBase Management System）のレプリケ,,,,,,,,,,,,,,,,, ,,ーション機能によって店舗サーバに転送される仕組みになっている。移行担当者は、本社サーバと各試行店舗の,,,,,,,,,,,,,,,,, ,,店舗サーバにおいて、レプリケーションの設定を個別に実施しなければならなかった。また、本社⇔A店舗間のIP-,,,,,,,,,,,,,,,,, ,,VPN回線が不通になった場合、本社⇔B店舗⇔A店舗のIP-VPN回線が稼働していれば、それを使って本社とA店,,,,,,,,,,,,,,,,, ,,舗間のレプリケーションを継続するように、その稼働率を向上させなければならない。この迂回するレプリケーショ,,,,,,,,,,,,,,,,, ,,ンの本社・店舗間の組み合わせは多数ある。したがって、機器の切替手順の複雑さの観点からは、レプリケーショ,,,,,,,,,,,,,,,,, ,,ンの設定作業は、クリティカルな部分に該当した。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,３．移行リハーサルにおいて、特に工夫した点,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、上記のクリティカルな部分が計画通りに実施できることを確認するために、以下の3点の方法を組み合わ,,,,,,,,,,,,,,,,, ,,せた。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,①開発用システム資源の使用,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,　私は、IP-VPNルータの新機種への刷新と設定作業を、開発用のシステム資源を用いて行い、その結果から,,,,,,,,,,,,,,,, ,,,類推した。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,②一部の本番データの使用,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,　私は、商品マスタのデータ移行作業において、一部の本番データを用いて作業を行い、その結果から類推し,,,,,,,,,,,,,,,, ,,,た。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,③本番の切替手順書を用いたシミュレーション,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,　私は、レプリケーション設定作業のうち、店舗間を迂回するレプリケーションの設定変更については、本番の,,,,,,,,,,,,,,,, ,,,切替手順書を用いたシミュレーションを行い、その結果から類推した。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,（設問ウ）,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．設問イで述べた確認方法についての私の評価,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私が実施した確認方法は、予定した効果を発揮し、Nシステムは順調に稼働している。その意味では、私は適切,,,,,,,,,,,,,,,,, ,,な確認方法を実施したと評価できる。しかし、下記の2つは不十分な点があり、改良の余地があると考えられる。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．１　開発用システム資源の使用,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　Nシステムで稼働するIP-VPNルータの新機種は、3種類あった。私は、本社とある1つの試行店舗に導入予定の,,,,,,,,,,,,,,,,, ,,2機種を、開発室と協力会社に設置して移行リハーサルを実行した。残りの1機種は、移行リハーサルを行った2機,,,,,,,,,,,,,,,,, ,,種と互換性がある同一ベンダの機種だったので、私は問題なしと判断した。しかし、残りの1機種を導入した試行,,,,,,,,,,,,,,,,, ,,店舗での移行時に、想定外の警告メッセージがログに記録された。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．２　本番の切替手順書を用いたシミュレーション,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　本番の切替手順書は、DBMSの1バージョン古いレプリケーション機能のパラメータ記法に基づいて、K社のシス,,,,,,,,,,,,,,,,, ,,テム運用課が作成したものだった。当該DBMSは、最新バージョンと古いバージョンの両方のパラメータ記法で動,,,,,,,,,,,,,,,,, ,,作するので、問題は生じなかった。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．今後改善したい点,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は上記の評価に対し、以下の改善を実行する。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．１　開発用システム資源の使用,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、移行する全機種のルータの移行リハーサルを行う。動作に影響がない警告メッセージであっても見逃さず,,,,,,,,,,,,,,,,, ,,、安定した運用を維持し続ける環境の構築を支援する。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．２　本番の切替手順書を用いたシミュレーション,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　今後は、古いバージョンのパラメータ記法では、レプリケーションが動作しなくなる可能性がある。そこで、私は最,,,,,,,,,,,,,,,,, ,,新版のパラメータ記法に従った本番の切替手順書の改訂をK社のシステム運用課に依頼する。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, 平成１９年度　問２　優れたユーザビリティ実現のためのWebシステムの設計について,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,　顧客サービスの向上や事務作業の効率向上などを目的に、企業内で利用されてきた基幹系システムを拡張して、,,,,,,,,,,,,,,,,,, ,企業外の多くのユーザに利用してもらうためのWebシステムを開発するケースが増えている。例えば、基幹システム,,,,,,,,,,,,,,,,,, ,に取り込む注文をインターネットで受け付けたり、基幹システムのデータを使って、注文の配送状況をインターネット,,,,,,,,,,,,,,,,,, ,で確認したりするようなWebシステムがそれに当たる。,,,,,,,,,,,,,,,,,, ,　このようなシステムでは、ユーザに入力・表示方法やレスポンスなどで不快な思いをさせないよう、優れたユーザビ,,,,,,,,,,,,,,,,,, ,リティを提供することが重要である。そのためには、アプリケーションエンジニアは、アクセスの集中度やユーザの習,,,,,,,,,,,,,,,,,, ,熟度などの観点から、システムが提供するサービスとユーザの特性を分析し、その結果をシステムの設計に反映さ,,,,,,,,,,,,,,,,,, ,せなければならない。具体的には、ユーザインタフェース及びクライアントやサーバで稼働するアプリケーションの設,,,,,,,,,,,,,,,,,, ,計について、例えば、次に挙げるような工夫を行わなければならない。,,,,,,,,,,,,,,,,,, ,,・,入力仕様が複雑で、入力項目が多く、複数ページにわたるような注文処理では、入力支援のための参照機能,,,,,,,,,,,,,,,, ,,,を充実させるとともに、入力途中での中断・再開に対応するために、入力内容をサーバに適宜保存する。,,,,,,,,,,,,,,,, ,,・,習熟度が低いユーザが多く、誤入力の発生頻度が高いと予想される処理では、クライアントの側で入力チェッ,,,,,,,,,,,,,,,, ,,,クを十分に行い、サーバへのアクセスを極力抑制する。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,設問ア,,,あなたが開発に携わったWebシステムの概要と、開発の背景について、800字以内で述べよ。,,,,,,,,,,,,,,, ,設問イ,,,設問アで述べたWebシステムが提供するサービスとユーザの特性について、どのように分析したか、簡潔,,,,,,,,,,,,,,, ,,,,に述べよ。また、分析結果を踏まえ、優れたユーザビリティを実現するために、Webシステムのユーザインタ,,,,,,,,,,,,,,, ,,,,フェース及びクライアントやサーバで稼働するアプリケーションをどのように設計したか。特に重要と考え、,,,,,,,,,,,,,,, ,,,,工夫した点を中心に、具体的に述べよ。,,,,,,,,,,,,,,, ,設問ウ,,,設問イで述べた設計上の工夫について、あなたはどのように評価しているか。また、今後、改善したい点は,,,,,,,,,,,,,,, ,,,,何か。それぞれ簡潔に述べよ。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ■解説,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,■出題趣旨,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　最近、顧客サービスの向上や事務作業の効率向上などを目的に、企業内で利用されてきた基幹系システムを,,,,,,,,,,,,,,,,, ,,拡張して、企業外の多くのユーザに利用してもらうためのWebシステムを開発するケースが増えている。,,,,,,,,,,,,,,,,, ,,　このようなWebシステムでは、より多くのユーザに利用してもらったり、より確実に利用してもらったりすることが、,,,,,,,,,,,,,,,,, ,,そのWebシステムの提供目的達成のために重要であり、そのために、優れたユーザビリティを提供することが重,,,,,,,,,,,,,,,,, ,,要な開発目標となる。,,,,,,,,,,,,,,,,, ,,　本問では、まず、このようなWebシステムが提供するサービスとユーザの特性についてどのように分析したかを,,,,,,,,,,,,,,,,, ,,論述することを求めている。次に、その結果を踏まえ、優れたユーザビリティを実現するために、ユーザインタフェ,,,,,,,,,,,,,,,,, ,,ースとクライアントやサーバで稼働するアプリケーションの設計においてどのような工夫を行ったかを、具体的に,,,,,,,,,,,,,,,,, ,,論述することを求めている。論述を通じて、アプリケーションエンジニアに必要な設計についての経験・見識を評,,,,,,,,,,,,,,,,, ,,価する。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,■採点講評,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　全問に共通して、記述の乱雑なものや誤字脱字が目立つもの、論述内容が理解しづらいものがあった。このよ,,,,,,,,,,,,,,,,, ,,うな論述では、受験者の能力や経験を正しく読み取れない場合もあり得るので、ぜひ留意してもらいたい。,,,,,,,,,,,,,,,,, ,,　問２（優れたユーザビリティ実現のためのWebシステムの設計について）は、選択率が最も高く、多くの受験者が,,,,,,,,,,,,,,,,, ,,Webシステムの設計を経験していることがうかがえた。サービスとユーザの特性については、よく書けていた。し,,,,,,,,,,,,,,,,, ,,かし、ユーザインタフェースの設計における工夫では、サービスとユーザの特性に関連付けた工夫についての論,,,,,,,,,,,,,,,,, ,,述を期待したが、関連のない工夫を列挙した論述が多かった。また、クライアントやサーバで稼働するアプリケー,,,,,,,,,,,,,,,,, ,,ションの設計における工夫については、具体性の不十分な論述が多かった。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ■論述例,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．システム概要,,,,,,,,,,,,,,,,,, ,１．１　私が開発に携わったWebシステムの概要,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　N市は豊かな自然ときれいな海に囲まれ、観光業を主要産業としている。A社はN市とその周辺都市に7つのホ,,,,,,,,,,,,,,,,, ,,テルを営業しており、この度、各ホテルのホームページから利用者が直接宿泊予約できる、Web予約システムを,,,,,,,,,,,,,,,,, ,,構築することとなった。,,,,,,,,,,,,,,,,, ,,　これまでA社のホームページの作成などを受注してきたソフトウェアハウスB社は、本システム開発を受注し、B,,,,,,,,,,,,,,,,, ,,社に所属する私はシステムアーキテクトとして参画した。,,,,,,,,,,,,,,,,, ,,　Web予約システムは、利用者がインターネットを利用して、ウェブブラウザから宿泊予約ができるシステムであり,,,,,,,,,,,,,,,,, ,,、カレンダ形式で日付と空き部屋、選択可能な宿泊プランを提示し、利用者に選択させる。その後、代表者氏名,,,,,,,,,,,,,,,,, ,,や住所、宿泊人数、支払方法等の情報を入力し、料金などを表示した最終確認画面で予約確定ボタンを押すと、,,,,,,,,,,,,,,,,, ,,予約が取れるシステムである。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．２　予約システムを開発することになった背景,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　これまでA社のホテル予約は、ホームページ等に記載されている電話によるものか、旅行代理店からの予約に,,,,,,,,,,,,,,,,, ,,限られていた。しかし、電話で空き部屋やプランを伝えるのには時間がかかり、正確に伝わらないこともあった。,,,,,,,,,,,,,,,,, ,,また、予約を受付けた際にすぐにシステム入力されない場合があり、規定数以上の予約を受付けてしまうなどの,,,,,,,,,,,,,,,,, ,,トラブルも発生していた。,,,,,,,,,,,,,,,,, ,,　そこで、予約業務の効率化と、利用者の利便性向上による予約数の増加、予約数の適切な管理を目的として、,,,,,,,,,,,,,,,,, ,,これまで社内システムとして利用していた予約管理システムの機能を拡張し、利用者が直接Webから予約を可能,,,,,,,,,,,,,,,,, ,,とするWeb予約システムの構築が決定された。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．私が実施したWebシステムの設計,,,,,,,,,,,,,,,,,, ,２．１　Web予約システムが提供するサービスの特性とユーザの特性,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　Web予約システムでは機会損失を防ぐために、入力・表示方法やレスポンスなどで不快な思いをさせない、優れ,,,,,,,,,,,,,,,,, ,,たユーザビリティが必要になる。それを実現するには、サービス特性を十分理解した上で、それを利用するユー,,,,,,,,,,,,,,,,, ,,ザの特性をも加味して設計しなければならない。そう考えた私は、要件定義の最初に、サービス特性の確認とユ,,,,,,,,,,,,,,,,, ,,ーザ特性の分析を実施することにした。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,（１）サービス特性の確認,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,　今回システム化する予約業務は、予約時の選択項目が多い。日程、部屋タイプ、価格、料理の有無、その他,,,,,,,,,,,,,,,, ,,,サービスの有無等である。しかも、それぞれに宿泊客の嗜好が入るので、それぞれに細かい条件が加わる。,,,,,,,,,,,,,,,, ,,,例えば、海側か山側か、部屋の大きさ、バスルームに窓があるかどうかなどだ。,,,,,,,,,,,,,,,, ,,,　事前にそのあたりも、これまでの電話予約ではどのような点に対して不満の声が出ているのかを、宿泊客に,,,,,,,,,,,,,,,, ,,,対するアンケート調査で確認しているが、その結果でも、やはり電話の応対時間が長くなった時に、不満の声,,,,,,,,,,,,,,,, ,,,が増えていることを確認した。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,（２）ユーザ特性の分析,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,　また、ユーザのパソコン操作に関する習熟度について想定するために、ホテル利用者の年齢層を確認したと,,,,,,,,,,,,,,,, ,,,ころ、自然の中に立つリゾートホテルについては特に50代以上の利用者が多く、A社全体で見ても50代以上の,,,,,,,,,,,,,,,, ,,,利用者が約半数以上を占めるという状況であることが分かった。,,,,,,,,,,,,,,,, ,,,　このことから、習熟度はかなり低いことが予想されたため、予約操作や情報を表示する操作は、できる限り,,,,,,,,,,,,,,,, ,,,簡単にして、誤入力や機会損失を防ぐ必要があると判断した。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．２　Webシステムの設計について,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　こうした分析結果を受けて要件を詰めていった結果、かなり入力項目が多くなってしまった。しかも、部屋タイプ,,,,,,,,,,,,,,,,, ,,や料理など、入力項目の中にはシステム側から提供する情報も多くなる。それらを考慮してユーザインタフェース,,,,,,,,,,,,,,,,, ,,を設計する必要があった。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,（１）Ajaxの採用,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,　まず、ユーザの習熟度が低いことから、可能な限りマウス操作で入力できるように考えた。そのため、選択項,,,,,,,,,,,,,,,, ,,,目は、リストボックスを使用したり、1画面内で選択を進めていくに連れて表示を変える操作など、クライアント,,,,,,,,,,,,,,,, ,,,サーバ同等の処理が必要になる。料金計算もサーバ側ではなく、その都度クライアント側で実施させる必要が,,,,,,,,,,,,,,,, ,,,ある。そこで私は、それを可能にするために、Ajaxを採用して設計することにした。これにより、クライアントサ,,,,,,,,,,,,,,,, ,,,ーバとほぼ同等の操作が、クライアント側で実施できるので、操作性もレスポンスもユーザに満足してもらえる,,,,,,,,,,,,,,,, ,,,と考えた。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,（２）入力内容保存機能,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,　次に（情報量が多いので）入力時間が長くなるという問題に対しては、途中で中断できるボタンを配置して、,,,,,,,,,,,,,,,, ,,,そのボタンを利用者がクリックしたタイミングで、その時点での入力済み項目を保存できるように設計した。こう,,,,,,,,,,,,,,,, ,,,することで、従来の電話予約時には実現できなかった”複数回に分けての予約”も可能になる。これにより、予,,,,,,,,,,,,,,,, ,,,約時の機会損失も減少できると期待した。ただし、個人を特定できる情報も保存することになるので、漏洩リス,,,,,,,,,,,,,,,, ,,,クを考えて、保存期間は1週間限定にすることにした。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,３．評価と改善点,,,,,,,,,,,,,,,,,, ,３．１　設計上の工夫に対する評価,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　当初は年齢が高い層の人たちはWeb予約システムを利用せず、結局電話予約ばかり利用されてしまうのでは,,,,,,,,,,,,,,,,, ,,ないかという懸念があった。しかし、システム化するまでの既存顧客の電話予約とシステムからの予約の割合を,,,,,,,,,,,,,,,,, ,,比較すると、順調にシステム予約の割合が増えている。インターネットを利用していない人もいるので、電話予約,,,,,,,,,,,,,,,,, ,,をなくすことはしないが、当初目標だった70％（既存顧客のシステム予約利用者の割合）は、6カ月で超えた。,,,,,,,,,,,,,,,,, ,,ランダムに依頼したアンケート結果を見ても、おおむね好評である。いずれも、ユーザインタフェース設計におい,,,,,,,,,,,,,,,,, ,,て、利用者の顔を見て、彼らにとっての使いやすさとは何かを追求したことが良かったと考えている。,,,,,,,,,,,,,,,,, ,,　また、個人情報をサーバ側で保存することになったが、1週間経過した段階で自動的に削除できるほか、セキュ,,,,,,,,,,,,,,,,, ,,リティ面も考慮した設計にしたので、今のところ特に問題は発生していない。ここも設計段階で工夫した点が良か,,,,,,,,,,,,,,,,, ,,ったと評価している。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,３．２　今後の改善点,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　とはいうものの、手放しで喜んでもいられない。今回は可能な限りマウス操作で入力を完了させる設計にしたが,,,,,,,,,,,,,,,,, ,,、これが逆に面倒だという意見も上がっている。それはキーボード入力に長けた、いわゆる（パソコン操作やキー,,,,,,,,,,,,,,,,, ,,ボード入力の）習熟度の高いユーザからの意見である。確かに、日付の入力などは可憐だから選択するよりも、,,,,,,,,,,,,,,,,, ,,キーボードから直接数字を入力した方が早いのは早い。,,,,,,,,,,,,,,,,, ,,　そのような意見に対して、今後は、利用者がキーボード入力かマウス操作化を選択できるようにして、習熟度に,,,,,,,,,,,,,,,,, ,,よってインタフェースが切り替えられるような設計にしたい。以上,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, 平成１９年度　問２　優れたユーザビリティ実現のためのWebシステムの設計について,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,　顧客サービスの向上や事務作業の効率向上などを目的に、企業内で利用されてきた基幹系システムを拡張して、,,,,,,,,,,,,,,,,,, ,企業外の多くのユーザに利用してもらうためのWebシステムを開発するケースが増えている。例えば、基幹システム,,,,,,,,,,,,,,,,,, ,に取り込む注文をインターネットで受け付けたり、基幹システムのデータを使って、注文の配送状況をインターネット,,,,,,,,,,,,,,,,,, ,で確認したりするようなWebシステムがそれに当たる。,,,,,,,,,,,,,,,,,, ,　このようなシステムでは、ユーザに入力・表示方法やレスポンスなどで不快な思いをさせないよう、優れたユーザビ,,,,,,,,,,,,,,,,,, ,リティを提供することが重要である。そのためには、アプリケーションエンジニアは、アクセスの集中度やユーザの習,,,,,,,,,,,,,,,,,, ,熟度などの観点から、システムが提供するサービスとユーザの特性を分析し、その結果をシステムの設計に反映さ,,,,,,,,,,,,,,,,,, ,せなければならない。具体的には、ユーザインタフェース及びクライアントやサーバで稼働するアプリケーションの設,,,,,,,,,,,,,,,,,, ,計について、例えば、次に挙げるような工夫を行わなければならない。,,,,,,,,,,,,,,,,,, ,,・,入力仕様が複雑で、入力項目が多く、複数ページにわたるような注文処理では、入力支援のための参照機能,,,,,,,,,,,,,,,, ,,,を充実させるとともに、入力途中での中断・再開に対応するために、入力内容をサーバに適宜保存する。,,,,,,,,,,,,,,,, ,,・,習熟度が低いユーザが多く、誤入力の発生頻度が高いと予想される処理では、クライアントの側で入力チェッ,,,,,,,,,,,,,,,, ,,,クを十分に行い、サーバへのアクセスを極力抑制する。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,設問ア,,,あなたが開発に携わったWebシステムの概要と、開発の背景について、800字以内で述べよ。,,,,,,,,,,,,,,, ,設問イ,,,設問アで述べたWebシステムが提供するサービスとユーザの特性について、どのように分析したか、簡潔,,,,,,,,,,,,,,, ,,,,に述べよ。また、分析結果を踏まえ、優れたユーザビリティを実現するために、Webシステムのユーザインタ,,,,,,,,,,,,,,, ,,,,フェース及びクライアントやサーバで稼働するアプリケーションをどのように設計したか。特に重要と考え、,,,,,,,,,,,,,,, ,,,,工夫した点を中心に、具体的に述べよ。,,,,,,,,,,,,,,, ,設問ウ,,,設問イで述べた設計上の工夫について、あなたはどのように評価しているか。また、今後、改善したい点は,,,,,,,,,,,,,,, ,,,,何か。それぞれ簡潔に述べよ。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ■解説,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,■出題趣旨,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　最近、顧客サービスの向上や事務作業の効率向上などを目的に、企業内で利用されてきた基幹系システムを,,,,,,,,,,,,,,,,, ,,拡張して、企業外の多くのユーザに利用してもらうためのWebシステムを開発するケースが増えている。,,,,,,,,,,,,,,,,, ,,　このようなWebシステムでは、より多くのユーザに利用してもらったり、より確実に利用してもらったりすることが、,,,,,,,,,,,,,,,,, ,,そのWebシステムの提供目的達成のために重要であり、そのために、優れたユーザビリティを提供することが重,,,,,,,,,,,,,,,,, ,,要な開発目標となる。,,,,,,,,,,,,,,,,, ,,　本問では、まず、このようなWebシステムが提供するサービスとユーザの特性についてどのように分析したかを,,,,,,,,,,,,,,,,, ,,論述することを求めている。次に、その結果を踏まえ、優れたユーザビリティを実現するために、ユーザインタフェ,,,,,,,,,,,,,,,,, ,,ースとクライアントやサーバで稼働するアプリケーションの設計においてどのような工夫を行ったかを、具体的に,,,,,,,,,,,,,,,,, ,,論述することを求めている。論述を通じて、アプリケーションエンジニアに必要な設計についての経験・見識を評,,,,,,,,,,,,,,,,, ,,価する。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,■採点講評,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　全問に共通して、記述の乱雑なものや誤字脱字が目立つもの、論述内容が理解しづらいものがあった。このよ,,,,,,,,,,,,,,,,, ,,うな論述では、受験者の能力や経験を正しく読み取れない場合もあり得るので、ぜひ留意してもらいたい。,,,,,,,,,,,,,,,,, ,,　問２（優れたユーザビリティ実現のためのWebシステムの設計について）は、選択率が最も高く、多くの受験者が,,,,,,,,,,,,,,,,, ,,Webシステムの設計を経験していることがうかがえた。サービスとユーザの特性については、よく書けていた。し,,,,,,,,,,,,,,,,, ,,かし、ユーザインタフェースの設計における工夫では、サービスとユーザの特性に関連付けた工夫についての論,,,,,,,,,,,,,,,,, ,,述を期待したが、関連のない工夫を列挙した論述が多かった。また、クライアントやサーバで稼働するアプリケー,,,,,,,,,,,,,,,,, ,,ションの設計における工夫については、具体性の不十分な論述が多かった。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ■解答例,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,（設問ア）,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．私が開発に携わったWebシステム開発の背景,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　K社は、北日本の地方都市を中心に約150店舗を運営するスーパマーケットである。日本全体の人口減少やコ,,,,,,,,,,,,,,,,, ,,ンビニエンスストアの拡大によって、K社の売上高は微減し続けていた。その当時、大手のスーパマーケットは、イ,,,,,,,,,,,,,,,,, ,,ンターネットで注文を受け付けて、店舗から顧客が指定する場所に注文商品を配達するネットスーパ事業を開始,,,,,,,,,,,,,,,,, ,,していた。K社の経営者層は、経営計画策定時に、ネットスーパ事業への参入とそれに対応するシステム（以下、,,,,,,,,,,,,,,,,, ,,Nシステムという）の開発を決定した。Nシステム開発の目的は、①：3年後の売上高が前年度比で8％増加する、,,,,,,,,,,,,,,,,, ,,②：Nシステムを利用し、割引サービスやポイントを得る会員（以下、N会員という）の数が3年間で50万人増加する,,,,,,,,,,,,,,,,, ,,、の2点だった。私は、K社の情報システム部に所属するシステムアーキテクトであり、Nシステム開発プロジェクト,,,,,,,,,,,,,,,,, ,,の設計チームリーダに任命された。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．Nシステムの概要,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　Nシステムの構成は、①：アプリケーションサーバ10台、データベースサーバ3台をN社の情報システム部に設置,,,,,,,,,,,,,,,,, ,,する。②：アプリケーションソフトウェアのうち、クライアントPC側はWebブラウザ上で動作するJavaスクリプト、サー,,,,,,,,,,,,,,,,, ,,バ側はJavaサーブレットを使用する。Nシステムが対象とする主な業務は、会員管理業務、注文受付業務、商品,,,,,,,,,,,,,,,,, ,,集荷業務、商品引渡業務、店舗運営管理業務である。注文受付業務の大半は、顧客が操作するWebブラウザの,,,,,,,,,,,,,,,,, ,,注文画面によってなされ、その良否がネットスーパ事業の業績を左右する。Nシステムは、K社の情報システム部,,,,,,,,,,,,,,,,, ,,にとって、初めて開発するWebシステムだった。Nシステムの注文画面は約10画面から構成され、複雑な画面遷,,,,,,,,,,,,,,,,, ,,移を伴うため、私はその設計の難易度が高いと予想した。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,（設問イ）,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．私が分析したNシステムのサービスとN会員の特性,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、N会員に、入力・表示方法やレスポンスなどで不快な思いをさせないよう、優れたユーザビリティを提供す,,,,,,,,,,,,,,,,, ,,ることが重要であると考えた。しかし、N会員はNシステムが本番稼働と同時に募集開始されるため、Nシステムの,,,,,,,,,,,,,,,,, ,,外部設計時点では存在せず、ユーザビリティの具体像を明確化しづらい状況だった。,,,,,,,,,,,,,,,,, ,,　K社は、以前から店舗のレジで会員カードを提示するとポイントが貯まる制度を導入していた。私は、その会員,,,,,,,,,,,,,,,,, ,,の中から無作為抽出した200名に対し、Nシステムに関するアンケートに回答する者（以下、Nモニタという）を募集,,,,,,,,,,,,,,,,, ,,し、22名が応募した。私は、Nモニタの意見を参考にしてNシステムの外部設計を進めようと考えた。そのために、,,,,,,,,,,,,,,,,, ,,私は以下の2点の観点から、NシステムのサービスとNモニタの特性を分析した。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．１　アクセスの集中度の観点,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、Nモニタに対するアンケートの1項目に、ネットスーパへの注文時間帯を入れた。アンケートの回答は、様,,,,,,,,,,,,,,,,, ,,々であり、特定の時間帯に集中しなかった。強いて言えば、主婦は13;00～15:00を、OL等の会社員は21:00～,,,,,,,,,,,,,,,,, ,,23:00を回答する者が多かった。私は、K社の店舗が地方都市に集中していることを勘案し、N会員は中高年の女,,,,,,,,,,,,,,,,, ,,性が大半を占めると予想した。そこで、私は平日13:00～15:00をアクセスが集中する時間にした。しかし、その集,,,,,,,,,,,,,,,,, ,,中度は低く、私はその時間帯のアクセス数が1日の平均値の20％増加すると想定した。また、日曜日や祝日に,,,,,,,,,,,,,,,,, ,,商品の受け取りを希望する者は多かった。しかし、週末等の特定の日に注文すると回答した者は少なかった。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．２　ユーザの習熟度の観点,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、Nモニタに対するアンケートの1項目に、PCもしくは携帯電話からのWebアクセス経験年数を入れた。ほと,,,,,,,,,,,,,,,,, ,,んどのNモニタは”5年以上”と回答した。この結果からは、ユーザの習熟度は”高”になると想定された。しかし、,,,,,,,,,,,,,,,,, ,,私は、来店が困難であり、パソコンなどの操作に不慣れな年配者が新規のN会員になる可能性が高いと予想した,,,,,,,,,,,,,,,,, ,,。そこで、私はN会員のコンピュータ操作に関する習熟度を”低”とした。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．私が設計したユーザインタフェースと工夫した点,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、上記の分析結果を踏まえて、Nシステムの外部設計に反映させる作業を開始した。私は、具体的にはユ,,,,,,,,,,,,,,,,, ,,ーザインタフェース及びクライアントやサーバで稼働するアプリケーションの設計について、以下の2点の工夫を,,,,,,,,,,,,,,,,, ,,行った。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．１　入力支援のための参照機能と中断・再開の対応,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　注文画面は、大きく商品検索画面、商品選択・数量入力画面等の複数の画面から構成される。私は、例えば商,,,,,,,,,,,,,,,,, ,,品検索画面は、商品分類検索指定・キーワード検索指定・価格帯条件指定など入力項目が多く、入力仕様が複,,,,,,,,,,,,,,,,, ,,雑になると考えた。そこで、私は、入力支援のための参照機能を充実させた。例えば、新規配送先指定画面には,,,,,,,,,,,,,,,,, ,,、郵便番号を入力すると該当する住所を表示し、選択させる参照画面をポップアップさせる仕様にした。また、私,,,,,,,,,,,,,,,,, ,,は入力途中での中断・再開に対応するために、入力内容をサーバに画面遷移ごとに適宜保存させる仕様とした。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．２　クライアント側で入力チェック,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、N会員のコンピュータ操作に関する習熟度を”低”としたので、誤入力の発生頻度が高いと予想される注,,,,,,,,,,,,,,,,, ,,文画面処理では、クライアント側でJavaスクリプトを使った入力チェックを十分に行い、サーバへのアクセスを極力,,,,,,,,,,,,,,,,, ,,抑制する仕様にした。ただし、Webブラウザの設定を”Javaスクリプトを使用しない”にしているN会員もいると考え,,,,,,,,,,,,,,,,, ,,られるので、私はクライアント側と同一のチェックを注文完了後に、再度サーバ側で一括して実行する仕様にした,,,,,,,,,,,,,,,,, ,,。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,（設問ウ）,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．設問イで述べた設計上の工夫についての私の評価,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私が実施した設計上の工夫は、予定した効果を発揮し、Nシステムは順調に稼働している。その意味では、私,,,,,,,,,,,,,,,,, ,,は正しい設計をしたと評価できる。しかし、下記の2つは不十分な点があり、改良の余地があると考えられる。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．１　注文した商品の受取拒否,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　ある年配女性のN会員は、宅配会社から届けられた商品のうち、卵20パックの受取を拒否した。その理由は”そ,,,,,,,,,,,,,,,,, ,,のような注文入力をした覚えはない。主人と私の2人ではそんなにたくさん食べられない”だった。宅配会社の担,,,,,,,,,,,,,,,,, ,,当者は、受け取り拒否の正当な理由ではないと思いつつ、返品を受け入れた。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．２　定期的な購買品の煩雑な商品選択・数量入力,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　”毎週、食パン2斤と牛乳3パック等の5品目を必ず購入しています。商品選択及び数量入力が面倒なので、簡,,,,,,,,,,,,,,,,, ,,単にできないでしょうか？”という問い合わせメールが高頻度に購買する会員からNシステムのヘルプデスクに送,,,,,,,,,,,,,,,,, ,,付された。私は、Nシステムの取引ログを査閲して、定期的に同一商品を同一数量購入している会員の存在を確,,,,,,,,,,,,,,,,, ,,認した。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．今後改善したい点,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は上記の評価に対し、以下の改善を実行する。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．１　注文した商品の受取拒否,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、当該会員は注文数量”２”を誤って”２０”と入力し、それに気づかず注文確定ボタンを押したと推測してい,,,,,,,,,,,,,,,,, ,,る。今後は、10個以上の注文数量が入力された場合、注文画面の数量欄に赤色で”！”を表示させる仕様に変更,,,,,,,,,,,,,,,,, ,,する。また、商品集荷一覧表にも、その旨と注文したN会員の電話番号を印刷し、商品集荷時に担当者が電話確,,,,,,,,,,,,,,,,, ,,認できるようにする。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．２　定期的な購買品の煩雑な商品選択・数量入力,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、会員情報管理画面において、定期的に購買する商品と数量を登録させ、注文画面でそれを一括表示さ,,,,,,,,,,,,,,,,, ,,せる仕様を追加する。また、私はその仕様追加をN会員にお知らせメールで通知する。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, 平成１９年度　問３　大規模システムの一部を改造した場合の全体テストの方法について,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,　企業の情報システムは、メインフレームやオープンシステムとして構築された個々のシステムが相互に連携し、大,,,,,,,,,,,,,,,,,, ,規模システムとなっている場合が多い。このような大規模システムの一部を改造する場合、例えば、マスタデータを,,,,,,,,,,,,,,,,,, ,連携させる必要が生じたり、トランザクションデータの量が変化したりするので、連携先システムを含めたテストを行,,,,,,,,,,,,,,,,,, ,い、全体の機能と性能を検証しなければならない。,,,,,,,,,,,,,,,,,, ,　しかし、多くの場合、本番環境や、本番環境と同規模のネットワークやハードウェアを使用してテストすることは難し,,,,,,,,,,,,,,,,,, ,いので、テストの目的を明確にしたうえで、それに代わるテスト環境とテスト方法の策定が必要である。,,,,,,,,,,,,,,,,,, ,　機能を検証するテストでは、大規模システム全体を一気にテストできないことが多く、複数に分割してテストすること,,,,,,,,,,,,,,,,,, ,になる。その際、改造内容に着目して、連携するシステムを模擬するプログラムを準備したり、本番データからテスト,,,,,,,,,,,,,,,,,, ,に必要なデータを抽出したりすることがある。,,,,,,,,,,,,,,,,,, ,　性能を検証するテストでは、データ量や連携のタイミングに着目したテスト項目、テスト環境及びテスト方法の策定,,,,,,,,,,,,,,,,,, ,が重要である。例えば、メッセージ通信による連携システム間のテストを行う場合、過去の実績を基に想定したメッセ,,,,,,,,,,,,,,,,,, ,ージの発生量と集中度を模擬するシミュレータを利用して、負荷試験やタイミング試験を行うことがある。,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,設問ア,,,あなたが開発に携わった大規模システムの概要と、システムの改造内容について、800字以内で述べよ。,,,,,,,,,,,,,,, ,設問イ,,,設問アで述べた大規模システムにおいて、連携先システムを含めた全体テストとして、機能面、性能面で,,,,,,,,,,,,,,, ,,,,どのようなことを検証すべきと考えたか、簡潔に述べよ。また、そのためにはどのようなテストが必要と考え,,,,,,,,,,,,,,, ,,,,、どのようなテスト環境やテスト方法を策定し、検証したか。特に重要と考え、工夫した点を中心に、具体的,,,,,,,,,,,,,,, ,,,,に述べよ。,,,,,,,,,,,,,,, ,設問ウ,,,設問イで述べた全体テストを、あなたはどのように評価しているか。また、今後、改善したい点は何か。そ,,,,,,,,,,,,,,, ,,,,れぞれ簡潔に述べよ。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ■解説,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,■出題趣旨,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　企業の情報システムは、メインフレームやオープンシステムとして構築された個々のシステムが相互に連携し、,,,,,,,,,,,,,,,,, ,,大規模システムとなっている場合が多い。このような大規模システムの一部を改造する場合、連携先システムを,,,,,,,,,,,,,,,,, ,,含めた全体テストを行い、全体の機能と性能を検証しなければならない。,,,,,,,,,,,,,,,,, ,,　しかし、多くの場合、本番環境や、本番環境と同規模のネットワークやハードウェアを使用してテストすることは,,,,,,,,,,,,,,,,, ,,難しいので、それに代わるテスト環境とテスト方法の策定が必要である。,,,,,,,,,,,,,,,,, ,,　本問では、大規模システムの一部を改造した場合の全体テストにおいて、検証すべきと考えた内容と、テスト環,,,,,,,,,,,,,,,,, ,,境やテスト方法について重要と考え、工夫した点を中心に、具体的に論述することを求めている。論述を通じて、,,,,,,,,,,,,,,,,, ,,アプリケーションエンジニアに必要なテストに関する能力・経験などを評価する。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,■採点講評,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　全問に共通して、記述の乱雑なものや誤字脱字が目立つもの、論述内容が理解しづらいものがあった。このよ,,,,,,,,,,,,,,,,, ,,うな論述では、受験者の能力や経験を正しく読み取れない場合もあり得るので、ぜひ留意してもらいたい。,,,,,,,,,,,,,,,,, ,,　問３（大規模システムの一部を改造した場合の全体テストの方法について)では、受験者のテスト経験が豊富で,,,,,,,,,,,,,,,,, ,,あることがうかがえた。しかし、テスト環境とテスト方法の策定に関する工夫の論述は不十分で、実施したテスト,,,,,,,,,,,,,,,,, ,,内容を列挙しただけの論述が多かった。また、”連携先システムを含めた全体テスト”について論述することを期,,,,,,,,,,,,,,,,, ,,待したが、題意と異なり、”改造した部分のテスト”について論述したものが多かった。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,■解説,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,略,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ■解答例,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,（設問ア）,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．私が開発に携わった大規模システムの概要,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　K社は、北日本の地方都市を中心に約150店舗を運営するスーパマーケットである。日本全体の人口減少やコ,,,,,,,,,,,,,,,,, ,,ンビニエンスストアの拡大によって、K社の売上高は微減し続けていた。その当時、大手のスーパマーケットは、イ,,,,,,,,,,,,,,,,, ,,ンターネットで注文を受け付けて、店舗から顧客が指定する場所に注文商品を配達するネットスーパ事業を開始,,,,,,,,,,,,,,,,, ,,していた。K社の経営者層は、経営計画策定時に、ネットスーパ事業への参入とそれに対応するシステム（以下、,,,,,,,,,,,,,,,,, ,,Nシステムという）の開発を決定した。私は、K社の情報システム部に所属するシステムアーキテクトであり、当,,,,,,,,,,,,,,,,, ,,システム開発プロジェクトの設計チームリーダに任命された。K社は、スーパマーケットを効率よく運営するために,,,,,,,,,,,,,,,,, ,,POS端末を使った販売管理システム（以下、既存システムという）を運用している。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．既存システムの改造内容,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　K社の経営者層は、Nシステムの開発費用を抑制するために、既存システムにある機能を極力活用して、Nシス,,,,,,,,,,,,,,,,, ,,テムを開発する制約条件を当開発プロジェクトに課していた。そこで、私は以下5点の既存システムの改造内容を,,,,,,,,,,,,,,,,, ,,設計した。,,,,,,,,,,,,,,,,, ,,,①,K社の会員がNシステムの本社サーバに記録した注文受付情報を、データベースのレプリケーション機能（,,,,,,,,,,,,,,, ,,,,以下、R機能という）を使って、既存システムの店舗サーバに受け入れさせる。,,,,,,,,,,,,,,, ,,,②,店舗担当者が店舗内もしくは店舗に所属する倉庫から商品を集荷し、その商品のバーコードを読み取り、,,,,,,,,,,,,,,, ,,,,POS端末に入力された商品集荷情報が店舗サーバに記録される。,,,,,,,,,,,,,,, ,,,③,店舗担当者は、②の集荷した商品を宅配会社に運送委託するか、もしくは来店した会員に手渡す際に、P,,,,,,,,,,,,,,, ,,,,OS端末を使って商品集荷情報を売上実績情報に変換し、店舗サーバに記録する。,,,,,,,,,,,,,,, ,,,④,③の店舗サーバの売上実績情報を、R機能を使って、既存システムの本社サーバに受け入れさせる。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,（設問イ）,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．機能面・性能面で検証すべきだと考えた点,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、Nシステムが本番稼働を開始すると、売上実績情報の量が増加するので、連携先であるNシステムを含,,,,,,,,,,,,,,,,, ,,めたテストを行い、全体の機能と性能を検証しなければならないと考えた。私は、特に機能面では、Nシステムと,,,,,,,,,,,,,,,,, ,,既存システムの両方の売上実績情報を統合した売上統計分析機能を、性能面ではピーク時の注文受付情報及,,,,,,,,,,,,,,,,, ,,び売上実績情報のR機能を使った本社サーバ・店舗サーバ間の転送性能を検証すべきだと考えた。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．私が策定したテスト環境とテスト方法,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、上記の検証をするためには、本番環境や、本番環境と同規模のネットワークやハードウェアを使用してテ,,,,,,,,,,,,,,,,, ,,ストすることが望ましいと考えた。しかし、K社では、そのテスト環境の確保が困難だった。そこで、私は全体テスト,,,,,,,,,,,,,,,,, ,,の目的を明確にしたうえで、以下2点のそれに代わるテスト環境とテスト方法を策定した。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,①テスト環境,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,　K社内にテスト用のNシステムの本社サーバ、既存システムのテスト用本社サーバ、5台の店舗サーバ、6台,,,,,,,,,,,,,,,, ,,,のルータを設置する。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,②テスト方法,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,　過去3年分の既存システムの売上実績情報とNシステムの本番稼働後に予測される3年分の注文受付情報,,,,,,,,,,,,,,,, ,,,及び売上実績情報を本社サーバ、店舗サーバに配置する。ルータにはK社のネットワーク環境であるIP-VPN,,,,,,,,,,,,,,,, ,,,の運用条件と同じ回線速度を設定する。総合テスト終了後の既存システムとNシステムをインストールし、運,,,,,,,,,,,,,,,, ,,,用手順に基づいて実行する。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,３．私が特に工夫した点,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、機能と性能を検証するテストにおいて、特に以下の工夫をした。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,３．１　機能を検証するテスト,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、既存システムとNシステム全体を一気にテストできないと考え、複数に分割してテストする計画を立案した,,,,,,,,,,,,,,,,, ,,。その際、私は改造内容に着目し、テスト方法やテストデータの内容と組合せにおいて、以下2点の工夫をした。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,①連携するシステムを模擬するプログラムの準備,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,　Nシステムは、テスト実施時点では本番稼働を開始していなかったので、Nシステムの本番データはなかった,,,,,,,,,,,,,,,, ,,,。そこで、私はK社の会員を模擬するプログラムを開発し、注文受付情報をNシステムの本社サーバに追加し,,,,,,,,,,,,,,,, ,,,た。このプログラムは、50万人の会員がWebブラウザから3年間に約1千万件の注文受付情報を作成すること,,,,,,,,,,,,,,,, ,,,を模擬した。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,②本番データからのテストに必要なデータの抽出,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,　既存システムには、テスト実施時点では約4年分の売上実績情報が蓄積されていた。そこで、私はこの本番,,,,,,,,,,,,,,,, ,,,データのうち、テスト実施月の前月度分の売上実績情報を使って、売上統計分析機能を検証するテストを実,,,,,,,,,,,,,,,, ,,,施した。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,３．２　性能を検証するテスト,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、性能を検証するテストでは、データ量や連携のタイミングに着目したテスト項目、テスト環境及びテスト方,,,,,,,,,,,,,,,,, ,,法の策定が重要であると考えた。そこで、私は、R機能を使った本社サーバ、店舗サーバ間の転送性能の負荷試,,,,,,,,,,,,,,,,, ,,験を行う場合に、シミュレータを利用する以下の工夫をした。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,①,Nシステムの本社サーバに注文受付情報を1秒間に約1件ずつ追加する。,,,,,,,,,,,,,,,, ,,②,既存システムの5台の店舗サーバに売上実績情報を約1秒間に合計約2千件ずつ追加する。,,,,,,,,,,,,,,,, ,,③,テスト環境のルータ間のリンク速度をK社が契約しているIP-VPNの平均帯域である１Mbpsにするために、架,,,,,,,,,,,,,,,, ,,,空のトラフィックを当該ルータ間のリンクに流す。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,（設問ウ）,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．設問イで述べた全体テストに対する私の評価,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私が実施した全体テストによって、計画数を超える欠陥が摘出され、Nシステム及び改造後の既存システムは,,,,,,,,,,,,,,,,, ,,順調に稼働している。その意味では、私は適正な全体テストを実施したと評価できる。しかし、下記の2点は不十,,,,,,,,,,,,,,,,, ,,分な箇所を含んでおり、改良の余地があると考えられる。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．１　長すぎる注文受付情報作成時間,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、Nシステムの本社サーバに約1千万件の注文受付情報を作成する模擬プログラムを設計した。この模擬,,,,,,,,,,,,,,,,, ,,プログラムは、SQL（Structured Query Language）のInsert文を繰り返し実行してデータを注文受付情報テーブル,,,,,,,,,,,,,,,,, ,,に追加した。テスト環境に設置したNシステムの本社サーバの磁気ディスク性能が低かったため、この模擬プログ,,,,,,,,,,,,,,,,, ,,ラムは約6日間連続して、全データを追加し終えた。機能テストは順調に実行されたので、問題は発生しなかった,,,,,,,,,,,,,,,,, ,,。しかし、約1千万件の注文受付情報を再作成しなければならなくなった場合、スケジュール遅延リスクが顕在化,,,,,,,,,,,,,,,,, ,,すると考えられた。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．２　手間取るルータ間のリンク速度の設定,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、各ルータとスイッチングハブを10Mbpsで接続した。そして、私は２Mバイトのファイルをある店舗サーバに,,,,,,,,,,,,,,,,, ,,設置し、FTP（File Transfer Protocol）を使って繰り返し本社サーバに転送するプログラムを設計した。当プログラ,,,,,,,,,,,,,,,,, ,,ムは起動時にファイルの転送間隔数秒を指定できた。私はこの指定を使って、トラフィックをルータ間のリンクに,,,,,,,,,,,,,,,,, ,,10Mbps-1Mbps＝9Mbpsの負荷を与えようとしようとした。しかし、サーバのCPU率の変化やファイルキャッシュの,,,,,,,,,,,,,,,,, ,,状況によって、ルータ間のリンク速度は0.8～1.2Mbps間で振れ、１Mbps程度に収束させにくかった。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．今後改善したい点,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は上記の評価に対し、以下の改善を実行する。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．１　長すぎる注文受付情報作成時間,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、注文受付情報作成時間の多くは、SQLのInsert文の解釈実行時間であると考えている。そこで、今後私,,,,,,,,,,,,,,,,, ,,は注文受付情報をCSVファイルとして作成し、DBMSに付属するユーティリティを使って、テーブルに取り込む。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．２　手間取るルータ間のリンク速度の設定,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、Nシステムの本番稼働後に、架空データを自動的に作り、使用可能帯域をbps単位で設定できるソフトウ,,,,,,,,,,,,,,,,, ,,ェアツールを見つけ出した。今後私は、これをテスト環境の本社サーバで動作させ、ルータ間のリンク速度を調整,,,,,,,,,,,,,,,,, ,,する。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, 平成20年度　問1　システム要件定義の準備について,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,　システム要件定義（以下、要件定義という）は、限られた期間内で品質を確保し、かつ、効率よく行うことが求められ,,,,,,,,,,,,,,,,,, ,るので、ユーザとの打ち合わせを実施するに当たっては、事前の準備が大切である。,,,,,,,,,,,,,,,,,, ,　アプリケーションエンジニアは、準備に当たって、メンバの経験やスキル、対象業務の特徴を踏まえ、例えば、次の,,,,,,,,,,,,,,,,,, ,ような工夫をしなければならない。,,,,,,,,,,,,,,,,,, ,,・,要件定義を行うメンバのスキルを補強し、メンバ間のコミュニケーションが円滑に行われるよう、業界知識や業,,,,,,,,,,,,,,,, ,,,務要件などテーマを厳選した勉強会を行う。,,,,,,,,,,,,,,,, ,,・,ヒアリングの対象者は、その組織や立場を考慮して選定し、対象者に合わせたヒアリングシナリオを作成して,,,,,,,,,,,,,,,, ,,,おく。,,,,,,,,,,,,,,,, ,,・,関係する資料の提供をユーザに依頼する際、ユーザが準備しやすいようにサンプルを提示する。,,,,,,,,,,,,,,,, ,,・,システムや業務機能が類似しているほかのシステムの要件を参考にし、確認すべき要件をリストアップしてお,,,,,,,,,,,,,,,, ,,,く。,,,,,,,,,,,,,,,, ,　これらの事前の準備結果を基に、ユーザと開発者の両者でそれぞれが行うべきことや協力して行うべきことを確認,,,,,,,,,,,,,,,,,, ,・合意して要件定義を進めることが重要である。,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,設問ア,,,あなたが開発に携わったシステムの概要と対象業務の特徴について、800字以内で述べよ。,,,,,,,,,,,,,,, ,設問イ,,,設問アで述べたシステムの要件定義において、限られた期間内で品質を確保し、かつ、効率よく行うため,,,,,,,,,,,,,,, ,,,,に、あなたはどのような準備をしたか。要件定義を行うメンバの経験やスキル、対象業務の特徴を踏まえて,,,,,,,,,,,,,,, ,,,,、重要と考え、工夫した点を中心に、具体的に述べよ。,,,,,,,,,,,,,,, ,設問ウ,,,設問イで述べた準備について、あなたはどのように評価しているか。また、今後改善したい点は何か。それ,,,,,,,,,,,,,,, ,,,,ぞれ簡潔に述べよ。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ■解説,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,■出題趣旨,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　システム要件定義は、限られた期間内で品質を確保し、かつ、効率よく行うことが求められるので、ユーザとの,,,,,,,,,,,,,,,,, ,,打ち合わせを実施するに当たっては、事前の準備が大切である。,,,,,,,,,,,,,,,,, ,,　アプリケーションエンジニアは、準備に当たって、メンバの経験やスキル、対象業務の特徴を踏まえ、工夫をしな,,,,,,,,,,,,,,,,, ,,ければならない。また、これらの事前の準備結果を基に、ユーザと開発者の両者でそれぞれが行うべきことを協,,,,,,,,,,,,,,,,, ,,力して行うべきことを確認・合意して進めることが重要である。,,,,,,,,,,,,,,,,, ,,　本問では、システム要件定義の品質を確保し、かつ、効率よく行うために準備した内容を問うことによって、アプ,,,,,,,,,,,,,,,,, ,,リケーションエンジニアとしてのシステム要件定義に関する能力・経験などを評価する。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,■採点講評,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　全問に共通して、規程字数に満たないもの、記述の乱雑なものや誤字脱字が目立つもの、論述内容が理解し,,,,,,,,,,,,,,,,, ,,づらいものがあった。このような論述では、受験者の能力や経験を正しく読み取れない場合もあり得るので、ぜひ,,,,,,,,,,,,,,,,, ,,留意してもらいたい。,,,,,,,,,,,,,,,,, ,,　問１（システム要件定義の準備について）は選択率が最も高く、多くの受験者が要件定義を経験していることが,,,,,,,,,,,,,,,,, ,,うかがえた。しかし、品質を確保し、かつ、効率よく行うための事前の準備に関する工夫の論述は不十分で、作業,,,,,,,,,,,,,,,,, ,,内容を列挙しただけの論述も多く、設計以降の準備に関する論述も散見された。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ■解答例,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,（設問ア）,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．私が開発に携わったシステムの概要,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　K社は、北日本の地方都市を中心に約150店舗を運営するスーパマーケットである。日本全体の人口減少やコ,,,,,,,,,,,,,,,,, ,,ンビニエンスストアの拡大によって、K社の売上高は微減し続けていた。その当時、大手のスーパマーケットは、イ,,,,,,,,,,,,,,,,, ,,ンターネットで注文を受け付けて、店舗から顧客が指定する場所に注文商品を配達するネットスーパ事業を開始,,,,,,,,,,,,,,,,, ,,していた。K社の経営者層は、経営計画策定時に、ネットスーパ事業への参入とそれに対応するシステム（以下、,,,,,,,,,,,,,,,,, ,,Nシステムという)の開発を決定した。Nシステムの概要は、,,,,,,,,,,,,,,,,, ,,,①,アプリケーションサーバ10台、データベースサーバ3台をN社の情報システム部に設置する。,,,,,,,,,,,,,,, ,,,②,アプリケーションソフトウェアのうち、クライアントPC側はWebブラウザ上で動作するJavaスクリプト、サーバ,,,,,,,,,,,,,,, ,,,,側はJavaサーブレットを使用する。,,,,,,,,,,,,,,, ,,である。私は、K社の情報システム部に所属するシステムアーキテクトであり、Nシステム開発プロジェクトの設計,,,,,,,,,,,,,,,,, ,,チームリーダに任命された。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．当システムの対象業務の特徴,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　Nシステムが対象とする主な業務は、会員管理業務、注文受付業務、商品集荷業務、商品引渡業務、店舗運営,,,,,,,,,,,,,,,,, ,,管理業務である。注文受付業務の大半は、顧客が操作するWebブラウザの注文画面によってなされ、その良否,,,,,,,,,,,,,,,,, ,,がネットスーパ事業の業績を左右するので、注文受付業務の要件定義が最も重要だった。K社の情報システム部,,,,,,,,,,,,,,,,, ,,の部長は、要件定義のヒアリングを受けたり、要件定義書案のレビューや承認を行ったりするユーザ（以下、代表,,,,,,,,,,,,,,,,, ,,ユーザという）を、店舗の店長・担当者の中から10名を選出した。私は、代表ユーザの経歴・スキル記述書を査閲,,,,,,,,,,,,,,,,, ,,した。しかし、顧客がWebブラウザを使って商品の注文をするシステムの運用経験がある者はいなかった。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,（設問イ）,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．私が実施した要件定義の準備,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、要件定義は限られた期間内で品質を確保し、かつ、効率よく行うことが求められると考えた。そこで、私は,,,,,,,,,,,,,,,,, ,,代表ユーザとの打ち合わせを実施するに当たって、事前の準備を実施した。例えば、私はプロジェクトマネージャ,,,,,,,,,,,,,,,,, ,,が作成したNシステム開発プロジェクト計画書を査読し、当プロジェクトの目標やNシステムの開発目的を確認した,,,,,,,,,,,,,,,,, ,,。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．メンバの経験やスキルなどを踏まえて工夫した点,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、要件定義の準備に当たって、メンバの経験やスキル、対象業務の特徴を踏まえ、以下の4点の工夫をし,,,,,,,,,,,,,,,,, ,,た。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．１　テーマを厳選した勉強会の実施,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、要件定義を行う代表ユーザのスキルを補強し、代表ユーザ間のコミュニケーションが円滑に行われるよ,,,,,,,,,,,,,,,,, ,,う、Webアクセシビリティや最新マーケティング技法などテーマを厳選した勉強会を行った。例えば、代表ユーザ,,,,,,,,,,,,,,,,, ,,は、Webアクセシビリティに関して、W3Cが公表しているWCAGや操作しやすいWeb画面の事例などを6時間学習,,,,,,,,,,,,,,,,, ,,した。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．２　対象者に合わせたヒアリングシナリオの作成,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、ヒアリングの前に、代表ユーザに合わせた2種類のヒアリングシナリオを作成した。その１つは、店舗の店,,,,,,,,,,,,,,,,, ,,長向けのヒアリングシナリオであり、もう1つは店舗担当者向けのものだった。前者は、割引サービスやポイントを,,,,,,,,,,,,,,,,, ,,得る会員を増大させるための施策など、K社の営業政策もしくはそれに付随するNシステム全体の課題が中心と,,,,,,,,,,,,,,,,, ,,なった。後者は、商品集荷業務などの業務手順や予想される問題点が中心となった。特に、私は前者について、,,,,,,,,,,,,,,,,, ,,具体的な営業政策を確定させるために、店舗運営上順守しなければならない制約条件と想定する前提条件を最,,,,,,,,,,,,,,,,, ,,初にヒアリングするシナリオにした。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．３　ユーザが提供する資料のサンプルの提示,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、代表ユーザのうち店舗担当者に、注文画面の例を作成・提供させることにした。この目的は、注文受付業,,,,,,,,,,,,,,,,, ,,務の要件に関する理解を深めさせ、外部設計以降のフェーズでの仕様変更の発生を防止するためだった。私は,,,,,,,,,,,,,,,,, ,,、注文画面の例の作成・提供をユーザに依頼する際、ユーザが準備しやすいようにサンプルを10枚提示した。私,,,,,,,,,,,,,,,,, ,,はこれらのサンプルを、ネットスーパ事業を運営している大手のスーパマーケット、書籍のインターネット販売会社,,,,,,,,,,,,,,,,, ,,、お寿司や弁当の宅配会社などが開設しているWebサイトの画面例を見本にして作成した。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．４　確認すべき要件のリストアップ,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、見本となるNシステムの対象業務機能が類似している他システムを、大手のスーパマーケット３社のネッ,,,,,,,,,,,,,,,,, ,,トスーパ事業のシステムに特定した。私は、その3社の業務要件を比較表に整理し、確認すべき要件を質問書と,,,,,,,,,,,,,,,,, ,,してリストアップした。例えば、,,,,,,,,,,,,,,,,, ,,,①,1回の基本配送料、無料配送になる最低購入額,,,,,,,,,,,,,,, ,,,②,配達可能地域,,,,,,,,,,,,,,, ,,,③,支払方法（振込・クレジットカード・代金引換など）,,,,,,,,,,,,,,, ,,,④,注文方法（電話・インターネットサイト・モバイルサイト・FAX）,,,,,,,,,,,,,,, ,,,⑤,商品受取方法（自宅に宅配・指定された場所に宅配・店舗で引渡）,,,,,,,,,,,,,,, ,,,⑥,注文受付後の最短配達時間（12時間・24時間・36時間・48時間）,,,,,,,,,,,,,,, ,,などだった。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,３．私が行った要件定義の進め方,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、上記の事前の準備結果を基に、代表ユーザと設計チームメンバの両者でそれぞれが行うべきことや協力,,,,,,,,,,,,,,,,, ,,して行うべきことを確認・合意して要件定義を進めた。例えば、代表ユーザが機能要件の原案、設計チームメンバ,,,,,,,,,,,,,,,,, ,,が非機能要件の原案を作成することとした。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,（設問ウ）,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．設問イで述べた準備に対する私の評価,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私が実施した要件定義の準備は、予定した効果を発揮し、Nシステムは順調に稼働している。その意味では、,,,,,,,,,,,,,,,,, ,,私は正しい要件定義の準備をしたと評価できる。しかし、下記の２つには不十分な点があり、改良の余地がある,,,,,,,,,,,,,,,,, ,,と考えられる。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．１　ネットスーパ事業に関する勉強会の実施,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、店舗担当者に注文画面の例を依頼した際、”ネットスーパ事業の勉強会も実施すべきである”との指摘を,,,,,,,,,,,,,,,,, ,,受けた。店舗担当者の中には、ネットスーパを利用した経験がない者が2名いた。スーパマーケットであるK社の,,,,,,,,,,,,,,,,, ,,社員ならば、当然、ネットスーパ事業の概要を知っているはずだと考えた私が間違っていた。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．２　質問書に記述した確認要件の条件設定,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、作成した質問書に基づいて、配達可能地域を店舗担当者にヒアリングした。私は”店舗から半径15km以,,,,,,,,,,,,,,,,, ,,内”といった回答を期待した。しかし、店舗担当者は”店舗での作業は多忙であり、配達できない”と回答した。質,,,,,,,,,,,,,,,,, ,,問書に記述した配達可能地域に関する、確認要件の条件設定が不十分だった。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．今後改善したい点,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は上記の評価に対し、以下の改善を実行する。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．１　ネットスーパ事業に関する勉強会の実施,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、ネットスーパ事業のような常識に近い業界知識であっても、勉強会のテーマの候補に組み入れる。さらに,,,,,,,,,,,,,,,,, ,,、私はそれらのテーマの候補を代表ユーザに確認させ、優先順位を決めさせる。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．２　質問書に記述した確認要件の条件設定,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、配達可能地域をヒアリングする際、配達する者が店舗担当者の場合と、宅配会社の場合に分けた質問,,,,,,,,,,,,,,,,, ,,書を準備する。また、顧客に約束する注文受付後の最短配達時間など、配達可能地域を制約する条件も質問書,,,,,,,,,,,,,,,,, ,,に追記する。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, 平成20年度　問2　フレームワークの利用について,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,　最近、システムの開発にフレームワークを利用するケースが増えている。フレームワークを効果的に利用すること,,,,,,,,,,,,,,,,,, ,が出来れば、対象システムの品質を確保し、生産性の向上が期待できる。,,,,,,,,,,,,,,,,,, ,　ただし、フレームワークの利用においては、例えば、利用方法の習得時間の短縮、機能や性能面での制約への対,,,,,,,,,,,,,,,,,, ,応、機能の利用方法に関する開発者間のばらつきの統制、業務機能の効率の良い設計・開発などの課題に直面す,,,,,,,,,,,,,,,,,, ,ることがある。,,,,,,,,,,,,,,,,,, ,　アプリケーションエンジニアは、これらの課題を解決するために、利用するフレームワークの経験者や専門家の協,,,,,,,,,,,,,,,,,, ,力を得ながら、次のような対策を実施しなければならない。,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,・,利用方法の習得時間を短縮するために、専用の開発支援環境や利用ガイドを整備する。,,,,,,,,,,,,,,,, ,,・,機能や性能面での制約に対応するために、フレームワークの一部をほかのフレームワークや独自に作成した,,,,,,,,,,,,,,,, ,,,ソフトウェアなどで代替する。,,,,,,,,,,,,,,,, ,,・,機能の利用方法に関する開発者間のばらつきを統制するために、利用規約を作成して周知徹底を図ったり、,,,,,,,,,,,,,,,, ,,,利用する機能に制限を加えたりする。,,,,,,,,,,,,,,,, ,,・,業務機能を効率よく設計・開発するために、フレームワークに基づいて、業務機能用のテンプレートや業務共,,,,,,,,,,,,,,,, ,,,通の機能を設計・開発し、各業務機能の設計・開発でそれらを利用する。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,　これらの対策を、システムの規模、要求される性能や信頼性の水準などのシステムの特性、開発要員のスキルな,,,,,,,,,,,,,,,,,, ,どを考慮して、効果的に実施しなければならない。,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,設問ア,,,あなたが開発に携わったシステム、および利用したフレームワークの概要について、800字以内で述べよ。,,,,,,,,,,,,,,, ,設問イ,,,設問アで述べたフレームワークを利用するために課題と認識したことは何か。また、それらの課題を解決,,,,,,,,,,,,,,, ,,,,するために、システムの規模、システムの特性、開発要員のスキルなどを考慮して、どのような対策をどの,,,,,,,,,,,,,,, ,,,,ように効果的に実施したか。重要と考えた点を中心に、具体的に述べよ。,,,,,,,,,,,,,,, ,設問ウ,,,設問イで述べた対策について、あなたはどのように評価しているか。また、今後、改善したい点は何か。,,,,,,,,,,,,,,, ,,,,それぞれ簡潔に述べよ。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ■解説,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,■出題趣旨,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　生産性や品質を向上させることを目的に、アプリケーションの開発にフレームワークを利用するケースが増えて,,,,,,,,,,,,,,,,, ,,いる。ただし、フレームワークの利用においては、利用方法の習得時間の短縮、機能や性能面での制約への対,,,,,,,,,,,,,,,,, ,,応、機能の利用方法に関する開発者間のばらつきの統制、業務機能の効率の良い設計・開発などの解決すべき,,,,,,,,,,,,,,,,, ,,課題がある。,,,,,,,,,,,,,,,,, ,,　本問では、フレームワークの利用に当たって、どのような課題を認識し、その課題を、対象システムの規模、シ,,,,,,,,,,,,,,,,, ,,ステムの特性、開発要員のスキルなどを考慮して、どのような対策をどのように効果的に実施して解決したかを,,,,,,,,,,,,,,,,, ,,具体的に論述することを求めている。論述を通じて、アプリケーションエンジニアとしてのシステム設計におけるツ,,,,,,,,,,,,,,,,, ,,ールや技法の適応能力、課題設定能力や課題解決能力を評価する。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,■採点講評,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　全問に共通して、規程字数に満たないもの、記述の乱雑なものや誤字脱字が目立つもの、論述内容が理解し,,,,,,,,,,,,,,,,, ,,づらいものがあった。このような論述では、受験者の能力や経験を正しく読み取れない場合もあり得るので、ぜひ,,,,,,,,,,,,,,,,, ,,留意してもらいたい。,,,,,,,,,,,,,,,,, ,,　問２（フレームワークの利用について）では、フレームワークを利用した経験がある受験者が数多くいることがう,,,,,,,,,,,,,,,,, ,,かがえた。フレームワークの利用における課題については、おおむねよくかけていた。しかし、課題に対する対策,,,,,,,,,,,,,,,,, ,,についての論述は不十分で、具体性に欠ける論述が多かった。また、対策をどのように効果的に実施したかを論,,,,,,,,,,,,,,,,, ,,述することを期待したが、実施した対策を列挙するだけの論述が多かった。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ■解答例,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,（設問ア）,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．私が開発に携わったシステムの概要,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　K社は、北日本の地方都市を中心に約150店舗を運営するスーパマーケットである。日本全体の人口減少やコ,,,,,,,,,,,,,,,,, ,,ンビニエンスストアの拡大によって、K社の売上高は微減し続けていた。その当時、大手のスーパマーケットは、イ,,,,,,,,,,,,,,,,, ,,ンターネットで注文を受け付けて、店舗から顧客が指定する場所に注文商品を配達するネットスーパ事業を開始,,,,,,,,,,,,,,,,, ,,していた。K社の経営者層は、経営計画策定時に、ネットスーパ事業への参入とそれに対応するシステム(以下、,,,,,,,,,,,,,,,,, ,,Nシステムという）の開発を決定した。その当時、システムの開発にフレームワークを利用するケースが増えてい,,,,,,,,,,,,,,,,, ,,た。K社のITストラテジストは、Nシステムの品質確保と生産性の向上を期待して、フレームワークを効果的に利用,,,,,,,,,,,,,,,,, ,,することを個別システム計画書の制約条件として記載していた。私は、K社の情報システム部に所属するシステ,,,,,,,,,,,,,,,,, ,,ムアーキテクトであり、Nシステム開発プロジェクトの設計チームリーダに任命された。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．利用したフレームワークの概要,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私が利用したフレームワーク（以下、Sフレームワークという）の概要は、以下のとおりである。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,①,基本ソフトウェア及びJavaVM（Virtual Machine）とWebアプリケーションの間に位置し、開発するWebアプリ,,,,,,,,,,,,,,, ,,,,ケーションに共通して必要となる機能をJavaクラスのライブラリ化している。,,,,,,,,,,,,,,, ,,,②,提供される主な機能は、下記の3点である。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,（a）セッション管理,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,,　サーバとクライアントPCのWebブラウザの組み合わせを識別するためのセッションIDを管理する。,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,（b）テンプレート管理機能,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,,　デザイナーによって作成されるHTML文書とJavaプログラムによって自動生成されるHTML文書を分離,,,,,,,,,,,,,, ,,,,,して管理する。,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,（c）認証管理,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,,　IDとパスワードによってネットスーパの会員を識別する。入会・退会・パスワードの変更を管理する。,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,（設問イ）,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．フレームワークを利用するために認識した課題,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、フレームワークの利用において、以下の4点の課題を認識した。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．１　利用方法の習得時間の短縮,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　設計チームの半数のメンバは、Sフレームを使った経験がなかった。Sフレームには、設問アで述べた主な機能,,,,,,,,,,,,,,,,, ,,以外に、,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,①,Javaサーブレットを経由してデータベースにアクセスする機能,,,,,,,,,,,,,,, ,,,②,会員が入力した郵便番号等をWebブラウザ上でチェックするJavaスクリプトを自動生成する機能,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,などの多岐にわたる機能があった。したがって、Sフレームのすべての機能を利用するためには、30日程度の研,,,,,,,,,,,,,,,,, ,,修期間が必要だった。しかし、Nシステムは、短納期で開発されなければならず、Sフレームを利用するための習,,,,,,,,,,,,,,,,, ,,得時間の短縮が求められた。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．２　機能や性能面での制約,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　Sフレームには、以下のような機能や性能面での制約があった。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,①,Java以外のPerlやPHPなどの他言語を使用できない。,,,,,,,,,,,,,,, ,,,②,Ajaxを利用できない。,,,,,,,,,,,,,,, ,,,③,Webサーバを複数台設置し、導入予定の負荷分散装置と組み合わせて使用した場合の性能評価データが,,,,,,,,,,,,,,, ,,,,ない。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．３　機能の利用方法に関する開発者間のばらつき,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　設計チームのメンバの1人であるQ氏は、Sフレームを熟知しており、その高度な利用も可能だった。したがって、,,,,,,,,,,,,,,,,, ,,Q氏とSフレームの未経験者では、Sフレームの利用方法に関するばらつきが発生すると予想された。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．４　業務機能の効率の良い設計・開発,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　K社の経営者層およびプロジェクトマネージャは、Nシステムの開発費抑制を強く要望していた。私は、Sフレー,,,,,,,,,,,,,,,,, ,,ムを多用し、Nシステムの規模を考慮して業務機能を効率よく設計・開発しなければならなかった。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．課題を解決するために実施した対策,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、上記の課題を解決するために、利用するSフレームの経験者や専門家の協力を得ながら、以下の4点の,,,,,,,,,,,,,,,,, ,,対策を実施した。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．１　専用の開発支援環境や利用ガイドの整備,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、Sフレームに関するスキルの習得時間を短縮するために、,,,,,,,,,,,,,,,,, ,,,①,Sフレーム専用の開発支援環境・テスト環境を整備した。私はこの環境の利用制限を置かず、設計チーム,,,,,,,,,,,,,,, ,,,,のメンバのSフレームに関する疑問点を即時に解消させた。,,,,,,,,,,,,,,, ,,,②,Sフレームを活用した開発標準・Sフレームの利用ガイドを整備した。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．２　機能面での制約への対応,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は機能面での制約に対応するために、独自に作成したJavaスクリプトで代替した。その独自に作成した部分,,,,,,,,,,,,,,,,, ,,は、K社の店舗の所在地を地図で示すものだった。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．３　性能面での制約への対応,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は性能での制約に対応するために、本番環境と同一の運用環境を整備し、Nシステムの特性を考慮してWeb,,,,,,,,,,,,,,,,, ,,サーバに大量の問い合わせを発生させるシミュレータを開発し実行した。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．４　利用規約の作成と利用に関する機能の制限,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、Sフレームのスキルに関する開発者間のばらつきを統制するために、Sフレームの利用規約を作成して周,,,,,,,,,,,,,,,,, ,,知徹底を図り、Sフレームの利用機能に制限を加えた。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,３．特に重要と考えた点,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、業務機能の効率の良い設計・開発をするために、各設計者が独自に設計を進めるのではなく、Sフレー,,,,,,,,,,,,,,,,, ,,ムの画面テンプレートに基づいて、それから外れない設計を行わせた。もし、画面テンプレートから外れる設計を,,,,,,,,,,,,,,,,, ,,行う場合は、私の承認を得なければならないこととした。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,（設問ウ）,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．設問イで述べた対策の評価,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　Sフレームは私が予定した通りに利用され、Nシステムは順調に稼働している。その意味では、私は効果的なS,,,,,,,,,,,,,,,,, ,,フレームの利用をしたと評価できる。しかし、下記の２つは不十分な点があり、改良の余地があると考えられる。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．１　開発者間の設計のばらつき,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　Sフレームは、①処理を要求するアクションを実行する。②結果を出力するHTMLデータを表示のレイヤに押し込,,,,,,,,,,,,,,,,, ,,む、いわゆる”プッシュ型”アーキテクチャを採用していた。しかし、開発者の中には、逆の②①の順で処理を実行,,,,,,,,,,,,,,,,, ,,させる、いわゆる”プル型”に近い設計をするものがおり、開発者間での設計のばらつきが一部存在した。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．２　画面テンプレートから固執しすぎた設計,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　プログラミングを完了してみると、その生産性が平均値の約40％しかないプログラムが3つあった。その原因を,,,,,,,,,,,,,,,,, ,,調査してみると、設計者が画面テンプレートに固執しすぎた設計をしていた。そのため、画面テンプレートが提供,,,,,,,,,,,,,,,,, ,,する機能を迂回するソースプログラムの記述量が増加していた。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．今後改善したい点,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は上記の評価に対し、以下の改善を実行する。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．１　開発者間の設計のばらつき,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は今後、開発標準・Sフレームの利用ガイド・利用規約に記載されていないプログラム構造設計をしようとする,,,,,,,,,,,,,,,,, ,,場合、Sフレームの熟達者であるQ氏に相談させる。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．２　画面テンプレートから固執しすぎた設計,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、開発標準・Sフレームの利用ガイドに、画面テンプレートを使用しない方が良い設計事例を追記する。そ,,,,,,,,,,,,,,,,, ,,の追記する事例は、生産性が低くなった設計箇所、増加するソースプログラムの記述例、実施すべき画面設計な,,,,,,,,,,,,,,,,, ,,どにする。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, 平成２１年度　問１　要件定義,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,　システムアーキテクトは、要件定義において、ユーザ要求をヒアリングし、その要求を正しく理解したうえで、システ,,,,,,,,,,,,,,,,,, ,ムの要件としてドキュメントにまとめ、ユーザに確認する。,,,,,,,,,,,,,,,,,, ,　しかし、ユーザから提示された要求に漏れがあったり、ユーザ要求の意味を取り違えたりすると、システムから出,,,,,,,,,,,,,,,,,, ,力された情報が想定したものと異なったり、必要な情報の提供タイミングが遅くなったりするなど、本来、ユーザが,,,,,,,,,,,,,,,,,, ,求めているシステムにはならないことがある。したがって、システムアーキテクトは、次のような点に留意して、ユーザ,,,,,,,,,,,,,,,,,, ,要求をヒアリングし、その要求を正しく理解することが大切である。,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,・,ユーザから提示された個々の要求に矛盾がないか。,,,,,,,,,,,,,,,, ,,・,ユーザ要求として提示されるべき業務手順や法的な制約などが、ユーザ部門内では自明のこととして、省略さ,,,,,,,,,,,,,,,, ,,,れていないか。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,　その上で、要件としてまとめるために、対象業務をモデル化したり、ユーザ要求を可視化したりする。その際、ユー,,,,,,,,,,,,,,,,,, ,ザとの認識の相違をなくすために、次のような工夫を行うことが重要である。,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,・,モデルを分かりやすく表記するためにUMLを用いたり、言葉の定義を統一するために用語辞書を作成したりす,,,,,,,,,,,,,,,, ,,,る。,,,,,,,,,,,,,,,, ,,・,現行業務とシステム構築後の業務の変更点を明確にするために、両者の対比表を作成する。,,,,,,,,,,,,,,,, ,,・,システムによって実現する機能と運用によって行う作業を明確にするために、業務の流れ、処理のタイミング,,,,,,,,,,,,,,,, ,,,を記述した業務フロー図を作成する,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,設問ア,,,あなたが要件定義に携わったシステムについて、対象業務の概要とシステム開発の目的を、800字以内で,,,,,,,,,,,,,,, ,,,,述べよ。,,,,,,,,,,,,,,, ,設問イ,,,設問アで述べたシステムについて、ユーザ要求を正しく理解するために、あなたはどのような点に留意して,,,,,,,,,,,,,,, ,,,,ユーザ要求をヒアリングし、どのように要件としてまとめたか。800字以上1600字以内で具体的に述べよ。,,,,,,,,,,,,,,, ,設問ウ,,,設問イで述べた要件をまとめる際、ユーザとの認識の相違をなくすために、重要と考え工夫した点につい,,,,,,,,,,,,,,, ,,,,て、600字以上1200字以内で具体的に述べよ。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ■ポイント,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,■出題趣旨,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　要件定義では、ユーザ要求をヒアリングし、その要求を正しく理解した上で、システムの要件としてドキュメントに,,,,,,,,,,,,,,,,, ,,まとめ、ユーザに確認する。しかしながら、ユーザ要求に漏れがあったり、ユーザ要求の意味を取り違えたりする,,,,,,,,,,,,,,,,, ,,と、本来、ユーザが求めているシステムにはならないことがある。,,,,,,,,,,,,,,,,, ,,　本問は、ユーザ要求をどのような点に留意してヒアリングし、どのように要件としてまとめたか、また、その要件,,,,,,,,,,,,,,,,, ,,をまとめる際、ユーザとの認識の相違をなくすために、どのような工夫をしたか具体的に論述することを求めてい,,,,,,,,,,,,,,,,, ,,る。,,,,,,,,,,,,,,,,, ,,　本問では、論述を通じて、システムアーキテクトに必要な要求分析能力や要件定義能力を評価する。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,■採点講評,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　全問に共通して、文字の記述が乱雑なものや誤字脱字が目立つもの、論旨がはっきりせず論述内容が理解し,,,,,,,,,,,,,,,,, ,,づらいものがあった。このような論述では、論述内容を正しく読み取れない場合もあるので、ぜひ留意してもらい,,,,,,,,,,,,,,,,, ,,たい。また、一般論や問題文の引用に終始するものも目立った。このような論述では、受験者の能力や経験を正,,,,,,,,,,,,,,,,, ,,しく評価できない場合がある。対象業務との関連や実際の経験を踏まえて具体的に論述してほしい。,,,,,,,,,,,,,,,,, ,,　問１（要件定義について）では、ユーザ要求をヒアリングする際の留意点、どのように要件としてまとめたか、まと,,,,,,,,,,,,,,,,, ,,める際の工夫についての論述を求めたが、ヒアリングに関する記述がないものや、留意点が不明確なもの、作業,,,,,,,,,,,,,,,,, ,,の記述に終始しているものが目立った。また、”ヒアリングする際の留意点”、”まとめる際の工夫した点”の記述,,,,,,,,,,,,,,,,, ,,ではなく、要件定義の内容をそのまま論述したものが散見された。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,■解説,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,　ユーザが求めているシステムを構築するために、要件定義の工程においてユーザの要求を正しく理解することが,,,,,,,,,,,,,,,,,, ,テーマの問題である。要件定義では、ユーザ要求のヒアリング、要求の正しい理解、システム要件のドキュメント化、,,,,,,,,,,,,,,,,,, ,ユーザとの合意などの作業が必要である。システムアーキテクトに相応のスキルがあってもユーザが適切に要求を,,,,,,,,,,,,,,,,,, ,提示できない場合や、システムアーキテクトがユーザの要求を正しく理解できない場合などは、要件定義が不完全,,,,,,,,,,,,,,,,,, ,になり、完成したシステムはユーザの期待するシステムとは異なってしまう。,,,,,,,,,,,,,,,,,, ,　システムアーキテクトは、ユーザの要求を正しく理解するために、「ユーザから提示された個々の要求に矛盾がな,,,,,,,,,,,,,,,,,, ,い」ことや「ユーザにとって自明な事項が省略されていない」ことに留意しなければならない。ユーザの要求を踏まえ,,,,,,,,,,,,,,,,,, ,、システムの要件をまとめる際には、ユーザとの認識の相違が生じないよう、対象業務のモデルを分かりやすく表現,,,,,,,,,,,,,,,,,, ,する工夫や、新旧の業務の比較をする工夫なども必要である。,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,　設問アでは、「対象業務の概要」と「システム開発の目的」を記述する。複数の要求事項がある場合、論旨が乱れ,,,,,,,,,,,,,,,,,, ,ないようにしながら、一つの見出しの中にまとめて記述することもできる。例えば、「業務の現状の問題点を解消する,,,,,,,,,,,,,,,,,, ,」ことを「対象業務の概要」と「システム開発の目的」という二つの見出しの下で記述しようとすると、問題点そのもの,,,,,,,,,,,,,,,,,, ,は「対象業務の概要」に含まれ、問題点の解消は「システム開発の目的」に含まれるときがある。このような場合、問,,,,,,,,,,,,,,,,,, ,題点と問題点の解消を区分けして記述しにくくなるため、「対象業務の概要とシステム開発の目的」と見出しを一つ,,,,,,,,,,,,,,,,,, ,にして「業務の現状の問題点を解消する」ということを記述してもよい。,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,　設問イでは、「ユーザ要求をヒアリングするときの留意点」と「まとめたシステム要件」を記述する。要件定義があい,,,,,,,,,,,,,,,,,, ,まいになったり、不正確になったりしないように、どのような点に留意してヒアリングをしたかということが、設問イの記,,,,,,,,,,,,,,,,,, ,述の中心となる。「まとめたシステム要件」については、結果の記述であり、おのずと記述量は少なくなる。設問イを8,,,,,,,,,,,,,,,,,, ,00字以上記述するためには、「ユーザ要求をヒアリングするときの留意点」を意図的に多く記述したい。逆に、記述し,,,,,,,,,,,,,,,,,, ,たいことが多く解答用紙が不足しそうになったときは、事前に検討したストーリーを取捨選択しながら記述するとよい,,,,,,,,,,,,,,,,,, ,。,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,　設問ウでは、「重要と考え工夫した点」を記述する。要求事項が一点のみであるため、「重要と考え工夫した点」を,,,,,,,,,,,,,,,,,, ,複数記述にしないと、設問ウの解答字数の下限600字に達しない可能性がある。事前に検討したストーリーになかっ,,,,,,,,,,,,,,,,,, ,たことを付け加えることは、論旨の展開から考えても困難であるし、かつ論述の流れを乱すことになる。十分な量の,,,,,,,,,,,,,,,,,, ,ストーリーを準備しておきたい。,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ■見出しとストーリー,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,■設問ア,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　設問アには、問題文に直接対応する部分がない。自身の経験に基づき要求事項を記述する。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,設問ア,,,あなたが要件定義に携わったシステムについて、対象業務の概要とシステム開発の目的を、800字,,,,,,,,,,,,, ,,,,,,以内で述べよ。,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　例として次のような見出しとストーリーが考えられる。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,ア　対象業務の概要とシステム開発の目的,,,,,,,,,,,,,,,, ,,,ア―１　対象業務の概要,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,・,機械製造業A社の設計部門では、設計者を支援する設計技術支援システムが稼働している,,,,,,,,,,,,,, ,,,,・,設計技術支援システムは、設計者が、過去の設計情報や部品の情報をデータベースから検索し、必要,,,,,,,,,,,,,, ,,,,,に応じて情報を流用できるようになっており、設計作業の生産性の向上、品質の向上を図ることを主な,,,,,,,,,,,,,, ,,,,,目的としている,,,,,,,,,,,,,, ,,,,・,設計技術支援システムは、設計者にとって必須のシステムになっている,,,,,,,,,,,,,, ,,,,・,A社の設計部門は、製造する機械の種類によって三つの部門に分かれている,,,,,,,,,,,,,, ,,,,・,各部門は独立性が高く、部門独自の業務ルールなどが存在し、現状の設計技術支援システムは各部,,,,,,,,,,,,,, ,,,,,門が個々に立ち上げたシステムである,,,,,,,,,,,,,, ,,,,・,大きな部門では小型汎用機による設計技術支援システムを導入しており、小規模な部門ではオフコン,,,,,,,,,,,,,, ,,,,,ベースのシステムを稼働させている,,,,,,,,,,,,,, ,,,,・,景気後退の流れの中で、A社においても受注の伸びが鈍化傾向にあり、固定費や経費について幹部か,,,,,,,,,,,,,, ,,,,,ら削減の強い指示が出ている,,,,,,,,,,,,,, ,,,,・,併せて設計スピードの向上が課題となっており、設計技術支援システムの刷新の必要性が設計者の声,,,,,,,,,,,,,, ,,,,,として出てきている,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,ア―２　システム開発の目的,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,・,一部の機器のリース期限が近付いており、リースを延長するのか、新しい機器を導入するのか判断の,,,,,,,,,,,,,, ,,,,,時期を迎えた,,,,,,,,,,,,,, ,,,,・,最も古いコンピュータ機器は8年前に導入したものであり、性能面で限界が近づき、機器そのものの老,,,,,,,,,,,,,, ,,,,,朽化も目立っている,,,,,,,,,,,,,, ,,,,・,部門ごとの独自システムを解消し、全社で一本化された新しいシステムを開発することが経営会議で承,,,,,,,,,,,,,, ,,,,,認された,,,,,,,,,,,,,, ,,,,・,部門ごとに異なる要求を取り込み、ユーザフレンドリーなシステムとすることが、システム開発のポイント,,,,,,,,,,,,,, ,,,,・,自身の立場はP社のシステムアーキテクトで、システム構築におけるリーダとしてプロジェクトに参画,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,■設問イ,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　設問イには、問題文の次の部分が対応する。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,設問イ,,,設問アで述べたシステムについて、ユーザ要求を正しく理解するために、あなたはどのような点に留意,,,,,,,,,,,,,, ,,,,,してユーザ要求をヒアリングし、どのように要件としてまとめたか。800字以上1600字以内で具体的に述,,,,,,,,,,,,,, ,,,,,べよ。,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　しかし、ユーザから提示された要求に漏れがあったり、ユーザ要求の意味を取り違えたりすると、システムから,,,,,,,,,,,,,,,,, ,,出力された情報が想定されたものと異なったり、必要な情報の提供タイミングが遅くなったりするなど、本来、ユー,,,,,,,,,,,,,,,,, ,,ザが求めているシステムにはならないことがある。したがって、システムアーキテクトは、次のような点に留意して,,,,,,,,,,,,,,,,, ,,、ユーザ要求をヒアリングし、その要求を正しく理解することが大切である。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,・,ユーザから提示された個々の要求に矛盾がないか。,,,,,,,,,,,,,,, ,,,・,ユーザ要求として提示されるべき業務手順や法的な制約などが、ユーザ部門内では自明のこととして、省,,,,,,,,,,,,,,, ,,,,略されていないか。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　その上で、要件としてまとめるために、対象業務をモデル化したり、ユーザ要求を可視化したりする。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　例として次のような見出しとストーリーが考えられる。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,イ　ユーザ要求を正しく理解するためのユーザ要求のヒアリングにおける留意点と要件としてまとめたユーザ,,,,,,,,,,,,,,,, ,,,要求,,,,,,,,,,,,,,,, ,,,イ―１　ユーザ要求を正しく理解するためのユーザ要求のヒアリングにおける留意点,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,・,顧客の各部門は取扱製品が異なるため、設計技術支援システムで取り扱う部品の情報が部門によって,,,,,,,,,,,,,, ,,,,,大きく異なる,,,,,,,,,,,,,, ,,,,・,部品は自社製品の部品と、一般の購入部品にわかれる,,,,,,,,,,,,,, ,,,,・,一般の購入部品については、部品がもつ属性を全社で統一してデータベース化する必要があるが、設,,,,,,,,,,,,,, ,,,,,計者が必要とする部品の属性について情報の粒度の差が大きく、粒度の小さい側に合わせてデータベ,,,,,,,,,,,,,, ,,,,,ース化する情報をヒアリングしなければならない,,,,,,,,,,,,,, ,,,,・,自社製品の部品については、保持すべき情報に部門間の差はない,,,,,,,,,,,,,, ,,,,・,過去の設計情報については、A社社内で統一された様式で保存されている,,,,,,,,,,,,,, ,,,,・,過去の設計情報を設計段階で流用する際は、各部門によって参照する観点が異なるため、設計技術支,,,,,,,,,,,,,, ,,,,,援システムの操作性の面、設計情報の表現の面において各部門の要求が異なっている,,,,,,,,,,,,,, ,,,,・,過去の設計情報、部品の情報とも各部門の要求が異なるため、部門の要求の間で矛盾が生じないよう,,,,,,,,,,,,,, ,,,,,にヒアリングしなければならない,,,,,,,,,,,,,, ,,,,・,顧客の部門のうちC部門については、取り扱う情報量が多いため、特にヒアリング漏れが発生しないよ,,,,,,,,,,,,,, ,,,,,うに、他部門に比較して時間を掛けてヒアリングをする必要がある,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,イ―２　要件としてまとめたユーザ要求,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,・,部品の情報に関する要求に関して、部品の属性情報の粒度が異なるため、部門間で共通に取り扱うこ,,,,,,,,,,,,,, ,,,,,とのできる属性情報と、部門独自の要求となる属性情報を分けて表形式にまとめる,,,,,,,,,,,,,, ,,,,・,共通部分と独自部分の切り分けが重要となるため、属性情報をまとめた結果について、各部門の代表,,,,,,,,,,,,,, ,,,,,者を全員招集した会議において、まとめた表を提示して顧客の確認を受けることとする,,,,,,,,,,,,,, ,,,,・,設計情報に関する要求は、設計技術支援システムのユーザインタフェースの設計に大きな影響を与え,,,,,,,,,,,,,, ,,,,,る,,,,,,,,,,,,,, ,,,,・,使いやすいユーザインタフェースが期待されているため、ユーザ要求をまとめる際には、全体像を明確,,,,,,,,,,,,,, ,,,,,にすると同時に、設計者の利用頻度が高い処理の部分について、ユーザ要求を漏らさないように特に,,,,,,,,,,,,,, ,,,,,詳細な確認が必要となる,,,,,,,,,,,,,, ,,,,・,新しい設計技術支援システムでの操作方法は、現在稼働中の設計技術支援システムの操作方法から,,,,,,,,,,,,,, ,,,,,大きく変更となるため、全体の流れが明確になるような図にまとめユーザに提示する,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,■設問ウ,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　設問ウには、問題文の次の部分が対応する。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,設問ウ,,,設問イで述べた要件をまとめる際、ユーザとの認識の相違をなくすために、重要と考え工夫した点に,,,,,,,,,,,,, ,,,,,,ついて、600字以上1200字以内で具体的に述べよ。,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,　その際、ユーザとの認識の相違をなくすために、次のような工夫を行うことが重要である。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,・,モデルを分かりやすく表記するためにUMLを用いたり、言葉の定義を統一するために用語辞書を作成し,,,,,,,,,,,,,, ,,,,,たりする。,,,,,,,,,,,,,, ,,,,・,現行業務とシステム構築後の業務の変更点を明確にするために、両者の対比表を作成する。,,,,,,,,,,,,,, ,,,,・,システムによって実現する機能と運用によって行う作業を明確にするために、業務の流れ、処理のタイ,,,,,,,,,,,,,, ,,,,,ミングを記述した業務フロー図を作成する。,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　例として次のような見出しとストーリーが考えられる。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,ウ　ユーザとの認識の相違をなくすために、重要と考え工夫した点,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,・,複数の部門のシステムを統合した新しいシステムのため、一部の部品の名称や用語について異なる部,,,,,,,,,,,,,, ,,,,,分が生じた,,,,,,,,,,,,,, ,,,,・,いずれか一つの部門が使用している名称及び用語に統一することが最善であるが、ユーザの事情によ,,,,,,,,,,,,,, ,,,,,り名称や用語は複数の部門で使用されているものを混在して採用することとなった,,,,,,,,,,,,,, ,,,,・,新旧の部品の名称及び用語の対応表を作成することとした。対応表は、全体をまとめたもののほかに、,,,,,,,,,,,,,, ,,,,,部門ごとにこれまでの自部門の名称や用語と異なる部分だけを抽出したものを作成し、該当の部門へ,,,,,,,,,,,,,, ,,,,,配付することとした,,,,,,,,,,,,,, ,,,,・,部門では必要最低限の対応表を確認するのみでよいため、認識誤りの可能性が低くなると考えられた,,,,,,,,,,,,,, ,,,,・,ユーザインタフェースや処理の流れを確認する際には、具体的な設計業務でのオペレーション手順から,,,,,,,,,,,,,, ,,,,,大きくかい離していないことが分かるように、新旧両システムの流れを比較できるように工夫して表現し,,,,,,,,,,,,,, ,,,,,た,,,,,,,,,,,,,, ,,,,・,使用頻度の高い機能については、小さな要件定義の誤りであっても、後々手戻り作業が大きくなること,,,,,,,,,,,,,, ,,,,,が想定されたため、実画面のイメージと操作フローを明示した資料を作成し、ユーザに確認することとし,,,,,,,,,,,,,, ,,,,,た,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ■解答,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,設問ア,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,ア　対象業務の概要とシステム開発の目的,,,,,,,,,,,,,,,,, ,,ア―１　対象業務の概要,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,　私は、システムインテグレータのP社に所属するシステムアーキテクトである。今回、私が開発に携わったの,,,,,,,,,,,,,,,, ,,,は、機械製造業A社の設計部門で使用する新設計技術支援システムの開発である。A社では、設計者を支援,,,,,,,,,,,,,,,, ,,,する設計技術支援システムが稼働している。設計技術支援システムは、設計者が、過去の設計情報や部品,,,,,,,,,,,,,,,, ,,,の情報をデータベースから検索し、必要に応じて情報を流用できるようになっており、設計作業の生産性の向,,,,,,,,,,,,,,,, ,,,上、品質の向上を図ることを主な目的としている。この設計技術支援システムは、設計者にとって必須のシス,,,,,,,,,,,,,,,, ,,,テムになっている。A社の設計部門は、製造する機械の種類によって三つの部門に分かれている。各部門は,,,,,,,,,,,,,,,, ,,,独立性が高く、部門独自の業務ルールなどが存在し、これまでの設計技術支援システムは各部門が個々に,,,,,,,,,,,,,,,, ,,,立ち上げたシステムであった。景気後退の流れの中で、A社においても受注の伸びが鈍化傾向にあり、固定,,,,,,,,,,,,,,,, ,,,費や経費について幹部から削減の強い指示が出ている。併せて設計スピードの向上が課題となっており、設,,,,,,,,,,,,,,,, ,,,計技術支援システムの刷新の必要性が設計者の声として出てきていた。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,ア―２　システム開発の目的,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,　現在稼働中の機器のうち、最も古い機器は8年前に導入したものである。性能面で限界が近づき、機器その,,,,,,,,,,,,,,,, ,,,ものの老朽化も目立ってきたため、部門ごとの独自システムを解消し、全社で一本化された新しいシステムの,,,,,,,,,,,,,,,, ,,,開発が経営会議で承認された。新システムはPCサーバを中核とするクライアントサーバシステムで構築する。,,,,,,,,,,,,,,,, ,,,部門ごとに異なる要求を取り込み、ユーザフレンドリーなシステムとすることが、今回のシステム開発のポイン,,,,,,,,,,,,,,,, ,,,トである。私は、システム開発におけるリーダとしてプロジェクトに参画することとなった。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,■設問イ,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,イ　ユーザ要求を正しく理解するためのユーザ要求のヒアリングにおける留意点と要件としてまとめたユーザ要求,,,,,,,,,,,,,,,,, ,,イ―１　ユーザ要求を正しく理解するためのユーザ要求のヒアリングにおける留意点,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,　新システムの構築において、設計者が使用する部品情報と設計情報を一元管理するためのデータベースが,,,,,,,,,,,,,,,, ,,,必要になった。,,,,,,,,,,,,,,,, ,,,　設計技術支援システムで取り扱う部品の情報については、顧客の各部門は設計対象とする製品が異なるた,,,,,,,,,,,,,,,, ,,,め、部門によって使用する部品も大きく異なっている。設計で使用する部品は、自社製品の部品と、市場から,,,,,,,,,,,,,,,, ,,,調達する一般の購入部品にわかれている。一般の購入部品については、設計者が必要とする部品の属性情,,,,,,,,,,,,,,,, ,,,報の粒度に差が大きく、粒度の小さい側に合わせてデータベースに保持する情報をヒアリングする必要があっ,,,,,,,,,,,,,,,, ,,,た。一方、自社制作の部品については、保持すべき情報に部門間の差はなく、全社で統一することは容易で,,,,,,,,,,,,,,,, ,,,あった。,,,,,,,,,,,,,,,, ,,,　過去の設計情報については、A社社内で統一された様式で保持されているためデータベース化においては,,,,,,,,,,,,,,,, ,,,大きな問題は生じないが、過去の設計情報を設計段階で流用する時に、各部門によって参照する観点が異な,,,,,,,,,,,,,,,, ,,,るため、設計技術支援システムの操作性の面、設計情報の表現の面において各部門の要求が異なっている,,,,,,,,,,,,,,,, ,,,状況である。,,,,,,,,,,,,,,,, ,,,　過去の設計情報、部品の情報とも各部門の要求が異なる部分が存在するため、部門の要求の間で漏れや,,,,,,,,,,,,,,,, ,,,矛盾が生じないようにヒアリングしなければならない。,,,,,,,,,,,,,,,, ,,,　顧客部門のうちC部門については、取り扱う情報量が多いため、特にヒアリング漏れが発生しないように、他,,,,,,,,,,,,,,,, ,,,部門に比較して時間を掛けてヒアリングをする必要がある。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,イ―２　要件としてまとめたユーザ要求,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,　部品の情報に関する要求に関しては、部品の属性情報の粒度が異なるため、部門間で共通に取り扱うこと,,,,,,,,,,,,,,,, ,,,のできる属性情報と、部門独自の要求となる属性情報を分けて表形式にまとめることとした。共通部分と独自,,,,,,,,,,,,,,,, ,,,部分の切り分けが重要となるため、属性情報をまとめた結果について、各部門の代表者に一堂に会してもら,,,,,,,,,,,,,,,, ,,,い、まとめた表を提示して顧客の確認を受けるようにした。,,,,,,,,,,,,,,,, ,,,　設計情報に関する要求は、使い勝手に直結しており、設計技術支援システムのユーザインタフェースの設計,,,,,,,,,,,,,,,, ,,,に大きな影響を与える。ユーザ要求をまとめる際には、全体像を明確にすると同時に、設計者の利用頻度が,,,,,,,,,,,,,,,, ,,,高い処理の部分について、ユーザの要求を漏らさないように特に詳細な確認が必要となる。新しい設計技術,,,,,,,,,,,,,,,, ,,,支援システムでの操作方法は、現在稼働中の設計技術支援システムの操作方法から大きく変更となるため、,,,,,,,,,,,,,,,, ,,,全体の流れが明確になるような図にまとめユーザに提示することとした。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,■設問ウ,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,ウ　ユーザとの認識の相違をなくすために、重要と考え工夫した点,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,（１）名称の統一,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,　複数の部門のシステムを統合した新しいシステムのため、一部の部品の名称や用語について異なる部,,,,,,,,,,,,,,, ,,,,分が生じることが要件定義を進めていく段階で明確になった。名称や用語については、システムを構築す,,,,,,,,,,,,,,, ,,,,る立場からすれば、いずれか一つの部門が使用している名称及び用語に統一することが最善である。しか,,,,,,,,,,,,,,, ,,,,し、今回のA社の新システムでは、ユーザの事情により一つの部門で使用中の名称や用語に統一できず、,,,,,,,,,,,,,,, ,,,,複数の部門で使用している名称や用語を採用することとなった。,,,,,,,,,,,,,,, ,,,,　私は、ユーザとの認識の相違をなくすために、新旧の部品の名称及び用語の対応表を作成することとし,,,,,,,,,,,,,,, ,,,,た。対応表は、名称及び用語の全体をまとめたもののほかに、部門ごとにこれまでの自部門の名称や用語,,,,,,,,,,,,,,, ,,,,と異なる部分だけを抽出したものを作成し、該当の部門へ配布した。部門では自部門に関連する対応表を,,,,,,,,,,,,,,, ,,,,確認するのみで良いため、認識誤りの可能性が低くなると考えられた。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,（２）使用頻度の高い機能,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,　私は、ユーザインタフェースや処理の流れを確認する際には、具体的な設計業務でのオペレーション手,,,,,,,,,,,,,,, ,,,,順から大きくかい離していないことが分かるように、また、旧システムから変更になる箇所が分かるように、,,,,,,,,,,,,,,, ,,,,新旧両システムの流れを比較できるように工夫してドキュメントにまとめた。また、使用頻度の高い機能は,,,,,,,,,,,,,,, ,,,,、小さな要件定義の誤りであっても、後々の工程で手戻り作業が大きくなることが想定される。私は、使用,,,,,,,,,,,,,,, ,,,,頻度の高い機能について、実画面の概略イメージと概略の操作フローを明示したドキュメントを作成してユ,,,,,,,,,,,,,,, ,,,,ーザに提示し、ユーザに要件定義の妥当性を確認することとした。　以上,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, 平成２１年度　問１　要件定義,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,　システムアーキテクトは、要件定義において、ユーザ要求をヒアリングし、その要求を正しく理解したうえで、システ,,,,,,,,,,,,,,,,,, ,ムの要件としてドキュメントにまとめ、ユーザに確認する。,,,,,,,,,,,,,,,,,, ,　しかし、ユーザから提示された要求に漏れがあったり、ユーザ要求の意味を取り違えたりすると、システムから出,,,,,,,,,,,,,,,,,, ,力された情報が想定したものと異なったり、必要な情報の提供タイミングが遅くなったりするなど、本来、ユーザが,,,,,,,,,,,,,,,,,, ,求めているシステムにはならないことがある。したがって、システムアーキテクトは、次のような点に留意して、ユーザ,,,,,,,,,,,,,,,,,, ,要求をヒアリングし、その要求を正しく理解することが大切である。,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,・,ユーザから提示された個々の要求に矛盾がないか。,,,,,,,,,,,,,,,, ,,・,ユーザ要求として提示されるべき業務手順や法的な制約などが、ユーザ部門内では自明のこととして、省略さ,,,,,,,,,,,,,,,, ,,,れていないか。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,　その上で、要件としてまとめるために、対象業務をモデル化したり、ユーザ要求を可視化したりする。その際、ユー,,,,,,,,,,,,,,,,,, ,ザとの認識の相違をなくすために、次のような工夫を行うことが重要である。,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,・,モデルを分かりやすく表記するためにUMLを用いたり、言葉の定義を統一するために用語辞書を作成したりす,,,,,,,,,,,,,,,, ,,,る。,,,,,,,,,,,,,,,, ,,・,現行業務とシステム構築後の業務の変更点を明確にするために、両者の対比表を作成する。,,,,,,,,,,,,,,,, ,,・,システムによって実現する機能と運用によって行う作業を明確にするために、業務の流れ、処理のタイミング,,,,,,,,,,,,,,,, ,,,を記述した業務フロー図を作成する,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,設問ア,,,あなたが要件定義に携わったシステムについて、対象業務の概要とシステム開発の目的を、800字以内で,,,,,,,,,,,,,,, ,,,,述べよ。,,,,,,,,,,,,,,, ,設問イ,,,設問アで述べたシステムについて、ユーザ要求を正しく理解するために、あなたはどのような点に留意して,,,,,,,,,,,,,,, ,,,,ユーザ要求をヒアリングし、どのように要件としてまとめたか。800字以上1600字以内で具体的に述べよ。,,,,,,,,,,,,,,, ,設問ウ,,,設問イで述べた要件をまとめる際、ユーザとの認識の相違をなくすために、重要と考え工夫した点につい,,,,,,,,,,,,,,, ,,,,て、600字以上1200字以内で具体的に述べよ。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ■解答例,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,（設問ア）,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．システム開発の目的,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　K社は、北日本の地方都市を中心に約150店舗を運営するスーパマーケットである。日本全体の人口減少やコ,,,,,,,,,,,,,,,,, ,,ンビニエンスストアの拡大によって、K社の売上高は微減し続けていた。その当時、大手のスーパマーケットは、イ,,,,,,,,,,,,,,,,, ,,ンターネットで注文を受け付けて、店舗から顧客が指定する場所に注文商品を配達するネットスーパ事業を開始,,,,,,,,,,,,,,,,, ,,していた。K社の経営者層は、経営計画策定時に、ネットスーパ事業への参入とそれに対応するシステム（以下、,,,,,,,,,,,,,,,,, ,,Nシステムという）の開発を決定した。当システム開発の目的は、①3年後の売上高が前年度比で8％増加する、,,,,,,,,,,,,,,,,, ,,②割引サービスやポイントを得る会員数が3年間で50万人増加する、の2点だった。私は、K社の情報システム部,,,,,,,,,,,,,,,,, ,,に所属するシステムアーキテクトであり、当システム開発プロジェクトの設計チームリーダに任命された。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．対象業務の概要,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　Nシステムが対象とする業務の概要は、以下の通りである。,,,,,,,,,,,,,,,,, ,,,①,会員管理業務,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,　顧客がK社に郵送した会員申請書を受け付け、同封されている運転免許証などの本人確認書類と照合し,,,,,,,,,,,,,,, ,,,,て本会員の登録をする。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,②注文受付業務,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,　会員がWebブラウザの注文画面に入力した、注文商品、数量、宅配もしくは店舗での受け取り区分、宅配,,,,,,,,,,,,,,, ,,,,希望日時もしくは店舗での受け取り予定日時などを受け付ける。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,③商品集荷業務,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,　店舗担当者は、②で受け付けた注文情報に従って店舗内もしくは店舗に付属する倉庫から商品を集荷し,,,,,,,,,,,,,,, ,,,,、店舗内の指定の場所に置く。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,④商品引渡業務,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,　店舗担当者は、③の商品を宅配会社に委託するか、来店した会員に手渡す。現金払いの場合は、代金,,,,,,,,,,,,,,, ,,,,を受領する。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,⑤店舗運営管理業務,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,　ネットスーパ事業の売上高を増大させるために、店舗担当者が注文画面に表示する特売品やお勧め商,,,,,,,,,,,,,,, ,,,,品などを登録する。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,（設問イ）,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．私がユーザ要求をヒアリングしたときに留意した点,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、要件定義において、ユーザ要求をヒアリングし、その要求を正しく理解した上で、Nシステムの要件をドキ,,,,,,,,,,,,,,,,, ,,ュメントにまとめ、ユーザに確認する作業を開始した。ただし、ユーザから提示された要求に漏れがあったり、ユー,,,,,,,,,,,,,,,,, ,,ザ要求の意味を取り違えたりすると、Nシステムから出力された情報が想定したものと異なったり、必要な情報の,,,,,,,,,,,,,,,,, ,,提供タイミングが遅くなったりするなど、本来、ユーザが求めているNシステムにはならないことが想定された。し,,,,,,,,,,,,,,,,, ,,たがって、私は、以下の2点に留意して、ユーザ要求をヒアリングし、その要求を正しく理解することが大切だと考,,,,,,,,,,,,,,,,, ,,えた。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．１　ユーザから提示された個々の要求間の矛盾,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、Nシステムのユーザである複数の店舗担当者から、注文画面に表示するおすすめ商品の条件をヒアリン,,,,,,,,,,,,,,,,, ,,グした。,,,,,,,,,,,,,,,,, ,,,①,A店舗担当者の要求,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,　店舗ごとに店長が、前日の売り上げ状況を勘案して毎朝おすすめ商品を決めればよい。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,②B店舗担当者の要求,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,　大幅値引きした目玉商品をお薦め商品にするべきである。それが顧客満足度を高める。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,③C店舗担当者の要求,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,　K社の商品企画部が全社統一したお勧め商品を提示すべきである。店舗は売り場づくりに追われており、,,,,,,,,,,,,,,, ,,,,お勧め商品を毎日考える余裕がない。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,④D店舗担当者の要求,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,　ログインしている会員ごとに異なるお勧め商品を表示すべきである。例えば、若年層の会員に年配向け,,,,,,,,,,,,,,, ,,,,のお勧め商品を提示しても意味がない。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、これらの要求には相互に矛盾があり、そのすべてをNシステムに実装できないと判断した。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．２　自明のこととして省略されているユーザ要求,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、すべてのヒアリングを終えて、ユーザ要求を整理しているときに、自明のこととして省略されている、以下,,,,,,,,,,,,,,,,, ,,の2点のユーザ要求を発見した。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,①,各店舗の取扱商品は異なっている。例えば、売り場面積の小さい店舗は、家電製品や園芸品を販売していな,,,,,,,,,,,,,,,, ,,,い。ネットスーパ事業の商品集荷業務は各店舗で行われるので、会員が買い物をする店舗が取り扱っている,,,,,,,,,,,,,,,, ,,,商品のみをNシステムの注文画面に表示させなければならない。,,,,,,,,,,,,,,,, ,,②,各会員は商品を配達する、もしくは受け取る店舗を1つに定め、会員情報の１つとして登録しなければならない,,,,,,,,,,,,,,,, ,,,。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．私がヒアリング後にまとめた要件,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、上記の結果を踏まえ、要件定義書の作成に着手した。その時、私は以下の2点に配慮した。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．１　対象業務のモデル化,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、注文画面に表示するお勧め商品の条件に関する諸案を一覧表にまとめ、全店舗の店長に配布し、賛成,,,,,,,,,,,,,,,,, ,,する案を投票させた。その結果、私は店舗ごとの前週販売高が最も多い順に3商品と新聞チラシに掲載した目玉,,,,,,,,,,,,,,,,, ,,商品3商品をお勧め商品とする案に確定した。私は、お勧め商品が決定される過程を、フローチャートを使ってモ,,,,,,,,,,,,,,,,, ,,デル化した。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．２　ユーザ要求の可視化,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、K社が従来から運用している販売管理システムを調査し、各店舗の取扱商品は、店舗別取扱商品マスタ,,,,,,,,,,,,,,,,, ,,の”取扱区分（有・無）”によって把握可能なことを確認した。私は、店舗担当者と相談のうえ、この取扱区分が,,,,,,,,,,,,,,,,, ,,”有”の商品だけを注文画面に表示するユーザ要求を追加した。また、私はユーザ要求を可視化させるため、会,,,,,,,,,,,,,,,,, ,,員が入力した注文画面の図例を8枚作製し、それに注釈として説明文を記入した。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,（設問ウ）,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．ユーザとの認識の相違をなくすために工夫した点,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、ユーザとの認識の相違をなくすことが重要であると考えた。そのために、私は以下の3点の工夫を行った,,,,,,,,,,,,,,,,, ,,。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．１　言葉の定義を統一する用語辞書の作成,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私はネットスーパ事業に関連して良く使われる言葉を整理し、用語定義を統一するために、以下のような用語,,,,,,,,,,,,,,,,, ,,辞書を作成した。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,①,Webブラウザとは、”インターネットに接続するパソコンやモバイル端末にインストールされている、Webペー,,,,,,,,,,,,,,, ,,,,ジを閲覧するためのアプリケーションソフトウェア”,,,,,,,,,,,,,,, ,,,②,商品集荷とは、”会員が注文した商品名・数量・棚番号が印刷された一覧表を見て、店舗内もしくは店舗に,,,,,,,,,,,,,,, ,,,,付属する倉庫から商品を買い物かごに入れ、所定の位置に置くこと。その時に、商品集荷専用のPOS端末,,,,,,,,,,,,,,, ,,,,で、通常のレジ精算と同様に商品のバーコードをスキャンする業務も含まれる”,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．２　業務の変更点を明確にする新旧対比表の作成,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、店舗担当者が遂行する業務の変更点を明確にする新旧対比表を作成した。例えば、私は商品入荷業務,,,,,,,,,,,,,,,,, ,,に関して、,,,,,,,,,,,,,,,,, ,,,①,旧手順・・・発注した商品が店舗に到着したら検品して、店舗内の所定の棚に補充する。もし、所定の棚に,,,,,,,,,,,,,,, ,,,,収容しきれない場合は、店舗に付属する倉庫に入庫する。,,,,,,,,,,,,,,, ,,,②,新手順・・・発注した商品が店舗に到着したら検品する。検品された商品に、別途印刷された一覧表にある,,,,,,,,,,,,,,, ,,,,、ネットスーパの注文受付情報に基づいて発注された大型商品や取り寄せ商品が含まれていれば、それを,,,,,,,,,,,,,,, ,,,,所定の場所に置く。それ以降の手順は、旧手順と同様である。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．３　業務の流れなどを記述した業務フロー図,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　私は、Nシステムが対象とする業務・商品・情報・代金の流れを記述した業務フロー図を作成することにした。私,,,,,,,,,,,,,,,,, ,,は、以下の手順に従って業務フロー図を32枚完成させた。,,,,,,,,,,,,,,,,, ,,,①,業務フロー図をいくつかの列に分割し、業務担当者やシステム名を上部に記入する。,,,,,,,,,,,,,,, ,,,②,時間の流れに沿って、おおむね左上から右下方向に業務名を長方形の枠内に配置する。,,,,,,,,,,,,,,, ,,,③,業務間で授受される商品は点線、情報は実線、代金は二重線で矢印を付けて表記する。その実戦の横に,,,,,,,,,,,,,,, ,,,,は情報名を付記する。,,,,,,,,,,,,,,, ,,,④,条件分岐がある場合は、ひし形で条件名、”はい”と”いいえ”などの条件指定を記入する。,,,,,,,,,,,,,,, ,,,⑤,１４：００といった時刻や日付などの処理タイミングが決まっている場合は、それをカッコ付けて記入する。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, 平成21年度　問１　要件定義について,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,　システムアーキテクトは、要件定義において、ユーザ要求をヒアリングしたり、その要求を正しく理解した上で、シス,,,,,,,,,,,,,,,,,, ,テムの要求としてドキュメントにまとめ、ユーザに確認する。,,,,,,,,,,,,,,,,,, ,　しかし、ユーザから提示された要求に漏れがあったり、ユーザ要求の意味を取り違えたりすると、システムから出力,,,,,,,,,,,,,,,,,, ,された情報が想定したものと異なったり、必要な情報の提供タイミングが遅くなったりするなど、本来、ユーザが求め,,,,,,,,,,,,,,,,,, ,ているシステムにならないことがある。従って、システムアーキテクトは、次のような点に留意して、ユーザ要求をヒア,,,,,,,,,,,,,,,,,, ,リングし、その要求を正しく理解することが大切である。,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,・ユーザから提示された個々の要求に矛盾がないか,,,,,,,,,,,,,,,,, ,,・ユーザ要求として提示されるべき業務手順や法的な制約などが、ユーザ部門内では自明のこととして、省略され,,,,,,,,,,,,,,,,, ,,　ていないか,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,　そのうえで、要件としてまとめるために、対象業務をモデル化したり、ユーザ要求を可視化したりする。その際、ユー,,,,,,,,,,,,,,,,,, ,ザとの認識の相違をなくすために、次のような工夫を行うことが大切である。,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,・モデルを分かりやすく表記するためにUMLを用いたり、言葉の定義を統一するために用語辞書を作成したりする,,,,,,,,,,,,,,,,, ,,・現行業務とシステム構築後の業務の変更点を明確にするために、両者の対比表を作成する。,,,,,,,,,,,,,,,,, ,,・システムによって実現する機能と運用によって行う業務を明確にするために、業務の流れ、処理のタイミングを記,,,,,,,,,,,,,,,,, ,,　述した業務フロー図を作成する。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,　あなたの経験と考えに基づいて、設問ア～ウに従って論述せよ。,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,設問ア　,,,あなたが要件定義に携わったシステムについて、対象業務の概要とシステム開発の目的を、800字以内で,,,,,,,,,,,,,,, ,,,,述べよ。,,,,,,,,,,,,,,, ,設問イ,,,設問アで述べたシステムについて、ユーザ要求をヒアリングし、どのように要件としてまとめたか。800字以,,,,,,,,,,,,,,, ,,,,上1600字以内で具体的に述べよ。,,,,,,,,,,,,,,, ,設問ウ,,,設問イで述べた要件をまとめる際、ユーザとの認識の相違をなくすために重要と考え工夫した点について、,,,,,,,,,,,,,,, ,,,,600字以上1200字以内で具体的に述べよ。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, 【解説】,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,　システムアーキテクとの出題範囲のうち、上流工程である要件定義に関する出題である。要件定義は高い頻度で出,,,,,,,,,,,,,,,,,, ,題されるので、ユーザ要求のヒアリングを中心にしっかりと論述のポイントを整理して準備しておくと良い。,,,,,,,,,,,,,,,,,, ,　問題文と設問文からどのような論文の構成が求められているかを確認するために、問題文を基にして「章立て」する,,,,,,,,,,,,,,,,,, ,と次のようになる。,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,第1章　対象業務の概要とシステム開発の目的,,,,,,,,,,,,,,,,, ,,　１．１　対象業務の概要,,,,,,,,,,,,,,,,, ,,　１．２　システム開発の目的,,,,,,,,,,,,,,,,, ,,第2章　ユーザ要求を正しくヒアリングする際の留意点と留意点を踏まえた要件のまとめ方,,,,,,,,,,,,,,,,, ,,　２．１　ユーザ要求をヒアリングする際の留意点,,,,,,,,,,,,,,,,, ,,　２．２　留意点を踏まえた要件のまとめ方,,,,,,,,,,,,,,,,, ,,第3章　ユーザとの認識の相違をなくすために、重要と考えた課題と工夫した点,,,,,,,,,,,,,,,,, ,,　３．１　ユーザとの認識の相違をなくすために、重要と考えた課題,,,,,,,,,,,,,,,,, ,,　３．２　工夫した点,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,　章立てが終わった時点で論述の方向性について検討する。論述では冗長な記述は大幅な減点となる。従って、同じ,,,,,,,,,,,,,,,,,, ,内容を繰り返すことを極力避けなければならない。この問題で冗長な内容となるポイントは、設問イの後半の「留意点,,,,,,,,,,,,,,,,,, ,を踏まえた要件のまとめ方」である。前半では「どのように要件としてまとめたか」後半では「設問イで述べた要件をま,,,,,,,,,,,,,,,,,, ,とめる際、ユーザとの認識の相違をなくすために、重要と考え工夫した点」について問われている。,,,,,,,,,,,,,,,,,, ,　同じ内容を書いても、書き方によっては題意に沿った内容にすることができる。しかし、冗長な表現は厳禁である。,,,,,,,,,,,,,,,,,, ,冗長な表現を回避するための一つの方法として、設問イの後半では、「第3章　ユーザとの認識の相違をなくすために,,,,,,,,,,,,,,,,,, ,重要と考え工夫した点」としているので、設問イの後半と設問ウが冗長となることを回避できる。,,,,,,,,,,,,,,,,,, ,　なお、設問イの後半は計画段階での工夫をアピールする、設問ウは実施段階での工夫をアピールすると考えて、論,,,,,,,,,,,,,,,,,, ,文設計してもよい。,,,,,,,,,,,,,,,,,, ,　「章立て」に従って、問題文にあがっているトピックを活用して論述する手順について次に述べる。,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, 第1章　対象業務の概要とシステム開発の目的,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,〔１．１　対象業務の概要〕,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　どのような題材を使って論述するかを検討する。問題文によれば、この問題では特に制約はない。そこで、この,,,,,,,,,,,,,,,,, ,,解説では輸入車両の原価管理システムを題材にして論述例を示す。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,◆論述例,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,第1章　対象業務の概要とシステム開発の目的,,,,,,,,,,,,,,,, ,,,１．１　対象業務の概要,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,　論述の対象とするシステムは、輸入車を輸入・販売する商社であるA社における原価管理システムである,,,,,,,,,,,,,,, ,,,,。A社は海外から車両を輸入して、輸入した車を日本の道路交通法に適用するように費用をかけて改造を,,,,,,,,,,,,,,, ,,,,行い販売している。,,,,,,,,,,,,,,, ,,,,　輸入車は、海外からの輸入から、改造、整備、販売までの個別原価管理を行う。そのために、30箇所ほど,,,,,,,,,,,,,,, ,,,,の費用の発生個所からの原価情報に加えて、共通原価及び共通経費の按分をして共通費を配賦する原価,,,,,,,,,,,,,,, ,,,,情報の管理が重要となる。したがって、対象の業務の特徴としては、扱うデータの発生源が３０箇所と多い、,,,,,,,,,,,,,,, ,,,,会計業務であるという点を挙げることができる。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,●,以上の論述例の留意すべき点は「対象の業務の特徴としては」と書いて特徴を明示して、設問イにおける「踏,,,,,,,,,,,,,,,, ,,,まえる展開」の準備をしていることである。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,〔１．２　システム開発の目的〕,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　設問アの後半では、問われている内容に対して明示的に答えることが重要である。この問題では「システム開発,,,,,,,,,,,,,,,,, ,,の目的」について問われているので、「システム開発の目的」というキーワードを必ず使うようにして、問われている,,,,,,,,,,,,,,,,, ,,内容を明示する。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,◆論述例,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,１．２　システム開発の目的,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,　A社では月次決算における原価管理業務に４日間を要していた。時間を要した原因の一つにシステム間,,,,,,,,,,,,,,, ,,,,連携が不十分で原価計算に必要な情報について振替伝票を手作業で起票している点があった。そのため、,,,,,,,,,,,,,,, ,,,,必要な伝票の作成が遅れたり、抜けたりして、原価計算が困難な状況が生じるということがあった。これが,,,,,,,,,,,,,,, ,,,,原因で経営者の迅速な経営判断が遅れてしまうことになりかねない。そこで自動振り替えを推進して、月次,,,,,,,,,,,,,,, ,,,,決算における原価管理業務を２日間に短縮するという、システム開発の目的を設定して、原価管理システ,,,,,,,,,,,,,,, ,,,,ム開発プロジェクトが立ち上がった。,,,,,,,,,,,,,,, ,,,,　私はA社のシステム開発を受注したソフトウェア企業のシステムアーキテクトの立場で、ユーザ要求を可視,,,,,,,,,,,,,,, ,,,,化することで重要な要件が漏れないことを特に重視して、次に述べるようにして要件定義を行った。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,●,設問アの最後では、立場や重視したポイントを明示して、設問イにつなげる文章を書くようにする。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, 第２章　ユーザ要求をヒアリングする際の留意点,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,〔２．１　ユーザ要求をヒアリングする際の留意点〕,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　問題文に「ユーザから提示された個々の要求に矛盾がないか」、「ユーザ要求として提示されるべき業務手順や,,,,,,,,,,,,,,,,, ,,法的な制約などが、ユーザ部門内では自明のこととして、省略されていないか」というトピックが上がっているので,,,,,,,,,,,,,,,,, ,,、それを論述に流用して、出題の趣旨に沿った論文を制限時間内に仕上げるようにする。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,◆論述例,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,第２章　ユーザ要求をヒアリングする際の留意点と留意点を踏まえた要件のまとめ方,,,,,,,,,,,,,,,, ,,,２．１　ユーザ要求をヒアリングする際の留意点,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,　機能要件についてはヒアリングを中心に行い要件定義を行う。その際の留意点は次のようであると私は考,,,,,,,,,,,,,,, ,,,,えた。,,,,,,,,,,,,,,, ,,,,（１）ユーザから提示された個々の要求に矛盾がないか,,,,,,,,,,,,,,, ,,,,,　原価管理システムの扱うデータの発生源が３０箇所あり多いという対象の業務の特徴を踏まえると、,,,,,,,,,,,,,, ,,,,,ユーザが個々に挙げる要件間に矛盾点がないかという点に留意してヒアリングを行うことが重要であ,,,,,,,,,,,,,, ,,,,,ると考えた。そこでヒアリングの結果をユーザ部門別に整理して、その矛盾点を洗い出すようにした。,,,,,,,,,,,,,, ,,,,（２）ユーザ要求として提示されるべき業務手順や法的な制約などが、ユーザ部門内では自明のこととし,,,,,,,,,,,,,,, ,,,,て省略されていないか,,,,,,,,,,,,,,, ,,,,,　ヒアリングではユーザから引き出しにくい非機能要件のうち、会計という対象業務の特徴を踏まえる,,,,,,,,,,,,,, ,,,,,と、会計における法的制約の充足がポイントであると考えた。そこで、ヒアリング対象者にA者の公認,,,,,,,,,,,,,, ,,,,,会計士を含めてヒアリングをすることにした。これによって、法的制約の充足を達成できると考えた。,,,,,,,,,,,,,, ,,,,　以上の点を踏まえてヒアリングを行い、次のようにして要件をまとめた。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,●,論述しているトピックそれぞれについて、「原価管理システムの扱うデータの発生源が３０箇所あり多いという対,,,,,,,,,,,,,,,, ,,,象の業務の特徴を踏まえると」、「会計という対象業務の特徴を踏まえると」と記述して、脈絡のある論文を書く,,,,,,,,,,,,,,,, ,,,ために「踏まえる展開」を意図的に行っていることを確認する。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,〔２．２　留意点を踏まえた要件のまとめ方〕,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　ここでアピールしたいのは、留意点ではなく、要件のまとめ方である。従って、箇条書きのタイトルが要件のまと,,,,,,,,,,,,,,,,, ,,め方を表すように決める。しかし、これではまとめ方と留意点との関連付けがわかりにくい。そこで箇条書きのタイ,,,,,,,,,,,,,,,,, ,,トルの直後に留意点を明示することで関連付けを行う。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,◆論述例,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,２．２　留意点を踏まえた要件のまとめ方,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,　ヒアリング時の留意点を踏まえて、次のようにして要件をまとめた。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,,（１）系統図法やディシジョン・ツリーによるチェック,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,,,　ユーザから提示された個々の要求に矛盾点はないかという留意点から、ニーズを部門別に整理し,,,,,,,,,,,,, ,,,,,,て、ニーズを系統図やディシジョンツリーに表現して重複や矛盾点をチェックした。特に複雑な条件に,,,,,,,,,,,,, ,,,,,,ついてはディシジョン・ツリーを積極的に採用した。なぜならば、条件の矛盾点を客観的に示し、整理,,,,,,,,,,,,, ,,,,,,することができるからである。チェックして矛盾点や重複を取りのぞいたものを要件として文書化した。,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,,（２）業務フロー図の作成,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,,,　業務手順や法的な制約などが、ユーザ部門では自明のこととして、省略されていないかという留意,,,,,,,,,,,,, ,,,,,,点については、モデル化してレビューのしやすさを確保することが課題となった。モデル化の技法とし,,,,,,,,,,,,, ,,,,,,ては、一般的には①ユースケース図、②DFD、③業務フロー図などがある。私はこれらの技法のうち,,,,,,,,,,,,, ,,,,,,、③業務フローを作成することにした。なぜならば、データの発生源が多いという対象業務の特徴を,,,,,,,,,,,,, ,,,,,,踏まえると、各部門との連携を一元的に表現できる業務フローがまとめ方として効果的であると考え,,,,,,,,,,,,, ,,,,,,たからである。,,,,,,,,,,,,, ,,,,,,　以上のように、要件と業務フローを中心に要件定義書を作成した。,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,●,まず、箇条書きの前後に文章を挿入して、節が箇条書きで終わらないようにして、論文としての体裁を確保する,,,,,,,,,,,,,,,, ,,,。次に課題を明示してから、検討した案を挙げて、最後に選択した案を、選択した根拠とともに述べるようにす,,,,,,,,,,,,,,,, ,,,る。これによって、専門知識に基づいて、いろいろと考えていることをアピールしている。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, 第３章　ユーザとの認識の相違をなくすために重要と考えた課題と工夫した点,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,〔３．１　ユーザとの認識の相違をなくすために重要と考えた課題〕,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　問題文をチェックすると、工夫点について、「モデルを分かりやすく表記するためにUMLを用いたり、言葉の定義,,,,,,,,,,,,,,,,, ,,を統一するために用語辞書を用いたりする」、「現行業務とシステム構築後の業務の変更点を明確にするために、,,,,,,,,,,,,,,,,, ,,両者の対比表を作成する」、「システムによって実現する機能と運用によって行う業務を明確にするために、業務,,,,,,,,,,,,,,,,, ,,の流れ、処理のタイミングを記述した業務フローを作成する」という三つのトピックが挙がっている。これらをヒント,,,,,,,,,,,,,,,,, ,,にして課題を設定する。その課題が重要と考えた根拠についても、しっかりと明示する。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,◆論述例,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,３．１　ユーザとの認識の相違をなくすために重要と考えた課題,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,　ユーザとの認識の相違があっては、原価管理の月次処理を２日間で完了させることは難しい。ユーザとの,,,,,,,,,,,,,,, ,,,,認識の相違をなくすために次の課題があった。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,（１）情報の提供タイミングの確認,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,,　原価管理システムでは必要なデータがそろわないと次の処理を行うことができない順次処理の部分が,,,,,,,,,,,,,, ,,,,,ある。順次に処理するために必要な情報の提供タイミングが重要となる。そこで、原価計算を順次に処,,,,,,,,,,,,,, ,,,,,理するために必要な情報の提供タイミングなどの確認が重要な課題であると考えた。なぜならば、共通,,,,,,,,,,,,,, ,,,,,費用の配賦では按分率が決まらないと配賦計算ができないからである。,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,（２）用語の整理,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,,　ユーザとの認識の相違を洗い出す要件定義書のレビューでは、ユーザ部門が多いため効率的なレビ,,,,,,,,,,,,,, ,,,,,ューを実施することが困難である。そこで、特に貿易関連の用語に整理が必要であると考え、用語の整,,,,,,,,,,,,,, ,,,,,理を実施することにした。,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,　以上の課題に対して次の工夫を行った。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,●ポイントになる箇所で「なぜならば」と書いて、読み手に分かりやすいように根拠を明示している。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,〔３．２　工夫した点〕,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　工夫した点のアピール方法の一つとして、課題に対していろいろと考えたことを書く方法がある。ポイントは、状,,,,,,,,,,,,,,,,, ,,況だけを書くのではなく、課題も明示することである。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,◆論述例,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,３．２　工夫した点,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,　対象ユーザ部門が多いということは、要件のレビューにも時間がかかる。その点を含めてユーザとの認識,,,,,,,,,,,,,,, ,,,,の相違をなくす工夫が重要である。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,（１）タイミング表現を重視した業務フロー,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,,　情報の提供タイミングの確認という課題について、タイミングあるいは状態を表現する手法としては一,,,,,,,,,,,,,, ,,,,,般的に①コントロールフロー図、②状態遷移図、③ステートマシン図、などがある。,,,,,,,,,,,,,, ,,,,,　しかし、私は業務フロー図にタイミングを書き込むことで、必要な情報の提供タイミングなどの確認を行,,,,,,,,,,,,,, ,,,,,うようにした。なぜならば、ユーザ部門数が多いという対象業務の特徴を踏まえ、多くの部門で業務フロ,,,,,,,,,,,,,, ,,,,,ーが最も使われているため、ユーザの理解が早いと考えたからである。,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,（２）用語辞書の作成,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,,　用語の整理という課題については、業務フローで出力される情報の表記方法について更に標準化を行,,,,,,,,,,,,,, ,,,,,い、用語辞書を作成するようにした。その際、効率的なレビューを行うために用語辞書の量を必要最小,,,,,,,,,,,,,, ,,,,,限にすることが課題となった。そこで私は、業務フローに追記するタイミングの表現に使われる用語を重,,,,,,,,,,,,,, ,,,,,視して用語辞書を作成するようにした。,,,,,,,,,,,,,, ,,,,,　これによって、情報提供のタイミングを重視して要件をレビューできると考えた。,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,　以上のようにして私は非機能要件を含めた要件を整理して効果的に要件をまとめあげた。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,●,箇条書きを活用して、アピールしたい工夫した点をタイトルにしている。課題との関連は、箇条書きのタイトルの,,,,,,,,,,,,,,,, ,,,直後に課題を示すことでわかるようにしている。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ■論述例,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,第1章　対象業務の概要とシステム開発の目的,,,,,,,,,,,,,,,,,, ,１．１　対象業務の概要,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　論述の対象とするシステムは、輸入車を輸入・販売する商社であるA社における原価管理システムである,,,,,,,,,,,,,,,,, ,,。A社は海外から車両を輸入して、輸入した車を日本の道路交通法に適用するように費用をかけて改造を,,,,,,,,,,,,,,,,, ,,行い販売している。,,,,,,,,,,,,,,,,, ,,　輸入車は、海外からの輸入から、改造、整備、販売までの個別原価管理を行う。そのために、30箇所ほど,,,,,,,,,,,,,,,,, ,,の費用の発生個所からの原価情報に加えて、共通原価及び共通経費の按分をして共通費を配賦する原価,,,,,,,,,,,,,,,,, ,,情報の管理が重要となる。したがって、対象の業務の特徴としては、扱うデータの発生源が３０箇所と多い、,,,,,,,,,,,,,,,,, ,,会計業務であるという点を挙げることができる。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,１．２　システム開発の目的,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　A社では月次決算における原価管理業務に４日間を要していた。時間を要した原因の一つにシステム間,,,,,,,,,,,,,,,,, ,,連携が不十分で原価計算に必要な情報について振替伝票を手作業で起票している点があった。そのため、,,,,,,,,,,,,,,,,, ,,必要な伝票の作成が遅れたり、抜けたりして、原価計算が困難な状況が生じるということがあった。これが,,,,,,,,,,,,,,,,, ,,原因で経営者の迅速な経営判断が遅れてしまうことになりかねない。そこで自動振り替えを推進して、月次,,,,,,,,,,,,,,,,, ,,決算における原価管理業務を２日間に短縮するという、システム開発の目的を設定して、原価管理システ,,,,,,,,,,,,,,,,, ,,ム開発プロジェクトが立ち上がった。,,,,,,,,,,,,,,,,, ,,　私はA社のシステム開発を受注したソフトウェア企業のシステムアーキテクトの立場で、ユーザ要求を可視,,,,,,,,,,,,,,,,, ,,化することで重要な要件が漏れないことを特に重視して、次に述べるようにして要件定義を行った。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,第２章　ユーザ要求をヒアリングする際の留意点と留意点を踏まえた要件のまとめ方,,,,,,,,,,,,,,,,,, ,２．１　ユーザ要求をヒアリングする際の留意点,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　機能要件についてはヒアリングを中心に行い要件定義を行う。その際の留意点は次のようであると私は考,,,,,,,,,,,,,,,,, ,,えた。,,,,,,,,,,,,,,,,, ,,（１）ユーザから提示された個々の要求に矛盾がないか,,,,,,,,,,,,,,,,, ,,,　原価管理システムの扱うデータの発生源が３０箇所あり多いという対象の業務の特徴を踏まえると、,,,,,,,,,,,,,,,, ,,,ユーザが個々に挙げる要件間に矛盾点がないかという点に留意してヒアリングを行うことが重要であ,,,,,,,,,,,,,,,, ,,,ると考えた。そこでヒアリングの結果をユーザ部門別に整理して、その矛盾点を洗い出すようにした。,,,,,,,,,,,,,,,, ,,（２）ユーザ要求として提示されるべき業務手順や法的な制約などが、ユーザ部門内では自明のこととし,,,,,,,,,,,,,,,,, ,,て省略されていないか,,,,,,,,,,,,,,,,, ,,,　ヒアリングではユーザから引き出しにくい非機能要件のうち、会計という対象業務の特徴を踏まえる,,,,,,,,,,,,,,,, ,,,と、会計における法的制約の充足がポイントであると考えた。そこで、ヒアリング対象者にA社の公認,,,,,,,,,,,,,,,, ,,,会計士を含めてヒアリングをすることにした。これによって、法的制約の充足を達成できると考えた。,,,,,,,,,,,,,,,, ,,　以上の点を踏まえてヒアリングを行い、次のようにして要件をまとめた。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,２．２　留意点を踏まえた要件のまとめ方,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　ヒアリング時の留意点を踏まえて、次のようにして要件をまとめた。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,（１）系統図法やディシジョン・ツリーによるチェック,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,　ユーザから提示された個々の要求に矛盾点はないかという留意点から、ニーズを部門別に整理し,,,,,,,,,,,,,,, ,,,,て、ニーズを系統図やディシジョンツリーに表現して重複や矛盾点をチェックした。特に複雑な条件に,,,,,,,,,,,,,,, ,,,,ついてはディシジョン・ツリーを積極的に採用した。なぜならば、条件の矛盾点を客観的に示し、整理,,,,,,,,,,,,,,, ,,,,することができるからである。チェックして矛盾点や重複を取りのぞいたものを要件として文書化した。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,（２）業務フロー図の作成,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,　業務手順や法的な制約などが、ユーザ部門では自明のこととして、省略されていないかという留意,,,,,,,,,,,,,,, ,,,,点については、モデル化してレビューのしやすさを確保することが課題となった。モデル化の技法とし,,,,,,,,,,,,,,, ,,,,ては、一般的には①ユースケース図、②DFD、③業務フロー図などがある。私はこれらの技法のうち,,,,,,,,,,,,,,, ,,,,、③業務フローを作成することにした。なぜならば、データの発生源が多いという対象業務の特徴を,,,,,,,,,,,,,,, ,,,,踏まえると、各部門との連携を一元的に表現できる業務フローがまとめ方として効果的であると考え,,,,,,,,,,,,,,, ,,,,たからである。,,,,,,,,,,,,,,, ,,,,　以上のように、要件と業務フローを中心に要件定義書を作成した。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,第３章　ユーザとの認識の相違をなくすために重要と考えた課題と工夫した点,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,３．１　ユーザとの認識の相違をなくすために重要と考えた課題,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　ユーザとの認識の相違があっては、原価管理の月次処理を２日間で完了させることは難しい。ユーザとの,,,,,,,,,,,,,,,,, ,,認識の相違をなくすために次の課題があった。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,（１）情報の提供タイミングの確認,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,　原価管理システムでは必要なデータがそろわないと次の処理を行うことができない順次処理の部分が,,,,,,,,,,,,,,,, ,,,ある。順次に処理するために必要な情報の提供タイミングが重要となる。そこで、原価計算を順次に処,,,,,,,,,,,,,,,, ,,,理するために必要な情報の提供タイミングなどの確認が重要な課題であると考えた。なぜならば、共通,,,,,,,,,,,,,,,, ,,,費用の配賦では按分率が決まらないと配賦計算ができないからである。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,（２）用語の整理,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,　ユーザとの認識の相違を洗い出す要件定義書のレビューでは、ユーザ部門が多いため効率的なレビ,,,,,,,,,,,,,,,, ,,,ューを実施することが困難である。そこで、特に貿易関連の用語に整理が必要であると考え、用語の整,,,,,,,,,,,,,,,, ,,,理を実施することにした。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　以上の課題に対して次の工夫を行った。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,３．２　工夫した点,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　対象ユーザ部門が多いということは、要件のレビューにも時間がかかる。その点を含めてユーザとの認識,,,,,,,,,,,,,,,,, ,,の相違をなくす工夫が重要である。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,（１）タイミング表現を重視した業務フロー,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,　情報の提供タイミングの確認という課題について、タイミングあるいは状態を表現する手法としては一,,,,,,,,,,,,,,,, ,,,般的に①コントロールフロー図、②状態遷移図、③ステートマシン図、などがある。,,,,,,,,,,,,,,,, ,,,　しかし、私は業務フロー図にタイミングを書き込むことで、必要な情報の提供タイミングなどの確認を行,,,,,,,,,,,,,,,, ,,,うようにした。なぜならば、ユーザ部門数が多いという対象業務の特徴を踏まえ、多くの部門で業務フロ,,,,,,,,,,,,,,,, ,,,ーが最も使われているため、ユーザの理解が早いと考えたからである。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,（２）用語辞書の作成,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,　用語の整理という課題については、業務フローで出力される情報の表記方法について更に標準化を行,,,,,,,,,,,,,,,, ,,,い、用語辞書を作成するようにした。その際、効率的なレビューを行うために用語辞書の量を必要最小,,,,,,,,,,,,,,,, ,,,限にすることが課題となった。そこで私は、業務フローに追記するタイミングの表現に使われる用語を重,,,,,,,,,,,,,,,, ,,,視して用語辞書を作成するようにした。,,,,,,,,,,,,,,,, ,,,　これによって、情報提供のタイミングを重視して要件をレビューできると考えた。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　以上のようにして私は非機能要件を含めた要件を整理して効果的に要件をまとめあげた。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, 平成２１年度　問２　システムの段階移行,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,　企業活動の中心となる販売管理システム、生産管理システム、会計システムなどの基幹業務システムを再構築し,,,,,,,,,,,,,,,,,, ,た場合、これらは一般的に規模が大きいシステムなので、一括移行ではなく、段階移行を選択する場合が多い。,,,,,,,,,,,,,,,,,, ,　例えば、多数の店舗を保有する企業では、店舗システムを、店舗ごとに旧システムから新システムへ順次切り替え,,,,,,,,,,,,,,,,,, ,る方法をとる。その場合、本部システムは、店舗システムの切替期間中、新旧システムを両方稼働させ、全店舗の,,,,,,,,,,,,,,,,,, ,切替終了後、旧システムを停止する。,,,,,,,,,,,,,,,,,, ,　このような場合は、新旧システムが併存する並行運用期間が発生するので、システムアーキテクトは、その間の対,,,,,,,,,,,,,,,,,, ,応を検討する必要がある。例えば、データの二重管理、新旧システムの機能差異などの課題に対し、次のような対,,,,,,,,,,,,,,,,,, ,応が必要になる。,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,・,日中にマスタファイルのデータの変更を行うとき、新旧システムの両方のマスタファイルの同期をとって変更す,,,,,,,,,,,,,,,, ,,,る必要があるので、一度の変更で両方のマスタファイルを更新する機能を追加する。,,,,,,,,,,,,,,,, ,,・,全社が新システムに切り替わるまで、新旧システムの機能差異を埋めるための暫定的な対応を行う。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,　その際、例えば、次のような工夫を行う。,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,・,並行運用期間中だけ利用する追加の機能は、削除する際にほかの機能に影響を与えない方法で実装する。,,,,,,,,,,,,,,,, ,,・,暫定的な対応を行うとき、基幹業務システムでの対応、EUCによる対応、運用による対応などを組み合わせて,,,,,,,,,,,,,,,, ,,,、工期、工数を最小限にとどめる。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,設問ア,,,あなたが移行に携わったシステムの概要と、段階移行の方法について、800字以内で述べよ。,,,,,,,,,,,,,,, ,設問イ,,,設問アで述べたシステムについて、あなたは並行運用期間中の課題をどのように想定し、その課題に対し,,,,,,,,,,,,,,, ,,,,てどのような対応方法を選んだか。その課題、対応方法、選んだ理由を、業務の特性を踏まえて、800字以,,,,,,,,,,,,,,, ,,,,上1600字以内で具体的に述べよ。,,,,,,,,,,,,,,, ,設問ウ,,,設問イで述べた対応方法を実施する上で、重要と考え工夫した点について、600字以上1200字以内で具体,,,,,,,,,,,,,,, ,,,,的に述べよ。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ■ポイント,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,■出題趣旨,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　基幹業務システムを再構築した場合、システム規模を考慮して、段階移行を行うことが多い。その場合、並行運,,,,,,,,,,,,,,,,, ,,用期間が発生するので、その間のデータの二重管理や新旧システムの機能差異などの課題を想定し、その対応,,,,,,,,,,,,,,,,, ,,を検討することが必要となる。,,,,,,,,,,,,,,,,, ,,　本問は、並行運用期間中の課題をどのように想定し、どのように対応したのか、また、その際、重要と考え工夫,,,,,,,,,,,,,,,,, ,,した内容について、具体的に論述することを求めている。,,,,,,,,,,,,,,,,, ,,　本問では、論述を通じて、システムアーキテクトに必要な移行方式の設計能力を評価する。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,■採点講評,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　全問に共通して、文字の記述が乱雑なものや誤字脱字が目立つもの、論旨がはっきりせず論述内容が理解し,,,,,,,,,,,,,,,,, ,,づらいものがあった。このような論述では、論述内容を正しく読み取れない場合もあるので、是非留意してもらい,,,,,,,,,,,,,,,,, ,,たい。また、一般論や問題文の引用に終始するものも目立った。このような論述では、受験者の能力や経験を正,,,,,,,,,,,,,,,,, ,,しく評価できない場合がある。対象業務との関連や実際の経験を踏まえて具体的に論述してほしい。,,,,,,,,,,,,,,,,, ,,　問２（システムの段階移行について）では、実際の移行経験を踏まえた、並行運用期間中の具体的な課題と対,,,,,,,,,,,,,,,,, ,,応方法についての論述を期待したが、単なる移行の経過や、移行の手順を説明している論述が多かった。また、,,,,,,,,,,,,,,,,, ,,業務の特性を踏まえての記述を求めているにも関わらず、業務的観点が欠落している論述も散見された。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,　本問は、システム移行の中でも段階移行がテーマの問題である。システム移行には、ビッグバンと呼ばれる一括移,,,,,,,,,,,,,,,,,, ,行の方式もあるが、本問ではあえて、段階的にシステムを移行する方式について記述することを指定している。一括,,,,,,,,,,,,,,,,,, ,移行では、一度にシステムを切り替えるため、既存（旧）システムの運用を継続させる必要はないが、段階移行の場,,,,,,,,,,,,,,,,,, ,合、必ず既存システムと新規開発システムとの並行運用期間が存在する。この並行運用期間の間は、本問の例に,,,,,,,,,,,,,,,,,, ,もあるように、既存システムと新システムとの間で様々な問題や矛盾が生じないように移行期間だけ使用するプログ,,,,,,,,,,,,,,,,,, ,ラムを開発したり、特別な運用を行ったりするなどの工夫が必要になってくる。段階移行の際の課題と対応策、さら,,,,,,,,,,,,,,,,,, ,に対応策を施した際の工夫を記述することがポイントとなる。また、段階移行がテーマであるため、単にシステム移,,,,,,,,,,,,,,,,,, ,行を行った際の対応策や工夫ではなく、段階的に移行を行った場合の内容を記述しなければならない点もポイント,,,,,,,,,,,,,,,,,, ,である。,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,　設問アでは、「システムの概要」と「段階移行の方法」についての記述が要求されている。システム移行がテーマの,,,,,,,,,,,,,,,,,, ,論文では、システム構成の説明に加え、運用状況の説明（バッチ処理のタイミングやシステムの稼働時間など）を加,,,,,,,,,,,,,,,,,, ,えると後の段階移行の方法や、設問イ、ウの記述への理解がしやすくなる。システム概要の次に、段階移行の方法,,,,,,,,,,,,,,,,,, ,について記述するが、設問アは、800字以内という字数制約があるため、システムの概要に文字数を使いすぎないよ,,,,,,,,,,,,,,,,,, ,うに注意したい。段階移行の方法については、どのような期間に、どのような順番で、または、どのような方法を用い,,,,,,,,,,,,,,,,,, ,て移行を行ったかを記述するとよい。,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,　設問イでは、「並行運用期間中の課題」、「課題に対する対応方法」、「その対応方法を選んだ理由」の記述が要求,,,,,,,,,,,,,,,,,, ,されている。問題文では、対応方法の例が記載されているため、これらを参考に対応方法を記述するとよい。論文で,,,,,,,,,,,,,,,,,, ,は対応方法とともに、その方法を選んだ理由も記述しなければならないため、理由の記述を書き漏らさないようにし,,,,,,,,,,,,,,,,,, ,たい。設問に「業務の特性を踏まえて」と記述されているため、業務の特性から対応策を採用した理由を記述すると,,,,,,,,,,,,,,,,,, ,よい。,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,　平成20年までのアプリケーションエンジニア試験では、設問ウは工夫点と改善点を記述することが定番となってい,,,,,,,,,,,,,,,,,, ,たが、システムアーキテクト試験になり、さらに具体的な内容の記述を求められるようになった。本問では、設問イで,,,,,,,,,,,,,,,,,, ,記述した対応方法を実施する上での「工夫点」の記述が要求されている。設問イで記述した対応方法と指定されて,,,,,,,,,,,,,,,,,, ,いるため、設問イとの対応関係が分かるような論文の構成にしなければならない。設問イで、対応方法を記述する,,,,,,,,,,,,,,,,,, ,際、工夫点も合わせて記述してしまうと設問ウに記述する内容がなくなってしまうので、設問イでは実施した内容、,,,,,,,,,,,,,,,,,, ,設問ウでは実施した内容に対する工夫と分けて記述するよう注意したい。,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ■見出しとストーリー,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,設問ア,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　設問アには、問題文の次の部分が対応する。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,設問ア,,,あなたが移行に携わったシステムの概要と、段階移行の方法について、800字以内で述べよ。,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　企業活動の中心となる販売管理システム、生産管理システム、会計システムなどの基幹業務システムを再構,,,,,,,,,,,,,,,,, ,,築した場合、これらは一般的に規模が大きいシステムなので、一括移行ではなく、段階移行を選択する場合が多,,,,,,,,,,,,,,,,, ,,い。,,,,,,,,,,,,,,,,, ,,　例えば、多数の店舗を保有する企業では、店舗システムを、店舗ごとに旧システムから新システムへ順次切り,,,,,,,,,,,,,,,,, ,,替える方法をとる。その場合、本部システムは、店舗システムの切替期間中、新旧システムを両方稼働させ、全,,,,,,,,,,,,,,,,, ,,店舗の切替終了後、旧システムを停止する。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,　例として次のような見出しとストーリーが考えられる。,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,ア　システムの概要と段階移行の方法,,,,,,,,,,,,,,,,, ,,ア―１　システムの概要,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,・,顧客は、家電量販店のA社,,,,,,,,,,,,,,, ,,,・,移行対象のシステムは販売管理システム,,,,,,,,,,,,,,, ,,,・,企業の構成は、本社、店舗20店、配送センタのPC,,,,,,,,,,,,,,, ,,,・,移行理由は、販売管理システムが老朽化したため、新しい販売管理システムを導入,,,,,,,,,,,,,,, ,,,・,販売管理システムの移行プロジェクトにおいてシステムアーキテクトとして参加,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,ア―２　段階移行の方法,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,・,店舗ごとに段階移行を行う,,,,,,,,,,,,,,, ,,,・,本社、配送センタは、移行完了まで新システムと旧システムを並行稼働させる,,,,,,,,,,,,,,, ,,,・,新旧システムのマスタファイルの同期は日次バッチで実施,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,■設問イ,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　設問イには、問題文の次の部分が対応する。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,設問イ,,,設問アで述べたシステムについて、あなたは並行運用期間中の課題をどのように想定し、その課題,,,,,,,,,,,,, ,,,,,,に対してどのような対応方法を選んだか。その課題、対応方法、選んだ理由を、業務の特性を踏ま,,,,,,,,,,,,, ,,,,,,えて、800字以上1600字以内で具体的に述べよ。,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,　このような場合は、新旧システムが併存する並行運用期間が発生するので、システムアーキテクトは、その,,,,,,,,,,,,,,,, ,,,間の対応を検討する必要がある。例えば、データの二重管理、新旧システムの機能差異などの課題に対し、,,,,,,,,,,,,,,,, ,,,次のような対応が必要になる。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,・,日中にマスタファイルのデータ変更を行うとき、新旧システムの両方のマスタファイルの同期を取って変,,,,,,,,,,,,,, ,,,,,更する必要があるので、一度の変更で両方のマスタファイルを更新する機能を追加する。,,,,,,,,,,,,,, ,,,,・,全社が新システムに切り替わるまで、新旧システムの機能差異を埋めるための暫定的な対応を行う。,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　例として次のような見出しとストーリーが考えられる。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,イ　日中のマスタデータの同期に関する課題、及び移行前日の店舗での運用に関する課題,,,,,,,,,,,,,,,, ,,,イ―１　日中のマスタデータの同期に関する課題,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,（１）課題,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,,　新旧システムの並行稼働中にマスタデータの即時同期が必要となる場合がある,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,（２）対応方法,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,,　新旧両方の商品マスタを同期させる移行用プログラムを開発,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,（３）対応方法を採用した理由,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,,　手動で対応する運用では、更新遅れ、更新ミスが発生する可能性があるため,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,イ―２　移行前日の店舗での運用に関する課題,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,（１）課題,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,,　配送センタでは、新システムからも、旧システムからの配送依頼データが送られてくることになり、対応,,,,,,,,,,,,,, ,,,,,が必要,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,（２）対応方法,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,,　切替前日の出庫手配を行わないような移行時の運用を実施,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,（３）対応方法を採用した理由,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,,　切替時専用プログラムの開発は、期間的コスト的に難しいと判断,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,■設問ウ,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　設問ウには、問題文の次の部分が対応する。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,設問ウ,,,設問イで述べた対応方法を実施する上で、重要と考え工夫した点について、600字以上1200字以内,,,,,,,,,,,,, ,,,,,,で具体的に述べよ。,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,　その際、例えば、次のような工夫を行う。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,・,並行運用期間中だけ利用する追加の機能は、削除する際にほかの機能に影響を与えない方法で実装,,,,,,,,,,,,,, ,,,,,する。,,,,,,,,,,,,,, ,,,,・,暫定的な対応を行うとき、基幹業務システムでの対応、EUCによる対応、運用による対応などを組み合,,,,,,,,,,,,,, ,,,,,わせて、工期、工数を最小限にとどめる。,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,　例として次のような見出しとストーリーが考えられる。,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,ウ　日中のマスタデータの同期に関する課題に対して重要と考え工夫した点、及び移行前日の店舗での運用,,,,,,,,,,,,,,,, ,,,に関する課題に対して重要と考え工夫した点,,,,,,,,,,,,,,,, ,,,ウ―１　日中のマスタデータの同期に関する課題に対して重要と考え工夫した点,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,・,プログラムで対応するため、試験を十分に行った,,,,,,,,,,,,,, ,,,,・,リハーサルを実施した,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,ウ―２　移行前日の店舗での運用に関する課題に対して重要と考え工夫した点,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,・,エンドユーザ向けの手順書を作成,,,,,,,,,,,,,, ,,,,・,担当者のリハーサルへの参加,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ■解答,,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,■設問ア,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,ア　移行対象システムの概要と段階移行の方法,,,,,,,,,,,,,,,,, ,,ア―１　移行対象システムの概要,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,　A社は、関東を中心に20店舗の販売店がある家電量販店である。A社は、この店舗を取りまとめる本社とA社,,,,,,,,,,,,,,,, ,,,の商品を保管する倉庫を管理している配送センタで構成されている。このA社が使用している販売管理システ,,,,,,,,,,,,,,,, ,,,ムが老朽化してきたため、新しい販売管理システムを構築することになった。現在の販売管理システムは、本,,,,,,,,,,,,,,,, ,,,社に本部サーバがあり、各店舗にも店舗サーバが設置されている。配送センタにもPCが設置され、本社サー,,,,,,,,,,,,,,,, ,,,バと各店舗サーバ、本社サーバと配送センタPCは、それぞれネットワークで接続されている。,,,,,,,,,,,,,,,, ,,,　本社サーバには、商品マスタ、在庫マスタ、売上データなどがあり、店舗サーバには店舗商品マスタや店舗,,,,,,,,,,,,,,,, ,,,売上データがある。本社サーバと店舗サーバのデータは日次バッチで同期を取っている。本社サーバでは、こ,,,,,,,,,,,,,,,, ,,,れらのマスタデータに加え、補充発注のためのデータや配送のためのデータを管理している。配送センタには,,,,,,,,,,,,,,,, ,,,、サーバはなくPCから直接本社サーバを参照、更新している。移行先となる新システムのサーバ構成もほぼ,,,,,,,,,,,,,,,, ,,,同じである。私は、販売管理システムの移行プロジェクトにおいて、システムアーキテクトして参加した。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,ア―２　段階移行の方法,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,　店舗ごとに営業時間が異なるため、移行作業のためにシステムを長時間完全に停止させることができない。,,,,,,,,,,,,,,,, ,,,このため、現行の販売システムから新システムへの移行は、1店舗ごとに実施する段階移行の方法を採用し,,,,,,,,,,,,,,,, ,,,た。移行は月末に実施する月次処理実施日の後、翌月の月次処理までに、全店舗を移行する計画を立てた。,,,,,,,,,,,,,,,, ,,,移行期間中、本社は、現行システムのサーバと新システムのサーバを並行稼働させ、日次バッチで各マスタ,,,,,,,,,,,,,,,, ,,,データの同期を取る方法を取った。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,■設問イ,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,イ　日中のマスタデータの同期に関する課題、及び移行前日の店舗での運用に関する課題,,,,,,,,,,,,,,,,, ,,イ―１　日中のマスタデータの同期に関する課題,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,　業務運用上、日中にマスタデータの更新が行われる場合がある。この課題に対し、以下のような対策を講じ,,,,,,,,,,,,,,,, ,,,た。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,（１）想定した課題,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,　旧システムと新システムとのマスタデータの同期は、日次バッチで実施する方法を採用したが、日中、商,,,,,,,,,,,,,,, ,,,,品マスタを更新する場合もある。これは、競合他社の商品よりも高い価格を設定した商品を店舗によって,,,,,,,,,,,,,,, ,,,,価格変更する場合である。このような場合、店舗サーバの商品マスタを更新し、更新データを緊急価格変,,,,,,,,,,,,,,, ,,,,更として本社サーバへ送信する。本社では、この変更を受け取った場合、各店舗商品マスタへの即時反映,,,,,,,,,,,,,,, ,,,,を行うかどうかの判断を行う。価格変更が必要と判断した場合は、本社商品マスタの更新と各店舗サーバ,,,,,,,,,,,,,,, ,,,,の商品マスタの更新処理を実行する。並行移行期間は、新旧両方のマスタデータの即時更新処理が必要,,,,,,,,,,,,,,, ,,,,となる。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,（２）対応方法,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,　本社で商品マスタの更新が必要と判断した場合、旧システムと新システムの本社サーバの商品マスタを,,,,,,,,,,,,,,, ,,,,更新するプログラムを移行用プログラムとして開発することで対応することとした。新旧システムともに、商,,,,,,,,,,,,,,, ,,,,品マスタ即時同期処理が存在するため、商品マスタが更新されると各店舗にも修正された商品価格が即,,,,,,,,,,,,,,, ,,,,時反映される。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,（３）対応方法を採用した理由,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,　手動で新旧システム両方への即時対応処理を運用で実施することは、運用上煩雑になり更新漏れ、更,,,,,,,,,,,,,,, ,,,,新ミスなどのミスが生じる可能性があるため、移行用プログラムで対応したほうがよいと判断した。また、本,,,,,,,,,,,,,,, ,,,,社サーバの商品マスタの更新処理を行った後は、既存の機能を利用できる点も採用した理由である。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,イ―２　移行前日の店舗での運用に関する課題,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,　移行前日の店舗の運用に関して、問題があることが分かり、以下のような対策を講じた。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,（１）想定した課題,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,　店舗サーバの切替前日に配送センタへ出庫手配を行うと、旧システムに配送依頼データが残り、翌日の,,,,,,,,,,,,,,, ,,,,切替時に前日行った配送依頼の状況が新システムに反映されない。切替前日の配送依頼を新システムに,,,,,,,,,,,,,,, ,,,,反映する仕組みが必要となる。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,（２）対応方法,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,　切替前日の配送依頼は実施しないような移行手順にするよう運用で対応した。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,（３）対応方法を採用した理由,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,,　切替前日と当日だけ使用する専用プログラムを開発することは期間的にもコスト的にも難しいと判断した,,,,,,,,,,,,,,, ,,,,。また、エンドユーザに新しい作業を行ってもらうのではなく、従来の作業を行わないという運用は比較的容,,,,,,,,,,,,,,, ,,,,易であろうと考えた。,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,■設問ウ,,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,ウ　日中のマスタデータの同期に関する課題に対して重要と考え工夫した点、及び移行前日の店舗での運用に,,,,,,,,,,,,,,,,, ,,関する課題に対して重要と考え工夫した点,,,,,,,,,,,,,,,,, ,,ウ―１　日中のマスタデータの同期に関する課題に対して重要と考え工夫した点,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,　競合他社に対抗するための施策である緊急価格変更処理は移行期間中でも重要な機能であると考え、並,,,,,,,,,,,,,,,, ,,,行移行期間に使用する新旧システムの同時更新プログラムの開発に関して、テストを十分に行い、マスタデー,,,,,,,,,,,,,,,, ,,,タの更新漏れや更新ミスが発生しないよう工夫した。テストに加え、実際の移行データを用いたリハーサルを,,,,,,,,,,,,,,,, ,,,実施した。リハーサル実施においては、移行プログラムの利用を想定した移行リハーサルを本社サーバの移,,,,,,,,,,,,,,,, ,,,行準備に組み込んだ。移行期間中に、緊急価格変更の処理があったが、問題なく新旧システムのマスタデー,,,,,,,,,,,,,,,, ,,,タの更新と各店舗サーバへのマスタデータの更新を行うことができた。,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,ウ―２　移行前日の店舗での運用に関する課題に対して重要と考え工夫した点,,,,,,,,,,,,,,,,, ,,,,,,,,,,,,,,,,,,, ,,,　各店舗における切替前日と切替当日の運用については、各店舗の担当者向けの詳細な手順書を作成し、,,,,,,,,,,,,,,,, ,,,前日までに完了しておく作業や、切替当日実施しなければならない作業を理解しやすいように業務フローを,,,,,,,,,,,,,,,, ,,,交えて整理した。特に、通常の作業との違いが分かりやすくなるような手順書の作成を心掛けるようにした。さ,,,,,,,,,,,,,,,, ,,,らに、担当者向けの説明会を行い、希望者にはリハーサルへの参加も行えるようにした。実際の各店舗の移,,,,,,,,,,,,,,,, ,,,行においては、手順書通りの運用が実施でき、想定していた切替前日に配送依頼が行われるような事態が起,,,,,,,,,,,,,,,, ,,,こらず移行を行うことができた。　以上,,,,,,,,,,,,,,,,