SAシステムアーキテクト試験 午後Ⅰ
平成26年度秋期 システムアーキテクト 午後Ⅰ 問3
事例を読んで設問の答えを考えてから、解説のポイントとIPA公式の解答例・採点講評で確認しましょう。
問題


解き方のヒントを見る
確認した事実と判断を分けて考える
監査への対応やデータの確認を考えるときは、確認できた事実と、そこから導いた判断を分けて整理しましょう。判断の前提が与えられた情報で確かめられるか、という一つの観点に絞って検討します。
この問題で問われていること
この問題では、何らかの対応や確認が必要だと考えたときに、その判断を支える事実が何かに注目しましょう。自分の経験や一般的な印象を補って考えていないか、判断と根拠のつながりを点検することが大切です。
視点
気になる点を見つけたら、確認済みの内容と自分の解釈を分けて捉えます。解釈を事実として扱っていないかを振り返り、判断の根拠を自分の言葉で説明できるか確かめましょう。
確認ポイント
- 判断の根拠となる事実を捉えているか
- 自分の解釈を確認済みの事実として扱っていないか
- 示された情報にない前提を判断に加えていないか
正解と解説を見る
解説
分散していた勤務関連データの一元管理と警告一覧による確認の効率化を理解し、業務ルールを確認条件に具体化する問題です。部をまたぐ工数集計と夏期休暇の予定・実績の比較まで考えることが要点です。
問題の全体像
D社では、勤務管理表、プロジェクト別業務時間、残業届出書が別々に管理され、データの不一致や部長の確認負担が生じています。勤務時刻の信頼性、プロジェクト工数の精度、夏期休暇の取得率にも問題があります。新システムでは、市販パッケージに加えて、ダウンロードデータから工数一覧や警告一覧などを作成します。出題趣旨では、利用者のシステム化要件とパッケージの機能を正しく理解し、必要な機能を設計する能力を問うとされています。各改善が監査の指摘を解消できるかを、業務ルールとデータ構造から判断します。
設問1(1)(データの管理方法)
指摘1の「勤務管理表、プロジェクト別業務時間及び残業届出書の3種類のデータ」と、その不一致に着目します。新システムでは、勤務実績、プロジェクト別業務時間、残業予定を同じシステムに入力します。公式解答例では、3種類全てを新システムで一元管理することが要点です。30字以内では「3種類のデータを全て新システムで一元管理する。」とまとめられます。採点講評では、二つのデータだけを取り上げた解答が多かったとされており、残業届出書に相当するデータも含める必要があります。
設問1(1)(部長の確認方法)
指摘1の、平均50名の部員について全ての日の明細を確認することには無理がある、という記述に着目します。追加機能は基準を満たさないデータを警告一覧に出力し、部長はその内容を精査して部員に確認します。公式解答例では、部長が確認すべきデータだけを警告一覧に出力することが要点です。30字以内では「部長が確認すべきデータだけを警告一覧に出力する。」と表せます。確認対象を絞る仕組みまで示すことが必要です。
設問1(2)
指摘2は、社員が入力した開始時刻・終了時刻を確認するための根拠がないことです。新システムの概要(1)では、ICカードリーダ付き入力端末で入退室時刻を記録し、初回入室時刻と最終退室時刻を取り込みます。公式解答例では、この入退室時刻の記録機能を挙げています。35字以内では「ICカードリーダ付き入力端末で入退室時刻を記録する機能」とまとめられます。終業後のサークル活動などもあるため、退室時刻をそのまま業務終了時刻とするのではなく、入力時刻を確認する根拠として利用します。
設問2(a)
最終退室時刻が未入力となる、出社を伴わない日の扱いを確認します。本文では、終日社外で業務を行う場合は始業区分を出張とし、始業区分が出張又は休暇種別の場合は終業区分を空白にすると定めています。このため、公式解答例のaは「空白」です。採点講評でも、本文に示された終業区分の4種類から判断すべきところ、それ以外の解答が見られたとされています。
設問2(b)
最終退室時刻が終了時刻より早い場合は、フロアから退室した後にも社外で業務を続けた状況を考えます。終業区分が直帰であれば、この時刻の関係を説明できます。したがって、公式解答例のbは「直帰」です。単に退室時刻が早いことから早退と判断せず、業務の終了時刻との前後関係に着目することが必要です。
設問2(c)
就業条件では、連続する3か月の残業時間上限が120時間であり、警告一覧は上限の9割を超える社員を確認します。120時間の9割は108時間なので、当月とその前の2か月を対象に月間残業時間を合計します。公式解答例のcは「当月までの連続する3か月」です。空欄の後に「月間残業時間の合計」が続くため、空欄には集計対象の期間を入れます。採点講評では、「連続する3か月の累計」としてしまった解答が多かったと指摘されています。
設問2(d)
確認項目⑤は、プロジェクト別業務時間を翌営業日中に入力しているかを確認するものです。表1から、対象業務の明細と、その勤務年月日・入力年月日を持つファイルを探します。該当するのは「月間プロジェクト別業務時間明細」であり、公式解答例のdもこのファイル名です。月間業務時間明細にも日付属性はありますが、ここで確認する対象はプロジェクト別業務時間の入力です。
設問2(e)
入力期限を判定するには、業務を行った日と入力した日を比較します。月間プロジェクト別業務時間明細では、業務を行った日を示す属性が「勤務年月日」です。公式解答例ではeを「勤務年月日」としています。翌営業日までの入力が容認されるので、比較する二つの日付が2営業日以上離れていないことを確認します。公式解答例では、eとfは順不同です。
設問2(f)
勤務年月日と比較するもう一方の日付は、プロジェクト別業務時間を入力した日を示す「入力年月日」です。したがって、公式解答例のfは「入力年月日」です。翌営業日中という期限なので、土曜日・日曜日・祝日を踏まえた営業日で間隔を判断します。公式解答例ではeとfは順不同であり、勤務年月日と入力年月日の組合せを押さえることが要点です。
設問3(1)(内容)
現在の設計では、部長がダウンロードできるのは自分の部のデータです。しかし、レビューで求められているのはプロジェクト単位の工数実績なので、他部の参加者の工数も含める必要があります。公式解答例では、部内だけでなく他部のデータと合わせた一覧を作成することを挙げています。30字以内では「部内だけでなく他部のデータと合わせた一覧を作成すること」とまとめられます。個人や部の範囲から、プロジェクト全体へ集計範囲を広げる点が要点です。
設問3(1)(理由)
本文の「プロジェクトは複数の部が関わっているものが多い」という記述が直接の根拠です。自部のデータだけでは、同じプロジェクトに参加する他部の社員の工数が抜け、プロジェクト全体の実績を把握できません。公式解答例では「プロジェクトは複数の部が関わっているものが多いから」としています。この表現は30字以内に収まり、一覧の集計範囲を広げる必要性を具体的に説明しています。
設問3(2)(判断した理由)
指摘4には、予定を入力しない社員だけでなく、予定どおりに休まない社員も多いとあります。予定の3日分入力チェックは予定の有無を、取得奨励メールは予定日前の働きかけを扱いますが、予定日が過ぎた後に取得したかどうかは確認していません。公式解答例では、休暇取得予定日に休まなかった社員を把握できないことを理由としています。35字以内では「休暇取得予定日に休まなかった社員を把握できないから」とまとめられます。
設問3(2)(社員の条件)
表1の「夏期休暇明細」と、その予定実績区分・休暇年月日に着目します。本文では、予定データは取得予定年月日から、実績データは毎日の勤務実績から作成すると説明されています。公式解答例では、当年の過去日付の予定データ件数が実績データ件数より多い社員、又は予定日が過ぎても実績データが存在しない社員を挙げています。40字以内では「当年の夏期休暇明細で過去の予定データ件数が実績件数より多い社員」と表せます。将来の予定を未取得と判定せず、既に予定日が過ぎたものを確認することが必要です。採点講評でも、夏期休暇明細のファイル設計を誤解したと思われる解答が目立ったとされています。
学習のポイント
本文の業務ルールをファイル・属性・判定条件に対応付け、管理対象の範囲と予定・実績の違いを読み取る力を養います。
出典:独立行政法人 情報処理推進機構(IPA)平成26年度秋期 システムアーキテクト試験 午後Ⅰ 問3(公式資料:問題冊子(PDF) / 解答例 / 採点講評)
関連する過去問一覧
IPA Advancedは非公式の学習サイトです。解説にはAIによる補助生成を含む場合があります。公式の問題冊子・解答例・採点講評を優先し、誤りは確認後に訂正します。運営・編集方針