平成21年度　問2　システムの段階移行について,,,,,, ,,,,,, ,　企業活動の中心となる販売管理システム、生産管理システム、会計システムなどの基幹業務システムを再構築した,,,,, ,場合、これらは一般的に規模が大きいシステムなので、一括移行ではなく、段階移行を選択する場合が多い。,,,,, ,　例えば、多数の店舗を保有する企業では、店舗システムを、店舗ごとに旧システムから新システムへ順次切り替え,,,,, ,る方法をとる。その場合、本部システムは、店舗システムの切り替え期間中、新旧システムを両方稼働させ、全店舗,,,,, ,の切り替え終了後、旧システムを停止する。,,,,, ,　このような場合は、新旧システムが併存する並行運用期間が発生するので、システムアーキテクトは、その間の対,,,,, ,応を検討する必要がある。例えば、データの二重管理、新旧システムの機能差異などの課題に対し、次のような対応,,,,, ,が必要になる。,,,,, ,,,,,, ,,・日中にマスタファイルのデータ変更を行うとき、新旧システムの両方のマスタファイルの同期をとって変更する必,,,, ,,　要があるので、一度の変更で両方のマスタファイルを更新する機能を追加する。,,,, ,,・全社が新システムに切り替わるまで、新旧システムの機能差異を埋めるための暫定的な対応を行う。,,,, ,,,,,, ,　その際、例えば、次のような工夫を行う。,,,,, ,,,,,, ,,・並行運用期間中だけ利用する追加の機能は、削除する際に他の機能に影響を与えない方法で実装する。,,,, ,,・暫定的な対応を行うとき、基幹業務システムでの対応、EUCによる対応、運用による対応などを組み合わせて、,,,, ,,　工期、工数を最小限にとどめる。,,,, ,,,,,, ,　あなたの経験と考えにもとづいて、設問ア～ウに従って論述せよ。,,,,, ,,,,,, ,設問ア,,,あなたが移行に携わったシステムの概要と、段階移行の方法について、800字以内で述べよ。,, ,設問イ,,,設問アで述べたシステムについて、あなたは並行運用期間中の課題をどのように想定し、その課題に対し,, ,,,,てどのような対応方法を選んだか。その課題、対応方法、選んだ理由を、業務の特性を踏まえて、800字以,, ,,,,上、１６００字以内で具体的に述べよ。,, ,設問ウ,,,設問イで述べた対応方法を実施する上で、重要と考え工夫した点について、600字以上1200字以内で具体,, ,,,,的に述べよ。,, ,,,,,, 【解説】,,,,,, ,,,,,, ,　大きく分けて、一括移行方式と段階的移行方式とがある移行方式のうち、段階的移行方式に限定して問う問題であ,,,,, ,る。論旨展開を確認するため、設問に沿って章立てをすると次のようになる。,,,,, ,,,,,, ,,第1章　システムの概要と段階移行の方法,,,, ,,,１．１　システムの概要,,, ,,,１．２　段階移行の方法,,, ,,第2章　業務の特性を踏まえて想定した並行期間中の課題と課題への対応方法,,,, ,,,２．１　想定した並行期間中の課題,,, ,,,２．２　課題への対応方法,,, ,,第3章　対応方法を実施する上で重要と考えた課題と工夫した点,,,, ,,,３．１　対応方法を実施する上で重要と考えた課題,,, ,,,３．２　工夫した点,,, ,,,,,, ,　この問題を読解する上でのポイントは、設問イでは計画段階の課題と対応方法、設問ウでは実施段階の課題と工,,,,, ,夫した点について問われていることが分かる。,,,,, ,　論文の題材については、問題文から一括移行するとリスクの大きい大規模システムが最適である。論文題材に関,,,,, ,する知識を共有して論述のポイントを効果的に把握してもらうために、平成19年秋アプリケーションエンジニア試験（,,,,, ,現システムアーキテクト試験）午後１問２の問題を事例として用いて論述する。章立てに基づいた論述のポイントを次,,,,, ,に解説する。,,,,, ,,,,,, 第1章　システムの概要と段階移行の方法,,,,,, ,,,,,, ,〔１．１　システムの概要〕,,,,, ,,,,,, ,,　問題文から大規模システムを題材にすることが求められている。次に示す論述例では販売システムを題材に論,,,, ,,述している。設問イにおいて、「業務の特性を踏まえて」と書いてあることから、「販売システムは高い応答性が要,,,, ,,求される」及び「競合他社との競争が激化している」という業務の特性を挙げている。,,,, ,,,,,, ,,◆論述例,,,, ,,,,,, ,,,第1章　システムの概要と段階移行の方法,,, ,,,１．１　システムの概要,,, ,,,,,, ,,,,　論述の題材は家電量販店のA社における販売システムである。A社は本社、配送センタ及び20の店舗で,, ,,,,構成されている。,, ,,,,　各店舗のレジは開店から並んでいる状態である。従って、第1番目の業務の特性として、販売システムは,, ,,,,高い応答性が要求されるという点を挙げることができる。また、一般に知られている通り、家電量販店業界,, ,,,,は競合他社との競争が激化しているという第2の業務の特性を挙げることができる。新システムでは、他店,, ,,,,との価格競争に勝つために日中に販売価格を緊急に変更する緊急売価変更機能を持っている。,, ,,,,　新旧システムは両方とも、本社に本社サーバを設置し、店舗在庫マスタ、配送センタ在庫マスタ、商品マス,, ,,,,タ、発送指示データを除くマスタの内容については同期している。,, ,,,,,, ,,●設問イでは、二つ挙げた業務の特性を踏まえて論旨展開をする。,,,, ,,,,,, ,〔１．２　段階移行の方法〕,,,,, ,,,,,, ,,　段階移行については問題文に例が挙がっているので、それを参考にして論述する。,,,, ,,,,,, ,,◆論述例,,,, ,,,,,, ,,,１．２　段階移行の方法,,, ,,,,,, ,,,,　販売システムは移行が失敗した場合の損失が大きいため、店舗ごとに旧システムから新システムへ順次,, ,,,,切り替える方法を取ることにした。従って、販売システムは、移行期間中に新旧システムを両方稼働させ、,, ,,,,全店舗の切り替え終了後、旧システムを停止するようにした。,, ,,,,　このような移行方法を採用した場合、データの二重管理や新旧システムの機能差異の課題が生じる。私,, ,,,,はA社の販売システムの開発を請け負ったソフトウェア会社のシステムアーキテクトの立場で、高い応答性,, ,,,,確保と新機能のリリースを早めた競争力の向上を重視して、新旧システムの並行運用期間の課題を次のよ,, ,,,,うにして解決した。,, ,,,,,, ,,,●この論述例のように、設問アの終わりでは設問イにつなげる文章を書くようにする。,,, ,,,,,, 第2章　想定した並行期間中の課題,,,,,, ,,,,,, ,〔２．１　想定した並行期間中の課題〕,,,,, ,,,,,, ,,　設問イに注目すると、「あなたは並行運用期間中の課題をどのように想定し」と記述してある。「あなたはどのよう,,,, ,,な並行運用期間中の課題を想定し」という問いならば課題を挙げればよいが、この問題の場合、課題だけではな,,,, ,,く、課題を導く方法についても問われていることが分かる。この点に留意して論旨を展開する。,,,, ,,　課題については、論述例のように問題文にあがっているトピックをそのまま流用してもよい。なお、一般的に設問,,,, ,,イでは、前半に注力しないで、後半の対応方法にポイントを置いて論述することが重要である。,,,, ,,,,,, ,,◆論述例,,,, ,,,,,, ,,,第2章　業務の特性を踏まえて想定した並行期間中の課題と課題への対応方法,,, ,,,２．１　想定した並行期間中の課題,,, ,,,,,, ,,,,　並行期間中の課題をすべて洗い出すために私は、新旧システムのシステムフローや業務フローを比較・,, ,,,,検討することにした。なぜならば、システム面と業務面の両方から課題を洗い出すことで、課題抽出の漏れ,, ,,,,をなくすことができると考えたからである。その結果、次の課題が判明した。,, ,,,,,, ,,,,（１）データの二重管理,, ,,,,,, ,,,,,　新旧システムの両システムの本社サーバで管理している、店舗在庫マスタ、配送センタマスタ、商品マ, ,,,,,スタなどのマスタについては、両システムで同期を取らなければならない。データの二重管理が問題とな, ,,,,,った。, ,,,,,, ,,,,（２）新旧システムの機能差異,, ,,,,,, ,,,,,　新システムが持つ新機能を早期にリリースしたいが、旧システムでは、その機能を持たない。そのため, ,,,,,、機能差異が課題となった。できるだけ早く新機能をリリースしたい。, ,,,,,, ,,●論述例のように「課題」というキーワードを使って、しっかりと題意に沿って論述することが重要である。,,,, ,,,,,, ,〔２．２　課題への対応〕,,,,, ,,,,,, ,,　ここは論文の第1のヤマ場である。しっかりと理由を示してシステムアーキテクトとしての考え方をアピールする。,,,, ,,,,,, ,,◆論述例,,,, ,,,,,, ,,,２．２　課題への対応方法,,, ,,,,,, ,,,,　業務の特性を踏まえて私は、次のようにして課題へ対応した。,, ,,,,,, ,,,,（１）即時と日次バッチ処理の混合による同期,, ,,,,,, ,,,,,　新旧システム間のデータの二重管理の方法としては、①即時同期、②日次バッチ処理同期、③即時と, ,,,,,日次バッチ処理の混合による同期、という方法を検討した。私は、販売システムは高い応答性が要求さ, ,,,,,れるという業務の特性を踏まえて③を採用した。, ,,,,,　具体的には、各店舗からリアルタイムな在庫更新が必要な配送センタ在庫マスタに限定して即時同期, ,,,,,を採用し、その他のマスタについては日次バッチ処理同期を採用することにした。なぜならば、即時同期, ,,,,,をできるだけ減らすことによって、並行期間中の応答性の低下や暫定的な変更により生じる新システム, ,,,,,の品質低下を最小にできると考えたからである。, ,,,,,, ,,,,（２）並行期間中における緊急売価変更機能のリリース,, ,,,,,, ,,,,,　新旧システムの機能差異という課題については、①並行期間中では新システムの機能は使わない、②, ,,,,,新機能を限定してリリースする、という案を検討した。そこで私は、家電量販業界は競合他社との競争が, ,,,,,激化しているという業務の特性を踏まえて、②を採用し、日中に販売価格を緊急に変更する緊急売価変, ,,,,,更機能を並行期間中にリリースすることにした。なぜならば、これによって、新システムのメリットを並行, ,,,,,期間中も享受できると考えたからである。, ,,,,,　なお、旧システムの店舗については、運用上の負荷や迅速性が低下するが、従来の方法で緊急売価, ,,,,,変更を行うようにした。, ,,,,,　以上の対応方法を選択したが、即時と日次バッチ処理の混合による同期については、実施する段階で, ,,,,,次のような課題が生じることが判明した。, ,,,,,, ,,●設問で明示的に「理由」が求められているので、「なぜならば」を使ってしっかりと理由を明示することが重要で,,,, ,,ある。,,,, ,,,,,, 第3章　対応方法を実施する上で重要と考えた課題と工夫した点,,,,,, ,,,,,, ,〔３．１　対応方法を実施する上で重要と考えた課題〕,,,,, ,,,,,, ,,　設問ウは字数が600字以上と、設問イに比べて少なくてよい。そのため実施段階での工夫した点は設問イで述べ,,,, ,,た二つの対応方法のうち一つに絞って、一つのトピックで論旨を展開している。このような展開であっても、設問ウ,,,, ,,の「設問イで述べた対応方法を実施する上で」という解答条件を満足しているので、大幅減点されることはない。,,,, ,,　工夫をアピールするためには、困難な状況や課題を明示することが重要である。そのうち、この例では課題を使,,,, ,,って工夫した点をアピールしている。,,,, ,,,,,, ,,◆論述例,,,, ,,,,,, ,,,第3章　対応方法を実施する上で重要と考えた課題と工夫した点,,, ,,,３．１　対応方法を実施する上で重要と考えた課題,,, ,,,,,, ,,,,　対応方法を決めたうえで、新旧システムの両システムを盛り込んだ並行期間中のシステムフローを作成し,, ,,,,た結果、配送完了処理における配送指示データの保存場所という課題が判明した。具体的には次の通りで,, ,,,,ある。,, ,,,,　マスタについては、新システムの即時と日次バッチ処理の混合による同期という対処方法で問題はなかっ,, ,,,,た。しかし、トランザクションデータについては、新旧システムの両方に存在していてはデータの二重管理と,, ,,,,なりかねないため、両システム間で同期をとることができない。そこで問題となったのが、配送指示データの,, ,,,,配置場所である。,, ,,,,　配送センタでは、店舗が配送指示処理を行い作成した、本社サーバ内の配送指示データを更新して配送,, ,,,,完了処理を行う。並行期間中は、該当店舗が移行前の場合、配送指示データは旧システムの本社サーバ,, ,,,,にある。移行後の場合は新システムの本社サーバにある。配送指示データが、新旧システムのどちらの本,, ,,,,社サーバにあるか、判別する必要があるという課題があった。,, ,,,,,, ,,●以上のように課題を明示することで、次で述べる工夫した点の妥当性を確保していることがポイントである。,,,, ,,,,,, ,〔３．２　工夫した点〕,,,,, ,,,,,, ,,　「工夫」を辞書で引くと「、「いろいろ考えた点」とある。従って、いろいろ考えたことを明示すればよい。,,,, ,,,,,, ,,◆論述例,,,, ,,,,,, ,,,３．２　工夫した点,,, ,,,,,, ,,,,　配送完了処理における配送指示データの場所の判別という課題について次のような案を検討した。,, ,,,,,, ,,,,①新システムにおける暫定的な対応,, ,,,,,, ,,,,,　店舗の移行日をシステムで持ち、配送完了処理を行う際に使用する配送指示伝票の作成日が移行前, ,,,,,なら旧システムの、移行後ならば新システムの本社サーバの配送指示データを参照するように新システ, ,,,,,ムで暫定的に対応する。, ,,,,,, ,,,,②運用による対応,, ,,,,,, ,,,,,　店舗の移行スケジュールを配送センタの処理担当者に渡し、配送完了処理を行う際に使用する配送指, ,,,,,示伝票の作成日が該当店舗の移行日より前の場合は、旧システムで配送指示処理を行ったと判断し旧, ,,,,,システムで処理する。作成日が該当店舗の移行日以降の場合は新システムで配送指示処理を行ったと, ,,,,,判定して、新システムで処理する。, ,,,,,, ,,,,　私は暫定的な対処であることを重視して、②の運用で対処する方法を選択した。このように私は暫定的,, ,,,,な対処を最小限に抑え、できるだけ運用側で対処することで、新システムの品質を確保するように工夫し,, ,,,,てシステムの段階移行を成功させた。,, ,,,,,, ,,●このように設問ウにおいても十分な論旨展開が要求されるが、制限時間内に論述を終了させるために、「設問,,,, ,,イで述べた対応方法を実施する上で」と解答条件が指示された場合であっても、トピック数を絞り込んで論述する,,,, ,,ことが重要である。,,,, ,,,,,, 平成２１年度　問２　システムの段階移行,,,,,, ,,,,,, ,　企業活動の中心となる販売管理システム、生産管理システム、会計システムなどの基幹業務システムを再構築し,,,,, ,た場合、これらは一般的に規模が大きいシステムなので、一括移行ではなく、段階移行を選択する場合が多い。,,,,, ,　例えば、多数の店舗を保有する企業では、店舗システムを、店舗ごとに旧システムから新システムへ順次切り替え,,,,, ,る方法をとる。その場合、本部システムは、店舗システムの切替期間中、新旧システムを両方稼働させ、全店舗の,,,,, ,切替終了後、旧システムを停止する。,,,,, ,　このような場合は、新旧システムが併存する並行運用期間が発生するので、システムアーキテクトは、その間の対,,,,, ,応を検討する必要がある。例えば、データの二重管理、新旧システムの機能差異などの課題に対し、次のような対,,,,, ,応が必要になる。,,,,, ,,,,,, ,,・,日中にマスタファイルのデータの変更を行うとき、新旧システムの両方のマスタファイルの同期をとって変更す,,, ,,,る必要があるので、一度の変更で両方のマスタファイルを更新する機能を追加する。,,, ,,・,全社が新システムに切り替わるまで、新旧システムの機能差異を埋めるための暫定的な対応を行う。,,, ,,,,,, ,　その際、例えば、次のような工夫を行う。,,,,, ,,,,,, ,,・,並行運用期間中だけ利用する追加の機能は、削除する際にほかの機能に影響を与えない方法で実装する。,,, ,,・,暫定的な対応を行うとき、基幹業務システムでの対応、EUCによる対応、運用による対応などを組み合わせて,,, ,,,、工期、工数を最小限にとどめる。,,, ,,,,,, ,設問ア,,,あなたが移行に携わったシステムの概要と、段階移行の方法について、800字以内で述べよ。,, ,設問イ,,,設問アで述べたシステムについて、あなたは並行運用期間中の課題をどのように想定し、その課題に対し,, ,,,,てどのような対応方法を選んだか。その課題、対応方法、選んだ理由を、業務の特性を踏まえて、800字以,, ,,,,上1600字以内で具体的に述べよ。,, ,設問ウ,,,設問イで述べた対応方法を実施する上で、重要と考え工夫した点について、600字以上1200字以内で具体,, ,,,,的に述べよ。,, ,,,,,, ■解答例,,,,,, ,,,,,, ,（設問ア）,,,,, ,,,,,, ,１．私が移行に携わったシステムの概要,,,,, ,,,,,, ,,　K社は、北日本の地方都市を中心に約150店舗を運営するスーパマーケットである。日本全体の人口減少やコ,,,, ,,ンビニエンスストアの拡大によって、K社の売上高は微減し続けていた。その当時、大手のスーパマーケットは、イ,,,, ,,ンターネットで注文を受け付けて、店舗から顧客が指定する場所に注文商品を配達するネットスーパ事業を開始,,,, ,,していた。K社の経営者層は、経営計画策定時に、ネットスーパ事業への参入とそれに対応するシステム（以下、,,,, ,,Nシステムという）の開発を決定した。Nシステムの主な対象業務は、会員管理業務・注文受付業務・商品集荷業,,,, ,,務・商品引渡業務・店舗運営管理業務である。私は、K社の情報システム部に所属するシステムアーキテクトであ,,,, ,,り、当システム開発プロジェクトの設計チームリーダに任命された。,,,, ,,,,,, ,２．採用された段階移行の方法,,,,, ,,,,,, ,,　K社の経営者層は、ネットスーパ事業の売上高が損益分岐点を超え、利益を計上できるまでには3年間は必要,,,, ,,であり、試行錯誤を伴うと考えていた。そこで、K社の経営者層は、①K社の約30店舗（以下、試行店舗という）はN,,,, ,,システムの本番稼働時期に合わせて、ネットスーパ事業を開始する。②試行店舗を3か月間運営して、収益性や,,,, ,,問題点を把握する。③Nシステムの本番稼働日から4か月後に、改善点を織り込んで残りの約120店舗のネットス,,,, ,,ーパ事業を開始する。④ただし、収益性が見込めない店舗は、ネットスーパ事業を行わない、という方針を決定し,,,, ,,た。したがって、Nシステムの移行は一斉移行ではなく、店舗ごとに本番稼働時期の異なる段階移行の方法が採,,,, ,,用されることになった。また、K社が運用してきたPOS端末を含む販売管理システム（以下、既存システムという）,,,, ,,の一部が変更され、段階移行の期間中は、その並行運用が必要になった。,,,, ,,,,,, ,（設問イ）,,,,, ,,,,,, ,１．私が想定した並行運用期間中の課題,,,,, ,,,,,, ,,　試行店舗がNシステムと既存システムの両方を3か月間運営しているとき、それ以外の店舗は既存システムだ,,,, ,,けを運用することになった。そこで、私はその並行運用期間の課題の検討を開始した。,,,, ,,,,,, ,１．１　データの二重管理による課題,,,,, ,,,,,, ,,　Nシステムの商品マスタテーブルは、既存システムの商品マスタテーブルとは別に存在している。Nシステムの,,,, ,,商品マスタテーブルには、”商品の画像”、”冷蔵輸送要否区分”など既存システムの商品マスタテーブルには,,,, ,,ない列と、両者に共通する列である”商品名”、”商品分類コード”などが存在する。したがって、並行運用期間中,,,, ,,に商品マスタを変更しなければならないとき、Nシステムと既存システムの両方の商品マスタテーブルの同期をと,,,, ,,って変更する必要があった。,,,, ,,,,,, ,１．２　会員が商品を店舗で引き取る場合に生ずる課題,,,,, ,,,,,, ,,　顧客である会員がネットスーパの注文受付画面から発注した商品を受け取る方法には、（a）宅配便を使って自,,,, ,,宅で商品を受け取り、（b）日時を指定して店舗で商品を受け取りの2つがあった。各試行店舗は、①（a）のみ対応,,,, ,,、②（a）（b）の両方に対応、③当初は①の未対応だが、多店舗の状況によって②に変更予定、の３つのうち、いず,,,, ,,れか１つを選ばねばならなかった。この③に該当する試行店舗は、並行運用期間中に、当該試行店舗の既存シ,,,, ,,ステムのPOS端末プログラム更新、会員受取用商品置場や冷蔵・冷凍設備の新設、店舗担当者の教育訓練など,,,, ,,のいくつかの課題を克服しなければならなかった。,,,, ,,,,,, ,２．私が選択した対応方法,,,,, ,,,,,, ,,　私は、上記2点の課題に対し、業務の特性を踏まえて下記の対応方法を選択した。,,,, ,,,,,, ,２．１　データの二重管理による課題,,,,, ,,,,,, ,,　私は、Nシステムの商品マスタテーブルと既存システムの商品マスタテーブルとを異なる２つのマスタ管理プロ,,,, ,,グラムによって維持すると、両テーブルが不一致になる可能性を否定できないと考えた。そこで、私は両テーブル,,,, ,,を一括して登録・修正・削除する商品マスタ管理プログラムを追加する設計をした。また、豆乳の冷蔵輸送要否区,,,, ,,分のように、担当者によって商品属性の解釈が異なる場合がある。そこで私は、本社の商品管理課の担当者等,,,, ,,の特定者だけが、この商品マスタ管理プログラムを使った商品テーブルの登録・修正・削除のアクセス権を保有,,,, ,,するものとした。,,,, ,,,,,, ,２．２　会員が商品を店舗で引取る場合に生ずる課題,,,,, ,,,,,, ,,　私は、設問イの１．２で述べた、各試行店舗が①②③のいずれかの方法を選ぶ場合であっても、すべて②の方,,,, ,,法を選んだものとみなした運用環境を想定した暫定的な対応を行った。例えば、会員が日時を指定して店舗で商,,,, ,,品を受け取る場合、鮮度が要求される商品については荷揃え時にPOS端末でバーコードを読み取り、商品引渡,,,, ,,時点での賞味期限チェックを行わなければならない。したがって、③の方法を選んだ店舗は試行期間中に急遽、,,,, ,,そのような既存システムにはない新プログラムをPOS端末に導入しなければならず、混乱が予想された。そこで,,,, ,,私は、試行店舗のすべてにこのような新プログラムを導入しておくものとした。ただし、誤運用を回避するために、,,,, ,,新プログラムの起動時にはIDとパスワードが要求されるように設計し、①の方法を選んだ店舗での起動を事実上,,,, ,,排除した。,,,, ,,,,,, ,（設問ウ）,,,,, ,,,,,, ,１．対応方法を実施するうえで、重要と考え工夫した点,,,,, ,,,,,, ,,　設問イで述べた対応方法を実施するうえで、私が重要と考え工夫した点は、以下の通りだった。,,,, ,,,,,, ,１．１　データの二重管理による課題,,,,, ,,,,,, ,,　私が重要と考えたのは、Nシステムの商品単価の設定だった。既存システムでの顧客が購入する商品の単価,,,, ,,は、POS端末の単価テーブルに格納されている。このPOS端末の単価は、次の流れに沿って設定される。①本社,,,, ,,の商品管理課が標準単価テーブルを設定する。②本社の商品企画部が、全店舗に共通した特売企画の単価を,,,, ,,、共通特売単価テーブルに設定する。③各店舗の店長は、店舗独自特売企画の単価を決定し、本社の商品企画,,,, ,,部が承認して、店舗独自売単価テーブルにその単価を設定する。④①を転送用本社単価テーブルにコピーし、②,,,, ,,をその転送用本社単価テーブルに上書きし、さらに③をその転送用本社単価テーブルに上書きする。⑤④の,,,, ,,転送用本社単価テーブルを核店舗サーバの店舗共通単価テーブルにレプリケーションする。⑥開店直前に、⑤,,,, ,,の店舗共通単価テーブルは、店舗内のPOS端末の単価テーブルにレプリケーションされる。,,,, ,,　ネットスーパ事業の単価も、この①～⑥の流れに沿って設定されなければならない。しかし、K社の経営者層は,,,, ,,、ネットスーパの会員を増やすために、例えば、缶ビール36本を一度に注文すると店舗の単価よりも10％値引き,,,, ,,するようなネットスーパ独自の単価設定機能が必要と考えた。そこで私は、上記の②の設定画面に、ネットスーパ,,,, ,,用の単価を設定する欄を追加し、ネットスーパ用の共通特売単価テーブルも更新する工夫をした。私は、並行運,,,, ,,用期間中はこのプログラムを運用し、会員が予定通り増加した時点でこのプログラムの運用を停止するものとし,,,, ,,た。,,,, ,,,,,, ,１．２　会員が商品を店舗で引取る場合に生ずる課題,,,,, ,,,,,, ,,　私は、起動時にIDとパスワードが要求される新プログラムを運用するのは、並行運用期間中だけであり、並行,,,, ,,運用後は設問イで述べた①もしくは②の運用方法に従ったプログラムをPOS端末に格納させるものとした。私は,,,, ,,、起動時にIDとパスワードが要求される新プログラムを削除する際に他の機能に影響を与えない方法で実装する,,,, ,,工夫をした。,,,, ,,,,,, 平成２２年度　問１　複数の業務にまたがった統一コードの整備方針の策定,,,,,, ,,,,,, ,　近年、事業を横断した顧客動向の把握、事業グループ全体での在庫量の適正化などを目的に、複数の業務にま,,,,, ,たがった業務改善が行われている。このような業務改善では、複数の業務間で統一的に集計や分析をするために、,,,,, ,顧客、仕入先、製品などそれぞれに、統一したコード（以下、統一コードという）を付与することが多い。,,,,, ,　しかし、一般に、業務ごとに利用しているコードは、体系だけでなく、コードを付与している対象や範囲などが異なる,,,,, ,ことも多い。例えば、同じ顧客コードであっても、付与している対象が企業の場合と企業に属する個人の場合がある,,,,, ,。また、付与している範囲が契約先だけを対象にしている場合と契約先に加えて契約見込み先などを対象にしてい,,,,, ,る場合がある。,,,,, ,　その際、システムアーキテクトは各業務の特性を踏まえ、統一コードの体系、統一コード付与の対象や範囲、個別,,,,, ,の業務利用しているコードとの変換方法など、統一コードの整備方針を策定する。,,,,, ,　統一コードの整備方針の策定では、例えば、次のような視点から現状の業務やシステムを調査する。,,,,, ,,・,現状のコード体系や、コードを付与している対象、範囲の違い,,, ,,・,新たなコードを付与することによる、業務やシステムへの影響,,, ,　また、与えられたコストと期間で業務改善を実現するために、統一コードの付与を業務改善効果の大きな業務に限,,,,, ,定する、あるいはコード変換機能を一元化して既存システムへの影響を排除するなどの工夫をすることも重要である,,,,, ,。,,,,, ,,,,,, ,設問ア,,,あなたが携わった統一コードの整備方針の策定における、複数の業務にまたがった業務改善の目的と、,, ,,,,対象のコードについて、800字以内で述べよ。,, ,設問イ,,,設問アで述べた業務改善を実現するために、あなたは現状の業務やシステムをどのような視点から調査し,, ,,,,たか。また、その結果に基づいて、どのような統一コードの整備方針を策定したか。800字以上1600字以内,, ,,,,で具体的に述べよ。,, ,設問ウ,,,設問イで述べた整備方針の策定で、与えられたコストと期間で業務改善を実現するために重要と考え、工,, ,,,,夫した点を、600字以上1200字以内で具体的に述べよ。,, ,,,,,, ■ポイント,,,,,, ,,,,,, ,■出題趣旨,,,,, ,,,,,, ,,　近年、業務横断での業務改善が増えている。このような業務改善では、複数の業務間で統一的に集計や分析,,,, ,,をするために統一したコードを新たに設定することがある。システムアーキテクトは、業務改善を実現するために,,,, ,,、全体最適の観点から統一コードの整備方針を策定する。その際、業務改善の目的を達成するだけでなく、与え,,,, ,,られたコストと期間について配慮することも重要である。,,,, ,,　本問は、現状の業務やシステムをどのような視点から調査し、どのような統一コードの整備方針を策定したか、,,,, ,,また、どのような工夫をしたかについて、具体的に論述することを求めている。論述を通じて、システムアーキテク,,,, ,,トに必要なシステムの分析能力、仕様の調整能力などを評価する。,,,, ,,,,,, ,■採点講評,,,,, ,,,,,, ,,　全問に共通して、具体性があり、経験に基づいた論述が多かった一方、”論述の対象とする計画又はシステム,,,, ,,の概要”、”論述の対象とする製品又はシステムの概要”が適切に記入されていないので評価を下げた論述が相,,,, ,,当数あった。また、問題文を引用しているだけなど具体性に乏しい論述や、各設問で整合の取れていない論述が,,,, ,,散見された。このような論述は、受験者の能力や経験を正しく評価できない場合があるので、実際の経験に基づ,,,, ,,き設問に沿って具体的に論述してほしい。,,,, ,,　また、論述は第三者に読ませるものであることを意識してほしい。例えば、段落を分けることで何についての記,,,, ,,述なのかを明確にする、業界特有の用語は説明を入れるなど、考えを的確に伝えるための工夫をしてほしい。,,,, ,,　問１（複数の業務にまたがった統一コードの整備方針の策定について）では、具体性があり、経験に基づいたと,,,, ,,思われる論述が多かった。設問では、業務改善の目的、調査の視点、業務改善実現のための工夫などの論述を,,,, ,,求めたが、業務改善のためではなくコードの統一自体を目的にするものや、業務と無関係に桁数などを調査した,,,, ,,だけのもの、工夫点が業務改善と関係の薄いものが目立った。システムアーキテクトは、業務を理解して情報シ,,,, ,,ステムの構造を設計する役割をもつので、業務の視点からの論述を期待したが、そのような論述は少なかった。,,,, ,,,,,, ,■解説,,,,, ,,,,,, ,,　本問は、複数の業務にまたがった統一コードの整備方針の策定がテーマの問題である。論文では、どのように,,,, ,,統一コードを設計したかではなく、どのように統一コードの整備方針を策定したかを記述しなければならない。ま,,,, ,,た、問題文では「複数の業務にまたがった」という表現がされているため、少なくとも二つ以上の業務間でコードを,,,, ,,共有した事例で論文を書く必要がある。どのような方針で調査を行い、方針を策定した際の工夫点も記述する。,,,, ,,,,,, ,,　設問アでは、統一コードの整備を行うに当たって、「業務改善の目的」と「統一の対象となったコード」の説明を,,,, ,,記述する。設問アは、設問イ、ウで記述する内容の裏付けとなるため、ここで説得力のあるコード化の目的や対,,,, ,,象コードの説明をしておきたい。特に、対象コードについては、設問イ、ウの記述の中で、設問アで説明していな,,,, ,,かったコード名が突然出現するようなことがないように注意しよう。また、設問アは、800字以内という字数制限が,,,, ,,あるため、業務改善の目的と対象コードの説明の配分にも注意を払う必要がある。,,,, ,,,,,, ,,　設問イでは、統一コードを整備するに当たって行った「調査の視点」と「統一コードの整備方針」を記述する。設,,,, ,,問の記述が「どのような視点から調査したか」、「どのような統一コードの整備方針を策定したか」となっているた,,,, ,,め、調査方針と策定した整備方針だけを記述すればよいように受け取ってしまうが、どのような視点で調査したか,,,, ,,と統一コードの整備方針のつなぎとする調査結果も記述したほうが論文の流れがスムーズになる。ただし、設問,,,, ,,ウで工夫点を記述するため、設問イで調査及び策定時の工夫点まで記述してしまわないように注意しよう。,,,, ,,,,,, ,,　設問ウには、「整備方針の策定を行う上で実施した工夫点」を記述する。設問では、「与えられたコストと期間で,,,, ,,業務改善を実施するために」となっているため、コストと期間に関連する工夫点を記述するとよい。,,,, ,,,,,, ,■見出しとストーリ,,,,, ,,,,,, ,,略,,,, ,,,,,, ■解答,,,,,, ,,,,,, ,■設問ア,,,,, ,,,,,, ,,ア　複数の業務にまたがった業務改善の目的及び対象のコード,,,, ,,ア―１　複数の業務にまたがった業務改善の目的,,,, ,,,,,, ,,,　Ｘ社は、全国に販売営業所があるオフィスサプライ製品の販売会社である。法人顧客からの電話やＦＡＸで,,, ,,,の受注に加え、インターネットによる法人及び個人顧客向けの商品販売サイトも運営している。取扱商品は約,,, ,,,5万点、存在している。統一コード整備の主な対象業務は、大口法人顧客向けの受注管理業務とインターネッ,,, ,,,ト販売システムの受注管理業務である。販売管理システムを利用している業務部門とインターネット販売業務,,, ,,,を行っている業務部門が異なっており、それぞれにコード体系を管理運用していた。大口顧客向けの販売管,,, ,,,理システムとインターネット販売システムのコード統一化により、コード管理業務の効率化を図り、システム維,,, ,,,持管理コストの削減を行うことが業務改善の目的である。私は、この業務改善活動とそれに伴うシステム改修,,, ,,,作業にシステムアーキテクトとして参画した。,,, ,,,,,, ,,ア―２　対象のコード,,,, ,,,,,, ,,,　コード統一化対象となるのは、顧客コードと製品コードである。現状は、システムが別々の部門で管理されて,,, ,,,いたこともあり、顧客コードは大口顧客向けの販売管理システムとインターネット販売システムとで統一化され,,, ,,,ていなかった。特に、インターネット販売システムは、個人顧客を意識した顧客コードになっており、法人の登,,, ,,,録はできず、法人が利用する場合は、法人の購買担当者のアカウントを登録する方法になっている。また、製,,, ,,,品コードは、インターネット販売システム開始時に、販売管理システムのコード体系を流用し整備したが、これ,,, ,,,も新規追加商品等により、インターネット販売専用品の独自コードが存在している。,,, ,,,,,, ,■設問イ,,,,, ,,,,,, ,,イ　現状の業務をどのような視点で調査したか、および調査結果と統一コードの整備方針,,,, ,,イ―１　現状の業務をどのような視点で調査したか,,,, ,,,,,, ,,,　以下の視点で現状の業務及びコード体系の調査を行った。,,, ,,,,,, ,,,,・,現状のコード体系や、コードを付与している対象、範囲の違いと新たなコードを付与することによる業務, ,,,,,システムへの影響の２つの視点で現状の業務及びコード体系の調査を行った。, ,,,,,, ,,イ―２　調査結果と統一コードの整備方針,,,, ,,,,,, ,,,（１）調査結果,,, ,,,,,, ,,,,・,現状のコード体系や、コードを付与している対象、範囲の違い, ,,,,,, ,,,,,　販売管理システムは、法人顧客のみが顧客コード管理対象となっており、製品も法人顧客に納品する, ,,,,,ものだけが製品コードとして登録されていた。インターネット販売システムには、法人顧客担当者及び個, ,,,,,人顧客が顧客として登録されており、製品は、販売管理システムで販売されている製品以外に個人顧, ,,,,,客向けの製品も製品コードとして登録されていた。, ,,,,,, ,,,,・,新たなコードを付与することによる、業務やシステムへの影響, ,,,,,, ,,,,,　顧客コードに関しては、インターネット販売システムはシステム改修で対応できることが分かったが、, ,,,,,販売管理システム側は、インターネット販売とのコード統一化により顧客コードの登録業務を変更する, ,,,,,必要があることが判明した。また、製品コードについては、インターネット販売システムでは一部の商品, ,,,,,で供給元の製品コードをそのまま使っている商品があり、これに対応する必要があることが分かった。, ,,,,,, ,,,（２）統一コード整備の方針,,, ,,,,,, ,,,,・顧客コード,, ,,,,,, ,,,,,　個人会員もコードの統一対象に含めた場合、顧客数が膨大になりスケジュールに影響すると判断し、, ,,,,,法人会員のみを統一化対象とする方針にした。, ,,,,,, ,,,,・製品コード,, ,,,,,, ,,,,,　全取扱商品の製品コードを統一化対象とする方針とした。インターネット販売で用いていた供給元の, ,,,,,製品コードを利用していた製品に対しては、自社コード体系に沿った製品コードを新しく付与する。, ,,,,,, ,■設問ウ,,,,, ,,,,,, ,,ウ　重要と考え工夫した点,,,, ,,,,,, ,,,（１）統一コード付与範囲の限定による業務の効率化,,, ,,,,,, ,,,,　当初、顧客コードの統一コード付与を法人顧客と個人会員を併せて行えないか検討したが、個人会員の,, ,,,,ユーザ数が多く、また、個人会員は利用頻度に差があるため、法人会員を統一化コード付与対象とし、個,, ,,,,人会員はインターネット販売システムで管理する方針とした。また、法人会員の統一コード付与は、顧客コ,, ,,,,ードの同期を取るような中間機能を開発し、この機能を用いることで販売管理システムのコード管理業務に,, ,,,,影響が出ないような方式を取ることにした。これらの工夫によって、統一コード付与後の業務影響を最小に,, ,,,,抑えることができた。,, ,,,,,, ,,,（２）エンドユーザ部門の協力依頼,,, ,,,,,, ,,,,　コード統合の検討にあたって、コード統合の方針検討の打ち合わせに、販売管理システム及びインターネ,, ,,,,ット販売システムのコード管理担当者も参画してもらうように働きかけ、業務影響の早期発見に努めた。,, ,,,,,, ,,,（３）コード変換機能の開発,,, ,,,,,, ,,,,　販売管理システムとインターネット販売システムの顧客コードとの同期を取る中間機能を開発するととも,, ,,,,に、インターネット販売用の製品に関して、供給元の製品コードとの対応付けを行うコード一元管理機能を,, ,,,,開発する方針とし、手作業によるコード変換作業ができるだけ発生しないような工夫を行った。　以上,, ,,,,,, 平成22年度　問１　複数の業務にまたがった統一コードの整備方針の策定について,,,,,, ,,,,,, ,　近年、事業を横断した顧客動向の把握、事業グループ全体での在庫量の適正化などを目的に、複数の業務にまた,,,,, ,がった業務改善が行われている。このような業務改善では、複数の業務間で統一的に集計や分析をするために、顧,,,,, ,客、仕入れ先、製品などそれぞれに、統一したコード（以下、統一コードという）を付与することが多い。,,,,, ,　しかし、一般に、業務ごとに利用しているコードは、体系だけでなく、コードを付与している対象や範囲などが異なる,,,,, ,ことも多い。例えば、同じ顧客コードであっても、付与している対象が企業の場合と企業に属する個人の場合がある。,,,,, ,また、付与している範囲が契約先だけを対象にしている場合と契約先に加えて契約見込み先などを対象にしている,,,,, ,場合がある。,,,,, ,　その際、システムアーキテクトは各業務の特性を踏まえ、統一コードの体系、統一コード付与の対象や範囲、個別,,,,, ,の業務で利用しているコードの変換方法など、統一コードの整備方針を策定する。,,,,, ,,,,,, ,,・現状のコード体系や、コードを付与している対象、範囲の違い,,,, ,,・新たなコードを付与することによる、業務やシステムへの影響,,,, ,,,,,, ,　また、与えられたコストと期間で業務改善を実現するために、統一コードの付与を業務改善効果の大きな業務に限,,,,, ,定する、あるいはコード変換機能を一元化して既存システムへの影響を排除するなどの工夫をすることも重要である,,,,, ,。,,,,, ,,,,,, ,設問ア,,,あなたが携わった統一コードの整備方針の策定における、複数の業務にまたがった業務改善の目的と、対,, ,,,,象のコードについて800字以内で述べよ。,, ,設問イ,,,設問アで述べた業務改善を実現するために、あなたは現状の業務やシステムをどのような視点から調査し,, ,,,,たか。また、その結果に基づいて、どのような統一コードの整備方針を策定したか。800字以上1600字以内,, ,,,,で具体的に述べよ。,, ,設問ウ,,,設問イで述べた整備方針の策定で、与えられたコストと期間で業務改善を実現するために重要と考え、工,, ,,,,夫した点を、600字以上1200字以内で具体的に述べよ。,, ,,,,,, 【解説】,,,,,, ,,,,,, ,　情報システム分野からの出題である。問題のタイトルに含まれる「複数業務」、「統一コード」、「整備方針」というキ,,,,, ,ーワードを満足する論述が求められているため、難易度の高い問題である。,,,,, ,　問題文に沿って章立てした例を次に挙げる。,,,,, ,,,,,, ,第1章　業務改善の目的と対象コード,,,,, ,,１．１　業務改善の目的,,,, ,,１．２　業務コード,,,, ,第2章　調査の視点と整備方針の策定,,,,, ,,２．１　現状の業務調査やシステム調査の視点,,,, ,,２．２　統一コードの整備方針の策定,,,, ,第3章　業務改善の実現で重要と考え工夫したこと,,,,, ,,３．１　業務改善の実現で重要と考えたこと,,,, ,,３．２　業務改善の実現で工夫したこと,,,, ,,,,,, ,　次に各章、節ごとに論述のポイントを説明する。,,,,, ,,,,,, 第1章　業務改善の目的と対象コード,,,,,, ,,,,,, ,〔１．１　業務改善の目的〕,,,,, ,,,,,, ,,　通常の問題では、システムの概要について問われるが、この問題では、明示的に業務改善の目的について問う,,,, ,,ている。この場合、事前に準備したシステムの概要ではなく、しっかりと、業務改善の目的について明示的に論述,,,, ,,することが重要である。,,,, ,,　論述する題材は、問題のタイトルに含まれる「複数業務」「統一コード」「整備方針」を満足しなければならない。な,,,, ,,ぜならば、問題冊子に問題の趣旨に沿って論述しなければならないことが明記されているからである。特に見逃し,,,, ,,がちになる「複数業務」に留意する。論述例を次に示す。,,,, ,,,,,, ,,◆論述例,,,, ,,,,,, ,,,第1章　業務改善の目的と対象コード,,, ,,,１．１　業務改善の目的,,, ,,,,,, ,,,,　論述の対象とする業務は、A百貨店における2分化した二つの販売管理業務である。A百貨店は百貨店同,, ,,,,士で統合を行ったが、販売管理システムを統合できず、販売力が二分されたままで顧客価値の創造が不十,, ,,,,分であり、統合のメリットが出ない状況であった。,, ,,,,　そのような状況の中、顧客への価値を高めることで売り上げや利益の向上を狙うという業務改善の目的の,, ,,,,もと、カテゴリマネジメントの導入を決定した。単なる価格競争から抜け出すためには、顧客に対して「買い,, ,,,,やすさ・利便性」、「役立つ情報」、「楽しさ」などの価値を、店頭を通じて提供していく必要がある。カテゴリマ,, ,,,,ネジメントはそのための手法である。各業務の特性として、一方は「店頭販売に強い」、もう一方は「外商販,, ,,,,売に強い」という点を挙げることができる。,, ,,,,,, ,〔１．２　対象コード〕,,,,, ,,,,,, ,,　論述の対象となるコードを明示して、そのコードについて説明する。必要に応じて設問イにつなげる文章を書いて,,,, ,,設問アを締めくくる。,,,, ,,,,,, ,,◆論述例,,,, ,,,,,, ,,,１．２　対象コード,,, ,,,,,, ,,,,　対象コードは、カテゴリごとの商品ライフサイクル全体を管理するカテゴリ統一コードである。このコードは,, ,,,,、商品を単品としてとらえるのではなく、顧客にとっての機能や価値といった観点から複数商品をカテゴリに,, ,,,,分類して設定する。,, ,,,,　商品構成をどう決め、限られたスペースの中でどう棚割りや販売促進を実施していくか。更に在庫を抑え,, ,,,,つつ欠品も防ぎ、売り場効率を上げるためにはメーカや卸との関係強化も必要であった。その解決には、百,, ,,,,貨店の販売商品のカテゴリをどのように設定するかがカギとなった。,, ,,,,　私は、A百貨店のシステムアーキテクトの立場で、次のようにカテゴリ統一コードの整備方針を策定して、,, ,,,,制約条件の下で業務改善を実施した。,, ,,,,,, 第2章　調査の視点と整備方針の策定,,,,,, ,,,,,, ,〔２．１　現状の業務調査やシステム調査の視点〕,,,,, ,,,,,, ,,　問題文に「現状のコード体系や、コードを付与している対象、範囲の違い」、「新たなコードを付与することによる、,,,, ,,業務やシステムへの影響」という例が挙がっているので、これを参考にして調査の視点を明示する。それに続く論,,,, ,,旨展開例としては、現状のコード体系を調査して、現状のコードを改善するか、新規にコードを追加するかを検討,,,, ,,する論旨展開を挙げることができる。,,,, ,,　論述の際に留意すべき点は、設問イの中核はこの前半部分ではなく、次の節の後半部分にあるということである,,,, ,,。前半部分で多く論じ過ぎないことが、時間内に合格論文を書くためには重要である。,,,, ,,,,,, ,,◆論述例,,,, ,,,,,, ,,,第2章　調査の視点と整備方針の策定,,, ,,,２．１　現状の業務調査やシステム調査の視点,,, ,,,,,, ,,,,　A百貨店では異なる二つの販売管理システムが稼働している状況を踏まえ、私は、次の二つの視点から,, ,,,,現状調査を実施した。,, ,,,,,, ,,,,（１）コードを付加している対象や範囲の視点,, ,,,,,, ,,,,,　統合以前の二つの百貨店では、一般顧客への店頭販売力、特定顧客への外商販売力など、「強み」, ,,,,,がそれぞれに異なる。そのため、コードを付加している対象や範囲が異なると考え、この視点を重視した, ,,,,,。, ,,,,,, ,,,,（２）新コードの運用開始による業務やシステムへの影響,, ,,,,,, ,,,,,　既存のコード体系を調査した結果、新コードの必要性が高いと判断した場合、新コードの運用開始によ, ,,,,,る影響を考慮する必要がある。なぜならば、システム開発予算や期間の制約条件を満足しなければなら, ,,,,,ないからである。そこで、既存のコードを捨て、新コードによる運用を開始した場合の影響を業務面とシス, ,,,,,テム面の両方で調査する必要があると考えた。, ,,,,,, ,,,,　以上の視点から調査した結果、次に述べる課題が判明した。,, ,,,,,, ,〔２．２　統一コードの整備方針の策定〕,,,,, ,,,,,, ,,　この節で重要なことは「策定」していることを、しっかりと表現しなければならない。すなわち、調査の結果から判,,,, ,,明した課題に対して、いろいろな整備方針案を検討する展開を盛り込むことが重要である。,,,, ,,　その次に必要なことは、次の二つである。,,,, ,,,,,, ,,（１）業務特性を踏まえる展開をする,,,, ,,,,,, ,,,　問題文において「システムアーキテクトは各業務の特性を踏まえ」と明記しているので、業務特性を踏まえた,,, ,,,論旨展開を明示的に行う。,,, ,,,,,, ,,（２）次の設問ウで述べる工夫と内容が重複しない,,,, ,,,,,, ,,,　冗長な論文は避けなければならない。従って、設問イでは、調査の結果に基づいた整備方針を説明し、設問,,, ,,,ウでは、コストと期間の制約の下で重視したことや工夫したことをアピールする展開を盛り込んで整備方針につ,,, ,,,いて論じる。,,, ,,,,,, ,,◆論述例,,,, ,,,,,, ,,,２．２　統一コードの整備方針の策定,,, ,,,,,, ,,,,　調査の結果、カテゴリマネジメントの導入には、各店舗を横断的に高い精度で見ることができないという課,, ,,,,題があることが判明した。,, ,,,,　各店舗を横断的に見たいというのは、各店舗で扱っている同一の商品をまとめて仕入れることで、原価を,, ,,,,引き下げたりするためである。従来のコード体系や、頻繁に変更するコード運用の結果、カテゴリマネジメン,, ,,,,トの求める精度を満足できないという、課題があった。,, ,,,,　このような課題に対して、次の整備方針を策定した。,, ,,,,,, ,,,,（１）年商予定額が均等になるようにカテゴリ統一コードの各要素を設定する整備方針,, ,,,,,, ,,,,,　従来のように、商品の用途と代替性で判断すると、カテゴリマネジメントでは粒度が粗くてよい商品が細, ,,,,,かく分けられすぎるということになる。そこで私は、店頭販売に強い、外商販売に強いという各業務の特, ,,,,,性を踏まえ、店頭と外商が扱う異なる商品群を最適な大きさにするために、年商予定額が均等になるよ, ,,,,,うにカテゴリ統一のコードの各要素を設定する方針とした。なぜならば、カテゴリ統一コードの設定を誤る, ,,,,,と、粒度の粗い部分に年商額が集中して、誤った意思決定をすることがあると考えたからである。, ,,,,,, ,,,,（２）カテゴリ統一コードを3年は固定する整備方針,, ,,,,,, ,,,,,　頻繁に変更してしまうと、本来の目的である継続比較や各店舗比較ができなくなってしまう。そこで業務, ,,,,,特性を踏まえ3年は固定する整備方針とした。, ,,,,,, ,,,,　経営陣からは、決められたコストで半年間のうちに業務改善の実現が求められていた。そこで私は、次に,, ,,,,述べる工夫をして整備方針を追加策定した。,, ,,,,,, 第3章　業務改善の実現で重要と考え工夫したこと,,,,,, ,,,,,, ,〔３．１　業務改善の実現で重要と考えたこと〕,,,,, ,,,,,, ,,　設問ウの前半なので設問イと同様に簡潔に論述して設問ウの後半に注力する。重要と考えた根拠を明示するこ,,,, ,,とが重要である。,,,, ,,,,,, ,,◆論述例,,,, ,,,,,, ,,,３．１　業務改善の実現で重要と考えたこと,,, ,,,,,, ,,,,　コストと半年という期間の制約条件を踏まえると、A百貨店で稼働する二つの販売管理システムを統合し,, ,,,,て、全店舗を対象に、業務改善を実現することは要件定義の段階から困難な状況であった。,, ,,,,　そのような状況で私が特に重視したのは、制約条件下における業務改善効果の最大化である。経営陣か,, ,,,,ら百貨店統合の定量的な効果を早急に求められていたからである。,, ,,,,,, ,〔３．２　業務改善の実現で工夫したこと〕,,,,, ,,,,,, ,,　ここでは、まず課題を明示する。その後に工夫をアピールする。その方法には、（１）いろいろと検討したことを示,,,, ,,して工夫をアピールする方法、（２）困難な状況を説明してから施策を示すことで工夫をアピールする方法、があ,,,, ,,る。論述例では、前者を採用して工夫をアピールしている。,,,, ,,,,,, ,,◆論述例,,,, ,,,,,, ,,,３．２　業務改善の実現で工夫したこと,,, ,,,,,, ,,,,　カテゴリマネジメントの最大限の導入効果を半年後に引き出すために、私はシステムアーキテクトの立場,, ,,,,で、次の案を検討した。,, ,,,,,, ,,,,（１）カテゴリコードの片寄,, ,,,,,, ,,,,,　どちらかの販売管理システムが使うコードに片寄する。, ,,,,,, ,,,,（２）カテゴリコードの変換,, ,,,,,, ,,,,,　二つのコードを現状のまま稼働させ、それぞれをコードに変換する。, ,,,,,, ,,,,　以上の案を検討した結果、（２）を採用し、既存コードを変換して、既存の販売管理システムの上位システ,, ,,,,ムにあたる販売統合システムの入力とする整備方針とした。なぜならば、既存コードを片寄した場合、業務,, ,,,,への影響が大きく、制約条件下での実施は困難と判断したからである。また、カテゴリ統一コードを新設し、,, ,,,,コード変換の精度をあげることで、カテゴリマネジメントの要求レベルを満足させることができると判断した。,, ,,,,　ただし、既存のカテゴリコードをカテゴリ統一コードに変換する方法が課題となった。そこで私は、二つの販,, ,,,,売管理システムに、（１）それぞれに別々のコード変換機能を持たせる、（２）統合したコード変換機能を持た,, ,,,,せる、という案を検討した。その結果、（１）を採用することにした。なぜならば、既存のカテゴリコードを単純,, ,,,,に変換しただけでは、カテゴリマネジメントの要求レベルを達成できず、トランザクションの発生時に複数の,, ,,,,コードを合成してカテゴリ統一コードに変換する必要があると考えた。そこで私は、二つの販売管理システム,, ,,,,ごとに異なるコード変換機能を実装する整備方針とした。,, ,,,,　このように各業務の特性を踏まえ、私はカテゴリ統一コードの整備方針を策定して、制約条件下で業務改,, ,,,,善の最大限の効果を引き出すことに成功した。,, ,,,,,, ,●なお、設問ウにおいて、「与えられたコストと期間で業務改善を実現するために重要と考え」と書いてあるので、重,,,,, ,要と考えたことをコストや期間とすることは、避けた方が無難と考える。そこで問題文に挙がっている「業務改善効果,,,,, ,の最大化」や「既存システムへの影響の排除」などを挙げると良い。,,,,, ,,,,,, 平成２２年度　問１　複数の業務にまたがった統一コードの整備方針の策定,,,,,, ,,,,,, ,　近年、事業を横断した顧客動向の把握、事業グループ全体での在庫量の適正化などを目的に、複数の業務にま,,,,, ,たがった業務改善が行われている。このような業務改善では、複数の業務間で統一的に集計や分析をするために、,,,,, ,顧客、仕入先、製品などそれぞれに、統一したコード（以下、統一コードという）を付与することが多い。,,,,, ,　しかし、一般に、業務ごとに利用しているコードは、体系だけでなく、コードを付与している対象や範囲などが異なる,,,,, ,ことも多い。例えば、同じ顧客コードであっても、付与している対象が企業の場合と企業に属する個人の場合がある,,,,, ,。また、付与している範囲が契約先だけを対象にしている場合と契約先に加えて契約見込み先などを対象にしてい,,,,, ,る場合がある。,,,,, ,　その際、システムアーキテクトは各業務の特性を踏まえ、統一コードの体系、統一コード付与の対象や範囲、個別,,,,, ,の業務利用しているコードとの変換方法など、統一コードの整備方針を策定する。,,,,, ,　統一コードの整備方針の策定では、例えば、次のような視点から現状の業務やシステムを調査する。,,,,, ,,・,現状のコード体系や、コードを付与している対象、範囲の違い,,, ,,・,新たなコードを付与することによる、業務やシステムへの影響,,, ,　また、与えられたコストと期間で業務改善を実現するために、統一コードの付与を業務改善効果の大きな業務に限,,,,, ,定する、あるいはコード変換機能を一元化して既存システムへの影響を排除するなどの工夫をすることも重要である,,,,, ,。,,,,, ,,,,,, ,設問ア,,,あなたが携わった統一コードの整備方針の策定における、複数の業務にまたがった業務改善の目的と、,, ,,,,対象のコードについて、800字以内で述べよ。,, ,設問イ,,,設問アで述べた業務改善を実現するために、あなたは現状の業務やシステムをどのような視点から調査し,, ,,,,たか。また、その結果に基づいて、どのような統一コードの整備方針を策定したか。800字以上1600字以内,, ,,,,で具体的に述べよ。,, ,設問ウ,,,設問イで述べた整備方針の策定で、与えられたコストと期間で業務改善を実現するために重要と考え、工,, ,,,,夫した点を、600字以上1200字以内で具体的に述べよ。,, ,,,,,, ■解答例,,,,,, ,,,,,, ,（設問ア）,,,,, ,,,,,, ,１．複数の業務にまたがった業務改善の目的,,,,, ,,,,,, ,,　K社は、北日本の地方都市を中心に約150店舗を運営するスーパマーケットである。日本全体の人口減少やコ,,,, ,,ンビニエンスストアの拡大によって、K社の売上高は微減し続けていた。その当時、大手のスーパマーケットは、イ,,,, ,,ンターネットで注文を受け付けて、店舗から顧客が指定する場所に注文商品を配達するネットスーパ事業を開始,,,, ,,していた。K社の経営者層は、経営計画策定時に、ネットスーパ事業への参入とそれに対応するシステム（以下、,,,, ,,Nシステムという）の開発を決定した。私は、K社の情報システム部に所属するシステムアーキテクトであり、Nシス,,,, ,,テム開発プロジェクトの設計チームリーダに任命された。K社の経営者層は、”店舗およびネットスーパでの全商,,,, ,,品の販売動向把握”を複数の店舗にまたがった業務改善の目的にした。この業務改善は、店舗とネットスーパで,,,, ,,の売上高伸び率や粗利益率などを比較し、経営上の的確な意思決定の支援を目的にしていた。,,,, ,,,,,, ,２．私が携わった統一コードの対象コード,,,,, ,,,,,, ,,　K社が販売する商品の商品コードには、メーカがバーコードとして付与するJAN（Japanese Article Number）コー,,,, ,,ドと各店舗が独自に採番するコード（以下、Dコードという）の２つがある。Dコードは、”コロッケ”、”唐揚げ”などの,,,, ,,店舗内で調理される商品や、”きゅうり”、”ねぎ”などの箱単位で入荷され、店舗で袋詰めされる商品に付けられ,,,, ,,る。Dコードは、各店長の判断によって店舗ごとに採番され、K社全体では統一されていない。例えば、ある店舗の,,,, ,,”トマト”と他の店舗の”焼き鳥”に同一の商品コードが付けられている場合もある。しかし、Nシステムの注文受付,,,, ,,画面に表示される商品には、全店舗で共通した商品コードを付けなければならないので、Dコードを統一したコー,,,, ,,ドを新たに設定することになった。,,,, ,,,,,, ,（設問イ）,,,,, ,,,,,, ,１．私が調査した現状の業務やシステムに対する視点,,,,, ,,,,,, ,,　私は、統一コードの整備方針の策定において、以下2つの視点から現状の業務やシステムを調査した。,,,, ,,,,,, ,１．１　Dコードの体系,,,,, ,,,,,, ,,　Dコードは、K社が従来運用している販売管理システム（以下、既存システムという）のPOS端末によって読み,,,, ,,込まれ、設定された単価をPOS端末に返すために付与される。したがって、Dコードには各店舗内での一意性が,,,, ,,あり、かつJANコード以外のコードが付与されなければならない。ただし、DコードはPOS端末での代金精算業務,,,, ,,以外の用途には使われていないので、K社全体で統一される必要がなかった。JANコードは13桁で構成され、日,,,, ,,本を意味する”４５”もしくは”４９”の国別コードで始まっている。そこで、Dコードは固定値である”２０”の後に各店,,,, ,,舗が独自に採番した10桁の連番を連結したコード体系になっている。,,,, ,,,,,, ,１．２　Dコードの対象範囲の違い,,,,, ,,,,,, ,,　K社の店舗の中には、K社ではない事業者が”焼き立てパン屋さん”のようなコーナーを開設している店舗がある,,,, ,,。そのパンの包装袋にもDコードが付けられ、K社のPOS端末によってK社の商品と一緒に代金精算がなされてい,,,, ,,る場合もある。また、日用品や雑貨を主に販売する店舗は、Dコードを付与した商品を取り扱っていない。したがっ,,,, ,,て、Dコードの対象範囲は、店舗によって様々だった。,,,, ,,,,,, ,１．３　統一コード付与による業務やシステムへの影響,,,,, ,,,,,, ,,　私は、全店舗で統一された商品コードをK社の業務や既存システムに適用した場合の影響を調査し、以下の結,,,, ,,論を得た。,,,, ,,,①,K社の商品企画部の担当者は、各店舗で使用されているDコードを一覧表にまとめ、統一コードを設定しな,, ,,,,ければならない。,, ,,,②,K社の商品企画部の担当者は、①の統一コードをPCに入力し、Dコードを統一コードに変換するためのファ,, ,,,,イルを作成しなければならない。,, ,,,③,各店舗の販売担当者は、②のファイルを使って既存システムの店舗サーバの商品マスタを更新しなけれ,, ,,,,ばならない。,, ,,,④,各店舗の販売担当者は、各商品のDコードのバーコードラベルを統一コードが付けられたバーコードラベル,, ,,,,に貼り換えなければならない。,, ,,　これらの作業を完了させるためには、K社全体で10人月程度の工数が掛かると見積もられた。,,,, ,,,,,, ,２．私が策定した統一コードの整備方針,,,,, ,,,,,, ,,　私は、上記の調査結果及び各業務の特性を踏まえ、以下3点の統一コードの整備方針を策定した。,,,, ,,,①,統一コードは、K社全体で一意性を保持する。,, ,,,②,統一コードの対象は、K社が取り扱う全商品とする。ただし、K社がK社以外の事業者のために採番した商,, ,,,,品コードを付与された商品も統一コードの対象とする。,, ,,,③,Dコードと統一コードを相互に変換するためのテーブル（以下、変換テーブルという）を新設する。,, ,,,,,, ,（設問ウ）,,,,, ,,,,,, ,１．業務改善を実現するために重要と考え、工夫した点,,,,, ,,,,,, ,,　私は、また、与えられたコストと期間で業務改善を実現するために、以下2点の工夫をした。,,,, ,,,,,, ,１．１　統一コードの付与範囲の限定,,,,, ,,,,,, ,,　私は、統一コードの付与範囲を業務改善効果の大きな以下の2業務に限定した。,,,, ,,,,,, ,,,①,Nシステムの注文受付業務,, ,,,,,, ,,,,　会員がWebブラウザの注文画面で選択する商品の商品コードを統一コードにする。,, ,,,,,, ,,,②既存システムの売上統計分析業務,,, ,,,,,, ,,,,　特定商品の前者時系列分析や店舗別比較分析等に統一コードを使用する。,, ,,,,,, ,,　したがって、既存システムの売上統計分析以外の業務では、従来通りDコードを使用する。,,,, ,,,,,, ,１．２　JANコードの統一コードへの組み入れ,,,,, ,,,,,, ,,　私は、統一コードの設定作業量を軽減するために、K社が使用しているJANコードを、そのまま統一コードに組,,,, ,,み入れることとした。これによって、実質的に統一コード設定作業は、Dコードの統一コード化に限定された。私,,,, ,,はこの設定作業を、以下の作業手順によって実行することとした。,,,, ,,,,,, ,,,①,Dコードが付与されている商品の商品分類基準を設定し、商品分類番号を含む商品分類マスタを作成する,, ,,,,。,, ,,,②,統一コードの先頭は”２１”に固定する。,, ,,,③,Dコードが付けられる全商品を一覧表にし、その統一コードの3桁目～7桁目に①の商品分類番号を設定す,, ,,,,る。,, ,,,④,統一コードの8桁以降は、K社全体の連番とし、同一商品には同一の連番を設定する。,, ,,,,,, ,１．３　Dコードと統一コードの変換機能の一元化,,,,, ,,,,,, ,,　私は変換テーブルを使って、Dコードと統一コードの変換機能を一元化し、既存システムへの影響を排除した。,,,, ,,具体的には以下3点の変換機能を設計した。,,,, ,,,①,変換テーブルの主キー属性は｛店舗番号、Dコード｝に、主キー属性以外の属性は統一コードにする。,, ,,,②,Nシステムの注文受付情報に記録されている統一コードと、注文入力した会員が利用する店舗番号を組み,, ,,,,として、変換テーブルの｛統一コード、店舗番号｝を参照し、Dコードを取得して店舗サーバに転送する。,, ,,,③,店舗サーバから本社サーバに転送された売上実績情報に記録されているDコードと店舗番号を組みとして,, ,,,,変換テーブルの｛Dコード、店舗番号｝を参照し、統一コードを取得して既存システムの売上統計分析機能,, ,,,,に転送する。,, ,,,,,, 平成２２年度　問２　システム間連携方式,,,,,, ,,,,,, ,　生産システム、物流システム、販売システムなどの企業内システムは、部門ごとに独立したシステムとなっている,,,,, ,場合がある。このため、販売システムで発生する顧客データを物流システムに渡して最新の顧客情報で出荷伝票を,,,,, ,出力する、販売システムで発生する販売データを生産システムの在庫情報に反映して迅速に生産計画を決定する,,,,, ,など、企業内の情報共有をシステム間連携によって実現することがある。システム間連携方式には、ファイル転送、,,,,, ,データベース共有、リアルタイム連携などがある。,,,,, ,　システムアーキテクトは、システム間連携方式を選択する際に、例えば、次のような業務要件に留意しなければな,,,,, ,らない。,,,,, ,,・,当日登録した顧客情報に基づいて、当日配送を可能とする必要がある。,,, ,,・,生産数の確定前に、拠点ごとの在庫数を確定する必要がある。,,, ,　これらの業務要件を踏まえ、データの収集と反映のタイミング、処理すべきデータ量などのシステム要件を明確に,,,,, ,する。その要件に基づき、データ伝送時間、システム間の整合性の維持などを考慮して、適切なシステム間連携方,,,,, ,式を選択する。,,,,, ,　さらに、運用時間帯、運用体制などの運用要件を明らかにし、稼働状況のモニタリング、異常の検知、障害発生時,,,,, ,の対応などの実現方法を検討することも重要である。,,,,, ,,,,,, ,設問ア,,,あなたが携わったシステム間連携方式の検討において、対象システムの概要と連携が必要になった背景,, ,,,,について、800字以内で述べよ。,, ,設問イ,,,設問アで述べたシステムを連携させる際に、あなたは、どのような業務要件を踏まえ、どのようなシステム,, ,,,,要件を明確にしたか。また、その要件に基づいてどのようなシステム間連携方式を選択したか、選択した理,, ,,,,由とともに、800字以上1600字以内で具体的に述べよ。,, ,設問ウ,,,設問イで述べたシステム間連携方式について、運用要件と実現方法を、重要と考えた点を中心に、600字,, ,,,,以上1200字以内で具体的に述べよ。,, ,,,,,, ■ポイント,,,,,, ,,,,,, ,■出題趣旨,,,,, ,,,,,, ,,　業務システムは、部門ごとに独立したシステムとなっている場合がある。このため、企業内の情報共有を目的と,,,, ,,して、システム間連携が行われている。システムアーキテクトは、対象とする情報システムの開発に必要となる要,,,, ,,件を分析、整理し、その要件を実現する最適なシステム方式を設計する。,,,, ,,　本問は、どのような業務要件を踏まえ、どのようなシステム要件を明確にし、その要件に基づいてどのようなシ,,,, ,,ステム間連携方式を選択したかについて、具体的に論述することを求めている。論述を通じて、システムアーキテ,,,, ,,クトに必要な、システム間連携方式の設計能力、運用の実践能力などを評価する。,,,, ,,,,,, ,■採点講評,,,,, ,,,,,, ,,　全問に共通して、具体性があり、経験に基づいた論述が多かった一方、”論述の対象とする計画又はシステム,,,, ,,の概要”、”論述の対象とする製品又はシステムの概要”が適切に記入されていないので評価を下げた論述が相,,,, ,,当数あった。また、問題文を引用しているだけなど具体性に乏しい論述や、各設問で整合の取れていない論述が,,,, ,,散見された。このような論述は、受験者の能力や経験を正しく評価できない場合があるので、実際の経験に基づ,,,, ,,き設問に沿って具体的に論述してほしい。,,,, ,,　また、論述は第三者に読ませるものであることを意識してほしい。例えば、段落を分けることで何についての記,,,, ,,述なのかを明確にする、業務特有の用語は説明を入れるなど、考えを的確に伝えるための工夫をしてほしい。,,,, ,,　問２（システム間連携方式について）では、企業統合などの大規模なものから、小規模システム間でのデータ連,,,, ,,携など多岐にわたる論述があり、様々な局面でシステム間連携方式の設計がなされていることがうかがわれた。,,,, ,,設問では、単一のシステムだけでなく複数のシステムを意識した業務要件、システム要件、連携方式という多角,,,, ,,的な論述を求めた。これは、システムアーキテクトが全体最適の観点からシステム構造を設計しなければならな,,,, ,,いからである。しかし、業務要件を論述せずにシステム要件や連携方式の説明に終始している論述や、業務要,,,, ,,件とシステム要件を混同している論述が多く見られた。,,,, ,,,,,, ,　複数のシステムにおけるデータ交換をシステム間連携によって実現することがテーマの問題である。生産システム,,,,, ,、物流システム、販売システムなど、企業内には多くのシステムが稼働している。各システムが独立に構築されてい,,,,, ,るような場合、システム間のデータ連携については構築時点で必要な部分のみが実装されることが多い。しかし、新,,,,, ,たな業務モデルの出現、新規市場への進出など、システムの構築時点では想定していなかった状況へとビジネス環,,,,, ,境が変化することもある。新しい状況に対応するためには、関連するシステムを一括して再構築するなどシステムの,,,,, ,刷新が理想であるが、費用面の制約があったり、短期間での実現が求められたりするため、システムの刷新は現実,,,,, ,味に欠ける場合がある。このような場合は、システム刷新に代わり、システム間連携によってデータ交換をすることを,,,,, ,検討する。システム間連携方式は、ファイル転送、データベース共有、リアルタイム連携などいくつかの方式が考え,,,,, ,られる。連携方式の選択に際しては、「何のために連携が必要なのか」という業務要件を踏まえ、業務要件を満たせ,,,,, ,るようにデータ交換の即時性、交換するデータ量、システム間の整合性などのシステム要件を明確にしなければなら,,,,, ,ない。,,,,, ,,,,,, ,　設問アでは、「対象システムの概要」と「システム間連携が必要になった背景」を記述する。対象業務について制約,,,,, ,がないため、どのような業務であっても題材にできる。ただし、システムの連携がテーマであるので、少なくとも二つ,,,,, ,のシステムが関連するような業務としなければならない。システムの概要は、何らかの形で複数のシステムに触れて,,,,, ,おく必要がある。システム間の連携が必要になった背景については、「なぜ連携が必要になったのか」という観点で,,,,, ,記述する。背景のみを記述することは難しいと考えられるので、業務の説明と併せて記述するとよい。「背景」の記述,,,,, ,が要求事項であるから、業務の説明に終始することのないようにくれぐれも注意したい。,,,,, ,,,,,, ,設問イでは、システム間連携の実現に際し、「業務要件を踏まえて明確にしたシステム要件」と、「システム要件に基,,,,, ,づいて選択したシステム間連携方式と選択の理由」を記述する。業務要件を踏まえて明確にしたシステム要件の記,,,,, ,述については、業務要件とシステム要件を混同しないように注意しなければならない。明確に分割して記述する必要,,,,, ,はないが、何が業務要件で、何がシステム要件なのかを論文の読み手（採点者）が分かるように表現する必要があ,,,,, ,る。業務要件は、設問アで述べた連携業務が必要になった背景と矛盾しないようにする。十分なストーリー作りをし,,,,, ,ておけば問題なく乗り切れると考えられる。業務要件としては、「当日登録した顧客情報に基づいて、当日配送を可,,,,, ,能とする制約がある」、「生産数の確定前に、拠点ごとの在庫数を確定する必要がある」と例が示されており、どの程,,,,, ,度まで業務要件を記述すればよいかの参考にできる。業務要件、システム要件のどちらも数多く記述する必要はな,,,,, ,く、中核になる要件を二つ、三つ取り上げればよい。多数のシステム要件を取り上げる場合は、要件間に相反する事,,,,, ,項が含まれることがあるため、論旨に矛盾が生じないように注意しておきたい。,,,,, ,,,,,, ,　設問ウでは、題材としたシステム間連携方式について、「運用要件」と「実現方法」を記述する。運用要件は幅広い,,,,, ,観点で考えることができ、何を取り上げてもよい。この問題では、運用要件として、運用時間帯、障害発生時の対応,,,,, ,という一般的な例が示されている。検討したシステム要件に対応させてシステム間連携を実現する場合に、運用上,,,,, ,注意しなければならないような要件を選択するとよい。実現方法としては、稼働状況のモニタリング、異常の検知、障,,,,, ,害発生時の対応という具体例が与えられている。システム間連携方式がリアルタイム連携であれば、実現方法とし,,,,, ,て稼働状況のモニタリングが必須であると考えられるように、システム間連携方式やシステム要件などと実現方法の,,,,, ,対応関係に注意して記述したい。,,,,, ,,,,,, ■見出しとストーリ,,,,,, ,,,,,, ,■設問,,,,, ,,,,,, ,,　設問アには、問題文の次の部分が対応する。,,,, ,,,,,, ,,,設問ア,,,あなたが携わったシステム間連携方式の検討において、対象システムの概要と連携が必要になった ,,,,,,背景について、800字以内で述べよ。 ,,,,,, ,,,　生産システム、物流システム、販売システムなどの企業内システムは、部門ごとに独立したシステムとなって,,, ,,,いる場合がある。このため、販売システムで発生する顧客データを物流システムに渡して最新の顧客情報で,,, ,,,出荷伝票を出力する、販売システムで発生する販売データを生産システムの在庫情報に反映して迅速に生産,,, ,,,計画を決定するなど、企業内の情報共有をシステム間連携によって実現することがある。,,, ,,,,,, ,,　例として次のような見出しとストーリーが考えられる。,,,, ,,,,,, ,,,ア　対象システムの概要と連携が必要になった背景,,, ,,,ア―１　対象システムの概要,,, ,,,,,, ,,,,・,顧客は会員制スポーツクラブを運営するA社, ,,,,・,システム間連携が必要になったのは、会員システム、設備・要員システム, ,,,,・,会員システムでは、顧客である会員の個人情報、予約情報、予約履歴などを管理する, ,,,,・,設備・要員システムでは、スポーツクラブの設備のスケジュール、保守履歴、スポーツクラブに所属する, ,,,,,インストラクタのスケジュールなどを管理する, ,,,,・,システムの一部が会員に開放され、インターネット経由でレッスンや施設の予約ができる, ,,,,・,例えばプールの利用など、レッスンや施設によって予約が不要のものもある, ,,,,・,自身の立場は、本件のシステム連携の構築を請け負ったシステムインテグレータP社に所属するシステ, ,,,,,ムアーキテクト, ,,,,,, ,,,ア―２　連携が必要になった背景,,, ,,,,,, ,,,,・,レッスンや施設の予約は、利用を希望する日の前日の午後８時までに行うことになっている, ,,,,・,前日の午後８時に締め切った予約を基に、インストラクタや施設の割り当てバッチJOBを実行し、翌日分, ,,,,,のインストラクタ手配、施設のスケジュール表の作成などを行う, ,,,,・,職場からの帰宅後に予約をする会員も多く、午後８時の締め切り時刻では早いという声が上がっていた, ,,,,・,新規の会員登録は本人確認のため店舗に出向く必要があり、午後６時が当日分の締め切り時刻であっ, ,,,,,た。一般の会社員からは、平日の午後６時までにはいけないという声も多い, ,,,,・,顧客サービスの拡大のため予約受付の延長を検討, ,,,,・,新規の会員登録もクレジットカードの信用情報に基づきWebから行えるように変更する, ,,,,・,午後8時以降に行われた翌日分の予約申し込み、Webから登録した新規会員の翌日分の予約申し込み, ,,,,,の処理を行うため、システム間連携により対応することとなった, ,,,,・,同業他社との競争が激しく顧客サービスの強化が幹部から指示されており、1カ月程度の短時間でサー, ,,,,,ビス稼働が必要である, ,,,,,, ,■設問イ,,,,, ,,,,,, ,,　設問イには、問題文の次の部分が対応する。,,,, ,,,,,, ,,,設問イ,,,設問アで述べたシステムを連携させる際に、あなたは、どのような業務要件を踏まえ、どのようなシ ,,,,,,ステム要件を明確にしたか。また、その要件に基づいてどのようなシステム間連携方式を選択した ,,,,,,か、選択した理由とともに、800字以上1600字以内で具体的に述べよ。 ,,,,,, ,,,　システム間連携方式には、ファイル転送、データベース共有、リアルタイム連携などがある。,,, ,,,　システムアーキテクトは、システム間連携方式を選択する際に、たとえば、次のような業務要件に留意しなけ,,, ,,,ればならない。,,, ,,,,・,当日登録した顧客情報に基づいて、当日配送を可能とする制約がある。, ,,,,・,生産数の確定前に、拠点ごとの在庫数を確定する必要がある。, ,,,　これらの業務要件を踏まえ、データの収集と反映のタイミング、処理すべきデータ量などのシステム要件を明,,, ,,,確にする。その要件に基づき、データ伝送時間、システム間の整合性の維持などを考慮して、適切なシステム,,, ,,,間連携方式を選択する。,,, ,,,,,, ,,　例として次のような見出しとストーリーが考えられる。,,,, ,,,,,, ,,,イ　業務要件、システム要件、及び選択したシステム間連携方式と選択の理由,,, ,,,イ―１　業務要件,,, ,,,,,, ,,,,・,スポーツクラブは毎日午前10時開店, ,,,,・,インストラクタが店舗に到着するまでに最大1時間30分を要する, ,,,,・,前日の割当処理分以外に追加で必要になったインストラクタの手配のためには、余裕時間を加味して2, ,,,,,時間前の午前8時には手配メールを配信する必要がある, ,,,,・,追加手配処理開始後に行われた当日分の利用申し込みは、空きがあった場合にのみ店舗にて受け付, ,,,,,ける, ,,,,・,午後８時以降の予約受付は、場合によってはインストラクタの手配が付かないような事態も考えられる, ,,,,,ため、仮予約の形で受け付ける, ,,,,,, ,,,イ―２　システム要件,,, ,,,,,, ,,,,・,重要な点は午前8時というリミットを超えないように手配メールを配信することである, ,,,,・,午後８時以降の予約情報は、あくまでも仮ということで会員システムにのみ蓄えられる, ,,,,・,午後8時までに予約できず、当日、電話や来店してレッスンや施設を予約する件数について、過去5年分, ,,,,,を調査すると平均70件程度である。ピークは金曜日、祝日の前日で約200件となっている, ,,,,・,午後8時から実行される割り当てバッチJOBの処理時間を過去5年分調査すると、処理件数が最大の場, ,,,,,合（約400件）で、20分程度要している。午後8時から翌朝までの予約件数がピーク時で約200件となって, ,,,,,いるため、当日の朝に追加で実行すべきレッスンや施設の割当JOBには10分程度を見込まなければな, ,,,,,らない。, ,,,,・,当日朝にインストラクタなどの割当を追加するために必要となる基データは、会員システムにのみ蓄え, ,,,,,ているため、会員システムから施設・要員システムに転送され、当日朝用の割当JOBを実行する, ,,,,・,会員システムと施設・要員システムは相互に高速LANで接続されており、毎日のバックアップ処理での, ,,,,,データ量とデータ転送時間を鑑みると、会員システムから施設・要員システムにデータを転送する時間, ,,,,,は、すべてのデータを一度で転送した場合でも、5分以下と考えられる, ,,,,・,午前8時の手配メール配信に間に合わせるために、連携処理を開始する時刻は余裕をもたせて午前7, ,,,,,時とする, ,,,,・,データの整合性については、会員システムに蓄えられた予約情報のデータを施設・要員システムのデ, ,,,,,ータベースに挿入（追加）するため、データベースの整合性制約によりデータの不整合が生じることはな, ,,,,,い。何らかの理由により挿入できなかったデータはエラーリストに出力する。エラーデータは、運用で対, ,,,,,応することとし、午前10時の開店時点で店舗にて参照できるようにする, ,,,,,, ,,,イ―３　選択したシステム間連携方式と選択の理由,,, ,,,,,, ,,,,・,候補としたシステム間連携方式は、データベースの共通化、リアルタイム連携、ファイル転送, ,,,,・,データベースの共通化については、会員システム、施設・要員システムで使用されているデータベース, ,,,,,を統合する必要がある。しかし、データベースの統合は、既存システムを構成するプログラムの修正が, ,,,,,必要になるなど影響は大きい, ,,,,・,今回のシステム間連携においては、投下できるコストがデータベース統合に見合うものでないことと、連, ,,,,,携システムが稼働するまでの時間が短いことから、データベースの共通化は採用しないこととする, ,,,,・,リアルタイム連携については、本来であれば理想的な連携になることが多い。しかし、午後８時以降の, ,,,,,予約は仮予約であるため、今回の連携では採用できない, ,,,,・,今回の連携は割り当てバッチJOBにて処理する内容で、緩い連携で十分対応可能となるため、ファイル, ,,,,,転送は適切な手段と考えられ、今回のシステム間連携の方式として採用した, ,,,,,, ,■設問ウ,,,,, ,,,,,, ,,　設問ウには、問題文の次の部分が対応する。,,,, ,,,,,, ,,,設問ウ,,,設問イで述べたシステム間連携方式について、運用要件と実現方法を、重要と考えた点を中心に、6 ,,,,,,00字以上1200字以内で具体的に述べよ。 ,,,,,, ,,,　さらに、運用時間帯、運用体制などの運用要件を明らかにし、稼働状況のモニタリング、異常の検知、障害,,, ,,,発生時の対応などの実現方法を検討することも重要である。,,, ,,,,,, ,,　例として次のような見出しとストーリーが考えられる。,,,, ,,,,,, ,,,ウ　システム間連携方式における運用要件と実現方法,,, ,,,ウ―１　運用要件,,, ,,,,,, ,,,,・,運用時間帯は、毎日午前7時～午前８時であり、この1時間に割当てバッチJOB～手配メールの配信を, ,,,,,実行する, ,,,,・,運用体制は、割り当てバッチJOBの実行～手配メールの配信のすべてが時刻指定の自動起動となるた, ,,,,,め、平常時は現状の運用体制で対応できる, ,,,,・,ただし、JOBの異常終了など緊急時の場合には、従来のシステム運用責任者への連絡以外に、インス, ,,,,,トラクタへの指示を動的に行う施設の責任者への連絡が必要, ,,,,,, ,,,ウ―２　実現方法,,, ,,,,,, ,,,,・,稼働状況のモニタリングは、以前よりシステムの運用部門が行っている, ,,,,・,モニタリングツールが導入済みである, ,,,,・,JOBの異常終了は現時点においても検出対象となっており、システム運用責任者の携帯電話へメール, ,,,,,が配信される, ,,,,・,処理の負荷が急激に増加した場合も検出対象で、システム運用責任者の携帯電話へメールが配信さ, ,,,,,れる, ,,,,・,システムの使用率は４０％程度で推移しており、使用率が７５％になった場合、警告を発することになっ, ,,,,,ている, ,,,,・,今回のシステム間連携はファイル転送とバッチJOBの追加であり、他の事例を参考にすると、連携処理, ,,,,,を追加することで負荷が大幅に増加することは考えにくい, ,,,,・,ただし、具体的な負荷の増大は稼働後まで不明確な部分もあるため、2段階で負荷の増大を検出するこ, ,,,,,ととし、使用率が６０％になった場合にも警告を発するように設定を追加する, ,,,,・,JOBの異常終了や警告の発信があった場合には、施設の責任者についても携帯電話へメールが発信, ,,,,,されるように設定を追加する, ,,,,,, ■解答,,,,,, ,,,,,, ,設問ア,,,,, ,,,,,, ,,ア　対象システムの概要と連携が必要になった背景,,,, ,,ア―１　対象システムの概要,,,, ,,,,,, ,,,　私はシステムインテグレータP社に所属するシステムアーキテクトである。今回、私は、会員制スポーツクラブ,,, ,,,を運営するA社におけるシステム間連携の構築を請け負うこととなった。A社においてシステム間連携を実現し,,, ,,,たのは、会員システムと設備・要員システムの連携である。会員システムでは、顧客である会員の個人情報、,,, ,,,予約情報、予約履歴などを管理している。設備・要員システムでは、スポーツクラブの設備のスケジュール、保,,, ,,,守履歴、スポーツクラブに所属するインストラクタのスケジュールなどを管理している。システムの一部は会員,,, ,,,に開放され、インターネット経由でレッスンや施設の予約ができるようになっている。,,, ,,,,,, ,,ア―２　連携が必要になった背景,,,, ,,,,,, ,,,　これまで、レッスンや施設の予約は、利用を希望する日の前日の午後8時までに行うことになっていた。前日,,, ,,,の午後8時に締め切った予約を基に、インストラクタや施設の割当バッチJOBを実行し、翌日分のインストラク,,, ,,,タの手配がされ、併せて施設のスケジュール表が作成される。A社の会員は、職場から帰宅した後に予約をす,,, ,,,る場合も多く、午後8時の締め切り時刻では早すぎるという声が上がっていた。新しく会員になることを希望す,,, ,,,る顧客は、本人確認のため店舗に出向く必要があり、午後6時が当日分の会員登録の締め切り時刻であった,,, ,,,。一般の会社員からは、平日の午後6時までにはいけないという声も多く上がっていた。スポーツクラブ業界は,,, ,,,競争が激しく、顧客サービスの拡大が幹部から指示されており、その一環として予約受け付けの延長を実現,,, ,,,することとなった。顧客サービスの強化はスピード重視で、1カ月程度の短時間でのサービス稼働が必要であ,,, ,,,る。,,, ,,,,,, ,■設問イ,,,,, ,,,,,, ,,イ　業務要件、システム要件、及び選択したシステム間連携方式と選択の理由,,,, ,,イ―１　業務要件,,,, ,,,,,, ,,,　翌日分の予約申し込みと会員登録の締め切り時刻の延長を短期間に実現するため、システム間連携により,,, ,,,対応することとなった。ただし、締め切り後の予約については、インストラクタの手配が付かないような場合も,,, ,,,考えられるため、受け付けは仮予約とする。スポーツクラブは毎日午前10時が開店時刻であり、インストラクタ,,, ,,,が店舗に到着するまでに最大1時間30分を要する。仮予約によって追加で必要になったインストラクタを手配,,, ,,,するためには、余裕を見て開店2時間前の午前8時には手配メールを配信する必要がある。追加手配処理開,,, ,,,始後に行われた当日分の利用申し込みについては、今回のシステム間連携の対象外とし、空きがあった場合,,, ,,,にのみ店舗にて受け付ける運用とすることになっている。,,, ,,,,,, ,,イ―２　システム要件,,,, ,,,,,, ,,,　システム間連携における最も重要な点は午前8時までに手配メールを配信することである。,,, ,,,,,, ,,,（１）データ量と処理時間について,,, ,,,,,, ,,,,　午後8時以降の予約情報は仮予約であり、会員システムにのみ蓄えられる。締め切り時刻を過ぎ、電話,, ,,,,や来店してレッスンや施設を予約する件数は、過去5年分を調査すると平均70件程度である。ピークは金,, ,,,,曜日で約２００件となっている。午後8時に実行する割当てバッチJOBの処理時間についても過去5年分を,, ,,,,調査すると、処理件数は最大約400件で、20分程度要している。午後8時から翌日開店までの予約件数が,, ,,,,最大約200件であるため、当日の朝に追加実行するレッスンや施設の割当JOBには10分程度と想定できる,, ,,,,。割当JOBに必要となる基データは、会員システムにのみ蓄えているため、施設・要員システムのデータと,, ,,,,組み合わせて、割当JOBを実行することになる。会員システムと施設・要員システムは高速LANで接続され,, ,,,,ており、毎日のバックアップ処理でのデータ量とデータ転送時間を鑑みると、会員システムから施設・要員,, ,,,,システムに一括でデータを転送する場合でも、5分以下と考えられる。午前8時の手配メール配信に間に合,, ,,,,わせるために、連携処理を開始する時刻は余裕を持たせて午前7時とする。,, ,,,,,, ,,,（２）データの整合性について,,, ,,,,,, ,,,,　連携処理では、会員システムに蓄えられた予約情報のデータを施設・要員システムのデータベースに挿,, ,,,,入（追加）するため、データベースの整合性制約によりデータの不整合が生じることはない。挿入できなか,, ,,,,ったデータはエラーリストに出力し、運用で対応する要件である。午前10時の開店時でエラーリストを店舗,, ,,,,にて参照できるようにする。,, ,,,,,, ,,イ―３　選択したシステム間連携方式と選択の理由,,,, ,,,,,, ,,,　候補としたシステム間連携方式は、データベースの共通化、リアルタイム連携、ファイル転送である。データ,,, ,,,ベースの共通化については、会員システムと施設・要員システムのデータベースを統合する必要がある。,,, ,,,データベースの統合は、既存システムを構成するプログラムの修正が必要になるなど影響が大きい。今回の,,, ,,,システム間連携においては、データベース統合に必要なコストが得られないことと、短期間に連携システムを,,, ,,,稼働させる必要があることからデータベースの共通化は採用しないこととした。リアルタイム連携は、理想的な,,, ,,,連携となるが、今回の連携では採用できない。今回の連携は割り当てバッチJOBにて処理する内容で、緩い,,, ,,,連携で十分対応可能となるため、ファイル転送は適切な手段と考えられる。今回のシステム間連携の方式は,,, ,,,ファイル転送を採用した。,,, ,,,,,, ,■設問ウ,,,,, ,,,,,, ,,ウ　システム間連携方式における運用要件と実現方法,,,, ,,ウ―１　運用要件,,,, ,,,,,, ,,,　今回のシステム連携の運用時間帯は、毎日午前7時～午前8時であり、この1時間に割当バッチJOBから手,,, ,,,配メールまでを実行することになる。運用体制としては、割当バッチJOBの実行から手配メールの配信までの,,, ,,,すべての処理が、時刻を指定することによる自動起動によって実行できるため、平常時は現状の運用体制で,,, ,,,対応できると考えられる。現状の運用体制においては、JOBの異常終了など緊急時の場合に、システム運用,,, ,,,責任者へ連絡が取られることになっている。今回の割当バッチJOBについて異常終了など緊急事態が発生,,, ,,,した場合には、インストラクタへの指示を動的に行う施設の責任者への連絡が必要である。,,, ,,,,,, ,,ウ―２　実現方法,,,, ,,,,,, ,,,　稼働状況のモニタリングは、以前よりシステムの運用部門が行っている。モニタリングについては、モニタリ,,, ,,,ングツールが導入済みである。このモニタリングツールではJOBの異常終了も検知できるようになっており、異,,, ,,,常終了を検知した場合は、システム運用責任者の携帯電話へメールが配信される設定がされている。この設,,, ,,,定を応用して割当バッチJOBの異常時に施設の責任者に対しても携帯電話へメールが配信されるように設定,,, ,,,した。同時に、処理の負荷が急激に増加した場合も検出対象となっており、システム運用責任者の携帯電話,,, ,,,へメールが配信される。システムの使用率は４０％程度で推移しており、現時点では使用率が７５％になった,,, ,,,場合、警告を発することになっている。今回のシステム間連携は、従来のシステムにファイル転送と割当バッ,,, ,,,チJOBを追加することであり、他の同等規模の事例を参考にすると、連携処理を追加することで負荷が大幅,,, ,,,に増加することはないと判断できる。ただし、具体的な負荷の増大は稼働後まで不明確な部分もあるため、,,, ,,,2段階で負荷の増大を検出することとし、使用率が６０％になった場合にも警告を発するように設定を追加する,,, ,,,こととした。割当バッチJOBの異常終了の検知と同様に、警告の発信があった場合には、施設の責任者に,,, ,,,ついても携帯電話へメールが発信されるように設定を追加した。　以上,,, ,,,,,, 平成２２年度　問２　システム間連携方式,,,,,, ,,,,,, ,　生産システム、物流システム、販売システムなどの企業内システムは、部門ごとに独立したシステムとなっている,,,,, ,場合がある。このため、販売システムで発生する顧客データを物流システムに渡して最新の顧客情報で出荷伝票を,,,,, ,出力する、販売システムで発生する販売データを生産システムの在庫情報に反映して迅速に生産計画を決定する,,,,, ,など、企業内の情報共有をシステム間連携によって実現することがある。システム間連携方式には、ファイル転送、,,,,, ,データベース共有、リアルタイム連携などがある。,,,,, ,　システムアーキテクトは、システム間連携方式を選択する際に、例えば、次のような業務要件に留意しなければな,,,,, ,らない。,,,,, ,,・,当日登録した顧客情報に基づいて、当日配送を可能とする必要がある。,,, ,,・,生産数の確定前に、拠点ごとの在庫数を確定する必要がある。,,, ,　これらの業務要件を踏まえ、データの収集と反映のタイミング、処理すべきデータ量などのシステム要件を明確に,,,,, ,する。その要件に基づき、データ伝送時間、システム間の整合性の維持などを考慮して、適切なシステム間連携方,,,,, ,式を選択する。,,,,, ,　さらに、運用時間帯、運用体制などの運用要件を明らかにし、稼働状況のモニタリング、異常の検知、障害発生時,,,,, ,の対応などの実現方法を検討することも重要である。,,,,, ,,,,,, ,設問ア,,,あなたが携わったシステム間連携方式の検討において、対象システムの概要と連携が必要になった背景,, ,,,,について、800字以内で述べよ。,, ,設問イ,,,設問アで述べたシステムを連携させる際に、あなたは、どのような業務要件を踏まえ、どのようなシステム,, ,,,,要件を明確にしたか。また、その要件に基づいてどのようなシステム間連携方式を選択したか、選択した理,, ,,,,由とともに、800字以上1600字以内で具体的に述べよ。,, ,設問ウ,,,設問イで述べたシステム間連携方式について、運用要件と実現方法を、重要と考えた点を中心に、600字,, ,,,,以上1200字以内で具体的に述べよ。,, ,,,,,, ■解答例,,,,,, ,,,,,, ,（設問ア）,,,,, ,,,,,, ,１．論述の対象とするシステムの概要,,,,, ,,,,,, ,,　K社は、北日本の地方都市を中心に約150店舗を運営するスーパマーケットである。日本全体の人口減少やコ,,,, ,,ンビニエンスストアの拡大によって、K社の売上高は微減し続けていた。その当時、大手のスーパマーケットは、,,,, ,,インターネットで注文を受け付けて、店舗から顧客が指定する場所に注文商品を配達するネットスーパ事業を開,,,, ,,始していた。K社の経営者層は、経営計画策定時に、ネットスーパ事業への参入とそれに対応するシステム（以,,,, ,,下、Nシステムという）の開発を決定した。当システム開発の目的は、①3年後の売上高が前年度比で8％増加す,,,, ,,る、②割引サービスやポイントを得る会員数が3年間で50万人増加する、の2点だった。私は、K社の情報システ,,,, ,,ム部に所属するシステムアーキテクトであり、当システム開発プロジェクトの設計チームリーダに任命された。,,,, ,,,,,, ,２．システム間連携が必要となった背景,,,,, ,,,,,, ,,　K社は、スーパマーケットを効率よく運営するために販売管理システム（以下、既存システムという）を運用してい,,,, ,,る。この既存システムは、本社サーバ、店舗サーバ、POS端末をクライアントサーバ型に配置する構成を採用して,,,, ,,いる。K社の経営者層は、Nシステムの開発費用を抑制するために、既存システムにある機能を極力活用して、N,,,, ,,システムを開発する制約条件を当プロジェクトに課していた。そこで、当プロジェクトのプロジェクトマネージャは①,,,, ,,ネットスーパに関する売上実績は、POS端末を通じて既存システムに計上する。②ネットスーパに関する売上実,,,, ,,績統計分析機能は、既存システムによって実現させる、開発方針を決定した。したがって、Nシステムのうち少なく,,,, ,,とも商品引渡業務機能は既存システムと連携しなければならなかった。,,,, ,,,,,, ,（設問イ）,,,,, ,,,,,, ,１．私が明確にした業務要件とシステム要件,,,,, ,,,,,, ,,　私は、システム間連携方式を選択するためには、それに先立って必要な業務要件とシステム要件を明確にしな,,,, ,,ければならないと考えた。,,,, ,,,,,, ,１．１　欠品防止のための追加発注,,,,, ,,,,,, ,,　要件定義のヒアリングにおいて、店舗担当者は「店舗では顧客から”遠くから刺身を買いに来たのに１つもない”,,,, ,,といった苦情を良く受ける。ネットスーパで受け付けた注文は、極力欠品が無いようにしたい。そこで賞味期限が,,,, ,,短く、欠品になりやすい弁当や寿司のような商品の注文を受け付けたら、その分を仕入先に追加発注してほしい,,,, ,,」と述べた。そこで、私はこの意見を必要な業務要件とし、Nシステムの商品マスタに即時発注区分を設定する。,,,, ,,即時発注区分に該当する商品に関する注文受付情報は、既存システムに店舗着荷日とともに転送し、発注情報,,,, ,,を作成させるシステム要件を設定した。,,,, ,,,,,, ,１．２　クレジットカード決済機能,,,,, ,,,,,, ,,　Nシステムの業務要件に、ネットスーパ利用時のクレジットカードによる決済があった。既存システムのPOS端末,,,, ,,にはクレジットカード決済機能がある。POS端末は、入力されたクレジットカード決済情報を引数にして、本社サー,,,, ,,バのAPI（Application Programming Interface）を呼び出して決済している。私はこの機能を活用した会員がクレジ,,,, ,,ットカードを使った決済入力をした場合、本社サーバのAPIを呼び出すシステム要件を設定した。,,,, ,,,,,, ,１．３　商品引渡業務機能と売上実績計上,,,,, ,,,,,, ,,　要件定義のヒアリングにおいて、店舗担当者は「店舗で勤務するレジ担当者はほとんどパート社員であり、高齢,,,, ,,者もいる。しかし、POS端末の操作には慣れているので、ネットスーパで受け付けた商品を宅配業者に引き渡す,,,, ,,場合であっても、POS端末からレシートを発行させ、それを商品に貼付させたい」と述べた。そこで、私はこの意見,,,, ,,を必要な業務要件とし、本社サーバに登録された注文受付情報を店舗サーバに転送する。店舗担当者は、POS,,,, ,,端末を操作して店舗サーバにある注文受付情報を取得し、ピッキングリストを印刷する。ある会員が注文したす,,,, ,,べての商品の荷揃えが完了したら、その注文受付情報を売上実績情報に変換するシステム要件を設定した。,,,, ,,,,,, ,２．私が選択したシステム間連携方式とその理由,,,,, ,,,,,, ,,　システム間連携方式には、ファイル転送、データベース共有、リアルタイム連携などがある。私は、上記のシス,,,, ,,テム要件にしたがって、システム間連携方式を選択した。,,,, ,,,,,, ,２．１　欠品防止のための追加発注,,,,, ,,,,,, ,,　弁当や寿司のような即時発注区分が設定されている商品の発注期限の設定条件は、仕入先によって異なり複,,,, ,,雑であることだった。そこで私は、これを理由にして、即時発注区分が設定されている注文受付情報が、即時に,,,, ,,既存システムとのインタフェースファイルに転送されるリアルタイム連携方式を採用した。,,,, ,,,,,, ,２．２　クレジットカード決済機能,,,,, ,,,,,, ,,　私は、会員が操作するWebブラウザがCGI（Common Gateway Interface）経由で、本社サーバのAPIを呼び出す,,,, ,,システム間連携方式を採用した。その理由は、既存システムと同一の方法によって、クレジットカード決済機能を,,,, ,,利用すれば、信頼性が高く、システム間の整合性が維持しやすいと考えたからだった。,,,, ,,,,,, ,２．３　商品引渡業務機能と売上実績計上,,,,, ,,,,,, ,,　私は、本社サーバの注文受付情報を店舗サーバに転送するまでの処理はNシステム側で担当し、店舗―サー,,,, ,,バの注文受付情報は、既存システムによって読み出されるデータベース共有方式を採用した。その理由は、注,,,, ,,文受付情報のデータ伝送時間をゼロにできるからだった。,,,, ,,,,,, ,（設問ウ）,,,,, ,,,,,, ,１．システム間連携方式の運用要件と実現方法,,,,, ,,,,,, ,,　私は、設問イで述べたシステム間連携方式の運用要件と実現方法を以下のように規定した。,,,, ,,,,,, ,１．１　欠品防止のための追加発注,,,,, ,,,,,, ,,　Nシステムの注文受付機能は、特定のシステム保守日を除いて、365日24時間稼働する。したがって、私は注文,,,, ,,受付情報が、新規登録・変更・削除される都度、即時に既存システムとのインタフェースファイルに転送させる機,,,, ,,能の運用時間帯を、Nシステムの注文受付機能のそれと同一にした。その運用体制は、K社の情報システム部の,,,, ,,ITサービスマネージャが決定する。既存システムとのインタフェースファイルが開かない・書き込めない・容量が規,,,, ,,定値を超えた等の異常検知や稼働状況のモニタリングは、K社情報システムが導入している運用監視システム,,,, ,,によって実現され、障害発生時の対応はK社情報システムの運用管理規定に従って実行される。,,,, ,,,,,, ,１．２　クレジットカード決済機能,,,,, ,,,,,, ,,　当機能は、本社サーバのAPIの呼び出しによって実現される。したがって、私はその運用時間帯・運用体制と実,,,, ,,現方法を既存システムの保守責任者・運用責任者の決定に従うものとした。,,,, ,,,,,, ,１．３　商品引渡業務機能と売上実績計上,,,,, ,,,,,, ,,　本社サーバに登録された注文受付情報が店舗サーバに転送される機能は、DBMSのレプリケーション機能によ,,,, ,,って実行される。したがって私はこの機能の運用時間帯・運用体制と実現方法をK社システム部の運用責任者の,,,, ,,決定に従うものとした。店舗サーバに転送された注文受付情報のすべての商品の引き渡しに関する運用要件と,,,, ,,実現方法は、各店舗の店長によって決定される。また、私は店舗サーバに登録されたすべての注文受付情報が,,,, ,,売上実績情報の変換されている稼働状況のモニタリング、変換されていない・重複して変換されているなど異常,,,, ,,検知を既存システムの保守責任者・運用責任者の決定に従うものとした。,,,, ,,,,,, 平成２３年度　問１　複数のシステムにまたがったシステム構造の見直し,,,,,, ,,,,,, ,　近年、情報システムへの要求は、事業統合に伴う業務システムの統合や、事業を横断した顧客情報の把握など、,,,,, ,複数のシステムに関連するものが増える傾向にある。それらの要求に対応する時、機能やデータの配置などのシス,,,,, ,テム構造を全体最適の観点から対象となる全システムにまたがって見直し、機能追加の容易性の確保や変更時の,,,,, ,影響範囲を狭めることも重要である。,,,,, ,　このような複数のシステムにまたがったシステム構造の見直しにおいて、システムアーキテクトは、例えば、次のよ,,,,, ,うな視点から業務とシステムを分析する。,,,,, ,,,,,, ,,・,新たな商品やサービスに対応する際の変更箇所や変更方法の傾向,,, ,,・,システムによる機能の配置の違い,,, ,,・,データの配置や流れ,,, ,,,,,, ,　分析の結果に基づき、複数の類似した機能及びデータを共通化するために、コンポーネントの分割・統合をしたり、,,,,, ,マスタファイルを各システムから分離・統合したりすることなどを検討し、システム構造を見直す。多くの場合、考えら,,,,, ,れるシステム構造は複数あり、それぞれにメリットやデメリットがあるので、そのメリットを活かすとともにデメリットの,,,,, ,軽減方法を検討したうえで、新しいシステム構造を選定する。,,,,, ,　例えば、システム間の接続が複雑化してしまう場合には、複雑化を解消するために、連携基盤を採用して各シス,,,,, ,テムをハブ型に接続する。統合しようとするマスタファイルのコード体系が異なる場合には、互いのデータを関連付,,,,, ,けるために、新たなコード体系を定義して新旧のコードの相互変換を可能にする。,,,,, ,,,,,, ,設問ア,,,あなたが携わった複数のシステムにまたがったシステム構造の見直しについて、見直しの背景と概要、対,, ,,,,象になった複数のシステムの概要を８００字以内で述べよ。,, ,設問イ,,,設問アで述べたシステム構造の見直しにおいて、業務とシステムをどのような視点から分析し、どのような,, ,,,,新しいシステム構造を選定したか。メリットなどの選定理由とともに、800字以上1600字以内で具体的に述,, ,,,,べよ。,, ,設問ウ,,,設問イで述べた新しいシステム構造には、どのようなデメリットがあり、どのような軽減方法を検討したか。6,, ,,,,00字以上1200字以内で具体的に述べよ。,, ,,,,,, ■ポイント,,,,,, ,,,,,, ,■出題趣旨,,,,, ,,,,,, ,,　近年の情報システムへの要求は、単一のシステムではなく複数のシステムに関連するものが増えている。その,,,, ,,際、複数のシステムにまたがってシステム構造を見直す場合がある。このような場合、システムアーキテクトは、,,,, ,,業務とシステムの現状を分析したうえで、機能追加の容易性や変更時の影響範囲などを考慮して、全体最適の,,,, ,,観点からシステム構造の見直しをしなければならない。,,,, ,,　本問は、業務とシステムの現状をどのような視点から分析し、どのようなシステム構造を選定したか、メリットな,,,, ,,どの選定理由、デメリットとその軽減策を具体的に記述することを求めている。論述を通じて、業務分析力及び全,,,, ,,体最適の観点からシステム構造を設計する能力を評価する。,,,, ,,,,,, ,■採点講評,,,,, ,,,,,, ,,　全問に共通して、具体性があり、経験に基づいていることをうかがわせる論述が多かった。一方で、答案用紙の,,,, ,,冒頭で記入を求めている”論述の対象とする計画又はシステムの概要”、”論述の対象とする製品又はシステム,,,, ,,の概要”が未記入又は記入漏れの項目があるなど適切に記述されていないので、評価を下げた論述が相当数あ,,,, ,,った。問題文の引用で文字数を費やし内容が薄い論述や、問題文に例示した項目と一般論の組み合わせからな,,,, ,,る具体性に欠ける論述、設問で問うている内容に対応しない論述も散見された。このような論述では、受験者の,,,, ,,能力や経験を正しく評価できない場合があるので、実際の経験に基づき設問に沿って具体的に論述してほしい。,,,, ,,　また、論述は第三者に読ませるものであることを意識してほしい。例えば、業界特有の用語や略語には説明を,,,, ,,付ける、段落を分けたり見出しを入れたりすることで何について述べているのかを明確にするなど、自分の考えを,,,, ,,第三者に的確に伝えるための工夫をしてほしい。,,,, ,,　問１（複数のシステムにまたがったシステム構造の見直しについて）では、具体性のある論述が多く、実際の経,,,, ,,験から論述していることがうかがわれた。システムアーキテクトは、業務を理解してシステムの構造を設計する役,,,, ,,割をもつので、業務とシステムの両面からの論述を期待したが、そのような論述は少なかった。設問では、業務と,,,, ,,システムをどのような視点から分析し、どのようなシステム構造を選択したかについての論述を求めたが、業務,,,, ,,の視点からの分析を論述していないものや、システム構造ではなく連携方式だけを論述しているものが多く見ら,,,, ,,れた。また、選択したシステム構造のデメリットとその軽減方法の論述を求めたが、システム構造のデメリットでは,,,, ,,なくシステム統合などの背景そのもののデメリットを論述しているものが散見された。,,,, ,,,,,, ,　事業統合に伴う業務システムの統合、事業を横断した顧客動向の把握などに対応するため、複数のシステムに,,,,, ,またがってシステム構造を見直すことがテーマの問題である。情報システムに対する利用部門からの新しいニーズ,,,,, ,に対応する場合、機能追加の容易性の確保、変更範囲の局所化などが容易に行えるようにするため、システムの,,,,, ,構造を見直すことがある。,,,,, ,　システム構造の見直しに際し、システムアーキテクトは、業務とシステムの両面から分析を行う必要がある。例え,,,,, ,ば、業務面から、新商品や新サービスに対応するときの変更箇所、変更方法の検討などを分析したり、システム面,,,,, ,からデータの配置や流れなどを分析したりする必要がある。,,,,, ,　分析結果を基にシステム構造を検討する場合には、業務機能を提供するコンポーネントを分割統合したり、共通の,,,,, ,マスタデータベースを構築したりするなど方針を明確にする必要がある。方針に従ったシステム構造の変更に際して,,,,, ,は、メリット、デメリットが生じる。メリットを活かすと同時にデメリットが極力少なくなるような方策を検討しなければな,,,,, ,らない。,,,,, ,,,,,, ,　設問アでは、複数のシステムにまたがったシステム構造の見直しについて、「見直しの背景と概要」、「対象になっ,,,,, ,た複数のシステムの概要」を記述する。システム構造の見直しについては制約がないため、どのような業務やシステ,,,,, ,ムであっても題材にできる。「事業統合に伴うシステムの統合」、「事業を横断した顧客動向の把握」などが例として,,,,, ,問題文に提示されており、システム構造の見直しを行うことになった契機は相応のインパクトであることが想定され,,,,, ,ていると考えられる。システム構造の見直しが必要になった背景については、「なぜ見直しが必要になったのか」とい,,,,, ,う観点で記述し、必要性をアピールしたい。見直しの背景と概要を明確に分割して記述しにくい場合は、併せて記述,,,,, ,してもよい。ただし、見直しの背景と概要の両方が要求事項であるため、概要の記述に終始しないように注意しなけ,,,,, ,ればならない。,,,,, ,　システムの概要については、最低でも二つのシステムの概要を記述しなければならないため、設問アの解答用紙（,,,,, ,800字以内）に収まるように注意したい。詳細なシステム構造については設問イで触れることとし、設問アではシステ,,,,, ,ムの目的や機能などの概要を記述する程度でよいと考えられる。,,,,, ,,,,,, ,　設問イでは、「システム構造の見直しにおける業務とシステムの分析の視点」、「選定した新しいシステム構造」を,,,,, ,記述する。,,,,, ,　業務面の分析では、システム構造の見直しにつながるような視点が必要である。例えば、単なる業務効率の向上,,,,, ,や、業務の流れの簡略化という視点のみでは、システム構造の見直しに関連した分析とはいえない。業務面単独で,,,,, ,はシステムの変更について直接分析しにくい場合は、問題文に「新たな商品やサービスに対応する際の変更箇所や,,,,, ,変更方法の傾向」と示されている例のように、業務面とシステム面を併せて分析してもよい。システム構造の選定理,,,,, ,由としてメリット、デメリットを記述するため、複数の側面から分析しておきたい。,,,,, ,　システム面の分析では、システム機能の配置、データの配置、データの流れなど純粋なシステムの特性について,,,,, ,分析する。業務システムの統合などの課題に際して、現状のシステム構造における問題点と、問題点を解消するた,,,,, ,めの新しいシステム構造をどのように実現するかを検討する。問題文には分析の視点として三つの項目が列挙され,,,,, ,ているが、すべての視点について検討しなくてもよい。,,,,, ,　新しいシステム構造については、具体的にどのような構造を採用することになったのかを記述する。記述時間と原,,,,, ,稿用紙の字数制限を考えると、詳細なシステム構造の記述が求められているとは考えにくい。ただし、メリットを生か,,,,, ,して「システム構造を選定する」必要があるため、システム構造については複数の案を提示しなければならない。メリ,,,,, ,ットそのものは、分析段階で明確になった課題や問題が解消されるという主旨で記述すればよいが、どのようなメリ,,,,, ,ットを生かしたシステム構造なのかが分かるように記述する。システム構造の選定については、メリットの選定理由,,,,, ,の記述を忘れないようにしなければならない。,,,,, ,,,,,, ,　設問ウでは、「新しいシステム構造を採用することによって生じるデメリット」について記述する。デメリットは記述し,,,,, ,にくい事柄ではあるが、設問の要求事項なので必ず記述しなければならない。システム構造の変更（利用部門にと,,,,, ,っては業務システムが変更）の結果、業務の処理手順が変更になったり、作業が追加になったりするなど不都合が,,,,, ,生じることがある。このような場合は、全体最適化の視点から利用部門に不都合をあえて受け入れてもらえるよう、,,,,, ,幹部から説明してもらったり、新しいシステムの勉強会を開催したりという手段をとることが多い。しかし、設問ウでは,,,,, ,、システム構造の工夫によってデメリットを軽減することが要求されているため、説明会、勉強会などの管理的側面,,,,, ,による解決策では題意にそぐわない。デメリットは軽減すればよいため、新しいシステム構造において完全に解消す,,,,, ,ることを考える必要はない。,,,,, ,,,,,, ■見出しとストーリー,,,,,, ,,,,,, ,■設問ア,,,,, ,,,,,, ,,　設問アには、問題文の次の部分が対応する。,,,, ,,,,,, ,,,設問ア,,,あなたが携わった複数のシステムにまたがったシステム構造の見直しについて、見直しの背景と概 ,,,,,,要、対象となった複数のシステムの概要を800字以内で述べよ。 ,,,,,, ,,,　近年、情報システムへの要求は、事業統合に伴う業務システムの統合や、事業を横断した顧客動向の把握,,, ,,,など、複数のシステムに関連するものが増える傾向にある。それらの要求に対応するとき、機能やデータの配,,, ,,,置などのシステム構造を全体最適の観点から対象となる全システムにまたがった見直し、機能追加の容易性,,, ,,,の確保や変更時の影響範囲を狭めることも重要である。,,, ,,,,,, ,,　例として次のような見出しとストーリーが考えられる。,,,, ,,,,,, ,,,ア　対象になった複数のシステムの概要及び見直しが必要になった背景と概要,,, ,,,ア―１　対象になった複数のシステムの概要,,, ,,,,,, ,,,,・,顧客は家電量販店をチェーン展開するA社, ,,,,・,業容拡大のため、日用雑貨の通信販売専門会社B社との合併, ,,,,・,A社が取り扱っている商品の中の消耗品を、合併したB社の通信販売網に乗せる, ,,,,・,システム構造を見直したのは、両社の販売管理システム、在庫管理システム、顧客管理システム, ,,,,・,A社のシステムはクライアントサーバシステムで構築されている。B社のシステムはWebシステムで構築, ,,,,,されている, ,,,,・,ネットワークの範囲は、A社では本社と店舗が専用線で接続、B社では本社と倉庫間が専用線、本社と, ,,,,,顧客間はインターネットで接続, ,,,,・,自身の立場は、本案件のシステム構造の見直しを行ったシステムインテグレータP社に所属するシステ, ,,,,,ムアーキテクト, ,,,,,, ,,,ア―２　見直しが必要になった背景と概要,,, ,,,,,, ,,,,・,A社では基本的に店頭販売方式で、顧客は居住地に近い店舗へほぼ固定的に足を運んでいる, ,,,,・,A社の各店舗の規模、品揃えは同等であるため、複数の店舗や遠隔地の店舗で商品を購入する顧客, ,,,,,はいない, ,,,,・,家電に関連する消耗品は店舗まで足を運ぶことなく電話などで注文し、登録の住所へ配送するというサ, ,,,,,ービスがあった。しかし、店舗の営業時間外にも消耗品を購入したいという声が多かった, ,,,,・,競合の家電量販店がA社の地盤に進出し、経営環境が悪化してきた, ,,,,・,顧客サービスの拡大のため通信販売を検討し、B社と合併することになった, ,,,,・,B社の販売管理システムを採用することも検討したが、大型の白物家電は工事や据え付けが必要で、, ,,,,,通信販売の販売管理システムでは対応できない, ,,,,・,A社、B社のすべてのシステムを統一できず、既存システムを併用する必要があった。データの相互利, ,,,,,用など、単に両社のシステムを併用することでは対応できない部分もあり、全体最適化、情報システム, ,,,,,運営経費の削減を目指し、システム構造を見直すことになった, ,,,,,, ,■設問イ,,,,, ,,,,,, ,,　設問イには、問題文の次の部分が対応する。,,,, ,,,,,, ,,,設問イ,,,設問アで述べたシステム構造の見直しにおいて、業務とシステムをどのような視点から分析し、どの ,,,,,,ような新しいシステム構造を選定したか。メリットなどの選定理由とともに、800字以上1600字以内で ,,,,,,具体的に述べよ。 ,,,,,, ,,,　近年、情報システムへの要求は、事業統合に伴う業務システムの統合や、事業を横断した顧客動向の把握,,, ,,,など、複数のシステムに関連するものが増える傾向にある。それらの要求に対応するとき、機能やデータの配,,, ,,,置などのシステム構造を全体最適の観点から対象となる全システムにまたがって見直し、機能追加の容易性,,, ,,,の確保や変更時の影響範囲を狭めることも重要である。,,, ,,,　このような複数のシステムにまたがったシステム構造の見直しにおいて、システムアーキテクトは、例えば、,,, ,,,次のような視点から業務とシステムを分析する。,,, ,,,,,, ,,,,・,新たな商品やサービスに対応する際の変更箇所や変更方法の傾向, ,,,,・,システムによる機能の配置の違い, ,,,,・,データの配置や流れ, ,,,,,, ,,,　分析の結果に基づき、複数の類似した機能及びデータを共通化するために、コンポーネントの分割・統合を,,, ,,,実施したり、マスタファイルを各システムから分離・統合したりすることなどを検討し、システム構造を見直す。,,, ,,,多くの場合、考えられるシステム構造は複数あり、それぞれにメリットやデメリットがあるので、そのメリットを生,,, ,,,かすとともにデメリットの軽減方法を検討したうえで、新しいシステム構造を選定する。,,, ,,,,,, ,,　例として次のような見出しとストーリーが考えられる。,,,, ,,,,,, ,,,イ　業務とシステムを分析した視点、システム構造の見直し、及びメリットの選定理由,,, ,,,イ―１　業務とシステムを分析した視点,,, ,,,,,, ,,,,・,基本的に両者のシステムは統合する方向で検討するが、業務内容によって併用することも可能とする, ,,,,・,分析対象は、システムの機能とデータ配置, ,,,,・,A社が通信販売を新たに開始することにおけるシステムの変更箇所についての視点, ,,,,,・,A社が取り扱っている消耗品の販売をB社の通信販売網へ乗せ、顧客の購入手段を拡大する ,,,,,・,A社の消耗品以外の商品について販売方法は変更しない ,,,,,・,A社の取り扱う大型白物家電とB社が取り扱う日用雑貨とは、商品の管理方法が異なる ,,,,,・,A社のシステムでは店舗と物流倉庫が関連付けられており、物流倉庫間で在庫をやり取りすることは ,,,,,,例外処理である ,,,,,・,B社の物流倉庫は全国3か所に集約されており、どの倉庫からも任意の顧客への商品を発送できる ,,,,,・,時間的、物理的制約から、当面物流倉庫は両社既存のままとし、取扱商品も変更しない ,,,,,・,顧客については、両社でほぼ同じ管理を行っている ,,,,・,データ配置についての視点, ,,,,,・,販売管理システムに関するデータについて、A社は店舗ごとにマスタが配置されており、夜間バッチ ,,,,,,処理で本社にトランザクションデータが集約される ,,,,,・,B社の販売管理システムのデータは本社管理となっている ,,,,,・,顧客管理システム、在庫管理システムともデータは各社の本社に一元管理されている ,,,,,, ,,,イ―２　システム構造の見直し,,, ,,,,,, ,,,,・,基本的な方針として、①A社もしくはB社のシステムに片寄せする、②統合したシステムを新たに構築す, ,,,,,る、③両社のシステムを併用する、のいずれかの方式が考えられる, ,,,,・,システムの機能面, ,,,,,・,統合した新システムの構築が最適と考えられるが、会社合併までの準備期間が短いため、新たなシ ,,,,,,ステム構築は物理的に難しい ,,,,,・,販売管理システムについては、共通機能が多い点、通信販売をA社が新規に開始する点を考え、B ,,,,,,社のシステムを基本的に使用する。大型白物家電など特定の商品については、A社のシステムを当 ,,,,,,面使用する ,,,,,・,商品の取り扱い、物流倉庫の運用などについて変更がないため、在庫管理システムについては、両 ,,,,,,者のシステムを継続して使用する ,,,,・,データの配置, ,,,,,・,基本的な方針として、データは一元管理する。ただし、システムの機能に関連して両者のシステムを ,,,,,,併用する場合に、従来通りデータをもたせる必要性を考慮する ,,,,,・,店舗ごとに管理されていたA社の販売管理システムのデータについても統合する ,,,,,・,新しいシステムは、B社のシステムが主体となるため、基本的にはB社のデータベースを使用する ,,,,,・,A社のシステムからB社のデータベースへアクセスするために使用できる汎用部品を作成する ,,,,,, ,,,イ―３　メリットの選定理由,,, ,,,,,, ,,,,・,販売管理システムについて、大型白物家電の販売方法は、会社合併後も当面変更する予定はなく、シ, ,,,,,ステムの修正・変更などについてはB社のシステムに限定できるメリットがある, ,,,,・,顧客管理システムについて、B社のシステムに片寄せするため、保守に対する考え方や方法についてB, ,,,,,社のポリシをそのまま継続して適用できるメリットが考えられる, ,,,,・,在庫管理システムについては、従来システムを併用するものの、データについては共通部分が多いた, ,,,,,め、テーブルを共通化する。A社の物流倉庫単位で管理していたデータについても、共通化できるもの, ,,,,,は共通化する。共通化を推進することで管理工数の削減が期待できる, ,,,,・,データベースの統合については、データベースサーバの運用コスト削減メリット、顧客データなどの合併, ,,,,,前に両者が持っていたデータの相互活用が期待できる, ,,,,,, ,■設問ウ,,,,, ,,,,,, ,,　設問ウには、問題文の次の部分が対応する。,,,, ,,,,,, ,,,設問ウ,,,設問イで述べた新しいシステム構造には、どのようなデメリットがあり、どのような軽減方法を検討し ,,,,,,たか。600字以上1200字以内で具体的に述べよ。 ,,,,,, ,,,　分析の結果に基づき、複数の類似した機能及びデータを共通化するために、コンポーネントの分割・統合を,,, ,,,実施したり、マスタファイルを各システムから分離・統合したりすることなどを検討し、システム構造を見直す。,,, ,,,多くの場合、考えられるシステム構造は複数あり、それぞれにメリットやデメリットがあるので、そのメリットを生,,, ,,,かすとともにデメリットの軽減方法を検討したうえで、新しいシステム構造を選定する。,,, ,,,　例えば、システム間の接続が複雑化してしまう場合には、複雑化を解消するために、連携基盤を採用して各,,, ,,,システムをハブ型に接続する。統合しようとするマスタファイルのコード体系が異なる場合には、互いのデータ,,, ,,,を関連付けるために、新たなコード体系を定義して新旧のコードの相互変換を可能にする。,,, ,,,,,, ,,　例として次のような見出しとストーリーが考えられる。,,,, ,,,,,, ,,,ウ　新しいシステム構造におけるデメリットとデメリットの軽減方法,,, ,,,,,, ,,,,・,販売管理システムについて、A社又はB社のシステムに統合できず、両者のシステムを併用するシステ, ,,,,,ム構造になった点, ,,,,,・,販売管理システムはユーザインタフェースをWebアプリケーションとして構築し、従来のシステムの機 ,,,,,,能を呼び出す方式として、ユーザには統一感を与え、新たに開発する部分を最小限に抑える ,,,,・,データを一元管理することになったため、両者のシステムで使用していたコードなど一部のデータを従, ,,,,,来通り使用できなくなった点, ,,,,,・,マスタテーブルはB社のデータベースに統合する ,,,,,・,両者が使用しているマスタテーブルについて、A社のコードに対応する新たなB社のコードを付与し、 ,,,,,,テーブルを統合する ,,,,,・,A社のシステムを継続して使用する部分については、A社のコードをB社のコードに変換するテーブル ,,,,,,を用意し、A社のコードからB社のコードへ自動的に変換できる機能を実装する ,,,,,, ■解答,,,,,, ,,,,,, ,■設問ア,,,,, ,,,,,, ,,ア　対象になった複数のシステムの概要及び見直しが必要になった背景と概要,,,, ,,ア―１　対象になった複数のシステムの概要,,,, ,,,,,, ,,,　私はシステムインテグレータP社に所属するシステムアーキテクトである。今回、私は、家電量販店をチェー,,, ,,,ン展開するA社のシステム構造の見直しを行うこととなった。A社は、業容拡大のため、日用雑貨の通信販売,,, ,,,専門会社B社と合併した。合併に伴いA社が取り扱っている消耗品を合併したB社の通信販売網でも販売する,,, ,,,こととなった。業務の変更に対応してシステム構造を見直したのは、両者の販売管理システム、在庫管理シス,,, ,,,テム、顧客管理システムについてである。A社のシステムはクライアントサーバシステムで構築されている。B,,, ,,,社のシステムはWebシステムで構築されている。,,, ,,,,,, ,,ア―２　見直しが必要になった背景と概要,,,, ,,,,,, ,,,　A社では基本的に店頭販売方式で、顧客は居住地に近い店舗へほぼ固定的に足を運んでいる。A社の各店,,, ,,,舗の規模、品揃えは同等であり、複数の店舗や遠隔地の店舗で商品を購入する顧客はいない。家電に関連,,, ,,,する消耗品は電話などで注文し、登録の住所へ配送するサービスがあった。しかし、営業時間外にも消耗品,,, ,,,を購入したいという声が多くなっていた。競合の家電量販店がA社の地盤に進出し、経営環境が悪化してきて,,, ,,,おり、顧客サービスの拡大のため通信販売を検討したことが、B社と合併することになった経緯である。規模の,,, ,,,大きいB社の販売システムを採用することも検討したが、大型の白物家電は工事や据付けが必要で、通信販,,, ,,,売専門の販売管理システムでは対応できないことが判明した。また、データの相互利用など、単に両社のシス,,, ,,,テムを併用することでは対応できない部分もあり、全体最適化、情報システム運営経費の削減を目指し、シス,,, ,,,テム構造の見直しが決定された。,,, ,,,,,, ,■設問イ,,,,, ,,,,,, ,,イ　業務とシステムを分析した視点、システム構造の見直し、及びメリットの選定理由,,,, ,,イ―１　業務とシステムを分析した視点,,,, ,,,,,, ,,,　新しいシステムについて、基本的に両者のシステムは統合する方向で検討するが、業務内容によって併用,,, ,,,することも可能とすることとした。,,, ,,,,,, ,,,（１）A社が通信販売を開始することにおけるシステムの変更箇所についての視点,,, ,,,,,, ,,,,　通信販売を新たに開始する目的は、A社が取り扱っている消耗品の販売をB社の通信販売網へ乗せ、顧,, ,,,,客の購入手段を拡大することである。商品については、A社の商品の特性上、A社の消耗品以外の商品に,, ,,,,ついて販売方法は変更しない。A社の取り扱う大型白物家電とB社が取り扱う日用雑貨とは、管理方法も,, ,,,,異なっている。物流については、A社では店舗と物流倉庫が関連付けられており、物流倉庫間で在庫をや,, ,,,,り取りすることは基本的にはない。B社の物流倉庫は3か所に集約されており、どの倉庫からでも任意の顧,, ,,,,客へ商品を発送できるようになっている。時間的、物理的制約から、当面物流倉庫は両社既存のままとし、,, ,,,,取扱商品も変更しない方針である。顧客については両社ともほぼ同じ管理方法である。,, ,,,,,, ,,,（２）データ配置についての視点,,, ,,,,,, ,,,,　販売管理システムについて、A社は店舗ごとにマスタが配置され、夜間バッチ処理で本社に販売データが,, ,,,,集約されている。B社の販売管理システムのデータは本社で集中管理されている。顧客管理システム、在,, ,,,,庫管理システムともデータは各社の本社に一元管理されている。,, ,,,,,, ,,イ―２　システム構造の見直し,,,, ,,,,,, ,,,　統合した新システムの構築が最適と考えられるが、会社合併までの準備期間が短いため、新たなシステム,,, ,,,構築は物理的に難しい。私は、システム構造として、①A社もしくはB社のシステムに片寄せする、②両者のシ,,, ,,,ステムを併用するのいずれかの方式を考えた。,,, ,,,,,, ,,,（１）システムの機能面,,, ,,,,,, ,,,,　販売管理システムについては、共通機能が多い点、通信販売をA社が新規に開始する点を考え、B社の,, ,,,,システムを基本的に使用することにした。ただし、大型白物家電など特定の商品については、A社のシステ,, ,,,,ムを当面使用する。顧客管理システムについては、B社のシステムの機能がA社のシステムの機能を包含,, ,,,,しているため、B社のシステムに片寄せする。商品の取り扱い、物流倉庫の運用などについて変更がない,, ,,,,ため、在庫管理システムについては、両者のシステムを継続して使用する。,, ,,,,,, ,,,（２）データの配置,,, ,,,,,, ,,,,　データは一元管理する。ただし、システムの機能に関連して両者のシステムを併用する場合に、従来通り,, ,,,,データを持たせる必要性を考慮しなければならない。店舗ごとに管理されていたA社の販売管理システム,, ,,,,のデータは統合する。新システムは、B社のシステムが主体となるため、B社のデータベースを使用する。,, ,,,,合併後も残るA社のシステムに対応するため、A社のシステムからB社のデータベースへアクセスする汎用,, ,,,,部品を作成する。,, ,,,,,, ,,イ―３　メリットの選定理由,,,, ,,,,,, ,,,　販売管理システムについて、大型白物家電の販売方法は、会社合併後も当面変更する予定はなく、システ,,, ,,,ムの修正・変更などについてはB社のシステムに限定できるメリットがある。顧客管理システムについては、B,,, ,,,社のシステムに片寄せするため、保守に対する考え方や方法についてB社のポリシを継続できるメリットが考,,, ,,,えられる。在庫管理システムについて、共通化を推進することで管理工数を削減できる。データベースの統合,,, ,,,については、データベースサーバの運用コスト削減メリット、顧客データなど合併前に両者がもっていたデータ,,, ,,,の相互活用が期待できる。,,, ,,,,,, ,■設問ウ,,,,, ,,,,,, ,,ウ　新しいシステム構造におけるデメリットとデメリットの軽減方法,,,, ,,,,,, ,,,（１）販売管理システムのシステム構造について,,, ,,,,,, ,,,,　販売管理システムは、A社又はB社のシステムに統合できなかったため、両者のシステムを併用するシス,, ,,,,テム構造となったことがデメリットである。ユーザに対して複数のシステムへアクセスさせることは、操作ミス,, ,,,,を生じさせたり、使用性を低下させたりする可能性が高い。新しい販売管理システムはB社の販売管理シ,, ,,,,ステムを基本的に踏襲するため、Webアプリケーションプログラムとなる。私は、両者の販売管理システ,, ,,,,ムへのポータルとなるインターフェースをWebアプリケーションとして構築し、従来のシステムの機能を呼び,, ,,,,出す方式として、ユーザには統一感を与え、新たに開発する部分を最小限に抑えることによりデメリットを,, ,,,,軽減することとした。,, ,,,,,, ,,,（２）データの一元管理について,,, ,,,,,, ,,,,　システムを統合することが基本路線であり、データについては一元管理が必須の条件といえる。しかし、,, ,,,,一元管理することによって、重複データやデータ属性の相違などが生じるため、両者のシステムで使用して,, ,,,,いたコードなど一部のデータを従来通り使用できなくなるというデメリットが生じる。単にコードを統一するだ,, ,,,,けで済めば簡単であるが、コードが変更になることによる業務上のミスが増加する可能性がある。今回の,, ,,,,システム構造では、マスタテーブルはB社のデータベース統合する。多くのマスタテーブルは両社が使用し,, ,,,,ており、統合に際しA社のコードに対応する新たなB社のコードを付与し、テーブルを統合することとした。,, ,,,,A社のシステムを継続して使用する部分については、A社のコードを統合先のB社のコードに変換するテー,, ,,,,ブルを用意する。さらに、A社のコードからB社のコードへ自動的に変換できる機能を実装することによって,, ,,,,ユーザの負担を軽減することとした。　以上,, ,,,,,, 平成23年度　問1　複数のシステムにまたがったシステム構造の見直しについて,,,,,, ,,,,,, ,　近年、情報システムへの要求は、事業統合に伴う業務システムの統合や、事業を横断した顧客動向の把握など、,,,,, ,複数のシステムに関連するものが増える傾向にある。それらの要求に対応するとき、機能やデータの配置などのシス,,,,, ,テム構造を全体最適の観点から対象となる全システムにまたがって見直し、機能追加の容易性の確保や変更時の,,,,, ,影響範囲を狭めることも重要である。,,,,, ,　このような複数のシステムにまたがったシステム構造の見直しにおいて、システムアーキテクトは、たとえば、次のよ,,,,, ,うな視点から業務とシステムを分析する。,,,,, ,,,,,, ,,・新たな商品やサービスに対応する際の変更箇所や変更方法の傾向,,,, ,,・システムによる機能の配置の違い,,,, ,,・データの配置の流れ,,,, ,,,,,, ,　分析の結果に基づき、複数の類似した機能及びデータを共通化するために、コンポ―ネントの分割・統合を実施し,,,,, ,たり、マスタファイルを各システムから分離・統合したりすることなどを検討し、システム構造を見直す。多くの場合、考,,,,, ,えられるシステム構造は複数あり、それぞれにメリットやデメリットがあるので、そのメリットを生かすとともにデメリット,,,,, ,の軽減方法を検討したうえで、新しいシステム構造を選定する。,,,,, ,　例えば、システム間の接続が複雑化してしまう場合には、複雑化を解消するために、連携基盤を採用して各システ,,,,, ,ムをハブ型に接続する。統合しようとするマスタファイルのコード体系が異なる場合には、互いのデータを関連付ける,,,,, ,ために、新たなコード体系を定義して新旧のコードの相互変換を可能にする。,,,,, ,　あなたの経験と考えに基づいて、設問ア～ウに従って論述せよ。,,,,, ,,,,,, ,設問ア,,,あなたが携わった複数のシステムにまたがったシステム構造の見直しについて、見直しの背景と概要、対,, ,,,,象となった複数のシステムの概要を800字以内で述べよ。,, ,設問イ,,,設問アで述べたシステム構造の見直しにおいて、業務とシステムをどのような視点から分析し、どのような,, ,,,,新しいシステム構造を選定したか。メリットなどの選定理由とともに、800字以上1600字以内で具体的に述べ,, ,,,,よ。,, ,設問ウ,,,設問イで述べた新しいシステム構造には、どのようなデメリットがあり、どのような軽減方法を検討したか。6,, ,,,,00字以上1200字以内で具体的に述べよ。,, ,,,,,, 【解説】,,,,,, ,,,,,, ,　システムアーキテクトの重要な観点である全体最適に関する出題である。複数のシステムにまたがる題材を求めら,,,,, ,れるので、単一システムについての論述ではなく、広域的な視点で論じる必要がある。このようなシステム見直しの経,,,,, ,験者であれば、それなりの論述が可能であろうが、経験していない人には取りつきにくい題材である。,,,,, ,　設問文に沿って章立てすると、次のようになる。,,,,, ,,,,,, ,,第1章　見直しの背景と概要及び対象となった複数のシステムの概要,,,, ,,,１．１　見直しの背景と概要,,, ,,,１．２　対象となった複数のシステムの概要,,, ,,第2章　複数のシステムにまたがったシステム構造の見直し,,,, ,,,２．１　業務とシステムの分析の観点,,, ,,,２．２　新しいシステム構造の選定,,, ,,第3章　新しいシステム構造のデメリットと軽減方法,,,, ,,,３．１　新しいシステム構造のデメリット,,, ,,,３．２　デメリットの軽減方法,,, ,,,,,, ,　次に、各章、節ごとに論述のポイントを説明する。,,,,, ,,,,,, 第1章　見直しの背景と概要及び対象となった複数システムの概要,,,,,, ,,,,,, ,〔１．１　見直しの背景と概要〕,,,,, ,,,,,, ,,　この節は、問題文の最初の段落の内容に該当している。業務システムの統合や、事業を横断した顧客動向の把,,,, ,,握など、複数のシステムに関連する情報システムへの要求が、開発期間の長期化や開発コストの増大につなが,,,, ,,ることを論じればよいだろう。,,,, ,,　設問アでは、章立てに対して、明示的に記述することが重要である。「見直しの背景」、「見直しの概要」という,,,, ,,言葉を、意図的に論述に使うようにする。,,,, ,,,,,, ,,◆論述例,,,, ,,,,,, ,,,第1章　見直しの背景と概要及び対象になった複数のシステムの概要,,, ,,,１．１　見直しの背景と概要,,, ,,,,,, ,,,,　自動車販売業を営むA社では、大量の事務処理を目的として汎用コンピュータを導入し、複数のシステム,, ,,,,を稼働させ、開発・維持を行ってきた。その結果、インターネット、携帯電話、提携ATMのチャネルが増大し,, ,,,,複数システムを横断する要望が発生した場合、開発期間の長期化や開発コストの増大につながっていた。,, ,,,,これが見直しの背景となり基幹業務である見込み客管理、受注管理から納車管理までのシステムを全体再,, ,,,,構築することになった。,, ,,,,　見直しの概要としては、システム間の接続を複雑化させないために、連携基盤を採用して、各システムを,, ,,,,ハブ型に接続するように設計した。ただし、連携基盤を導入することでアプリケーションの”リライト”が発生,, ,,,,するが、顧客側にデメリットが生じないように、”リライト”が不要なプログラムについてはラッピング技術を適,, ,,,,用して対応することにした。,, ,,,,,, ,〔１．２　対象となった複数のシステムの概要〕,,,,, ,,,,,, ,,　ここでは、単体ではなく、複数のシステムについて、それらの概要を述べる。きちんとシステム名を挙げてから説,,,, ,,明することが重要である。一般的に、単体システムについての概要を述べることには慣れていても、複数のシステ,,,, ,,ムに関しては難しいと推測できる。しかし、難しいとしても、明示的に複数のシステムを挙げて論じるようにする。,,,, ,,,,,, ,,◆論述例,,,, ,,,,,, ,,,　対象となる業務は、自動車販売における、見込客管理システム、受注管理システム、納車管理システムであ,,, ,,,る。見込み客管理システムは、セールスパーソンがもつモバイルPCのためのもので、クラウド上で稼働するシ,,, ,,,ステムである。受注管理システムと納車管理システムについては、クライアントサーバ方式を採用していて構築,,, ,,,されているが、A社において、事業統合を行う際に、完全な統合をせず、ブリッジを介して複数の受注管理シス,,, ,,,テムが稼働しているという状況であった。,,, ,,,　私は、A社のシステムアーキテクトとして、全体最適の観点から、次のような観点でシステムの分析をして、デ,,, ,,,メリットの軽減に留意しながら、システム構造の見直しを行った。,,, ,,,,,, 第2章　複数のシステムにまたがったシステム構造の見直し,,,,,, ,,,,,, ,〔２．１　業務とシステムの分析の観点〕,,,,, ,,,,,, ,,　分析の観点については、問題文に「新たな商品やサービスに対応する際の変更箇所や変更方法の傾向」、「シ,,,, ,,ステムによる機能の配置の違い」、「データの配置や流れ」という例が上がっているので、これらを参考にして分析,,,, ,,の視点を選択する。注意しなければならないのは、設問イの前半に注力しないことである。問題文では三つの例,,,, ,,があがっているが、一つの視点を明示すればよい。,,,, ,,　節の前半では、単なる分析の視点だけで終わらせずに、分析内容についてもしっかりと述べることが重要である,,,, ,,。,,,, ,,,,,, ,,◆論述例,,,, ,,,,,, ,,,第2章　複数のシステムにまたがったシステム構造の見直し,,, ,,,２．１　業務とシステムの分析の視点,,, ,,,,,, ,,,,　新たな商品やサービスに対応する際、複数システムに横断的に変更が生じる変更要求における、開発期,, ,,,,間の長期化や開発コスト増という課題を踏まえて、業務やシステムの変更箇所の視点から分析することにし,, ,,,,た。その結果、次の分析結果を得た。,, ,,,,,, ,,,,,（１）商品の増加（5年で４０％増加）, ,,,,,（２）業務数の増加（5年で５％増加）, ,,,,,（３）インターネット、携帯電話、提携端末などのチャネルサービスの増加（5年で3倍）, ,,,,,, ,,,,　以上の分析結果から、インターネット、携帯電話、提携端末などのチャネルサービスに関する要望が多く、,, ,,,,これを踏まえて全体最適をすることを課題と設定した。,, ,,,,,, ,〔２．２　新しいシステム構造の選定〕,,,,, ,,,,,, ,,　問題文に「多くの場合、考えられるシステム構造は複数あり、それぞれにメリットやデメリットなどがあるので、そ,,,, ,,のメリットを生かすとともにデメリットの軽減方法を検討したうえで、新しいシステム構造を選定する」と記述されて,,,, ,,いるので、問題文の趣旨に沿って論述するために、この展開をしっかりと論文に盛り込み、複数のシステム構造を,,,, ,,挙げるようにする。,,,, ,,　なお、デメリットについては設問ウで述べるので、設問イでは簡潔に述べるようにして、論文が冗長にならないよ,,,, ,,うにする。,,,, ,,,,,, ,,◆論述例,,,, ,,,,,, ,,,２．２　新しいシステム構造の選定,,, ,,,,,, ,,,,　チャネルサービスに関する要望は、部分最適の形で各システムに盛り込まれていた。そこで、チャネルサ,, ,,,,ービスに関する機能をコンポーネントとして共通化することにした。その際、次のシステム構造を検討した。,, ,,,,,, ,,,,（１）コンポーネントや各システムをラッピングしたオブジェクト指向のシステム構造,, ,,,,,, ,,,,,　新技術対応が可能、移行コストが安いというメリットがある。一方、既存ソフトウェアを流用するため、根, ,,,,,本的な解決にならないというデメリットがある。, ,,,,,, ,,,,（２）リエンジニアリングのためのパッケージ化されたシステム構造,, ,,,,,, ,,,,,　業務フロー全体を見直し、それにふさわしいパッケージ化されたシステムを導入する。メリットとしては、, ,,,,,新技術への対応が可能であり、システム開発コストの低下が期待できる。デメリットとしては、分析の結, ,,,,,果から、リエンジニアリングに現行業務が適していないこと、移行コストが高いことなどがある。, ,,,,,, ,,,,（３）システム間連携基盤を導入して、チャネルサービスを含む主要システムのプログラムをリライトして,, ,,,,接続するシステム構造,, ,,,,,, ,,,,,　システム間連携基盤を導入して、全体最適の観点から、アプリケーションの構造化を図り、プログラム, ,,,,,をリライトする。メリットとしては、ソフトウェアの保守性の向上、事務システムのわかりやすさの向上など, ,,,,,があげられる。デメリットとしては、システム間連携基盤を導入するためのコスト増や導入期間の長期化, ,,,,,の他、既存システムのうち変更が生じない安定した業務ロジックにまで影響が生じることなどが挙げられ, ,,,,,る。, ,,,,,, ,,,,　以上の検討の結果、私は（３）のシステム間連携基盤の導入と主要システムのプログラムのリライトを採用,, ,,,,することにした。発想自体はオーソドックスであるが、システム開発に関するキャッシュフローを作成した結,, ,,,,果、今回の見直しの背景となった、システム開発期間とコストの抑制が、長期にわたって可能であると判断,, ,,,,したからである。,, ,,,,　ただし、システム間連携基盤を導入して、全面的にプログラムをリライトすると、初期コストが高く、一時的,, ,,,,に導入期間が長くなるという問題があった。そこで私は、分析の結果から判明した業務数の増加が少ないこ,, ,,,,とを踏まえ、コンポーネントごとに、費用対効果を分析して開発範囲を設定し、必要に応じてリライト以外の,, ,,,,方法も検討してコストや期間を抑える方針を設定した。,, ,,,,,, 第3章　新しいシステム構造のデメリットと軽減方法,,,,,, ,,,,,, ,〔３．１　新しいシステム構造のデメリット〕,,,,, ,,,,,, ,,　設問イにおいて、新しいシステム構造のデメリットも述べているので、同じ内容を繰り返して記述すると、冗長な,,,, ,,論文と判断されることになる。そこで、デメリットを更に分析したという展開にして、冗長をさけるようにするとよい。,,,, ,,　デメリットについては、一つ上げただけでは600字を超えない可能性があるので、論述時間に余裕がある場合は,,,, ,,、二つ挙げておくと字数不足のリスクを減らすことができる。ただし、たくさん挙げればよいというものではない。大,,,, ,,きな二つのデメリットについてしっかりと論旨展開した論文の方が、採点者に高いアピールができるだろう。,,,, ,,,,,, ,,◆論述例,,,, ,,,,,, ,,,第3章　新しいシステム構造のデメリットと軽減方法,,, ,,,３．１　新しいシステム構造のデメリット,,, ,,,,,, ,,,,　新しいシステム構造を採用した場合、メリットを生かしてシステムを設計することも重要であるが、同じくら,, ,,,,い、デメリットを軽減する策も重要である。そこで私は、システム構造の選定の際に導いたデメリットのうち、,, ,,,,軽減の対象となりそうなものを検討した。その結果、すべてのコンポーネントを新システム構造に単純に適,, ,,,,応させると費用対効果の面で悪化する、というデメリットが明確になった。そこで、業務ロジックの変更の少,, ,,,,ないコンポーネントを新システム構造に低コストで対応させることを課題として、次に述べるデメリットの軽減,, ,,,,方法を検討した。,, ,,,,,, ,〔デメリットの軽減方法〕,,,,, ,,,,,, ,,　デメリットを課題としたうえで、軽減方法に関して、各種の案を挙げること、あるいは、困難な状況を説明すること,,,, ,,によって”工夫”をアピールするとよい。語尾が「～した」の連続とならないように、「なぜならば～」や「ただし、～と,,,, ,,いう課題が新たに生じた」などと記述して、システムアーキテクトとしての考えのアピールや、読み手を納得させる,,,, ,,ための十分な論旨を展開することが重要である。,,,, ,,,,,, ,,◆論述例,,,, ,,,,,, ,,,３．２　デメリットの軽減方法,,, ,,,,,, ,,,,　低コストで対応するという課題に対して、次の対応策を検討した。,, ,,,,,, ,,,,（１）コンポーネントのソースコードを変更しない方法,, ,,,,,, ,,,,,　アプリケーション構造をそのままにして、プログラムをツールによって自動変換し、システム間連携基盤, ,,,,,に接続できるようにする。, ,,,,,, ,,,,（２）システム間連携基盤のアドオンパッケージを導入する方法,, ,,,,,, ,,,,,　システム間連携基盤には、開発済みのアドオンパッケージがある。これを評価して、流用可能なパッケ, ,,,,,ージを選定して導入する。, ,,,,,, ,,,,　以上の案を検討した結果、私は（１）と（２）を併用して採用し、対処することとした。なぜならば、（２）につい,, ,,,,ては、インターネット、携帯端末、提携端末ごとに、インタフェース関連のアドオンパッケージを導入してコン,, ,,,,ポ―ネントとして扱うことで、各種チャネルとインタフェースが容易にできると考えたからである。（２）を採用,, ,,,,できないコンポーネントについては（１）を採用した。なぜならば、変更要求の生じる頻度の少ないコンポーネ,, ,,,,ントについては、アプリケーション構造を変えずに自動変換することでコスト増を抑えられることができると考,, ,,,,えたからである。　―以上―,, ,,,,,, 平成２３年度　問１　複数のシステムにまたがったシステム構造の見直し,,,,,, ,,,,,, ,　近年、情報システムへの要求は、事業統合に伴う業務システムの統合や、事業を横断した顧客情報の把握など、,,,,, ,複数のシステムに関連するものが増える傾向にある。それらの要求に対応する時、機能やデータの配置などのシス,,,,, ,テム構造を全体最適の観点から対象となる全システムにまたがって見直し、機能追加の容易性の確保や変更時の,,,,, ,影響範囲を狭めることも重要である。,,,,, ,　このような複数のシステムにまたがったシステム構造の見直しにおいて、システムアーキテクトは、例えば、次のよ,,,,, ,うな視点から業務とシステムを分析する。,,,,, ,,,,,, ,,・,新たな商品やサービスに対応する際の変更箇所や変更方法の傾向,,, ,,・,システムによる機能の配置の違い,,, ,,・,データの配置や流れ,,, ,,,,,, ,　分析の結果に基づき、複数の類似した機能及びデータを共通化するために、コンポーネントの分割・統合をしたり、,,,,, ,マスタファイルを各システムから分離・統合したりすることなどを検討し、システム構造を見直す。多くの場合、考えら,,,,, ,れるシステム構造は複数あり、それぞれにメリットやデメリットがあるので、そのメリットを活かすとともにデメリットの,,,,, ,軽減方法を検討したうえで、新しいシステム構造を選定する。,,,,, ,　例えば、システム間の接続が複雑化してしまう場合には、複雑化を解消するために、連携基盤を採用して各シス,,,,, ,テムをハブ型に接続する。統合しようとするマスタファイルのコード体系が異なる場合には、互いのデータを関連付,,,,, ,けるために、新たなコード体系を定義して新旧のコードの相互変換を可能にする。,,,,, ,,,,,, ,設問ア,,,あなたが携わった複数のシステムにまたがったシステム構造の見直しについて、見直しの背景と概要、対,, ,,,,象になった複数のシステムの概要を８００字以内で述べよ。,, ,設問イ,,,設問アで述べたシステム構造の見直しにおいて、業務とシステムをどのような視点から分析し、どのような,, ,,,,新しいシステム構造を選定したか。メリットなどの選定理由とともに、800字以上1600字以内で具体的に述,, ,,,,べよ。,, ,設問ウ,,,設問イで述べた新しいシステム構造には、どのようなデメリットがあり、どのような軽減方法を検討したか。6,, ,,,,00字以上1200字以内で具体的に述べよ。,, ,,,,,, ■解答例,,,,,, ,,,,,, ,（設問ア）,,,,, ,,,,,, ,１．システム構造の見直しの背景と概要,,,,, ,,,,,, ,,　K社は、北日本の地方都市を中心に約150店舗を運営するスーパマーケットである。その当時、大手のスーパマ,,,, ,,ーケットは、インターネットで注文を受け付けて、店舗から顧客が指定する場所に注文商品を配達するネットスー,,,, ,,パ事業を開始していた。K社の経営者層は、経営計画策定時に、ネットスーパ事業への参入とそれに対応する新,,,, ,,システムの開発を決定した。K社は、新システム開発の企画時点から2年前に、生鮮食料品を中心に小売するA,,,, ,,社が、雑貨屋日用品を中心に小売するB社を吸収合併し、社名変更をして出来た会社である。K社が運用してき,,,, ,,た販売管理システムは、A社が保有していたシステム（以下、A系という）とB社が保有していたシステム（以下、B,,,, ,,系という）をほぼそのまま引き継いだシステムだった。,,,, ,,,,,, ,２．見直しの対象になった複数のシステムの概要,,,,, ,,,,,, ,,　私は、K社の情報システム部に所属するシステムアーキテクトであり、Nシステム開発プロジェクトの設計チーム,,,, ,,リーダに任命された。K社の経営者層が当プロジェクトに求めた目標の1つに、売上実績情報を総合的に分析でき,,,, ,,るデータウェアハウス機能（以下、D機能という）の提供があった。そこで私は、A系とB系のD機能を調査し、次の,,,, ,,事実が判明した。,,,, ,,,①A系,,, ,,,,　A系を使用している店舗だけを対象にしたD機能を保有しており、活用もなされていた。,, ,,,②B系,,, ,,,,　B系を使用している店舗だけを対象にした、A系よりも少ないD機能を保有していた。ただし、一部のB系の,, ,,,,店舗の売上実績情報は、このD機能に取り込まれておらず、十分には活用されていなかった。,, ,,,③,,, ,,,,　A系とB系のD機能は統合されておらず、K社の商品企画部は、A系とB系を別々に使って販売動向を分析,, ,,,,していた。A系とB系の売上実績情報は会計システム上だけで合算されていた。,, ,,,,,, ,（設問イ）,,,,, ,,,,,, ,１．私が行った業務とシステムの分析の視点,,,,, ,,,,,, ,,　私は、当プロジェクトの目標に従って、K社全体のD機能を設計しなければならなかった。私は、機能やデータの,,,, ,,配置などのシステム構造を全体最適の観点から対象となるA系とB系を見直し、機能追加の容易性の確保や変,,,, ,,更時の影響範囲を狭めることが重要だと考えた。そこで私は、以下3点の視点から業務とシステムを分析した。,,,, ,,,,,, ,１．１　新たなサービスに対応する際の変更箇所の傾向,,,,, ,,,,,, ,,①A系,,,, ,,,,,, ,,,　A系のD機能は、OLAP（Online Analytical Processing）ツールを保有しておりダイシング・スライシング等を対,,, ,,,話的に実行できた。また、スライシングの基準となるデータ分析軸は10次元まで設定でき、商品群別・店舗別・,,, ,,,週別・購買年齢層別・粗利益群別などの分析が可能だった。私は、K社の経営者層にA系のD機能の良否を確,,, ,,,認し、K社の経営者層はネットスーパ事業を分析対象に含めても十分に使用できると回答した。したがって、A,,, ,,,系のD機能をK社全体に売り上げ動向分析に使用できれば、基本的に機能追加・変更等の改造は不要だった,,, ,,,。,,, ,,,,,, ,,②B系,,,, ,,,,,, ,,,　B系のD機能は、商品群別・店舗別・四半期別等の売上実績統計を帳票によって提供するものだった。OLAP,,, ,,,ツールは付属しておらず、K社の商品企画部の評価は低かった。B系のD機能をK社全体に売上動向分析,,, ,,,に使用するには、多くの変更が必要だった。,,, ,,,,,, ,１．２　システムによる機能配置の違い,,,,, ,,,,,, ,,①A系,,,, ,,,,,, ,,,　A系は、ソフトウェアパッケージの一部をカスタマイズして開発されたシステムだった。A系のソースプログラム,,, ,,,は公開されており、K社の情報システム部は、ソフトウェアパッケージの開発元の協力を得ながら、カスタマイ,,, ,,,ズを実施していた。A系のD機能は、サブシステムとして実装されており、それだけを切り離して稼働出来た。,,, ,,,,,, ,,②B系,,,, ,,,,,, ,,,　B系のD機能は他の機能と一緒に提供されており、D機能だけを切り出して稼働させるには、多くの追加・変,,, ,,,更作業が必要だった。また、B系は、ソフトウェアパッケージであり、カスタマイズは実施されていなかった。B系,,, ,,,のソースプログラムは公開されておらず、変更はできなかった。,,, ,,,,,, ,１．３　データの配置や流れ,,,,, ,,,,,, ,,①A系,,,, ,,,,,, ,,,　A系を使用している店舗のPOS端末は、入力された売上実績情報を店舗サーバに転送・記録し、さらにその,,, ,,,売上実績情報はIP-VPNを通じてA系用の本社サーバに転送・記録される。夜間バッチ処理によって、A系用,,, ,,,の本社サーバ内にある売上実績情報は、A系のD機能のデータウェアハウス用のデータベース形式に変換・,,, ,,,格納される。,,, ,,,,,, ,,②B系,,,, ,,,,,, ,,,　B系を使用している店舗のPOS端末は、入力された売上実績情報を店舗サーバに転送・記録し、さらにその,,, ,,,売上実績情報はIP-VPNを通じてB系用の本社サーバに転送・記録される。B系のD機能は、本社サーバに格,,, ,,,納された売上実績情報を集計し、帳票出力している。,,, ,,,,,, ,２．私が選定した新しいシステム構造とその選定理由,,,,, ,,,,,, ,,　私は、上記の分析の結果に基づき、以下の2点を特徴にする新しいシステム構造を選定した。,,,, ,,,,,, ,２．１　連携基盤を採用したハブ型システム,,,,, ,,,,,, ,,　私は、A系とB系の類似した機能及びデータを共通化するとシステム間接続が複雑になると考えた。そこで、私,,,, ,,は、A系のD機能を独立させハブ化し、A系とB系の両方の本社サーバから売上実績情報を取り込む連携基盤方,,,, ,,式を採用した。,,,, ,,,,,, ,２．２　新コード体系の定義と新旧コードの相互変換,,,,, ,,,,,, ,,　私は、上記の分析過程の中で、A系とB系の商品群の分類基準が異なっていることに気が付いた。そこで、私は,,,, ,,A系とB系を統合する新商品分類コード体系を定義して、新旧コードを相互変換するマスタを設計した。,,,, ,,,,,, ,（設問ウ）,,,,, ,,,,,, ,１．新しいシステム構造のデメリット,,,,, ,１．１　連携基盤を採用したハブ型システム,,,,, ,,,,,, ,,　この方式には、システム構造を簡素化するメリットがあった。しかし、A系の売上実績情報以外に、B系の売上実,,,, ,,績情報と新事業であるネットスーパの売上実績情報も、連携基盤となるA系のD機能に集中して入力されるため、,,,, ,,A系のD機能のデータウェアハウス用のデータベース形式に変換・格納する処理時間が長くなるデメリットがあっ,,,, ,,た。,,,, ,,,,,, ,１．２　新コード体系の定義と新旧コードの相互変換,,,,, ,,,,,, ,,　私は、A系とB系の過去の商品群の分類基準の変遷を調査した。すると、A系の商品群の分類基準は頻繁に変,,,, ,,更されていた。これは新商品が次々と販売されるお菓子やビール・ジュースに比較的多く見られる現象だった。そ,,,, ,,こで、私は新商品分類コードと旧商品分類コードの両方を持つ変換マスタを新設しても1時点の変換しかできず、,,,, ,,長期間に渡って使えないデメリットがあると考えた。,,,, ,,,,,, ,２．デメリットの軽減方法の検討,,,,, ,２．１　連携基盤を採用したハブ型システム,,,,, ,,,,,, ,,　私は、この方式のデメリットである性能不良を軽減するために、以下の3案を検討した。,,,, ,,,,,, ,,①案,,A系のD機能を本社サーバではない、別の専用サーバで実行する。,, ,,②案,,A系のD機能は、本社サーバで実行させるが、データウェアハウス用のデータベースを格納する補助記憶,, ,,,,装置を磁気ディスクから、SSD（Solid State Drive）に変更する。,, ,,③案,,A社の本社サーバのハードウェアをマルチプロセッサシステムに変更して、その中に仮想サーバを複数設,, ,,,,置し、A系のD機能をその1つの仮想サーバ上で実行させる。,, ,,,,,, ,,　私は、上記の3案を比較検討した。その結果、私はネットスーパ事業の売上実績情報が1千万件/年を超えた場,,,, ,,合でも、安価で性能を伸長させやすい③案を採用した。,,,, ,,,,,, ,２．２　新コード体系の定義と新旧コードの相互変換,,,,, ,,,,,, ,,　私は、変換マスタを長期間に渡って使えないデメリットを軽減するために、以下の2案を検討した。,,,, ,,,,,, ,,①案,,商品群の分類基準変更は年1回に限定し、変換マスタの主キーを｛年度、新商品分類コード｝にする。,, ,,②案,,商品群の分類基準変更は随時可能とし、変換マスタの主キーを｛新商品分類コード、摘要開始日｝にする。,, ,,,,,, ,,　私は、K社の商品企画部と協議し、商品群の分類基準を機動的に変更できる②案を採用した。,,,, ,,,,,, 平成２３年度　問２　システムテスト計画の策定,,,,,, ,,,,,, ,　システムアーキテクトは、システムテストの直前だけではなく、様々な局面でシステムテスト計画についての検討を,,,,, ,求められる。その計画の策定において、対象業務の重要度や業務特性を考慮しながら、障害発生時の対応、オンラ,,,,, ,インやバッチのピーク時処理など、テストの重点確認項目を明確にする。重要度や業務特性を考慮した重点確認項,,,,, ,目には、例えば、次のようなものがある。,,,,, ,,・,銀行のATMでの取引業務や小売業のPOSでの売上管理業務など重要度が高く、障害発生時にも一定のサー,,, ,,,ビスを継続しなければならない業務の場合、円滑に縮退運転に移行できること,,, ,,・,株式の取引業務など処理量が極端に変動する業務の場合、想定する最大のデータ量を処理できることに加,,, ,,,え、変動するデータ量にも適切に対応できること,,, ,　システムテストでは、本番と同じ構成をテスト環境として構築し、十分なテスト期間を設定することで、システムの品,,,,, ,質を確保することが望ましい。しかし、一般的には期間や費用などに制約があるので、その中で効率よくシステムの,,,,, ,品質を確保するシステムテスト計画を策定することが重要であり、例えば、次のような工夫を行う。,,,,, ,,・,限られた期間で、網羅性の高いテストを行うために、月次処理に続けて年次処理を実施できる日付を設定し,,, ,,,て、テストの準備工数を削減する。,,, ,,・,限られた費用で、多くのテストケースを実行するために、自動化ツールを採用して人件費を削減する。,,, ,,,,,, ,設問ア,,,あなたが携わったシステムテストにおいて、対象業務と対象システムの概要、及び期間や費用などの制約,, ,,,,について、800字以内で述べよ。,, ,設問イ,,,設問アで述べたシステムのシステムテスト計画を策定する際に、あなたは、どのようなテストの重点確認項,, ,,,,目を策定したか。考慮した業務の重要度や業務特性とともに、800字以上1600字以内で具体的に述べよ。,, ,設問ウ,,,設問イで述べたシステムテスト計画の策定において、制約のある中で効率よくシステムの品質を確保する,, ,,,,ために、あなたが重要と考え工夫した点について、600字以上1200字以内で具体的に述べよ。,, ,,,,,, ■ポイント,,,,,, ,,,,,, ,■出題趣旨,,,,, ,,,,,, ,,　システムアーキテクトは、システムテスト計画の検討において、対象業務の重要度や業務特性を考慮しながら,,,, ,,テストの重点確認項目を設定する必要がある。一般的に期間や費用などの制約があるので、制約の中で効率よ,,,, ,,くシステムの品質を確保するシステムテスト計画を策定することが重要である。,,,, ,,　本問は、システムテスト計画を策定する際に、どのような業務の重要度や業務特性に基づき、どのようなテスト,,,, ,,の重点確認項目を設定したか、具体的に論述することを求めている。また、期間や費用の制約の中で効率よくシ,,,, ,,ステムの品質を確保するために、重要と考え工夫した点について、具体的に論述することを求めている。論述を,,,, ,,通じて、業務の重要度や業務特性及びプロジェクトの制約を踏まえたシステムテスト計画の策定能力を評価する,,,, ,,。,,,, ,,,,,, ,■採点講評,,,,, ,,,,,, ,,　全問に共通して、具体性があり、経験に基づいていることをうかがわせる論述が多かった。一方で、答案用紙の,,,, ,,冒頭で記入を求めている”論述の対象とする計画又はシステムの概要”、”論述の対象とする製品又はシステム,,,, ,,の概要”が未記入又は記入漏れの項目があるなど適切に記述されていないので、評価を下げた論述が相当数あ,,,, ,,った。問題文の引用で文字数を費やし内容が薄い論述や、問題文に例示した項目と一般論の組み合わせからな,,,, ,,る具体性に欠ける論述、設問で問うている内容に対応しない論述も散見された。このような論述では、受験者の,,,, ,,能力や経験を正しく評価できない場合があるので、実際の経験に基づき設問に沿って具体的に論述してほしい。,,,, ,,　また、論述は第三者に読ませるものであることを意識してほしい。例えば、業界特有の用語や略語には説明を,,,, ,,付ける、段落を分けたり見出しを入れたりすることで何について述べているのかを明確にするなど、自分の考えを,,,, ,,第三者に的確に伝えるための工夫をしてほしい。,,,, ,,　問２（システムテスト計画の策定について）では、具体性のある論述が多く、多くの受験者がシステムテストを経,,,, ,,験していることがうかがわれた。一方で、システムテストの計画の策定についての論述を求めたにもかかわらず、,,,, ,,システムテストの実施についての論述に終始するものも見られた。設問では、業務の重要度や業務特性につい,,,, ,,ての論述を求めたが、業務について論述せず、システムの説明やシステムテストの経緯・経過の説明に終始して,,,, ,,いる論述が多く見られた。また、制約がある中でどのように品質を確保したかについての論述を求めたが、制約,,,, ,,内容の記述がないものや、制約と品質確保の工夫が対応していないもの、プロジェクトの制約とシステムテストの,,,, ,,制約を混同しているものなどが散見された。,,,, ,,,,,, ,　対象業務の重要度や業務特性を考慮しながら、システムテストにおける重点確認項目を明確にして、システムテス,,,,, ,トの計画を策定することがテーマの問題である。,,,,, ,　銀行の勘定系システムであれば障害発生時であっても一定のサービスを提供する必要があったり、株式の取引シ,,,,, ,ステムであれば急激に変化するデータ量にも適切に対応する必要があったりするなど、情報システムには対象業務,,,,, ,の重要度や対象業務の特性に対応できる処理能力を有していることが求められる。システムテストでは、このような,,,,, ,重要度や特性を確認できるようなテスト項目を明確にしなければならない。,,,,, ,　システムテストの実施においては、業務への適合度を推し量るため、本番環境と同じテスト環境を構築し、かつ、本,,,,, ,番開始後にテストにおいて想定していなかった事態に遭遇しないように、十分なテスト期間を確保し、システムの品,,,,, ,質を確認することが望ましい。しかし、プロジェクトにはスケジュールやコストに関する制約があり、理想的なシステム,,,,, ,テストが行えないことも多い。システムアーキテクトは、限られたリソースの範囲でシステムの品質を確保するために,,,,, ,、効率の良いシステムテストの計画を策定しなければならない。,,,,, ,　問題文の冒頭には、「システムテストの直前だけではなく、様々な局面でシステムテスト計画についての検討を求,,,,, ,められる」と説明されている。ただし、この問題では全ての局面におけるシステムテストの計画策定について要求さ,,,,, ,れているのではない。問題選択時に落ち着いて確認したい。,,,,, ,,,,,, ,　設問アでは、「対象業務の概要」、「対象システムの概要」、「システムテストにおける期間や費用などの制約」を記,,,,, ,述する。対象業務、対象システムについては、特段に指定されている事項はないため、どのような業務やシステムで,,,,, ,あっても題材にできる。注意すべき点は、対象業務の概要と対象システムの概要の両方を記述しなければならない,,,,, ,ことである。多くの設問アでは、対象業務の概要もしくは対象システムの概要のいずれかが要求事項になっている。,,,,, ,概要には何を記述しても良いが、業務に関する記述のみ、システムに関する記述のみにならないように気を付けて,,,,, ,ほしい。どちらか一方の記述のみであれば減点対象となることが予想される。対象業務の概要が要求されているに,,,,, ,もかかわらず、対象システムの概要を記述してしまう受験者が多いので、対象業務の概要として記述する事項につ,,,,, ,いて準備しておきたい。,,,,, ,　システムテストにおける期間や費用の制約については、一般的なプロジェクトに課せられる期間、費用の制約を記,,,,, ,述できる。期間と費用の制約の両方を記述しても良いし、どちらか一方を記述しても良い。制約であることを説明す,,,,, ,るためには、「なぜ十分な期間が確保できないのか」、「なぜ費用が少ない中でのシステム開発となったのか」という,,,,, ,視点の記述が必要である。単に「短い期間のプロジェクトであった」、「費用が少なかった」という記述にならないよう,,,,, ,に注意したい。,,,,, ,　対象業務や対象システムの概要、期間や費用の制約をうまく調整して、設問アの解答用紙（800字以内）に収まる,,,,, ,ように記述しなければならない。,,,,, ,,,,,, ,　設問イでは、「システムテスト計画を策定する際に設定した重点確認項目」について、「考慮した業務の重要度」や「,,,,, ,業務特性」を含めて記述する。設問イにおいて業務の重要度や業務特性を記述するために、設問アでの対象業務,,,,, ,の概要は必要最低限でよいと考えられる。論文全体のストーリーを作成するときに検討した事項を、設問アと設問イ,,,,, ,に適宜配分すればよい。問題文には業務の重要度や業務特性を踏まえたシステムテストにおける重点確認項目が,,,,, ,2点例示されており、作問者がどのような記述を期待しているのかうかがい知ることができる。例を参考に、設問イの,,,,, ,要求事項である業務の重要度、業務特性、重点確認項目について、それぞれ深く掘り下げ、詳細に記述しなければ,,,,, ,ならない。,,,,, ,　業務の重要度や業務特性について、設問アの制約の記述同様に「なぜ重要なのか」という点を強調して記述する,,,,, ,必要がある。例えば、システムが停止することによって、「すべての顧客との取引が停止し、膨大な金額の損失が発,,,,, ,生する」、「生産ラインが停止し、生産ラインの再開に数日を要する」のように、システムの利用者に多大な影響が生,,,,, ,じるという観点で記述しなければならない。システムの規模そのものは業務の重要度に直接結びつかないが、顧客,,,,, ,に与える影響範囲の広さという観点ではシステムの規模についても言及する必要がある。,,,,, ,　重点確認項目について、一般的なシステムテストにおいて重点確認項目が一つということは考えにくい。重点確認,,,,, ,項目としては少なくとも２、３点は記述しておきたい。設問ウにおいて制約のある中で重点確認項目をテストし、品質,,,,, ,を確保することを述べるため、例えば、システムテストの環境が本番環境と同じか、本番環境に近い環境であること,,,,, ,が要求されるような重点確認項目を取り上げることもできる。要求されている記述項目が1項目となっているため、設,,,,, ,問イの最低字数（800字）を下回らないように注意しなければならない。,,,,, ,,,,,, ,　設問ウでは、システムテスト計画の策定に際し、制約のある中で効率よくシステムの品質を確保するための工夫点,,,,, ,について記述する。制約そのものは設問アで述べており、設問アの記述内容と矛盾しないように注意しなければなら,,,,, ,ない。問題文には、期間の制約がある場合、費用の制約がある場合、それぞれについて一点ずつ例が記述されて,,,,, ,おり、参考にしたい。いずれの例においても、システムテストを効率的に実施することによって、制約をクリアすること,,,,, ,が示されている。費用の制約に対して直接的な金額を示すことは難しいため、問題文の例では、工数削減をもって,,,,, ,費用の削減としている。多くの工夫点を列挙する必要はなく、システムアーキテクトとしてどのような工夫をしたかと,,,,, ,いう観点で数点記述すればよい。,,,,, ,　要求事項について適切に記述すれば、設問ウの最低字数（６００字）を下回ることはないと考えられる。設問アで期,,,,, ,間と費用の両方の制約を述べた場合は、設問ウにおいても両方の制約に対する工夫点を述べなければならないた,,,,, ,め、設問ウを記述する時間配分には注意したい。,,,,, ,,,,,, ■見出しとストーリー,,,,,, ,,,,,, ,■設問ア,,,,, ,,,,,, ,,　設問アには、問題文に直接対応する部分がない。設問アでは、対象業務とシステムの概要、期間や費用などの,,,, ,,制約を述べる。,,,, ,,,,,, ,,,設問ア,,,あなたが携わったシステムテストにおいて、対象業務と対象システムの概要、及び期間や費用など ,,,,,,の制約について、800字以内で述べよ。 ,,,,,, ,,　例として次のような見出しとストーリーが考えられる。,,,, ,,,,,, ,,,ア　対象業務と対象システムの概要及び期間や費用などの制約,,, ,,,ア―１　対象業務と対象システムの概要,,, ,,,,,, ,,,,・,顧客はメディアショップを展開するＡ社, ,,,,・,Ａ社の主力取扱い商品は、ＤＶＤやＣＤなどの映像・音楽ソフト、ゲームソフト、コンサートやイベンドなど, ,,,,,のチケット, ,,,,・,経営のスリム化の一環として、店舗主体の営業形態が本社主導の営業形態へ変更となり、形態変更に, ,,,,,対応するために販売管理システムを刷新, ,,,,・,従来は店舗の店長に相応の権限が委譲されており、店舗ごとに独自戦略色が強かった, ,,,,・,営業形態の刷新後は本社企画部門が戦略を策定し、本社営業部門が実行推進部隊, ,,,,・,本社主導で各種施策を展開することにより、経営方針の徹底ができ、重複業務の排除などコスト削減も, ,,,,,期待されている, ,,,,・,システム的には、従来店舗ごとに主要なデータを管理し、夜間バッチによって本社へデータをアップロー, ,,,,,ドしていた分散処理を、本社集中処理に変更, ,,,,・,新しい販売管理システムでは、店舗には端末を配置し、専用線で本社のサーバ群と接続する, ,,,,・,店舗独自業務用の店舗サーバを配置, ,,,,・,新しい販売管理システムでは、店頭販売に加え、Ｗｅｂオンライン販売、Ｗｅｂ予約に対応できる機能を, ,,,,,追加, ,,,,・,自身の立場は、本案件のシステム構築を行ったシステムインテグレータＰ社に所属するシステムアーキ, ,,,,,テクト, ,,,,,, ,,,ア―２　期間や費用などの制約,,, ,,,,,, ,,,,・,昨今の経済状況により業績が低迷しており、経営のスリム化は1年間の短期で実現することが命題, ,,,,・,新しい販売管理システムは開発期間が10カ月となる, ,,,,・,Ａ社は約１５０店舗を展開しており、この規模の販売管理システムの構築は、過去の同等規模の案件と, ,,,,,比較すると、開発期間が１０％程度短い, ,,,,・,今回のプロジェクトは請負案件であり、受注金額的に見ても、工数を従来の同等プロジェクトと比較して, ,,,,,5%程度少なくしなければならない, ,,,,・,プロジェクトマネージャよりシステムテストに割り当てることのできる期間・工数について、５％程度削減, ,,,,,となる旨の指示が出ている, ,,,,,, ,■設問イ,,,,, ,,,,,, ,,　設問イには、問題文の次の部分が対応する。,,,, ,,,,,, ,,,設問イ,,,設問アで述べたシステムのシステムテスト計画を策定する際に、あなたは、どのようなテストの重点 ,,,,,,確認項目を設定したか。考慮した業務の重要度や業務特性とともに、800字以上1600字以内で具体 ,,,,,,的に述べよ。 ,,,,,, ,,,　システムアーキテクトは、システムテストの直前だけではなく、様々な局面でシステムテスト計画についての,,, ,,,検討を求められる。その計画の策定において、対象業務の重要度や業務特性を考慮しながら、障害発生時の,,, ,,,対応、オンラインやバッチのピーク時処理など、テストの重点確認項目を明確にする。重要度や業務特性を考,,, ,,,慮した重点確認項目には、例えば、次のようなものがある。,,, ,,,,・,銀行のＡＴＭでの取引業務や小売業のＰＯＳでの売上管理業務など重要度が高く、障害発生時にも一, ,,,,,定のサービスを継続しなければならない業務の場合、円滑に縮退運転に移行できること, ,,,,・,株式の取引業務など処理量が極端に変動する業務の場合、想定する最大のデータ量を処理できること, ,,,,,に加え、変動するデータ量にも適切に対応できること, ,,,,,, ,,　例として次のような見出しとストーリーが考えられる。,,,, ,,,,,, ,,,イ　対象業務の重要度と業務特性及び重点確認項目,,, ,,,イ―１　対象業務の重要度と業務特性,,, ,,,,,, ,,,,・,販売管理システムはＡ社の店頭販売を支援するシステムで、販売管理システムが停止するとＡ社の基, ,,,,,本業務そのものが停止する, ,,,,・,新商品の販売開始日、人気アーティストのコンサートチケットの販売開始日にトラフィックが集中する, ,,,,・,販売開始日の中でも開始時点（開店時刻）の午前10時に一段のピークが想定される, ,,,,・,来店する顧客層に社会人が多く、１８時～２０時の時間帯に昼間時の１２０％の負荷が継続する。この, ,,,,,負荷は、販売開始日のピークよりも少ない, ,,,,,, ,,,イ―２　重点確認項目,,, ,,,,,, ,,,,・,可用性の確保が最重要項目であり、ピーク時に処理性能が若干低下しても、可用性を維持するという, ,,,,,要件である, ,,,,・,ピーク時の最大不可状況において、サーバがダウンするようなことがなくシステムが安定的に稼働する, ,,,,,ことを確認しなければならない, ,,,,・,新しい販売管理システムではPCサーバを導入する。夜間の高負荷が継続する時間帯にシステムが安, ,,,,,定して稼働することも確認項目となる, ,,,,・,新販売管理システムを構成する社外販売向けのWebサーバは、アプリケーションサーバの負荷をチェッ, ,,,,,クし、アプリケーションサーバの高負荷時には一部のトラフィックをSorryサーバへ分散させる設計となっ, ,,,,,ている。, ,,,,・,Sorryサーバへの振り分け機能の確認は、アプリケーションサーバをダウンさせないための重要な確認, ,,,,,項目である。, ,,,,・,万一のサーバダウン、電気通信回線の障害などにより店舗から本社に接続できなくなる事態を想定し, ,,,,,て縮退運転が行える設計となっている, ,,,,・,店舗サーバには、店舗独自業務のためのデータと、商品販売を継続するための必要最小限のデータが, ,,,,,格納されている, ,,,,・,店舗側の販売管理システムのプログラムには、サーバとの接続状況を定期的にチェックする機能が実, ,,,,,装されており、本社との接続エラーを検出するとローカル業務に切り替える仕様である, ,,,,・,ローカル業務へのスムーズな切替は重点確認項目である, ,,,,・,縮退運転期間中は、携帯電話網を活用した本社との通信路を確保し、22時の閉店後の夜間バッチによ, ,,,,,って情報交換する, ,,,,・,夜間バッチでは、当日分の販売実績データなどを本社へアップロードし、新しい商品情報などのマスタ, ,,,,,データの差分を店舗へダウンロードする, ,,,,・,適切な時間内に夜間バッチが終了することは重点確認項目である, ,,,,,, ,■設問ウ,,,,, ,,,,,, ,,　設問ウには、問題文の次の部分が対応する。,,,, ,,,,,, ,,,設問ウ,,,設問イで述べたシステムテスト計画の策定において、制約のある中で効率よくシステムの品質を確 ,,,,,,保するために、あなたが重要と考え工夫した点について、600字以上1200字以内で具体的に述べよ ,,,,,,。 ,,,,,, ,,,　システムテストでは、本番と同じ構成をテスト環境として構築し、十分なテスト期間を設定することで、システ,,, ,,,ムの品質を確保することが望ましい。しかし、一般的には期間や費用などに制約があるので、その中で効率よ,,, ,,,くシステムの品質を確保するシステムテスト計画を策定することが重要であり、例えば、次のような工夫を行う,,, ,,,。,,, ,,,,・,限られた期間で、網羅性の高いテストを行うために、月次処理に続けて年次処理を実施できる日付を設, ,,,,,定して、テストの準備工数を削減する。, ,,,,・,限られた費用で、多くのテストケースを実行するために、自動化ツールを採用して人件費を削減する。, ,,,,,, ,,　例として次のような見出しとストーリーが考えられる。,,,, ,,,,,, ,,,ウ　効率よくシステムの品質を確保するために重要と考え工夫した点,,, ,,,,,, ,,,,・,システムテストの準備に関すること, ,,,,,・,新しい販売管理システムでは、Webオンライン販売が新機能となる。システムテストにおけるテスト項 ,,,,,,目についても新規に設定しなければならない ,,,,,・,Webオンライン販売機能について、機能を実現するコンポーネントなど、旧システムと同等な部分に ,,,,,,ついては、旧システムのシステムテストにおけるテスト項目を流用する ,,,,,・,新しい販売管理システムに対応して、予約販売の機能を追加するため、顧客の商品購入パターンが ,,,,,,増加する ,,,,,・,テストケース数が商品購入パターンの組み合わせに対応して飛躍的に増加する ,,,,,・,効率よくテストケースを設定するために、テストケース生成自動化ツールを導入するとともに、外部設 ,,,,,,計を担当した要員を配置し、効率よくテストケースを作成する ,,,,・,システムテストの実施に関すること, ,,,,,・,A社の150店舗には全体で約500台の端末が配備される。全端末を同時に稼働させる負荷テストが ,,,,,,必要 ,,,,,・,店舗への端末配備期間とシステムテストの期間が重複するため、実端末を利用した負荷テストはス ,,,,,,ケジュール的に実施不可能。約半数の端末で実施して結果を吟味することとなる ,,,,,・,Webからのアクセスは開発メンバを動員して実施する予定であったが、外部設計工程の遅延により ,,,,,,十分な要員を確保することが難しくなった ,,,,,・,負荷テストツールを導入する。ツールの選定に際し、Webからのアクセスと同様のトラフィックと社内 ,,,,,,ネットワークからのトラフィックを同時に発生させることができるツールを選択 ,,,,,・,負荷テストツールの導入により、テスト環境構築の工数を０．５人月、負荷テストのテスト工数を２人 ,,,,,,月削減することができ、ツール導入前と同等の品質のテストを実施できた ,,,,,, ■解答,,,,,, ,,,,,, ,■設問ア,,,,, ,,,,,, ,,ア　対象業務と対象システムの概要及び期間や費用などの制約,,,, ,,ア―１　対象業務と対象システムの概要,,,, ,,,,,, ,,,　私はシステムインテグレータP社に所属するシステムアーキテクトである。今回、メディアショップを展開するA,,, ,,,社の販売管理システムの構築を取りまとめた。A社の主力取扱い商品は、DVDやCDなどの映像・音楽ソフト、,,, ,,,ゲームソフト、コンサートのチケットなどである。A社では、経営のスリム化を進めており、店舗主体の営業形態,,, ,,,が本社主導の営業形態へ変更となり、販売管理システムも形態変更に合わせ刷新することとなった。従来は,,, ,,,店舗の店長の権限が強く、店舗ごとに独自戦略色が強かった。営業形態の刷新後は、本社主導で各種施策,,, ,,,を展開することにより、経営方針が徹底でき、重複業務の排除などコスト削減も期待されている。従来は店舗,,, ,,,ごとにマスタをもち、夜間バッチによって本社へ販売データを集約していた分散処理を、本社集中処理に変更,,, ,,,する。新しいシステムでは、店舗には端末を配置し、専用線で本社のサーバ群と接続し、店舗独自業務として,,, ,,,店舗サーバを配置する。新システムでは、店頭販売に加えWeb予約・販売に対応できる機能を追加することと,,, ,,,なった。,,, ,,,,,, ,,ア―２　期間や費用などの制約,,,, ,,,,,, ,,,　A社は、業績が低迷しており、経営のスリム化は1年間の短期間で実現することが命題となっており、新シス,,, ,,,テムの開発期間は10カ月となった。A社の店舗は約150店舗あり、この規模の販売管理システムの構築として,,, ,,,は、過去の同等規模の案件と比較すると、開発期間が１０％程度短い。今回は請負案件であり、従来の同等,,, ,,,プロジェクトと比較して受注金額は５％程度少ない。プロジェクトマネージャよりシステムテストに割り当てるこ,,, ,,,とのできる期間・工数について、５％程度削減となる旨の指示が出ている。,,, ,,,,,, ,■設問イ,,,,, ,,,,,, ,,イ　対象業務の重要度と業務特性及び重点確認項目,,,, ,,イ―１　対象業務の重要度と業務特性,,,, ,,,,,, ,,,　販売管理システムはA社の店頭販売を支援するシステムであり、販売管理システムが停止するとA社の基本,,, ,,,業務そのものが停止するという事態が生じる。新商品の販売開始日、人気アーティストのコンサートチケットの,,, ,,,販売開始日にトラフィックが集中することが事前の調査で分かっている。さらに、販売開始日の中でも販売開,,, ,,,始時点（開店時刻）の午前１０時に一段のピークがあることも判明している。A社へ来店する顧客層には社会,,, ,,,人が多く、会社から帰宅する時間帯の１８時～２０時に昼間時間の１２０％の負荷が継続する。この負荷は、,,, ,,,販売開始日のピークよりも少ないが、継続時間という点で着目しなければならない。,,, ,,,,,, ,,イ―２　重点確認項目,,,, ,,,,,, ,,,　業務の停止を避けるために、可用性の確保が最重要項目であり、ピーク時に処理性能が若干低下しても、,,, ,,,可用性を維持するという要件がA社から示されている。そのため、ピーク時の最大負荷状況においては、サー,,, ,,,バがダウンするようなことがなくシステムが安定的に稼働することを確認しなければならない。新販売管理シ,,, ,,,ステムではPCサーバを導入することが決まっており、夜間の高負荷が継続する時間帯にシステムが安定して,,, ,,,稼働することも重点確認項目である。新販売管理システムを構成する社外販売向けのWebサーバは、アプリ,,, ,,,ケーションサーバの負荷をチェックし、アプリケーションサーバの高負荷時には一部のトラフィックをSorryサー,,, ,,,バへ分散させる設計となっている。Sorryサーバへの振り分け機能の確認は、アプリケーションサーバをダウン,,, ,,,させないための重要な確認項目と考えられる。,,, ,,,　万一のサーバダウン、電気通信回線の障害などにより店舗から本社に接続できなくなる事態が発生したとき,,, ,,,には縮退運転を行う。縮退運転をするために、店舗サーバには、店舗独自業務のためのデータと、商品販売,,, ,,,を継続するための必要最小限のデータが格納されている。店舗側の販売管理システムのプログラムには、サ,,, ,,,ーバとの接続状況を定期的にチェックする機能が実装されており、本社との接続エラーを検出するとローカル,,, ,,,業務に切り替える仕様である。業務の継続性という観点からローカル業務へのスムーズな切替は重点確認項,,, ,,,目である。,,, ,,,　縮退運転期間中は、携帯電話網を活用した本社との通信路を確保し、２２時の閉店後の夜間バッチによって,,, ,,,情報交換する。夜間バッチでは、当日分の販売実績データなどを本社へアップロードし、新しい商品情報など,,, ,,,のマスタデータの差分を店舗へダウンロードしなければならない。私は、翌日の業務を開始できるようにする,,, ,,,ためには、適切な時間内に夜間バッチが終了することについても重点確認項目とした。,,, ,,,,,, ,■設問ウ,,,,, ,,,,,, ,,ウ　効率よくシステムの品質を確保するために重要と考え工夫した点,,,, ,,,,,, ,,,（1）システムテストの準備に関すること,,, ,,,,,, ,,,,　新しい販売管理システムでは、Webオンライン予約とWebオンライン販売が新機能となる。システムテスト,, ,,,,におけるテスト項目についても、従来のシステムテストについて設定したテスト項目以外に新規に設定しな,, ,,,,ければならない。私は効率よくテスト項目を設計するため、Webオンライン予約、Webオンライン販売機能に,, ,,,,ついて、機能を構成するコンポーネントなど、従来の販売管理システムと同等な部分については、旧システ,, ,,,,ムのシステムテストにおけるテスト項目を流用することとした。,, ,,,,　業務機能として、予約販売を開始するため、顧客の商品購入パターンが増加する。新しい販売管理シス,, ,,,,テムにおいても予約販売の機能を追加することになるため、相応のテストが必要となる。具体的には、テス,, ,,,,トケース数が商品購入のパターンの組み合わせに対応して飛躍的に増加する。私は、効率よくテストケー,, ,,,,スを設定するために、テストケース生成自動化ツールを導入するとともに、外部設計を担当した要員を配置,, ,,,,し、効率よくテストケースを作成できる工夫をした。,, ,,,,,, ,,,（２）システムテストの実施に関すること,,, ,,,,,, ,,,,　A社の１５０店舗には全体で約５００台の端末が配備される。システムの可用性を確認するためには、全,, ,,,,端末を同時に稼働させる負荷を掛けた場合に、システムがダウンせず稼働していることを確認するテスト,, ,,,,が必要となる。しかし、店舗への端末配備期間とシステムテストの期間が重複するため、実端末を利用した,, ,,,,負荷テストはスケジュール的に実施不可であった。約半数の端末で実施して結果を吟味しなければならな,, ,,,,い。また、Webからのアクセスは開発メンバを動員して実施する予定であったが、外部設計工程の遅延によ,, ,,,,り十分な要員を確保することが難しくなった。私は、負荷テストツールを導入して、テスト環境の物理的な制,, ,,,,約に対抗することとした。ツールの選定に際し、Webからのアクセスと同様のトラフィックと社内ネットワーク,, ,,,,からのトラフィックを同時に発生させることができるツールを選択した。負荷テストツールの導入により、テス,, ,,,,ト環境構築の工数を０．５人月、負荷テストのテスト工数を２人月削減することができ、ツール導入前と同等,, ,,,,の品質のテストを実施できた。　以上,,